On Tuesday 21 October 2014 09:55:23 Jon Fink wrote:

I'm experiencing some issues where clients connected to a batman node (through a wired interface) are expiring from the local translation table after a period of inactivity. I'm guessing this is an intentional feature to support roaming but I'm wondering if there is a way to stop this behavior for certain MAC addresses. Some more detail of my setup:

• I have multiple mesh nodes named pico9, pico17, pico24, pico41, etc...
• Each node is running BATMAN 2014.2.0 attached to a wireless device.
• Each node is also bridging the batman device with its local ethernet

device. * A subset of the nodes are then connected to the same wired backbone, lets say pico9/17/24 are all on this backbone.

• I have my laptop also connected to the backbone and I am able to

successfully connect to any of the BATMAN nodes (over the wired backbone or to other nodes via the wireless mesh).

pico41 (not on the backbone) has a wired client connected to it, lets call it clientA

I can initially connect to clientA from my laptop and it shows up correctly in pico41's local translation table. However if I do not continually send data (ping, ssh, etc) between my laptop and clientA, I see the "last seen" column of pico41's local translation table entry increase. Eventually, clientA is removed from the table and I am not able to connect to it (ping or ssh) until I "do something" to trigger some traffic from clientA onto the mesh network. This is problematic because it requires either physically accessing clientA (not practical in our application) or manually ssh'ing into the node running batman and then connecting to clientA (makes for a challenging use-case)

Is this expiration from the local translation expected?

I've thought of a few hacks (make certain entries in the local translation table permanent, have a script on clientA which continually generates traffic) but I'm hoping someone else has thought about this same problem.

Thanks!

Hey Jon,

this behaviour is intentional - the idea is to keep the translation table clean with the timeout. Also other Layer 2 switches do that.

When using IP, what usually happens after not connecting to a certain host is that the source host tries to request the IP again via a broadcast ARP packet - and as soon as the destination replies, the local translation table gets updated. The ARP timeout should be considerably smaller than the 10 minutes used for local translation table timeouts, and as far as I know there should be a similar mechanism in IPv6.

That said, you should (in theory) always be able to SSH into your machine since the ARP entry was timed out before anyway and needs to be refreshed. Or do you use some kind of static ARP entries, or other means which we did not consider?

Thanks, Simon