User login

Weekly Report - 04/07/14

08

Jul

2014

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.