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

Simon Wunderlich <[email protected]> Mon, 20 Apr 2026 14:06:09 +0200
Newsgroups	org.open-mesh.lists.batman
Message-ID	<7831023.jRhZ6ZUK3Y@prime>
Hi Martin,

I'm answering without PGP - your previous mail was encrypted so I guess others 
can't read it. I hope you don't mind. Please see inline:

On Friday, April 17, 2026 9:49:13 AM Central European Summer Time Martin 
wrote:
> Hi Simon,
> 
> Thank you for your reply.
> 
> I’ve considered your suggestion, and it sounds feasible. The only issue I
> can think of is how to select the best possible gateway at the application
> level in this scenario. Wouldn’t this result in duplication of logic?

You are right, you may end up having some similar logic compared to what 
batman-adv does internally. I don't think this is much of a problem, since you 
would be re-using the same data but have a (slightly) different interpretation 
of it. The original batman-adv code doesn't (directly) care about the last 
seen time after all.

> 
> For the time being, I’ve patched the batman code to reduce the timeout from
> 200s to 20s. This works fine.

Glad to hear! If you don't mind that the originators time out quicker, then 
this could just be sufficient as well. Some other users may have even stricter 
timing requirements (e.g. less than 5s or even 1s) which may not work with 
this approach, though.

> 
> It would be great to have this timeout configurable via batctl. Is there any
> chance that such a feature could be implemented in the near future?

Personally I don't have plans to do so. This is quite a corner case, and we 
generally prefer to expose only few defines/variables to keep things simple. In 
a typical community network (Freifunk etc), 20s OGM timeout might be less than 
the TQ window size (5 entries * 5s originator interval), and create other 
problems. I don't see a general case where we want to change it, and I guess 
you have two options now (change the one line in the source or indirectly use 
the gateway list), so that's satisified too. :)

If there is more general interest to this, you can also write a patch if you 
like.

Cheers,
       Simon

> 
> 
> Regards, Martin
> 
> Sent from Proton Mail for iOS.
> 
> -------- Original Message --------
> On Thursday, 04/16/26 at 07:47 Simon Wunderlich <[email protected]>
> wrote: On Wednesday, April 15, 2026 5:10:23 PM Central European Summer Time
> Simon
> Wunderlich wrote:
> > Hi Martin,
> > 
> > On Tuesday, April 7, 2026 3:46:59 PM Central European Summer Time
> > 
> > [email protected] 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.
> 
> Perhaps one more practical idea: You could parse the gateway list and the
> originator list yourself (batctl has json output options). Then, you could
> get the "last seen" value from the originator list, and combine it with
> your gatewaylist. In that way, you could easily filter the "best gateway
> which was last seen <20 s" in a script. This doesn't help with batmans
> internal DHCP forwarding, but since you use static IPs anyway and probably
> already use a script to get the current gateway to look up the IP, this may
> be an easy fix ...
> 
> Cheers,
>        Simon
signature.asc (application/pgp-signature, 833 B)