On Thu, Sep 11, 2014 at 11:09:50AM +0200, Alexander Aring wrote: > Hi Martin, > > On Thu, Sep 11, 2014 at 10:53:53AM +0200, Alexander Aring wrote: > ... > > > > 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. :-) > > > > I reconsider about that, this is not okay. A attacker can send data to > occur this stack overflow... > > We need another solution for this. Maybe your current one, but handling > fragmentation at the beginning and then evaulate dispatch values. >
I look more in RFC 4944, it seems that mesh and BC0 and MESH always fits into a single fragmentation... but they don't say anything about max value and if we have encryption on... I am not sure now if there is a case where this can happen or not. Simple -> check fragmentation if fragmentation then goahead until it's reassembled. After reassembled check for all other dispatch values. This should be sure that we handle all packets if fragmented or not. - 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
