User login

Brad Christensen's blog




I used an interview in Sydney to procrastinate for most of this week...

Spent some time looking into HTTP/CoAP proxies. The Java-based Californium project seems the most well-established (although there seems to be little to compare it to). I got it up and running and it works nicely as a proxy, but it isn't completely seamless (i.e. resources are accessed on remote CoAP servers via addresses such as http://proxy_host/[coap_host]/resource, as opposed to http://[coap_host]/resource). I would have liked to have more time to investigate setting up a transparent proxy, but then again, I don't think direct HTTP/CoAP proxies are an intended use case for the Internet of Things - rather, an indirect proxy featuring caching (load balancing for the embedded network) and returning "prettier" data to the client would be more useful. At least with this experience I'll have something to discuss in my report.

A disadvantage of the Java proxy is that it runs separately to Contiki/6LBR, which has full control over the network interfaces. This means the CoAP proxy must be run on separate hardware to the 6LBR. In an ideal system this proxy would run as a Contiki process.




Successful week this week:

I recompiled everything from 6lbr's development branch (i.e. native 6lbr, mbxxx slip-radio and mbxxx 6lbr-demo), explicitly setting PAN IDs to 0xabcd for the mbxxx builds (for consistency with other platforms). I also made sure to reset the MAC and RDC layers of each build to use the "null" drivers, which ensure that packets should be transmitted/received as quickly as the hardware allows (with no regard for power usage). This resulted in excellent quality packet transmission, with the possibility of 0% packet loss over several minutes of pinging the devices, even for fragmented packets. The RTT is a quite respectable 60-70ms for pings split into two fragments.

Using the development branch for the mbxxx platform meant that the memory footprint increased again, which was a big problem for the 6lbr-demo app. To offset this, I completely disabled TCP (since it isn't needed by CoAP), and halved most of the buffers used by RPL. Thanks to gcc's magical -fpack-struct=1 there is now a working CoAP server on the device that can return its uptime in seconds!




Had my two practice presentations this week, which each went well, and received some good feedback from the WAND group. I've been busy with some assignments and job interviews this week so haven't made any further progress.




I've just finished up and run through my presentation this past week, ready to give (twice) on Wednesday. Wrote myself a script which I will need to stick to relatively closely in order to keep within 15 minutes. Should be good fun.

I started looking into running a CoAP application and found (as I had suspected earlier) that the CoAP example included with the 6lbr-demo application won't compile out of the box for my platform - it overflows the RAM by about 500 bytes, which is rather annoying.

I was hoping to find that I had just overlooked something related to compiling for low-resource devices, such as the Zolertia Z1, which also has only 8KB of RAM and is supported (there is a testbed subroutine in the Makefile which compiles the CoAP server for the Z1, although I haven't tested this due to not having the compiler installed for that platform). I did discover that the Z1 only has a 16-bit MCU while the STM32W is 32-bit, and I wondered whether that would have made any difference, but I talked that over with Richard S and we came to the conclusion that it probably couldn't have made as much difference as we were seeing.

Richard suggested trying some compiler flags and we found one of them which managed to reduce the overflow to only ~240 bytes. Contiki is already fairly heavily optimised however, so the other flags we tried weren't any use. It's possible that from here I could make some adjustments to buffer lengths etc, which might be an acceptable compromise at least to get things working.




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.




I haven't made much progress this week. I remembered that before I could get going with writing a CoAP application, I have to actually get the LoWPAN integrated with a proper network (rather than just a PTP link between the 6lbr and some computer), which I had tried earlier and I was confused at the time as to why it didn't just work. I've been trying to figure it out but to no avail.

Since I've just been piggybacking on the redcables network thus far, I think my next step will probably be to take the equipment back home where I have root access to the router and more control over the network configuration.

In happier although not entirely useful news, I did find a nice 802.15.4 packet sniffer implementation for Contiki which specifically works with the stm32w radio (which might have been really helpful a couple of weeks ago). It outputs 802.15.4 frames in pcap format, which can be piped into Wireshark to view a live capture.




I fixed the issue I'd been stuck with and got my motes communicating this week!

I received a response from Mátyás Kiss re stm32w support in 6lbr, but this unfortunately wasn't very helpful. I was certain that I had already set my PAN IDs to be identical between my slip-radio (tunnel mote) and client mote. He mentioned the need for a "driver modification" but I am still not sure what he was referring to by this as he never got back to me again after I asked.

I had assumed that the issue was with the slip-radio application, because I could see using Wireshark that DIOs were being received from the remote mote on the tunnel interface of the raspberry pi, but there was no outbound traffic from the router. I figured the problem had to be to do with the stm32w chip somehow, since the router is already known to work on the pi!

While testing several different configurations with the 6lbr router set to debug verbosely, I noticed the slip-radio would drop packets at regular intervals. I had previously read that packet drop logs were normal to see because of corruption over the wireless medium and they could essentially be ignored, but I hadn't noticed at the time that drops were occurring every 60 seconds, likely due to testing many different configurations and not leaving them each running for long enough to obviously identify a pattern. I realised that the frequency lined up with when DIOs are sent out by the remote mote, but this left me confused for days as to how/why they were being dropped at the slip-radio because the devices' PAN IDs matched.

However I eventually realised that it was neither of the motes that were the issue - there is also a PAN ID hardcoded into the router itself; it turned out that was set in a different place and for some reason inconsistent. I had assumed the slip-radio handled everything to do with the LoWPAN, but the router must formulate the packets to begin with and pass them off to be sent.

Time to do some CoAP!




I put 6lbr on the Raspberry Pi this week, following their fairly simple hello world guide, which involves connecting the Pi with a remote host directly via Ethernet. I can access the web server exposed on the 6lbr host, but 6lbr still seems unable to find or communicate with other nearby motes. I have been following the guides as closely as possible to try and eliminate extra variables - interestingly to start with, I tried on a regular network (redcables) which didn't work, so will come back to that at some point later.

The slip-radio application used by the tunnel mote compiles fine out of the box, although I needed to hardcode in its RF channel (supposedly it can be changed from within the web app, but that seems to have no effect as evidenced in the logs). The 6lbr-demo application required a slight modification so that it wouldn't overflow the RAM on the device: essentially it needs to be added to a list of known low-resource devices, but for now I've hardcoded in the low-resource values.

After more research manually looking through mailing list messages I found that one other person has tried using the stm32w chip with 6lbr and ran into similar problems. It is suggested that a platform-dependent command handler method needs to be written but ultimately no further progress is documented. From what I could tell, the command handler is only used to change the RF channel and PAN ID at runtime, and these should already be set to the correct values anyway. Implementing the command handler looked reasonably trivial so to confirm that not having the handler wasn't causing my problem, I implemented it myself. It looks like it is working, and indeed hasn't changed anything.

I've sent an email to the 6lbr mailing list to check what stage support for stm32w is at and to see whether it's an issue. Soliciting help seems like the best way forward right now!




I finished my last assignment for the semester this week (hooray) but after a few more days without any real success I sat down with Richard Sanger for several hours and we worked through the issue I'd been having communicating with my motes on their globally routable IP addresses. The mote would not respond to neighbour discovery solicitations so we first manually added an entry into the IPv6 neighbours table on the host PC to direct traffic to the mote, and then traced through the UDP server's code to see how it was assigning IP addresses internally. The conclusion we came to was that adding the address using the ADDR_TENTATIVE type rather than ADDR_AUTOCONF allowed the server to receive packets bound for its global address (we saw that the link-local IP was assigned as tentative), but the response sent by the server was not able to reach the host PC. The response packet appears to be dropped before it is even sent out of the server because the server has no route to the host PC.

I'm still baffled by the fact that this seems to work for pretty much everyone else straight out of the box, but having had Richard look at it with me now I'm at least confident that I'm not just overlooking something completely obvious. In our trawl through the code we were specifically looking for cases where its platform implementation might have differed from others (such as the Sky mote used as an example in the exercise I originally followed) but we found nothing to be suspicious of.

I also tested using netcat that I could communicate with the UDP server beyond just pinging (working with the link-local address again).

In any case, I'm now satisfied that I have looked at this in sufficient depth and can continue on to implementing my RPL border router. I suspect (and very much hope) that enabling RPL will just make this a non-issue anyway.

Over the weekend I set myself up in the lab and brought in the new motes that I hadn't touched before, but I realised I was unable to flash them because their firmware was too old. This wasn't something I'd come up against with my original motes because I had been playing around with them for a while and in the process some software had upgraded them automatically. The stm32w_flasher utility is supposed to do it, but the Linux version fails, so I had to do it from my Windows machine. At least it was worth figuring this out to be able to note later.

I'll be away next week (7-14 July) spending some time in various parts of the north island with family.




I haven't progressed significantly further than last week. Still stuck at the moment with connecting to motes from the host PC, but after looking at the link with Wireshark (which I should have thought to do much earlier) I realised that I was receiving RPL DODAG Information Solicitations from the link-local IP of the mote, so I worked out that I can connect to the mote on its link-local address if I direct it through the tunnel interface. However, I still can't connect to the mote on its globally routable IP.

This is really frustrating since everything I've read has indicated that it should just work - except for this one mailing list thread authored by someone who appears to have an identical problem. Instead of solving the problem, the author found a working bridge in an application called uDPWS, which runs on top of Contiki. I might start by looking into this next week to see what the differences between the bridges are.