I have been able to set up a wireless mesh network using batman-adv running on a few Raspberry Pis. The Pis are able to detect each other on the mesh, communicate between each other, and share an internet connection if any Pi on the network is acting as a gateway.
The problem I am facing is that if multiple gateways exist on the network, the clients (devices which are receiving the internet connection by the gateway) will never switch to getting their internet connection from any other gateway than the one they initially obtained it from, even if the routing algorithm detects that they have a better connection to another gateway.
Each gateway is running a DHCP server to assign IP addresses to the clients accessing the internet through them. The DHCP server I am using is dnsmasq.
The expected behaviour is either:
Neither of these scenarios are happening. If for whatever reason the gateway providing the internet to a client drops, the client will not attempt to create a new connection until the DHCP lease times out. However this is contradictory to what is claimed on the wiki for this package: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
Please advise on how to configure this mesh network so that either one of the expected behaviours will happen.
This is exactly the expected behavior at the IP layer.
If a DHCP server provides a default gateway, that gateway remains in place for the life of the lease. The DHCP client, by design, cannot definitively determine if the default gateway is down.
DHCP is a poll-based protocol; a DHCP server cannot proactively change the parameters of a lease until the DHCP client requests an update. The instructions in the link of your question indicates that (emphasis added):
To inform clients possessing a valid DHCP lease about a gateway change (the link quality to the gateway could have dropped or the client is roaming around) batman-adv will also inspect incoming DHCP renewal packets. If their destination is not the currently selected gateway and below a certain TQ threshold (currently defaulting to a TQ of 50), the DHCP renewal packet is not forwarded, thereby forcing the client to request a new DHCP lease from a better-connected gateway.
Note that the change happens by inspecting incoming renewal packets. Due to the nature of DHCP, you are stuck waiting for a lease renewal request to update the gateway.
You can set low lease times to increase the polling rate, but if you need real-time reaction to failed gateways, you will need to employ an actual routing protocol.