On 24/07/14 16:52, Alexander Aring wrote: > On Thu, Jul 24, 2014 at 01:59:21PM +0100, Martin Townsend wrote: >> Looking at contiki code [0], line 1582 onwards it looks to me like they >> process fragmentation headers first and then could potentially process an >> uncompressed IPv6 header. >> >> [0] >> https://github.com/contiki-os/contiki/blob/master/core/net/ipv6/sicslowpan.c >> >> Also I've just read in RFC 6282 on page 5 that >> " >> >> Section 5.3 of [RFC4944] <http://tools.ietf.org/html/rfc4944#section-5.3> >> also defines how to fragment compressed IPv6 >> datagrams that do not fit within a single link frame. Section 5.3 of >> [RFC4944] <http://tools.ietf.org/html/rfc4944#section-5.3> defines the >> fragment header's datagram_size and >> datagram_offset values as the size and offset of the IPv6 datagram >> before compression. As a result, all fragment payload outside the >> first fragment must carry their respective portions of the IPv6 >> datagram before compression. This document does not change that >> requirement. When using the fragmentation mechanism described in >> Section 5.3 of [RFC4944] >> <http://tools.ietf.org/html/rfc4944#section-5.3>, any header that cannot fit >> within the first >> fragment MUST NOT be compressed. >> >> " >> >> my reading of this is that on tx if at the point of compressing the IPv6 >> header it doesn't fit into 127 bytes then we should send the packet as >> uncompressed IPv6 and then on receive we should process uncompressed IPv6 >> packets using 6LoWPAN fragmentation mechanism, or am I wrong in this? >> > mhhh, that's interesting. It seems we should really not send compressed > fragmentation 6lowpan packets. > > This part updates the Section of 5.3 which means we should do what > rfc6282 for section 5.3 of rfc4944 says. > > Now, I wonder myself why my contiki device sends compressed fragmented > packets, but it should not do that. We should not compress the ipv6 header > and set the dispatch value "IPv6" instead IPHC and followed by the ipv6 > packet. Then we should do the fragmentation mechanism. > > But on the receiving side we should evaluate if it's "IPHC" or "IPv6" > after reassembly. Contiki sends me compressed headers while fragmentation, > but it should not do this. Also wireshark does accept and decode the IPHC > format without malformed information. > > > On sending part we need to hope that contiki/tinyos or others 6LoWPAN > stack, can accept uncompressed IPv6 packets. > > On receiving part we should really check if it's a IPHC dispatch value > and add a comment to this for compatibility with others stacks. What do > you think about this? Did you see any stacks that sends uncompressed > 6lowpan packets while fragmentation? > > > Thanks Martin for pointing this out. > > - Alex My understanding is that you can send compressed packets with fragmentation and should always strive to compress the IPv6 header. The only situation that you should send an uncompressed IPv6 header is when all the headers including the compressed IPv6 header do not fit into the first fragment, ie are more than the MTU of the device sending the packet, for us 127 MTU of the 802.15.4 device. ie the sum of all the MAC headers/6 LoWPAN headers and the compressed IPv6 header > 127.
- Martin. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
