* Host endianness dependent DHT lookup
@ 2019-11-28 10:01 Sven Eckelmann
2019-11-28 10:13 ` Antonio Quartulli
0 siblings, 1 reply; 3+ messages in thread
From: Sven Eckelmann @ 2019-11-28 10:01 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: a
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
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?
If this is a correct assumption, then we would have this problem since
3e26722bc9f2 ("batman-adv: make the Distributed ARP Table vlan aware")
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Host endianness dependent DHT lookup
2019-11-28 10:01 Host endianness dependent DHT lookup Sven Eckelmann
@ 2019-11-28 10:13 ` Antonio Quartulli
2019-11-28 10:15 ` Sven Eckelmann
0 siblings, 1 reply; 3+ messages in thread
From: Antonio Quartulli @ 2019-11-28 10:13 UTC (permalink / raw)
To: Sven Eckelmann, b.a.t.m.a.n
[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Host endianness dependent DHT lookup
2019-11-28 10:13 ` Antonio Quartulli
@ 2019-11-28 10:15 ` Sven Eckelmann
0 siblings, 0 replies; 3+ messages in thread
From: Sven Eckelmann @ 2019-11-28 10:15 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: b.a.t.m.a.n
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
On Thursday, 28 November 2019 11:13:21 CET Antonio Quartulli wrote:
[...]
> Will you send a patch?
> I guess converting the VID into network order before accessing it should
> be enough, no?
Yes, I will prepare a patch. Just want to finish debugging another problem
before doing this.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-28 10:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-28 10:01 Host endianness dependent DHT lookup Sven Eckelmann
2019-11-28 10:13 ` Antonio Quartulli
2019-11-28 10:15 ` Sven Eckelmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).