Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Use safer default config for optional features

[Antonio Quartulli <antonio@meshcoding.com>]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]



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.

Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]