FYI on esoteric/niche network dhcp issue for the internet bridge

Damion

I run my own dhcp service on my home lan and was using udhcpd this seemed to be working, in that the tado internet bridge picked up an IP (2nd LED went solid) and my /var/log/syslog and tcpdump confirmed the device was picking this up and working. However it then kept asking "who-has" (ARP) for which ever DNS server I configured (e.g. 8.8.8.8) as if it assumed it could only route on the local lan. As a debugging step I disabled that and turned on the (suboptimal) configuration of using the router's own dhcp. This worked! So I set the lease to 200days and swapped back assuming if I left the device powered it should be safe for ages.

I raised a support case assuming their device was doing something simplistic and assuming the responding dhcp server was the gateway rather than accepting what was being sent. I mulled over clever routing tricks, a cheap router doing double nat and its own dhcp behind it. I also decided to bite the bullet and actually look into and install the fully fledged isc-dhcp-server.

That last step worked... so annoyingly it seemed udhcpd doesn't do something right. This device is the first and only device I've ever encountered which didn't work. I'd enabled authoritative mode, and can't see an option in udhcpd to do the same, so this might well be what is different in the packet with which it responds.

I emailed to close the case and I'm leaving this here for an internet search some day for anyone else running a different dhcp server to the one built in to their router.

Damion

I think I've now determined this wasn't authoritative mode, it's the lack of subnet mask being sent. All devices I've ever come across fall back to class based addressing of which rfc1918's 192.168.x.x is a class C or /24 in CIDR parlance. The Tado bridge wasn't doing this so it was arp requesting everything.

Now either of my DHCP daemons can provide the service. This remains a niche issue.