Gateway shut down detection takes too time from other nodes

Gateway shut down detection takes too time from other nodes

[mbiglari4]

Dear readers,

I have implemented a Mesh network with Wifi nodes on 802.11s and BATMAN adv. My mobile nodes are mesh nodes, and I am using 802.11s to create a mesh network. Within this network, some nodes act as servers and others as clients. Suppose one of the nodes is selected as a gateway by the clients. The problem is that when this gateway node powers off, the other nodes do not immediately detect this change, and it takes a long time for them to recognize and switch to a new server as the gateway.

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

[Simon Wunderlich]

Hi,

can you describe your setup a bit more? Are your "gateways" connected with 
each other over Ethernet? Do you have multiple DHCP servers on your gateways 
respectively, or is there a DHCP server in your LAN interconnecting gateways? 
Are you using bridge loop avoidance? Perhaps an illustration would help.

There are different scenarios how to set up this network kind of network, and 
failover time  may differ from a couple of seconds to a couple of minutes 
depending on the setup.

Thank you,
        Simon

On Monday, October 13, 2025 11:37:32 PM Central European Summer Time 
mbiglari4@gmail.com wrote:
> Dear readers,
> 
> I have implemented a Mesh network with Wifi nodes on 802.11s and BATMAN adv.
> My mobile nodes are mesh nodes, and I am using 802.11s to create a mesh
> network. Within this network, some nodes act as servers and others as
> clients. Suppose one of the nodes is selected as a gateway by the clients.
> The problem is that when this gateway node powers off, the other nodes do
> not immediately detect this change, and it takes a long time for them to
> recognize and switch to a new server as the gateway.

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

[mbiglari4]

Dear Simon,

I have a mesh network with three nodes that use 802.11s for the PHY and MAC layers, and BATMAN-adv on top to provide routing and mobility. Two of the nodes act as gateways, and the other functions as a client. The client selects the best gateway based on throughput.

Currently, I don’t have a DHCP server in this network — each node has a static IP address. The issue I’m encountering is that when the selected gateway node turns off, the client takes too long to switch to a new gateway. All nodes are using the BATMAN V routing protocol.

I believe this delay could be reduced by factoring the last connection time into the throughput calculation. For example, if you’re using an EWMA filter, you could treat a node that has been disconnected for more than 10 seconds as having a throughput of zero. This would cause the EWMA value to drop quickly, allowing the client to select a new gateway sooner.

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

[Simon Wunderlich]

On Thursday, October 23, 2025 2:28:10 PM Central European Summer Time 
mbiglari4@gmail.com wrote:
> Dear Simon,
> 
> I have a mesh network with three nodes that use 802.11s for the PHY and MAC
> layers, and BATMAN-adv on top to provide routing and mobility. Two of the
> nodes act as gateways, and the other functions as a client. The client
> selects the best gateway based on throughput.
> 
> Currently, I don’t have a DHCP server in this network — each node has a
> static IP address. The issue I’m encountering is that when the selected
> gateway node turns off, the client takes too long to switch to a new
> gateway. All nodes are using the BATMAN V routing protocol.

The setup is still not really clear to me. If you are not using DHCP but use 
static IP addresses, how do you do the selection of the best gateway? Is this 
a functionality of batman-adv, or a script?

batman-adv has the gateway feature [1] which optimizes the gateway based on 
throughput, but this is useful only with DHCP enabled - because it redirects 
your DHCP requests, nothing more, nothing less. This mechanism is rather slow, 
and changes will only happen when the IP address renewal is due.

You may also have interconnect your gateways with Ethernet, use a bridge, and 
enable BLA (bridge loop avoidance) in batman-adv. But it's not clear whether 
you do that.

Please explain your network setup in more detail, then we may be able to help.

[1] https://www.open-mesh.org/projects/batman-adv/wiki/Gateways

> 
> I believe this delay could be reduced by factoring the last connection time
> into the throughput calculation. For example, if you’re using an EWMA
> filter, you could treat a node that has been disconnected for more than 10
> seconds as having a throughput of zero. This would cause the EWMA value to
> drop quickly, allowing the client to select a new gateway sooner.

I can't really comment here unless I know which component in batman-adv would 
interact with, as explained above.

However, if you have an idea, you can also go ahead and implement those things 
yourself in batman-adv and try it out. Please note that BATMAN V is still 
considered experimental, and most networks I work with are running BATMAN IV.

Cheers,
      Simon

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

[martinvdberg]

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

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

[Simon Wunderlich]

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

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

[Simon Wunderlich]

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

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

[Martin]

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?

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

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?


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

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 5355 bytes --]

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Simon Wunderlich]

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