On Thu, Sep 11, 2014 at 11:45:58AM +0100, Martin Townsend wrote: > 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. >
Okay, I agree with you with the NALP dispatch. What's about the others. - Alex ------------------------------------------------------------------------------ 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
