http://wirelessafrica.meraka.org.za/wiki/api.php?action=feedcontributions&feedformat=atom&user=JHugo 2026-05-30T14:05:52Z User contributions MediaWiki 1.45.3 http://wirelessafrica.meraka.org.za/wiki/index.php?title=HPN_to-do/done_page&diff=4669 2009-06-02T13:02:36Z

<p>JHugo: New page: == HPN version 1 - To-do/done == === Done === ==== Nodes: ==== Automatic, Multi Radio configuration and meshing (using OLSR mesh protocol) Automatic IPv6 addressing Automatic IPv4 addr...</p> <hr /> <div>== HPN version 1 - To-do/done ==<br /> <br /> === Done ===<br /> ==== Nodes: ====<br /> Automatic, Multi Radio configuration and meshing (using OLSR mesh protocol)<br /> Automatic IPv6 addressing<br /> Automatic IPv4 addressing<br /> Automatic IPv4 over IPv6 tunneling<br /> End-to-end connectivity in the mesh over IPv4 or IPv6<br /> Automatic time synchronization with GateWay via ntp time protocol<br /> Automatic &quot;Node Name&quot; generation and registration into DNS<br /> Automatic HotSpot setup<br /> Automatic DHCP and DNS services on Ethernet and Wifi hotspot<br /> Automatic router advertising on IPv6<br /> Automatic OLSR HNA advertising of Ethernet and hotspot subnets<br /> Automatic OLSR HNA advertising of all 4over6 tunnels<br /> IPv6 enabled Web server<br /> Remote management via ssh<br /> Command line routing information<br /> Command line signal strenth indicator<br /> &quot;OLSR vis&quot; network visualization tool<br /> Intergated and external watchdog<br /> Automatic firmware checking and updating if it's available<br /> Automatic hunting / channel selection function<br /> Green/red node selection - in startup scripts + after hunting<br /> Shell scripts for signal strength display / alignment<br /> <br /> ==== GateWay: ====<br /> Automatic time synchronization and NTP server for the mesh<br /> Automatic DNS server for the mesh<br /> Automatic Default Gateway advertising into the mesh via OLSR<br /> <br /> === To-do: ===<br /> ==== Nodes: ====<br /> Automatic hunting / activate in GUI - on next boot or online<br /> Red/Green selection via GUI<br /> LED display function - visual status of link connectivity<br /> FreeBSD device driver for LEDs<br /> Hostname update via GUI<br /> info.txt generation during bootup<br /> Web interface for node with configuration / statistics<br /> Alignment tool (under Web interface)<br /> fix auto IPv4 subnet selection (avila MAC byte swap)<br /> Change default diversity settings in rc.conf.mesh<br /> Change default channel/BSSID settings in rc.conf.mesh<br /> Change default ack timoutout settings in rc.conf.mesh for 10km<br /> Generate new IPv6 prefix for APEX<br /> Attend to olsr multipath smooth changeover<br /> External watchdog board<br /> Upgrade to FreeBSD 7.2 ?<br /> <br /> ==== GateWay: ====<br /> Automatic gateway selection function ?<br /> Settings for DHCP, IPv4 addr, Default GW, DNS server, NTP server<br /> Change these setting via GUI<br /> Synchronize with upstream DNS server<br /> Synchronize with upstream NTP time server<br /> FTP server for firmware updates<br /> <br /> ==== Backbone backend ====<br /> Procure server<br /> OS + software on server<br /> Monitoring of backbone ?<br /> SANREN connection ?</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=Johann%27s_Research&diff=4668 2009-06-02T10:26:23Z

<p>JHugo: /* HPN design discussions page */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]]<br /> <br /> I'm not sure if my stuff is really research, but this is some of the stuff that I'm busy with:<br /> <br /> <br /> <br /> <br /> <br /> == [[High performance node page]] ==<br /> <br /> == [[HPN design discussions page]] ==<br /> <br /> == [[HPN to-do/done page]] ==<br /> <br /> == [[APEX backbone]] ==<br /> <br /> == [[Installing cacti on FreeBSD]] ==<br /> <br /> == [[Community wireless networks ]] ==<br /> <br /> == [[EeePC and FreeBSD page]] ==<br /> <br /> <br /> <br /> == [[Meraka wireless Network]] ==<br /> <br /> == [[VOIP page]] ==</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4667 2009-05-28T13:12:03Z

<p>JHugo: /* Throughput tests */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini.<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following network throughput tests was performed between Meraka and each one of the remote sites. The measurement tool used for the benchmarking is [http://sourceforge.net/projects/iperf iperf]<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=190.682 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=90.929 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=93.045 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 90.929/124.885/190.682/46.533 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 59898 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 5.12 MBytes '''2.55 Mbits/sec'''</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4666 2009-05-28T13:11:41Z

<p>JHugo: /* Throughput tests */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini.<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following network throughput tests was performed between Meraka and each one of the remote sites. The measurement tool used for the benchmarks is [http://sourceforge.net/projects/iperf iperf]<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=190.682 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=90.929 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=93.045 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 90.929/124.885/190.682/46.533 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 59898 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 5.12 MBytes '''2.55 Mbits/sec'''</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4665 2009-05-28T13:06:29Z

<p>JHugo: /* Throughput tests */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini.<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following network throughput tests was performed between Meraka and each one of the remote sites. The measurement tool used for the benchmarks is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=190.682 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=90.929 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=93.045 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 90.929/124.885/190.682/46.533 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 59898 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 5.12 MBytes '''2.55 Mbits/sec'''</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4664 2009-05-28T13:03:19Z

<p>JHugo: /* Motorola Backbone */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini.<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=190.682 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=90.929 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=93.045 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 90.929/124.885/190.682/46.533 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 59898 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 5.12 MBytes '''2.55 Mbits/sec'''</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4663 2009-05-28T12:59:59Z

<p>JHugo: /* Mbuzini (May 27 10:00) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=190.682 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=90.929 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=93.045 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 90.929/124.885/190.682/46.533 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 59898 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 5.12 MBytes '''2.55 Mbits/sec'''</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4662 2009-05-28T12:59:10Z

<p>JHugo: /* Lamomahsa (May 27 07:50) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=221.202 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=105.278 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=106.097 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 105.278/144.192/221.202/54.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.98 MBytes '''2.49 Mbits/sec'''<br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4661 2009-05-28T12:58:23Z

<p>JHugo: /* Mariepskop (May 26 13:36) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes '''2.51 Mbits/sec'''<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4660 2009-05-28T12:58:00Z

<p>JHugo: /* Mariepskop (May 26 13:36) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=147.200 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=76.803 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=73.115 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 73.115/99.039/147.200/34.088 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.7 sec 5.00 MBytes 2.51 Mbits/sec<br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4659 2009-05-28T12:57:21Z

<p>JHugo: /* Kiepersol (May 26 11:28) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes '''2.33 Mbits/sec'''<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4658 2009-05-28T12:57:05Z

<p>JHugo: /* Kiepersol (May 26 11:28) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=140.747 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=71.639 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=68.055 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 68.055/93.480/140.747/33.455 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.8 sec 4.67 MBytes 2.33 Mbits/sec<br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4657 2009-05-28T12:56:10Z

<p>JHugo: /* Mauschberg (May 26 09:29) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 0 packets received, 100.0% packet loss<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 60826 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-16.7 sec 4.93 MBytes '''2.48 Mbits/sec'''<br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4656 2009-05-28T12:54:30Z

<p>JHugo: /* Dullstroom (May 26 08:08) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=79.477 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=36.974 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=37.003 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 36.974/51.151/79.477/20.029 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 49707 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.3 sec 6.91 MBytes '''3.56 Mbits/sec'''<br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4655 2009-05-28T12:53:41Z

<p>JHugo: /* Garangkuva (May 22 10:29) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=24.918 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=11.442 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=10.283 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 10.283/15.548/24.918/6.643 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 4] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 4] 0.0-15.8 sec 9.01 MBytes '''4.77 Mbits/sec'''<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4654 2009-05-28T12:52:33Z

<p>JHugo: /* Renosterkop (May 21 09:34) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4653 2009-05-28T12:52:15Z

<p>JHugo: /* Duhva (May 21 16:49) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> <br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=82.330 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=39.529 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=42.279 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 39.529/54.713/82.330/19.561 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 3] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0-16.5 sec 6.19 MBytes '''3.15 Mbits/sec'''<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4652 2009-05-28T12:51:06Z

<p>JHugo: /* Lammerskop (May 21 13:37) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> <br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes '''3.17 Mbits/sec'''<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4651 2009-05-28T12:50:35Z

<p>JHugo: /* Renosterkop (May 21 09:34) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> <br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes 3.17 Mbits/sec<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4650 2009-05-28T12:50:17Z

<p>JHugo: /* Renosterkop (May 21 09:34) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> <br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes 3.17 Mbits/sec<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4649 2009-05-28T12:49:27Z

<p>JHugo: /* Renosterkop (May 21 09:34) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms <br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes '''3.97 Mbits/sec'''<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes 3.17 Mbits/sec<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4648 2009-05-28T12:48:09Z

<p>JHugo: /* Lammerskop (May 21 13:37) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes 3.97 Mbits/sec<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=55.760 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=25.314 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=23.425 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 23.425/34.833/55.760/14.818 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 60571 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.5 sec 6.22 MBytes 3.17 Mbits/sec<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4647 2009-05-28T12:45:31Z

<p>JHugo: /* Renosterkop (May 21 09:34) */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> <br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes 3.97 Mbits/sec<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4646 2009-05-28T11:03:59Z

<p>JHugo: /* Motorola Backbone */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network build with Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===<br /> <br /> The following benchmarks are for network throughputs between Meraka and each one of the remote sites. The measurement tool that was uses is iperf<br /> <br /> === Renosterkop (May 21 09:34) ===<br /> Meraka:<br /> <br /> Remote:<br /> PING 192.168.10.254 (192.168.10.254): 56 data bytes<br /> 64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=40.677 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=1 ttl=64 time=19.507 ms<br /> 64 bytes from 192.168.10.254: icmp_seq=2 ttl=64 time=19.293 ms<br /> <br /> --- 192.168.10.254 ping statistics ---<br /> 3 packets transmitted, 3 packets received, 0.0% packet loss<br /> round-trip min/avg/max/stddev = 19.293/26.492/40.677/10.030 ms<br /> ------------------------------------------------------------<br /> Server listening on TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> ------------------------------------------------------------<br /> ------------------------------------------------------------<br /> Client connecting to 192.168.10.254, TCP port 5001<br /> TCP window size: 32.5 KByte (default)<br /> ------------------------------------------------------------<br /> [ 5] local 192.168.10.222 port 61471 connected with 192.168.10.254 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 5] 0.0-16.1 sec 7.62 MBytes 3.97 Mbits/sec<br /> <br /> === Lammerskop (May 21 13:37) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Duhva (May 21 16:49) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Garangkuva (May 22 10:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> === Dullstroom (May 26 08:08) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mauschberg (May 26 09:29) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Kiepersol (May 26 11:28) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mariepskop (May 26 13:36) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Lamomahsa (May 27 07:50) ===<br /> Meraka:<br /> <br /> Remote:<br /> <br /> <br /> === Mbuzini (May 27 10:00) ===<br /> Meraka:<br /> <br /> Remote:</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4638 2009-05-25T14:15:37Z

<p>JHugo: /* Motorola Backbone */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network, build by Motorola, using Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4637 2009-05-25T08:16:29Z

<p>JHugo: /* Motorola Backbone */</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network, build by Motorola, using Motorola cannopy equipment.<br /> The network starts at Meraka and goes right up-to Mariepskop and then down to Mbuzini. See picture:<br /> <br /> [[Image:Backbone2.png]]<br /> <br /> === Throughput tests ===</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=APEX_backbone&diff=4636 2009-05-25T08:14:58Z

<p>JHugo: New page: == Motorola Backbone == The Motorola backbone is a wireless network, build by Motorola, using Motorola cannopy equipment. Image:Backbone2.png === Throughput tests ===</p> <hr /> <div>== Motorola Backbone ==<br /> <br /> The Motorola backbone is a wireless network, build by Motorola, using Motorola cannopy equipment.<br /> <br /> Image:Backbone2.png<br /> <br /> === Throughput tests ===</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=File:Backbone2.png&diff=4635 2009-05-25T08:09:56Z

<p>JHugo: </p> <hr /> <div></div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=Johann%27s_Research&diff=4634 2009-05-25T07:56:52Z

<p>JHugo: /* HPN design discussions page */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]]<br /> <br /> I'm not sure if my stuff is really research, but this is some of the stuff that I'm busy with:<br /> <br /> <br /> <br /> <br /> <br /> == [[High performance node page]] ==<br /> <br /> == [[HPN design discussions page]] ==<br /> <br /> == [[APEX backbone]] ==<br /> <br /> == [[Installing cacti on FreeBSD]] ==<br /> <br /> == [[Community wireless networks ]] ==<br /> <br /> == [[EeePC and FreeBSD page]] ==<br /> <br /> <br /> <br /> == [[Meraka wireless Network]] ==<br /> <br /> == [[VOIP page]] ==</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4633 2009-05-21T13:47:19Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * Each HPN node is equipped with two 5.8Ghz wifi adapters and antennas (panel and omni) that is used to build the backbone. Each one of these adapters is configured to operate on a specific wifi frequency that is also tied to a specific wifi channel. In order to make our HPN more user friendly we decided to assign these two channels to the colours &quot;red&quot; and &quot;green&quot;. The HPN node then inherit what ever colour is assigned to the directional panel antenna on the front. <br /> <br /> This means that when the &quot;green&quot; channel is configured on the panel antenna, then the &quot;red&quot; is used on the omni and we will refer to the HPN node as a GREEN node. If the &quot;red&quot; channel is used on the panel, then we talk about a RED node and the &quot;green channel is used on the omni. The default setting for a new node is to be a GREEN node and it can be changed to a RED node via the web interface.<br /> <br /> When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. There are lots of possible different ways to do this hunting. We decided to implement a very simple and easy algorithm until someone gets 'n new bright ideas. The following paragraphs describes our current implementation of our hunting procedure with our [[Initial (old) hunting description]] here.<br /> <br /> A HPN node will always start to search for connectivity on the panel antenna, fist on the same colour as the node, and then on the other colour. If no connectivity can be found, then it will hunt on the omni-directional antenna, first on opposite colour as the node, and then on the same colour. This sequence will repeat itself, until connectivity can be found to another node in the network. At this time the channels will be locked the colour of the node will be the same as the colour used on the panel antenna. This setting will stay the same, even across a reboot or power failure, until someone overrides it via the web interface.<br /> <br /> Lets take a new GREEN node for a example. When it boots up for the first time then it will come up in the hunting mode. It will first configure the patch antenna on the &quot;green&quot; channel. Then it will perform a link local IPv6 ping on that interface for about 3 seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after 3 seconds, then it will hunt further using the &quot;red&quot; channel on the patch, then &quot;red&quot; on the omni and then &quot;green&quot; on the omni.<br /> <br /> If no connectivity can be found, then it will start the hunting process from the beginning again, or until it is manually locked via the WEB interface. If connectivity can be established, then it will lock the node with the current settings. It will also enable the green/red link LED on the bottom of the node to show connectivity on that channel (The WEB interface can be used to get more information of which node connectivity has been established to). If connectivity is lost then the LED will turn off again. <br /> <br /> See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow2.png]]<br /> <br /> Note that this hunting procedure does not always end up in the best routing solution and it is not a replacement for common sense. <br /> <br /> Future improvements:<br /> - In scenarios where connectivity is possible to another node, on both the panel and omni, <br /> then our current algorithm will always select the panel, even if the omni may be a better choice.<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be override via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and distributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdog toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4632 2009-05-21T13:46:29Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * Each HPN node is equipped with two 5.8Ghz wifi adapters and antennas (panel and omni) that is used to build the backbone. Each one of these adapters is configured to operate on a specific wifi frequency that is also tied to a specific wifi channel. In order to make our HPN more user friendly we decided to assign these two channels to the colours &quot;red&quot; and &quot;green&quot;. The HPN node then inherit what ever colour is assigned to the directional panel antenna on the front. <br /> <br /> This means that when the &quot;green&quot; channel is configured on the panel antenna, then the &quot;red&quot; is used on the omni and we will refer to the HPN node as a GREEN node. If the &quot;red&quot; channel is used on the panel, then we talk about a RED node and the &quot;green channel is used on the omni. The default setting for a new node is to be a GREEN node and it can be changed to a RED node via the web interface.<br /> <br /> When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. There are lots of possible different ways to do this hunting. We decided to implement a very simple and easy algorithm until someone gets 'n new bright ideas. The following paragraphs describes our current implementation of our hunting procedure with our [[Initial (old) hunting description]] here.<br /> <br /> A HPN node will always start to search for connectivity on the panel antenna, fist on the same colour as the node, and then on the other colour. If no connectivity can be found, then it will hunt on the omni-directional antenna, first on opposite colour as the node, and then on the same colour. This sequence will repeat itself, until connectivity can be found to another node in the network. At this time the channels will be locked the colour of the node will be the same as the colour used on the panel antenna. This setting will stay the same, even across a reboot or power failure, until someone overrides it via the web interface.<br /> <br /> Lets take a new GREEN node for a example. When it boots up for the first time then it will come up in the hunting mode. It will first configure the patch antenna on the &quot;green&quot; channel. Then it will perform a link local IPv6 ping on that interface for about 3 seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after 3 seconds, then it will hunt further using the &quot;red&quot; channel on the patch, then &quot;red&quot; on the omni and then &quot;green&quot; on the omni.<br /> <br /> If no connectivity can be found, then it will start the hunting process from the beginning again, or until it is manually locked via the WEB interface. If connectivity can be established, then it will lock the node with the current settings. It will also enable the green/red link LED on the bottom of the node to show connectivity on that channel (The WEB interface can be used to get more information of which node connectivity has been established to). If connectivity is lost then the LED will turn off again. <br /> <br /> See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow2.png]]<br /> <br /> Note that this hunting procedure does not always end up in the best routing solution and it is not a replacement for common sense. <br /> <br /> Future improvements:<br /> - In scenarios where connectivity is possible to another node, on both the panel and omni, then our current algorithm will always select the panel, even if the omni may be a better choice.<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be override via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and distributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdog toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4631 2009-05-21T13:27:23Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * Each HPN node is equipped with two 5.8Ghz wifi adapters and antennas (panel and omni) that is used to build the backbone. Each one of these adapters is configured to operate on a specific wifi frequency that is also tied to a specific wifi channel. In order to make our HPN more user friendly we decided to assign these two channels to the colours &quot;red&quot; and &quot;green&quot;. The HPN node then inherit what ever colour is assigned to the directional panel antenna on the front. <br /> <br /> This means that when the &quot;green&quot; channel is configured on the panel antenna, then the &quot;red&quot; is used on the omni and we will refer to the HPN node as a GREEN node. If the &quot;red&quot; channel is used on the panel, then we talk about a RED node and the &quot;green channel is used on the omni. The default setting for a new node is to be a GREEN node and it can be changed to a RED node via the web interface.<br /> <br /> When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. There are lots of possible different ways to do this hunting. We decided to implement a very simple and easy algorithm until someone gets 'n new bright ideas. The following paragraphs describes our current implementation of our hunting procedure with our [[Initial (old) hunting description]] here.<br /> <br /> A HPN node will always start to search for connectivity on the panel antenna, fist on the same colour as the node, and then on the other colour. If no connectivity can be found, then it will hunt on the omni-directional antenna, first on opposite colour as the node, and then on the same colour. This sequence will repeat itself, until connectivity can be found to another node in the network. At this time the channels will be locked the colour of the node will be the same as the colour used on the panel antenna. This setting will stay the same, even across a reboot or power failure, until someone overrides it via the web interface.<br /> <br /> Lets take a new GREEN node for a example. When it boots up for the first time then it will come up in the hunting mode. It will first configure the patch antenna on the &quot;green&quot; frequency. It will perform a link local IPv6 ping on that interface for about 3 seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after 3 seconds, then it will hunt further using the &quot;red&quot; channel on the patch, then the &quot;red&quot; channel on the omni and then &quot;green&quot; on the omni.<br /> <br /> If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB interface. If connectivity can be established, then it will lock the node with the current settings. It will also enable the green/red link LED on the bottom of the node to show connectivity on that channel (The WEB interface can be used to get more information of which node connectivity has been established to). If connectivity is lost then the LED will turn off again. <br /> <br /> See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow2.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be override via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and distributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdog toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4630 2009-05-21T13:24:54Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * Each HPN node is equipped with two 5.8Ghz wifi adapters and antennas (pannel and omni) that is used to build the backbone. Each one of these adapters is configured to operate on a specific wifi frequency that is also tied to a specific wifi channel. In order to make our HPN more user friendly we decided to assign these two channels to the colours &quot;red&quot; and &quot;green&quot;. The HPN node then inherit what ever colour is assigned to the directional pannel antenna on the front. <br /> <br /> This means that when the &quot;green&quot; channel is configured on the pannel antenna, then the &quot;red&quot; is used on the omni and we will refer to the HPN node as a GREEN node. If the &quot;red&quot; channel is used on the pannel, then we talk about a RED node and the &quot;green channel is used on the omni. The default setting for a new node is to be a GREEN node and it can be changed to a RED node via the web interface.<br /> <br /> When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. There are lots of possible different ways to do this hunting. We decided to implement a very simple and easy algorithm until someone gets 'n new bright ideas. The following paragraphs describes our current implementation of our hunting procedure with our [[Initial (old) hunting description]] here.<br /> <br /> A HPN node will always start to search for connectivity on the pannel antenna, fist on the same colour as the node, and then on the other colour. If no connectivity can be found, then it will hunt on the omni-directional antenna, first on opposite colour as the node, and then on the same colour. This sequence will repeat itself, until connectivity can be found to another node in the network. At this time the channels will be locked the colour of the node will be the same as the colour used on the pannel antenna. This setting will stay the same, even across a reboot or power failure, until someone overrides it via the web interface.<br /> <br /> Lets take a new GREEN node for a example. When it boots up for the first time then it will come up in the hunting mode. It will first configure the patch antenna on the &quot;green&quot; frequency. It will perform a link local IPv6 ping on that interface for about 3 seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after 3 seconds, then it will hunt further using the &quot;red&quot; channel on the patch, then the &quot;red&quot; channel on the omni and then &quot;green&quot; on the omni.<br /> <br /> If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB interface. If connectivity can be established, then it will lock the node with the current settings. It will also enable the green/red link LED on the bottom of the node to show connectivity on that channel (The WEB interface can be used to get more information of wich node connectivity has been established to). If connectivity is lost then the LED will turn off again. <br /> <br /> See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow2.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4629 2009-05-21T12:26:30Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> [[Initial (old) hunting description]]<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow2.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=File:Hunt-flow2.png&diff=4628 2009-05-21T12:25:57Z

<p>JHugo: </p> <hr /> <div></div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=Initial_(old)_hunting_description&diff=4627 2009-05-21T12:24:29Z

<p>JHugo: </p> <hr /> <div>When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below. <br /> <br /> [[Image:Hunt-flow-diag.png]]</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=Initial_(old)_hunting_description&diff=4626 2009-05-21T12:21:46Z

<p>JHugo: New page: * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch ant...</p> <hr /> <div> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below. <br /> <br /> Image:Hunt-flow-diag.png</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4625 2009-05-21T12:21:28Z

<p>JHugo: /* Initial (old) hunting description */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> [[Initial (old) hunting description]]<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4624 2009-05-21T12:21:06Z

<p>JHugo: /* Initial (old) hunting description */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> = [[Initial (old) hunting description]] =<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4623 2009-05-21T12:20:38Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> == [[Initial (old) hunting description]] ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4622 2009-05-21T12:20:25Z

<p>JHugo: /* Behaviour of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> == [[Initial (old) hunting description]]<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4621 2009-05-21T12:05:03Z

<p>JHugo: /* Behavior of a normal node in a mesh */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behaviour of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=HPN_design_discussions_page&diff=4616 2009-04-16T13:56:38Z

<p>JHugo: /* FreeBSD vs Linux */</p> <hr /> <div>== FreeBSD vs Linux ==<br /> <br /> === Licencing ===<br /> Extract form a FreeBSD vs Linux page regarding licensing:<br /> http://www.lemis.com/bsdpaper.html<br /> <br /> How does the BSD license differ from the GNU Public license?<br /> *Linux is available under the GNU General Public License (GPL), which is designed to eliminate closed source software. In particular, any derivative work of a product released under the GPL must also be supplied with source code if requested. By contrast, the BSD license is less restrictive: binary-only distributions are allowed. This is particularly attractive for embedded applications.<br /> <br /> <br /> === Atheros based wifi cards ===<br /> We are currently using Atheros based wifi cards in our HPN's. The reason for this is that almost all the mini-PCI wifi cards on the market are Atheros based and they are by far the best supported in the open source community. Atheros worked with the open source community (Sam Leffler) and they provided a HAL (hardware abstraction layer) that interfaces between the Atheros wifi card and between the open source OS. At some stage someone release an reverse engineered HAL (called openHAL) based on a very old version from Atheros. By the end of 2008 Atheros decided to open up the source code of their latest HAL for the open source community.<br /> <br /> <br /> <br /> === FreeBSD ===<br /> <br /> Pros<br /> *All field deployments we have so far are on systems running FreeBSD; so we have great knowledge on its performance.<br /> *We have far more than enough experience; hence turn-around for changes/additions are way too short, compared to Linux.<br /> *Sam Leffler that wrote most of the Atheros HAL source code is also one of the big FreeBSD developers. <br /> *All the Atheros driver code (from HAL) is now fully integrated into FreeBSD and is part of the OS.<br /> *Works great for wireless modes, like ad-hoc, compared to Linux.<br /> *All tests done on arm/avila boards involved only FreeBSD and none on Linux.<br /> Cons<br /> *With regard to the HPN, none.<br /> *Under-appreciated<br /> <br /> === Linux ===<br /> Pros<br /> *Runs on more (+cheaper) hardware platforms.<br /> <br /> Cons<br /> *There is three different trees for the Atheros diver. <br /> 1) AR5K - based on a very old, the reversed engineered HAL<br /> 2) OpenWRT version - I think it is based on the Madwifi driver, but not sure<br /> 3) Madwifi - This one also have different trees. One base on the old closed HAL and one based on the new open source HAL that Atheros released. I'm not sure it they are also busy incorporating it into the OS.<br /> *I've heard people complaining about the stability of Atheros adhoc mode under Linux.<br /> <br /> == OLSR vs B.A.T.M.A.N ==<br /> <br /> This discussion is around what mesh routing protocol to use for our High Performance Nodes. Before we look into the protocols we need to understand the environment where the HPNs are going to be used in, who's going to install and maintain the network and what other system requirements will have an influence on the protocol selection.<br /> <br /> From the project contract it is clear that the target is not a pilot/research network, but a real commercial network that must provide connectivity to several schools and government departments, as well as for the community. The installation and maintenance will be the responsibility of external (not Meraka/CSIR) partners. This means that eventually it will not be a research network and whatever protocol we select needs to be very stable and well tested. Another requirement is that the network should be so easy do install (auto configure) and maintain and that it can be done by someone in the community. (It must not need an Engineer to design/configure/tweak the network before it is usable).<br /> <br /> The biggest requirement of any network is that it should be stable. After that you get all the other features like speed, ease of use, supported features etc. In a development network one can tolerate some degree of instability while working on new functionalities, but on a network that will be used by other parties should be rock solid and stable. The biggest factor about introducing any new protocols in a network, is that one needs a certain amount of time (years) to test, fix bugs and make sure that everything is stable and usable.<br /> <br /> === OLSR ===<br /> <br /> Pros<br /> * Proven and stable, lots of big networks using it<br /> * Scales well<br /> * Support both IPv4 and IPv6<br /> * Support for Linux, FreeBSD, MacOS<br /> * Active development<br /> <br /> Conns<br /> * Routing information packets can become big<br /> * Lots of network overheads to food routing information<br /> * Can cause high CPU loads on small CPU's in low cost HW platforms<br /> * Has difficulty routing in the presence of multiple gateways on the mesh<br /> <br /> === B.A.T.M.A.N ===<br /> <br /> B.A.T.M.A.N is a fairly new protocol with many different versions, flavors (L2, L3) and derivatives (R.O.B.I.N, Mikrotik MME).<br /> https://www.open-mesh.net/wiki/BranchesExplained<br /> <br /> ==== B.A.T.M.A.N Layer2 ====<br /> Pros<br /> * Works on L2 and is protocol independent (support both IPv4 and IPv6)<br /> * Can use DHCP for automatic IPv4 addressing<br /> * Small and effective routing table<br /> <br /> Conns<br /> * No FreeBSD port<br /> * Not a mature protocol, still in developing state<br /> * Seems like B.A.T.M.A.N development is more active with the Layer3 version than the Layer2 one<br /> * Problems with multi-radio nodes: https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-February/002405.html<br /> <br /> ==== B.A.T.M.A.N Layer3 ====<br /> <br /> Pros<br /> * Small and effective routing table<br /> * Smaller, less frequent routing information packets flooding the network<br /> * Cannot have routing loops (according to the design, but some people seem to differ)<br /> http://www.mail-archive.com/babel-users@lists.alioth.debian.org/msg00148.html<br /> * Active development<br /> * Intelligent management of multiple gateways with varying bandwidth characteristics<br /> <br /> Conns<br /> * No IPv6 support<br /> * No FreeBSD port<br /> ** In progress: http://www.mail-archive.com/b.a.t.m.a.n@open-mesh.net/msg00560.html<br /> * Not a mature protocol, still in developing state<br /> <br /> === Random thoughts. ===<br /> * Our current Meraka team only have experience with OLSR, but not with BATMAN (Except for David, but he's overseas). Maybe we need to setup a test network to get a feeling of the amount of tweaking that is needed to get it to run and how much is done automatically. In the end we want a mesh node that is totally auto configured, including all IPv4 and IPv6 addresses.<br /> ** I (Antoine) am in the process of helping George set up a small B.A.T.M.A.N. mesh for the dashboard development work.<br /> * A google search for a up-to-date comparison between OLSR and BATMAN did not deliver much. From a quick scan in a couple articles and comments it seems like OLSR is very stable and performs well in mesh networks, but BATMAN seems to be very promising and may be the preferred mesh protocol in future. <br /> * With another google search I could find a couple of big operational networks based on OLSR, but I could not find any big operational BATMAN networks. If there are any big operational BATMAN networks out there then I would really like to get more information and comments on it.<br /> ** http://wiki.opennet-initiative.de/index.php - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://wiki.leipzig.freifunk.net/BATMAN - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://www.open-mesh.net/wiki/BerlinExperience <br /> ** http://www.open-mesh.net/wiki/Experience <br /> * Meraka has an operational and stable HPN node that is based on FreeBSD. The current HPN mesh protocol is OLSR and the mesh supports both IPv4 and IPv6. The biggest drawback at the moment is that it does not have an user interface and some vi tweaking is needed.<br /> * The exhaustion of the remaining pool of unallocated IPv4 addresses is approaching within the next few years. IPv4 will not expire or stop to work, but there will be an migration phase where both IPv4 and IPv6 will be used. Some new services and web sites will only be reachable via IPv6. The default protocol on most operating systems are IPv6 and there is a big drive from Microsoft to push IPv6. We cannot just stick our heads in the ground and ignore this fact like an Ostridge. Our current HPN have full IPv6 support and it will not make a lot of sense move backwards to something that does not support IPv6. If we do feel like BATMAN is a better choice then it will make sense to add IPv6 support to it as well.<br /> * Is there enough development time and money on the project to add a lot of new and promising features to the HPN, or should we rather concentrate on the parts that are missing in order to get a stable network out there.<br /> <br /> ==Decision==</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=HPN_design_discussions_page&diff=4615 2009-04-16T10:58:37Z

<p>JHugo: /* Linux */</p> <hr /> <div>== FreeBSD vs Linux ==<br /> We are currently using Atheros based wifi cards in our HPN's. The reason for this is that almost all the mini-PCI wifi cards on the market are Atheros based and they are by far the best supported in the open source community. Atheros worked with the open source community (Sam Leffler) and they provided a HAL (hardware abstraction layer) that interfaces between the Atheros wifi card and between the open source OS. At some stage someone release an reverse engineered HAL (called openHAL) based on a very old version from Atheros. By the end of 2008 Atheros decided to open up the source code of their latest HAL for the open source community.<br /> <br /> <br /> <br /> === FreeBSD ===<br /> <br /> Pros<br /> *All field deployments we have so far are on systems running FreeBSD; so we have great knowledge on its performance.<br /> *We have far more than enough experience; hence turn-around for changes/additions are way too short, compared to Linux.<br /> *Sam Leffler that wrote most of the Atheros HAL source code is also one of the big FreeBSD developers. <br /> *All the Atheros driver code (from HAL) is now fully integrated into FreeBSD and is part of the OS.<br /> *Works great for wireless modes, like ad-hoc, compared to Linux.<br /> *All tests done on arm/avila boards involved only FreeBSD and none on Linux.<br /> Cons<br /> *With regard to the HPN, none.<br /> *Under-appreciated<br /> <br /> === Linux ===<br /> Pros<br /> *Runs on more (+cheaper) hardware platforms.<br /> <br /> Cons<br /> *There is three different trees for the Atheros diver. <br /> 1) AR5K - based on a very old, the reversed engineered HAL<br /> 2) OpenWRT version - I think it is based on the Madwifi driver, but not sure<br /> 3) Madwifi - This one also have different trees. One base on the old closed HAL and one based on the new open source HAL that Atheros released. I'm not sure it they are also busy incorporating it into the OS.<br /> *I've heard people complaining about the stability of Atheros adhoc mode under Linux.<br /> <br /> == OLSR vs B.A.T.M.A.N ==<br /> <br /> This discussion is around what mesh routing protocol to use for our High Performance Nodes. Before we look into the protocols we need to understand the environment where the HPNs are going to be used in, who's going to install and maintain the network and what other system requirements will have an influence on the protocol selection.<br /> <br /> From the project contract it is clear that the target is not a pilot/research network, but a real commercial network that must provide connectivity to several schools and government departments, as well as for the community. The installation and maintenance will be the responsibility of external (not Meraka/CSIR) partners. This means that eventually it will not be a research network and whatever protocol we select needs to be very stable and well tested. Another requirement is that the network should be so easy do install (auto configure) and maintain and that it can be done by someone in the community. (It must not need an Engineer to design/configure/tweak the network before it is usable).<br /> <br /> The biggest requirement of any network is that it should be stable. After that you get all the other features like speed, ease of use, supported features etc. In a development network one can tolerate some degree of instability while working on new functionalities, but on a network that will be used by other parties should be rock solid and stable. The biggest factor about introducing any new protocols in a network, is that one needs a certain amount of time (years) to test, fix bugs and make sure that everything is stable and usable.<br /> <br /> === OLSR ===<br /> <br /> Pros<br /> * Proven and stable, lots of big networks using it<br /> * Scales well<br /> * Support both IPv4 and IPv6<br /> * Support for Linux, FreeBSD, MacOS<br /> * Active development<br /> <br /> Conns<br /> * Routing information packets can become big<br /> * Lots of network overheads to food routing information<br /> * Can cause high CPU loads on small CPU's in low cost HW platforms<br /> * Has difficulty routing in the presence of multiple gateways on the mesh<br /> <br /> === B.A.T.M.A.N ===<br /> <br /> B.A.T.M.A.N is a fairly new protocol with many different versions, flavors (L2, L3) and derivatives (R.O.B.I.N, Mikrotik MME).<br /> https://www.open-mesh.net/wiki/BranchesExplained<br /> <br /> ==== B.A.T.M.A.N Layer2 ====<br /> Pros<br /> * Works on L2 and is protocol independent (support both IPv4 and IPv6)<br /> * Can use DHCP for automatic IPv4 addressing<br /> * Small and effective routing table<br /> <br /> Conns<br /> * No FreeBSD port<br /> * Not a mature protocol, still in developing state<br /> * Seems like B.A.T.M.A.N development is more active with the Layer3 version than the Layer2 one<br /> * Problems with multi-radio nodes: https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-February/002405.html<br /> <br /> ==== B.A.T.M.A.N Layer3 ====<br /> <br /> Pros<br /> * Small and effective routing table<br /> * Smaller, less frequent routing information packets flooding the network<br /> * Cannot have routing loops (according to the design, but some people seem to differ)<br /> http://www.mail-archive.com/babel-users@lists.alioth.debian.org/msg00148.html<br /> * Active development<br /> * Intelligent management of multiple gateways with varying bandwidth characteristics<br /> <br /> Conns<br /> * No IPv6 support<br /> * No FreeBSD port<br /> ** In progress: http://www.mail-archive.com/b.a.t.m.a.n@open-mesh.net/msg00560.html<br /> * Not a mature protocol, still in developing state<br /> <br /> === Random thoughts. ===<br /> * Our current Meraka team only have experience with OLSR, but not with BATMAN (Except for David, but he's overseas). Maybe we need to setup a test network to get a feeling of the amount of tweaking that is needed to get it to run and how much is done automatically. In the end we want a mesh node that is totally auto configured, including all IPv4 and IPv6 addresses.<br /> ** I (Antoine) am in the process of helping George set up a small B.A.T.M.A.N. mesh for the dashboard development work.<br /> * A google search for a up-to-date comparison between OLSR and BATMAN did not deliver much. From a quick scan in a couple articles and comments it seems like OLSR is very stable and performs well in mesh networks, but BATMAN seems to be very promising and may be the preferred mesh protocol in future. <br /> * With another google search I could find a couple of big operational networks based on OLSR, but I could not find any big operational BATMAN networks. If there are any big operational BATMAN networks out there then I would really like to get more information and comments on it.<br /> ** http://wiki.opennet-initiative.de/index.php - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://wiki.leipzig.freifunk.net/BATMAN - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://www.open-mesh.net/wiki/BerlinExperience <br /> ** http://www.open-mesh.net/wiki/Experience <br /> * Meraka has an operational and stable HPN node that is based on FreeBSD. The current HPN mesh protocol is OLSR and the mesh supports both IPv4 and IPv6. The biggest drawback at the moment is that it does not have an user interface and some vi tweaking is needed.<br /> * The exhaustion of the remaining pool of unallocated IPv4 addresses is approaching within the next few years. IPv4 will not expire or stop to work, but there will be an migration phase where both IPv4 and IPv6 will be used. Some new services and web sites will only be reachable via IPv6. The default protocol on most operating systems are IPv6 and there is a big drive from Microsoft to push IPv6. We cannot just stick our heads in the ground and ignore this fact like an Ostridge. Our current HPN have full IPv6 support and it will not make a lot of sense move backwards to something that does not support IPv6. If we do feel like BATMAN is a better choice then it will make sense to add IPv6 support to it as well.<br /> * Is there enough development time and money on the project to add a lot of new and promising features to the HPN, or should we rather concentrate on the parts that are missing in order to get a stable network out there.<br /> <br /> ==Decision==</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=HPN_design_discussions_page&diff=4613 2009-04-16T09:01:59Z

<p>JHugo: /* FreeBSD vs Linux */</p> <hr /> <div>== FreeBSD vs Linux ==<br /> We are currently using Atheros based wifi cards in our HPN's. The reason for this is that almost all the mini-PCI wifi cards on the market are Atheros based and they are by far the best supported in the open source community. Atheros worked with the open source community (Sam Leffler) and they provided a HAL (hardware abstraction layer) that interfaces between the Atheros wifi card and between the open source OS. At some stage someone release an reverse engineered HAL (called openHAL) based on a very old version from Atheros. By the end of 2008 Atheros decided to open up the source code of their latest HAL for the open source community.<br /> <br /> <br /> <br /> === FreeBSD ===<br /> <br /> Pros<br /> *All field deployments we have so far are on systems running FreeBSD; so we have great knowledge on its performance.<br /> *We have far more than enough experience; hence turn-around for changes/additions are way too short, compared to Linux.<br /> *Sam Leffler that wrote most of the Atheros HAL source code is also one of the big FreeBSD developers. <br /> *All the Atheros driver code (from HAL) is now fully integrated into FreeBSD and is part of the OS.<br /> *Works great for wireless modes, like ad-hoc, compared to Linux.<br /> *All tests done on arm/avila boards involved only FreeBSD and none on Linux.<br /> Cons<br /> *With regard to the HPN, none.<br /> *Under-appreciated<br /> <br /> === Linux ===<br /> Pros<br /> *Runs on more (+cheaper) hardware platforms.<br /> <br /> Cons<br /> *There are three main <br /> *There is three different trees for the Atheros diver. <br /> 1) AR5K - based on a very old, the reversed engineered HAL<br /> 2) OpenWRT version - I think it is based on the Madwifi driver, but not sure<br /> 3) Madwifi - This one also have different trees. One base on the old closed HAL and one based on the new open source HAL that Atheros released. I'm not sure it they are also busy incorporating it into the OS.<br /> <br /> == OLSR vs B.A.T.M.A.N ==<br /> <br /> This discussion is around what mesh routing protocol to use for our High Performance Nodes. Before we look into the protocols we need to understand the environment where the HPNs are going to be used in, who's going to install and maintain the network and what other system requirements will have an influence on the protocol selection.<br /> <br /> From the project contract it is clear that the target is not a pilot/research network, but a real commercial network that must provide connectivity to several schools and government departments, as well as for the community. The installation and maintenance will be the responsibility of external (not Meraka/CSIR) partners. This means that eventually it will not be a research network and whatever protocol we select needs to be very stable and well tested. Another requirement is that the network should be so easy do install (auto configure) and maintain and that it can be done by someone in the community. (It must not need an Engineer to design/configure/tweak the network before it is usable).<br /> <br /> The biggest requirement of any network is that it should be stable. After that you get all the other features like speed, ease of use, supported features etc. In a development network one can tolerate some degree of instability while working on new functionalities, but on a network that will be used by other parties should be rock solid and stable. The biggest factor about introducing any new protocols in a network, is that one needs a certain amount of time (years) to test, fix bugs and make sure that everything is stable and usable.<br /> <br /> === OLSR ===<br /> <br /> Pros<br /> * Proven and stable, lots of big networks using it<br /> * Scales well<br /> * Support both IPv4 and IPv6<br /> * Support for Linux, FreeBSD, MacOS<br /> * Active development<br /> <br /> Conns<br /> * Routing information packets can become big<br /> * Lots of network overheads to food routing information<br /> * Can cause high CPU loads on small CPU's in low cost HW platforms<br /> * Has difficulty routing in the presence of multiple gateways on the mesh<br /> <br /> === B.A.T.M.A.N ===<br /> <br /> B.A.T.M.A.N is a fairly new protocol with many different versions, flavors (L2, L3) and derivatives (R.O.B.I.N, Mikrotik MME).<br /> https://www.open-mesh.net/wiki/BranchesExplained<br /> <br /> ==== B.A.T.M.A.N Layer2 ====<br /> Pros<br /> * Works on L2 and is protocol independent (support both IPv4 and IPv6)<br /> * Can use DHCP for automatic IPv4 addressing<br /> * Small and effective routing table<br /> <br /> Conns<br /> * No FreeBSD port<br /> * Not a mature protocol, still in developing state<br /> * Seems like B.A.T.M.A.N development is more active with the Layer3 version than the Layer2 one<br /> * Problems with multi-radio nodes: https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-February/002405.html<br /> <br /> ==== B.A.T.M.A.N Layer3 ====<br /> <br /> Pros<br /> * Small and effective routing table<br /> * Smaller, less frequent routing information packets flooding the network<br /> * Cannot have routing loops (according to the design, but some people seem to differ)<br /> http://www.mail-archive.com/babel-users@lists.alioth.debian.org/msg00148.html<br /> * Active development<br /> * Intelligent management of multiple gateways with varying bandwidth characteristics<br /> <br /> Conns<br /> * No IPv6 support<br /> * No FreeBSD port<br /> ** In progress: http://www.mail-archive.com/b.a.t.m.a.n@open-mesh.net/msg00560.html<br /> * Not a mature protocol, still in developing state<br /> <br /> === Random thoughts. ===<br /> * Our current Meraka team only have experience with OLSR, but not with BATMAN (Except for David, but he's overseas). Maybe we need to setup a test network to get a feeling of the amount of tweaking that is needed to get it to run and how much is done automatically. In the end we want a mesh node that is totally auto configured, including all IPv4 and IPv6 addresses.<br /> ** I (Antoine) am in the process of helping George set up a small B.A.T.M.A.N. mesh for the dashboard development work.<br /> * A google search for a up-to-date comparison between OLSR and BATMAN did not deliver much. From a quick scan in a couple articles and comments it seems like OLSR is very stable and performs well in mesh networks, but BATMAN seems to be very promising and may be the preferred mesh protocol in future. <br /> * With another google search I could find a couple of big operational networks based on OLSR, but I could not find any big operational BATMAN networks. If there are any big operational BATMAN networks out there then I would really like to get more information and comments on it.<br /> ** http://wiki.opennet-initiative.de/index.php - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://wiki.leipzig.freifunk.net/BATMAN - mixed OLSR &amp; B.A.T.M.A.N.<br /> ** http://www.open-mesh.net/wiki/BerlinExperience <br /> ** http://www.open-mesh.net/wiki/Experience <br /> * Meraka has an operational and stable HPN node that is based on FreeBSD. The current HPN mesh protocol is OLSR and the mesh supports both IPv4 and IPv6. The biggest drawback at the moment is that it does not have an user interface and some vi tweaking is needed.<br /> * The exhaustion of the remaining pool of unallocated IPv4 addresses is approaching within the next few years. IPv4 will not expire or stop to work, but there will be an migration phase where both IPv4 and IPv6 will be used. Some new services and web sites will only be reachable via IPv6. The default protocol on most operating systems are IPv6 and there is a big drive from Microsoft to push IPv6. We cannot just stick our heads in the ground and ignore this fact like an Ostridge. Our current HPN have full IPv6 support and it will not make a lot of sense move backwards to something that does not support IPv6. If we do feel like BATMAN is a better choice then it will make sense to add IPv6 support to it as well.<br /> * Is there enough development time and money on the project to add a lot of new and promising features to the HPN, or should we rather concentrate on the parts that are missing in order to get a stable network out there.<br /> <br /> ==Decision==</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4601 2009-04-07T10:56:53Z

<p>JHugo: /* Typical Outdoor Range at 5.8Ghz */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behavior of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> <br /> [[Image:001.jpg|border|300px]][[Image:002.jpg|border|300px]]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=File:001.jpg&diff=4600 2009-04-07T10:49:38Z

<p>JHugo: </p> <hr /> <div></div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=High_performance_node_page&diff=4599 2009-04-07T10:45:44Z

<p>JHugo: /* Typical Outdoor Range at 5.8Ghz */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]][[Category: High Performance Node]]<br /> <br /> == What is a HPN (high performance node) ? ==<br /> <br /> The HPN is a multi-radio (3x radios), high performance, wireless (802.11) router. It has three antennas, one 5.8Ghz directional panel antenna as well as two omni's (2.4Ghz + 5.8Ghz). At the bottom of the router there is a weather proof UTP connector that is used for both Power-Over-Ethernet (PoE) and Ethernet connectivity to the router. A special mounting bracket at the back of the router allows it to be attached to an aluminum pole that is usually mounted to the side of a building or some structure.<br /> <br /> [[Image:HPN.png]]<br /> <br /> == How to build a mesh with HPN's ==<br /> The idea is to build a mesh network with these routers by aligning each directional antennas to point to a neighboring omni or another directional antenna. The wireless cards in a router operates on different channels (frequencies). To make it more user friendly each channel (frequencies) is tied to a color. This means that a red panel antenna must be aligned to a red omni (or another red panel) and a green panel must be aligned to a green omni (or green panel). The blue channel (2.4Ghz) is used to create a wifi hostspot for clients who would like to connect to the mesh network via wifi.<br /> <br /> [[Image:Mesh-Network.png]]<br /> <br /> <br /> Every mesh network usually have one GateWay that connects to the Internet or to some other network. Any one of the mesh nodes can be configured to become a GateWay for the mesh. When a node becomes a GateWay then the channels (frequencies) of the antennas are fixed to the following: 5.8Ghz directional panel = RED, 5.8Ghz omni = GREEN and the 2.4Ghz omni = BLUE. The GateWay node will also become the DNS server for the mesh and all the nodes inside the mesh will register their HostNames with the DNS server. Another function of the GateWay node is to act as a time server for the mesh network and all the nodes inside the mesh will synchronize their time with the GateWay node. <br /> <br /> The best approach to build a mesh network is to start with the installation of the GateWay node. Next you install the node(s) that aligns to the GateWay node and then grow the mesh from there. Fist perform a visual alignment of the panel antenna on the node before the power is switched on. When a normal node starts up for the first time, then it will hunt for a mesh signal and it will lock it's channels (frequencies) once connectivity is established. It will first hunt for connectivity on both the red and green channels on the directional panel antenna for X seconds. If no signal is found, then the hunt will continue on the 5.8Ghz omni directional antenna for X seconds. This sequence will repeat itself until a signal is found, or until the channels are manually locked via the web interface on the node itself. <br /> <br /> Every node has a GREEN and a RED LED that is visible from underneath the node (should be visible when one stands under the node that is mounted on a pole). These LEDs are there to give some indication of connectivity and they will only turn on if connectivity can be established on either the red or green channel. Note that the LED does not show the signal quality or to what node it is connected to, it only shows that there is connectivity to another HPN node and on what channel (red or green). Signal quality and node connectivity information is only available via the web interface, but in most cases a visual alignment combined with a link indicator will be sufficient enough to get a mesh node up and running.<br /> <br /> == How can a client connect to the mesh ==<br /> <br /> [[Image:Hpn-switch-pc.png]]<br /> <br /> Client devices can connect to any of the nodes via Ethernet or via wifi (blue channel = hostspot). The client devices should be configured to make use of DHCP so that all networking configurations can be done automatically (The node will provide all the networking details via DHCP). It is also recommended that the IPv6 protocol stack should be switch on if it is available. IPv6 should already be enabled on Windows Vista as well as most Unix systems.<br /> <br /> == How does the mesh work ? ==<br /> <br /> Almost everything in the network will be configured automatically, except for the selection of the gateway node and the channel (red or green) of a wireless link. The mesh supports both IPv6 and IPv4 traffic from any end-point (a place where a mesh client connects) to any other end-point in the mesh, while the backbone uses IPv6 only. A routing protocol called OLSR (Optimized Link State Routing) is used to exchange routing information between all the nodes inside the mesh and to select the best path for data traffic between end-points in the mesh.<br /> <br /> [[Image:OLSR.png]]<br /> <br /> Lets take an example (see diagram) where HP want to send data to Dell.<br /> <br /> ==== Using IPv6 ====<br /> HP will address the data to the IPv6 address of Dell and send it to node C. Node C will look in it's routing table and see that there are two routes to Dell, one route via node B-A-D-E and the other route via D-E. It will then select the best route and send it to the next node, in our case node D. Node D will look in it's routing table and see that the only route to Dell is via node E. Node E will look at it's routing table and see that Dell is directly connected and it will forward the data to Dell.<br /> <br /> ==== Using IPv4 ====<br /> This one is a bit more complicated. IPv4 is only used on the outside of the network (where the mesh clients connect to it) and then the IPv4 traffic is tunneled over the IPv6 backbone of the mesh to any another end point in the mesh. The mesh will automatically create a one-to-many IPv4 tunnel over the IPv6 network (4over6 tunneling protocol). This means that it looks like a network with an IPv4 tunnel from every IPv4 subnet to every other IPv4 subnet in the mesh. From a client's perspective it looks like a normal IPv4 routed network. From the backbone's perspective it looks like a IPv6 only network and all the OLSR routing information is IPv6 only. <br /> <br /> So how does the network know how to forward IPv4 packets to the correct destination ? It makes use of IPv4-mapped-IPv6 addresses (see [http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC4291] and [http://tools.ietf.org/html/rfc4038 RFC4038]). Every node will map an IPv4 addresses into a IPv6 address before data goes to the backbone and the IPv4-Mapped-IPv6 addresses are converted back to a plain IPv4 address when it comes out of the backbone. OLSR will advertise these IPv4-Mapped-IPv6 address subnets on the backbone so that all the nodes will learn these subnets and they will calculate the best route to these subnets.<br /> <br /> Lets take example again, using IPv4. HP will address the data to the IPv4 address of Dell and send it to node C. Node C will change the IPv4 packet to an IPv6 packet with an IPv4-mapped-IPv6 addresses. From there it will follow the same route as the IPv6 example above. Node E will take the original IPv4 packet out of the IPv4-mapped-IPv6 packet and it will send the original IPv4 packet to Dell.<br /> <br /> See http://wirelessafrica.meraka.org.za/wiki/index.php/John%27s_research#4over6_Automatic_tunnels for more detail of the 4over6 tunneling protocol.<br /> <br /> === Why is the mesh using IPv6 ? ===<br /> <br /> ==== Reason one ====<br /> It is predicted that unused IPv4 address space will be depleted within the next two years. Operating systems like Vista and most Unix systems defaults to IPv6 by default and most applications are IPv6 ready. With this in mind it makes sense that any new networking products should provide both IPv4 and IPv6 support.<br /> <br /> ==== Reason two ====<br /> In a single radio mesh network there is just one RF channel and everybody makes use of the same IP subnet. One limitation of a single radio mesh is that each mesh radio needs to handle both incoming and outgoing traffic. This causes the throughput to be halved because a radio cannot transmit and receive simultaneously. Another problem is that if one radio is transmitting then all its neighbors must all be in listening mode. These problems can cause a single radio mesh to very quickly run out of steam.<br /> <br /> Multi-radio mesh technology solves this problem by configuring every radio inside a router to operate on a different frequency and on a different IP subnet. In the HPN two radios are dedicated for backbone traffic and the third is used to create a client hotspot. 802.11a is generally used for backbone traffic, and 802.11b/g for client coverage. <br /> <br /> In a multi-radio mesh network it is very difficult to use the same IPv4 subnet on all the backbone wireless interfaces inside a mesh. The OLSR routing protocol uses broadcast packets to flood OLSR routing information to all of it's neighbors. This works very well with a single radio mesh, but not with a multi-radio mesh. Almost all TCP/IP (IPv4) stacks implementations can only send out broadcast packets on one interface at a time, but not on multiple interfaces on the same IPv4 subnet. This means that every interface needs to operate on a different IPv4 subnet, with the effect that some OLSR links may be physically possible, but it cannot be used for data because the IPv4 subnets are different. A multi-radio IPv4 OLSR network is possible, but it usually needs a lot of planning and configuration.<br /> <br /> [[Image:IPv4-Network.png]]<br /> <br /> The TCP/IP stack of IPv6 does not make use of Broadcast packets and OLSR routing information is flooded to it's neighbors via multicast packets. These multicast packets will automatically be duplicated by the TCP/IP stack and send out via multiple IPv6 interfaces on the same IPv6 subnet. This means that the mesh can use the same IPv6 subnet, all over the mesh backbone, without any problems. With a multi-radio IPv6 OLSR mesh you don't need any IPv6 configuration on the backbone as all the nodes use the same IPv6 subnet.<br /> <br /> [[Image:IPv6-Network.png]]<br /> <br /> == Behavior of a normal node in a mesh ==<br /> <br /> The following describes how a normal node will behave inside a mesh and what service it will provide:<br /> <br /> * When a new node boots up for the fist time, then it will go into a hunting mode and it will search for other nodes in the mesh. In hunting mode it will first configure the patch antenna on the GREEN frequency. It will perform a link local IPv6 ping on that interface for about X seconds to determine if any IPv6 connectivity can be found on that antenna/channel. If no connectivity is found after X seconds, then it will hunt further using RED on the patch, then GREEN on the omni and then RED on the omni. If no connectivity can be found, then it will start the hunting process from the beginning, or until it is manually locked via the WEB terface. If connectivity can be established, then it will enable the green/red link LED on the bottom of the node to show connectivity (use the WEB interface for more information on to which node connectivity has been established to). If connectivity is lost then the LED will be off again. After stable connectivity for about X consecutive pings, the node will lock the antenna/channels util someone changes it manually via the WEB interface. Once the antennas/channels are locked then it will also change the sensitivity of the link LED and LED updates will be less frequently. The LED sensitivity can be manually changed via the WEB interface by selecting the &quot;alignment&quot; button. The alignment feature will give signal strength information on the WEB interface. See hunt-flow-diagram below.<br /> <br /> [[Image:Hunt-flow-diag.png]]<br /> <br /> * When a new node boots up then an unique IPv6 address ((inside this mesh. See IP addressing section) will be configured on all the Ethernet and wireless interfaces. An unique (inside this mesh) IPv4 address is calculated and configured on the Ethernet interface and on the 2.4Ghz omni interface. The node will use the MAC address of the adapter to calculate a unique IPv4 and IPv6 subnet for that interface. These automatic addresses can be overrided via the WEB interface (E.g. if a globally routeable IPv6 address is required for a website inside the mesh and it should be visible from the Internet). Wireless interfaces are placed into adhoc mode and the channel, ssid and bssid are also configured.<br /> <br /> * When a new node boots up then the OLSR daemon is started and it will listen en send OLSR topology packets to all of it's neighboring nodes. OLSR runs on all the wireless interfaces, but not on the Ethernet interface. All the IPv4 subnets are converted to 4in6 IPv6 addresses and these IPv6 subnets are placed into the HNA section of olsrd.conf, together with the IPv6 subnets that are configured on the Ethernet interface and on the 2.4Ghz omni interface. These HNA subnets are then distributed, via OLSR, to all the other nodes inside the mesh.<br /> <br /> * The 4over6 tunneling daemon take care of all IPv4 comms and dirtributing of routing information inside the mesh.<br /> <br /> * The node will start ntpd daemon on provide NTP time services on all it's IPv4 and IPv6 addresses. NTP will also synchronize it's local time with the GW-node on a regular basis.<br /> <br /> * The node will register it's own hostname in DNS on the GW-node. It will start dnsmasq daemon and it will also provide DNS services on all it's IPv4 and IPv6 addresses. Dnsmasq will forward all DNS queries to the DNS server running on the GW-node.<br /> <br /> * Dnsmasq is used to provide IPv4 DHCP services and DNS services on both the Ethernet interface and on the 2.4Ghz omni (hostspot) interface.<br /> <br /> * rtadvd will run on both the Ethernet interface and on the 2.4Ghz omni interface and it is used to advertise IPv6 prefixes to locally connected IPv6 client devices.<br /> <br /> * sshd allows remote ssh login's from anywhere in the mesh network.<br /> <br /> * watchdogd toggles the watchdog during normal operations. Should the system hang for some reason, then the watchdog will restart the HPN node.<br /> <br /> * mini_httpd is used for the WEB gui running on the HPN node.<br /> <br /> == Behavior of the GateWay node in a mesh ==<br /> <br /> Any standard mesh node can become a GateWay node by selecting the &quot;GateWay&quot; button under &quot;Additional features&quot; on the WEB interface. The GateWay node is the place where the mesh will connect to some outside network and it will be the default route for the mesh. When a normal node becomes a GateWay node, then it does not disable any normal node features, but it just adds some additional features. The following are the additional features that a GateWay node will have:<br /> <br /> * The GW-node will not go into a hunting mode and it will lock it's channels with GREEN on the omni and RED on the directional panel. The default channels can be swapped via the WEB interface.<br /> <br /> * The GW-node is the default route for the mesh and it will advertise a default route via OLSR to the rest of the mesh.<br /> <br /> * The GW-node connects to the outside networks via Ethernet. It will perform a DHCP request on this interface in order to get an automatic IP address and external DNS server configurations from the external network. These setting can be overided via the WEB interface, under &quot;Additional features&quot;.<br /> <br /> * The GW-node becomes the DNS server for the mesh and it will configure and start the 'named' services on IPv6, as well as on a well known IPv6 address of fec0:0:0:ffff::1. It will allow any node inside a mesh to submit their hostname into DNS and it will provide DNS services to any node or other device inside the mesh on IPv6 only. The GateWay node will also forward external DNS requests to upstream DNS servers if they are available. Upstream DNS servers are usually configured via DHCP but these setting can also be overided under &quot;Additional features&quot; on the WEB interface. DNS services are still available via 'dnsmasq', on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a time server for the mesh. It will synchronize it's time to an external time server if it's configured and available, otherwise it will use it's own internal RTC to synchronize it's time to. This time will be available to the rest of the mesh on a well known IPv6 address of fec0:0:0:ffff::1 and all the nodes in a mesh will use this time to synchronize their own time servers to. The GW-node will still provide NTP time services on all it's IPv4 and IPv6 addresses like a normal node will do.<br /> <br /> * The GW-node becomes a firmware update server for the mesh. It will start ftpd services on IPv6, on a well known IPv6 address of fec0:0:0:ffff::1. It will took for new firmware on the Internet. If new firmware is available, then it will download the software and make it available to the other nodes inside the mesh via ftp.<br /> <br /> == IPv4 addressing scheme ==<br /> <br /> IPv4 addresses are not used in the backbone, but only on the edge of the network. This means that every node will have two IPv4 subnets configured, one on the Ethernet adapter (npe0) and the other on the 2.4Ghz omni (ath2) that is used for a wifi hotspot. The High performance node will always use the first IPv4 address on a configured subnet. E.g 10.234.18.1/24<br /> <br /> The HPN currently makes use of an automatic IPv4 addressing scheme where the IPv4 subnet is derived from the two least significant bytes of the MAC address of that particular interface. The first bye of the network is always 10 because we are making use of the 10net inside the mesh. The next two byes comes from the last two byes of the Mac address and it will become the IPv4 subnet for that adapter. The adapter itself will be 10.x.x.1 and it will become the default gateway for that subnet. DNSmasq will hand out DHCP addresses form 10.x.x.100 - 10.x.x.199 on the calculated subnet.<br /> <br /> Mac = 00:d0:12:07:cb:73<br /> cb.73 (hex) = 203.115 (decimal)<br /> IP subnet = 10.203.115 with /24 subnet mask<br /> IP address = 10.203.115.1<br /> DHCP = 10.203.115.100-10.203.115.199<br /> <br /> This addressing scheme will work 99% of the time, but it is not failsafe. Subnet clashes may occur due to the MAC address numbering schemes used by different vendors. MAC addresses usually have a vendor portion (first part of address) and a product/sequent number portion (last part). The last part is the part that is used to generate an IPv4 address. The last two bytes will most probably, at some stage, be that same for two different cards from two different vendors and there may be a very small chance for both of these cards end up in the same mesh network. In this case the automatic address can be overridden manually in rc.conf.local. At this stage there is no build in detection system that will handle Mac address clashes.<br /> <br /> Other addressing schemes to consider:<br /> * Manage and assign all IPv4 addresses centrally. Program addresses into the HPN's during the manufacturing process. This will sort out all IPv4 address clashes. Issues - Do you assign a IPv4 address block per community or just sequential per HPN node?<br /> * Manage a block of IPv4 addresses for each community somewhere on the local mesh. HPN nodes can then request an IPv4 addresses from this repository and use it. Issues - what happens if server is down or during a power failure. Will you get a new IPv4 address every time, simular to what you get with ADSL. This will mean that all the the PC's and devices that received DHCP addresses from DNSmasq will have to change as well. <br /> <br /> Issues that may influence the selection of an addressing scheme:<br /> * Should there be IPv4 connectivity between different mesh networks ?<br /> * Should there be IPv4 connectivity between a network inside a mesh and some other place in the Internet ?<br /> * Should someone upstream device be able to initiate a connection into a mesh network (E.g. web server in mesh). ?<br /> * Should we make use of legal (routeable) IPv4 address space, or should we stick to the 10net.<br /> * Should the network be able to build and exchange IPv4 routing information with other networks.<br /> * Routing information can be simplified if sequential IPv4 addresses are managed centrally and allocated per mesh<br /> * Should the addressing scheme survive a power cycle or load shedding inside a community<br /> * Is the WISP going to do NAT ?<br /> <br /> == IPv6 addressing scheme ==<br /> <br /> All the HPN nodes supports end-to-end IPv6 communications over the mesh. IPv6 only needs a network prefix (IPv6 subnet) for every adapter and the protocol stack will work out the IPv6 address for each interface. <br /> <br /> Our mesh is making use of a private Unique Local Addresses (ULAs) space, described in [http://www.rfc-editor.org/rfc/rfc4193.txt RFC4193]. This address space in similar to the 10net in IPv4, but with the difference that each ULA is globally unique. This means that we can calculate our own network prefix that we use in a mesh. This leaves the option to use the same prefix for all the different mesh networks, or we can use an unique prefix for every mesh. A unique prefix for every mesh may have an routing advantage if we need to connect different mesh networks together in future, but it also means that HPN's should be pre-configured with a prefix that is tied to a specific community and the prefix allocations should be managed centrally.<br /> <br /> Note that private Unique Local IPv6 addresses are not globally routable, but only inside our mesh. If we need globally routable IPv6 addresses then we need to apply for Provider Independent IPv6 address space from Afrinic. These addresses is uosually someting that is given to some network provider (owner of the network) and it will have a yearly fee attached to it. Issues - it is not always clear who the owner of a communit mesh is.<br /> <br /> The best sollution may be to use a combination of both addressing schemes. Use ULA addresses all over the mesh and only use leagal IPv6 addresses where devices needs to be availble on the Internet.<br /> <br /> == WEB interface ==<br /> At the moment there is no WEB GUI for the HPN. This is an suggestion of how the GUI should look like. The idea is to keep it simple as possible with as little as possible that can be changed.<br /> <br /> === WEB Gui main page ===<br /> <br /> [[Image:HPN-hunt-html.png|border|300px]][[Image:HPN-green-html.png|border|300px]][[Image:HPN-red-html.png|border|300px]]<br /> <br /> The default setting for a HPN is to come up in the hunting mode. After a successful hunt, the HPN will lock to either a red or green node and it will keep the setting, even during power failures. The menu will show the current state of a HPN, but it will also allow you to override the current mode by selecting red, green or hunting manually. Changes are only allowed after a valid login.<br /> <br /> The bar graph will give some indication of signal strength to other nodes on both the red and green channel. Note that there can be a link to more than one node on a given channel (red or green). The indicator on the main page will only show the signal to the first node that it links with. A more detailed view is available on the align page under the &quot;More features&quot; button.<br /> <br /> The last thing that can be changed from the main menu is the name of the HPN. This name will also be registered into the mesh DNS. All changes will only take effect after selecting the SUBMIT button. Additional features can be reached via the &quot;More features&quot; button.<br /> <br /> === More features ===<br /> <br /> [[Image:HPN-features-html.png|border|300px]]<br /> <br /> ==== Configure / Align / Stats ====<br /> <br /> [[Image:HPN-configure-html.png|border|300px]][[Image:HPN-align-html.png|border|300px]][[Image:HPN-stats-html.png|border|300px]]<br /> <br /> == Specifications ==<br /> <br /> [[High_Performance_Node_-_Specification]]<br /> <br /> == Upgrades ==<br /> All the HPN nodes in a mesh will look for new firmware updates from the GateWay node on a regular basis. New firmware is placed inside a special directory on the GateWay node and it is made available, via ftp, to all the other HPN nodes in the mesh. Each HPN nodes will compare the firmware from this directory with it's current version of firmware to determine if it's newer. If new firmware is available, then the node will download and untar the new firmware onto a spare partition on the flash disk. After that all the custom configurations are copied over to the new partition. The HPN will then change the active partition to the new one and it will reboot with the new firmware. If someting should go wrong with the upgrade, then the HPN will revert back to the previous version of firmware.<br /> <br /> The GateWay node will look for new firmware somewhere on the Internet or from the WISP box. If available it will download the new firmware and place it into the special ftp directory.<br /> <br /> == Typical Outdoor Range at 5.8Ghz ==<br /> At this stage we haven't found a testing site that is suitable for our tests. The following is just gestimates and it still needs to be tested.<br /> <br /> * Omni to Omni: up to xx km (2km?)<br /> * Panel to Omni: up to xx km (5km?)<br /> * Panel to Panel: up to xx km (10km?)<br /> * External to External: more than xx km (20km?), depending on antenna type<br /> <br /> Now for some test results:<br /> For our first test we selected a friendly site for the panel-to-panel test. We selected Anita's home because she is just over 10km from Meraka and there is a clear line of site between both sites (this is also our longest 11a link so far). Another reason is that we already have a 32bBi directional antenna, from an existing installation on Meraka's roof, that is pointing directly to her home. <br /> <br /> We used one of our new routers for this site, but we replaced the 5.8Ghz omni antenna with a 27dBi grid antenna so that we could have one link to login to the router, while we can do some tests on the second antenna.<br /> <br /> Here is a picture of Anita's husband with the router the he installed on their roof.<br /> [Image:002.jpg]<br /> <br /> == Regulatory ==<br /> Wirelss equipment that operate in the ISM bands do not need an spectrum licence, but they need to be ICASA approved. All the wifi adapters inside the HPN nodes are ICASA approved. From recent media reports regarding DABBA communications and there equipent in the Orange Farm area, it seems like our HPN node needs to get ICASA approval for the complete assembled HPN node as well. Every node should have it's own ICASA sticker on the back.<br /> <br /> == Using WEP/WPA in adhoc mode ==<br /> <br /> One of the requirements of the High Performance Node is to have WEP or WPA enabled between the wireless links of the mesh nodes. This is one of the functionalities that we would like to sort out before we install any of the nodes in the field. It's very difficult to change the encryption mode after an installation because the mesh nodes will lose connectivity if one node is upgraded to use WEP, while another is still using older software without WEP.<br /> <br /> WEP and WPA are both methods to enable the encryption of data that it is send over the air. WEP (Wired equivalence privacy) is an older standard and it makes use of a WEP encryption engine while the newer WPA standard added the use of an AES encryption engine. WEP encryption has some security flaws embedded into the protocol and there are several tools available on the Internet that can crack WEP keys. These tools are more effective with the cracking of 64bit WEP keys than with 128bit keys and they require a large amount of captured data and processing power to crack a key. Note that not all WEP keys can be cracked, but only weak keys and that flaw was addressed and fixed by WPA.<br /> <br /> Wireless adapters on Unix Systems can operate in three different modes: Client, Hostap (Access Point) and Adhoc mode. Most of the implementations of wireless (802.11) networks are based on a model where there is one Access Point with several wireless clients attached to to it. <br /> <br /> [[Image:AP-client.png|center|One Access point with many nodes]]<br /> <br /> Wireless Mesh networks make use of the less tested Adhoc mode of 802.11.<br /> <br /> [[Image:Adhoc.png|center|Many nodes using Adhoc mode (many point to point links)]]<br /> <br /> <br /> WEP and WPA requires a couple of kld's to be loaded before they can be configured. The following kld's should be added to loader.conf<br /> wlan_acl_load=&quot;YES&quot;<br /> wlan_amrr_load=&quot;YES&quot;<br /> wlan_ccmp_load=&quot;YES&quot;<br /> wlan_tkip_load=&quot;YES&quot;<br /> wlan_wep_load=&quot;YES&quot;<br /> wlan_xauth_load=&quot;YES&quot;<br /> <br /> ==== WEP ====<br /> Enable and test WEP in Adhoc mode on the HPN.<br /> WEP makes use of a single PSK that needs to be configured on all the wireless nodes. Any node or wireless device that is configured with this PSK will have the capability to crypt and decrypt these wireless packets. There are two methods to configure WEP in FreeBSD. You can use either use ifconfig directly or you can make use of the WPA supplicant utility.<br /> <br /> ifconfig e.g.<br /> mesh-9e69:~ # ifconfig ath0 10.10.1.2/24 wep deftxkey 1 wepkey 128bitwepison<br /> mesh-9e69:~ # ifconfig ath0<br /> ath0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500<br /> ether 00:80:48:50:9e:69<br /> inet6 fe80::280:48ff:fe50:9e69%ath0 prefixlen 64 scopeid 0x1<br /> inet6 fd9c:6829:597c:20:280:48ff:fe50:9e69 prefixlen 64<br /> inet6 fd9c:6829:597c:20:: prefixlen 64 anycast<br /> inet 10.10.1.2 netmask 0xffffff00 broadcast 10.10.1.255<br /> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g &lt;adhoc&gt;<br /> status: associated<br /> ssid ptamesh channel 13 (2472 Mhz 11g) bssid 56:e5:be:30:14:5a<br /> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5<br /> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7<br /> roam:rate11g 5 protmode CTS burst<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Enable WEP on three mesh nodes and test connectivity.<br /> mesh-9e69:~ # ping6 ff02::1%ath0<br /> 16 bytes from fe80::280:48ff:fe50:9e69%ath0, icmp_seq=87 hlim=64 time=2.122 ms<br /> 16 bytes from fe80::280:48ff:fe50:9ddd%ath0, icmp_seq=87 hlim=64 time=5.625 ms(DUP!)<br /> 16 bytes from fe80::280:48ff:fe50:9a44%ath0, icmp_seq=87 hlim=64 time=32.358 ms(DUP!)<br /> <br /> Everything seems to work fine (as expeted) with WEP enabled in the mesh.<br /> <br /> '''WPA'''<br /> <br /> WPA was designed to work in an environment where you have one AP and several clients and not for Adhoc (mesh) networks. On the AP you have the Authenticator software and on the client you have the supplicant software. This means that if one would like to use WPA to it's full then every mesh node needs to be an Authenticator for all the other nodes it can see, as well as a supplicant for every node it can see. According to the WPA design document http://wirelessafrica.meraka.org.za/wiki/images/3/39/Wpa_supplicant-devel-04.pdf one can use WPA in Adhoc mode only in a static way with PSK's:<br /> IEEE 802.11 operation mode (Infrastucture/IBSS).<br /> 0 = infrastructure (Managed) mode, i.e., associate with an AP.<br /> 1 = IBSS (ad-hoc, peer-to-peer)<br /> Note: IBSS can only be used with key_mgmt NONE (plaintext and static WEP) and key_mgmt=WPA-<br /> NONE (fixed group key TKIP/CCMP). In addition, ap_scan has to be set to 2 for IBSS. WPA-None requires<br /> following network block options: proto=WPA, key_mgmt=WPA-NONE, pairwise=NONE, group=TKIP<br /> (or CCMP, but not both), and psk must also be set (either directly or using ASCII passphrase).<br /> <br /> This is methods is very similar to the way that WEP is being used. This means the the only advantage of using WPA over WEP is that one can make use of the AES encryption engine that comes with WPA. Please note that with this mode of WPA and with WEP that anyone can decrypt the data being send over the air if they get hold of the mesh-wide PSK that is configured on every node in the network. If security is of importance them end users should consider the use of point-to-point security mechanisms like VPN's.<br /> <br /> The configuration of WPA is not supported in command line mode, but only with the wpa_supplicant software. This is an example of a wpa_supplicant.conf file to enable WPA in Adhoc mode:<br /> <br /> ap_scan=2<br /> #<br /> network={<br /> ssid=&quot;ptamesh&quot;<br /> # Channel 13 : 2472 Mhz 11g<br /> frequency=2472<br /> mode=1<br /> proto=WPA<br /> key_mgmt=WPA-NONE<br /> pairwise=NONE<br /> group=TKIP<br /> psk=&quot;mesh-ipv6&quot;<br /> }<br /> <br /> To start the WPA software during boot-up one needs to add WPA to the ifconfig line in rc.conf. E.g.<br /> <br /> ifconfig_ath0=&quot;WPA 10.10.1.1/24 mode 11g mediaopt adhoc channel 13 ssid ptamesh&quot;<br /> <br /> Test configuration:<br /> <br /> Host A ----- wep ------- Host B ----- wep Host C<br /> <br /> Unfortunately WPA did not work as easy as WEP, so it's off to debugging.<br /> <br /> Starting wpa_supplicant in the foreground with debugging enabled. E.g<br /> <br /> wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> <br /> The debugging output shows that something happens that initiates a wlan scan operation, while the card is in Adhoc mode. This should not happen and wpa_supplicant software never completes the configuration due to this error.<br /> <br /> mesh-9ddd:~ # wpa_supplicant -d -i ath0 -c /etc/wpa_supplicant.conf<br /> Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' <br /> ctrl_interface 'N/A' bridge 'N/A'<br /> Configuration file '/etc/wpa_supplicant.conf' -&gt; '/etc/wpa_supplicant.conf'<br /> Reading configuration file '/etc/wpa_supplicant.conf'<br /> ap_scan=2<br /> Priority group 0<br /> id=0 ssid='ptamesh'<br /> Initializing interface (2) 'ath0'<br /> EAPOL: SUPP_PAE entering state DISCONNECTED<br /> EAPOL: KEY_RX entering state NO_KEY_RECEIVE<br /> EAPOL: SUPP_BE entering state INITIALIZE<br /> EAP: EAP entering state DISABLED<br /> EAPOL: External notification - portEnabled=0<br /> EAPOL: External notification - portValid=0<br /> Own MAC address: 00:80:48:50:9d:dd<br /> wpa_driver_bsd_set_wpa: enabled=1<br /> wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1<br /> wpa_driver_bsd_del_key: keyidx=0<br /> wpa_driver_bsd_del_key: keyidx=1<br /> wpa_driver_bsd_del_key: keyidx=2<br /> wpa_driver_bsd_del_key: keyidx=3<br /> wpa_driver_bsd_set_countermeasures: enabled=0<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> Setting scan request: 0 sec 100000 usec<br /> Added interface ath0<br /> State: DISCONNECTED -&gt; SCANNING<br /> Trying to associate with SSID 'ptamesh'<br /> Cancelling scan request<br /> WPA: clearing own WPA/RSN IE<br /> Automatic auth_alg selection: 0x1<br /> wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1<br /> WPA: No WPA/RSN IE available from association info<br /> WPA: Set cipher suites based on configuration<br /> WPA: Selected cipher suites: group 8 pairwise 1 key_mgmt 16 proto 1<br /> WPA: clearing AP WPA IE<br /> WPA: clearing AP RSN IE<br /> WPA: using GTK TKIP<br /> WPA: using PTK NONE<br /> WPA: using KEY_MGMT WPA-NONE<br /> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 <br /> f2 02 01 00 00 50 f2 00 01 00 00 50 f2 00<br /> No keys have been configured - skip key clearing<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> wpa_driver_bsd_set_drop_unencrypted: enabled=1<br /> State: SCANNING -&gt; ASSOCIATING<br /> wpa_driver_bsd_associate: ssid 'ptamesh' wpa ie len 24 pairwise 0 group 2 key <br /> mgmt 4<br /> ioctl[SIOCS80211, op 22, len 24]: Invalid argument<br /> Association request to the driver failed<br /> wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=0 set_tx=1 <br /> seq_len=6 key_len=32<br /> Cancelling authentication timeout<br /> State: ASSOCIATING -&gt; COMPLETED<br /> CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=-1 <br /> id_str=]<br /> EAPOL: External notification - portControl=ForceAuthorized<br /> <br /> Next was to install fresh copy of the FreeBSD src code onto my PC. I found the wpa_supplicant source code under /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c Build a new driver from source code and run it on a router. After that I've added in a lot of printf statements to trace how the driver works and to locate the code that puts the wifi card in scanning mode. In the end I found out that wpa_supplicant driver did not put the card in scanning mode, but it somehow caused the 802.11 stack to start the scanning. Unfortunately I don't know enough about the 802.11 code in FreeBSD to do any mode debugging. I've send a mail about the problem to one of the FreeBSD mailing lists and the originator of most of the 802.11 code in FreeBSD (Sam Leffler) said I must log a problem report. So I logged a problem report with FreeBSD and now we have to wait and see if someone to take responsibility to fix this problem. More information on the problem report can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=126822<br /> <br /> For now I recommend that we make use of WEP instead of WPA in our implementation as it is working and there isn't such a big advantage in using WPA over WEP in this mode except for the encryption algorithm that changes from WEP to AES.<br /> <br /> == Antenna calculations ==<br /> <br /> Every HP-node has two 5.15-5.6 GHz antennas. The one as a build in patch antenna and the other is an 5.1-5.8 GHz omni-directional antenna. The idea is that the patch antenna of a node will either be aligned to the omni or the patch antenna of another node. The following calculations is to get an feeling of what distances should be possible between these antennas.<br /> <br /> South African Wifi channels:<br /> Channel 1 : 2412 Mhz 11g Channel 48 : 5240 Mhz 11a<br /> Channel 2 : 2417 Mhz 11g Channel 52 : 5260* Mhz 11a<br /> Channel 3 : 2422 Mhz 11g Channel 56 : 5280* Mhz 11a<br /> Channel 4 : 2427 Mhz 11g Channel 60 : 5300* Mhz 11a<br /> Channel 5 : 2432 Mhz 11g Channel 64 : 5320* Mhz 11a<br /> Channel 6 : 2437 Mhz 11g Channel 100 : 5500* Mhz 11a<br /> Channel 7 : 2442 Mhz 11g Channel 104 : 5520* Mhz 11a<br /> Channel 8 : 2447 Mhz 11g Channel 108 : 5540* Mhz 11a<br /> Channel 9 : 2452 Mhz 11g Channel 112 : 5560* Mhz 11a<br /> Channel 10 : 2457 Mhz 11g Channel 116 : 5580* Mhz 11a<br /> Channel 11 : 2462 Mhz 11g Channel 120 : 5600* Mhz 11a<br /> Channel 12 : 2467 Mhz 11g Channel 124 : 5620* Mhz 11a<br /> Channel 13 : 2472 Mhz 11g Channel 128 : 5640* Mhz 11a<br /> Channel 36 : 5180 Mhz 11a Channel 132 : 5660* Mhz 11a<br /> Channel 40 : 5200 Mhz 11a Channel 136 : 5680* Mhz 11a<br /> Channel 44 : 5220 Mhz 11a Channel 140 : 5700* Mhz 11a<br /> <br /> HP-Node detailed specs: http://wirelessafrica.meraka.org.za/wiki/images/0/07/WLAN-A0033.pdf<br /> <br /> Pigtail detail specs: http://wirelessafrica.meraka.org.za/wiki/images/0/0a/Ca178_cable_assemblies_datasheet.pdf<br /> <br /> Wireless adapter detail specs: http://wirelessafrica.meraka.org.za/wiki/images/2/21/Wlm54sag23.pdf<br /> <br /> OR the Mikrotik version of the same adapter called a R52H (also manufactured by Compex, but usually cheaper)<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:R52H.pdf<br /> <br /> Another popular adapter is the DCMA-82 from Wistron. They have better RX sensitivity, but lower output power and they are a bit more expensive than the Compex cards. In some of the discussions that I've seen they state that the DCMA-82 has much cleaner output power, better RX sensitivity, and a lower failure rate/quality issues than Compex's cards.<br /> http://wirelessafrica.meraka.org.za/wiki/index.php/Image:DCMA-82.pdf<br /> <br /> Node specs summary:<br /> Patch antenna - 21-23 dBi, 16 deg H, 11 deg V, 5.15 -5.6 GHz<br /> 5Ghz Omni antenna - 8-11 dBi, 360 deg H, 10 deg V, 5.1 - 5.85 GHz<br /> 2.4Ghz Omni antenna - 7.5-8.5 dBi, 360 deg H, 12 deg V, 2.4 - 2.5 GHz<br /> 30mm U.FL-SMA pigtail - RG178 cable insertion loss, 2.4 GHZ = -1.1dB, 5.6 GHz = -2dB<br /> Compex WLM54AG23 adapter - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 23dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> 17dBm @ 54Mbps<br /> Mikrotik (Compex) R52H - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -70 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 24dBm @ 6-24Mbps<br /> 22dBm @ 36Mbps<br /> 19dBm @ 48Mbps<br /> Wistron DCMA-82 - IEEE 802.11a/b/g (2.4/5GHz)<br /> - AR5413/5414(AR5006X/XS) Atheros Chipset<br /> - RECEIVER SENSITIVITY 802.11a - <br /> -90 dBm @ 6Mbps<br /> -82 dBm @ 36Mbps<br /> -72 dBm @ 54Mbps<br /> - OUTPUT POWER 802.11a<br /> 22.5dBm @ 6-24Mbps<br /> 21.5dBm @ 36Mbps<br /> 18dBm @ 48Mbps<br /> <br /> I could not find any receive sensitivity info for ranges between 6Mbps and 54Mbps for the WLM54AG23. The closest I could find was the specs of another manufacturer card, using the same Atheros chipset as the WLM54AG23. Here is the receive sensitivity info for a WMIA-166AG Dual-Band miniPCI module (802.11a/g)<br /> Nominal Temp Range:<br /> 6Mbps 10-5 BER @ -90 dBm, typical<br /> 9Mbps 10-5 BER @ -89 dBm, typical<br /> 12Mbps 10-5 BER @ -88 dBm, typical<br /> 18Mbps 10-5 BER @ -86 dBm, typical<br /> 24Mbps 10-5 BER @ -82 dBm, typical<br /> 36Mbps 10-5 BER @ -78 dBm, typical<br /> 48Mbps 10-5 BER @ -72 dBm, typical<br /> 54Mbps 10-5 BER @ -68 dBm, typical <br /> <br /> The WLM54AG23 is not the best wifi adapter in the market, but it gives a good compromise between price vs performance. If one need to push the limits of a specific link then I would probable select the SR5 from Ubiquity. They have excellent TX power and RX sensitivity.<br /> <br /> There are lots of wifi/antenna/distance calculators available on the WEB. Most of these calculators cannot calculate the max distance for a link, you have to specify the distance and it will calculate you dBm margin. Links to a couple of Wifi/antenna/distance calculators:<br /> <br /> http://www.radiolabs.com/stations/wifi_calc.html<br /> http://www.zytrax.com/tech/wireless/calc.htm<br /> http://www.widgetbox.com/widget/wifi-link-calculator<br /> http://www.wifiextreme.com.au/index.php?main_page=page_5<br /> http://www.rflinx.com/help/calculations<br /> http://www.olotwireless.net/castella/radio.htm<br /> <br /> Here are some formulas use to calculate a link budget:<br /> Free space loss = 36.56 + 20Log10(Frequency) + 20Log10(Dist in miles)<br /> mW to dBm = 10Log10(milliWatts) + 30<br /> dBm to mW = 10(dBm/10)<br /> RX Power = Margin - RX sensitivity<br /> Theoretical margin = TX power budget + RX power budget - free space loss<br /> SAD factor = Theoretical margin/TX power budget * 100 and shows the percentage of spare power on transmission.<br /> <br /> (Free Space Loss) = 92.5 + (20 Log fequency) + (20 log km distance)<br /> <br /> Free space loss @ 5400GHz:<br /> 1km = -107.07dB 11km = -128.028dB<br /> 2km = -113.09dB 12km = -128.784dB<br /> 3km = -116.61dB 13km = -129.479dB<br /> 4km = -119.11dB 14km = -130.123dB<br /> 5km = -121.05dB 15km = -130.722dB<br /> 6km = -122.63dB 16km = -131.282dB<br /> 7km = -123.97dB 17km = -131.809dB<br /> 8km = -125.13dB 18km = -132.305dB<br /> 9km = -126.15dB 19km = -132.775dB<br /> 10km = -127.07dB 20km = -133.221dB<br /> <br /> The following are the minimum and maximum link calculations for our HPNode with a 5Ghz patch to omni link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Omni: <br /> Min link distance @ 54Mbps 0.9km: Max link distance @ 54Mbps 1.55km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -106dB Free space loss = -111dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 6.9km: Max link distance @ 24Mbps 12.3km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> 34km free space = -124dB Free space loss = -129dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 17km: Max link distance @ 6Mbps 30.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> omni min = 8dBi omni max = 11dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> 34km free space = -132dB Free space loss = -137dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> The following are the minimum and maximum link calculations for our HPnodes with a 5Ghz patch to patch link under ideal conditions with a decent fresnel zone. Just note that one very seldom get ideal conditions in real life installations. These calculations are done to get a feeling for what to expect from our equipment. Link distance calculations was done with these calculator at http://www.swisswireless.org/wlan_calc_en.html. I've first played around with the Free-space-loss values in the Link Budget tool until I would get a 6dB margin. They recommend to take a sufficient security margin (5-6 dB or more on large distances). Then I've used the Free space loss tool to convert my Free-space-loss value to a km distance. Lets do some calculations to see what we get.<br /> <br /> Patch - Patch:<br /> Min link distance @ 54Mbps 3.9km: Max link distance @ 54Mbps 6km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 17dBm TX power = 17dBm<br /> RX sensitivity = -70dBm RX sensitivity = -70dBm<br /> Free space loss = -119dB Free space loss = -123dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 24Mbps 30.9km: Max link distance @ 24Mbps 38.9km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -82dBm RX sensitivity = -82dBm<br /> Free space loss = -137dB Free space loss = -139dB<br /> link margin = 6dB link margin = 6dB<br /> <br /> Min link distance @ 6Mbps 77.6km: Max link distance @ 6Mbps 123km:<br /> patch min = 21dBi patch max = 23dBm<br /> pigtail = -2dBm pigtail = -2dBm<br /> TX power = 23dBm TX power = 23dBm<br /> RX sensitivity = -90dBm RX sensitivity = -90dBm<br /> Free space loss = -145dB Free space loss = -149dB<br /> link margin = 6dB link margin = 6dB</div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=File:002.jpg&diff=4598 2009-04-07T10:44:54Z

<p>JHugo: </p> <hr /> <div></div>

JHugo http://wirelessafrica.meraka.org.za/wiki/index.php?title=EeePC_and_FreeBSD_page&diff=4574 2009-03-24T12:04:40Z

<p>JHugo: /* Putting FreeBSD onto my EeePC */</p> <hr /> <div>[[Category: Development Team Research Pages]][[Category: Johann's Research Pages]]<br /> <br /> == Putting FreeBSD onto my EeePC ==<br /> <br /> OK, finally get around to it. First read John's info on the wiki: http://wiki.meraka.csir.co.za/wiki/index.php/Category:ASUS_eeePC<br /> <br /> Then copy John's FreeBSD EeePC distribution (img.tgz) to my PC. Follow Werner's instructions to get the distro on USB memory stick<br /> <br /> fdisk -I da0<br /> fdisk -B da0<br /> bsdlabel -w da0s1 auto<br /> bsdlabel -B da0s1<br /> newfs /dev/da0s1a<br /> mount /dev/da0s1a /mnt<br /> tar -xvf img.tgz -C /mnt/<br /> echo /dev/da0s1a / ufs rw 1 1 &gt; /mnt/etc/fstab<br /> echo ifconfig_DEFAULT=DHCP &gt; /mnt/etc/rc.conf<br /> echo hostname=demo &gt;&gt; /mnt/etc/rc.conf<br /> umount /mnt<br /> <br /> Plug into USB port on EeePC. Select boot form USB (Press ESC at bootup to get menu) Boot FreeBSD Dump WinXP image on a USB disk<br /> <br /> dd if=/dev/ad2 of=/dev/da2 bs=4k<br /> <br /> Follow instructions above to get FreeBSD on ad2<br /> <br /> fdisk -I ad2<br /> fdisk -B ad2<br /> bsdlabel -w ad2s1 auto<br /> bsdlabel -B ad2s1<br /> newfs -U /dev/ad2s1a<br /> mount /dev/ad2s1a /mnt<br /> tar -cf - --exclude /mnt / | tar -xvpf - -C /mnt<br /> echo /dev/ad2s1a / ufs rw 1 1 &gt; /mnt/etc/fstab<br /> <br /> Enable ipv6, ssh and moused in /etc/rc.conf<br /> <br /> ipv6_enable=&quot;YES&quot;<br /> sshd_enable=&quot;YES&quot;<br /> moused_enable=&quot;YES&quot;<br /> <br /> Shutdown and reboot.<br /> <br /> Install Xorg and KDE<br /> <br /> setenv PACKAGEROOT ftp://ftp2.za.freebsd.org<br /> pkg_add -r xorg<br /> pkg_add -r kde-lite<br /> <br /> Enable and test sound. Add the following line in /boot/loader.conf<br /> <br /> snd_hda_load=&quot;YES&quot;<br /> <br /> <br /> Search for app that can show the battery status in X. Install and test desktopbsd-tools. Battery status works. Test wifi install gui. Not impressed, it only supports WEP<br /> <br /> pkg_add -r desktopbsd-tools<br /> <br /> Battery status works. Test wifi install gui. Not impressed, it only supports WEP. Delete package and search for other battery apps. See that KDE has a package that can show battery status. Install klaptopdaemon.<br /> <br /> pkg_add -r kdeutils-klaptopdaemon<br /> <br /> Battle to get it to work. Eventually find out that you have to load AMP (advanced power management). Edit /etc/rc.conf and add the following lines.<br /> <br /> amp_enable=&quot;YES&quot;<br /> ampd_enable=&quot;YES&quot;<br /> <br /> Shutdown and reboot<br /> <br /> Login and start KDE. Enable battery monitor under kde &quot;Start&quot; &quot;Settings&quot; &quot;Power control&quot; &quot;Laptop Battery&quot;. Yes, I get a new battery icon. Remove power and test it. Battery shows power, but reporting of &quot;time left&quot; is broken.<br /> <br /> Enable power manager to preserve power while running on battery. Add following to rc.conf<br /> <br /> powerd_enable=&quot;YES&quot;<br /> <br /> and lower CPU speed. Add the following to /etc/sysctl.conf<br /> <br /> dev.cpu.0.cx_lowest=C3 <br /> <br /> Try to get dstumbler to work so that we can use the EeePC as a wireless measurement PC. Install BSD-airtools (dstumbler part of it), but it looks like the package is broken. Search for other packages that we can use, but I can't find anything. Start looking at what command line stats available.<br /> <br /> Try to enable virtual screen resolution in Xorg. Add the following in the Screen section of xorg.conf<br /> <br /> SubSection &quot;Display&quot;<br /> Viewport 0 0<br /> Depth 24<br /> Virtual 1200 720<br /> EndSubSection<br /> <br /> Restart X, but it doesn't work. Do a lot of reading and playing, but I cannot get it to work.</div>

JHugo