Hi,
I had a quick look on short addressing, does anyone know why RFC 6282
specifies one way of deriving IIDs from the short address:
"Short addresses are mapped into the restricted space of IEEE EUI-64 addresses
by
setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short
address, and all other bits to zero. As a result, an IID generated
from a short address has the form:
0000:00ff:fe00:XXXX
"
but RFC 4944 specifies a different way for SAA
"All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
addresses (Section 3 <http://tools.ietf.org/html/rfc4944#section-3> andSection
12 <http://tools.ietf.org/html/rfc4944#section-12>) are also possible. In these
cases, a "pseudo 48-bit address" is formed as follows. First, the
left-most 32 bits are formed by concatenating 16 zero bits to the 16-
bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
used). This produces a 32-bit field as follows:
16_bit_PAN:16_zero_bits
Then, these 32 bits are concatenated with the 16-bit short address.
This produces a 48-bit address as follows:
32_bits_as_specified_previously:16_bit_short_address
The interface identifier is formed from this 48-bit address as per
the "IPv6 over Ethernet" specification [RFC2464
<http://tools.ietf.org/html/rfc2464>]. However, in the
resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
be set to zero in keeping with the fact that this is not a globally
unique value."
Cheers,
Martin.
On 27/01/14 13:48, Alexander Aring wrote:
On Mon, Jan 27, 2014 at 01:39:28PM +0000, Martin Townsend wrote:
Hi Alex,
So the current 802.15.4 implementation will try and send beacon
frames but it doesn't support receiving beacon frames?
I didn't see any type = 2 but that may be down to this problem in
our receiver.
SSH is over Ethernet so no 6LoWPAN fragmentation I'm afraid. I did
ah ok, I thought some 6LoWPAN ssh connection. :D
try ping6 with large packets but due to the problem in our receiver
I was only seeing every other packet of the fragmented PDU. What I
did see looked ok though, both source and destination IP addresses
were compressed. It was using long 802.15.4 source/dest addressing
mode, is this because the IP address are derived from the MAC
addresses? When would it use the short addressing?
This is a little bit more complex. :-)
Currently on receiving side a short address will be correct
uncompressed, see [1].
On sending side only a broadcast short address will be using if
destination address is multicast. You can't use a long address here, see
[3]. That's another problem of the current architecture.
If you have an another stack != linux, then it's better to use long
address only.
The version of Wireshark (1.10.2) I'm using shows the MAC header, it
even decodes the frame control field :)
ah ok, sounds good.
- Alex
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ieee802154/6lowpan.c?id=refs/tags/v3.13#n211
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ieee802154/6lowpan.c?id=refs/tags/v3.13#n674
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
