| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
lab10 [2016/01/12 14:11]
dan.tudose [Nodes Beyond the Border] |
lab10 [2018/01/25 19:03] (current)
narcisa_ana.vasile [Building] |
| SLIP is the "mostly obsolete" wikipedia:Serial Line Internet Protocol. "On personal computers, SLIP has been largely replaced by the Point-to-Point Protocol (PPP), which is better engineered, has more features and does not require its IP address configuration to be set before it is established. On microcontrollers, however, SLIP is still the preferred way of encapsulating IP packets due to its very small overhead." | SLIP is the "mostly obsolete" wikipedia:Serial Line Internet Protocol. "On personal computers, SLIP has been largely replaced by the Point-to-Point Protocol (PPP), which is better engineered, has more features and does not require its IP address configuration to be set before it is established. On microcontrollers, however, SLIP is still the preferred way of encapsulating IP packets due to its very small overhead." |
| |
| Contiki uses SLIP to bridge the wireless IPv6 network onto a PC via a USB connection. So with your Zigduino plugged into your PC, and the right software running on each, traffic from the wireless IP network can reach your site-wide Ethernet network and potentially beyond. | Contiki uses SLIP to bridge the wireless IPv6 network onto a PC via a USB connection. So with your Sparrow plugged into your PC, and the right software running on each, traffic from the wireless IP network can reach your site-wide Ethernet network and potentially beyond. |
| |
| On Zigduino, there is only one UART exposed. This means we have to choose between reading debug messages and connecting to our PC via SLIP. This change is exposed by adding "WITH_SLIP=1" to the makefile or command line for any particular project. Projects made "WITH_SLIP" will expect to talk to a slip tunnel on the PC side. | On Sparrow, there is only one UART exposed. This means we have to choose between reading debug messages and connecting to our PC via SLIP. This change is exposed by adding "WITH_SLIP=1" to the makefile or command line for any particular project. Projects made "WITH_SLIP" will expect to talk to a slip tunnel on the PC side. |
| |
| Speaking of the PC side... In order for SLIP to work, something on the host PC has to be listening. Using Instant Contiki, the 'tunslip6' will do this. Running it in Linux creates a 'tun0' interface which gives the connected Zigduino an address of aaaa::1 on your local network. | Speaking of the PC side... In order for SLIP to work, something on the host PC has to be listening. Using Instant Contiki, the 'tunslip6' will do this. Running it in Linux creates a 'tun0' interface which gives the connected Sparrow an address of aaaa::1 on your local network. |
| |
| ===== Building ===== | ===== Building ===== |
| <code> | <code> |
| $ cd examples/ipv6/rpl-border-router | $ cd examples/ipv6/rpl-border-router |
| $ make TARGET=avr-zigduino savetarget | $ make TARGET=sparrow savetarget |
| $ make WITH_SLIP=1 WITH_WEBSERVER=0 -j10 | $ make WITH_SLIP=1 WITH_WEBSERVER=0 -j10 |
| $ make upload AVRDUDE_PORT=/dev/ttyUSB0 </code> | $ make upload AVRDUDE_PORT=/dev/ttyUSB0 </code> |
| fdfd::3 fe80::11:22ff:fe33:4403 </code> | fdfd::3 fe80::11:22ff:fe33:4403 </code> |
| |
| It's helpful that tunslip6 is putting through the debug messages from the Zigduino. So we can see the boot-up process complete successfully. | It's helpful that tunslip6 is putting through the debug messages from the Sparrow. So we can see the boot-up process complete successfully. |
| |
| ===== Ping ===== | ===== Ping ===== |
| |
| <code>$ cd examples/ipv6/rpl-collect | <code>$ cd examples/ipv6/rpl-collect |
| $ make TARGET=avr-zigduino savetarget | $ make TARGET=sparrow savetarget |
| $ make udp-sender.avr-zigduino.u AVRDUDE_PORT=/dev/ttyUSB1 -j10 </code> | $ make udp-sender.sparrow.u AVRDUDE_PORT=/dev/ttyUSB1 -j10 </code> |
| |
| Now see that we can ping it ok: | Now see that we can ping it ok: |
| |
| <code>$ cd examples/ipv6/rpl-border-router | <code>$ cd examples/ipv6/rpl-border-router |
| $ make TARGET=avr-zigduino savetarget | $ make TARGET=sparrow savetarget |
| $ make upload WITH_WEBSERVER=0 WITH_SLIP=1 AVRDUDE_PORT=/dev/ttyUSB0 -j10 | $ make upload WITH_WEBSERVER=0 WITH_SLIP=1 AVRDUDE_PORT=/dev/ttyUSB0 -j10 |
| $ cd examples/webserver-ipv6 | $ cd examples/webserver-ipv6 |
| $ make TARGET=avr-zigduino savetarget | $ make TARGET=sparrow savetarget |
| $ make WITH_WEBSERVER=webserver-nano -j10 | $ make WITH_WEBSERVER=webserver-nano -j10 |
| $ make upload login WITH_WEBSERVER=webserver-nano AVRDUDE_PORT=/dev/ttyUSB1 </code> | $ make upload login WITH_WEBSERVER=webserver-nano AVRDUDE_PORT=/dev/ttyUSB1 </code> |
| | |
| | ===== Running ===== |
| | |
| | This has to be done in another window, because "make login" above took over that window. Here we will bring up the tunnel, and try everything out, one thing at a time. Ping the router, ping the webserver, do the 'get'. |
| | |
| | <code>$ sudo ../../../tools/tunslip6 aaaa::1/64 -s /dev/ttyUSB0 -B 38400 -v6 |
| | $ sudo route -A inet6 add fdfd::/64 dev tun0 |
| | $ ping6 fdfd::3 $ ping6 fdfd::1 |
| | $ curl -g "http://[aaaa::11:22ff:fe33:4401]/" </code> |
| | |
| | Here's what success looks like! |
| | |
| | <code>$ curl -g "http://[aaaa::11:22ff:fe33:4401]/" <html> <head> <title>Contiki-nano</title> </head> <body> <pre> <a href="/">Front page</a>| <a href="status.shtml">Status</a>| <a href="tcp.shtml">Network connections</a>| <a href="processes.shtml">System processes</a>| <a href="files.shtml">File statistics</a>| <a href="/ttt/ttt.shtml">TicTacToe</a> </pre> Welcome to the <a href="http://www.sics.se/contiki/">Contiki</a> nano web server!<p align="right"> <br><br> <i>This page has been sent 2 times</i> </body> </html> </code> |
| | |
| | Plus here's the Wireshark summary of this conversation: |
| | <code> |
| | No. Time Source Destination Protocol Info |
| | 1 0.000000 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [SYN] Seq=0 Win=5760 Len=0 MSS=1440 TSV=87387016 TSER=0 WS=5 |
| | 2 0.242296 aaaa::11:22ff:fe33:4401 aaaa::1 TCP http > 36067 [SYN, ACK] Seq=0 Ack=1 Win=1220 Len=0 MSS=1220 |
| | 3 0.242351 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=1 Ack=1 Win=5760 Len=0 |
| | 4 0.242589 aaaa::1 aaaa::11:22ff:fe33:4401 HTTP GET / HTTP/1.1 |
| | 5 0.630341 aaaa::11:22ff:fe33:4401 aaaa::1 TCP [TCP segment of a reassembled PDU] |
| | 6 0.630388 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=165 Ack=86 Win=5760 Len=0 |
| | 7 0.898326 aaaa::11:22ff:fe33:4401 aaaa::1 TCP [TCP segment of a reassembled PDU] |
| | 8 0.898360 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=165 Ack=113 Win=5760 Len=0 |
| | 9 1.258323 aaaa::11:22ff:fe33:4401 aaaa::1 TCP [TCP segment of a reassembled PDU] |
| | 10 1.258369 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=165 Ack=408 Win=6432 Len=0 |
| | 11 1.550390 aaaa::11:22ff:fe33:4401 aaaa::1 TCP [TCP segment of a reassembled PDU] |
| | 12 1.550426 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=165 Ack=490 Win=6432 Len=0 |
| | 13 1.842334 aaaa::11:22ff:fe33:4401 aaaa::1 TCP [TCP segment of a reassembled PDU] |
| | 14 1.842364 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [ACK] Seq=165 Ack=567 Win=6432 Len=0 |
| | 15 2.098333 aaaa::11:22ff:fe33:4401 aaaa::1 TCP http > 36067 [FIN, ACK] Seq=567 Ack=165 Win=1220 Len=0 |
| | 16 2.098508 aaaa::1 aaaa::11:22ff:fe33:4401 TCP 36067 > http [FIN, ACK] Seq=165 Ack=568 Win=6432 Len=0 |
| | 17 2.334295 aaaa::11:22ff:fe33:4401 aaaa::1 TCP http > 36067 [ACK] Seq=568 Ack=166 Win=1220 Len=0 </code> |
