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

[Simon Wunderlich <sw@simonwunderlich.de>]

Hi Martin,

I've discussed this with my co-maintainer Sven, but we will most likely not 
adopt this change to batman-adv unless we find a really good use case or reason 
why this change should be made - as I wrote earlier, changing the originator 
timeout is not really required for most use cases, and even your use case can 
be solved differently. We try to keep the knobs in batman-adv/batctl minimal to 
avoid that people shoot themselves in the foot.

Therefore, I would actually recommend to not make this patch, at least not for 
upstream. If you need this for your own setup, then fine, but just hardcoding 
the change in the source code or use the application-level method we discussed 
is probably better.

For contributions we have a page [1] describing what we expect and how patches 
should be made. But again, I would suggest to spend the effort on something 
else. :)

Thank you,
        Simon

[1] https://www.open-mesh.org/projects/open-mesh/wiki/Contribute

On Tuesday, April 21, 2026 10:33:13 AM Central European Summer Time Martin 
wrote:
> Hi Simon,
> 
> I’m considering to add this batctl config. Do you have any tips to get
> started and would this be  something that you are willing to integrate /
> merge, once reviewed& approved?
> 
> Thanks, Martin
> 
> Sent from Proton Mail for iOS.
> 
> -------- Original Message --------
> On Monday, 04/20/26 at 14:06 Simon Wunderlich <sw@simonwunderlich.de> wrote:
> 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 <sw@simonwunderlich.de>
> > 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
> > > 
> > > 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.
> > 
> > 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