Hi Alex,
On 06/02/14 11:45, Alexander Aring wrote: > Hi Martin, > > On Thu, Feb 06, 2014 at 11:08:35AM +0000, Martin Townsend wrote: >> Hi Alex, >> >> No problems testing your new branch, just send me the URL, branch name and >> can you also send me the commit hash as open embedded uses this. >> > What do you mean with commit hash? > My current commit id is 6f744c3d72355f556d884583f4fc8b4e0f9723b1 That's the one, I think it's a SHA1 hash but don't quote me on that :) > > I create a new branch [1] with a date and I should not do a git push -f > anymore, that's a bad command. :-) > > I updated many things now... remove some unnecessary things in > reassembly.c file. > > But important is you should have a: > > /proc/sys/net/ieee802154/6lowpan/ > > directory. I added the runtime options for the garbage collector there > and a 6lowpanfrag_max_datagram_size file. So you can set there a > maximum datagram_size (bytes) for packets you will receive, otherwise > the fragmentation api will drop it. Default is the full 2^16 payload > length of ipv6. > >> One thing I've noticed with this problem I'm seeing is that I can make it >> happen a lot quicker by making a SSH connection to one of the boards over >> the ethernet port. Which is weird as this connection is IPv4, so there must >> be some sort of interaction going on between ethernet/6lowpan or IPv4/IPv6. >> > there is no ethernet/6lowpan, 6lowpan can have currently only ieee802154 or > btle > as mac layer. Or I just don't understand the point. > Sorry my fault, I shouldn't have used '/', I meant between ethernet and 6lowpan not ethernet over 6lowpan, ie. there may be some lockup occuring when data is being sent/received via interface eth0 as well as wpan0. I haven't had time to look through the network stack so I don't know if they are completely separate code paths and data structures. As a test I will connect to the boards via a serial cable and disable eth0 on both boards and just have traffic over wpan0 as see if it still gets into this situation. >> Anyway I'll do some more testing when the new branch is ready. >> > yea, I mean... new branch when it's ready... there are several things > why I don't like the current state of the branch, but it's still better > than the current implementation. Maybe I should bring the patches > mainline and then see for other solution for these things which I hate. > > Things which I hate are: > > - The size lookup function for 6lowpan header. I mean we don't need it > and can decompress 6lowpan on the fly and we know the size. But I need > to make some other things to provide that. See [1]. > > - The memory management.... we have lot of skb_clone there and I don't > know who delete a skb and so on. It's a little bit crazy. See [2]. > > But these all issues which I can solve later. Good point is to be RFC > complaint and remove the race conditions. Sounds good to me :) > - Alex > > [1] > https://github.com/linux-wpan/linux-net-next/tree/6lowpan_fragmentation_02062014 > [2] > https://github.com/linux-wpan/linux-net-next/blob/6f744c3d72355f556d884583f4fc8b4e0f9723b1/net/ieee802154/6lowpan.h#L359 > [3] > https://github.com/linux-wpan/linux-net-next/blob/6f744c3d72355f556d884583f4fc8b4e0f9723b1/net/ieee802154/6lowpan_rtln.c#L468 ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
