Hi Alan, See my response inline.
> I haven't changed the baud rate (so it's 115200), and my pings are > certainly not 400ms, so I'm not seeing that issue (whatever it > is/was). I'm not too certain that the baudrate gave a 20 times performance increase. However, I believe that a 115200 bps baudrate to transfer data to and from a 250kbps radio can be a bottleneck (and I clearly see it when my capturing device is set to only 115200 bps). > Another quick question... When you do a wireshark of something with > 6lowpan fragmentation, are you getting malformed packet errors for > the > first packet? I'm trying to decide whether this is something that > could > hold me up, or whether it's a wireshark issue with 6lowpan. I > uploaded a > capture file[1] from my embedded board. :1 is the PC with econotag > and > :2 is the embedded board with mrf24j40. As you can see, not all the > packets are making it through. I'll do some testing with the rftest > tools. The current 6lowpan code for the first fragment is wrong (i.e. it should be more that 25 bytes or so). When I dug in the source code, I found out that the first fragment is always empty (i.e. no payload). I fixed that, but I haven't found the time to release a patch yet. I'm sorry about that. However, in my initial test, without the fix, I could still manage to log into SSH (sporadically, due to a failing serial driver). > This example capture [2] shows an HC1 header (for example, packet 4) > that we don't have, but my quick look at the 6lowpan RFC hasn't been > able to convince me that it's required in any way. Like I said, it > could > be a Wireshark issue. HC1 header is required in order to "compress" the IPv6 header (from 40 bytes to something like 20 bytes in your case). It saves bandwidth and prevent the need for fragmentation. This is not required so to speak, but your packet go through the 6lowpan module, they will have the HC1 compression applied to them. While I'm at it, you might find this kind of issues as you play with the linux net-next kernel: - crash due to memory allocation in 6lowpan: on "my" kernel, I changed the kzalloc() call from GFP_KERNEL to GFP_ATOMIC. The backtrace was not always useful as it would point to random network code. - the serial driver itself has some bugs (in the linux-zigbee tree). Some patches sent to linux-zigbee mailing list were never applied. - during packet burst, packets can be sent in the wrong order: this is due to the way the queue was implemented in the MAC layer (net/mac802154/tx.c): if the device is busy, the packet is rescheduled to be send, but at the end of the queue. - UDP header compression is broken: the header is compressed correctly, however both compressed and uncompressed header are sent on the air. Because the code is broken on the sender and the receiver, it still works. I have a patch for that (saves a few bytes in the packet). You currently don't have L2 acknowledgment with the current Econotag firmware. I need to release my "additions": I enabled auto-ack in my firmware and go it to work between two devices. It requires modification in the 6lowpan and the MAC codes as well (so that the ACK flag can be passed down). I plan on releasing all of that, but I've been pretty busy lately. Besides, some code needs to be cleaned and cannot be released as is (e.g. I implemented a reset mechanism on the serial driver to reset the econotag when it stops responding, this is not needed anymore because the bug has since then been fixed in the firmware). Regards, Tony ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
