PhotonVision
Link-local IPV4LL support
Is your feature request related to a problem? Please describe. Link-local IP assignment may be useful for the initial setup of the camera by directly connecting it to a host computer. Without link-local resolution, the camera does not establish an IP address on interfaces without a DHCP server, preventing communication over that interface.
Describe the solution you'd like
Include avahi-autoipd in the PhotonVision image. avahi-autoipd acts as a fallback service for link-local address assignment whenever a DHCP or static address is not available. avahi-autoipd does not require the interface configuration to be edited from the current values to work.
Describe alternatives you've considered Network Manager also includes link-local address assignment, but may have weird interactions with DHCP and static address assignment due to the need for an indefinite timeout.
Additional context
Since avahi-autoipd doesn't require configuration changes, it may be dynamically editing the configuration at runtime. This needs to be evaluated to ensure it does not interfere with DHCP or static address assignment.
I installed avahi-autoipd on my own camera and have been successful in directly connecting to it over the link-local address. I will soon be testing to see if it also interacts correctly with the robot network.
I believe avahi-autoipd may have only been working on the unmanaged interfaces. However, RaspiOS Trixie (13) brings NetworkManager 1.52, which adds a fallback option for ipv4.link-local. Ubuntu doesn't update to NM 1.52 until Plucky (25.04), so that won't see an LTS release before next season.
With the new fallback option applied (in a somewhat hacky fashion to get PV installed on Trixie), it took 29 seconds to resolve the final DHCP address from an OM5P-AC radio on the active POE port and 15 seconds on the passive POE port. It temporarily held a link-local address, which was dropped once DHCP completed. It took 4 seconds to establish a link-local address when directly connected to a 10/100/1000 adapter to my laptop. With ipv4.link-local set to default, I timed 34 seconds and 16 seconds for the two OM5P-AC ports, which is likely just run variation. I don't have a VH-109 to test with at the moment, but can try that out later in the week.
I ran some light testing with the VH-109 radio, and got 14 seconds to resolve an IP address for both ipv4.link-local set to default and fallback.
Hm. I'd personally like to see this because I think connecting to a coproc with Ethernet directly is pretty nice for configuration, but I think we're still scared of hurting our default config. Two things I'd like to see: behavior over an FMS-like network (which, I know, is not exactly easy to obtain, but the VH-113 existing makes that a little easier) and what happens if you set a static IP. People will probably end up wanting to set a static IP, and we should make sure they can't accidentally make their coprocs inaccessible via network if they set a static IP and also have link local set up.
I'm also curious what happens if you have two coprocessors both end up on link local fallback. This should never happen on a robot, right? If DHCP, they'll each get a DHCP lease when the radio boots, and if static, it'll never end up as link local right?
If set to DHCP, both coprocessors may briefly have a link-local address if the radio is being slow to handle DHCP. However, the link-local protocol starts with a randomized address and includes steps to resolve address conflicts. A link-local address will never conflict with a DHCP address due to being in different address ranges. With the fallback configuration I am testing, the link-local address is removed once DHCP resolves, and DHCP is allowed to timeout and retry as normal.
If the coprocessor is configured with a static IP, that will be set immediately and link-local will not be attempted.
With the fallback configuration I am testing, the link-local address is removed once DHCP resolves, and DHCP is allowed to timeout and retry as normal.
This is where I ran into trouble in my earlier attempts to get link-local working. When DHCP retried after a timeout it would interrupt the link-local connection. The only way I got it working was to set the DHCP timeout to infinity so that it never re-tried. It sounds like the fallback option in 1.5.2 may finally take care of this.
