Hi Linus,
On 11/07/18 04:23, Linus Lüssing wrote:
On Mon, Jun 25, 2018 at 07:29:19PM +0200, Linus Lüssing wrote:
Currently, we only update the DHT on outgoing (= into the mesh) ARP Replies. I'm worried that an ARP Request would never reach this node (B) during the whole extended timeout, therefore not triggering the necessary ARP Reply, therefore leaving this node unreachable over this whole time frame. Which would probably result in a lot of confusion, I guess.
Another option I was wondering about is whether we could go for the original, simpler idea and add snooping of outgoing hw-src/IP-src pairs from ARP Requests. And whether that could be frequent and reliable enough to avoid confusion for the previously mentioned scenario.
I'm also wondering why we do not snoop outgoing ARP Requests yet, why we only snoop ARP Replies. Currently, in batadv_dat_snoop_outgoing_arp_request() there is only a:
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
to fill the local DAT cache. But something like a "batadv_dat_send_data(bat_priv, skb, ip_src, vid, BATADV_P_DAT_DHT_PUT);" to update the DHT seems absent.
Am I missing something?
We actually snoop ARP requests, but we use the extracted information to update the local cache only. You are right when saying that we don't update the DHT in this case.
We snoop ARP replies because we consider them "authoritative answers" that we can effectively trust.
Unless somebody has any objection, I think we could consider as such also the "source IP/MAC" in an ARP request and apply the same logic.
Cheers,