Is your feature request related to a problem? Please describe.
Currently, there is no way to detect whether there is a MAGE65 available on the local network to predict whether a connection attempt via mega65_ftp or etherload would succeed. A discovery of the MEGA65 might also enable us to connect to it without knowing specifics about which network interfact to use or what IP address might be free/available for the MEGA.
Describe the solution you'd like
The MEGA65 should provide a way to discover it in the network. This should work in HW so no software needs to be run first. A regular broadcast of a beacon might be a good way to detect it in the network. Using IPv6 and a link local address created from its MAC address via EUI-64 enables us to provide a way to connect to the MEGA without needing to configure a static free IP address first. As the broadcasted beacon packet will contain this link local address as src address, we automatically learn about an ip address to use for the ethernet tools just by listening to the beacon.
Downsides are: the tool on PC side needs to be enabled for listening, as usually host firewalls block all incoming traffic which is non-related to existing connections. This is typically asked via a UI dialog in macOS and Windows once the tool starts listening, so could be easy for the user to get this done.
Another requirement would be that IPv6 needs to be enabled on the network interface where the mega is connected, but as of today, IPv6 is enabled by default anyway.
Describe alternatives you've considered
Alternatives are to send special discovery packets via multicast or broadcast and let the mega reply to those instead of regular beacons. However, this will still need to open the firewall, as replies to those broadcasted requests need to be unicast which is not considered related traffic by most host firewalls. In addition, using multicast will need to have the mega to subscribe to the multicast address so switches will forward those packets. This will increase complexity in VHDL considerably, as the discovery mechanism needs to be implemented in HW, in order to be available before any ethernet software is uploaded and started.
Additional context
Ideally, the implementation will allow for a zero-configuration connection to the mega on the command-line (with maximum latency being the beacon interval, probably ~1 sec). M65Connect can monitor the beacon on the network and automatically use the IPv6 link local address when the connection is started, which will then have no delay.
In any case, it seems sensible to add IPv6 support to ETHLOAD.M65 and mega65_ftp, which would be desirable anyway.
Is your feature request related to a problem? Please describe. Currently, there is no way to detect whether there is a MAGE65 available on the local network to predict whether a connection attempt via mega65_ftp or etherload would succeed. A discovery of the MEGA65 might also enable us to connect to it without knowing specifics about which network interfact to use or what IP address might be free/available for the MEGA.
Describe the solution you'd like The MEGA65 should provide a way to discover it in the network. This should work in HW so no software needs to be run first. A regular broadcast of a beacon might be a good way to detect it in the network. Using IPv6 and a link local address created from its MAC address via EUI-64 enables us to provide a way to connect to the MEGA without needing to configure a static free IP address first. As the broadcasted beacon packet will contain this link local address as src address, we automatically learn about an ip address to use for the ethernet tools just by listening to the beacon.
Downsides are: the tool on PC side needs to be enabled for listening, as usually host firewalls block all incoming traffic which is non-related to existing connections. This is typically asked via a UI dialog in macOS and Windows once the tool starts listening, so could be easy for the user to get this done.
Another requirement would be that IPv6 needs to be enabled on the network interface where the mega is connected, but as of today, IPv6 is enabled by default anyway.
Describe alternatives you've considered Alternatives are to send special discovery packets via multicast or broadcast and let the mega reply to those instead of regular beacons. However, this will still need to open the firewall, as replies to those broadcasted requests need to be unicast which is not considered related traffic by most host firewalls. In addition, using multicast will need to have the mega to subscribe to the multicast address so switches will forward those packets. This will increase complexity in VHDL considerably, as the discovery mechanism needs to be implemented in HW, in order to be available before any ethernet software is uploaded and started.
Additional context Ideally, the implementation will allow for a zero-configuration connection to the mega on the command-line (with maximum latency being the beacon interval, probably ~1 sec). M65Connect can monitor the beacon on the network and automatically use the IPv6 link local address when the connection is started, which will then have no delay.
In any case, it seems sensible to add IPv6 support to ETHLOAD.M65 and mega65_ftp, which would be desirable anyway.