Implementing a virtual network

interface for Linux 2.6

Silvan Graf
(D-INFK)
Semester Thesis August 3, 2006
Advisor: Patrick Stuedi
Prof. G. Alonso
Institute of Pervasive Computing
ETH Zrich
Contents
1 Abstract 1
2 Introduction 3
2.1 Transparent heterogeneous mobile ad hoc networks . . . . . . . . . . . . . 3
3 Related Work 5
3.1 Transparent heterogeneous mobile ad hoc networks . . . . . . . . . . . . . 5
3.2 Linux kernel networking components . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Linux Ethernet Bridge . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Netlter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Routing protocols for MANET . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2 OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 An introduction to Linux 2.6 kernel programming 7
4.1 The Linux kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 The Hello World Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 The build system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1 Becoming part of the kernel . . . . . . . . . . . . . . . . . . . . . 9
4.4 The Linux device model . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Registering with the device model . . . . . . . . . . . . . . . . . . 11
4.4.2 System FS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5 The Network subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5.2 Default interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5.3 Packet transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Implementation of the virtual interface 21
5.1 The kernel module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2 Registering with the device model . . . . . . . . . . . . . . . . . . 22
5.1.3 The hook in the networking stack . . . . . . . . . . . . . . . . . . 22
5.1.4 The neighbor database . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.5 Processing incoming packets . . . . . . . . . . . . . . . . . . . . . 25
5.1.6 Processing outgoing packets . . . . . . . . . . . . . . . . . . . . . 25
5.2 The libvi library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 The victl command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Experiments and Results 27
6.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
iv CONTENTS
7 Users guide 31
7.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8 Conclusions and Future Work 33
Bibliography 34
Chapter 1
Abstract
This semester thesis shows how a virtual network interface can be used to transparently
build heterogeneous wireless multihop networks with varying MAC level protocols. The
implementation of such an interface for Linux 2.6 and the usage in cooperation with AODV
and OLSR are shown. Moreover, performance measurements are presented indicating the
overhead introduced by the virtual interface with respect to throughput and handover time.
The thesis further contains an introduction into Linux kernel module programming.
2 Chapter 1. Abstract
Chapter 2
Introduction
This semester thesis has been motivated by a previous work on transparent heterogeneous
mobile ad hoc networks [8]. In this work it has been shown how a virtual network interface
providing a MAC layer similar to 802.11 and a broadcast emulation can be used to trans-
parently build wireless multihop networks with varying MAC level protocols. While [8] is
based on a modied Linux Ethernet Bridge on kernel 2.4, this work started from scratch on
kernel 2.6.
This thesis presents how a virtual network interface providing a exible handover in-
frastructure, ent-to-end communication abstraction and a broadcast emulation layer is im-
plemented as a kernel module for Linux 2.6. A chapter on Linux kernel module program-
ming introduces the reader to the key concepts encountered in the implementation of the
virtual network interface. A userspace library and a tool to congure the virtual interface
are provided. Aguide on howto use the virtual interface together with the routing protocols
AODV and OLSR is given. Various experiments and their results are discussed to show the
efciency of this approach.
2.1 Transparent heterogeneous mobile ad hoc networks
Mobile ad hoc networks already exist in many forms of which the most popular incarnations
are personal area networks (PAN) and wireless sensor networks. For many applications it
is desirable to transparently build a heterogeneous mobile ad hoc network consisting of
different MANETs.
Figure 2.1: Heterogeneous Mobile Ad Hoc Network
Heterogeneous
MANET
Bluetooth
Scatternet
WLAN and
Bluetooth
Piconets
4 Chapter 2. Introduction
In gure 2.1 it is visible how nodes participating in different MANETs join those to-
gether to form a single transparent mobile ad hoc network.
The different usage scenarios impose their very specic requirements on devices and
protocols. Bluetooth PAN and WSN require the devices to be energy efcient whereas a
802.11 wireless network in an ofce needs a high throughput. The protocol stacks for the
different network types are optimized to their use and the protocols therefore differ strongly.
Most research on MANET assumes these networks to have a common MAC schema. The
virtual interface approach combines devices with different MAC level protocols into one
interface. Incoming packets on the physical devices are intercepted and further processed
by the virtual interface. The virtual interface sends outgoing packets over the appropriate
physical interface (cf. [8], 5.1.5 or 5.1.6). Figure 2.2 shows how a Bluetooth BNEP con-
nection is embedded into the virtual interface. A packet passes up the Bluetooth stack and
is intercepted by the virtual interface just before entering the IP layer.
Figure 2.2: Virtual Interface
MAC
IP
Transport
AODV
Application
Virtual
Interface vi
Broadcast Unicast
NDB Priorities Timer
HCI
L2CAP
H
C
I
D
S
D
P
D
B
N
E
P
802.x Interface
Chapter 3
Related Work
3.1 Transparent heterogeneous mobile ad hoc networks
In this work[8] a modied Linux Ethernet Bridge on kernel 2.4 was used to demonstrate
howwirelss multihop networks can be built using a virtual interface providing a MAXlayer
similar to 802.11 and broadcast emulation
1
The ideas of that work were used to implement
the virtual interface for Linux 2.6.
3.2 Linux kernel networking components
3.2.1 Linux Ethernet Bridge
The Linux Ethernet Bridge allows to put several real interfaces into a virtual bridging de-
vice. It is not only an in-kernel equivalent to a real ethernet bridge but together with Net-
lter a very sophisticated tool for packet ltering.
3.2.2 Netlter
Netlter and its userspace administration tool iptables are the packet lter rewalling toolkit
for Linux. The Linux kernel contains many so-called Netlter targets to build powerful
packet lter rulesets. Netlter can intercept packets at many states of their processing and
perform arbitraty operations on them.
The Netlter target ip_queue passes packets from kernel to userspace and back which
opens up many new applications.
3.3 Routing protocols for MANET
The routing in mobile ad hoc networks necessitates specialized algorithms and protocols
that can cope with the dynamic nature of appearing and vanishing neighbours. Two major
protocols have been used in this work to test the virtual interface in a realistic environment.
1
The Bluetooth Network Encapsulation Protocol BNEP provides a point to point connection. A broadcast is
to be understood as sending a packet over all existing BNEP links.
6 Chapter 3. Related Work
3.3.1 AODV
The Ad Hoc On demand Distance Vector routing protocol is a reactive routing algorithm
for MANET, meaning that routes between nodes are only built as soon as and maintained as
long as needed by a source node. AODV works with both unicast and multicast networks,
whereas in the latter it builds trees of multicast group members and nodes that connect the
multicast members. An implementation of AODV for Linux systems named AODV-UU
is provided by the Uppsala University[1]. It consists of a kernel module and a userspace
daemon. Although still experimental, aodvd performs well in a Linux MANET.
AODV-UU uses Netlter to capture the packets. It implements a facility similar to
ip_queue to pass the packets to userspace. The userspace daemon then processes the pack-
ets and modies the kernel routing table.
3.3.2 OLSR
The Optimized Link State Routing protocol is a proactive, table-driven routing algorithm
for MANET. An implementation of the OLSR protocol is provided by[6]. Olsrd runs as a
standalone server process and is platform independent. It is supposed to work on Linux,
FreeBSD, NetBSD, OS X and even on Windows. Olsrd does not depend on a kernel mod-
ule. All operations are performed in userspace. Explicit interaction with the kernel is only
necessary to manipulate the routing table.
Chapter 4
An introduction to Linux 2.6
kernel programming
This chapter tries to introduce the experienced systems programmer with a profound knowl-
edge in C to a few of the basic concepts of Linux kernel programming. The reader is as-
sumed to be familiar with using the GNU toolchain, namely gcc and make, further should
he know how to build a customized kernel.
It is of course not possible go give an elaborate introduction to kernel programming in
such a thesis. This introduction is supposed to teach the reader the very basics of Linux
kernel programming. It shows the major aspects related to the implementation of the virtual
network interface, namely to get a module built and have it registered with the central
facilities of the Linux kernel.
A more in-depth look at Linux kernel programming is given in [3] or [4].
Any structure or function which is referenced in the following can be looked up at the
"Cross-Referencing Linux"[5] project. They provide a search engine and a hyperlinked
view of the Linux source code.
4.1 The Linux kernel
The Linux kernel is a so-called monolithic kernel, i.e. all operating system services such
as memory and process management, hardware drivers, networking and concurrency are
implemented as a whole and run in supervisor mode sharing the same address space. Linux
provides the ability to load so-called modules at run-time. These become part of the kernel
as if they were linked-in.
Most device drivers are implemented as modules, although many of them can be linked
into the kernel at compile-time. The decision whether to link a driver into the kernel or
to have it as a module is based on the actual needs. The modern way is to have all drivers
which are not needed at an early phase of the boot process loaded as modules when needed.
4.2 The Hello World Module
Following the tradition of most programming related texts the rst example will print
"Hello, world". This example uses the logging facility of the kernel. The output is visible
either on the console, in the dmesg output or in the syslog, i.e. usually this is /var/log/mes-
sages.
Listing 4.1 shows the implementation of this simple module. Even in this simplistic ex-
ample a peculiarity of the Linux kernel shows up: the heavy usage of preprocessor macros.
The rst is found after the includes. MODULE_LICENSE declares the license under which
8 Chapter 4. An introduction to Linux 2.6 kernel programming
a module is distributed. As the Linux kernel itself is distributed only under GPL [2] which
does not allow linking proprietary objects to GPL-objects, it is quite unavoidable to choose
GPL as the modules license. Otherwise many kernel features are hidden from the module,
which is very restricting.
The next macro is encountered in line 7. KERN_ALERT, its friends KERN_DEBUG,
KERN_INFO and others dene the class of a log message which is to be printed to the
kernel log ring-buffer. These macros expand to strings which prex the actual message.
The last two lines of this example tell the kernel how to load and unload this module,
again these are macros.
Listing 4.2 shows the corresponding makele and listing 4.3 how the module is loaded
into the kernel. Looking at the output of the dmesg program should reveal the two strings.
Listing 4.1: A minimal kernel module
1 # i nc l ude < l i n u x / i n i t . h>
2 # i nc l ude < l i n u x / module . h>
3 MODULE_LICENSE( "GPL" ) ;
4
5 s t a t i c i nt h e l l o _ i n i t ( voi d )
6 {
7 p r i n t k (KERN_ALERT " Hel l o , wor l d \ n" ) ;
8 ret urn 0 ;
9 }
10
11 s t a t i c i nt h e l l o _ e x i t ( voi d )
12 {
13 p r i n t k (KERN_ALERT " Goodbye , wor l d \ n " ) ;
14 }
15
16 mo d u l e _ i n i t ( h e l l o _ i n i t ) ;
17 modul e _e xi t ( h e l l o _ e x i t ) ;
Listing 4.2: The Makele
1 i f ne q ( ( $KERNELRELEASE) , )
2 obj m : = h e l l o . o
3 e l s e
4 KERNELDIR ?= / l i b / modul es / $ ( s h e l l uname r ) / b u i l d
5 PWD : = $ ( s h e l l pwd)
6
7 d e f a u l t :
8 $ (MAKE) C $ ( KERNELDIR) M=$ (PWD) modul es
9 e ndi f
Listing 4.3: Building and loading the module
1 make
2 i nsmod h e l l o . ko
3 rmmod h e l l o
4.3 The build system 9
4.3 The build system
The previous section showed how an external module can be built. This build process al-
ready involves the kernel build system. If a module is to be distributed as part of the kernel,
its interaction goes further. The kernel build system not only comprehends compiling and
linking but also the conguration. The user usually congures the kernel options through
make cong or its derivatives make menucong or make xcong. These tools allow the user
to select which modules should make part of the kernel and how they will be linked to it -
statically or as a module. A number of other parameters can be adjusted during this process.
To make a module appear in these tools, it obviously needs to announe its presence.
4.3.1 Becoming part of the kernel
To let the module appear in the network section of the kernel conguration, its source has
to be moved to net/hello/ in the kernel source tree. The le net/Kcong has to contain a
line source "net/hello/Kcong". In the hello directory, a new le Kcong has to be created
according to listing 4.4. The makele has to be adapted to its new environment as the
Listing 4.4: Cong le for the kernel build system
1 c o n f i g HELLO
2 t r i s t a t e " He l l o wor l d module "
3 hel p
4 To compi l e t h i s code as a module ,
5 choos e M he r e : t h e module
6 wi l l be c a l l e d h e l l o .
7
8 I f uns ur e , s ay N.
module has to be compiled if and only if it is enabled in the conguration. Listing 4.5 shows
how it might look like. Apart from some general conventions for in-kernel makeles, the
main difference to the simple one in the previous section is in line 15 where the content
of the variable CONFIG_HELLO is evaluated. This variable is set by the conguration
system of the kernel and refers to the cong HELLO directive in listing 4.4.
10 Chapter 4. An introduction to Linux 2.6 kernel programming
Listing 4.5: Makele using the kernel build system
1 DEBUG = y
2
3 i f e q ( $ (DEBUG) , y )
4 DEBFLAGS = O g DHELLO_DEBUG
5 e l s e
6 DEBFLAGS = O2
7 e ndi f
8
9 CFLAGS += $ (DEBFLAGS) I $ ( LDDINC)
10
11 TARGET = h e l l o
12
13 i f ne q ( $ (KERNELRELEASE) , )
14
15 obj $ ( CONFIG_HELLO) : = h e l l o . o
16
17 # h e l l o o b j s := #no o t h e r o b j e c t s ar e l i n k e d t o h e l l o . o
18
19 e l s e
20
21 KERNELDIR ?= / l i b / modul es / $ ( s h e l l uname r ) / b u i l d
22 PWD : = $ ( s he l l pwd)
23
24 modul es :
25 $ (MAKE) C $ ( KERNELDIR) M=$ (PWD) LDDINC=$ (PWD) modul es
26
27 e ndi f
28
29
30 i n s t a l l :
31 i n s t a l l d $ ( INSTALLDIR)
32 i n s t a l l c $ (TARGET) . o $ ( INSTALLDIR)
33
34 c l e a n :
35 rm r f . o ~ c or e . depend . ko
36 rm r f . mod . c . t mp _ v e r s i ons . . cmd
37
38
39 depend . depend dep :
40 $ (CC) $ (CFLAGS) M . c > . depend
41
42 i f e q ( . depend , $ ( wi l dcard . depend ) )
43 i nc l ude . depend
44 e ndi f
4.4 The Linux device model 11
4.4 The Linux device model
Linux 2.6 introduces a unied device model, a single data structure containing all the in-
formation on how the system is put together. Advanced features like hotplugging devices
on USB and PCI or power management demanded for a more sophisticated design than the
one in Linux 2.4.
The kernel programmers work became easier because all subsystems work similarly
while at the same time the registration of a driver and its devices to the system may have
become more difcult. Certainly, the new device model is a giant step in the development
of the Linux kernel and shows that Linux 2.6 is a modern and well designed operating
system. The device model is mainly split into buses, classes and devices. A small piece of
Figure 4.1: A look into the device model
it is shown in gure 4.1 which is adapted from [3].
A bus represents the way a device is connected to the system, whereas classes group
devices according to their function. Two network devices, connected to the PCI bus and
the USB bus, respectively, appear in the same class as they provide the same function.
Each object in the device model - e.g. device, driver, bus - is represented by a kobject.
The kobjects tasks include reference counting, SysFS representation, hotplug event han-
dling. It holds the device module structure together by having pointers to the parent, a kset,
a list containing its children. It helps distinguishing the different types of kobjects with a
pointer to a kobj_type.
The kobject structure and its primary helpers kobj_type and kset are dened in in-
clude/linux/kobject.h. An excerpt of this le is given in listing 4.6.
Listing 4.7 shows how a kobject is normally used. It is a member of the struct which
wants to use kobjects facilities. This technique is encountered throughout the kernel in
many places, e.g. the linked list implementation (cf. listing 4.6). At this point it might
be important to know that the basic structure device of which any device in the kernel has
an instance normally is not used solely, instead each subsystem denes a container for
this structure. Another interesting point is to see that the structure class_device contains a
kobject and the structure device contains another one. The usefulness of this will be seen
in the section covering SystemFS.
4.4.1 Registering with the device model
Devices in Linux 2.6 normally wont be created out of the blue. The need for a device
structure or even the whole driver arises when a device is detected through hotplug events
12 Chapter 4. An introduction to Linux 2.6 kernel programming
Listing 4.6: kobject structures
1 s t r uc t k o b j _ t y p e {
2 voi d ( r e l e a s e ) ( s t r uc t k o b j e c t ) ;
3 s t r uc t s y s f s _ o p s s y s f s _ o p s ;
4 s t r uc t a t t r i b u t e d e f a u l t _ a t t r s ;
5 } ;
6 s t r uc t k s e t {
7 s t r uc t s ubs ys t em s ubs ys ;
8 s t r uc t k o b j _ t y p e kt ype ;
9 s t r uc t l i s t _ h e a d l i s t ;
10 s t r uc t k o b j e c t kobj ;
11 s t r uc t k s e t _ h o t p l u g _ o p s hot pl ug_ops ;
12 } ;
13 s t r uc t k o b j e c t {
14 char k_name ;
15 char name [KOBJ_NAME_LEN] ;
16 s t r uc t k r e f k r e f ;
17 s t r uc t l i s t _ h e a d e n t r y ;
18 s t r uc t k o b j e c t p a r e n t ;
19 s t r uc t k s e t k s e t ;
20 s t r uc t k o b j _ t y p e kt ype ;
21 s t r uc t d e n t r y d e n t r y ;
22 } ;
Listing 4.7: A kobject consumer
1 s t r uc t c l a s s _ d e v i c e {
2 s t r uc t l i s t _ h e a d node ;
3 s t r uc t k o b j e c t kobj ;
4 s t r uc t c l a s s c l a s s ;
5 s t r uc t d e v i c e dev ;
6 voi d c l a s s _ d a t a ;
7 char c l a s s _ i d [ BUS_ID_SIZE ] ;
8 } ;
4.4 The Linux device model 13
or probing on the bus. Only special devices like the pure virtual network interface have
to be initialized and registered with their respective subsystems manually. Another excep-
tion are busses which dene on the one hand a bus_type and on the other hand a device.
Busses like the platform bus which do not have a physical representation (e.g. the USB
has a representation in form of a UHCI controller) have to initialize their device structures
themselves.
Network devices register with the network system through register_netdevice which
also includes a registration with the class net. It is important to distinguish between the
different institutions to which a device might register and to know the various structures
needed to do this. Table 4.1 tries to give an overview of the major entry points to the
device model. It shows the relationship of subsystems and their structures and registration
functions.
Table 4.1: Registration facilities of the device model
part of the model structure function
class struct class_device class_device_register
network subsystem struct net_device register_netdevice
bus struct device device_register
4.4.2 System FS
The user interface to the new device model is a lesystem which is usually mounted in
/sys. It lists all devices, drivers, busses and their relations. All of them can export attributes
which then are listed as les. Links to other parts of the system are implemented as direc-
tories, i.e. the pci bus contains directories representing the actual busses (pci controller)
which again contain links to the connected devices. Device directories contain links to
their drivers. Via this lesystem the user or system utilities can access and modify the pa-
rameters of devices and drivers. The lesystem behaves much like the old /proc lesystem,
although its structure is quite strictly dened. The user can manipulate it using echo, cat
and similar tools. The library libvi and the management tool victl make use of the les
in the sys lesystem. Looking at listing 4.8 one might be able to detect the correlation of
the SysFS tree and the data structure showed in gure 4.1. As attributes are exported
to SysFS as les, one has to dene functions for read and write operations. The kernel
provides macros and a convenient API to decorate a kobject with custom attributes. A
directory containing several attributes is attached to an existing kobject as shown in list-
ing 4.9. The function add_myattrs is usually called upon initialization of the class_device
structure. The functions providing the read and write operations on the SysFS les should
return the number of bytes read or written. The network devices, which are covered later,
contain a class_device structure. Considering the device eth0 the new attributes would ap-
pear in /sys/class/net/eth0/myattrs/. The class_device also holds a link to a device structure
which essentially is the the basic representation of any device. This structure maintains all
the connections to busses, drivers and some very specic informations on power manage-
ment, DMA and other things we usually do not want to get in touch with. This example
shows how a class_device can be extended by attributes. This is what we usually want, as
there lies the information a user/administrator has to deal with. The attributes exported by
device cover mostly the mentioned low-level details which are usually read-only.
14 Chapter 4. An introduction to Linux 2.6 kernel programming
Listing 4.8: Look into SysFS
1 / s ys
2 | bl oc k
3 | . . .
4 | bus
5 | | . . .
6 | | p c i
7 | | | d e v i c e s
8 | | | | . . .
9 | | | | 0000: 00: 1 d . 1 > . . .
10 | | | | . . .
11 | | d r i v e r s
12 | | | I n t e l ICH
13 | | | | 0000: 00: 1 f . 5 > . . .
14 | | | | . . .
15 | | | . . .
16 | | uhci _hcd
17 | | | 0000: 00: 1 d . 0 > . . .
18 | | | 0000: 00: 1 d . 1 > . . .
19 | | | . . .
20 | | . . .
21 | usb
22 | | d e v i c e s
23 | d r i v e r s
24 | c l a s s
25 | | i n p u t
26 | | | i n p u t 0
27 | | | | d e v i c e > . . .
28 | | | | . . .
29 | d e v i c e s
30 | f i r mwar e
31 | k e r n e l
32 | module
33 power
4.4 The Linux device model 15
Listing 4.9: Adding a group of attributes
1 s t a t i c s s i z e _ t s t o r e _ a t t r _ a ( s t r uc t c l a s s _ d e v i c e cd ,
2 c ons t char buf ,
3 s i z e _ t l e n )
4 { . . . }
5
6 s t a t i c s s i z e _ t s t o r e _ a t t r _ b ( . . . ) { }
7 s t a t i c s s i z e _ t s t o r e _ a t t r _ c ( . . . ) { }
8
9 s t a t i c s s i z e _ t s h o w_ a t t r _ c ( s t r uc t c l a s s _ d e v i c e cd ,
10 c ons t char buf ,
11 s i z e _ t l e n )
12 { . . . }
13
14 s t a t i c CLASS_DEVICE_ATTR( a t t r _ a , S_IWUSR,
15 NULL, s t o r e _ a t t r _ a ) ;
16 s t a t i c CLASS_DEVICE_ATTR( add , S_IWUSR,
17 NULL, s t o r e _ a t t r _ b ) ;
18 s t a t i c CLASS_DEVICE_ATTR( maxdi f f , S_IWUSR | S_IRUGO,
19 s how_a t t r _c , s t o r e _ a t t r _ c ) ;
20
21 s t a t i c s t r uc t a t t r i b u t e my a t t r s [ ] = {
22 &c l a s s _ d e v i c e _ a t t r _ a t t r _ a . a t t r ,
23 &c l a s s _ d e v i c e _ a t t r _ a t t r _ b . a t t r ,
24 &c l a s s _ d e v i c e _ a t t r _ a t t r _ c . a t t r ,
25 NULL
26 } ;
27
28 s t a t i c s t r uc t a t t r i b u t e _ g r o u p mygroup = {
29 . name = " my a t t r s " ,
30 . a t t r s = mya t t r s ,
31 } ;
32
33 i nt a dd_mya t t r s ( s t r uc t c l a s s _ d e v i c e dev )
34 {
35 s t r uc t k o b j e c t kobj = &dev . kobj ;
36 i nt e r r ;
37 e r r = s y s f s _ c r e a t e _ g r o u p ( kobj , &mygroup ) ;
38 i f ( e r r )
39 {
40 p r _ i n f o (%s can t c r e a t e gr oup %s \ n " ,
41 __FUNCTION__ , mygroup . name ) ;
42
43 }
44 r e t u r n e r r ;
45 }
16 Chapter 4. An introduction to Linux 2.6 kernel programming
4.5 The Network subsystem
The Linux network subsystem breaks with the unix philosophy of everything being a le.
Contrary to block and char devices, network devices do not have an entry point in the /dev
directory. There is usually no reason to perform read or write operations on a network
device. These operations are performed on a socket, of which many hundreds can be mul-
tiplexed to a network interface. A network interface has to provide means for transmitting
and receiving packets. The network subsystem is completely independent of protocols -
either hardware or software - albeit providing major support for ethernet devices and the
TCP/IP protocol suite. Implementing a device similar to an ethernet device is very tempt-
ing, so that even the plip device, which is a network device that links two computers via
their parallel ports, resembles an ethernet device in many ways.
4.5.1 Initialization
A network device is created using the function alloc_netdev and registered with the net-
work subsystem using register_netdev. The usage of these functions is demonstrated in
listing 4.11. The function mydev_create carries out all steps necessary to create a new
network device. The structure type mydev_private is the place where device specic data
is stored. The function alloc_netdev allocates the space for this private data, too. It is in
fact appended to the structure net_device. The pointer priv links to the start of the private
data. Listing 4.11 also shows how the class_device structure discussed earlier is used in a
specic subsystem.
Listing 4.10: Initialization of a network device
1 s t r uc t myde v_pr i va t e{
2 / p r i v a t e f i e l d s /
3 } ;
4
5 voi d mydev_set up ( s t r uc t n e t _ d e v i c e dev )
6 {
7 / cust om i n i t i a l i z a t i o n code /
8 }
9
10 s t r uc t n e t _ d e v i c e mydev_cr eat e ( )
11 {
12 mydev = a l l o c _ n e t d e v ( s i z e o f ( s t r uc t myde v_pr i vat e ) ,
13 " mydev%d " , mydev_set up ) ;
14 i f ( mydev )
15 {
16 i f ( r e g i s t e r _ d e t d e v ( mydev ) )
17 {
18 / e r r o r handl i ng /
19 f r e e _ n e t d e v ( mydev ) ;
20 }
21 }
22 e l s e
23 {
24 / e r r o r handl i ng /
25 }
26 }
4.5 The Network subsystem 17
Listing 4.11: Main network device infrastructure
1 s t r uc t n e t _ d e v i c e a l l o c _ n e t d e v (
2 i nt s i z e o f _ p r i v ,
3 c ons t char name ,
4 voi d ( s e t u p ) ( s t r uc t n e t _ d e v i c e ) ) ;
5 voi d f r e e _ n e t d e v ( s t r uc t n e t _ d e v i c e dev ) ;
6 i nt r e g i s t e r _ n e t d e v ( s t r uc t n e t _ d e v i c e dev ) ;
7 voi d u n r e g i s t e r _ n e t d e v ( s t r uc t n e t _ d e v i c e dev ) ;
8
9 s t r uc t n e t _ d e v i c e
10 {
11 . . .
12 voi d p r i v ;
13 . . .
14 s t r uc t c l a s s _ d e v i c e c l a s s _ d e v ;
15 . . .
16 }
4.5.2 Default interface
The network subsystem requires a device to implement a set of default functions. During
initialization, the driver has to store the pointers to the implementing functions into the
appropriate elds of the net_device structure (cf. listing 4.10). Not all of these functions
have to be implemented specically, as the kernel includes some default implementations
which are enabled through netdev_alloc. A list of the most common candidates for custom
implementation is given in listing 4.12.
Listing 4.12: Network device interface service routines
1 i nt ( open ) ( s t r uc t n e t _ d e v i c e dev ) ;
2 i nt ( s t o p ) ( s t r uc t n e t _ d e v i c e dev ) ;
3 i nt ( h a r d _ s t a r t _ x mi t ) ( s t r uc t s k _ b u f f skb ,
4 s t r uc t n e t _ d e v i c e dev ) ;
5 i nt ( s e t _ ma c _ a ddr e s s ) ( s t r uc t n e t _ d e v i c e dev ,
6 voi d addr ) ;
7 i nt ( d o _ i o c t l ) ( s t r uc t n e t _ d e v i c e dev ,
8 s t r uc t i f r e q i f r , i nt cmd ) ;
9 i nt ( s e t _ c o n f i g ) ( s t r uc t n e t _ d e v i c e dev ,
10 s t r uc t i f map map ) ;
11 i nt ( change_mt u ) ( s t r uc t n e t _ d e v i c e dev , i nt new_mtu ) ;
12 voi d ( t x _ t i me o u t ) ( s t r uc t n e t _ d e v i c e dev ) ;
open
This function is called as soon as ifcong activates the device. Any resources should
be initialized at this point, i.e. in a physical device this includes IRQ, DMA, et.
stop
This is the opposite to open.
hard_start_xmit
The actual workhorse of a network device which transmits packets. Will be covered
in-depth in the next section.
18 Chapter 4. An introduction to Linux 2.6 kernel programming
set_mac_address
If a device is able to set its mac address, e.g. in a register of the chip on the adapter,
then this function would perform this low-level work. The default implementation
just sets the corresponding eld net_device->dev_addr.
do_ioctl
Only if the interface is desired to perform specic ioctl operations this eld must
be non-null. The implementation of custom ioctl operations is not covered in this
thesis
1
change_mtu
If the MTU for this interface changes, this function is called.
tx_timeout
If a packet transmission fails to be completed within reasonable time, this function
is supposed to handle the problem and to resume transmission.
4.5.3 Packet transport
Packet transport can be split in two parts: sending and receiving. Sending is always initiated
by the network stack. The network interface gets the data to be sent via the hard_start_xmit
function mentioned in the previous section. Reception is usually due to an interrupt caused
by a packet coming over the wire and reaching the controller on the network adapter. Be-
cause of the impossibility to deal with these device-specic topics, the device-independent
structure sk_buff which is central to packet transport will be explained.
The protocol-independency of the sk_buff structure in listing 4.14 is clearly visible in
the excessive usage of unions. This structure perfectly ts the packet-oriented nature of
most modern network protocols. It integrates the header-data for three protocol-layers, the
actual payload and a lot of administrative information. The latter mostly relate to the packet
lter (Netlter) and caching. The sk_buff system includes several functions to manipulate
this non-trivial structure. Listing 4.13 shows the signature of these functions.
Listing 4.13: sk_buff manipulation
1 s t r uc t s k _ b u f f s kb_c l one ( s t r uc t s k _ b u f f skb ,
2 i nt p r i o r i t y ) ;
3 s t r uc t s k _ b u f f a l l o c _ s k b ( unsi gned i nt s i z e ,
4 i nt p r i o r i t y ) ;
5 voi d s kb_t r i m ( s t r uc t s k _ b u f f skb ,
6 unsi gned i nt l e n )
7 unsi gned char s k b _ p u l l ( s t r uc t s k _ b u f f skb ,
8 unsi gned i nt l e n ) ;
9 unsi gned char skb_push ( s t r uc t s k _ b u f f skb ,
10 unsi gned i nt l e n ) ;
11 unsi gned char s kb_put ( s t r uc t s k _ b u f f skb ,
12 unsi gned i nt l e n ) ;
skb_clone
Duplicates an sk_buff structure in its entirety
1
With the introduction of sysfs the ioctl mechanism has become obsolete in most cases. The author considers
ioctl harmful as every new ioctl operation is like a new system call. The kernel API therefore changes rapidly
and becomes complex. Further, ioctl operations are assigned global numbers which have to be coordinated to not
overlap between different devices.
4.5 The Network subsystem 19
alloc_skb
Allocates an sk_buff structure. This is mainly used in the receiving part of a network
driver.
skb_pull
Removes data from the start of the buffer. This functions returns a pointer to the next
data in the buffer. Subsequent calls to skb_push will overwrite the old data.
skb_push
Adds data to the start of the buffer. A pointer to the new start is returned.
skb_put
Adds data to the end of the buffer. A pointer to the start of the extra data is returnen.
20 Chapter 4. An introduction to Linux 2.6 kernel programming
Listing 4.14: Excerpt of the sk_buff structure
1 s t r uc t s k _ b u f f {
2 s t r uc t s k _ b u f f ne xt ;
3 s t r uc t s k _ b u f f pr ev ;
4 s t r uc t s k_buf f _he a d l i s t ;
5 s t r uc t sock sk ;
6 s t r uc t t i me v a l st amp ;
7 s t r uc t n e t _ d e v i c e dev ;
8 s t r uc t n e t _ d e v i c e i n p u t _ d e v ;
9 s t r uc t n e t _ d e v i c e r e a l _ d e v ;
10
11 uni on {
12 s t r uc t t c p h d r t h ;
13 s t r uc t udphdr uh ;
14 s t r uc t i cmphdr icmph ;
15 s t r uc t i gmphdr igmph ;
16 s t r uc t i p h d r i p i p h ;
17 s t r uc t i pv6hdr i pv6h ;
18 unsi gned char raw ;
19 } h ;
20
21 uni on {
22 s t r uc t i p h d r i ph ;
23 s t r uc t i pv6hdr i pv6h ;
24 s t r uc t a r p h d r ar ph ;
25 unsi gned char raw ;
26 } nh ;
27
28 uni on {
29 unsi gned char raw ;
30 } mac ;
31 / . . . /
32 unsi gned i nt l en ,
33 d a t a _ l e n ,
34 mac_len ,
35 csum ;
36 unsi gned char l o c a l _ d f ,
37 cl oned ,
38 pkt _t ype ,
39 ip_summed ;
40 __u32 p r i o r i t y ;
41 unsi gned s hor t p r o t o c o l ,
42 s e c u r i t y ;
43 /
44 . . . d e s t i n a t i o n cache . . .
45 . . . NETFILTER . . .
46 /
47 unsi gned char head ,
48 dat a ,
49 t a i l ,
50 end ;
51 } ;
Chapter 5
Implementation of the virtual
interface
The virtual network interface for transparent heterogeneous mobile ad hoc networks con-
sists of three parts.
A kernel module providing the actual network interface
A library providing programmatic access to the congurable options
A userspace utility to manage virtual interfaces
5.1 The kernel module
The original work [8] adapted the bridge code, whereas this work started from scratch,
albeit taking a lot of inspiration out of the bridge code.
The requirements for the module were as follows.
Provide the functionality of the original virtual interface, namely
Attach network devices
Maintain a neighbor database
Choose outgoing link according to priority
Provide some fuzziness, i.e. maxdiff
Provide a broadcast emulation
Conguration via SysFS
No use of custom ioctls
Implementation should be as simple as possible
Minimize overhead
5.1.1 User interface
The network interface exposes its functionality to the network subsystem via well-dened
interfaces. The conguration specic to the virtual interface is only available through
SysFS. The following shows which operations the user is able to perform using the les in
SysFS.
22 Chapter 5. Implementation of the virtual interface
Driver
/sys/bus/platform/driver/vi/
Show version
version
Create a virtual interface
add
Remove a virtual interface
remove
Device
/sys/class/net/vi<x>/vi/
Attach physical network interface
add
Detach physical network interface
remove
Manipulate maxdiff value
maxdiff
Port
/sys/class/net/vi<x>/vi/ports/eth<y>/viport/
/sys/class/net/eth<y>/viport/
Manipulate priority
priority
The les may be manipulated using cat and echo.
5.1.2 Registering with the device model
The driver registers with the platform bus as there is no real bus it belongs to. The drivers
registration is necessary because there needs to be an interface to the driver in order to
instantiate a virtual interface.
5.1.3 The hook in the networking stack
Listing 5.1: Patch #2 to net/core/dev.c
1 i f ( h a n d l e _ v i (&skb , &pt _pr e v , &r e t , or i g_de v ) )
2 got o out ;
Listing 5.2: Patch to inclue/linux/netdevice.h
1 / v i s t u f f /
2 s t r uc t n e t _ v i _ p o r t v i _ p o r t ;
The locations to insert the patches in listings 5.3, 5.1, 5.2 are found by looking for the
strings "handle_bridge" and "br_port" in dev.c and netdevice.h, respectively. The code is
inserted just below the bridge code which looks very similar.
5.1 The kernel module 23
Listing 5.3: Patch #1 to net/core/dev.c
1 # i f d e f i n e d ( CONFIG_VI ) | | d e f i n e d ( CONFIG_VI_MODULE)
2 i nt ( vi _ha ndl e _f r a me _hook ) ( s t r uc t n e t _ v i _ p o r t p ,
3 s t r uc t s k _ b u f f pskb ) ;
4 s t r uc t n e t _ v i ;
5
6 s t a t i c _ _ i n l i n e _ _ i nt h a n d l e _ v i (
7 s t r uc t s k _ b u f f pskb ,
8 s t r uc t p a c k e t _ t y p e pt _pr e v , i nt r e t ,
9 s t r uc t n e t _ d e v i c e or i g_de v )
10 {
11 s t r uc t n e t _ v i _ p o r t p o r t ;
12
13 i f ( ( pskb)> p k t _ t y p e == PACKET_LOOPBACK | |
14 ( p o r t = r c u _ d e r e f e r e n c e ( ( pskb)>dev>v i _ p o r t ) ) == NULL)
15 ret urn 0 ;
16 ret urn vi _ha ndl e _f r ame_hook ( por t , pskb ) ;
17 }
18 # e l s e
19 # de f i ne h a n d l e _ v i ( skb , pt _pr e v , r e t , or i g_de v ) ( 0 )
20 # e ndi f
The hook is placed in the general packet reception routine of a network device. Before
passing the sk_buff to the upper layers it is checked if it has to be passed to a virtual
interface or to the bridge.
A drawback of this approach is the necessity to patch and recompile the kernel. Differ-
ent, less invasive approaches will be discussed in chapter 8.
24 Chapter 5. Implementation of the virtual interface
5.1.4 The neighbor database
The neighbor database is a hashtable with the hash function calculated on the mac address.
A doubly linked list for each hash value contains the entries corresponding to neighbors.
The structure of a neighbor entry can be seen in listing 5.4.
Listing 5.4: Structure net_vi_ndb_entry
1 s t r uc t n e t _ v i _ n d b _ e n t r y
2 {
3 s t r uc t h l i s t _ n o d e h l i s t ;
4 a t o mi c _ t us e _c ount ;
5 s t r uc t mac_addr addr ;
6 s t r uc t n e t _ v i _ p o r t d s t ;
7 s t r uc t r cu_head r c u ;
8 unsi gned l ong t s ;
9 unsi gned i s _ l o c a l : 1 ;
10 } ;
Figure 5.1: The neighbor database (simplied)
The elds of this structure are used as follows.
hlist
The linked list
use_count
An atomic reference counter
addr
The address of the neighbor. Local devices are neighbors, too.
dst
The port through which a neighbor is reached
rcu
Structure for the RCU-mechanism. This is used for adding and removing entries.
ts
A timestamp. The difference of such timestamps are compared with the maxdiff
value
is_local
As mentioned, local devices are neighbors, too. This eld differentiates between
them and real neighbors.
5.1 The kernel module 25
Insertion The function to insert and update entries into the neighbor database is the same.
First, the hashtable is searched for a matching entry. If one is found, it is updated, otherwise
a new entry is created. The update sets the timestamp to the kernel time jifes.
Outgoing link selection Outgoing links are selected according to the algorithm in listing
5.5.
Listing 5.5: Link selection
1 l i s t = t a b l e [ hash ( mac ) ]
2 out goi ng = NULL
3 f o r e a c h ( e n t r y i n l i s t )
4 {
5 i f ( e n t r y . mac == mac )
6 {
7 i f ( out goi ng == NULL) out goi ng = e n t r y ;
8 e l s e i f ( e n t r y . p o r t . p r i o r i t y < out goi ng . p o r t . p r i o r i t y )
9 {
10 i f ( out goi ng . t s e n t r y . t s < ma xdi f f ) out goi ng = e n t r y ;
11 }
12 e l s e
13 {
14 i f ( e n t r y . t s out goi ng . t s > ma xdi f f ) out goi ng = e n t r y ;
15 }
16 }
17 }
The implementation of this section is found in vi_ndb.c
5.1.5 Processing incoming packets
Incoming packets reach the virtual interface through the hook in dev.c.
First, the senders entry in the neighbor database is updated or created, then the packet
is passed up if:
the virtual interface is in promiscuous mode
the packet was sent to the broadcast address
the destination address is the local address
the destination address belongs to one of the ports
The implementation of this section is found in vi_input.c
5.1.6 Processing outgoing packets
Outgoing packets reach the virtual interface through the hard_start_xmit hook of the net-
work device default interface. A packet is sent according to the following policy:
Broadcast packet
transmit over all attached interfaces
Normal packet
Neighbor known
transmit over the corresponding outgoing link
26 Chapter 5. Implementation of the virtual interface
Neighbor unknown
transmit over all attached interfaces
The implementation of this section is found in vi_device.c.
5.2 The libvi library
This library provides the interface given in listing 5.6. The library uses libsysfs [9] to access
the virtual les in the SysFS to congure the virtual interface. Before actually using the
functions provided by libvi it has to be initialized by calling vi_init.
Listing 5.6: Virtual interface conguration library
1 i nt v i _ i n i t ( voi d ) ;
2 i nt v i _ a d d v i ( c ons t char name ) ;
3 i nt v i _ d e l v i ( c ons t char name ) ;
4 i nt v i _ a d d i f ( c ons t char vi ,
5 c ons t char i f name ) ;
6 i nt v i _ d e l i f ( c ons t char vi ,
7 c ons t char i f name ) ;
8 i nt v i _ s e t _ p o r t p r i o r i t y ( c ons t char i f name ,
9 unsi gned l ong p r i o ) ;
10 i nt v i _ s e t _ ma x d i f f ( c ons t char vi ,
11 unsi gned l ong ma xdi f f ) ;
12 i nt v i _ g e t _ p o r t p r i o t i t y ( c ons t char i f name ,
13 unsi gned l ong p r i o ) ;
14 i nt v i _ g e t _ ma x d i f f ( c ons t char i f name ,
15 unsi gned l ong ma xdi f f ) ;
5.3 The victl command
The victl command is a command-line utility which uses libvi to manage virtual interfaces.
If victl is run without parameters it displays a help message which explains how to use it.
Chapter 6
Experiments and Results
The performance of the virtual interface was measured according to throughput and handover-
time. The neighbor database look-up and the detour the packets have to take naturally im-
pair throughput. Handover-time in case of a vanishing link is important as packets can get
lost. There are three types of handover which have to be considered. Figure 6.1 visualizes
them.
All readings were taken on Dell Latitude with integrated IEEE 802.11b adapters. Blue-
tooth connections were provided by various USB dongles. Linux pand was used to setup a
BNEP connection.
6.1 Throughput
Throughput was measured using netio[7] which is a small program available for many
platforms. It is client-server based and able to measure both TCP and UDP throughput. See
the results presented in table 6.1 and 6.2. RAW measurements were taken without virtual
interface. The varying packet sizes are important to determine the per-packet overhead.
The values are averaged over 10 readings and show the throughput between two nodes in
Mbps and the standard deviation .
Compared to the virtual interface of original paper the new virtual interface has a sig-
nicantly larger overhead. Measurements with the Linux Ethernet Bridge on kernel 2.6.
showed that it has the same problems. Throughput including a bridge is about 30% lower
than raw throughput. The virtual interface can still be compared with the bridge because
the neighbour database (vi) and the forwarding database (bridge) are quite similar and both
use the same locking mechanisms.
Figure 6.2 shows the relation of the throughput on Linux 2.4 and Linux 2.6. Interest-
ingly also the raw throughput on 2.6 is much lower than on 2.4 on the same hardware.
Figure 6.1: Horizontal, Diagonal, and Vertical handover
S D S D S D
S
D
Bluetooth
802.11
S Source Node
Destination Node
Broken Link
Node Movement
28 Chapter 6. Experiments and Results
Figure 6.2: Wireless LAN throughput on Linux 2.4 and Linux 2.6
WL/TCP/RAW WL/TCP/V WL/UDP/RAW WL/UDP/V
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
Performance comparison of 2.4 and 2.6 versions
Linux 2.4
Linux 2.6
Table 6.1: WLAN throughput in Mbps
Packet TCP UDP
RAW 1k 3.4477 0.0221 3.5164 0.0025
2k 3.4555 0.0250 3.4688 0.0000
4k 3.4500 0.0234 3.8906 0.0588
8k 3.4641 0.0066 3.8711 0.0124
16k 3.4477 0.0377 3.8883 0.0074
32k 3.4211 0.1119 3.9992 0.0607
VI 1k 3.1797 0.1053 3.2891 0.1148
2k 3.1742 0.1022 3.5586 0.3257
4k 3.1711 0.1006 3.6234 0.3131
8k 3.1578 0.0978 3.7383 0.2988
16k 2.7477 0.8312 3.8086 0.2374
32k 3.1617 0.0938 3.8422 0.1498
Table 6.2: Bluetooth throughput in Mbps
Packet TCP UDP
RAW 1k 0.5484 0.0911 0.5709 0.0625
2k 0.5156 0.0772 0.6841 0.0815
4k 0.5158 0.0822 0.6415 0.1035
8k 0.5501 0.0789 0.6949 0.0963
16k 0.5470 0.0768 0.7015 0.1264
32k 0.5625 0.0746 0.7090 0.1357
VI 1k 0.5306 0.0732 0.6340 0.0684
2k 0.5805 0.0837 0.6466 0.0516
4k 0.5818 0.0784 0.6243 0.0923
8k 0.5471 0.0611 0.6573 0.0896
16k 0.5837 0.0867 0.6715 0.1359
32k 0.5445 0.0603 0.7361 0.1479
6.2 Handover 29
Table 6.3: Handover time in seconds
Type From To Routing Interface Time
Horizontal WL WL AODV Raw 2 0
VI 2 0
OLSR Raw 1.02 0.06
VI 1.04 0.08
BT BT AODV VI 3.5 9
OLSR VI 8 3.01
Diagonal WL BT AODV VI/10 1.65 0.67
VI/1000 2.05 0.55
OLSR VI/10 1.15 0.71
VI/1000 7 0.62
Vertical WL BT AODV VI/10 0 0
VI/1000 0.7 0.35
OLSR VI/10 0 0
VI/1000 1.05 0.55
6.2 Handover
Horizontal handover
The MAC level protocol remains the same, but the route changes.
Vertical handover
The neighbour remains the same, but the MAC level protocol changes.
Diagonal handover
The MAC level protocol and the route change simultaneously.
The handover times were measured using ping. The number of missing packets were
counted and multiplied by the ping frequency. The results are presented in table 6.3. Han-
dover times are averages over 10 readings with standard deviation . Entries of the form
"VI/x" must be understood as "Virtual Interface with a maxdiff value of x". The large stan-
dard deviations in the horizontal Bluetooth handover are caused by the Bluetooth inquiry
mechanism.
The handover times from Bluetooth to WLAN, either diagonal or vertical, are similar
to the times from WLAN to Bluetooth.
The handover times of the original and the new virtual interface do not differ as much
as the throughput, i.e. they are essentially equal.
30 Chapter 6. Experiments and Results
Chapter 7
Users guide
7.1 Installation
Linux kernel
Install the Linux 2.6.12 sources
Congure the kernel to your needs
Build and install the kernel
Reboot and verify
Apply the patch vimodule.patch
Rebuild and install the kernel
Routing protocols
Get the source distribution of AODV-UU [1]
Install according to the AODV-UU installation manual
Get the source distribution of OLSRD [6]
Install according to the OLSRD installation manual
Libsysfs
Install the development package of libsysfs for your distribution
or get and install the source distribution from [9]
Virtual interface
If the le congure does not exist in the root of the vi distribution, issue the following
commands
aclocal
autoheader
autoconf
run ./congure
run make
run make install
32 Chapter 7. Users guide
7.2 Usage
The victl is self-explanatory. The following is an example on how to install a virtual inter-
face.
Load the module vi.ko
Add a virtual interface using victl addvi vi0
Start the interface by ifcong vi0 up
Add an existing network interface to the virtual interface by victl addif vi0 eth1
Set the priority by victl setportprio vi0 eth1 10
Add another existing interface by victl addif vi0 bnep0
Set a MAC address for the virtual interface by ifcong vi0 hw ether $MAC
Set an IP address by ifcong vi0 $IP
Chapter 8
Conclusions and Future Work
Using a virtual interface for transparent heterogeneous mobile ad hoc networks has once
again proven to be a good approach. Using either OLSR or AODV reasonable handover
times can be achieved, although Bluetooth connection setup may drastically impair perfor-
mance. The throughput rate are little below the raw rate.
Placing a hook into dev.c has shown to be very invasive and not at all exible. It is
indeed not too easy to nd a way to get the raw ethernet frames with a reasonable overhead.
The most promising solution might be a customNetlter target. Such a target can be loaded
and unloaded from kernel at any time. A well-understood architecture in the kernel and a
userspace utility make Netlter a powerful tool. The Netlter target for the virtual interface
and other known Netlter targets could be combined in any favored way
Another approach might be to use the ip_queue Netlter target which allows the im-
plementation of packet lters in userspace. Due to the necessary context switches, this
solution should not be considered a real alternative.
34 Chapter 8. Conclusions and Future Work
Bibliography
[1] Uppsala University CoRe Group. Aodv-uu. http://core.it.uu.se/AdHoc/AodvUUImpl.
[2] Free Software Foundation. Gnu general public license.
http://www.gnu.org/licenses/gpl.html.
[3] Alessandro Rubini Jonathan Corbet and Greg Kroah-Hartman. Linux Device Drivers.
OReilly Media, 3rd edition, 2005.
[4] Eva-Katharina Kunst Jrgen Quade. Linux Treiber entwickeln. dpunkt.verlag GmbH,
1st edition, 2004.
[5] Cross-Referencing Linux. Lxr. http://lxr.linux.no.
[6] OLSRD Project. Olsr daemon. http://www.olsr.org.
[7] Kai Uwe Rommel. Netio. http://www.ars.de/ars/ars.nsf/docs/netio.
[8] Patrick Stuedi and Gustavo Alonso. Transparent heterogeneous mobile ad hoc
networks. In The Second Annual International Conference on Mobile and Ubiquitous
Systems: Networking and Services. MobiQuitous, San Diego, pages 237246, 2005.
[9] Linux Diagnostic Tools. sysfsutils. http://linux-diag.sourceforge.net/Sysfsutils.html.