Analysis and Integration of IEEE Networks on Linux

Size: px

Start display at page:

Download "Analysis and Integration of IEEE Networks on Linux"

Jonathan Martin
5 years ago
Views:

1 Analysis and Integration of IEEE Networks on Linux Rahul Jain Computer Science Jacobs University Bremen Campus Ring Bremen Germany Type: Guided Research Report Date: May 15, 2009 Supervisor: Prof. Dr. Jürgen Schönwälder Executive Summary IEEE promises network flexibility, low cost and low power consumption. It is ideal for many applications at home requiring low-data-rate communications in an ad-hoc network. Existing wireless solutions ( and Bluetooth) are both overly complex compared to and not suited for the purpose of home automation and industrial control - two application fields where IEEE is expected to have a major impact. However, the lack of a standalone networking Linux stack for IEEE has impeded its growth and acceptance on the platform. This is detrimental to the advancement of the technology as Linux holds a considerable share in embedded devices - IEEE capable hardware is usually found on embedded devices. 6LoWPAN, however, by enabling the transmission of IPv6 packets over makes it easier for Linux to interact with networks. However, there again is no native 6LoWPAN stack for Linux. This project looks at an existing way of integrating networks with Linux by carrying out 6LoWPAN outside the kernel space. The resulting network is then analyzed in detail. The possibility of integrating 6LoWPAN and IEEE within the Linux kernel is also looked into. This would facilitate integration of IEEE networks with Linux.

2 Contents 1 Overview 3 2 Technical Background Hardware IEEE Data Link Layer General MAC Frame Format Ethernet II IPv ICMPv LoWPAN HC01 Compression The Contiki Operating System Implementation Software Requirements and Setup Network Architecture Transmitting and Receiving Packets Analysis 15 5 Development Ideas Native Linux Support LoWPAN and Wireshark Conclusion 18 2

3 1 Overview There have been several attempts to network the home environment through proprietary solutions, and through standards such as HomePNA, the Homeplug Powerline Alliance, CEA R-7, HomeRF, and Echonet. The approaches to achieve this goal fall into two broad categories: wired and wireless. Telephone lines, cable modems and power line carriers have player a stellar role in the wired arena. Wireless technologies however have the advantage of avoiding installation cost, since no new wiring is needed. In addition, the wider availability of cheaper and highly integrated wireless components and the success of other wireless communication technologies such as cellular and Wi-Fi and IEEE b has significantly contributed towards the rise in popularity of wireless solutions. With the explosive growth of the Internet, the major focus to date has been in satisfying the need for shared high-speed connectivity. Applications such as home automation, security, and gaming on the other hand have relaxed throughput requirements.these applications cannot handle the complexity of heavy protocol stacks that impact power consumption and utilize too many computational resources. Thus, the need for a standard with ultra-low complexity, cost, and power for low-data-rate wireless connectivity among inexpensive fixed, portable, and moving devices. IEEE [1] was the answer to this problem. With IEEE , the emphasis is on very low cost communication of nearby devices. The vast majority of applications will therefore require the use of embedded devices. Linux is an open source operating system and has been gathering steam on embedded platforms recently. While integration of IEEE networks with Windows has already been achieved, the same can not be said for Linux. Efforts within the open source community are also currently at a standstill [2]. The need for the Linux integration of IEEE networks is therefore paramount. However, it is still possible to use Linux as the master controller for applications that employ IEEE The master controller is responsible for data acquisition and for communicating with other systems. There are many industrial controllers / data acquisition systems that use Linux as the operating system. By keeping the actual IEEE implementation outside of kernel space it is possible to integrate IEEE networks with Linux. The easy availability of a wide variety of network tools for Linux makes it easier to analyze and study these networks and work towards their integration with Linux. 3

2 Technical Background This section describes the hardware used for the project. Furthermore, it introduces standards (IEEE 802.15.

4 2 Technical Background This section describes the hardware used for the project. Furthermore, it introduces standards (IEEE and 6LoWPAN) that are inherent to the project and also introduces the software used in the project (Contiki and Wireshark). Details of the standards that are relevant to the project are also described herein. 2.1 Hardware The hardware platform chosen for this project is the Atmel Raven (ATAVR- RZRAVEN) 2.4 GHz Evaluation and Starter Kit. The RZRAVEN 2.4 GHz Evaluation and Starter kit enables development, debugging and demonstration of a wide range of low power wireless applications including IEEE , 6LoWPAN and ZigBee networks.the RZRAVEN kit comprises two AVR Raven boards (AVRRAVEN) with 2.4 GHz transceiver, on board picopower AVR application processors and LCD display, and one USB stick (AVRRZUSBSTICK) with a 2.4 GHz transceiver for USB connection to a computer. Figure 1: Atmel Raven Kit AVR JTAGICE mkii was used to program the Raven USB stick and the two Raven boards.the JTAGICE mkii supports devices with debugwire Interface. debugwire enables on-chip debug of AVR micro controllers in small pin count packages, using only a single wire for the debug interface. 4

Figure 2: AVR JTAGICE mkii 2.2 IEEE 802.15.4 IEEE 802.15.4 [1] is the standard which specifies the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs).

The standard uses carrier sense multiple access with collision avoidance (CSMA-CA) medium access mechanism and supports star as well as peer-to-peer topologies.

5 Figure 2: AVR JTAGICE mkii 2.2 IEEE IEEE [1] is the standard which specifies the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). This standard defines the protocol and interconnection of devices via radio communication in a personal area network (PAN). The standard uses carrier sense multiple access with collision avoidance (CSMA-CA) medium access mechanism and supports star as well as peer-to-peer topologies. Figure 3 presents a high level overview of IEEE The media access is Figure 3: Summary of high-level characteristics (IEEE ) contention based; however, using the optional superframe structure, time slots can be allocated by the PAN coordinator to devices with time critical data. Connectivity to higher performance networks is provided through a PAN coordinator. 5

2.2.1 Data Link Layer The IEEE 802 project [3] splits the data link layer (DLL) into two sublayers, the MAC and logical link control (LLC) sublayers. The LLC is standardized in 802.

6 2.2.1 Data Link Layer The IEEE 802 project [3] splits the data link layer (DLL) into two sublayers, the MAC and logical link control (LLC) sublayers. The LLC is standardized in and is common among the 802 standards such as 802.3, , and , while the MAC sublayer is closer to the hardware and may vary with the physical layer implementation. Figure 4 shows how IEEE fits into the International Organization for Standardization (ISO) open systems interconnection (OSI) reference model. Figure 4: IEEE in the ISO-OSI layered network model General MAC Frame Format The MAC frame structure is kept very flexible to accommodate the needs of different applications and network topologies while maintaining a simple protocol. The general format of a MAC frame is shown in Figure 5. The MAC frame is called the MAC protocol data unit (MPDU) and is composed of the MAC header (MHR), MAC service data unit (MSDU), and MAC footer (MFR). The first field of the MAC header is the frame control field. It indicates the type of MAC frame being transmitted, specifies the format of the address field, and controls the acknowledgment. In short, the frame control field specifies how the rest of the frame looks and what it contains. The size of the address field may vary between 0 and 20 bytes. For instance, a data frame may contain both source and destination information, while 6

Figure 5: The general MAC frame format the return acknowledgment frame does not contain any address information at all. On the other hand, a beacon frame may only contain source address information.

7 Figure 5: The general MAC frame format the return acknowledgment frame does not contain any address information at all. On the other hand, a beacon frame may only contain source address information. In addition, short 8-bit device addresses or 64-bit IEEE device addresses may be used. This flexible structure helps increase the efficiency of the protocol by keeping the packets short. The payload field is variable in length; however, the complete MAC frame may not exceed 127 bytes in length. The data contained in the payload is dependent on the frame type. The IEEE MAC has four different frame types. These are the beacon frame, data frame, acknowledgment frame, and MAC command frame. Only the data and beacon frames actually contain information sent by higher layers; the acknowledgment and MAC command frames originate in the MAC and are used for MAC peer-to-peer communication. Other fields in a MAC frame are the sequence number and frame check sequence (FCS). The sequence number in the MAC header matches the acknowledgment frame with the previous transmission. The transaction is considered successful only when the acknowledgment frame contains the same sequence number as the previously transmitted frame. The FCS helps verify the integrity of the MAC frame. The FCS in an IEEE MAC frame is a 16-bit International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) cyclic redundancy check (CRC). 2.3 Ethernet II Ethernet II framing (also known as DIX Ethernet, named after the major participants in the framing of the protocol: DEC, Intel and Xerox) defines the two-octet EtherType field in an Ethernet frame, preceded by destination 7

and source MAC addresses, that identifies an upper layer protocol encapsulated within the frame data. Figure 6 below shows the frame format. Figure 6: The most common Ethernet Frame format, type II 2.

8 and source MAC addresses, that identifies an upper layer protocol encapsulated within the frame data. Figure 6 below shows the frame format. Figure 6: The most common Ethernet Frame format, type II 2.4 IPv6 Internet Protocol version 6 (IPv6 [4]) is the next-generation Internet Layer protocol for packet-switched internetworks and the Internet. Below is the header format for IPv Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address Figure: IPv6 Header Format 8

9 2.5 ICMPv6 The Internet Control Message Protocol Version 6 (ICMPv6 [5]) is a new version of the ICM protocol that forms an integral part of the Internet Protocol version 6 (IPv6) architecture. ICMPv6 messages are transported within an IPv6 packet that may include IPv6 extension headers. ICMPv6 packets have the format Type, Code & Checksum. The 8-bit Type field indicates the type of the message. If the high-order bit has value zero (values in the range from 0 to 127), it is an error message; if the high-order bit has value 1 (values in the range from 128 to 255), it is an information message. The 8-bit Code field content depends on the message type, and it is used to create an additional level of message granularity. The Checksum field is used to detect errors in the ICMP message and in part of the IPv6 message. Below is the header format Type Code Checksum Message Body Figure: ICMPv6 Header Format 2.6 6LoWPAN 6LoWPAN [6, 7] is a protocol definition to enable IPv6 [4] packets to be carried on top of low power wireless networks, specifically IEEE It takes the concepts used in IPv6 to create a set of headers that allow for the efficient encoding of large IPv6 addresses/headers into a smaller compressed header, while at the same time allowing for the use of various mesh networks and supporting fragmentation and reassembly where needed HC01 Compression Dispatch type value of 0x03 indicates LOWPAN IHPC compression. LOW- PAN IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero; Payload Length can be inferred from lower layers from either the 6LoWPAN 9

10 Fragmentation header or the IEEE header; Hop Limit will be set to a well-known value by the source; addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a single routable prefix assigned to the entire 6LoWPAN network; addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or 16-bit short IEEE addresses.[8] LOWPAN_IPHC Uncompressed fields follow Figure: LOWPAN_IPHC Header The LOWPAN IPHC Encoding Format is given below: T VF NH HLIM rsv SAM SAC DAM DAC Figure: LOWPAN_IPHC Encoding T: Traffic Class (bit 0): 0: Full 8 bits for Traffic Class are carried in-line. 1: Traffic Class is elided and implicitly 0. VF: Version and Flow Label (bit 1): 0: Full 4 bits for Version and 20 bits for Flow Label are carried in-line. 1: Version and Flow Label are elided. Version is implicitly 6. Traffic Class and Flow Label are implicitly 0. NH: Next Hop (bit 2): 0: Full 8 bits for Next Hop are carried in-line. 1: Next Hop is elided and the next header is compressed using LOWPAN_NHC. HLIM: Hop Limit (bits 3-4): 00: All 8 bits of Hop Limit are carried in-line. 01: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be 1. 10: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be

11 11: All 8 bits of Hop Limit are elided and the Hop Limit is assumed to be 255. rsv: Reserved (bit 5-7) SAC: Source Address Mode (bits 8-9): 00: All 128 bits of Source Address are carried in-line. 01: 64-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address. 11: All 128 bits of Source Address are elided. SAC: Source Address Context (bits 10-11): Identifies the compression context when the source address is compressed. The value 00 is reserved and indicates a link-local address. DAM: Destination Address Mode (bits 12-13): 00: All 128 bits of Destination Address are carried in-line. 01: 64-bit Compressed IPv6 address. 10: 16-bit Compressed IPv6 address. 11: All 128 bits of Destination Address are elided. DAC: Destination Address Context (bits 14-15): Identifies the compression context when the destination address is compressed. The value 00 is reserved and indicates a link-local address. 2.7 The Contiki Operating System Contiki [9] is an open source, highly portable, multi-tasking operating system for memory-efficient networked embedded systems and wireless sensor networks. Contiki is designed for micro controllers with small amounts of memory. Contiki s implementation of 6LoWPAN is based on RFC4944 Transmission of IPv6 Packets over IEEE Networks, draft-hui-6lowpaninterop-00 Interoperability Test for 6LoWPAN, and draft-hui-6lowpan-hc-01 Compression format for IPv6 datagrams in 6LoWPAN Networks. The current project implements the HC01 compression scheme, which was described earlier. 11

12 3 Implementation This section describes the steps taken to run Contiki with IPv6 and 6LoW- PAN support on the Atmel Raven evaluation kit with a Linux based PC acting as the IPv6 router. The steps followed are detailed in the online Contiki Tutorial.[10] 3.1 Software Requirements and Setup Below is a list of perquisites that needed to be satisfied before proceeding with the project. Atmel AVR Raven Contiki binary release which contains the needed binaries (webserver6.elf, ravenlcd 3290.elf and ravenusbstick.elf). PC running Linux with kernel or later, with support for the following kernel modules: IPv6, usbnet, cdc ether, cdc acm, rndis wlan. An IPv6 router daemon running on the host PC. The project uses radvd as the router daemon and the configuration file for the same is given below. interface usb0 { AdvSendAdvert on; AdvLinkMTU 1280; AdvCurHopLimit 128; AdvReachableTime ; MinRtrAdvInterval 100; MaxRtrAdvInterval 150; AdvDefaultLifetime 200; prefix AAAA::/64 { AdvOnLink on; AdvAutonomous on; AdvPreferredLifetime ; AdvValidLifetime ; }; }; AVR Studio or later to program the RZ Raven USB stick and the Raven boards. AVR studio is a Windows only sofware. Wireshark or later to analyze the IEEE traffic. 12

13 The Raven board ATmega1284P was flashed with the binary webserver6.elf, Raven board ATmega3290P with the binary ravenlcd 3290.elf and the RZ Raven USB stick with the binary ravenusbstick.elf using the JTAG interface. 3.2 Network Architecture In Contiki phraseology, the RZ Raven USB stick flashed with the binary ravenusbstick is termed as Jackdaw.[11] On plugging the jackdaw, the Linux kernel immediately recognizes it. Below is the output of the command dmesg when the Jackdaw is plugged in. [ ] usb 2-2: new full speed USB device using uhci_hcd and address 2 [ ] usb 2-2: configuration #1 chosen from 1 choice [ ] cdc_acm 2-2:1.2: ttyacm0: USB ACM device [ ] usbcore: registered new interface driver cdc_acm [ ] cdc_acm: v0.26:usb Abstract Control Model driver for USB modems and ISDN adapters [ ] usbcore: registered new interface driver cdc_ether [ ] rndis_host 2-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.1-2, RNDIS device, 02:12:13:14:15:16 [ ] usbcore: registered new interface driver rndis_host [ ] usbcore: registered new interface driver rndis_wlan Furthermore, a USB networking interface named usb0 is created. Then the networking interface is assigned a IPv6 global address of aaaa::1/64. The router advertisement daemon is started on the host computer and the raven board is subsequently booted up. It then configures an IPv6 address based on the router advertisements. Figure 6 below shows a schematic representation of the connection scheme. The dotted line indicates a wireless connection while the straight line indicates a physical USB connection. The MAC and IPv6 addresses of both the RZ Raven USB stick and the Raven board are shown as well. In addition, the complete details of the usb0 networking interface are listed below. usb0 Link encap:ethernet HWaddr 02:12:13:14:15:16 inet6 addr: 2001:4978:1db:1::1/64 Scope:Global inet6 addr: fe80::12:13ff:fe14:1516/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1280 Metric:1 RX packets:70 errors:54 dropped:0 overruns:0 frame:54 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4581 (4.5 KB) TX bytes:5868 (5.8 KB) 13

Figure 7: Schematic Representation of the setup 3.3 Transmitting and Receiving Packets Figure 8: Wireshark Capture There is no widely available 802.15.

As a temporary solution and to be able to connect IPv6 hosts such as Raven boards to IP networks, a bridge function is implemented on the RZ USB Stick.

14 Figure 7: Schematic Representation of the setup 3.3 Transmitting and Receiving Packets Figure 8: Wireshark Capture There is no widely available and 6lowpan stack for PCs. As a temporary solution and to be able to connect IPv6 hosts such as Raven boards to IP networks, a bridge function is implemented on the RZ USB Stick. The RZ USB stick bridges packets to Ethernet (The Ethernet interface is emulated on the USB port). It is possible to ping the RZ Raven USB stick from the board (by pressing the joystick on the board to the right twice) and vice versa (via the computer - ping6 -c 5 aaaa::11:22ff:fe33:4455. The above trace is captured via wireshark. The screenshot above captures 14

15 the frames. 4 Analysis Wireshark is again used to analyze the packets that are transmitted over the network. The packets from the radio network are IPv6 over , and use 6LoWPAN header compression and fragmentation for large packets. The USB stick decompresses, reassembles, bridges to Ethernet, and sends to the PC stack. The other way, the PC stack sends to the USB stick, it bridges, compresses and fragments, and then sends on to the radio. Evidence of this can be found by looking at the packet traces. Following packets are transmitted over the network when an Echo message is sent to the RZ Raven USB stick from the Raven board fe80::11:22ff:fe33:4455 fe80::12:13ff:fe14:1516 ICMPv6 Echo request fe80::12:13ff:fe14:1516 fe80::11:22ff:fe33:4455 ICMPv6 Echo reply :12:13:ff:fe:14:15:16 02:11:22:ff:fe:33:44:55 IEEE Data, Dst: 02:11:22:ff:fe:33:44:55, Src: 02:12:13:ff:fe:14:15:16, Bad FCS :11:22:ff:fe:33:44:55 02:12:13:ff:fe:14:15:16 IEEE Data, Dst: 02:12:13:ff:fe:14:15:16, Src: 02:11:22:ff:fe:33:44:55 Comparing it to the sequence of packets when a ping message is sent to the Raven Board from the PC router aaaa::11:22ff:fe33:4455 aaaa::1 ICMPv6 Echo reply aaaa::1 aaaa::11:22ff:fe33:4455 ICMPv6 Echo request :12:13:ff:fe:14:15:16 02:11:22:ff:fe:33:44:55 IEEE Data, Dst: 02:11:22:ff:fe:33:44:55, Src: 02:12:13:ff:fe:14:15:16, Bad FCS :11:22:ff:fe:33:44:55 02:12:13:ff:fe:14:15:16 IEEE Data, Dst: 02:12:13:ff:fe:14:15:16, Src: 02:11:22:ff:fe:33:44:55 Comapring the above two streams, we can infer that a message from the Raven board is termed as Echo Request whereas a message from the RZ Raven USB is termed as Echo Reply. It is also clear that in both the cases, the frame generated over the RZ Raven and then bridged over to the Ethernet is detected first and then the frame from the Raven board. Armed with the knowledge about the various Internet Protocols, the following IEEE packet will be decoded. The stream also confirms that the inference about the IP and MAC addresses made earlier was correct a 01 cb af ff ff ff ff cd ab fe ff

16 0020 d8 c8 3a a ff c e..: ~ c0 ff ff ff ff ff ff ff 0040 ff aa aa ff fe The decoding of the packet is as follows: First 14 bytes: Ethernet Pseudo Header Destination MAC Address: 33:33:00:00:00:01 [Raven Board] Source MAC Address: 02:12:13:14:15:16 [RZ Raven USB] Packet Checksum: 0x809a Header Frame Control Field: 0x01cb [Reversed, correct value: 0xcb01] Sequence Number: 0xaf Destination PAN: 0xffff Destination Address: 0xffff [Broadcast] Source PAN: 0xcdab [Reversed, correct value: 0xabcd] Source Address: 0x161514feff [Reversed: 02:12:13:ff:fe:14:15:16 => RZ USB] 6LoWPAN [as specified in HC01] Dispatch Type: 0x03 => IPHC Header Compression IPHC encoding bytes: 0xd8c8 = Bit 0: 1 means IPv6 traffic class is elided and assumed to be 0 Bit 1: 1 means version and Flow Label are elided. Version is implicitly 6. Traffic Class and Flow Label are implicitly 0. Bit 2: 0 means IPv6 next header field is not elided. Bit 3 and 4: 11 means IPv6 TTL is elided and assumed to be 255. Bit 5-7: 000, Reserved Bits 8-9: 11 means source address is elided completely. Bits 10-11: 00 means source address context is link local. The source address is compressed this way because: - it is link local, hence the first 64 bits can be elided, the source address context identifies the prefix is link local. - the last 64 bits of the address can be inferred from the MAC address (as specified in RFC 4944, by changing the Universal / local bit of the MAC). MAC is 02:12:13:ff:fe:14:15:16 and 64 last bits of IP are 0012:13ff:fe14:1516 Bits 12-13: 10 means destination address is compressed to 16 bits. Bits 14-15: 00 means destination address context is link local Following the encoding bytes, are the fields that were not elided, 16

17 in the same order as they appear in the IPv6 header: 0x3a = next header field, ICMPv6 0xa401 = destination address ICMPv6 header and payload ICMPv6 type = 0x86, until byte number 109 (0x01). It differs from the plain IPv6 packet (this is why bridging is bad between links that are too different) in the source link layer address option: for ethernet (last option of packet 5), it is 8 bytes long (type, length, 6 bytes mac address), for (last option of packet 6), it is 16 bytes long (type, length, 8 bytes MAC address, 6 bytes padding to respect options 8 bytes alignment). Two bytes footer: 0x0002 [Frame Check Sequence] This is the analysis of a particular frame. However, a look at all the obtained frames in the trace shows that they share a common dispatch type. This concurs the fact that the 6LoWPAN implementation used by Contiki is using IPHC Header Compression. Furthermore, it would be possible to decode all the other packets in the same way as the packet above was decoded. 5 Development Ideas This section lists the future work that can be carried on in this field. 5.1 Native Linux Support The Linux kernel currently lacks a working implementation of an stack as well as a 6LoWPAN stack. The goal would be develop a 6LoWPAN and an stack for the Linux kernel natively. This would imply that the 6LoWPAN compression which is being carried on the RZ Raven USB stick (which has an image of the Contiki operating system) would then be carried out within the Linux Kernel. This would also eliminate the need for a network bridge. In terms of architecture, the figure below encapsulates the idea. In words, the 6LoWPAN stack would reuse functions and definitions from the IPv6 stack of the Linux kernel. The stack would then do the same with the 6LoWPAN stack. However, not all functions and definitions would be shared as has a separate implementation of the physical layer and the data link layer compared to IPv6. 17

18 Figure 9: Wireshark Capture There is currently large amount of interest in this area. While current development in the area is at a standstill with the now dead Linux project [2] the potential for development in this field is huge and 6LoWPAN stacks exist for TinyOS and Contiki. These are open source operating systems, thereby their source code is easily available for edification reasons. Technically speaking, a concentrated approach in this direction would include a detailed study of the and 6LoWPAN implementation in these operating systems and then porting the entire code to Linux. After this, it would be necessary to write a native driver for the RZ Raven USB stick so that it is recognized and registered with the Linux kernel without the support of the ravenusbstick.elf binary LoWPAN and Wireshark Another area of concern is the lack of support for 6LoWPAN with wireshark. Wireshark s extensive support of most Internet Protocols makes it the network analyzer of choice amongst developers. However, it currently lacks support for decoding 6LoWPAN packets. However, as described earlier, it is not difficult to decode a 6LoWPAN compressed packet. The algorithm would need to be coded to match with wireshark s existing API and then submitted upstream for testing and possible future inclusion in the wireshark main tree. 6 Conclusion While Linux lacks native support for IEEE networks and 6LoW- PAN header compression, it is still possible to integrate and analyze networks with Linux. However, the real work, the 6LoWPAN header com- 18

19 pression and the generation of IEEE packets is performed outside the kernel space. Linux, while continuously gaining popularity on the embdedded front, is still quite new on the scene which explains the absence of an IEEE and 6LoWPAN stack for it. However, the future looks bright. There is a considerable amount of zeal in the community to develop these stacks for the Linux kernel and sooner or later, the goal would be achieved. When that is done, the analysis and integration of networks with Linux would be a much easier task. It would be supported natively, like and Bluetooth currently are. The only way, then, is forward. References [1] IEEE Standards. Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specification for Low-Rate Wireless Personal Area Networks (WPANs), September [2] Linux Project at SourceForge. sourceforge.net. [3] IEEE Standards. IEEE Standards for Local and Metropolitan Networks: Overview and Architecture, February [4] S. Deering and R. Hinden. Internet protocol, version 6 (ipv6) specification. December [5] S. Deering A. Conta and M. Gupta. Internet control message protocol (icmpv6) for the internet protocol version 6 (ipv6) specification. http: // March [6] G. Montenegro N. Kushalnagar and C. Schumacher. RFC 4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. tools.ietf.org/html/rfc4919.txt, August [7] J. Hui N. Kushalnagar, G. Montenegro and D. Culler. Transmission of ipv6 packets over ieee networks. html/rfc4944.txt, September [8] J. Hui. Compression format for ipv6 datagrams in 6lowpan networks - draft-hui-6lowpan-hc draft-hui-6lowpan-hc-01, July [9] The Contiki Operating System. contiki/docs/. 19

20 [10] Julien Abeille. Running Contiki with uipv6 and SICSlowpan Support on the Atmel Raven. Contiki Tutorials, October [11] RZRAVEN USB Stick (Jackdaw). contiki/docs/a01164.html. 20

Implementation and Evaluation of the Enhanced Header Compression (IPHC) for 6LoWPAN

Implementation and Evaluation of the Enhanced Header Compression (IPHC) for 6LoWPAN Alessandro Ludovici, Anna Calveras, Marisa Catalan, Carles Gómez, and Josep Paradells Wireless Networks Group (WNG),