List of Figures

1. A traditional base station scheme compared to an ah-hoc multi-hop network.
2. A scenario that can lead to the ``counting to infinity'' problem.
3. A possible path for a route reply if A wishes to find a route to J.
4. A ZRP scenario showing the zones of node A and node J using a r value of 2. Within the zones a pro-active routing protocol is used while a re-active protocol is used between zones.
5. The different components of the Zone Routing Protocol.
6. The generic OLSR packet.
7. Flooding a packet in a wireless multi-hop network. The arrows show all transmissions.
8. Flooding a packet in a wireless multi-hop network from the center node using MPRs(black). The arrows show all transmissions.
9. Flooding a packet in a wireless multihop network. The arrows show the way information is passed, not all transmissions.
10. Flooding a packet in a wireless multihop network from the center node using MPRs(black). The arrows show the way information is passed, not all transmissions.
11. Node A has selected the black nodes ar its MPRs.
12. An OLSR routed network. The gray nodes are chosen as MPRs by one or more neighbor.
13. The OLSR MID message.
14. A typical neighbor discovery session using HELLO messages.
15. The OLSR HELLO message.
16. the 8 bit Link Code field.
17. Nodes A and B runs OLSR on multiple interfaces. B uses the address of b1 as its main address. Nodes D and C runs on single interfaces(d1 and c1).
18. the OLSR Topology Control message format.
19. OLSR information repositories relation overview.
20. A node in the MANET announces itself as a gateway to Internet for the nodes in the MANET. This is done by HNA messaging.
21. The Host and Network Association message.
22. A would add B as its Internet gateway.
23. The link is set to symmetric at time A and set to asymmetric at time B.
24. The center node has chosen the black nodes as MPRs using a MPR_COVERAGE parameter of 1.
25. The center node has chosen the black nodes as MPRs using a MPR_COVERAGE parameter of 2. Not all two hop neighbors are covered by two MPRs since they are only reachable through one one hop neighbor.
26. olsrd main overview.
27. The socket parser.
28. The socket parser in its initial state passing all OLSR traffic to the packet parser.
29. Overview of the packet-parser.
30. A linked list. It can be one-way linked only following the full lines or double-linked following the dashed lines as well. The last element may point to the first or some predefined value like NULL.
31. A example of a balanced binary-tree. A search will never exceed the depth of the tree in number of seeks. In this example, a lookup will never result in more than 5 seeks.
32. Part of a B-tree. All data is actually stored in the leaf nodes.
33. The olsrd generic data index. A static list of indexes that is used for hashing, where each entry is the root element in a double-linked list.
34. Overview of the olsrd scheduler. When the scheduler polls it records a timestamp $t_1$. When all operations for that poll is done, a second timestamp $t_2$ is recorded. The scheduler then sleeps for $poll interval - (t_2 - t_1)$.
35. The parts of the code protected by the mutex.
36. The connection between the one- and two-hop neighbor sets. All lists are double linked with static root elements.
37. A situation where all nodes will register redundant two hop neighbors.
38. A situation where B registers the addresses of A as two separate nodes before receiving a MID from A if A uses interface1s address as its main address.
39. Node A is running olsrd on two network interfaces. Interface 1 is wireless while interface 2 is an Ethernet interface.
40. A situation where node A should keep a stable Internet gateway by either using G1 or G2, and not alter between them.
41. A IPv6 HNA packet containing one network announcement containing a netmask compared to one containing the prefix length. This prefix approach could also be used on IPv4 HNA messages.
42. The IW spy registration based on an IP address.
43. Example of how a plugin intercepts an application and adds its own program flow.
44. An example of how a plugin can enable the OLSR daemon to work as a relay for broadcasting. The Local application and the plugin communicate using interprocess communication.
45. A plugin can manipulate virtually every part of the olsr daemon.
46. The plugin initialization process.
47. The message format used by the power-status plugin. This data is sent as the data part of a regular OLSR message.
48. The main screen displays a list of known nodes and information about them.
49. The packet screen offers OLSR packet sniffing.
50. The route screen displays all active OLSR routes.
51. The settings screen displays information about the local nodes settings.
52. The internal design of the olsrd GUI client.
53. The test setup used for local usage testing. The links from A to B and C are altering(the link alters between A->B and A->C every 45 seconds). Node G announces Internet connectivity.
54. A topology setup used for OLSR overhead registration.
55. Overhead of OLSR control traffic at the test network set up at WoS3.
56. The scenario used for the real life implementation of the attack described in section 11.2.1. Node B has Internet connectivity and declares itself as a HNA gateway to the Internet.
57. What node B in the scenario from figure 11.1 sees when requesting http://www.slashdot.org in its local web browser. This is obviously a forged version of the real slashdot page. Note the hostname in the address bar.
58. The basic signature message as used in the implementation. This is sent as the message body of an olsr message.
59. The timestamp exchange challenge message. This is sent as the message body of an olsr message.
60. The timestamp exchange challenge-response message. This is sent as the message body of an olsr message.
61. The timestamp exchange response-response message. This is sent as the message body of an olsr message.
62. A replay attack on OLSR. The attacker records signed messages and plays them back on a later stage or to nodes that has no record of the sequence numbers of some of the recorded messages.
63. A illustration of the design of the secure plugin as related to olsrd.
64. The basic layout of the PAA solution.
65. The generic PAA packet.
66. The Forward Request message.
67. The Address Request message.
68. The Address Response message.
69. The Address Test message.
70. The Address Test Confirmation message.
71. An example of a conflictless PAA IP allocation session.
72. The flow of the IPv4 PAA-client.
73. The PAA-server operations.
74. The PAA-plugin.
75. The configured nodes A and B looses connectivity. A then configures a new node with address C. B also configures a new node with address C. A and B then reconnect, merging the networks. This leads to an address conflict amongst the already configured nodes C and C.
76. Node alters between having connection with Intermediate Node 1(IN1) and Intermediate Node 2(IN2) causing Internet traffic to alter between being routed through Gateway1(GW1) and Gateway2(GW2).
77. Using gateways without NAT. The TCP connection stays up. This solution requires a globally route-able address for the MANET host.
78. The TCP connection breaks just as A moves from IN1 to IN2 because the gateways use NET.
79. Using unidirectional UDP traffic from the MANET host to an Internet host through NAT gateways.
80. The TCP connection stays up due to explicit tunneling to one of the gateways. Throughput varies based on the route used.
81. A scenario where A has set up a tunnel to GW1 and routes all Internet destined traffic through this tunnel. The leftmost figure shows the traffic path when A has a bidirectional link to IN1. The rightmost figure shows the path of the Internet traffic when A only has a bidirectional link to IN2.
82. Setting up a tunnel to connect two external networks.