br-lan contains both the wired (LAN) ports and a wireless client interface. At layer 3 it's configured as a DHCP client, as are the devices hanging off its wired side. Essentially a wireless bridge for non-WLAN-capable devices (mainly an old but dependable printer).
The DHCP and DNS server (dnsmasq) is on the other side of the wireless link.
Is there a way to connect the wired links' status to that of the wireless side, so that when that other side of the wireless link (WDS or AP or mesh) goes down, then recovers, it forces the wired sides' link to also go down/up?
That way the wired devices should redo DHCP so that they can quickly get DNS-resolvable again.
Is this possible, perhaps something involving hotplug?
You should be able to do so using the hotplug system, but I don't see the need for a DHCP refresh in such a setup: the lease remains active until it times out, the server doesn't care if the wireless link is broken.
Could you explain your refresh problem a bit better, maybe there is a solution that doesn't involve bringing interface down/up?
1 Like
That's correct, but the hostname can no longer be resolved since the dnsmasq upstream has lost its state (e.g. upstream router rebooted).
Edit: Also, and this may be a deficiency of the printer's ancient network stack, its DHCP renewals don't seem to use its hostname. On the upstream router I see that the lease is renewed but the hostname is no longer listed against it, and trying to resolve it from another machine on the network fails.
The only reliable way to make it resolvable again is to pull the plug on the network cable that connects it to the bridge device and then plug it in again.
Ah OK - in this case, you can just add a static lease on the main router for your printer. The host name will then always resolve, no matter if it has an actual lease or not. I do this for all my devices that need to resolve in any case. This should also fix your second problem, since it will always resolve with the host name you add to the static lease.
EDIT: Assuming that your main router is also running OpenWrt, of course.
I'll try that - in fact I think I used to do that years ago. I was trying to be fancy, since that forces me to learn things 
Correct, both the bridge and the "upstream"/"main" one are OpenWrt.
I see some potential problems with the hotplug "solution", depending on your WiFi device:
- If it only has one LAN port, you will completely lose access to the device if the WiFi link goes down
- If it has a switch and the switch is not DSA-based, I think that you cannot bring individual ports up/down. This might be worked-around by using
swconfig, I don't know.
- If it has a switch and the switch is DSA-based, you should be able to bring individual ports up/down.
In any case, a hotplug rule would then involve calling the appropriate command to bring the port up/down. The hotplug documentation is at https://openwrt.org/docs/guide-user/base-system/hotplug.
I would test bringing ports up/down first manually, for example using another wired port or the wireless interface. Once you've found out how this works, you can move on to hotplug.
As for toggling the port, I would try ethtool first, as it doesn't require bringing the complete interface down and it should work on individual ports on DSA-based switches.
NB: I've never done what I just described, this is just to give you some hints.
Unless I misunderstood, the problem you're describing here shouldn't occur.
I've read through the thread, but I don't understand how that matters.
Are you saying that dnsmasq is running on this upstream router?
Is it running OpenWrt?
Is the WiFi device merely a Dumb AP - maybe I missed that in the thread?
From what I got, the upstream router is running OpenWrt and is using dnsmasq. OP is right that, if the upstream router reboots, DHCP leases are lost on the upstream side, so clients can't resolve the names of the devices any longer until the lease is refreshed. A static lease (or a hostname entry) should solve this.
2 Likes
Understood, in a previous device I used in this dumb bridge role I also ran a separate AP interface with its own layer 3 network (and a dnsmasq) but no routing to the internet, just as a management interface. Might do the same here.
@lleachii yes, both devices are OpenWrt. The main router is a R7800 running 22.03.5, and the new bridge (later to replace the router) is a WAX206 running snapshot.
Seems like the summary from this thread is that there's no elegant way to designate a constituent interface in a bridge as a "link state master for other constituents". So I'll probably end up just using a static lease again.
Just to close out this thread: It turns out that the issue is really because of the deficient network stack on the printer. We'll give it a pass, it's from the early oughts, and the printer still works great without any DRM infestation.
Its DHCP client has a limit of attempts it will make to obtain an address (the limit is configurable but seems to be buggy when changed from the default - 
). It also forgets its address any time the link goes down, and starts the DHCP attempts again once the link is up.
If no address is obtained during that window, it proceeds to silently sulk in a corner indefinitely until the link (or the printer) is bouned/power cycled. I guess exponential backoff with a ceiling hadn't been invented yet back then.
I could verify this by e.g. watching ARP traffic over the link after a link bounce while the upstream dnsmasq was stopped, to simulate an outage. ARP requests were being sent to the printer, but it couldn't reply since it had given up its address and was making no more attempts to get one. This continued even after dnsmasq upstream came back.
So it seems the only robust fix here is to configure it with a static address.