Hi Alex, On 11/09/14 11:33, Alexander Aring wrote: > On Thu, Sep 11, 2014 at 11:09:26AM +0100, Martin Townsend wrote: >> Hi Alex, >> >> Reposting to everyone this time :) >> > ok > ... >>>>> I know this issue and we should not do that in this way. >>>>> >>>>> Why? >>>>> >>>>> Because this works only for fragmentation with IPHC, for example if we >>>>> support mesh or Broadcast or HC1 compression. We should call after >>>>> successfully reassembled "means lowpan_frag_rcv returns 1" the lowpan_rcv >>>>> again. >>>>> So this is a recursion and we don't should use recursion to much, but it >>>>> should only be one recursion, so I think that's okay. :-) >>>> The spec says that the headers of the 6LoWPAN frame must fit in the first >>>> fragment. You need to process these headers to get to the fragmentation >>>> header, this is why the code is this way. >>> yes this is for IPHC dispatch values your code works, I don't want to >>> say that it doesn't work. Because fragmentation is something to >>> reconstruct the full payload, we should first evaluate the fragmentation >>> dispatches and then all others. To be sure that we can use fragmentation >>> on any dispatch value which is not the fragmentation dispatch values. >>> :-) >>> >>> Simple move it before nalp check. Maybe somebody fragment something and >>> the dispatch value after fragmentation is nalp. I know it should catch >>> the default branch above, but it's a little bit cleaner. I hope you are >>> in the same opinion. >> I think it should stay where it is. >> From RFC 4944 >> NALP: Specifies that the following bits are not a part of the LoWPAN >> encapsulation, and any LoWPAN node that encounters a dispatch >> value of 00xxxxxx shall discard the packet. Other non-LoWPAN >> protocols that wish to coexist with LoWPAN nodes should include a >> byte matching this pattern immediately following the 802.15.4. >> header. >> >> The last sentence implies that this NALP code is expected as the first byte >> following the MAC Header. If a NALP is encountered after processing the >> 6LoWPAN header stack then it will be treated as an unknown compression type. >> > yes. But the issue is more a reassembled fragmentet 6LoWPAN packet have > a dispatch value. This dispatch value should not NALP, but maybe > somebody did it and then we should make the same code like what we do > for NALP dispatches without fragmentation. A NALP dispatch byte should be the first byte in the MAC payload that allows other protocols to co-exist with 6LoWPAN. I think Jennet use this to insert their own protocol between 802.15.4 and 6LoWPAN. So we have to check for this before we do anything. Having a NALP byte after re-assembly isn't valid and should be treated as an unknown compression type in my opinion.
> The same for all other dispatches. The current code makes this with IPHC > and IPv6 dispatch. And I really don't know is that a MESH or BC0 can > also be fragmented because we have some worst cases in mac header, > etc... sizes. > > - Alex - Martin. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
