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,