Re: [B.A.T.M.A.N.] [PATCHv2 2/2] batman-adv: Snoop DHCPACKs for DAT

Linus Lüssing
2016-07-07T10:14:42Z

Hi Antonio,

> have you tried applying this patch on one of your servers and measure the local
> effect? (i.e. if the number of BRD ARP req is reduced or not?)

I had queried Martin Weinelt just yesterday, they will test it on
a 500 nodes compat-v15 setup soon :).

>
> I think that a DHCP ACK packet should already refresh the local ARP cache (or
> not?), thus the need for an ARP request should not be triggered by the newly
> joined client. (I might be wrong, but that's why I ask measuring the effect)

Hm, I don't think that the operating system will snoop DHCPACKs
itself to fill its ARP cache. I didn't see that in the VMs either.

But now that you are asking, re-read my thoughts regarding ARP+DAT
on the Gluon issue tracker. Which made me wonder again, why
the issue occures in the first place (e.g. client issues an ARP
Request first - why does that one not fill the DAT appropriately,
why does it need to fallback from the unicast DAT query to an ARP
Request flood?).

Looking at the code again now, I have a hunch. Question: Why
does batadv_dat_snoop_outgoing_arp_request() add the MAC/IP source
pair of the client to the local DAT cache only, why isn't it
propagated to the DHT?

Regards, Linus