User login

Patrick Snelgar's blog




Writing up Network Schema report, running into problems with knowledge gaps in regards to RA's.

Californium coap server is working but resources are added prior to the server execution. Handling of requests is done within the resource so adding new resources to the server is problematic.

Could look into getting a CoAP protocol library and manually writing server application.




Defining the schema for network layer
- using RA with DNS backup instead of DHCP (stateless is easier to implement and less resource heavy)
- write up with a given setup what should happen when a new node connects to the gateway.

Moving onto application layer
- californium is a java CoAP API (more familiar with java)
- investigate what is possible with the API
- potentially look into dummy client / server setup on test machine (not the RPi's)




Set up clean install DNS server using 'bind9' (sudo apt-get install bind9)
Configured the local configuration (named.conf.local) to include the zone ""
copied the db.127 file to and edited to have the relevant information (zone, address of device and address of coap server as IPv6)
configured /etc/resolv.conf to include the NS address and zone.
restarted bind9 with "sudo /etc/init.d/bind9 restart"
dig returns address "" - correct
dig returns no results - correct is beef::1
however it's looking for an ipv4 address (...IN A... in the query)
specifying dig AAAA returns address "beef::1" - correct
DNS server is now configured, not set up for chaching results and haven't tested for outside name resolution.

Re-installing radvd broke address configuration to node RPi.
restarting radvd on the gateway assigns an address to the node.
- they can both ping each other after this.
- need to setup dns address advert section.

Setting the dns on the node to point at the IPv6 address of the gateway and using dig fails, but using the ipv4 address (assigned by the attached router) works for finding the address of the coap server via dig. Need to work on getting the ipv6 name server address working.

Gateway RPi is still losing its static IP on boot (have to take the interface down with ifdown and up with ifup before the address takes) could be to do with boot order..




Manged to set up static IP for the gateway device:
required a clean install of the OS and radvd (had multiple version of radvd installed leading to unusual behavior).
Adding static config the /etc/network/interfaces file, then required an ifdown/ifup to refresh the configurations of the interface. Needed to add the interface the ifstate file in order for if* to work (/run/network/ifstate added: lowpan0=lowpan0) however this file is not persistent so changes may need to be replicated each boot.
Upon reboot the static config was missing - still looking into the source of the problem (address is assigned after a ifdown/ifup on the lowpan0 interface.)

Installed bind9 as the dns services, configured local zone and have working ipv4 local name resolution, still checks outside if local cannot resolve name (kept it this way in case the gateway needs to be connected to the internet), however it does not have working ipv6 name resolution yet.




Tried multiple setups of CoAP servers:

libcoap has been most successful so far, the example provided functional server with time functionality and worked nicely with Copper (Cu) a Firefox extension for CoAP servers.
Can configure the address (-A) to start up with - one thing that wasn't included was the necessity to add '&' to the end in order for the command to execute (possibly something within the code)
Tested with a LAN machine (/w Firefox + Copper) and the IPv4 address of the RPi on LAN
Initial Copper screenFirst view of the CoAP server from inside Copper

Selecting 'time' and clicking 'observe' produces the following result
ObservingObserving the time feature of the CoAP Server (PUSH notifications)

Running the client example program with settings "echo 1000 | sudo ./coap-client -m put -T cafe coap:// -f -"
gave the output: v:1 t:0 tkl:4 c:3 id:18275
which is just the header of the CoAP message (no payload was defined)
Also trying to 'put' into the core or async (instead of time) gives a response of "Method Not Allowed" same as trying the operations in Copper.

Having a running example is useful and next steps will be to configure the example, or write a separate script based on the example with the functionality that is required for the projects server.

ccoap is a C based implementation of a CoAP server with examples, however running anything other than the examples (there are command line versions) fails to work (no response from the server. Also required editing of /etc/services and installing cmake to compile the code.

WebIOPi is an interesting setup, has functionality for both CoAP and HTTP servers which could come in handy later on in the project. The main feature of the project is to have a web interface for viewing the GPIO ports on the board. it also is implemented as a daemon service, which is part of what is wanted for the project server.




The current state of 802.15.4 in the linux kernel has support for basic functionality only, send / receive (no scan or associate) and only SoftMAC drivers are available at this stage.
Moving away from low level implementation (drivers) and more toward the higher level interaction (but not quite application layer).
Will be setting up the IPv6 gateway using Radvd for addressing clients (assuming the nodes / gateway are already setup on the same channel / pan id as association is not functional yet).
Another possible solution for automatic addressing would be to use DHCPv6 (IPv6 version of DHCP) but this would require a dhcp server on the gateway and knowledge of address blocks / range.




Successfully set up 2 Raspberry Pis in a lowpan network and exchanging packets.
Used the Texas Instruments CC2531 USB dongle in conjunction with the smartRF software to perform packet sniffing of the 802.15.4 network.

Captured packets are in .psd format which cannot be opened natively in Wireshark.
There have been a few home built converters (.psd to .pcap) however so far they have mostly created malformed packets so are untrustworthy.




Rebuilt the bluetooth-next kernel with clean install of raspbian, still has input lag problems and breaks static IP setup (could be the keyboard).

Found another branch working with 802.15.4 implementation (linux-wpan-next) but negligible difference to the bluetooth-next branch, swapping to linux-wpan-next for kernel building as the openlabs blog quotes it as the one to use.

Source code has SoftMAC implemented with only sending a receiving implemented (basic functionality).
Nothing of HardMAC is implemented yet and no drivers present.

Working on setting up 2 rpi with same pan_id and channel then trying to exchange packets manually.




Still fighting with cross compiling a workable linux kernel for RaspberryPi
Through different tutorials for compiling and running custom kernels and configuring u-boot managed to get a very unstable (laggy) system up n running.




Started work on the RPi adaption of base station:
Working on getting the required tools and libraries in the latest version of Raspbian in order to use the 802.15.4 interface. So far I have installed the libnl library and iwpan tools form source, yet to test if they are working with the interface.

The RPi board needs to be set up for ease of access so I don't have to continuously switch peripherals from PC to RPi, needs static IP (working for the moment but breaks when a network connection is shared to the board) and vncserver on boot. This is setup using tightvnc for the moment with a viewer on a win7 laptop.

Next is to setup a sniffing program (with usb dongle) and attempt to use the add-on board to transmit packages to test if the add-on is accessible.