Tony - thanks for the confirmation. I'm at IETF 86 this week and booked pretty solid. I expect to get back to my fragmentation code this weekend and will follow up with questions or patches.
- Ralph On Mar 11, 2013, at 2:03 PM 3/11/13, Tony Cheneau <tony.chen...@amnesiak.org> wrote: > Hi, > > Sorry for the delay, I wanted to check the code first. See my answer inline. > > Le 2013-03-05 21:20, Alan Ott a écrit : >> On 03/05/2013 02:38 PM, Ralph Droms (rdroms) wrote: >>> On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner >>> <poett...@ibr.cs.tu-bs.de> wrote: >>> >>>> Hi! >>>> >>>> Am 20.02.2013 um 03:00 schrieb Ralph Droms (rdroms) <rdr...@cisco.com>: >>>> >>>>> What I want to do is update the header compression and fragmentation code >>>>> so it interoperates using header compression. I think I have code for >>>>> header compression and send-side fragmentation. I still need to work on >>>>> the receive-side fragmentation. >>>> Am I right in assuming, that fragmentation between two linux devices is >>>> not supposed to work at the moment? >>> The most recent version of 6lowpan.c that I pulled will interoperate with >>> other instances of that same code, but not with different codebases. >>> >>> 6lowpan.c inserts a fragment offset based on the compressed header, while >>> as I read the relevant RFCs, the offset should be based on the uncompressed >>> header. >> >> Yes, it should be based on the uncompressed header. That's one of the >> things Tony Cheneau fixed. I'm not sure whether that's in his patch set >> that's not upstream yet. > Actually, the patch I have for fragmentation (not integrated in net-next yet) > does not cover this particular issue. The current code leaves the first > fragment empty (i.e. with no payload), this is what it fixed in my patch. > Ralph is right when he says that the datagram_size field (as per RFC 4944 > Section 5.3) is not correctly set (it is currently computed over the > compressed 6LoWPAN header). > > I attached a capture of a fragmentation when using my current patches. > Reported datagram size is 227, while it should be 248 (I believe). > >>> Because both the fragment generation and fragment reassembly code use the >>> offset in the same way, 6lowpan.c will interoperate with itself but not, >>> e.g., Contiki or XINU code. >> >> I'm sure we fixed that (at least in some case). Tony can confirm. > I wonder why it works, but it might be just out of pure luck. > >>> As I wrote, I have a fix for fragment generation that has been tested with >>> Contiki (but has not been committed). I haven't had time to get back to >>> the code to fix the fragment reassembly code. > > Regards, > Tony<6lowpan-wrong-datagram-size.pcap> ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
