Building Contiki’s tunslip6

 

Difficulty: Easy

Duration: 2 minutes

Description: This document shows how to build Contiki’s tunslip6 utility. Tunslip is a tool used to bridge IP traffic between a host and another network element, typically a border router, over a serial line. Tunslip creates a virtual network interface (tun) on the host side and uses SLIP (serial line internet protocol) to encapsulate and pass IP traffic to and from the other side of the serial line. The network element sitting on the other side of the line does a similar job with it’s network interface. The tun interface can be used like any real network interface: routing, traffic forwarding, Wireshark analysis, etc.

Prerequisite: C compiler installed on PC.

 

Building tunslip from source

Get the source and compile it.

$ git clone https://github.com/iot-lab/contiki.git
$ cd contiki/tools
$ make tunslip6
$ ./tunslip6 
tunslip6: usage: ./tunslip6 [-B baudrate] [-H] [-L] [-s siodev] [-t tundev] [-T] [-v verbosity] [-d delay] [-a serveraddress] [-p serverport] ipaddress: Success

 

Checking it works (1 minute)

To check that your freshly built tunslip actually works for use with IoT-LAB, you need sudo priviledge on the host, and a working ssh-fronted access. Proceed with the following 3-steps:

1. proxyfy any device’s serial port onto the host using ssh -L (any non-reserved device will do, we use m3-4 on grenoble.iot-lab.info)

   $ ssh <login>@grenoble.iot-lab.info -N -L 2000:m3-4:20000 &

2. start tunslip6 on the host using sudo (creating the tun interface requires priviledge)

   $ sudo ./tunslip6 -v 2 -t tun0 -a localhost -p 2000 fd00::1/64

3. after tunslip exits, kill the ssh proxyfication process (just cleaning up)

   $ kill %%

This procedure ends in an (expected) error, but actually validates that tunslip works as it should. Since the device is not running, the serial line is not functional, and tunslip eventually exits in error. However, the whole tunslip process is executed and validated, as far as host networking is concerned: tun interface creation (and deletion), access to ssh-proxyfied serial port via localhost.

Below is a full trace of the process, including ssh cleanup. The error shown by tunslip is expected (and detailed in the note).

$ ssh grenoble.iot-lab.info -N -L 2000:m3-4:20000 &
[1] 14207
$ 
$ sudo ./tunslip6 -v2 -t tun0 -a localhost -p 2000 fd00::1/64
slip connected to ``127.0.0.1:2000''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add fd00::1
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.1.1  P-t-P:127.0.1.1  Mask:255.255.255.255
          inet6 addr: fe80::1/64 Scope:Link
          inet6 addr: fd00::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

channel 2: open failed: connect failed: Connection refused
tunslip6: serial_to_tun: read: Interrupted system call
ifconfig tun0 down
netstat -nr | awk '{ if ($2 == "tun0") print "route delete -net "$1; }' | sh

$ kill %%
$ 
[1]+  Done                    ssh grenoble.iot-lab.info -N -L 2000:m3-4:20000

Note: the first error trace “channel 2: open failed: connect failed: Connection refused” is generated by ssh, when tunslip first accesses the remote serial line via localhost:2000. This first access causes sshd on grenoble.iot-lab.info to lazily open a connection to the non-existing remote serial line server on m3-4:20000, which fails, and in turn causes tunslip to fail with the second error trace “tunslip6: serial_to_tun: read: Interrupted system call“. All fails well, and network job cleanup is performed.