ki-bo
commented
9 months ago I considered something like that but see problems with this approach:
The main problem is that the MEGA65 does not have any IP address it should respond to. It has a configured MAC address, but ICMP ping is an IP based protocol and can't be used just with MAC addresses.
Another issue is you would need to implement this in hardware (VHDL) which is quite complex. And it is not sufficient to just implement the ICMP protocol, but in addition also the ARP protocol. The PC will send ARP requests first to learn which MAC address is responsible for the target IP address, and only in a second step will send ICMP ping requests to that MAC address (using the IP layer in-between).
I believe all this will make more sense if we have a TCP/IP stack running on a separate CPU, not on the 45gs02. We already have a second CPU running for the serial/matrix monitor. As I would like to equip that one with a TCP/IP stack, anyway, at some point (to allow for debugging over network), this would be the perfect entity to also enable this kind of discovery.
Up until then, I rather am looking into providing a "beacon" like packet broadcasted once per second with special payload to indicate a MEGA65 is present and has its remote control enabled. As we don't have any IP address configuration or DHCP available in VHDL, the better protocol for this might be IPv6, as it provides a link-local address that is derived from the MAC address (EUI-64).
The existing network tooling (etherload, mega65_ftp, and soon M65Connect) could provide an improved user experience if they could detect whether the MEGA65 is listening at address x.x.x.65 on a given subnet without initiating a file transfer or other action. One way this could be accomplished is by responding to pings (ICMP echo requests) when in network listening mode.
As always, the MEGA65 should do nothing if not in its active listening mode. The user must have networking set up correctly and have pressed Shift+Pound to start active listening before the MEGA65 responds to pings. This allows tools to prompt the user to start active listening mode, and either abort or wait for it to become active.
One enhancement: It would be great if the ping reply could assert that a MEGA65 is sending the reply. (I don't know if such replies are allowed to contain metadata about the host.) This would allow tools to help users troubleshoot IP address collisions on the network: "There's something at address 65 but it's not a MEGA65, you need to fix this." Compliance with the ping protocol would be ideal, so a common network ping tool could also be used.