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,
--
Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
