On 07/02/15 08:27, Sven Eckelmann wrote:
On Friday 06 February 2015 14:20:28 Antonio Quartulli wrote:
To me this looks like the caching effect of DAT: bat0 is likely to change MAC address everytime you recreate the interface (unless you statically assign the MAC) therefore I presume that the other node (the one which did not reboot) was still caching the old bat0 MAC address (each entry requires some minutes before being invalidated/refreshed).
Thanks for the explanation.
So you are basically saying that DAT cannot detect when some nodes found a conflict in their ARP table (when receiving IP packets with a different MAC for an IP or similar things)?
Right. Well, the scenario "incoming packets altering the local ARP table and generating a conflict" was never really considered.
And there is also the problem when no local information is stored and only a conflict with some data data on another unrelated node is happened.
I haven't really understood this issue.
The first conflict (the conflict in the local ARP table) is not detected because David wanted that batman-adv isn't accessing the ARP table?
Even without reading the the ARP table we could "detect the conflict" by checking incoming packets and by matching their IP/MAC couple with what we have in DAT...At the moment we only assume that the IP/MAC couple is stable enough and that in the worst case the user will wait for the cache to get invalidated.
Still, I think this is an optimization that we may want to implement, but not a real issue that pushes us to disable DAT by default.
This means that any communication willing to contact the rebooted node was targetting the old address and therefore the two were not be able talk until the cache was refreshed.
Can this be the case?
Yes, unfortunately I hadn't the time to analyze it further and have no logs of any similar problem. Thats why I cannot check if this is contradicted by anything I've done (or not done). So it is a very plausible scenario which you've described.
No problem, I just wanted to get your feeling/feedback about that :)
Thanks a lot.