> > > >When using the fragmentation mechanism described in > >Section 5.3 of [RFC4944], any header that cannot fit within the first > >fragment MUST NOT be compressed. > > > > > >Any header == sum of headers. > Maybe they mean to cover further application headers that can be compressed. > Look at the draft GHC spec for instance.
But we don't support these right now and on the receiving side it should be okay to check if a fragmented 6LoWPAN header is compressed or not. It's simple to check on IPHC or IPv6 dispatch value after fragmentation. > > > >>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. > >Okay, I agree. That makes more sense, but when could happen this? > Not sure, what about ipv6 options?? again maybe they are future proofing > for future compression algorithms like GHC. I think they mean all header MAC + 6LoWPAN and NHC (next header compression). The only one NHC which we support is UDP at the moment. > > > >Worst case in our supported: > > > > 802.15.4 MAC dataframe: 39 (fc + seq + address + sec + fcs) > > 6LoWPAN Header : 43 (IPv6(40) + NHC(1) + IPHC(2)) > > UDP Header : 8 (like normal udp) > > > > Total : 90 > > > >So in worst case we have 90 bytes at the moment. But we should handle > >the receiving part correctly, if we receive some kind of this packets. > > > >If you look at [0] we always assume that a fragmented packet is > >compressed and run process_data function (ugly name for this). and we > >doesn't evaluate the DISPATCH value after fragmentation, which we should > >do because a non compressed fragmented header has a dispatch value of > >LOWPAN_DISPATCH_IPV6 which means it's not a compressed packet. > > > > > > > > > > > >I hacked a solution for this but need more error handling etc... it's > >only a draw for a possible solution: > > > >We simple run lowpan_rcv if the packet is reassembled. This function > >evaluate the dispatch value then. > I have a patch already which refactors lowpan_rcv to be more rfc compliant > (and renames process_data :) ) but it relies on an earlier patch which > hasn't been accepted yet. I'm away until Monday now so I'll send it then if > everyone is ok that this is the way to go. ok. - Alex ------------------------------------------------------------------------------ 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
