Hi Alex, I have tried out your new branch and I am seeing the same problem. It was happy for about an hour and then the pings became sporadic, after trying each device separately I can see that one of the devices is having trouble with pings. I have a wireshark trace from this device which is quite interesting which I can send you. It shows that when a ping request does eventually get a reply when there is a bunch of Neighbor Solicitations from the other node.
I can send you the trace if you want. If I stop the large pings and use the default ping which doesn't fragment everything is fine so I know packets can get through. BTW is the err: label right in lowpan_frag_rcv, any errors mean that the skb isn't freed. I looked at the invocation from lowpan_rcv and can't see how the cloned local_skb is freed. Cheers, Martin. 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 > > 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. > > >> 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. > > - 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
