[B.A.T.M.A.N.] [RFC PATCH] batman-adv: Increase DHCP snooped DAT entry purge timeout in DHT
a at unstable.cc
Fri Jul 20 06:47:35 CEST 2018
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the B.A.T.M.A.N