What do you mean by this? I wrote a similar (but in C) for the LS and the LS discovery process was achieved by doing a broadcast ping which the box responds to. Is this what you want to do?
Female answer: NoYes
The set of ACP-Commands includes an ACP_DISCOVER, which retrieves info about hard- and firmware version, IP-settings etc. LSUpdater uses this to discover the LS in the network by broadcasting this packet and collecting the answering LS. The reply is then used to display the info in the main dialog of the updater.
I think there are a couple of other interesting commands namely: ACP_Change_IP, SPECIAL_CMD_EMMODE, SPECIAL_CMD_NORMMODE, ACP_PART, SPECIAL_CMD_REBOOT. I'd like to incorporate these before moving on to the real interesting (and probably toughest) bit: ACP_FIRMUP_End, ACP_FIRMUP2, ACP_FILE_SEND, ACP_FILESEND_END. That would complete the custom updater for the stock firmware side.
What might be interesting, especially for those who'd like to stay with the (modified) stock firmware: SPECIAL_CMD_SAVECONFIG, SPECIAL_CMD_LOADCONFIG, SPECIAL_CMD_FACTORYSETUP, SPECIAL_CMD_MUULTILANG, SPECIAL_CMD_SHUTDOWN.
In the meanwhile I discovered that while the LSUpdater (and therefore acp_commander) uses UDP, ls_sonar uses more or less the same packets but on TCP (unfortunately only with a very limited set of commands). If I had to chose the protocol, I'd taken TCP because of the overhead. With UDP you never know if your packet found its way, if the packet was cripled etc, etc... . ls_sonar shows that buffalo has (also) implemented this in TCP. I wonder why the did the same for UDP and what protocoll the other boxes rely on.