Enable NM 1.52 link-local fallback resolution

[thatcomputerguy0101]

Description

This enables link-local as a fallback to DHCP address resolution, using the new features of NetworkManager 1.52. Debian 13 (Trixie) and Ubuntu 26.04 (Resolute) introduce the required updates to NetworkManager for this to work. Unlike #1550, this continues to timeout and retry DHCP while holding a link-local address, which should avoid breaking compatibility with DHCP servers that don't respond immediately.

Closes #1813, blocked on updating the images to have NM 1.52 or later.

Meta

Merge checklist:

• Pull Request title is short, imperative summary of proposed changes
• The description documents the what and why
• If this PR changes behavior or adds a feature, user documentation is updated
• If this PR touches photon-serde, all messages have been regenerated and hashes have not changed unexpectedly
• If this PR touches configuration, this is backwards compatible with settings back to v2025.3.2
• If this PR touches pipeline settings or anything related to data exchange, the frontend typing is updated
• If this PR addresses a bug, a regression test for it is added

[thatcomputerguy0101]

It would probably be good to mention this in the documentation, but I don't think there is currently a section talking about DHCP.

[mcm001]

Yeah, I don't believe our documentation talks about networking very much at all. It seems like a common enough foot gun. It may be worth mentioning, although most people probably don't need to know very much

[thatcomputerguy0101]

I added some draft documentation, although I'm unsure if I got the level of detail right.

[thatcomputerguy0101]

When do we want to try introducing this? The Raspberry Pi and Arabian Orange Pi images have the necessary NM versions, but the Rubik Pi and Joshua Riek Orange Pi images do not. It shouldn't break with older NM versions, but it won't do anything either.

[thatcomputerguy0101]

All of our images now have at least NM 1.52, so this feature should now be functional.

[crschardt]

I've been reading the NetworkManager issues and I'm not sure that version 1.52 completely solves this problem.

According to open issue 1775, we have to set ipv4.dhcp-timeout=infinity or the link local connection will still drop when the DHCP connection times out and NetworkManager resets the connection.

I'll try to do more testing when I have some time.

[thatcomputerguy0101]

Good catch. I tested this again, and the connection does seem to briefly drop approximately every 50 seconds when connected via the link-local address as it tries to renegotiate the DHCP address.

[thatcomputerguy0101]

I tried combining this with ipv6-method link-local. In that case, the ipv4 link-local address without a DHCP server is stable. It transfers automatically to an ipv4 DHCP address once a server is available the next time it checks for a DHCP server (approx. every 50s). It does not revert back to a link-local address if the server disappears until the physical link is broken and reconnected. (Tested by turning on and off network bridging on the host computer.)

[mcm001]

Can we add some documentation on previous networking issues and the Om5p radio specifically? In general it's worth asking if we want to maintain support for it and its quirks. I remember something about ipv6 issues?

[crschardt]

If we want to avoid IPv6, we can configure the connection like this:

# 1. Keep the standard DHCP configuration active
nmcli connection modify "<con-name>" ipv4.method auto

# 2. Allow link-local (169.254.x.x) only when no DHCP IP is present
nmcli connection modify "<con-name>" ipv4.link-local fallback

# 3. Tell NM that an outstanding DHCP request is allowed to stay unfulfilled
nmcli connection modify "<con-name>" ipv4.may-fail yes

# 4. CRITICAL: Avoid protocol timeout errors that cause interface resets
nmcli connection modify "<con-name>" ipv4.dhcp-timeout infinity

# 5. Completely disable IPv6 to match your requirements
nmcli connection modify "<con-name>" ipv6.method disabled

# 6. Set connection auto-activation retries to infinite loop mode
nmcli connection modify "<con-name>" connection.autoconnect-retries 0

I used Google Gemini to help formulate this and I've been testing it with good results. I can swap between being connected to my router and being connected directly to my computer and the coprocessor remains reachable.

Here's the explanation provided by Gemini:

Using ipv4.dhcp-timeout infinity is the precise trick here: it instructs the internal DHCP client to keep requesting an IP address forever in the background without throwing a fatal protocol error. Because it never explicitly "fails", NetworkManager won't cycle the link or strip your fallback IP address.

I think that the reason enabling IPv6 also works is that it prevents the IPv4 DHCP timeout from triggering the network reset, essentially doing the same thing as setting the timeout to infinity.

[thatcomputerguy0101]

I think a weird thing about FRC networking is that the field DHCP server often isn't accessible when the wired link is established due to the wireless startup time. Most of our networking testing does not cover this frequently encountered scenario.

[thatcomputerguy0101]

Actually, I forgot that a range of addresses is reserved for on-radio DHCP to hand out, but it still doesn't hurt to check that deferred DHCP availably works correctly.

[thatcomputerguy0101]

I can confirm. Using ipv4.dhcp-timeout infinity behanves the same as ipv6.method link-local with respect to the ipv4 behavior. A link local address is obtained after the first DHCP failure and removed once DHCP succeeds.