Re: Gateway shut down detection takes too time from other nodes

[Simon Wunderlich <sw@simonwunderlich.de>]

Hi Martin,

On Tuesday, April 7, 2026 3:46:59 PM Central European Summer Time 
martinvdberg@gmail.com wrote:
> I think I have a similar use-case as the original poster and ran into the
> same problem.
> 
> Let me try to explain:
> 
> - Given a mesh network where each node is assigned a *static IP*.
> - In the mesh network there are some nodes acting as a Gateway.
> - The other nodes in the mesh are clients.
> - Using BATMAN-V
> 
> Each client node has a script running, when it detects "batctl gwl" to elect
> another gateway, the script will set the gateway's IP-address as default
> route: "ip route replace default via $gateway_ip dev bat0".
> 
> Now whenever a mesh-gateway is turned off, it will take 200 seconds before
> it is removed from the originators and only then "batctl gwl" will elect
> another gateway. This results in some client nodes have no internet for 200
> seconds.
> 
> So far, I haven't been able to get batman-adv (using batctl) to switch to
> another gateway sooner, e.g. after 10 or 20 seconds.
> 
> 
> Using DHCP is not an option in my use-case.
> 
> Is there somehow a way to reduce the 200 seconds? Possibly by switching to
> BATMAN-IV?
> 
> Regards, Martin

that's an interesting use case, although I would like to make clear that the 
gateway feature was designed for DHCP in mind, yet you use it with static IPs. 
The main purpose was to re-route DHCP packets to the selected gateway. 
Nethertheless, you could still use this mechanism for "signaling".

The gateway selection can be based on TQ or on bandwidth parameters, but there 
is no option to speed up the "dead marking" from the 200s of the originator 
timeout. you can decrease that number in the source code, but I would actually 
advise to use a completely different method independent of batman-adv - for 
example by using a layer 3 routing daemon, or another application which 
regularly signals their availability as a gateway. For DHCP (which it was 
originally designed for), lease times are typically 5 minutes minmum, so the 
200s timeout are not really a problem there ... but I acknowledge that it's 
not really useful for "fast" switching.

Cheers,
       Simon