Udhcpc Modified: Added 'leasefail' case

Hardware and Linux
1

I am doing some weird things and I need someone to tell me if what I am doing is wrong:

I am developing portable desktop scale systems around a CC100. Network port X2 (br1) is always attached to a WAGO WAP 758-919 in AccessPoint mode providing DHCP. Port X1 (br0) is usually attached to a router and talks to the internet, but in some cases I need to connect two of these (CC100) devices together directly via X1 and create an ad-hoc network to exchange UDP broadcast messages between them with Node-Red.

I can send messages between devices IF I manually set their IP address. To automate this I modified the /etc/udhcpc.script adding this case to the end of “case “$1” in”:

        leasefail)
        # DHCP failed to get a lease - no router/DHCP server available.
        # Assign a deterministic link-local IP (169.254.x.x) based on the
        # interface's MAC address so devices can still reach each other
        # directly without a router (e.g. in portable/field deployments).
        # The last 2 hex digits of the MAC are used as the final octet,
        # making the address unique per device (up to 256 devices conflict-free).
        logger -t "udhcpc-script" "DHCP failed on $interface, assigning link-local..."
        MAC=$(cat /sys/class/net/$interface/address | tr -d ':')
        LAST=${MAC#??????????}
        DEC=$((0x$LAST))
        ip addr flush dev "$interface"
        ip addr add 169.254.1.$DEC/16 dev "$interface"
        ;;

This does what I want it to do but I am worried I have unknowingly broken something else. Have I gone off the rails?

2

When does the DHCP fail ?
After the first request or after x requests ?

I ask because how quickly the gateway and DHCP server will bootup after a power loss ?

3

I realized my original question / code-snippet was incomplete. I have edited that.

We currently trigger the link-local fallback from the udhcpc “leasefail” case. We understand the concern regarding delayed DHCP server startup after a power loss.
In practice, the router we are using boots up very quickly (<10 seconds) with the CC100 taking about +30 seconds. Also this system is designed to stop operating / fault-state if there is a power loss event during operation, so an operator is required to reset the system anyways.

We are still investigating where the udhcpc retry timing is configured within the WAGO networking stack. Our intent is for DHCP to remain preferred when available, while still allowing deterministic link-local fallback for direct-controller deployments without infrastructure.

4

I’ve spent a lot more time stress testing this setup. It seems like the udhcpc.script runs any time a change is made at an ethernet port. I can hot-swap between the router (DHCP) and the direct device connection (169.254.1.xxx), it behaves as desired. I am also able to power-cycle the router with the CC100 constantly on.

I am very happy with the way this works, I think I am afraid it is too good to be true.
I will report back if I observe any suspicious behavior.

5

Nice to hear, I think the too good to be true is the maintenance needed in case of FW update.
Since it’s a FW modification, you will need to make sure it work for each update from now on.