deac/osd-contiki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Doc for uIPv6

Browse source
This commit is contained in:
julienabeille 2008-10-14 09:50:32 +00:00
parent 632a3585f5
commit e7b38010a2
25 changed files with 2035 additions and 227 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

251
doc/Doxyfile
View file

@ -3,7 +3,7 @@
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# Project related configuration options # Project related configuration options
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
PROJECT_NAME = "Contiki 2.2.1" PROJECT_NAME = "Contiki 2.1"
PROJECT_NUMBER = PROJECT_NUMBER =
OUTPUT_DIRECTORY = . OUTPUT_DIRECTORY = .
CREATE_SUBDIRS = NO CREATE_SUBDIRS = NO
@ -15,8 +15,8 @@ ABBREVIATE_BRIEF =
ALWAYS_DETAILED_SEC = NO ALWAYS_DETAILED_SEC = NO
INLINE_INHERITED_MEMB = NO INLINE_INHERITED_MEMB = NO
FULL_PATH_NAMES = YES FULL_PATH_NAMES = YES
STRIP_FROM_PATH = $(docroot) STRIP_FROM_PATH = ../
STRIP_FROM_INC_PATH = $(docroot) STRIP_FROM_INC_PATH =
SHORT_NAMES = YES SHORT_NAMES = YES
JAVADOC_AUTOBRIEF = YES JAVADOC_AUTOBRIEF = YES
MULTILINE_CPP_IS_BRIEF = NO MULTILINE_CPP_IS_BRIEF = NO
@ -33,7 +33,7 @@ SUBGROUPING = YES
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
EXTRACT_ALL = NO EXTRACT_ALL = NO
EXTRACT_PRIVATE = NO EXTRACT_PRIVATE = NO
EXTRACT_STATIC = NO EXTRACT_STATIC = YES
EXTRACT_LOCAL_CLASSES = NO EXTRACT_LOCAL_CLASSES = NO
EXTRACT_LOCAL_METHODS = NO EXTRACT_LOCAL_METHODS = NO
HIDE_UNDOC_MEMBERS = YES HIDE_UNDOC_MEMBERS = YES
@ -66,21 +66,241 @@ WARN_IF_UNDOCUMENTED = NO
WARN_IF_DOC_ERROR = YES WARN_IF_DOC_ERROR = YES
WARN_NO_PARAMDOC = NO WARN_NO_PARAMDOC = NO
WARN_FORMAT = "$file:$line: $text" WARN_FORMAT = "$file:$line: $text"
WARN_LOGFILE = doxygen.log WARN_LOGFILE =
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# configuration options related to the input files # configuration options related to the input files
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
INPUT = $(docsrc) INPUT = contiki-mainpage.txt net.txt dev.txt \
mem.txt \
sys.txt \
lib.txt \
platform.txt \
uip-doc.txt \
uip6-doc.txt \
tutorials.txt \
tutorial-raven.txt \
sicslowpan-doc.txt \
rime-doc.txt \
code-style.txt \
examples.txt \
sicslowmac-doc.txt \
uip-doc.txt build-system.txt \
pt-doc.txt \
../apps/program-handler/program-handler.c \
../core/sys/process.c \
../core/sys/process.h \
../core/sys/cc.h \
../core/sys/etimer.c \
../core/sys/etimer.h \
../core/sys/procinit.h \
../core/sys/procinit.c \
../core/sys/arg.c \
../core/sys/dsc.h \
../core/sys/loader.h \
../core/sys/pt.h \
../core/sys/lc.h \
../core/sys/lc-switch.h \
../core/sys/lc-addrlabels.h \
../core/sys/pt-sem.h \
../core/sys/clock.h \
../core/sys/mt.h \
../core/sys/mt.c \
../core/dev/eeprom.h \
../core/dev/radio.h \
../core/loader/elfloader.h \
../core/loader/elfloader-arch.h \
../cpu/avr/radio/rf230/at86rf230_registermap.h \
../cpu/avr/radio/rf230/frame.c \
../cpu/avr/radio/rf230/frame.h \
../cpu/avr/radio/rf230/hal.c \
../cpu/avr/radio/rf230/hal.h \
../cpu/avr/radio/rf230/radio.c \
../cpu/avr/radio/rf230/radio.h \
../core/cfs/cfs.h \
../core/ctk/ctk.h \
../core/ctk/ctk.c \
../core/ctk/ctk-draw.h \
../core/sys/timer.h \
../core/sys/timer.c \
../core/sys/timesynch.h \
../core/sys/timesynch.c \
../core/net/uip.h \
../core/net/uip.c \
../core/net/uip6.c \
../core/net/uip-nd6.h \
../core/net/uip-nd6.c \
../core/net/uip-nd6-io.c \
../core/net/uip-netif.c \
../core/net/uip-netif.h \
../core/net/uip-icmp6.h \
../core/net/uip-icmp6.c \
../core/net/uipopt.h \
../core/net/uip_arp.h \
../core/net/uip_arp.c \
../core/net/uip-split.h \
../core/net/uip-split.c \
../core/net/uip-fw.h \
../core/net/uip-fw.c \
../core/net/uiplib.h \
../core/net/uiplib.c \
../core/net/resolv.h \
../core/net/resolv.c \
../core/net/psock.h \
../core/net/psock.c \
../core/net/sicslowpan.h \
../core/net/sicslowpan.c \
../core/net/tcpip.h \
../core/net/tcpip.c \
../core/net/mac/mac.h \
../core/net/mac/nullmac.h \
../core/net/mac/nullmac.c \
../core/net/mac/xmac.h \
../core/net/mac/xmac.c \
../core/net/rime.h \
../core/net/rime/abc.h \
../core/net/rime/abc.c \
../core/net/rime/ctimer.h \
../core/net/rime/ctimer.c \
../core/net/rime/ibc.h \
../core/net/rime/ibc.c \
../core/net/rime/ipolite.h \
../core/net/rime/ipolite.c \
../core/net/rime/mesh.h \
../core/net/rime/mesh.c \
../core/net/rime/mh.h \
../core/net/rime/mh.c \
../core/net/rime/neighbor-discovery.h \
../core/net/rime/neighbor-discovery.c \
../core/net/rime/neighbor.h \
../core/net/rime/neighbor.c \
../core/net/rime/nf.h \
../core/net/rime/nf.c \
../core/net/rime/polite.h \
../core/net/rime/polite.c \
../core/net/rime/queuebuf.h \
../core/net/rime/queuebuf.c \
../core/net/rime/rimeaddr.h \
../core/net/rime/rimeaddr.c \
../core/net/rime/rimebuf.h \
../core/net/rime/rimebuf.c \
../core/net/rime/rimestats.h \
../core/net/rime/rimestats.c \
../core/net/rime/rmh.h \
../core/net/rime/rmh.c \
../core/net/rime/route-discovery.h \
../core/net/rime/route-discovery.c \
../core/net/rime/route.h \
../core/net/rime/route.c \
../core/net/rime/ruc.h \
../core/net/rime/ruc.c \
../core/net/rime/rucb.h \
../core/net/rime/rucb.c \
../core/net/rime/sabc.h \
../core/net/rime/sabc.c \
../core/net/rime/sibc.h \
../core/net/rime/sibc.c \
../core/net/rime/suc.h \
../core/net/rime/suc.c \
../core/net/rime/collect.h \
../core/net/rime/collect.c \
../core/net/rime/trickle.h \
../core/net/rime/trickle.c \
../core/net/rime/uc.h \
../core/net/rime/uc.c \
../core/net/rime/rudolph0.h \
../core/net/rime/rudolph0.c \
../core/net/rime/rudolph1.h \
../core/net/rime/rudolph1.c \
../cpu/avr/radio/mac/mac.c \
../cpu/avr/radio/mac/mac.h \
../cpu/avr/radio/mac/sicslowmac.c \
../cpu/avr/radio/mac/sicslowmac.h \
../cpu/avr/radio/ieee-manager/ieee-15-4-manager.c \
../cpu/avr/radio/ieee-manager/ieee-15-4-manager.h \
../core/lib/petsciiconv.h \
../core/lib/memb.h \
../core/lib/memb.c \
../core/lib/mmem.h \
../core/lib/mmem.c \
../core/lib/list.h \
../core/lib/list.c \
../core/lib/me.h \
../core/lib/me.c \
../core/lib/crc16.h \
../core/lib/crc16.c \
../platform/sky/doc/sky.txt \
../platform/esb/doc/esb.txt \
../platform/esb/doc/slipintro.txt \
../platform/esb/dev/beep.h \
../platform/esb/dev/eeprom.c \
../platform/esb/dev/rs232.h \
../platform/esb/dev/rs232.c \
../platform/esb/dev/tr1001.c \
../cpu/avr/dev/usb/serial/cdc_task.c \
../cpu/avr/dev/usb/serial/cdc_task.h \
../cpu/avr/dev/usb/serial/uart_usb_lib.c \
../cpu/avr/dev/usb/serial/uart_usb_lib.h \
../cpu/avr/dev/usb/rndis/ndis.h \
../cpu/avr/dev/usb/rndis/rndis.c \
../cpu/avr/dev/usb/rndis/rndis_protocol.h \
../cpu/avr/dev/usb/rndis/rndis_task.c \
../cpu/avr/dev/usb/rndis/rndis_task.h \
../cpu/avr/dev/usb/storage/avr_flash.c \
../cpu/avr/dev/usb/storage/ctrl_access.c \
../cpu/avr/dev/usb/storage/scsi_decoder.c \
../cpu/avr/dev/usb/storage/storage_task.c \
../cpu/avr/dev/usb/storage/avr_flash.h \
../cpu/avr/dev/usb/storage/conf_access.h \
../cpu/avr/dev/usb/storage/ctrl_access.h \
../cpu/avr/dev/usb/storage/ctrl_status.h \
../cpu/avr/dev/usb/storage/storage_task.h \
../cpu/avr/dev/usb/conf_usb.h \
../cpu/avr/dev/usb/usb_descriptors.c \
../cpu/avr/dev/usb/usb_descriptors.h \
../cpu/avr/dev/usb/usb_specific_request.c \
../cpu/avr/dev/usb/usb_specific_request.h \
../cpu/avr/dev/usb/usb_standard_request.c \
../cpu/avr/dev/usb/usb_drv.h \
../cpu/avr/dev/usb/usb_drv.c \
../cpu/avr/dev/usb/usb_task.h \
../cpu/avr/dev/usb/usb_task.c \
../platform/avr-ravenusb/sicslow_ethernet.c \
../platform/avr-ravenusb/sicslow_ethernet.h \
../platform/avr-ravenusb/contiki-raven-default-init-net.c \
../platform/avr-ravenusb/contiki-raven-main-net.c \
../platform/avr-ravenusb/contiki-raven.h \
ravenusbstick-docs.txt \
../platform/avr-ravenlcd/adc.c \
../platform/avr-ravenlcd/beep.c \
../platform/avr-ravenlcd/key.c \
../platform/avr-ravenlcd/lcd.c \
../platform/avr-ravenlcd/menu.c \
../platform/avr-ravenlcd/raven3290.c \
../platform/avr-ravenlcd/sleep.c \
../platform/avr-ravenlcd/temp.c \
../platform/avr-ravenlcd/timer.c \
../platform/avr-ravenlcd/uart.c \
../platform/avr-ravenlcd/adc.h \
../platform/avr-ravenlcd/beep.h \
../platform/avr-ravenlcd/key.h \
../platform/avr-ravenlcd/lcd.h \
../platform/avr-ravenlcd/menu.h \
../platform/avr-ravenlcd/main.h \
../platform/avr-ravenlcd/sleep.h \
../platform/avr-ravenlcd/temp.h \
../platform/avr-ravenlcd/timer.h \
../platform/avr-ravenlcd/uart.h
FILE_PATTERNS = *.h *.c *.doc.html
FILE_PATTERNS =
RECURSIVE = NO RECURSIVE = NO
EXCLUDE = EXCLUDE =
EXCLUDE_SYMLINKS = NO EXCLUDE_SYMLINKS = NO
EXCLUDE_PATTERNS = EXCLUDE_PATTERNS =
EXAMPLE_PATH = . ../examples/rime ../examples/multi-threading EXAMPLE_PATH = . ../examples/rime
EXAMPLE_PATTERNS = EXAMPLE_PATTERNS =
EXAMPLE_RECURSIVE = NO EXAMPLE_RECURSIVE = NO
IMAGE_PATH = IMAGE_PATH = ./pics
INPUT_FILTER = INPUT_FILTER =
FILTER_PATTERNS = FILTER_PATTERNS =
FILTER_SOURCE_FILES = NO FILTER_SOURCE_FILES = NO
@ -122,7 +342,7 @@ TREEVIEW_WIDTH = 250
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
# configuration options related to the LaTeX output # configuration options related to the LaTeX output
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
GENERATE_LATEX = $(doclatex) GENERATE_LATEX = YES
LATEX_OUTPUT = latex LATEX_OUTPUT = latex
LATEX_CMD_NAME = latex LATEX_CMD_NAME = latex
MAKEINDEX_CMD_NAME = makeindex MAKEINDEX_CMD_NAME = makeindex
@ -180,9 +400,14 @@ INCLUDE_PATH =
INCLUDE_FILE_PATTERNS = INCLUDE_FILE_PATTERNS =
PREDEFINED = CC_FUNCTION_POINTER_ARGS \ PREDEFINED = CC_FUNCTION_POINTER_ARGS \
UIP_UDP \ UIP_UDP \
UIP_TCP \
UIP_CONF_IPV6 \
UIP_CONF_IPV6_REASSEMBLY \
UIP_CONF_IPV6_CHECKS \
UIP_CONF_IPV6_QUEUE_PKT \
SICSLOWPAN_CONF_FRAG \
WITH_LOADER_ARCH \ WITH_LOADER_ARCH \
DOXYGEN \ DOXYGEN
"ASCCMD(name, flags, args)=void CMD_ASCII(name)"
EXPAND_AS_DEFINED = EXPAND_AS_DEFINED =
SKIP_FUNCTION_MACROS = YES SKIP_FUNCTION_MACROS = YES
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
@ -198,7 +423,7 @@ PERL_PATH = /usr/bin/perl
#--------------------------------------------------------------------------- #---------------------------------------------------------------------------
CLASS_DIAGRAMS = NO CLASS_DIAGRAMS = NO
HIDE_UNDOC_RELATIONS = YES HIDE_UNDOC_RELATIONS = YES
HAVE_DOT = NO HAVE_DOT = YES
CLASS_GRAPH = NO CLASS_GRAPH = NO
COLLABORATION_GRAPH = NO COLLABORATION_GRAPH = NO
GROUP_GRAPHS = NO GROUP_GRAPHS = NO

BIN
doc/pics/caution.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 982 B

BIN
doc/pics/contiki_menu_3290.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/pics/dataframe.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 6.2 KiB

BIN
doc/pics/fcf.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/pics/layers.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 9.3 KiB

BIN
doc/pics/raven.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 166 KiB

BIN
doc/pics/raven.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
doc/pics/raven_detail.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
doc/pics/ravenusb_large.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
doc/pics/ravenusb_medium.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
doc/pics/ravenusb_network_connections.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
doc/pics/ravenusb_shortpins.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 64 KiB

BIN
doc/pics/tutorial-raven-basic.jpg Executable file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
doc/pics/tutorial-raven-connections.jpg Executable file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
doc/pics/tutorial-raven-jtag.jpg Executable file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 59 KiB

BIN
doc/pics/wireshark_color.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 158 KiB

BIN
doc/pics/wireshark_explained.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 184 KiB

265
doc/ravenusbstick-docs.txt Normal file
View file

@ -0,0 +1,265 @@
/**
\ingroup platform
\defgroup usbstick RZRAVEN USB Stick (Jackdaw)
\image html ravenusb_medium.jpg
\section introduction Introduction
This document explains the Raven USB Stick when operated on an IPv6 network. The
USB Stick allows the computer, and outside networks, to communicate with low-cost
embedded nodes. The "RZUSBSTICK" hardware, when loaded with the Contiki "ravenusbstick"
example, forms the complete device described here. This combination of hardware and
firmware is henceforth referred to as the "Jackdaw".
\section capabilities Capabilities
The Jackdaw supports multiple operating systems, customizing itself to OSes as
needed. The overall idea for a network interface is to emulate an ethernet interface.
Data is passed to the Jackdaw as if it was an ethernet port, however the Jackdaw
passes this data over the air to end nodes.
The Jackdaw can function as an 802.15.4 sniffer, and can sniff the raw 802.15.4 frame
at the same time it is providing network functionality.
In addition to the network interface, the Jackdaw can enumerate a USB serial port
at the same time. This serial port can be used to pass debug messages, or to change
operating parameters as needed. Note that WindowsXP SP2 or lower does not support this,
the serial port will only be enumerated on Linux or WindowsXP SP3. Windows Vista should
work with minor modification to the INF files.
Finally the Jackdaw has the ability to show up as a USB mass storage drive. This is used
to load drivers onto a PC without needing any other hardware, such as a driver disk. The
amount of storage is very limited at around 59 Kbyte, sufficent for a few driver files.
\section pluging Plugging It In
When plugging the Jackdaw in, several things occur in sequence:
- Attempt to appear as a network interface with a serial port. If this fails (drivers don't load),
it then unmounts itself and waits a few seconds.
- Attempt to appear as just a network interface. If this fails as well, it again unmounts itself.
- Finally mounts as a mass storage device
If the device has never before been plugged in, you will end up with an unformatted USB mass storage device.
You can format this as you would a normal drive - on Windows right click and select "format". If the device
has previously been formatted, or was programmed from a preformatted flash image, you will end up with a new drive
which contains the drivers needed to have the device work on Windows.
\subsection loaddrivers Loading Drivers
Windows should prompt you for drivers for the device. Simply point it to location "C:\contikisrc\cpu\avr\dev\usb\INF" Where
the directory "c:\contikisrc" is where the Contiki source code is on your computer.
If you have a Jackdaw with a formatted mass storage section, with the drivers on it, you can simply wait until that drive shows
up. Then point the Windows "new hardware found" Wizard to this new drive, which should have three .INF files in it.
\section setup Setting Up
\subsection Linux
The Jackdaw has excellent support in Linux. The first thing to check is that it was detected. Plug it in, and check the output of 'dmesg'.
You should see something like:
\verbatim
usb 5-2: new full speed USB device using uhci_hcd and address 29
usb 5-2: configuration #1 chosen from 1 choice
rndis_host 5-2:1.0: dev can't take 1338 byte packets (max 1338), adjusting MTU to 1280
usb0: register 'rndis_host' at usb-0000:00:1d.3-2, RNDIS device, 02:12:13:14:15:16
cdc_acm 5-2:1.2: ttyACM0: USB ACM device
usb 5-2: New USB device found, idVendor=03eb, idProduct=2021
usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-2: Product: RZRAVEN USB DEMO
usb 5-2: Manufacturer: Atmel
usb 5-2: SerialNumber: 1.0.0
\endverbatim
You can then check that it was assigned a link-local address. Run 'ifconfig' and observe the output, looking for the line about usb0:
\verbatim
usb0 Link encap:Ethernet HWaddr 02:12:13:14:15:16
inet6 addr: fe80::12:13ff:fe14:1516/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1280 Metric:1
RX packets:131 errors:131 dropped:0 overruns:0 frame:131
TX packets:169 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30429 (29.7 KiB) TX bytes:28290 (27.6 KiB)
\endverbatim
The address that starts with "fe80" is the link-local address. If this wasn't automatically assigned, you can assign one as such:
\verbatim
ip -6 address add fe80::12:13ff:fe14:1516/64 scope link dev usb0
\endverbatim
If you wish to see how to generate router advertisements in Linux see the \ref tutorialraven .
You will also notice the line mentioning ttyACM0, that is the 'debug' interface. You can connect any terminal emulator to it such
as gtkterm. Simply set the port to "dev/ttyACM0". See the \ref DebugPort section for more information.
\subsection Windows XP
Once the drivers are installed, you should see the device show up in "Network Connections". You should see something like this:
\image html ravenusb_network_connections.png
Right-click on this, and hit "Properties".
Click the "Install" button. Select "Protocol" as the type of network component, and hit "Add". The manufacture is "Microsoft" and the network protocol
is "TCP/IP version 6". Hit OK.
Then in the window "This connection uses the following items:", uncheck everything EXCEPT "Microsoft TCP/IP version 6". Hit OK and get out
of that dialog. We can no longer do anything graphically, as WindowsXP doesn't have support for IPv6 through anything but
the command-line interface.
If you wish to see how to configure Windows to generate router advertisements, see the \ref tutorialraven.
You may additionally see a debug port enumerate. This will show up as a serial port, which can be checked by going to the Device Manager and seeing if an "Atmel Raven USB Debug Port" shows up under "Ports (COM & LPT)". If so, you can connect a terminal emulator such to this port. A simple one that is recommended is "Br@y++ Terminal".
\section DebugPort Debug Port Useage
The Jackdaw enumerates a CDC serial port. This is typically used by USB<-->Serial converters, however in this case it simply emulates a serial port. Since there is no physical serial port, the setting of the baud rate does not matter.
The Jackdaw sends both a LF and CR after every line, so you should disable any terminal emulator options that add extra CR's.
With the port connected, strike the 'h' key to bring up the main menu. It should look something like this:
\verbatim
********** Jackdaw Menu ******************
* *
* Main Menu: *
* h,? Print this menu *
* m Print current mode *
* s Set to sniffer mode *
* n Set to network mode *
* 6 Toggle 6lowpan *
* r Toggle raw mode *
* u Switch to mass-storage*
* *
* Make selection at any time by pressing *
* your choice on keyboard. *
******************************************
\endverbatim
<b>Network mode</b><br>
Network mode is the default mode. In this mode addresses inside IP packets will be adjusted to reflect the network they
are on. For instance inside a Router Advertisement message, the link-layer address on the ethernet side will be 6 bytes.
On the 802.15.4 side it will be 8 bytes. This allows both systems to accept this IP packet as valid.
<b>Sniffer mode</b><br>
In sniffer mode, the IP packets themselves are left unchanged. This means that you won't be able to form a network, as
the computer's IP stack will not understand why the link-layer addresses are 8 bytes. It is only expecting 6 bytes, as
it is assuming an ethernet layer.
<b>6lowpan enabled/disabled</b><br>
Enabling or Disabling 6lowpan changes if the USBStick will decode 6lowpan messages into valid IPv6 messages and send
them over the ethernet interface. Enabled by default.
<b>raw mode enabled/disabled</b><br>
If raw mode is enabled, every 802.15.4 frame that comes in will be sent to the computer raw. It will be sent as an
ethernet frame, with the ETHTYPE set to 0x809A. Note this is not an IEEE standard, so to use this device as a
802.15.4 sniffer needs some extra work, described in the \ref Wireshark section. Also for every 802.15.4 packet
that is sent out over the RF port is sent out over ethernet as well.
<b>Mass Storage</b><br>
This will switch the device to \ref MassStorageMode
\section Wireshark Using Wireshark
When using the Jackdow with 6lowpan, you can
simply operate Wireshark as normal. Select the interface as the USB Stick, on Linux this will likely be "usb0", and on Windows
it will just call the interface "Atmel". You will see pure IPv6 packets, with traffic such as ICMPv6, TCP, or UDP.
If you have raw mode enabled (it is by default), you will also see 802.15.4 information. You may see many 802.15.4 packets
for one IP packet due to fragmentation. You can also put either 'ipv6' or 'wpan' in the filter box at the top of Wireshark
to filter out everything but IPv6 or 802.15.4 traffic. Also, for received frames the 802.15.4 data will come BEFORE the IPv6
packet. For transmitted frames, the 802.15.4 data will come AFTER the IPv6 packet. You can see that in the following, where
messages from the same source are boxed:
\image html wireshark_explained.png
Note that Wireshark does have support for 802.15.4, but you need version 1.1.2 or later. See \ref annex_wireshark for download instructions.
\note 802.15.4 packets transmitted from the Jackdaw will come up as having "Bad FCS". This is because the FCS is added automatically by the
radio chip, and is not known to the microcontroller on the Jackdaw. Hence some padding bytes are added to allow you to see where the FCS would go.
The 802.15.4 packet was generated from the IPv6 packet directly. The only way to actually sniff the real over the air data is to use a second Jackdaw
as just a sniffer.
Also be sure to use the features of wireshark to make life easier! You can colorize packets based on various things, including
destination and source addresses. The following example colourizes packets destined for different addresses differently, quickly
letting you see message flow. You could furthur colorize based on the message type, to allow you to see 802.15.4 packets and
IPv6 packets in different colors. The following example has the 'source_eth' and 'dest_eth' rules at the top of the order, you
may want to put them lower so you still see other colourizations such as bad TCP, checksum errors, etc.
\image html wireshark_color.png
\section MassStorageMode Mass Storage Mode
The mass storage mode provides a small amount of storage by using part of the internal flash of the AVR. This will get
erased every time the AVR is reprogrammed.
The Jackdaw can end in mass storage mode in three ways. It can fail all other modes and end up there, it can be forced
there through the debug port, or it can be forced there through a hardware switch. see the \ref hardwareforce section.
Once in mass storage mode, you will have to format the device. This can be done by right-clicking on it and hitting
format, or if you attempt to open the drive Windows will ask you to format it. Once it is formatted you can store a few INF
files on it! If you read the FLASH back from the AVR, you now have an image with a preformatted drive with those INF files
on it already!
\section hardwareforce Forcing Jackdaw to certain Modes
The Jackdaw has several operating modes, and very limited inputs to switch between them. Hence it auto-switches to what
it feels is the most useful mode, but it's not always right. Hence an override is provided to allow you to use it in other
modes.
This override is to short two pads on the back of the Jackdaw. Note that only a somewhat conductive short is needed, a moist finger should be plenty of conductivity. The pads to short are visible below the"A" in the "ATMEL" logo. There will be three pads - only short the two closest to the "ATMEL" logo. Or as below:
\image html ravenusb_shortpins.jpg
Short them when plugging in the Jackdaw, and it enters "reverse logic mode". If it doesn't, you either might have
not enough conductivity, or you might be shorting to the third pad too much.
In "reverse logic mode" it will stay in the main mode (Network interface + Serial debug port) if it doesn't see the
driver loading on the host computer. This mode is needed for Windows Vista, where you have to keep the hardware plugged in while
installing drivers.
If the driver DOES load OK, it will remount itself as a mass storage device. The idea is that you can hold the Jackdaw a specific
way when plugging in and it will mount as mass storage. Note that it will FIRST mount as a network interface for a few seconds
before switching.
One problem with this is Windows XP SP2: it will never exit the first (network + debug) mode, and you don't have a debug
port to switch to mass storage mode. You can either upgrade to SP3, or uncomment this line in platforms\ravenusbstick\contiki-raven-default-init-lowlevel.c:
\code
#define WINXPSP2
\endcode
\section Address Translation
Addresses on the 802.15.4 network are 8 bytes long, and addresses on an ethernet network are 6 bytes long. This provides some problems for
bridging the two networks. This should be done by routing the IP packets between the ethernet and 802.15.4 network, but the current
code does not have support for routing.
As a temporary solution, addresses are "translated" when passing through the Jackdaw. This generates valid ethernet addresses from the
802.15.4 addresses, and valid 802.15.4 addresses from ethernet addresses. Note this also includes translating addresses which are
inside IP packets. Certain messages, such as various neighbor discovery messages, include a link-layer address. An IP stack which
is expecting an ethernet-sized address will get confused by the different size, and vis-versa.
Details of the translation can be found in the \ref sicslowinterop documentation. It is important to remember this is a temporary solution
until proper routing is implemented.
\section Annex
\subsection annex_wireshark Wireshark download
\li Check the latest stable release at http://www.wireshark.org/ - it may already be revision 1.1.2 or later.
\li You can apply a patch to Wireshark sources earlier than 1.1.2 and rebuild it yourself, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2938
\li You can download the latest sources or prebuild binary from http://www.wireshark.org/download/automated/ - be sure to get SVN revision 26352 or later. For win32 there are three types of binaries, the "normal" installer will have a name like "wireshark-win32-1.1.2-SVN-26354.exe".
\li You can download a prebuilt version of Wireshark 1.0.3 at http://www.newae.com/download/wireshark-setup-1.0.3-jackdaw.exe
\note
For some reason the author list is crazy, i'm not sure how to stop this! It should follow this text...
*/

127
doc/sicslowmac-doc.txt Normal file
View file

@ -0,0 +1,127 @@
/**
\addtogroup rf230mac
@{
*/
/**
* \defgroup macdoc SICSLoWMAC Implementation
* @{
\section macintro 1. Introduction
The phase1 MAC implemented to support the IPv6/6LoWPAN stack within the Contiki
project is a light weight yet adequate beginning. This phase supports point to
point data connectivity between a router device and an end device. The router is
the RZ USB stick from the ATAVRRZRAVEN kit. The end node is the AVR
Raven from the ATAVRRZRAVEN kit. The picture below shows the complete ATAVRRZRAVEN kit.
\image html raven.png
The next phases will implement a commissioning concept including scan, and
beacon generation. These kinds of primitives will allow dynamic network
formation. Additionally, routing and low power/sleep will be implemented in
following phases.
\section macprereqs 2. Prerequisites
See the \ref tutorialraven for required systems setup configuration.
\section macoverview 3. MAC Overview
This MAC follows the recommendations of RFC4944 with respect to data frames and
acknowledgements (i.e. all data frames are acknowledged). At the time of this
writing (phase 1) beacons (frames) and association events are not implemented.
Additionally, data frames always carry both source and destination addresses.
PANID compression (intra-pan) is not used so both source and destination PANID's
are present in the frame.
The SICSLoWMAC supports the IEEE 802.15.4 Data Request primitive and the Data
Request Indication primitive. The data request primitive constructs a <b>proper</b>
802.15.4 frame for transmission over the air while the data indication parses a
received frame for processing in higher layers (6LoWPAN). The source code for
the mac can be found in the sicslowmac.[c,h] files.
To assemble a frame a MAC header is constructed with certain presumptions:
-# Long source and destination addresses are used.
-# A hard coded PANID is used.
-# A hard coded channel is used.
-# Acknowledgements are used.
-# Up to 3 auto retry attempts are used.
These and other variables are defined in mac.h.
Given this data and the output of the 6LoWPAN function, the MAC can construct
the data frame and the Frame Control Field for transmission.
An IEEE 802.15.4 MAC data frame consists of the fields shown below:
\image html dataframe.png
The Frame Control Field (FCF) consist of the fields shown below:
\image html fcf.jpg
\note The MAC address of each node is expected to be stored in EEPROM and
retrieved during the initialization process immediately after power on.
\section macrelationship 4. 6LoWPAN, MAC and Radio Relationship
The output function of the 6LoWPAN layer (sicslowpan.c) is the input function
to the MAC (sicslowmac.c). The output function of the MAC is the input function
of the radio (radio.c). When the radio receives a frame over the air it processes
it in its TRX_END event function. If the frame passes address and CRC filtering
it is queued in the MAC event queue. Subsequently, when the MAC task is processed,
the received frame is parsed and handed off to the 6LoWPAN layer via its input
function. These relationships are depicted below:
\image html layers.png
\section maccode 5. Source Code Location
The source code for the MAC, Radio and support functions is located in the path:
- \\cpu\\avr\\radio
- \\rf230
- \\mac
- \\ieee-manager
-# The \\rf230 folder contains the low level HAL drivers to access and control
the radio as well as the low level frame formatting and parsing functions.
-# The \\mac folder contains the MAC layer code, the generic MAC initialization
functions and the defines mentioned in section 3.
-# The \\ieee-manager folder contains the access functions for various PIB
variables and radio functions such as channel setting.
The source code for the Raven platforms is located in the path:
- \\platform
- \\avr-raven
- \\avr-ravenlcd
- \\avr-ravenusb
-# The \\avr-raven folder contains the source code to initialize and start the
raven board.
-# The \\avr-ravenlcd folder contains the complete source code to initialize
and start the ATmega3209P on raven board in a user interface capacity. See the
Doxygen generated documentation for more information.
-# The \\avr-ravenusb folder contains the source code to initialize and start
the raven USB stick as a network interface on either Linux or Windows platforms.
Note that appropriate drivers are located in the path:
- \\cpu\\avr\\dev\\usb\\INF
\section macavrstudio 6. AVR Studio Project Location
There are two projects that utilize the Logo Certified IPv6 and 6LoWPAN layers
contributed to the Contiki project by Cisco. These are ping-ipv6and webserver-ipv6
applications. They are located in the following paths:
- \\examples\\webserver-ipv6
and
- \\examples\\ping-ipv6
The ping-ipv6 application will allow the USB stick to ping the Raven board while
the webserver-ipv6 application will allow the raven board to serve a web page.
When the ravenlcd-3290 application is programmed into the ATmega3290P on the
Raven board, the Raven board can ping the USB stick and it can periodically update
the temperature in the appropriate web page when served.
*/
/** @} */
/** @} */

210
doc/sicslowpan-doc.txt Normal file
View file

@ -0,0 +1,210 @@
/**
\addtogroup uip
@{
*/
/**
* \defgroup sicslowpan 6LoWPAN implementation
* @{
6lowpan is a Working Group in IETF which defines the use of IPv6 on
IEEE 802.15.4 links.
Our implementation is based on RFC4944 <em>Transmission of IPv6
Packets over IEEE 802.15.4 Networks</em>, draft-hui-6lowpan-interop-00
<em>Interoperability Test for 6LoWPAN</em>, and draft-hui-6lowpan-hc-01
<em>Compression format for IPv6 datagrams in 6lowpan Networks</em>.
<HR>
\section drafts Specifications implemented
\note We currently only support 802.15.4 64-bit addresses.
\subsection rfc4944 RFC 4944
RFC4944 defines address configuration mechanisms based on 802.15.4
16-bit and 64-bit addresses, fragmentation of IPv6 packets below IP
layer, IPv6 and UDP header compression, a mesh header to enable link-layer
forwarding in a mesh under topology, and a broadcast header to enable
broadcast in a mesh under topology.
We implement addressing, fragmentation, and header compression. We support
the header compression scenarios defined in draft-hui-6lowpan-interop-00.
This draft defines an interoperability scenario which was used between
ArchRock and Sensinode implementations.
We do not implement mesh under related features, as we target route over
techniques.
\subsection hc01 draft-hui-6lowpan-hc-01
draft-hui-6lowpan-hc-01 defines a stateful header compression mechanism
which should soon deprecate the stateless header compression mechanism
defined in RFC4944. It is much more powerfull and flexible, in
particular it allows compression of some multicast addresses and of all
global unicast addresses.
<HR>
\section general Implementation overview
6lowpan does not run as a separate process. It is called by the MAC %process
when a 6lowpan packet is received, and by the tcpip %process when an
IPv6 packet needs to be sent.
It is initialized from the MAC %process, which calls sicslowpan_init
(giving as argument a pointer to the mac_driver structure).
The main 6lowpan functions are implemented in the sicslowpan.h and
sicslowpan.c files. They are used to format packets between the
802.15.4 and the IPv6 layers.
6lowpan also creates a few IPv6 and link-layer dependencies which are
detailed in the next section.
<HR>
\section implementation Implementation details
\subsection Addressing
<b>Link-layer addresses</b><br>
The format of a 802.15.4 address is defined in uip.h.
\code
/** \brief 64 bit 802.15.4 address */
struct uip_802154_shortaddr {
u8_t addr[2];
};
/** \brief 16 bit 802.15.4 address */
struct uip_802154_longaddr {
u8_t addr[8];
};
/** \brief 802.15.4 address */
typedef struct uip_802154_longaddr uip_lladdr_t;
#define UIP_802154_SHORTADDR_LEN 2
#define UIP_802154_LONGADDR_LEN 8
#define UIP_LLADDR_LEN UIP_802154_LONGADDR_LEN
\endcode
<b>Neighbor Discovery Link Layer Address options </b><br>
The format of ND link-layer address options depends on the length of
the link-layer addresses.
802.15.4 specificities regarding link-layer address options are implemented in uip-nd6.h.
\code
#define UIP_ND6_OPT_SHORT_LLAO_LEN 8
#define UIP_ND6_OPT_LONG_LLAO_LEN 16
#define UIP_ND6_OPT_LLAO_LEN UIP_ND6_OPT_LONG_LLAO_LEN
\endcode
<b>Address Autoconfiguration</b><br>
The address autoconfiguration mechanism also depends on the format of
the link-layer address. The dependency is reflected in the
#uip_netif_addr_autoconf_set function in #uip-netif.c.
\code
#if (UIP_LLADDR_LEN == 8)
memcpy(ipaddr->u8 + 8, lladdr, UIP_LLADDR_LEN);
ipaddr->u8[8] ^= 0x02;
\endcode
\subsection io Packet Input/Output
At initialization, the #input function in sicslowpan.c is set as the
function to be called by the MAC upon packet reception. The #output
function is set as the tcpip_output function.<br>
At packet reception, the link-layer copies the 802.15.4 payload in the
rime buffer, and sets its length. It also stores the source and
destination link-layer addresses as two rime addresses.
\code
rimebuf_copyfrom(&rx_frame.payload, rx_frame.payload_length);
rimebuf_set_datalen(rx_frame.payload_length);
rimebuf_set_addr(RIMEBUF_ADDR_RECEIVER, (const rimeaddr_t *)&rx_frame.dest_addr);
rimebuf_set_addr(RIMEBUF_ADDR_SENDER, (const rimeaddr_t *)&rx_frame.src_addr);
\endcode
It then calls the sicslowpan #input function. Similarly, when the IPv6 layer
has a packet to send over the radio, it puts the packet in uip_buf,
sets uip_len and calls the sicslowpan #output function.
\subsection frag Fragmentation
\li #output function: When an IP packet, after header compression, is
too big to fit in a 802.15.4 frame, it is fragmented in several packets
which are sent successively over the radio. The packets are formatted
as defined in RFC 4944. Only the first fragment contains the IP/UDP
compressed or uncompressed header fields.
\li #input function: This function takes care of fragment
reassembly. We do not assume that the fragments are received in order.
When reassembly of a packet is ongoing, we discard any non fragmented
packet or fragment from another packet. Reassembly times out after
#SICSLOWPAN_REASS_MAXAGE = 20s.
\note Fragmentation support is enabled by setting the #SICSLOWPAN_CONF_FRAG
compilation option.
\note As we do not support complex buffer allocation mechanism, for now
we define a new 1280 bytes buffer (#sicslowpan_buf) to reassemble packets.
At reception, once all the fragments are received, we copy the packet
to #uip_buf, set #uip_len, and call #tcpip_input.
\note #MAC_MAX_PAYLOAD defines the maximum payload
length in a 802.15.4 frame. For now it is constant and equal to 102
bytes (the 802.15.4 frame can be maximum 127 bytes long, and
the header 25 bytes long).
\subsection hc Header Compression
<b>Compression schemes</b><br>
The #SICSLOWPAN_CONF_COMPRESSION compilation option defines the
compression scheme supported. We support HC1, HC01, and IPv6 compression.
HC1 and IPv6 compression are defined in RFC4944, HC01 in
draft-hui-6lowpan-hc. What we call IPv6 compression means sending packets
with no compression, and adding the IPv6 dispatch before the IPv6 header.<br>
If at compile time IPv6 "compression" is chosen, packets sent will never
be compressed, and compressed packets will not be processed at reception.<br>
If at compile time either HC1 or HC01 are chosen, we will try to compress
all fields at sending, and will accept packets compressed with the
chosen scheme, as well as uncompressed packets.<br>
Note that HC1 and HC01 supports are mutually exclusive. HC01 should soon
deprecate HC1.
<b>Compression related functions</b><br>
When a packet is received, the #input function is called. Fragmentation
issues are handled, then we check the dispatch byte: if it is IPv6, we
treat the packet inline. If it is HC1 or HC01, the corresponding
decompression function (#uncompress_hdr_hc1 or #uncompress_hdr_hc01)
is called.<br>
When a packet needs to be sent, we try to compress it. If only the IPv6
compression support is enabled, we just add the IPv6 dispatch before the
802.15.4 payload. If HC1 or HC01 support is enabled, we call the
corresponding compression function (#compress_hdr_hc1 or #compress_hdr_hc01)
to compress the packet as much as possible.
<b>HC1 comments</b><br>
In HC1, if the IPv6 flow label is not compressed, we would need to copy
the fields after the flow label starting in the middle of a byte (the
flow label is 20 bits long). To avoid this, we compress the packets only
if all fields can be compressed. If we cannot, we use the IPv6 dispatch
and send all headers fields inline. This behavior is the one defined in
draft-hui-6lowpan-interop-00.<br>
In the same way, if the packet is an UDP packet, we compress the UDP
header only if all fields can be compressed.<br>
Note that HC1 can only compress unicast link local addresses. For this
reason, we recommend using HC01.
<b>HC01 comments</b><br>
HC01 uses address contexts to enable compression of global unicast
addresses. All nodes must share context (namely the global prefixes in
use) to compress and uncompress such addresses successfully. The context
number is defined by 2 bits. Context 00 is reserved for the link local
context. Other contexts have to be distributed within the LoWPAN
dynamically, by means of ND extensions yet to be defined.<br>
Until then, if you want to test global address compression, you need
to configure the global contexts manually.
<HR>
*/
/** @} */
/** @} */

592
doc/tutorial-raven.txt Normal file
View file

@ -0,0 +1,592 @@
/**
\addtogroup tutorials
@{
*/
/**
* \defgroup tutorialraven Running Contiki with uIPv6 and SICSlowpan support on Atmel RAVEN hardware
* @{
This tutorial explains how to run Contiki with IPv6 and 6lowpan
support on Atmel RAVEN hardware.
\section toc Table of contents
\ref introduction<br>
\ref hardware<br>
\ref software<br>
\ref overview<br>
\ref installation<br>
\ref running<br>
\ref advanced<br>
\ref issues<br>
\ref annex<br>
<HR>
\section introduction Introduction
This tutorial explains how to run Contiki with IPv6 and 6lowpan
support on Atmel RAVEN evaluation kit (ATAVRRZRAVEN) hardware. We
present basic example system architecture and application scenarios,
as well as instructions to run more advanced demos.
<HR>
\section hardware Hardware requirements
To run the demo, you will need at least
\li one AVR RAVEN board, which embeds an ATmega1284P and an
ATmega3290P micro controller (MCU) as well as an AT86RF230
802.15.4 radio chip.
\li one RZ USB stick, which embeds an AT90USB1287 MCU and
an AT86RF230 802.15.4 radio chip.
\li one PC running Windows to program the chips. For the demo
itself, a PC running Linux or Windows.
\li one On-chip programming platform. We recommend Atmel JTAGICE
mkII.
\note Links to detailed hardware documentation are in
\ref annex_hardware
<HR>
\section software Software requirements
To install the demo you need:
\li Contiki 2.3 or later source code, installed in a directory. In
the rest of this tutorial we assume the directory is c:/contiki
\li Cygwin with "make" utility installed.
\li AVR Studio 4.14 or later
\li WinAVR20080610 or later
\li Windows drivers installed for the JTAGICE mkII.
Instructions to install these tools are in the section \ref annex_software.<br>
To run the demo, you need:
\li one PC running Linux with kernel 2.6.24 or later, with support for the
following kernel modules: IPv6, usbnet, cdc_ether, cdc_acm, rndis_wlan.
\li OR one PC running Windows with IPv6 support. If you use Windows XP,
you need Service Pack 3 installed.
\note
On windows XP, if ipv6 support is not enabled, enable it by typing
in a shell:
\verbatim
ipv6 install
\endverbatim
<HR>
\section overview Demo Overview
\subsection overview_architecture Network Architecture
The network comprises:
\li a PC acting as an IPv6 router with an 802.15.4 interface
and an Ethernet interface.
\li a RAVEN board acting as an IPv6 host.
In the basic demo, you can:
\li Ping the RAVEN Board from the router
\li Ping the router from the RAVEN board, using the RAVEN board
menu
\li Browse the web server running on the RAVEN board. The server
displays the live temperature measured from the board temperature
sensor
\image html tutorial-raven-basic.jpg
<HR>
\section installation Compiling, installing, configuring
\subsection installation_compiling Compiling the binaries for RAVEN and RZ USB stick
The binaries needed are:
\li c:/contiki/examples/webserver-ipv6/webserver6.elf file for the RAVEN board ATmega1284P
\li c:/contiki/platform/avr-ravenlcd/ravenlcd_3290.elf file for the RAVEN board ATmega3290P
\li c:/contiki/examples/ravenusbstick/ravenusbstick.elf file for the RZ USB Stick AT90USB1287
To compile each of them, type in Cygwin:
\verbatim
cd c:/contiki/examples/webserver-ipv6
make TARGET=avr-raven webserver6.elf
\endverbatim
\verbatim
cd c:/contiki/platform/avr-ravenlcd
make
\endverbatim
\verbatim
cd c:/contiki/examples/ravenusbstick
make
\endverbatim
\subsection installation_hw Installing the hardware
To power the RAVEN, put the EXT/BAT jumper in BAT position.
This will enable power on batteries. If you want to power
the RAVEN externally, check instructions in
\ref advanced_externalboard.
The RZ USB Stick needs to be plugged in the PC you will run
the demo on. If you plan to run the demo on a Windows PC, you
will need to install drivers once contiki is loaded on the
stick. Until then, you can exit any driver installation popup.
\subsection installation_loading Programming the boards
<b>What you need to do</b><br>
\li On the RAVEN board, program the binaries on both AVR ATmega.
\li On the RZ USB Stick, load the binary on the AT90USB1287
<b>Hardware connections</b><br>
\li Connect the JTAG connectors to the JTAGICE as described in
the picture below.
\image html tutorial-raven-jtag.jpg
\li Connect the JTAGICE mkII to a Windows PC through USB.
\li To program (load) each AVR, you will need to connect the
JTAGICE JTAG connector to the JTAG pins corresponding to the
AVR you want to program, as shown in the picture below.
\image html tutorial-raven-connections.jpg
<b>To load the binary on each AVR in Windows</b><br>
\li Launch AVR Studio and exit any popup window.
\li Connect the JTAG pins of the JTAGICE into the JTAG connector of
the target processor.
\li In AVR Studio, click on "Tools"->"Program AVR"->"Auto Connect"
\li Go to the "Main tab"
\li In the "Programming mode and target settings" list, select JTAG
\li Select the processor type in the "Device" list and click
"Read Signature". If the Device signature is read properly,
it means AVR Studio is properly connected to the AVR.
\li Go to the "Program" tab
\li In the "ELF Production file format" section,
browse to the binary, then click program
\verbatim
For webserver6.elf, set the processor to ATmega1284P
For ravenlcd_3290.elf, set the processor to ATmega3290P
For ravenusbstick.elf, set the processor to AT90USB1287
\endverbatim
Once the RZ USB Stick is programmed, unplug it from the PC.
Note this programmed the fuses, EEPROM, and FLASH all at once.
<HR>
\section running Running the basic demo
\subsection running_router Setting up the router
<b>On Linux</b><br>
Plug the RZ USB Stick in the PC. It should appear as a USB
network interface (e.g. usb0).
usb0 should automatically get an IPv6 link local address, i.e.
fe80::0012:13ff:fe14:1516/64. Check this is the case by typing
\verbatim
ifconfig
\endverbatim
and checking the addresses of interface usb0
If it does not, add it manually:
\verbatim
ip -6 address add fe80::0012:13ff:fe14:1516/64 scope link dev usb0
\endverbatim
Configure the IP addresses on usb0
\verbatim
ip -6 address add aaaa::1/64 dev usb0
\endverbatim
Install the radvd deamon and configure it so the usb0
interface advertises the aaaa::/64 prefix as on link
and usable for address autoconfiguration.
Example radvd configuration (usually in /etc/radvd.conf)
\verbatim
interface usb0
{
AdvSendAdvert on;
AdvLinkMTU 1280;
AdvCurHopLimit 128;
AdvReachableTime 360000;
MinRtrAdvInterval 500;
MaxRtrAdvInterval 1000;
prefix AAAA::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
\endverbatim
Restart the radvd daemon. Example command:
\verbatim
/etc/init.d/radvd restart
\endverbatim
If you get a message that radvd won't start as forwarding isn't enabled,
you can run this as root:
\verbatim
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
\endverbatim
<b>On Windows</b><br>
Plug the RZ USB Stick in the PC. A "new hardware installation"
window should pop up. If it does not, go to "Control Panel"->
"Add Hardware". Choose "Install the driver manually", then
select the search path C:\\contiki\\cpu\\avr\\dev\\usb\\INF. Finish
the installation.
You now need to get the "interface index" of the USB Stick
interface (noted [interface index] in the following) and the
Ethernet interface (noted [ethernet interface index] in the
following).
In a DOS or Cygwin shell, type
\verbatim
ipv6 if
\endverbatim
As an example, the output might look something like this:
\verbatim
...
Interface 7: Ethernet
...
link-layer address: 02-12-13-14-15-16
preferred link-local fe80::12:13ff:fe14:1516, life infinite
...
Interface 4: Ethernet: Local Area Connection
...
link-layer address: 00-1e-37-16-5d-83
preferred link-local fe80::21e:37ff:fe16:5d83, life infinite
...
...
\endverbatim
Note the link-layer address associated with interface 7 is the USB Stick. Hence
[interface index] is 7, [ethernet interface index] is 4 and [ethernet
link-local address] is fe80::21e:37ff:fe16:5d83.
Then you need to
\li Set the USB Stick interface as an advertising interface
\li Configure a global IP address on the USB Stick interface
\li Add a default route through the Ethernet interface
\li Set the aaaa::/64 prefix as "on link" and published on the USB Stick
interface.
To do so, type:
\code
ipv6 ifc [interface index] advertises forwards
ipv6 adu [interface index]/aaaa::1
ipv6 rtu ::/0 [ethernet interface index]/[ethernet link-local address] publish
ipv6 rtu aaaa::/64 [interface index] publish
\endcode
\subsection running_raven Booting the RAVEN boards
Reboot the RAVEN board.
The PC sends router advertisements and the RAVEN Board configures
an IPv6 global address based on them. The PC global addresses
were set above. Communication is ready.
\subsection running_ping1 Pinging the RAVEN board from the router
On Windows (Cygwin shell) or Linux, type
\verbatim
ping6 -n 5 aaaa::11:22ff:fe33:4455
\endverbatim
or
\verbatim
ping6 -s aaaa::1 aaaa::11:22ff:fe33:4455
\endverbatim
The router is sending 5 echo requests to the RAVEN board. The RAVEN board
answers with 5 echo replies.
\subsection running_ping2 Pinging the router from the RAVEN board
To send a ping from the RAVEN to the router you need to use the
RAVEN's joystick and LCD screen. Initially, the LCD screen should
print CONTIKI - 6LOWPAN in a loop. You can navigate the LCD menu by
using the small joystick just below its lower right corner. To 'ping'
push the joystick twice to the right. The RAVEN board sends 4 echo
requests to the router, which answers by 4 echo replies.<br>
For more information about the LCD menu, please see \ref lcdraven.
\subsection running_browse Browsing the RAVEN board web server
In a Web browser, point to http://[aaaa::0011:22ff:fe33:4455].
Then click on 'Sensor Readings'. If no temperature is displayed it
means that you need to start the temperature update %process on the
RAVEN. To do so you must use the RAVEN's LCD menu and
joystick. Starting from the CONTIKI - 6LOWPAN display navigate to TEMP
and then to SEND. You can pick either ONCE or AUTO, but in any
case you always need to reload the webpage to see the latest temperature
reading. <br>
For more information about the LCD menu, please see \ref lcdraven.
<HR>
\section advanced Advanced use
\subsection advanced_externalboard Using an external board for power and Debug
To power the RAVEN boards externally and enable debug output
on RS232, you can use the stk500 board together with the raven.
Power:
\li Set the 'EXT/BAT' jumper on the RAVEN board to EXT
\li Attach pin 2 on the bottom strip to GND of your STK500
\li Attach pin 1 on the bottom strip to VTG of your STK500
\li Power the STK500
Debug Connection
\li Attach pin 4 of the leftmost I/O header to pin 'TXD' on your STK500
\li Connect the STK500's "RS232SPARE" port to a RS232 port on a PC
\li Connect a terminal program (e.g. hyper terminal on Windows,
minicom on Linux) to the RS232 port on the PC at 57600 Baud,
with parity 8N1, no flow control
\li The raven board will output debug messages to the terminal
\note To enable specific debugging messages, edit the source
file you are interested in (e.g. core/net/uip-nd6-io.c for
Neighbor Discovery messages debug) and set the macro DEBUG to 1.
Then recompile the code, load the new binary on the board and
restart the RAVEN.
The following image shows this connection, with the red and black
being VCC and GND. The green wire is debug out:
\image html raven_detail.jpg
\note The output to the RS232 converts will only be about
3V, but they are expecting a signal swinging up to VTG, or by
default 5V. You may have to set VTG to 3.3V and power the Raven
from another source, making sure the GNDs of both the STK500
and your external source are connected together.
\subsection advanced_details Understanding the setup
There is no widely available 802.15.4 and 6lowpan stack for PCs.
As a temporary solution and to be able to connect IPv6 hosts
such as RAVEN boards to IP networks, we implemented a "bridge"
function on the RZ USB Stick. The RZ USB stick bridges 802.15.4
packets to Ethernet (The Ethernet interface is emulated on the
USB port).
As Ethernet frames and addresses are very different
from 802.15.4 ones, a few adjustements are needed on addresses
and some neighbor discovery packets. As a consequence, 802.15.4
MAC addresses configured on both the RAVEN boards and the RZ USB
stick must have the format:<br>
\verbatim
x2:xx:xx:ff:fe:xx:xx:xx
\endverbatim
where x can take any hexadecimal value.
Read the section below to change the MAC address on one device.
\subsection advanced_eeprom Change a device MAC address
You can change the MAC address of a RAVEN board or the RZ USB
Stick by setting the 8 first bytes of the EEPROM, following
the convention above. You can do this three ways.
The first is to set EEPROM bytes directly in an AVR Studio project, in
Debug mode
\li compile the binary file for RAVEN, as explained in \ref installation
\li Connect the JTAG pins of the JTAGICE into the JTAG connector of
the target processor.
\li IN AVR Studio, go to File->open, select the binary just created
\li The Debug mode should start
\li Click on View->memory
\li select EEPROM in the menu, then just type in the first 8 bytes
the target MAC address
The second is to reprogram the whole EEPROM individually from the
Flash and Fuses.
\li Connect the JTAG pins of the JTAGICE into the JTAG connector of
the target processor.
\li In AVR Studio, click on "Tools"->"Program AVR"->"Auto Connect"
\li Go to the "Program" tab
\li In the "EEPROM" section, click on "Read" and save the EEPROM
content in a file (in hex format)
\li Edit this file with a text editor, change the value of the
first 8 bytes, save
\li In the "EEPROM" section, check the path to the "Input Hex file"
is the one to the file you just modified and click on "Program".
The third is to modify the default value in the code:
\li Edit the file contiki-raven-main.c in the directory
platform\avr-raven. You will see the MAC address set in a line like:
\code
/* Put default MAC address in EEPROM */
uint8_t mac_address[8] EEMEM = {0x02, 0x11, 0x22, 0xff, 0xfe, 0x33, 0x44, 0x55};
\endcode
\li Change this value, recompile and reprogram the elf on the board.
\subsection advanced_fuses Setting the fuses manually
In case you need to reset the fuses on one AVR, do the following:
\li In AVR Studio, click on "Tools"->"Program AVR"->"Auto Connect"
\li Go to the "Fuses" tab
\li In the lower part of the window, set the EXTENDED,
HIGH, LOW fuses to the following values
\verbatim
0xFF, 0x99, 0xE2 for the ATmega1284P on the RAVEN board
0xFF, 0x99, 0xE2 for the ATmega3290P on the RAVEN board
0xFB, 0x99, 0xDE for the AT90USB1287 on the USB Stick
\endverbatim
\li In the same tab, Click on "Program"
\subsection advanced_capture Observing packets with Atmel Wireless Services or Wireshark
To view packets being sent over the air, you can use Atmel AVR
Wireless Services in Sniffer Mode, with the RZ USB Stick. You need
the software preinstalled on the RZ USB Stick to do this. Packets
are sent on channel 24. Links to detailed information about
AVR Wireless Services is provided with the RZ USB Stick.
See the \ref usbstick documentation for more details about using Wireshark.
\subsection adavanced_linux Programming Flash, Fuses, EEPROM from a Linux machine
One can use avrdude to load the binaries in Linux.
\subsection advanced_hc01 Using HC01 Header Compression Scheme
IETF Internet Draft draft-hui-6lowpan-hc-01 defines a stateful
header compression mechanism (called HC01) which will soon
deprecate the stateless header compression mechanism (called
HC1) defined in RFC4944. HC01 is much more powerfull and flexible,
in particular it allows compression of some multicast addresses
and of all global unicast addresses.
Contiki is compiled by default with HC1 support. To use HC01
instead, edit platform/xxx/contiki-conf.h (replace xxx with avr-raven,
then avr-ravenusb.)
and replace the line<BR>
\code
#define SICSLOWPAN_CONF_COMPRESSION SICSLOWPAN_CONF_COMPRESSION_HC1
\endcode
with
\code
#define SICSLOWPAN_CONF_COMPRESSION SICSLOWPAN_CONF_COMPRESSION_HC01
\endcode
Recompile and load Contiki for both the RAVEN ATmega1284P and RZ USB
Stick.
If you capture packets being sent over the air (on the 802.15.4
network), you will see that much more packets are compressed than
when HC1 is used. Overall, packets sent are much smaller.
\subsection advanced_network Building a more complete network
You can integrate the RAVEN boards and RZ USB stick to a more
complete IPv6 network by connecting the PC which you plug the RZ
USB Stick in to any IPv6 network with correct routing configured.
This way, you will be able to reach the RAVEN boards (to read
sensor data for example) from anywhere within this IPv6 network,
or even any IPv4 network if v4 to v6 translation mechanisms are
used between both networks.
You can also have several RAVEN boards in your setup. If you do so,
be sure to configure different MAC addresses on each board.
<HR>
\subsection issues Known issues
<b>RZ USB Stick Link local address not created on Linux</b><br>
When plugging the RZ USB Stick in a Linux PC, it should
automatically configure a link local address
(fe80::0012:13ff:fe14:1516/64 with default MAC address). On some Linux
distributions, it seems to fail. To check this, in a terminal,
type
\verbatim
ifconfig
\endverbatim
If the interface usb0 does not have an IPv6 address starting
with fe80::, add it manually by typing:
\verbatim
ip -6 address add fe80::0012:13ff:fe14:1516/64 scope link dev usb0
\endverbatim
<b>make version issues</b><br>
You need to use the "make" executable from WinAVR. There
are compilation issues with GNU make coming with Cygwin.
<HR>
\section annex Annex
\subsection annex_contikiDocs Annex - Additional Documentation
\li USB Stick Platform: \ref usbstick
\li User interface on Raven:\ref lcdraven
\li Wireless libraries for Atmel Radio: \ref wireless
\li MAC for Atmel Radio: \ref macdoc
\li IPv6 Implementation: \ref uip6
\li 6lowpan Implementation: \ref sicslowpan
\subsection annex_hardware Annex - Atmel products detailed documentation
<b>RAVEN evaluation and starter kits</b><br>
\li ATAVRRZRAVEN evaluation kit:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4291
\li AVR RAVEN board:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4395
\li RZ USB Stick:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4396
<b>RAVEN AVRs and Wireless transceivers</b><br>
\li ATmega 1284P MegaAVR:
http://www.atmel.com/dyn/products/product_card.asp?part_id=4331
\li ATmega 3290P LCD AVR:
http://www.atmel.com/dyn/products/product_card.asp?part_id=4059
\li AT90USB1287 USB AVR:
http://www.atmel.com/dyn/products/product_card.asp?part_id=3875
\li AT86RF230 802.15.4 Transceiver:
http://www.atmel.com/dyn/products/product_card.asp?part_id=3941
<b>Additional hardware</b><br>
\li ATSTK500 evaluation kit
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735
\li ATEVK1100 evaluation kit
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4114
\li AVR JTAGICE mkII debugging platform
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353
<b>Buying the hardware (part number ATAVRRZRAVEN and ATJTAGICE2)</b><br>
\li For the U.S. you can use http://www.atmel.com/contacts/distributor_check.asp
\li Digikey http://www.digikey.com/
\li Spoerle http://www.spoerle.com/en/products
\li Lawicel http://www.lawicel-shop.se
\subsection annex_software Software setup details
<b>Contiki</b><br>
Download Contiki code from http://www.sics.se/contiki and
extract the source code. We assume the directory you extract
to is c:/contiki.
<b>Cygwin</b><br>
\li Download Cygwin from http://www.cygwin.com
\li Launch the setup executable
\li Follow the instructions until you reach the Window "Cygwin
Setup - Select Packages"
\li In this window, expand the "Devel" item and
<b>AVR Studio</b><br>
Download and install AVR Studio from
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725
<b>WinAVR</b><br>
WinAVR which contains a number of AVR tools
such as the avr-gcc compiler.
Download and install WinAVR latest version from
http://winavr.sourceforge.net/
<b>JTAGICE mkII Drivers</b><br>
Plug the JTAGICE mkII in a USB port of a windows PC. Follow the
indications to install the Windows drivers automatically.
*/
/** @} */
/** @} */

7
doc/tutorials.txt Normal file
View file

@ -0,0 +1,7 @@
/**
* \defgroup tutorials Tutorials
* @{
This module contains all Contiki related tutorials.
*/
/** @} */

3
doc/uip-doc.txt
View file

@ -3,8 +3,6 @@
@{ @{
*/ */
/** /**
\defgroup uip The uIP TCP/IP stack \defgroup uip The uIP TCP/IP stack
@{ @{
@ -25,6 +23,7 @@ low as a few hundred bytes.
uIP can be found at the uIP web page: http://www.sics.se/~adam/uip/ uIP can be found at the uIP web page: http://www.sics.se/~adam/uip/
\sa \ref tcpip \sa \ref tcpip
\sa \ref uip6 and sicslowpan
\sa \ref uipopt "uIP Compile-time configuration options" \sa \ref uipopt "uIP Compile-time configuration options"
\sa \ref uipconffunc "uIP Run-time configuration functions" \sa \ref uipconffunc "uIP Run-time configuration functions"
\sa \ref uipinit "uIP initialization functions" \sa \ref uipinit "uIP initialization functions"

383
doc/uip6-doc.txt Normal file
View file

@ -0,0 +1,383 @@
/**
\addtogroup uip
@{
*/
/**
* \defgroup uip6 uIP IPv6 specific features
* @{
The uIP IPv6 stack provides new Internet communication abilities to Contiki.
This document describes Ipv6 specific features. For features that
are common to the IPv4 and IPv6 code please refer to \ref uip "uIP".
<HR>
\section intro Introduction
Ipv6 is to replace IPv4 in a near future. Indeed, to move to a real
<em> Internet of Things </em> a larger address space is required. This extended
address space (2^128 instead of 2^32) is one of the key features of
IPv6 together with its simplified header format, its improved support
for extensions and options, and its new QoS and security capabilities.
The uip IPv6 stack implementation targets constrained devices such as
sensors. The code size is around 11.5Kbyte and the RAM usage around
1.7Kbyte (see \ref size "below" for more detailed information).
Our implementation follows closely RFC 4294 <em>IPv6 Node Requirements</em>
whose goal is to allow "IPv6 to function well and
interoperate in a large number of situations and deployments".
The implementation currently does not support any router features (it does not forward packets, send RAs...)
<HR>
\section protocol IPv6 Protocol Implementation
This section gives a short overview of the different protocols that
are part of the uIP IPv6 stack. A complete description can be found in the
corresponding IETF standards which are available at
http://www.ietf.org/rfc.html.
\note The #UIP_CONF_IPV6 compilation flag is used to enable IPv6 (and
disable IPv4). It is also recommended to set #UIP_CONF_IPV6_CHECKS to
1 if one cannot guarantee that the incoming packets are correctly formed.
\subsection ipv6 IPv6 (RFC 2460)
The IP packets are processed in the #uip_process function.
After a few validity checks on the IPv6 header, the extension headers
are processed until an upper layer (ICMPv6, UDP or TCP) header is found.
We support 4 extension headers:
\li Hop-by-Hop Options: this header is used to carry optional
information that need to be examined only by a packet's destination node.
\li Routing: this header is used by an IPv6 source to list one or more
intermediate nodes to be "visited" on the way to a packet's destination.
\li Fragment: this header is used when a large packet is divided into
smaller fragments.
\li Destination Options: this header is used to carry optional
information that need be examined only by a packet's destination node
The Authentication and ESP headers are not currently supported.
The IPv6 header, extension headers, and options are defined in uip.h.
Although we can receive packets with the extension headers listed
above, we do not offer support to send packets with extension headers.
<b>Fragment Reassembly</b><br>
This part of the code is very similar to the \ref ipreass "IPv4 fragmentation code". The only difference is that the fragmented packet
is not assumed to be a TCP packet. As a result, we use a different
%timer to time-out reassembly if all fragments have not been received
after #UIP_REASS_MAXAGE = 60s.
\note Fragment reassembly is enabled if #UIP_CONF_REASSEMBLY is set to 1.
\note We can only reassemble packet of at most #UIP_LINK_MTU = 1280
bytes as we do not have larger buffers.
\subsection address Interface and Addressing (RFC 4291, RFC 4861 p.51, RFC 4862 p.10)
An IPv6 address has 128 bits and is defined as follows:
\code
typedef union uip_ip6addr_t {
u8_t u8[16]
u16_t u16[8];
} uip_ip6addr_t;
\endcode
We assume that each node has a <em>single interface</em> of type
#uip_netif.
Each interface can have up to #UIP_NETIF_MAX_ADDRESSES unicast IPv6
addresses including its link-local address. It also has a
solicited-node multicast address. We assume that the unicast
addresses are obtained via \ref autoconf "stateless address autoconfiguration"
so that the solicited-node address is the same for all the
unicast addresses. Indeed, the solicited-node multicast address
is formed by combining the prefix FF02::1:FF00:0/104 and the
last 24-bits of the corresponding IPv6 address. When using stateless address
autoconfiguration these bits are always equal to the last 24-bits of
the link-layer address.
\subsection multicast Multicast support
We do not support applications using multicast. Nevertheless, our node
should join the all-nodes multicast address, as well as its solicited-node
multicast address. Joining the all-nodes multicast address does not
require any action. Joining the solicited-node multicast address is
done using Multicast Listener Discovery (MLD or MLDv2). More exactly,
the node should send a MLD report packet. However this step can be
safely skipped and we do so.
\subsection nd Neighbor Discovery (RFC 4861)
"IPv6 nodes on the same link use Neighbor Discovery to discover each
other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the paths
to active neighbors" (citation from the abstract of RFC
4861).
\note In IPv6 terminology, a \em link is a communication medium over
which nodes can communicate at the link layer, i.e., the layer
immediately below IP (e.g.: ethernet, 802.11, etc.). Neighbors are
thus nodes attached to the same link.
Neighbor Discovery (ND) replaces ARP in IPv4 but does much
more.
<b>Neighbor discovery messages </b><br>
\li Neighbor Solicitation (NS)\n
Sent by a node during duplicate address detection, address resolution or
%neighbor unreachability detection (see explanations below).\n
Possible option: Source link-layer address
\li Neighbor Advertisement (NA)\n
Sent by a node in response to a NS.\n
Possible option: Target link-layer address
\li Router Advertisement (RA)\n
Sent periodically by routers to advertise their presence together with
various link and Internet parameters.\n
Possible options: Source link-layer address, MTU, Prefix Information
\li Router Solicitation (RS)\n
Sent by a host to request routers to generate a RA immediately rather
than at their next scheduled time. Received RS are discarded.\n
Possible option: Source link-layer address
\li Redirect Message\n
Not supported
The structures corresponding to the different message headers and
options are in uip-nd6.h. The functions used to send / %process this
messages are also described in uip-nd6.h although the actual code is in
uip-nd6-io.c.
<b>Neighbor discovery structures </b><br>
We use the following %neighbor discovery structures (declared in uip-nd6.c):
\li A <em>%neighbor cache</em> with entries of type #uip_nd6_neighbor
\li A <em>prefix list</em> with entries of type #uip_nd6_prefix
\li A <em>default router list</em> with entries of type #uip_nd6_defrouter
Each of this structure has its own add, remove and lookup
functions. To update an entry in a ND structure, we first do a lookup
to obtain a pointer to the entry, we then directly modify the
different entry fields.
<b>Neighbor discovery processes </b><br>
\li Address resolution\n
Determine the link-layer address of a %neighbor given its IPv6 address.\n
-> send a NS (done in #tcpip_ipv6_output).
\li Neighbor unreachability detection\n
Verify that a neighbor is still reachable via a cached link-layer
address.\n
-> send a NS (done in #uip_nd6_periodic).
\li Next-hop determination\n
Map an IPv6 destination address into the IPv6 address of the %neighbor
to which traffic for the destination should be sent.\n
-> look at on-link prefixes, if the destination is not on-link,
choose a default router, else send directly (done in #tcpip_ipv6_output).
\li Router, prefix, and parameter discovery\n
Update the list of default routers, on-link prefixes, and the network
parameters.\n
-> receive a RA (see #uip_nd6_io_ra_input).
\subsection autoconf Stateless Address Autoconfiguration (RFC 4862)
RFC 4862 defines two main processes:
\li Duplicate Address Detection (DAD)\n
Make sure that an address the node wished to use is not already in use
by another node.\n
-> send a NS (done in #uip_netif_dad)
\li Address Autoconfiguration\n
Configure an address for an interface by combining a received prefix
and the interface ID (see #uip_netif_addr_add). The interface ID is
obtained from the link-layer address using #uip_netif_get_interface_id.\n
-> Receive a RA with a prefix information option that has the
autonomous flag set.
When an interface becomes active, its link-local address is created
by combining the FE80::0/64 prefix and the interface ID. DAD is then
performed for this link-local address. Available routers are
discovered by sending up to #UIP_ND6_MAX_RTR_SOLICITATIONS RS
packets. Address autoconfiguration is then performed based on the
prefix information received in the RA. The interface initialization is
performed in #uip_netif_init.
\subsection icmpv6 ICMPv6 (RFC 4443)
We support ICMPv6 Error messages as well as Echo Reply and Echo Request
messages. The application used for sending Echo Requests (see ping6.c)
is not part of the IP stack.
\note RFC 4443 stipulates that 'Every ICMPv6 error message MUST
include as much of the IPv6 offending (invoking) packet as
possible'. In a constrained environment this is not very resource
friendly.
The ICMPv6 message headers and constants are defined in uip-icmp6.h.
<HR>
\section timers IPv6 Timers and Processes
The IPv6 stack (like the IPv4 stack) is a Contiki process
\code
PROCESS(tcpip_process, "TCP/IP stack");
\endcode
In addition to the \ref mainloop "periodic timer" that is used by TCP,
five IPv6 specific timers are attached to this %process:
\li The #uip_nd6_timer_periodic is used for periodic checking of the
%neighbor discovery structures.
\li The #uip_netif_timer_dad is used to properly paced the Neighbor
Solicitation packets sent for Duplicate Address Detection.
\li The #uip_netif_timer_rs is use to delay the sending of Router Solicitations
packets in particular during the router discovery %process.
\li The #uip_netif_timer_periodic is used to periodically check the
validity of the addresses attached to the network interface.
\li The #uip_reass_timer is used to time-out the fragment reassembly
%process.
\n
Both #uip_nd6_timer_periodic and #uip_netif_timer_periodic run continuously.
This could be avoided by using callback timers to handle ND and Netif structures timeouts.
<HR>
\section compileflags Compile time flags and variables
This section just lists all IPv6 related compile time flags. Each flag
function is documented in this page in the appropriate section.
\code
/*Boolean flags*/
UIP_CONF_IPV6
UIP_CONF_IPV6_CHECKS
UIP_CONF_IPV6_QUEUE_PKT
UIP_CONF_IPV6_REASSEMBLY
/*Integer flags*/
UIP_NETIF_MAX_ADDRESSES
UIP_ND6_MAX_PREFIXES
UIP_ND6_MAX_NEIGHBORS
UIP_ND6_MAX_DEFROUTER
\endcode
<HR>
\section buffers IPv6 Buffers
The IPv6 code uses the same \ref memory "single global buffer" as the
IPv4 code. This buffer should be large enough to contain one
packet of maximum size, i.e., #UIP_LINK_MTU = 1280 bytes. When \ref
reass "fragment reassembly" is enabled an additional buffer of the
same size is used.
The only difference with the IPv4 code is the per %neighbor buffering
that is available when #UIP_CONF_QUEUE_PKT is set to 1. This
additional buffering is used to queue one packet per %neighbor while
performing address resolution for it. This is a very costly feature as
it increases the RAM usage by approximately #UIP_ND6_MAX_NEIGHBORS *
#UIP_LINK_MTU bytes.
<HR>
\section size IPv6 Code Size
\note We used Atmel's RAVEN boards with the Atmega1284P MCU (128Kbyte
of flash and 16Kbyte of SRAM) to benchmark
our code. These numbers are obtained using 'avr-gcc 4.2.2 (WinAVR
20071221)'. Elf is the output format.
\note The following compilation flags were used:
\code
UIP_CONF_IPV6 1
UIP_CONF_IPV6_CHECKS 1
UIP_CONF_IPV6_QUEUE_PKT 0
UIP_CONF_IPV6_REASSEMBLY 0
UIP_NETIF_MAX_ADDRESSES 3
UIP_ND6_MAX_PREFIXES 3
UIP_ND6_MAX_NEIGHBORS 4
UIP_ND6_MAX_DEFROUTER 2
\endcode
The total IPv6 code size is approximately 11.5Kbyte and the RAM usage around
1.8Kbyte. For an additional NEIGHBOR count 35bytes, 25 for an additional
PREFIX, 7 for an additional DEFROUTER, and 25 for an additional ADDRESS.
<HR>
\section l2 IPv6 Link Layer dependencies
The IPv6 stack can potentially run on very different link layers
(ethernet, 802.15.4, 802.11, etc).
The link-layer influences the following IP layer objects:
\li #uip_lladdr_t, the link-layer address type, and its length,
#UIP_LLADDR_LEN.
\code
struct uip_eth_addr {
u8_t addr[6];
};
typedef struct uip_eth_addr uip_lladdr_t;
#define UIP_LLADDR_LEN 6
\endcode
\li #uip_lladdr, the link-layer address of the node.
\code
uip_lladdr_t uip_lladdr = {{0x00,0x06,0x98,0x00,0x02,0x32}};
\endcode
\li #UIP_ND6_OPT_LLAO_LEN, the length of the link-layer option in the
different ND messages
Moreover, #tcpip_output should point to the
link-layer function used to send a packet. Similarly, the link-layer
should call #tcpip_input when an IP packet is received.
The code corresponding to the desired link layer is selected at
compilation time (see for example the #UIP_LL_802154 flag).
<HR>
\section l45 IPv6 interaction with upper layers
The TCP and the UDP protocol are part of the \ref uip "uIP" stack and were left
unchanged by the IPv6 implementation.
For the application layer, please refer to the \ref api "application program interface".
<HR>
\section compliance IPv6 compliance
\subsection rfc4294 IPv6 Node Requirements, RFC4294
This section describes which parts of RFC4294 we are compliant with. For each section, we put between brackets the requirement level.\n
When all IPv6 related compile flags are set, our stack is fully compliant with RFC4294 (i.e. we implemement all the MUSTs), except for MLD support and redirect function support.\n
\note RFC4294 is currently being updated by IETF 6man WG. One of the important points for us in the update is that after discussion on the 6man mailing list, IPSec support will become a SHOULD (was a MUST).\n
<b>Sub IP layer</b><br>
We support RFC2464 transmission of IPv6 packets over Ethernet\n
We will soon support RFC4944 transmission of IPv6 packets over 802.15.4\n
<b>IP layer</b><br>
\li IPv6 RFC2460 (MUST): When the compile flags UIP_CONF_IPV6_CHECKS and UIP_CONF_REASSEMBLY are set, full support
\li Neighbor Discovery RFC4861 (MUST): When the UIP_CONF_CHECKS and UIP_CONF_QUEUE_PKT flag are set, full support except redirect function
\li Address Autoconfiguration RFC4862 (MUST): When the UIP_CONF_CHECKS flag is set, full support except sending MLD report (see MLD)
\li Path MTU Discovery RFC 1981 (SHOULD): no support
\li Jumbograms RFC 2675 (MAY): no support
\li ICMPv6 RFC 4443 (MUST): full support
\li IPv6 addressing architecture RFC 3513 (MUST): full support
\li Privacy extensions for address autoconfiguration RFC 3041 (SHOULD): no support.
\li Default Address Selection RFC 3484 (MUST): full support.
\li MLDv1 (RFC 2710) and MLDv2 (RFC 3810) (conditional MUST applying here): no support. As we run IPv6 over Multicast or broadcast capable links (Ethernet or 802.15.4), the conditional MUST applies. We should be able to send an MLD report when joining a solicited node multicast group at address configuration time. This will be available in a later release.
<b>DNS (RFC 1034, 1035, 3152, 3363, 3596) and DHCPv6 (RFC 3315) (conditional MUST)</b><br>
no support
<b>IPv4 Transition mechanisms RFC 4213 (conditional MUST)</b><br>
no support
<b>Mobile IP RFC 3775 (MAY / SHOULD)</b><br>
no support
<b>IPSec RFC 4301 4302 4303 2410 2404 2451 3602(MUSTs) 4305 (SHOULD)</b><br>
no support
<b>SNMP (MAY)</b><br>
no support
\subsection ipv6ready IPv6 certification through ipv6ready alliance
IPv6ready is the certification authority for IPv6 implementations (http://www.ipv6ready.org). It delivers two certificates (phase 1 and phase 2).\n
When all the IPv6 related compile flags are set, we pass all the tests for phase 1.\n
We pass all the tests for phase 2 except:
\li the tests related to the redirect function
\li the tests related to PMTU discovery
\li test v6LC1.3.2C: A "bug" in the test suite (fragmentation states are not deleted after test v6LC1.3.2B) makes us fail this test unless we run it individually.
\li 5.1.3: UDP port unreachable (the UDP message is too large for our implementation and the UDP code does not send any ICMP error message)
<HR>
*/
/** @} */
/** @} */