The CSIR Pretoria mesh network was setup as a test-bed mesh network in order to get an understanding of the issues that face real-world, outdoor mesh networks. Some of these issues include LOS (Line of Sight), Weather Proofing and the Hidden Node problem.
Below is a diagram showing the current status of the mesh network, green nodes show people who are currently connected, red nodes show people who would like to be connected in the future
- Please fill in information about your node e.g. Equipment, Placement (Rooftop), Hardware etc.
Want to join the Pretoria Mesh?
1. Visit NodeDB and create a node for yourself. 2. Build a node. Read the HowTos for more information on building your own node. 3. Get Pretoria Mesh Settings and configure your node.
Network Log 30 January 2006
Elardus Park went down at 5:50PM (omni and directional) after a heavy raintorm - I'll climb up tomorrow morning and have a look.
Network Log 1 May 2006
I noticed that the elardus park tower would often lose its routing information for the elardus park mesh so I did a bit of research on the olsrd.conf file. Here is what I discovered
The /usr/local/etc/olsrd.conf file had the following settings
HelloInterval 3.0 HelloValidityTime 9.0 (default 3xHelloInterval) TCInterval 5.0 TCValidityTime 15.0 (default) MidInterval 5.0 (default) MidValidityTime 15.0 (default) HnaInterval 5.0 HnaValidityTime 15.0
With the validity times being so short, a large file downnload would saturate the traffic and occasionally not allow a hello packet through allowing the routing info to expire after the validity time which was 15 seconds for TC
I changed the interval settings to those found in Freifunk firmware which are better suited for static meshes like ours, the intervals were set to:
HelloInterval 5.0 HelloValidityTime 90.0 TcInterval 15.0 TcValidityTime 90.0 MidInterval 15.0 MidValidityTime 90.0 HnaInterval 15.0 HnaValidityTime 90.0
Lets hope the network is more stable now!
P.S. To change the /usr/local/etc/olsrd.conf on the soekris running freeBSD you must do the following
mount -u -w / vi /usr/local/etc/olsrd.conf sync mount -u -r /
Network Log 5 May 2006
Added Chris Krause onto network
WiFi: 10.1.1.52 LAN: 10.3.52.1
What a mission - for some reason his Linksys with OpenWRT refused to work in client mode - I had to use our old SVEASOFT ZULU release that we built with RIP at the end of 2004 and flash it to an old Linksys 2.2 that I had lying around.
Network Log 10 May 2006
Added Marelie Davel onto network
WiFi: 10.51.1.23 LAN: 10.3.23.1
Discovered major problem with new Freifunk firmware
If you have a '-' in the ssid it interprets this as a command line option So "pta-mesh" caused the wireless interface to fail
Had to change all mesh node in the Pretoria wireless network to "ptamesh"
When I changed Rodericks to "ptamesh" and reboot a very weird thing happened After logging in and checking the state of the wireless interface here is what I found:
rodrick2istc# ifconfig wi0 wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe25:5fae%wi0 prefixlen 64 scopeid 0x4 inet 10.50.1.1 netmask 0xffffff00 broadcast 10.50.1.255 ether 00:02:2d:25:5f:ae media: IEEE 802.11 Wireless Ethernet autoselect mode 11b <adhoc> (DS/11Mbps <adhoc>) status: associated ssid "Sector 2" channel 4 bssid 00:0b:6b:37:45:2b stationname "FreeBSD WaveLAN/IEEE node" authmode OPEN privacy OFF txpowmax 100 bintval 100
Huh!! How did it change it's ssid to 'Sector 2 and channel to 4 when it should be ssid: ptamesh, channel 11!!!!!! Is someone taking over the node?
Network Log 15 May 2006
The Elardus park mesh is still having problems with routing tables disappearing between my node and the water tower.
The Soekris on the water tower is running OLSR build 0.4.9 whereas the Linksys is running OLSR build 0.4.10-pre There could be some minor protocol differences between them which I suspect is causing the problem
Running olsrd in debug mode on the soekris gives me the following errors
10.51.1.12:INF <- 10.51.1.12 FAILED 10.51.1.13:INF <- 10.51.1.13 FAILED 10.51.1.14:INF <- 10.51.1.14 FAILED 10.51.1.20:INF <- 10.51.1.20 FAILED Updating kernel routes... mid set: 23:06:07.405772
Processing TC from 10.51.1.14 Received TC from NON SYM neighbor 10.51.1.13 Unknown type: 130, size 64, from 10.51.1.13 Processing TC from 10.51.1.12 Received TC from NON SYM neighbor 10.51.1.13 Received HNA from NON SYM neighbor 10.51.1.13 Received HNA from NON SYM neighbor 10.51.1.13
Network Log 18 June 2006
Strange things happening at Elardus park ETX to tower from my house now at 2.2 with about 50% of packets being lost
Checked settings at Elardus Park ssid is empty?? similar problem to Rodericks that had its ssid changed
ndis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:6fff:fe34:21cb%ndis0 prefixlen 64 scopeid 0x1 inet 10.51.1.1 netmask 0xffffff00 broadcast 10.51.1.255 ether 00:02:6f:34:21:cb media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps <adhoc>) status: associated ssid "" channel 1 authmode OPEN privacy OFF txpowmax 100 protmode CTS
Could it be interference on channel 1 (Louis has an AP near him on channel 3 which can cause interference on channel 1 - maybe when the network is quite I'll do a channel change and check
Network Log 19 June 2006
Captains log Stardate 2006
Changed elarduspark network to channel 11
Looks like it was an interference problem, after changing the channel on all the nodes to channel 11, the ETX values recovered to good levels again
IP Hysteresis LinkQuality lost total NLQ ETX 10.51.1.1 0.00 0.94 6 100 1.00 1.06 10.51.1.20 0.00 0.86 14 100 1.00 1.16 10.51.1.12 0.00 0.81 19 100 1.00 1.23 10.51.1.14 0.00 0.89 11 100 1.00 1.12
The strange ssid problem on Elardus Park is apparently just a bug in the reporting tool of FreeBSD
- HELP ***
PERHAPS NOT THE CORRECT PLACE TO POST THIS MESSAGE BUT COULD ANYONE ASSIST IN CONNECTING TO THE ELARDUSPARK TOWER.
I'M ABOUT 1 KM FROM THE TOWER HOWEVER DON'T HAVE LINE OF SIGHT. IT WOULD APPEAR THAT I NEED TO HAVE LINE OF SIGHT, OTHERWISE MY 802.11 CARD WONT PICK UP PTAMESH.
ANY HELP MUCH APREACIATED.