b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed
* 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).