Enable link-local in parallel with DHCP

[crschardt]

This update to the DHCP connection settings allows IPv4 link local connection when waiting for a DHCP response. Once it get the DHCP response the IP settings will be set by the DHCP server. The benefit of enabling link-local is that it will allow people to test and configure their coprocessor without needing a network switch or robot radio.

I've tested this using a direct Ethernet connection between my Win11 laptop and the coprocessor. I've tested with an OrangePi5 and a RaspberryPi4.

I'd appreciate others giving this a try and letting me know if it works or causes problems.

[stephenjust]

Are there additional base-image changes required for this?

Starting from the 2025.0.0-beta2 image on Orange Pi 5 Plus, I'm seeing the new connection being created, but it's not being used:

pi@photonvision:~$ nmcli c
NAME                UUID                                  TYPE      DEVICE
netplan-zz-all-en   3fc91611-2585-3063-ac16-0d3e7c50d8c3  ethernet  enP4p65s0
lo                  7b4b82f5-6045-4b31-bf2e-13c0f2415fb7  loopback  lo
dhcp-enP4p65s0      ce684213-a719-4ff7-88bd-924aae6248a3  ethernet  --
netplan-zz-all-eth  361ae2b8-a95b-3e8e-bb96-107d56c02d9b  ethernet  --

pi@photonvision:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enP3p49s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether c0:74:2b:fe:c5:f5 brd ff:ff:ff:ff:ff:ff
3: enP4p65s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c0:74:2b:fe:c5:f4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c274:2bff:fefe:c5f4/64 scope link
       valid_lft forever preferred_lft forever

The behavior is that I can connect over ipv6 link local until the connection is eventually killed due to dhcp timeout (but it doesn't cut over to the new dhcp connection?) My guess is the default connections in cloud-init need to be removed.

[crschardt]

The behavior is that I can connect over ipv6 link local until the connection is eventually killed due to dhcp timeout (but it doesn't cut over to the new dhcp connection?) My guess is the default connections in cloud-init need to be removed.

Thank you for testing. Would you please post the logs?

[stephenjust]

The behavior is that I can connect over ipv6 link local until the connection is eventually killed due to dhcp timeout (but it doesn't cut over to the new dhcp connection?) My guess is the default connections in cloud-init need to be removed.

Thank you for testing. Would you please post the logs?

After some further examination, it was my bad. The version upgrade didn't stick. Once I got the correct code running, this worked fine (~~but I did uncover some issues with the OPi base image that need to be fixed, I'll prepare those today~~ edit: base-image is fine, turns out you need the netplan connections for PhotonVision to try to create its own dhcp connection, if you remove them, it won't even try to create the new dhcp-x connections)

[mcm001]

Would be very cool, but I know that on old radios, link local caused problems with our Pi image. Not sure how to approach testing best

[Gold856]

I vote to ship and hope we can get sufficient testing on the radio. If we ship it now, there's a high likelihood of getting enough testing on FMS.

[mcm001]

There are still a lot of old radios being used on test chassis I bet...