User login

Weekly Report - 08/08/14




I got the WSN integrated with a regular network during this week - which was an easier process than I had imagined. I had been thinking about it in kind of the wrong way, so as soon as I set it up in a configuration that resembled a real network, it started working fine. I now have the 6lbr running in "smart bridge" mode instead of the default router mode, which obtains the IPv6 prefix advertised by the global router and autoconfigures an IP address based on that and the MAC address.

The next issue I was working on getting past was the ability to ping/communicate with the motes from a PC (outside the WSN), which didn't seem to be working. I have been in contact with some very knowledgeable gentlemen through the 6lbr mailing list who have been working through the issue with me. I worked out that the fragmented pings have such a low chance of making it to the mote that it essentially never happens (let alone a fragmented reply be sent back). However, if I shorten the lengths of the pings so that their request packets don't fragment (e.g. ping6 -s10), they occasionally reach the motes (roughly 80% packet loss on average). The sniffer app that I found last week has been invaluable for looking into this. Laurent Deru confirmed via the mailing list that the fragmentation issue has been addressed in the development branch of 6lbr.

So there are a couple of minor issues now. One is that the motes have a tendency to drop off the RPL DODAG from time to time, which isn't ideal, although they recover eventually (this is probably part of the reason it took so long to debug the ping issues, as the first time I tried with non-fragmented packets it looked like it made no difference). Secondly, as Ron Segal also observed, it seems very easy to accidentally cause a denial of service through pinging even at regular intervals.

I've ended up learning a lot about just what kind of throughput I can expect from the motes now though. One interesting thing in particular is that the radios actually see and ACK pretty much everything. In particular, it surprised me that the sniffer was able to see traffic so accurately, and yet the mote had such a hard time just responding to ICMP requests. I'm fairly certain that ACKs must be done in hardware, which would explain why they were designed to be so simple (an ACK consists entirely of a sequence number, no addressing). So the fact that the mote sends an ACK on receiving an ICMP request but often doesn't actually respond to it with an ICMP reply seems to indicate that there is something wrong in terms of passing that packet from the radio to be processed at a higher level.

In any case, now that I know this is actually working (to some extent), I'm just going to get started on a CoAP application, and we'll see how that works out.