I have a 6 node mesh using GL.iNet 750s routers using 802.11s and batman-adv.
Everything works great. I can stream video from a camera to a laptop connected to the mesh.
I have two microcontrollers connected to the mesh. One continuously sends UDP packets (transmitter) to the other one (reciever) . However, after a number of seconds (60??), they stop going through the mesh.
The node that the receiver is connected to can ping the receiver, but other nodes can't. After a little while, the remote pings start working, and the UDP stream goes through again.
Any ideas on WHY the mesh looses the receiver that is connected to one node???
I know it's because it's silent, and not sending any packets. But why would that cause it to get lost by the rest of the mesh? The node that it is connected to can still ping it.
I'm also experimenting with a mesh of atheros devices, and was seeing behavior similar to your symptoms.
I lowered the mtu, until the problem went away. Unfortunately, that MTU is 1500, and thus, i have a lot of fragementation, thus low speed, but stable(ish).
What is your current MTU and fragmentation setting?
btw.: Nice graphics. How did you make that? Manually/graphviz, or something built-in to batman?
If it’s not part of the mesh, if it’s not sending traffic, the presence and route is not known to batman-adv. It seems as though it’s taking a long time to establish a route, or does it fail completely?
I haven’t looked into tuning, but perhaps looking into the claim table and the algorithms used to manage it might help.
Thanks Jeff. Yes, it not part of the mesh, and it's not sending traffic.
I know it's a bad design to have a node that receives and never transmits, and the workaround is to have it send a packet once a second or so, to keep it from getting dropped by the mesh.
Again, it's odd that the local node can still ping the receiver, but the other nodes can't (after it get's dropped/lost). It's also odd that it takes so long for the pings to start working again (and immediately the UDP packets start flowing again).
I'll start looking into some batman-adv internals and try to figure it out. Also the claim table.
If it sends an ACK of any sort, that should be enough to keep ARP tables and the like populated.
I wish I had more insight. The “stalls” for connectivity bother me on a smaller mesh, but haven’t been able to track them down yet. The MTU problem with ath10k drivers is higher in my list. I’m hoping that increasing MTU resolves the stalling issues.
