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