Hi Martin, On Thu, Sep 11, 2014 at 12:55:05PM +0200, Alexander Aring wrote: > 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. > ok. This is out of interest because we don't support all others than IPV6 and IPHC. The important thing is, if we don't know the dispatch after fragmentation -> drop it.
We will think about that issue, if somebody implements that. - 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
