I'm experimenting with a mesh network in the house. It has 4 nodes running batman_adv (BATMAN_IV) on stock OpenWrt 19.07.3 (i.e batman-adv-2019.2) on TP-Link WR902AC devices. The nodes mesh on 'mesh point' links on 2.4GHz and one node connects to the home wired network.

In the scenario, I have a laptop connected to the AP on one of the mesh nodes (not the gateway). I make a ssh connection from this to a host on the wired network. There is a consistent delay of about 8 seconds before the 'password' prompt comes back from the remote host.

I rebuilt OpenWrt 19.07.3 for that device, and ticked all the debug options for batman-adv. Running tcpdump on both soft and hard interfaces, and trace-cmd to capture the debug info, I find the following:

The DNS request and response for the remote host name, and the consequent ARP request and response go through within milliseconds. However the TCP SYN is received by the bat0 interface but is not forwarded on the mesh0 interface. SYN re-sends after 1 sec, then 2 sec are not forwarded either. Only the 3rd re-send (after another 4 sec) gets forwarded and then the ssh session proceeds normally.

Looking at the code, and after adding extra batadv_dbg() calls, I discover that the 'orig_node' returned by 'batadv_transtable_search()' on the dest address is NULL so the SYN gets thrown away by 'batadv_send_skb_unicast()'.

It is only after receiving an OGM message with a TT update for the remote host MAC from the gateway node that the local translation table gets populated with the remote host's MAC. I should say that I've set the 'orig_interval' to 3000 to reduce batman traffic, so that probably has an effect on the delay.

I do wonder why the ARP response is not used to populate the translation table immediately, as an ARP response is always going to be followed immediately by returning IP packets. The ARPs are snooped for the distributed ARP table anyway so why not use that information for the translation table too?

regards,

John Sager