Pretoria Mesh: Difference between revisions

From WirelessAfrica
No edit summary
 
(35 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Introduction=
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.
=Visulisation=
=Current Nodes=
=What do I need to connect to PTA mesh?=
==Hardware==
===Node===
This can either be a PC or a [[Wireless Router]].


===Antennae===
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 but still have line of sight issues. Yellow shows people who can have requested a connection and can potentially connect
This can either be bought or home-made(see [[Home-Brew Antennae]]).


===Other===
[[Image:pretoria-mesh-august-small.jpg]]
You will also require cables, a POE convertor, a pole and brackets.


==Firmware==
Your wireless router may require firmware updates that will be made available [ftp://comingsoon here].


==Software==
=Visualisation=
===Routing===
If you are using a PC, you may need to install an OLSR client.
===VPN===
If you want to be part of a Virtual Private Network, you will require VPN software on your client.


==Settings==
=Nodes=
===IP Allocation===
192.***.***.***/**


===OLSR Settings===
Please fill in information about your node e.g. Equipment, Placement (Rooftop), Hardware etc.
HNA:


=How do I put it all together?=
[[Koppie Node]]
Read the [[HowTo]] for more information
 
[[Rodericks Node]]
 
[[Davids Node]]
 
[[Karels Node]]
 
[[Louis Node]]
 
[[Andrews Node]]
 
[[Johns Node]]
 
[[Johanns Node]]
 
Want to join the Pretoria Mesh?
1. Visit [http://www.nodedb.com/africa/za/pretoria/? 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
 
= Network Log 26 July 2006 =
 
Marelie's antenna moved to a higher pole
 
We went to the plot today to put the Grid antenna on the high bluegum pole. Thanks to Craig Taylor's Cherry picker I didn't have to hang 12m up in the air on a very wobbly pole.
 
All went well: A new outdoor router (old aluminium box type) and 24dBi grid was mounted on a metal pole with bottom bracket at the top of the bluegum pole. The cherry picker (an old 60's bedform army truck operated by a Rastafarian) which lifted us to the top of the pole was great fun.
 
= Network Log 26 July 2006 =
 
Optimized some networking settings
 
I discovered the value of setting the BSSID and the fragmentation threshold
 
I noticed that Marelie's link was giving good ping times but performing badly with larger data loads. The framentation threshold allows you to set the threshold in bytes at which point a data block is split up into seperate TCP/IP fragments. With Marelie being a hidden node, and a large amount of interference possible. I set the fragmentation threshold to its lowest at 256 instead of the default 2346.
 
And yipppeee! the link is far more reliable
 
I also set the BSSID to d2:88:6e:34:21:77 which is what the rest of the network connected to the elardus park water tower is using and this also made a big difference in the network stability.
 
The ETX varies between 1.1 and 1.25 which is not bad for an 8km link
 
= Network Log 27 July 2006 =
 
Mesh partitioning problem isolated Marelie from the net. Cleared BSSID from all the nodes, reset water tower and all nodes, fixed again - but need a better solution.
 
BSSID's I've seen:
 
1. d2:88:6e:34:21:77
2. 26:46:6F:34:21:73
 
 
= Network Log 25 August 2006 =
 
Marelie's link has disappeared for about 20 days now due to a fault with the NDIS driver on the water tower (soon to be replaced). But it has reappeared again with BSSID: 26:46:6F:34:21:73. I've locked my node and her node to this BSSID again - maybe the link will hold out until Johann replaces the old soekris boards with the shiny new wrap boards with 802.11a links back to the koppie.

Latest revision as of 22:24, 25 August 2006

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 but still have line of sight issues. Yellow shows people who can have requested a connection and can potentially connect


Visualisation

Nodes

Please fill in information about your node e.g. Equipment, Placement (Rooftop), Hardware etc.

Koppie Node

Rodericks Node

Davids Node

Karels Node

Louis Node

Andrews Node

Johns Node

Johanns Node

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

Network Log 26 July 2006

Marelie's antenna moved to a higher pole

We went to the plot today to put the Grid antenna on the high bluegum pole. Thanks to Craig Taylor's Cherry picker I didn't have to hang 12m up in the air on a very wobbly pole.

All went well: A new outdoor router (old aluminium box type) and 24dBi grid was mounted on a metal pole with bottom bracket at the top of the bluegum pole. The cherry picker (an old 60's bedform army truck operated by a Rastafarian) which lifted us to the top of the pole was great fun.

Network Log 26 July 2006

Optimized some networking settings

I discovered the value of setting the BSSID and the fragmentation threshold

I noticed that Marelie's link was giving good ping times but performing badly with larger data loads. The framentation threshold allows you to set the threshold in bytes at which point a data block is split up into seperate TCP/IP fragments. With Marelie being a hidden node, and a large amount of interference possible. I set the fragmentation threshold to its lowest at 256 instead of the default 2346.

And yipppeee! the link is far more reliable

I also set the BSSID to d2:88:6e:34:21:77 which is what the rest of the network connected to the elardus park water tower is using and this also made a big difference in the network stability.

The ETX varies between 1.1 and 1.25 which is not bad for an 8km link

Network Log 27 July 2006

Mesh partitioning problem isolated Marelie from the net. Cleared BSSID from all the nodes, reset water tower and all nodes, fixed again - but need a better solution.

BSSID's I've seen:

1. d2:88:6e:34:21:77
2. 26:46:6F:34:21:73


Network Log 25 August 2006

Marelie's link has disappeared for about 20 days now due to a fault with the NDIS driver on the water tower (soon to be replaced). But it has reappeared again with BSSID: 26:46:6F:34:21:73. I've locked my node and her node to this BSSID again - maybe the link will hold out until Johann replaces the old soekris boards with the shiny new wrap boards with 802.11a links back to the koppie.