OLSR Interop - technical parameters

Comments

Comments and suggestions are very welcome (at cedric.adjih@inria.fr).

See also the: OFFICIAL OLSR Interop Page

OLSR Interop Test Program

Schedule is: interop the afternoon, maybe with pre-interop the morning.
TO BE DEFINED

Hardware

The interop would be performed with 2 kind of equipements:

802.11b equipement.
Ethernet equipement (10 Mbps).

Wireless configuration

Channel: 11
ESSID: OLSR
Mode: Ad-Hoc IBSS (or Ad-Hoc Demo?)

Multicast/Broadcast Addresses

The OLSR protocol UDP packets should be sent with the following parameters:

UDP port: 698
IPv4 broadcast address: 255.255.255.255
IPv6 multicast address: ff02::1 (or ff0e::1 ? which has been suggested)

Addresses

IPv4 Address

Each participant in the interop will have a range of 255 addresses allocated:

10.1.<participant id>.<free choice>/255.255.0.0 for wired (note the netmask).
10.2.<participant id>.<free choice>/255.255.0.0 for the normal wireless channel (note the netmask).

To get a participant id, just ask :-), see below

IPv6 Addresses

Each participant in the interop could use the following IPv6 addresses:

the unique local prefix FD51:F2D1:91AD:0000:/64 with IEEE EUI-64 suffix of their interface.
or alternatively: FD51:F2D1:91AD:0000:0000:<participant id>:<implementation id>:<free choice>/64

Participants (with machine(s))

Identifier	Name	Equipement
1	INRIA	one Linux laptop (implementation OOLSR, 802.11b+ethernet), IPv4=10.1.1.1 and IPv6=FD51:F2D1:91AD::1:1:1
2	Hitachi	Equipment = 2 Linux laptop (impl. HOLSR, 11b + Eth) and 2 Zaurus PDA , IPv4 = 10.x.2.1-4
3	LRI	-
4	BAE Systems	one laptop (and maybe one PDA (iPAQ)). 10.x.4.1 (and 10.x.4.2)
5	CRC	-
...	...	...
11	NRL (Navy)	One sharp zaurus, one toshiba wince, one linux box, and one windows xp box. Running nrlolsrdv7.4.
.	.	.
.	.	.
.	.	.
.	.	.
.	.	.
.	.	.
.	.	.
.	.	.

If you want to have an "participant identifier" allocated and/or you want to be on this list, please ask either on Friday, or at cedric.adjih@inria.fr, [you may specify the content of the fields of the table if you want to be publically listed].

Implementations

Identifier	Name	IPv4,IPv6	Comment	Link
1	OOLSR	IPv4,IPv6	INRIA implementation	(on demand, not [yet] publically released)
2	HOLSR	IPv4 (IPv6 under devlp)	Hitachi implementation	non-disclosable
3	Qolyester	IPv4, IPv6	LRI implementation	qolyester page
4	BAE SYSTEMS	IPv4, IPv6	BAE SYSTEMS implementation	non-diclosable
5	CRC	-	-	-
11	nrlolsrd	IPv4, IPv6	NRL	NRL OLSR&tools page
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.
.	.	.	.	.

If you want to have an "implementation identifier" allocated and/or you want to be on this list, please either ask Friday (or mail to cedric.adjih@inria.fr) [you may specify the content of the fields of the table if you want to be publically listed].

Things useful to check

Driver (Linux)

The wireless should be able to run in IBSS mode: some problems have been found with the wavelan2 for instance. Also the "ad-hoc demo mode" (non-standard, different from ad-hoc IBSS) should not be use (i.e. something like iwconfig eth1 get_port3 should return 0).

IP configuration

For IPv4, the following is suggested:

Activate IPv4 routing on the node: echo 1 > /proc/sys/net/ipv4/ip_forward
Desactivate IPv4 ICMP redirects, with something like:
echo 0 > /proc/sys/net/ipv4/conf/XXX/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/XXX/send_redirects

The following may solve specific problems:

If the implementation doesn't bind the socket to the interface, route add 255.255.255.255 dev eth1 may be useful (for one interface OLSR nodes),
Remove possible filtering which is in:
/proc/sys/net/ipv4/conf/*/rp_filter
What removing this filtering do, is: to accept packets from a different network+netmask that the one of the receiving interface. This actually increases problems (setting up routes), and is not useful if all the nodes are configurated with addresses 10.2.x.x and 10.1.x.x anyway.
iptables filters may be used to create more complex topologies.

IPtables IPv4

To ignore one machine:

iptables -A INPUT --proto udp --source <machine ip> --dport 698  -j DROP

Enable IPv4 forwarding (Windows)

From winguides.com: Open your registry and find or create the key below. Create a new DWORD value, or modify the existing value, called "IPEnableRouter" and set it according to the value data below. Exit your registry, you may need to restart or log out of Windows for the change to take effect.

 
System Key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
Value Name: IPEnableRouter
Data Type: REG_DWORD (DWORD Value)
Value Data: (0 = disabled, 1 = enabled)