Hi,
On 28/11/2019 11:01, Sven Eckelmann wrote:
Hi,
I just saw following in batadv_hash_dat():
key = (const unsigned char *)&dat->vid; for (i = 0; i < sizeof(dat->vid); i++) { hash += key[i]; hash += (hash << 10); hash ^= (hash >> 6); }
But the vid is in host order - not big endian like the IP part. So the batadv_dat_select_candidates will select different candidates depending on whether it is a little or big endian system, right?
That sounds like a correct statement.
We access the VID byte by byte, therefore different endianness will lead to different hash values (and thus different candidate selection).
I imagine I haven't observed this issue so far because I always worked with networks made up by very similar hardware.
If this is a correct assumption, then we would have this problem since 3e26722bc9f2 ("batman-adv: make the Distributed ARP Table vlan aware")
That's it. Very nice catch!
Will you send a patch? I guess converting the VID into network order before accessing it should be enough, no?
Thanks!
Regards,