Re: [B.A.T.M.A.N.] Local Clients Expiring from Translation Table

[Simon Wunderlich <sw@simonwunderlich.de>]

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

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

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