Dear all, my first bug report (hopefully :-)) for the Kernel ^^ Citing 6lowpan.c:675: /* Universal/local bit set, BT 6lowpan draft ch. 3.2.1 */ If the address is identified as a public address, the original address byte get's a set bit at 2^1. Otherwise, it will be deleted. so far, so good. That works well, BUT: the current RFC7668 does NOT state anything like that. Neither in ch. 3.2.1 or any other chapters I looked through. Please tell me, am I wrong or is this a non-conform implementation? Anyway, thank you very much for this rock-stable piece of software :-) Best wishes, Benjamin
It is already fixed in bluetooth-next: commit d74a94fd915d8d0f87836d281fcb1c081af495f8 Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Date: Sun Mar 12 10:19:38 2017 +0200 6lowpan: Fix IID format for Bluetooth According to RFC 7668 U/L bit shall not be used: https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: In the figure, letter 'b' represents a bit from the Bluetooth device address, copied as is without any changes on any bit. This means that no bit in the IID indicates whether the underlying Bluetooth device address is public or random. |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| +----------------+----------------+----------------+----------------+ Because of this the code cannot figure out the address type from the IP address anymore thus it makes no sense to use peer_lookup_ba as it needs the peer address type. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com> Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Ok, thank you very much. Sry for that mistake. -> Resolved