Main Page
Introduction
This project is building a 100 node Village Telco mesh network in Dili, Timor Leste. This will simultaneously provide a low cost local telephony service and a metropolitan IP backbone. The project is a collaboration between the Rowetel and Fongtil.
This Wiki documents the project management and technical parts of the project. It is hopeful the information will be useful for other Village Telco deployments.
What the Users are Saying
In January 2011 we interviewed several end users. A good example was Joao Do Carmo Pinto, who runs the CDC, an NGO in Baucau that helps people develop businesses around local skills and produce. Examples were small business canning or preserving local fish and fruit. When asked about the Village Telco Joao said:
- "It works really well, as long as the power is on it is 100% reliable. My GSM phone bill has dropped. I would love to see this deployed all over Baucau and would be happy to help promote it."
When asked how we could improve the Mesh Potato:
- "Multiple phones at the one site, for example one in each room. All my staff want them at home."
Funding and Support
The project is being kindly funded from two sources:
1/ The Information Society Innovation Fund ISIF.
2/ This Project was made possible in part through a donation from the Internet Society (ISOC) Community Grants Program ISOC.
Special thanks to Atcom who are manufacturing a batch of Mesh Potatoes just for this project.
Background
Dili is the largest city in Timor Leste, one of the poorest countries in Asia. Mobile and fixed phone service is available but simply too expensive for the average Timorese.
There is almost no local Internet infrastructure. For example it is impossible to send an IP packet from one side of Dili to the other without sending the packet overseas using a VSAT link or a dedicated point to point Wifi link. The cost of connecting to the Internet via VSAT discourages local Internet content – as all Internet traffic must be fetched from overseas via expensive and slow VSAT pipes.
Connectivity is typically provided via small ISPs which often distribute Internet from a VSAT using a 10-20 node point-multipoint Wifi networks. These networks require tall, expensive, and often unsafe masts. Each ISP re-crosses the same path as neighbouring ISPs which is a waste of resources and an inefficient use of spectrum.
A Village Telco is built from low cost, rugged Wifi telephony devices (the Mesh Potato). Each Mesh Potato provides a single telephone land-line to the end user, and is connected to other Mesh Potatoes via a mesh Wifi network. Mesh Potatoes are robust to developing world environmental conditions (e.g. accidental abuse, weather, static damage, poor electricity supply) and are designed for low power consumption. While telephony is the primary goal, the mesh network can also carry data.
Dili Village Telco
The Dili Village Telco is one of the first Village Telco roll outs in the world.
The Mesh Network is be a public resource, managed by Fongtil, such that anyone in Dili can have fair access to the bandwidth. This provides low cost access to local IP traffic. Applications include VOIP, web and as a pipe for ISP traffic.
Goals
1. Train Timorese to roll out a Village Telco network and in associated technologies (mesh Wifi, VOIP, mesh node installation and maintenance).
2. Deploy a 100 node Village Telco mesh network to build a local call telephone network.
3. Use the Mesh Wifi network to provide a community IP backbone across metropolitan Dili to encourage local IP traffic and local content.
Status
August 17, 2010: All Mesh Potatoes and associated hardware have been delivered to Dili, and are already being deployed (WP4000). A total of 80 nodes will be deployed in Dili over the next few months. We have also decided to build 10 node networks in the country towns of Baucau and Ermera.
August 2, 2010: The 10 node pilot network has been in daily use for 2 months. Ninety more Mesh Potatoes are en route to Dili. These nodes will be deployed (WP4000) over the next two months.
May 25 2010: Ten node Pilot network has been deployed, WP3000 is complete. Deployment of next 90 nodes (WP4000) starting in June.
April 29 2010: We are currently executing WP3000 "April Workshop and Pilot network". We are have completed the April 2010 Workshop and the 10 node pilot network is currently being installed by the Fongtil team.
September 23, 2010: Baucau and Ermera Village Telcos kicked off, and the Dili network grows to 34 nodes.
November 26 2010: Dili (40 nodes), Baucau (9 nodes), and Ermera (6 nodes) now have Mesh Potato networks running and in daily use. There are some link issues on 20% of the mesh links in Dili that we would like to fix.
January 17 2011: Dili (50 nodes), Baucau (9 nodes), and Ermera (6 nodes). Many happy customers using the system every day. There is significant demand for more nodes, so the roll out will continue. The Dili team is working on ways to improve the poorer mesh links across Dili.
February 10 2011: ISIF and ISOC Grant funded portion of project is complete, final reports have been submitted. However the Fongtil team will continue to invest time and resources into growing the network in 2011.
May 2012: Fongtil continue to maintain the network, evangelise Village Telco Technology in Timor Leste, and train people in Mesh Potato set up. Around 60 operational nodes in Dili. Still problems with reliable Wifi links in Dili.
Press, Media and Blog Posts
This project has generated a lot of interest with the media! Here are some pods casts and media articles. They make nice introductions to the Village Telco.
Media Stories:
1. March 2010, Latin Radical pod cast which has many interesting pod casts on Timor Leste.
2. April 2010, David was interviewed on Radio Australia's Tech Stream program.
3. April 20, 2010 Radio Australia Connect Asia Program. Similiar material as (2), but a different radio program.
4. April 20, 2010 Radio Australia Pacific Beat Program. Similiar material as (2), but a different raidio program.
5. April 20, 2010: Komunikasaun Alternativa foun Baratu ba Timor oan Timor Expose news story (Timorese news site in Tetum).
Blog Posts documenting the project:
1. April 20, 2010: Dili Village Telco Part 1 David and Rosemary arrive in Dili, talk about the plans for the project, and what it's like to visit Timor Leste.
2. April 22, 2010: Dili Village Telco Part 2 Training day.
3. April 24, 2010: Dili Village Telco Part 3 Assembling mesh nodes.
4. April 24, 2010: Dili Village Telco Part 4 Problem with interference.
5. April 25, 2010: Dili Village Telco Part 5 Installing mesh nodes at the University.
6. April 25, 2010: Dili Village Telco Part 6 Training on testing mesh links.
7. April 29, 2010: Dili Village Telco Part 7 Ermera mesh network and Batman over Ethernet.
8. April 29, 2010: Dili Village Telco Part 8 Lessons learned from April 2010 Trip.
9. May 25, 2010: Dili Village Telco Part 9 Ten node Pilot Network and WP3000 complete.
10. August 31, 2010: Dili Village Telco Part 10 The Dili Village Telco rolls out.
11. November 26, 2010: Ermera Village Telco Anders Hofstee has integrated Mesh Potatoes with his existing OSLR/Robin mesh network in Ermera, Timor Leste.
12. November 30, 2010: Baucau Village Telco Alipio Simoes trains local Timorese to set up a Village Telco in Baucau, Timor Leste.
13. December 3, 2010: Mesh Potato Spectrum Analyser Checking Wifi spectrum for interference and cardboard directional antennas.
14. January 9, 2011: Baucau Village Telco Part 2 We visit Baucau and talk to some very happy end users. Well done Alipio!
15. January 23, 2011: Dili Village Telco Part 11 - State of the Mesh Dilimesh mapping application, improving Links, ease of use, future of the Dili Village Telco.
16. May 9, 2012: ISIF award for Dili Village Telco. Fongtil and Rowetel are chosen from a field of 50 entrants for an ISIF award for the Dili Village Telco.
Photos:
Photos from the Dili Village Telco from Steve's Fickr account.
Presentations and Training Courses:
1. A non-technical overview of the Dili Village Telco Project OO in presentation form.
2. Introductory technical course on the Village Telco, Mesh Potato, and mesh networking.
3. Dili Village Telco presentation at linux.conf.au (LCA) January 2011, Brisbane, Australia. Slides available in Open Office and PDF form and here is the Video.
Contact
email: David Rowe <david_at_rowetel_dot_com>, Lemi Soares <ict4ngotimor_at_gmail_dot_com>
IRC..: irc.freenode.net #villagetelco channel
Thanks
1. The Henschke, Nescoli, and Merchant families in Kilkenny for letting me place test nodes at their houses.
2. Robert Boerner for helping to maintain this Wiki during a spam attack.
Project Plan
WP1000 Management
Write project plan and detailed task list, prepare sub contracts with Fongtil, set up budget lines manage project, measure outcomes, monitor progress.
WP2000 Kilkenny Mesh
Set up a small mesh network in David's suburb of Kilkenny, Adelaide, that models the Dili Village Telco. Gain experience in roof-top installations, Mesh Wifi performance measurement, and debugging problems. Set up server functions such as Supernode and Afrimesh. Performing this set up in a first world environment is good preparation for the Dili Village Telco roll out.
WP3000 April Workshop
A workshop Dili, Timor Leste, scheduled for April 2010, and presented by Rowetel. A training course will be presented to the Village Telco and Mesh Potato, and a 10 node Pilot network will be installed.
The training course will cover Village Telco introduction, mesh Wifi, the Mesh Potato operation and an overview of it's hardware and software components. Practical work will include configuring the Mesh Potato, reflashing and demonstrations of various problems such as interference and line of sight issues.
The installation part of the Worskhop will include assembly of the Mesh Potatoes into weatherproof boxes, building power cables, and Power over telephone Line (PoTL) adaptors. The nodes will be installed by the Fongtil team, and VTE server functions brought up. A gateway will be installed to connect local calls to the GSM/PSTN networks. Performance monitoring software will be installed to monitor the 10 node Pilot network.
Rowetel will work with Fongtil to debug and correct problems, gathering valuable experience for the Village Telco projects in the process.
WP4000 100 Node Village Telco
Using the experience gained with the Pilot network, the Fongtil team will extend the network to 100 nodes over a period of several months between July and October 2010. The completed network will supply local telephony and Internet backbone services. Fongtil will manage the day to day operation of the Dili Village Telco.
WP5000 Evaluation Visit
Rowetel will visit Dili to evaluate the project and troubleshoot any problems. Data will be gathered, and end users interviewed to see how effective the local telephony and IP backbone functions have been to the people of Dili. Reports will be published on the web to disseminate the project results as widely as possible. Selected training and installation information will be translated into Tetun and Bahasa Indonesian.
Network Design and Device Configuration
This section describes the IP network design used to implement the Dili Village Telco, including hints on configuration and testing. The goals of the network design are:
- To allow phone calls between Mesh Potatoes.
- To allow phone calls from Mesh Potatoes to the IP0X Asterisk server, which can gateway phone calls to the GSM/PSTN networks.
- To allow laptops to connect to the Mesh network via normal (non batman) Wifi Access Points (APs).
- Implement a "flat", no NAT network. Any computer on the network should be able to talk to any other computer on the network. For example a laptop connected to Wifi AP should be able to download content from a web server connected to the Ethernet port of a Mesh Potato on the other side of Dili. This supports local Timorese content and the "IP backbone" goal of the Dili Village Telco.
Network Diagram
The figure below shows the basic design, including the IPs of various subnets: Batman routes IP packets between the subnets, for example from 10.130.1.8 to 10.30.1.4. Batman also handles routing of IP packets to the Internet, via the Supernode. Once roll out is complete, there will be 100 Mesh Potatoes (only two are shown below). Mesh Potato 8 is an example of a Mesh Potato that has a Wifi Access Point (AP) connected. This allows regular Linux and Windows laptops to connect to the mesh network using normal (non Batman) Wifi. Mesh Potato 8 runs a DHCP server that allocates IPs to the local laptops. The DIR-300 could be any Wifi AP that can run in Access Point(bridged) mode, it is not running OpenWRT or Batman.
Notes and Common problems
1. The 192.168.1.0/24 and 10.30.1.x/24 networks share the same physical LAN (sample cables and Ethernet switch). This is because it is a very bad idea to route 192.168.1.0/24 packets to the mesh network. The 192.168.1.0/24 IP range is very common for LANs so we do not want to configure Batman to use this IP range, it would lead to confusion. To implement the "flat network" design we need subnets connected to the LAN to have a unique IP range on the 10.0.0.0/8 network. So we use 10.30.1.0/24 for the LAN connected to the 10.130.1.1 Mesh Potato, and 10.30.8.0/24 for the LAN connected to the 10.130.1.8 Mesh Potato.
2. Batman uses Policy routing, so routes to batman won't show up in the normal route table on Mesh Potatoes. The following example shows the ping/route command running on Mesh Potato 10.130.1.8. It has nothing connected to it's Ethernet (eth0) port. You can see we have an Internet connection (ping to Google works), but the route table shows the wrong gateway (192.168.1.20 on eth0). Batman hides the routing.
root@OpenWrt:/# ping google.com -c 3 PING google.com (150.101.98.211): 56 data bytes 64 bytes from 150.101.98.211: seq=0 ttl=60 time=31.679 ms 64 bytes from 150.101.98.211: seq=1 ttl=60 time=31.268 ms 64 bytes from 150.101.98.211: seq=2 ttl=60 time=30.167 ms root@OpenWrt:/# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.31.255.252 0.0.0.0 255.255.255.252 U 0 0 0 eth0 10.130.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ath0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.30.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.20 0.0.0.0 UG 0 0 0 eth0
3. If you connect a computer to the Ethernet port of a Mesh Potato you need a route from that computer back to the 10.130.1.0/24 batman network. For example on a Linux computer plugged into 10.30.1.0/24 LAN:
# ifconfig eth0:0 10.30.1.3 netmask 255.255.255.0 # route add -net 10.130.1.0/24 gw 10.30.1.1 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.130.1.0 10.30.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 10.30.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 192.168.1.22 0.0.0.0 UG 0 0 0 eth0
The route command tells the Linux computer to use 10.30.1.1 (Supernode) as a gateway to the 10.130.1.0/24 network. Without the route command packets can't find the mesh network. This Linux machine also has an eth0 interface on the 192.168.1.0/24 network.
Reading Further
This page documents the most important information for the Dili Village Telco. There is much more information on the Mesh Potato Howto section of the Village Telco Wiki.
Supernode
The Supernode is a Ubiquity Nanostation 2 which is similar to a Mesh Potato but does not have a FXS port. The Supernode provides the following functions:
- Gateways the mesh network to the 192.168.1.x network and hence the Internet.
- Gateways the mesh network to the 10.30.1.x network.
- Is the DNS server for the mesh network.
- Runs the batman visualization server (used for Afrimesh).
1. Instructions for flashing a Nanostation 2 with the Supernode firmware are here. Note that the default IP is 192.168.10.20 (not 192.168.1.20). To access the Supernode from a Linux computer:
# ifconfig eth0:1 192.168.10.1 # telnet 192.168.10.20
2. Set the password (passwd), then telnet will be disabled and ssh enabled when you reboot.
3. Use vi to edit /etc/config/network so it looks like this:
root@OpenWrt:/etc/config# cat network
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'ipaddr' '192.168.1.100'
option 'netmask' '255.255.255.0'
option 'gateway' '192.168.1.1'
option 'dns' '192.168.1.1'
config alias
option 'interface' 'lan'
option 'proto' 'static'
option 'ipaddr' '10.30.1.1'
option 'netmask' '255.255.255.0'
config 'interface' 'wifi0'
option 'ifname' 'ath0'
option 'proto' 'static'
option 'ipaddr' '10.130.1.1'
option 'netmask' '255.255.255.0'
Note in the file above we assume 192.168.1.1 is your Internet gateway, and DNS server, and that 192.168.1.100 with be the IP of the Supernode on the 192.168.1.0/24 network. Change as appropriate for your LAN.
4. Use vi to edit /etc/config/batmand to look like this:
config 'batmand' 'general'
option 'interface' 'ath0'
option 'hna' '10.30.1.0/24'
option 'originator_interval' ''
option 'preferred_gateway' ''
option 'policy_routing_script' ''
option 'disable_client_nat' ''
option 'disable_aggregation' ''
option 'gateway_class' '5000'
option 'routing_class' ''
option 'visualisation_srv' '10.130.1.1'
5. /etc/config/wireless should look like this:
config 'wifi-device' 'wifi0'
option 'type' 'atheros'
option 'channel' '1'
config 'wifi-iface'
option 'device' 'wifi0'
option 'encryption' 'none'
option 'ssid' 'potato'
option 'mode' 'ahdemo'
option 'bssid' '01:CA:FF:EE:BA:BE'
option swmerge 1
option bgscan 0
option 'network' 'wifi0'
6. Make sure dnsmasq (the DNS server) is started when the Supernode boots. If no link exists to /etc/init.d/dsnmasq create one:
root@OpenWrt:/etc/rc.d# ln -s ../init.d/dnsmasq S60dnsmasq
7. Reboot and test that you can ssh into the Supernode through the 192.168.1.0/24 IP:
# ssh [email protected]
8. ifconfig should look like:
root@OpenWrt:/etc/config# ifconfig
ath0 Link encap:Ethernet HWaddr 00:15:6D:A6:6E:FB
inet addr:10.130.1.1 Bcast:10.130.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:54049864 errors:0 dropped:85 overruns:0 frame:0
TX packets:4177245 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3569047834 (3.3 GiB) TX bytes:574004051 (547.4 MiB)
eth0 Link encap:Ethernet HWaddr 00:15:6D:E0:6E:FB
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:580545 errors:0 dropped:0 overruns:0 frame:0
TX packets:272528 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:406619435 (387.7 MiB) TX bytes:374502504 (357.1 MiB)
Interrupt:4 Base address:0x1000
eth0:1 Link encap:Ethernet HWaddr 00:15:6D:E0:6E:FB
inet addr:10.30.1.1 Bcast:10.31.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:4 Base address:0x1000
gate0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:169.254.0.0 P-t-P:169.254.0.0 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1471 Metric:1
RX packets:206 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:60856 (59.4 KiB) TX bytes:420 (420.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:48316 errors:0 dropped:0 overruns:0 frame:0
TX packets:48316 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3672638 (3.5 MiB) TX bytes:3672638 (3.5 MiB)
wifi0 Link encap:UNSPEC HWaddr 00-15-6D-A6-6E-FB-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32718875 errors:0 dropped:0 overruns:0 frame:452913
TX packets:4177892 errors:3219 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:195
RX bytes:4042919661 (3.7 GiB) TX bytes:666069218 (635.2 MiB)
Interrupt:3 Memory:b0000000-b00ffffc
9. A ps command should show batmand, the visualization server vis, and the DNS server dnsmaq running:
root@OpenWrt:/etc/config# ps <snip> 675 nobody 1276 S /usr/sbin/dnsmasq -K -D -y -Z -b -E -s lan -S /lan/ - 694 root 1600 S batmand -a 10.30.1.0/24 -g 5000 -s 10.130.1.1 ath0 695 root 1600 S batmand -a 10.30.1.0/24 -g 5000 -s 10.130.1.1 ath0 697 root 1600 S batmand -a 10.30.1.0/24 -g 5000 -s 10.130.1.1 ath0 698 root 1600 S batmand -a 10.30.1.0/24 -g 5000 -s 10.130.1.1 ath0 708 root 1540 S vis -j ath0 709 root 1540 S vis -j ath0 711 root 1540 S vis -j ath0 712 root 1540 S vis -j ath0 <snip>
10. You should be able to ping devices on the LAN and mesh Wifi networks:
root@OpenWrt:~# ping 192.168.1.1 root@OpenWrt:~# ping 10.30.8.2 root@OpenWrt:~# ping 10.130.1.2
This example assumes there is a 10.30.8.2 computer on the LAN and a Mesh Potato with IP 10.130.1.2.
11. If other Mesh Potatoes are running you should be able to see them using batmand -d1 -c:
root@OpenWrt:~# batmand -d1 -c Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... 10.130.1.3 (255) 10.130.1.3 [ ath0]: 10.130.1.3 (255) 10.130.1.8 (254) 10.130.1.8 [ ath0]: 10.130.1.8 (254) 10.130.1.7 (252) 10.130.1.7 [ ath0]: 10.130.1.7 (252) 10.130.1.6 (245) 10.130.1.6 [ ath0]: 10.130.1.6 (245)
12. You should be able to ping IPs on the Internet and DNS should be working:
root@OpenWrt:~# ping 8.8.8.8 -c 5 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=241 time=222.475 ms 64 bytes from 8.8.8.8: seq=1 ttl=241 time=226.580 ms 64 bytes from 8.8.8.8: seq=2 ttl=241 time=225.057 ms 64 bytes from 8.8.8.8: seq=3 ttl=241 time=223.272 ms 64 bytes from 8.8.8.8: seq=4 ttl=241 time=224.434 ms root@OpenWrt:~# ping google.com -c 5 PING google.com (150.101.98.211): 56 data bytes 64 bytes from 150.101.98.211: seq=0 ttl=61 time=24.163 ms 64 bytes from 150.101.98.211: seq=1 ttl=61 time=24.952 ms 64 bytes from 150.101.98.211: seq=2 ttl=61 time=25.809 ms 64 bytes from 150.101.98.211: seq=3 ttl=61 time=27.851 ms 64 bytes from 150.101.98.211: seq=4 ttl=61 time=25.165 ms
Mesh Potato
The first step is to set the mesh Wifi IP. Each Mesh Potato must have a unique 10.130.1.x IP on the mesh network.
Using Web GUI
You need a Ubuntu Linux computer with an IP on the 192.168.1.0/24 network:
1. Connect your Ubuntu Linux computer to the Mesh Potato Ethernet port.
2. Start a terminal: Applications->Accessories-Terminal
3. In the terminal:
$ sudo su - # /etc/init.d/NetworkManager stop # ifconfig eth1 down # ifconfig eth0 192.168.1.4 # ping 192.168.1.20 -c 5
Make sure ping to to 192.168.1.20 works.
5. Point your web browser at http://192.168.1.20, login with user/password root/admin.
6. Change the IP Address from 10.130.1.x to 10.130.1.yourchoice. Note there is no save - just move your mouse to another GUI field and you are finished.
7. Reboot: Remove the power to your potato then plug the power back in.
8. To restore your Linux computer network settings:
# /etc/init.d/NetworkManager start
Using a Telephone
1. Switch on the Mesh Potato and wait for dial tone in the telephone (1 minute).
2. Dial 2663 (CONF using letters).
3. Wait for the prompt "Just what do you think you're doing Dave...."
4. Dial the IP on the telephone, for example 10*130*1*123
5. Wait a few seconds. The IP will be read back to you.
6. Count to 5. Hangup the phone.
7. Reboot: Remove the power to your potato then plug the power back in.
Testing the Mesh Potato
- You are now ready to make phone calls. Just dial the last digits of the IP of another Mesh Potato. For example to dial Mesh Potato 10.130.1.123 dial "123". You can also dial a full IP, for example 10*130*1*123.
- Check your mesh Potato Wifi IP on the GUI using the Web GUI procedure above.
- If other Mesh Potatoes are running you should be able to see them using batmand -d1 -c. You can run this on the Supernode (see above) or any Mesh Potato:
root@OpenWrt:~# batmand -d1 -c Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... 10.130.1.3 (255) 10.130.1.3 [ ath0]: 10.130.1.3 (255) 10.130.1.8 (254) 10.130.1.8 [ ath0]: 10.130.1.8 (254) 10.130.1.7 (252) 10.130.1.7 [ ath0]: 10.130.1.7 (252) 10.130.1.6 (245) 10.130.1.6 [ ath0]: 10.130.1.6 (245)
To get a console on a Mesh Potato use from your Linux computer use telnet 192.168.1.20. After the MP01 password has been set, use ssh [email protected].
Mesh Potato with Wifi AP
In the Figure above, MP8 is connected to a Wifi Access Point (AP). This allows laptops a way to connect to the mesh network for:
- Internet access.
- Connecting to any other machine on the Mesh Network.
The laptop to AP link uses regular (non mesh) Wifi.
This section discusses the configuration of MP8, which can be repeated for other Mesh Potatoes that have Wifi APs connected.
Notes:
- DNS is provided by the Supernode at 10.130.1.1
- A DHCP server runs on MP8, which distributes configuration information to the laptops.
- The Wifi IP runs in bridge mode, any traffic between the Ethernet and Wifi interfaces is simply repeated. There is no NAT between the Ethernet and Wifi interfaces.
- The DIR-300 Wifi AP used for these tests runs standard firmware, as supplied from the store. It isn't running OpenWRT or batman. Any Wifi AP can be used, if it can run in bridge mode (called AP mode on the DIR-300 web GUI). The Wifi AP was configured to fetch it's configuration via DHCP.
- Batman handles routing of Internet traffic and traffic to other parts of the mesh.
- MP8 (mesh IP 10.130.1.8) uses the local LAN 10.30.8.0/24. For Mesh Potato 10.130.1.X, use local LAN 10.30.X.0/24.
1. /etc/config/network
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'
config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.1.20'
option 'gateway' '192.168.1.20'
option 'dns' '10.130.1.1'
config alias
option 'interface' 'lan'
option 'proto' 'static'
option 'ipaddr' '10.30.8.1'
option 'netmask' '255.255.255.0'
config 'interface' 'wifi0'
option 'ifname' 'ath0'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '10.130.1.8'
Note: The gateway entry above:
option 'gateway' '192.168.1.20'
Is needed, even though it does nothing (batman handles the Internet gateway function). Without it Asterisk can't make phone calls, and you see errors like:
-- extension exists, starting PBX 8
-- Executing [8@default:1] Dial("MP/1", "SIP/4...@10.130.1.8") in
new stack
[Dec 11 17:29:16] WARNING[597]: chan_sip.c:1775 __sip_xmit: sip_xmit of
0x585a88 (len 772) to 10.130.1.8:5060 returned -2: Bad file descriptor
-- Called 4...@10.130.1.8
2. /etc/config/wireless
config wifi-device wifi0 option type atheros option channel 1 config wifi-iface option device wifi0 option mode "ahdemo" option ssid "potato" option bssid 01:CA:FF:EE:BA:BE option swmerge 1 option bgscan 0 # Set distance for wireless long-shots in meters. # option distance 5500 # Broad- and multicast rate may be set here. Using default 1Mbit. # option mcast_rate 5500 # 17dBm transmit power is the maximum option txpower 17 # Don't use if you don't know what you are doing. option bursting 0 option turbo 0
3. /etc/config/batmand
config batmand general
option interface ath0
option announce 10.30.8.0/24
option gateway_class
option originator_interval
option preferred_gateway
option routing_class 1
option visualisation_srv 10.130.1.1
option policy_routing_script
4. The DHCP server is configured by /etc/udhcpd.conf
max_leases 100 start 10.30.8.100 end 10.30.8.199 interface eth0 lease_file /tmp/udhcpd.leases domain lan pidfile /tmp/udhcpd.pid option dns 10.130.1.1 option subnet 255.255.255.0 option router 10.30.8.1 lease 7200
The file /etc/init.d/dhcpd was added to start the DHCP server:
#!/bin/sh /etc/rc.common
# Copyright (C) 2008 OpenWrt.org
START=97
start() {
[ -f /etc/udhcpd.conf ] && udhcpd
}
And a symbolic link to start the DHCP server at boot time:
root@OpenWrt:# cd /etc/rc.d root@OpenWrt:/etc/rc.d# ln -s ../init.d/dhcpd S95dhcpd root@OpenWrt:/etc/rc.d# chmod 755 ../init.d/dhcpd
Now reboot.
5. After a reboot important entries of ps show
root@OpenWrt:/etc/rc.d# ps x <snip> 563 root 1584 S batmand -a 10.30.8.0/24 -r 1 -s 10.130.1.1 ath0 564 root 1584 S batmand -a 10.30.8.0/24 -r 1 -s 10.130.1.1 ath0 565 root 1584 S batmand -a 10.30.8.0/24 -r 1 -s 10.130.1.1 ath0 569 root 1968 S udhcpd <snip>
6. Useful tests
From MP8, try:
root@OpenWrt:# ping 10.130.1.1 (link to Supernode) root@OpenWrt:# ping 8.8.8.8 (an address on the Internet) root@OpenWrt:# ping google.com (tests DNS and Internet connectivity) root@OpenWrt:# ping 10.30.8.100 (Wifi AP, which should get it's address via DHCP)
From a laptop connected to the Wifi AP, check
- The laptop can connect and gets an address on the 10.30.8.x/24 network
- ping 10.30.8.100 (Wifi AP), and 10.30.8.1 (MP8)
- Then repeat ping tests above
IP04
1. You can set up an aliased eth0 interface and route by modifying /etc/inet.d/network-static to look like:
#!/bin/sh
# Start up file for network with static IP.
IF=eth0
IPADDRESS="192.168.1.216"
NETMASK="255.255.255.0"
GATEWAY="192.168.1.1"
DNS="192.168.1.1"
case $1 in
start) ifconfig $IF $IPADDRESS netmask $NETMASK up;
route add default gw $GATEWAY;
ifconfig eth0:1 10.30.1.4 netmask 255.255.255.0;
route add -net 10.130.1.0/24 gw 10.30.1.1;
echo "nameserver $DNS" > /etc/resolv.conf;;
stop) ifconfig $IF down;;
enable) rm -f /etc/rc.d/S10network-static;
ln -s /etc/init.d/network-static /etc/rc.d/S10network-static;;
disable) rm -f /etc/rc.d/S10network-static;;
*) cat <<EOF;;
Syntax: /etc/init.d/network-static [command]
Available commands:
start Start the service
stop Stop the service
enable Enable service autostart
disable Disable service autostart
EOF
esac
Note the ifconfig eth0:1 10.30.1.4 netmask 255.255.255.0 and route add -net 10.130.1.0/24 gw 10.30.1.1 lines.
Be very careful to include the semi-colons in the file above. Any errors in this file will break the IP04 Ethernet interface. You will then need the serial cable to correct the problem.
3. Reboot the IP04, check ifconfig and route -n:
root:~> ifconfig
eth0 Link encap:Ethernet HWaddr 00:09:45:56:1E:DD
inet addr:192.168.1.216 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3953301 errors:0 dropped:0 overruns:0 frame:0
TX packets:2882733 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Interrupt:48
eth0:1 Link encap:Ethernet HWaddr 00:09:45:56:1E:DD
inet addr:10.30.1.4 Bcast:10.30.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:48
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8176 errors:0 dropped:0 overruns:0 frame:0
TX packets:8176 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
root:~> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.30.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.130.1.0 10.30.1.1 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.22 0.0.0.0 UG 0 0 0 eth0
4. Check you can ping nodes on the mesh network:
root:~> ping 10.30.1.1 root:~> ping 10.130.1.1 root:~> ping 10.130.1.123
5. Telnet/ssh into 10.130.1.123, and check it can ping the IP04:
root@OpenWrt:~# ping 10.30.1.4
We assume that the Supernode is 10.130.1.1 and there is a Mesh Potato with IP 10.130.1.123.
6. Add some dial plan to /etc/asterisk/extension.conf on the IP04 to call an MP01 10.130.1.123:
[default] exten => 4000,1,Dial(SIP/10.130.1.123/4000)
At the IP04 command line, start and Asterisk CLI and reload the dialplan:
root:~> asterisk -r ip04*CLI> dialplan reload
Now try dialing 4000 from an IP04 extension. To debug monitor the Asterisk CLI on the IP04 and Mesh Potato (use set verbose 5 to gather lots of information).
Tests
The x86 sever is a convenient place to perform tests. Using ssh/telnet you can connect to any Mesh Potato from the x86 server. As the server has an IP on the 192.168.1.0/24 LAN you can ssh to the server from other machines on the local LAN.
1. nmap is really useful for testing which nodes are up:
david@dilivt1:~$ nmap -sP 10.130.1.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-12 07:47 CST Host supernode (10.130.1.1) is up (0.0018s latency). Host mp2 (10.130.1.2) is up (0.015s latency). Host mp3 (10.130.1.3) is up (0.016s latency). Host mp4 (10.130.1.4) is up (0.033s latency). Host mp5 (10.130.1.5) is up (0.015s latency). Host mp6 (10.130.1.6) is up (0.019s latency). Host mp7 (10.130.1.7) is up (0.034s latency). Host mp8 (10.130.1.8) is up (0.018s latency). Nmap done: 256 IP addresses (8 hosts up) scanned in 2.71 seconds
2. If you ssh to the Supernode, batmand -d1 -c gives you information on the mesh links, but the display can get very crowded:
root@OpenWrt:~# batmand -d1 -c Originator (#/255) Nexthop [outgoingIF]: Potential nexthops ... 10.130.1.3 (255) 10.130.1.3 [ ath0]: 10.130.1.3 (255) 10.130.1.8 (254) 10.130.1.8 [ ath0]: 10.130.1.8 (254) 10.130.1.7 (252) 10.130.1.7 [ ath0]: 10.130.1.7 (252) 10.130.1.6 (245) 10.130.1.6 [ ath0]: 10.130.1.6 (245)
3. From the Supernode ping the Internet, 10.130.1.x mesh Wifi nodes, 10.30.1.x hosts.
root@OpenWrt:# ping 8.8.8.8 (an address on the Internet) root@OpenWrt:# ping 10.130.1.123 (another mesh node) root@OpenWrt:# ping google.com (tests DNS and Internet connectivity) root@OpenWrt:# ping 10.30.1.4 (IP04, tests routing over mesh)
4. Some Wifi tests using ping are described on the Mesh Potato Howto page.
x86 Server
For the Dili Village Telco the x86 server is a Lenovo S10E netbook running Ubuntu 9.10 Karmic Koala. sshd and smokeping have been installed using the package manager. Some additional setup notes:
1. There is a nasty Ethernet bug on the S10Es. When large amounts of data at high speed flow over the Ethernet interface (for example a large web page or cat a large file over the LAN), the Ethernet port stops working! An ifconfig eth0 down && ifconfig eth0 up will bring the port up again. This doesn't occur with slower transfers, e.g. downloads from the Internet.
The fix is to add the file /etc/network/if-up.d/broadfix:
#!/bin/bash
if [[ "$IFACE" == eth[01] ]]; then
ethtool -K $IFACE rx off tx off
fi
Make this file executable and restart eth0:
root@dilivt1:/etc/network/if-up.d# chmod +x broadfix root@dilivt1:/etc/network/if-up.d# ifconfig eth0 down root@dilivt1:/etc/network/if-up.d# ifconfig eth0 up
It will be restarted every time the S10E boots.
2. Setting up an Ethernet interface on 10.30.1.0/24. This is a bit tricky as NetworkManager can interfere. An approach that works with NetworkManager is to add the file /etc/network/if-up.d/potato:
#!/bin/sh # Add interface and routes to connect to potato mesh network ifconfig eth0:0 10.30.1.3 netmask 255.255.255.0 route add -net 10.130.1.0/24 gw 10.30.1.1
Make it executable:
# chmod u+x /etc/network/if-up.d/potato
3. SmokePing is a really useful tool that graphs ping over time:
It can show when the mesh goes down for various reasons. It is useful to send short and long ping packets (Smokeping probes). Sometimes the mesh network will pass small packets well but long ones will be corrupted, for example due to interference. A mesh network that can reliably send large ping packets is a healthy mesh network. Here is some more information on debugging Mesh Networks.
Some Smokeping config files for the Dili Village Telco are:
/etc/smokeping/config.d/Probes
*** Probes *** + FPing binary = /usr/bin/fping ++ FPingNormal offset = 0% ++ FPingLarge offset = 50% packetsize = 1400
/etc/smokping/config.d/Targets
*** Targets *** probe = FPingNormal menu = Top title = Dili Village Telco remark = Dili Village Telco + Latency menu = DiliVT title = Dili Village Telco ++ localhost menu = localhostNormal title = localhost Normal probe = FPingNormal host = localhost ++ localhostLarge menu = localhostLarge title = locathost Large probe = FPingLarge host = localhost ++ SupernodeNormal menu = SupernodeNormal title = Supernode Normal probe = FPingNormal host = 10.130.1.1 ++ SupernodeLarge menu = SupernodeLarge title = Supernode Large probe = FPingLarge host = 10.130.1.1 ++ MP2 menu = MP2Normal title = MP2 Normal probe = FPingNormal host = 10.130.1.2 ++ MP2Large menu = MP2Large title = MP2 Large probe = FPingLarge host = 10.130.1.2
Just add more entries for MP3, MP4,......
Note: When smokeping is installed I needed to move smokeping.cgi:
# cd /var/www # mkdir smokeping # cp /usr/lib/cgi-bin/smokeping.cgi smokping
You can then view the smokeping web pages on http://server//cgi-bin/smokeping.cgi
4. Some files to make moving around the mesh easier, and save some typing:
/usr/bin/nmap-dilivt
#!/bin/sh nmap -sP 10.130.1.0/24
/etc/hosts
david@dilivt1:~$ cat /etc/hosts 127.0.0.1 dilivt1 localhost.localdomain localhost 127.0.1.1 dilivt-laptop1 10.130.1.1 supernode 10.130.1.2 mp2 10.130.1.3 mp3 10.130.1.4 mp4 10.130.1.5 mp5 10.130.1.6 mp6 10.130.1.7 mp7 10.130.1.8 mp8
Recovery
If you have serious problems with a Mesh Potato or Supernode, the best approach is to flash the firmware. This will reset it to a known state. This is much easier than searching through many conf files and using Linux command line tools to find one small error. Then configure the device as described above.
Mesh Potato Fall back IP
The Mesh Potato has a special fallback IP interface 172.31.255.254 that is always present if Linux is running. The 172.31.255.254 fallback IP may work even if the eth0 IP (192.168.1.20) has stopped working. You can telnet/ssh or try the web GUI using the 172.31.255.254 fallback IP.
Reflashing the Mesh Potato
1. The easiest way to flash a Mesh Potato is the ap51-flash command line tool (Linux version Windows version).
2. Connect your Mesh Potato into the Ethernet (eth0) port of your Ubuntu Linux PC. Make sure the Ethernet cable is OK and that you have located the correct Ethernet port. You can test using ping on the PC to send some data out of eth0, make sure the network light blinks on the Mesh Potato.
3. Stop the Ubuntu network manager running, as this can interfere:
[david@bunny mp_images]$ sudo /etc/init.d/network-manager stop
Or on some Ubuntu machines this step is:
[david@bunny mp_images]$ sudo /etc/init.d/NetworkManager stop
4. Unplug the power to the Mesh Potato for 2 seconds and plug the power back in. This will start the Mesh Potato boot loader.
5. When the "link" light comes on the Mesh Potato, start the ap51-flash software.
[david@bunny mp_images]$ sudo ./ap51-flash eth0 openwrt-atheros-root-rv233.squashfs openwrt-atheros-vmlinux-rv233.lzma
If it works, you will see:
Reading rootfs file openwrt-atheros-root-rv233.squashfs with 4325376 bytes... Reading kernel file openwrt-atheros-vmlinux-rv233.lzma with 720896 bytes... rootfs(0x006f0000) + kernel(0x000b0000) + nvram(0x00000000) sums up to 0x007a0000 bytes Peer MAC: 00:09:45:57:a7:f9 Peer IP : 192.168.1.114 Your MAC: 00:ba:be:ca:ff:ee Your IP : 192.168.1.0 Setting IP address... Loading rootfs... Sending rootfs, 8448 blocks... Initializing partitions... Flashing rootfs... Loading kernel... Sending kernel, 1408 blocks... Flashing kernel... Setting boot_script_data... Done. Restarting device... <snip>
6. The whole process will take a few minutes. The process will pause at the Flashing rootfs... and Flashing kernel... steps. Please be patient, the Mesh Potato is busy writing the images to flash, which is a slow process.
7. When you see Restarting device wait a few minutes for the Mesh Potato to reboot. When the Wifi light starts blinking, or there is dial tone in the telephone, you are ready to test.
With your laptop configured for a 192.168.1.0/24 network you can try to connect using telnet:
[david@bunny mp_images]$ sudo ifconfig eth0 192.168.1.2
[david@bunny mp_images]$ telnet 192.168.1.20
Trying 192.168.1.20...
Connected to 192.168.1.20.
Escape character is '^]'.
=== IMPORTANT ============================
Use 'passwd' to set your login password
this will disable telnet and enable SSH
------------------------------------------
BusyBox v1.14.4 (2010-01-13 18:19:41 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.
+++++++++++++++++++++++++++++++++++++++++++++++++++
Welcome to the
__ __ __ __ ___ __ ___ __
|\/| |_ |__ |_| __ |__| | | | |__| | | |
| | |__ __| | | | |__| | | | | |__|
O-----O
O / \ / \ 0
/ \ / \ / \ / \
O---O O----O O O-----O O---O
\ / \ / \ / \ /
O \ / \ / O
O-----O
Revision: 233 --- powered by OpenWrt Kamikaze
+++++++++++++++++++++++++++++++++++++++++++++++++++
root@OpenWrt:/#
Reflashing the Supernode
The easiest way to flash the Nanostation 2 Supernode is with the open-mesh-flash tool.
Notes:
- If you copy the supernode files to a USB key, use MD5sum to double check the files are OK. It is easy to pull the USB key out with the files partially written.
[david@bunny supernode]$ md5sum * 6902c581293a5aa9a02c082ac8c93f0e open-mesh-flash b021441eef6d6fd80cc10f6772eb9a0c openwrt-atheros-ubnt2-squashfs.bin eaa0ad13e984e45035a1174ba96859ac openwrt-atheros-vmlinux.lzma
- Timing can be important during this procedure. If you see Redboot telnet not supported, quickly restart open-mesh-flash using the up arrow.
- It is a good idea to turn off network manager first, see the Mesh Potato reflash procedure above.
- Do not touch the Nanostation while the colourful LEDs are blinking. This will take a few minutes. When they stop blinking remove the power for 2 seconds then plug the power back in. This will reboot the Nanostation.
- Use ping 192.168.10.20 to test:
# sudo ifconfig eth0 192.168.10.4 # ping 192.168.10.20
You need to configure your Ubuntu PC to be on the 192.168.10.0/24 network to ping and telnet the Supernode. You can change the IP of the Supernode later.
- If ping works then try telnet
# telnet 192.168.10.20
Horst Spectrum Analyser
An experimental feature we hope will be useful in debugging and tuning mesh links. More information on David's blog and this README file.
Screen shot (click for larger image):
Installation
1. Download these two files onto a host PC:
david@dilivt1:~$ wget http://rowetel.com/downloads/mp/horst david@dilivt1:~$ wget http://rowetel.com/downloads/mp/horst.sh
2. Copy to your Mesh Potato:
scp horst horst.sh [email protected]:/usr/sbin
3. Connect to the Mesh Potato using an Ethernet cable (not Wifi). Horst is most effective when scanning Wifi channels, but scanning (changing channels) will break any Wifi connections to the MP. It can be used in single channel mode over good quality Wifi links if you don't want to scan channels. An Ethernet connection is strongly recommended at first.
Using Ubuntu for the host PC and assuming the default eth0 MP IP of 192.168.1.20:
david@dilivt1:~$ sudo /etc/init.d/network-manager stop david@dilivt1:~$ sudo ifconfig eth0 192.168.1.2 david@dilivt1:~$ ssh [email protected]
4. On the MP01 make sure the permissions of the horst files are executable:
root@OpenWrt:~# chmod u+x /usr/sbin/horst /usr/sbin/horst.sh
5. Maximise your console window before you start horst- at least 100x30 characters. Otherwise some pop up windows like F-filter and C-channel won't work, and you won't see all of the spectrum. To start:
root@OpenWrt:~# horst.sh
6. Try the "N" spectrum analyser option. Press C-Channel and A for automatic scanning of channels. The I option toggles various views. On the "IP" and "IP Average" views look for signals "*" that might be interfering with your Batman IPs.
7. Other useful options are F-Filter to filter on just one Source MAC - useful for aligning antennas. When aligning antennas C-Channel E-enter channel to select just a single channel to get faster updates.
9. Press Q-quit to quit horst.
Known Issues
1. If C-channel of F-filter doesn't work make your console larger or use smaller font.
Testing Antennas and Disabling Diversity Antenna 2
One application for Horst is testing external antennas, for example directional high gain antennas. The Mesh Potato, like many routers, has two antennas, numbered 1 and 2. Antenna 1 is a tx/rx antenna, and Antenna 2 is only rx, sometimes called a "diversity" antenna. This helps with multipath issues where the signal received by one antenna may be very weak, but very strong in another antenna just a few cm away. Multipath effects are especially common during indoor operation.
Now we usually connect external antennas to Antenna 1, as we use external antennas for long range tx/rx operation. However the Mesh Potato Wifi driver tends to favour Antenna 2 for receive. So when testing antennas you can get confusing results: sometimes packets are received on Antenna 1 and sometimes on Antenna 2. These will usually have different signal strengths and will confuse antenna testing results.
So if you are using Horst to test antennas (or testing antennas with other software), it is useful to disable the receive only Antenna 2. First disable automatic antenna selection:
root@OpenWrt:~# echo 0 > /proc/sys/dev/wifi0/diversity
Then select just Antenna 1:
root@OpenWrt:~# echo 1 > /proc/sys/dev/wifi0/rxantenna
You can check using athstats:
root@OpenWrt:~# athstats
74 tx management frames
2691 tx failed due to too many retries
361969 long on-chip tx retries
13509527 tx frames with no ack marked
120624 tx frames with an alternate rate
761053 rx failed due to bad CRC
46146 PHY errors
15 transmit override receive
52 OFDM restart
46079 CCK restart
rssi of last ack: 17
rssi of last rcv: 24
739402 switched default/rx antenna
Antenna profile:
[1] tx 7247393 rx 37256094
[2] tx 7769498 rx 9750180
The last two lines from athstats indicate how many packets were received on Antenna 1 and how many on Antenna 2. After Antenna 1 is selected no more packets should be received on antenna 2. Try running athstats several times to check.
Note that a reboot is required to re-enable diversity (Antenna 2) operation, this:
root@OpenWrt:~# echo 1 > /proc/sys/dev/wifi0/diversity
doesn't seem to work.
Audio Ping
Ping tones "rendered" as audio tones. A prototype tuning tool for MP mesh Wifi links. For more information see David's blog post on this idea. Here is the source code.
This makes a really good demo with a speaker phone. You can test links to mesh nodes on your desk just by dialling, no ssh, ping, console commands. It also means people installing MPs don't need a laptop to test MPs.
1. Copy app_ping.so into /usr/lib/asterisk/modules/ on your MP01. Here is the x86 Linux version if you would like to try app_ping.so on your x86 Asterisk machine.
david@dilivt1:~$ scp app_ping.so [email protected]:/usr/lib/asterisk/modules
2. Add this dialplan to your /etc/asterisk/extensions.conf
[default]
; Audio ping, dial 4555, then last 3 digits of IP you want to ping,
; e.g. 001 for 10.130.1.1
exten => 4555,1,Answer
exten => 4555,2,Read(ip||3)
exten => 4555,3,Ping(10.130.1.${ip})
At the asterisk CLI load the module and the new dialplan:
OpenWrt*CLI> load app_ping OpenWrt*CLI> dialplan reload
Or simply reboot:
root@OpenWrt:~# reboot
3. You can monitor the Asterisk CLI (set debug 5), in the following example I dialled 4555, then 001 to ping 10.130.1.1:
OpenWrt*CLI> set debug 6
-- event_offhook
-- AST_STATE_DOWN:
-- event_dtmf 4
-- event_dtmf 5
-- event_dtmf 5
-- event_dtmf 5
-- event_digit_timer
-- extension exists, starting PBX 4555
-- event_dtmf 0
-- event_dtmf 0
-- event_dtmf 1
OpenWrt*CLI> set verbose 6
Verbosity was 0 and is now 6
The 'set verbose' command is deprecated and will be removed in a future release. Please use 'core set verbose' instead.
ping! 4.39 ms f 443 Hz
ping! 3.88 ms f 438 Hz
ping! 4.48 ms f 444 Hz
DiliMesh Mapping Application
Dilimesh is a Google Maps application which was developed to help manage and debug mesh links in the Dili Village Telco. As well as mapping nodes it calculates packet loss in real time and can report signal strengths of mesh links. It is very lightweight, easy to install, and is written mainly in Javascript in a single source file. This blog post describes Dilimesh and here is the Dilimesh README.
Click on the image below for a larger version:
Integrating With Open Mesh
Anders Hofstee from Catalpa International has integrated an open mesh network (running OLSR) with Mesh Potatoes. The approach is to flash Nanostation or Nanostation-loco devices with Open Mesh images, then install Batman and edit some conf files. the open mesh devices then run OLSR and Batman at the same time, so Mesh Potatoes can use the open mesh devices for routing.
This zip file contains the conf files that Anders has edited.
High Quality Mesh Links using 3rd Party Equipment HowTo
In Dili we had persistent problems with Wifi interference, sometimes on links as short as 300m. To overcome this we used Nanostation 2's flashed with the Supernode firmware as described above. For many links the 10dB directional antennas of the Nanostations could overcome interference. The Supernode firmware automatically meshed with the rest of the network, making set up very easy. So we would place a Nanostation at either end of a several hundred metre link, which would then mesh with nearby MP01s automatically.
However for some links we needed other technologies that could provide a high quality link between two parts of a Batman mesh network. This section describes how we set up high quality mesh links. Once the links are in place Batman will automatically route traffic over them, choosing them in preference to the regular omnidirectional Wifi links.
Ethernet Links
We had one case where we couldn't get a reliable Wifi link from the top of a 25m tower to the inside of an office building. So we used an Ethernet cable to link a node at the top of the mast to a node inside the office building. The node inside the office building then spread the mesh network within the building, overcoming the poor Wifi link to the top of the tower. Here is how we linked two MP01's via Ethernet
1. Assume we have Mesh Potato A (MPA) and Mesh Potato B (MPB).
2. MPA has a Wifi IP on the ath0 interface of 10.130.1.81, and we allocate an eth0:1 IP of 10.130.1.230
3. MPB has a Wifi IP on the ath0 interface of 10.130.1.82, and we allocate an eth0:1 IP of 10.130.1.233
4. Here is /etc/config/network for MPA. Note the final config alias entry that sets the eth0:1 IP address.
config 'interface' 'loopback' option 'ifname' 'lo' option 'proto' 'static' option 'ipaddr' '127.0.0.1' option 'netmask' '255.0.0.0' config 'interface' 'lan' option 'ifname' 'eth0' option 'proto' 'static' option 'netmask' '255.255.255.0' option 'ipaddr' '192.168.1.20' option 'dns' '192.168.1.20' option 'gateway' '192.168.1.20' config 'interface' 'wifi0' option 'ifname' 'ath0' option 'proto' 'static' option 'netmask' '255.255.255.0' option 'ipaddr' '10.130.1.81' config alias option 'interface' 'lan' option 'proto' 'static' option 'ipaddr' '10.130.1.230' option 'netmask' '255.255.255.0'
5. Here is /etc/config/batman. The quotes around "ath0 eth0:1" are important
config batmand general option interface "ath0 eth0:1" option announce option gateway_class option originator_interval option preferred_gateway option routing_class option visualisation_srv 10.130.1.1 option policy_routing_script
6. Reboot and run some checks
root@OpenWrt:/etc/config# ps x | grep bat
566 root 1592 S batmand -s 10.130.1.1 ath0 eth0:1
567 root 1592 S batmand -s 10.130.1.1 ath0 eth0:1
571 root 1592 S batmand -s 10.130.1.1 ath0 eth0:1
1568 root 1964 S grep bat
root@OpenWrt:/etc/config# ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:09:45:58:1D:AD
inet addr:10.130.1.230 Bcast:10.130.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:4 Base address:0x1000
7. Batman should find the link through eth0:1
root@OpenWrt:~# batmand -cd1 10.130.1.233 (184) 10.130.1.233 [ eth0:1]: 10.130.1.233 (184) 10.130.1.111 (109) 10.130.1.113 [ ath0]: 10.130.1.113 (109)
8. To test, try disabling the Wifi link on MPB. Our mesh network is on channel 1, so changing it to 10 will force Batman to use the Ethernet link.
root@OpenWrt:~# iwconfig ath0 channel 10
When you change the channel ssh to MPB will freeze, and pings to MPB will stop. After a few seconds Batman should re-establish the mesh link using the Ethernet cable.
Notes
1. Batman requires the eth0:1 IPs to have the same subnet and broadcast address as the ath0 Wifi IP. They all have to be on 10.130.1.0/24.
2. The eth0:1 IPs were chosen carefully to make sure they were unused by other nodes on the mesh.
3. Note that we have the 10.130.1.0/24 subnet mapped to the ath0 *and* eth0:1 interfaces:
root@OpenWrt:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.31.255.252 0.0.0.0 255.255.255.252 U 0 0 0 eth0 10.130.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 <- same subnet, different interface! 10.130.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ath0 <- same subnet, different interface! 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.20 0.0.0.0 UG 0 0 0 eth0
This makes ping tests and regular routing out of these interfaces tricky, but Batman uses IP routing and can handle this (think of Batman using a 32 bit routing mask). I mention this as having two interfaces on the same subnet confused the hell out of me.
Bridging with Ubiquity Nanobridge M5
As well as with M5's this will also work with any Layer 2 link that can bridge two Ethernet networks. Just make your choice of bridge work like the Ethernet cable above.
1. Start by setting up a bridge over Ethernet as above. Make sure this works OK before configuring the M5s.
2. Configure one M5 as "Access Point WDS". The default IP is 192.168.1.20,default username/pass ubnt/ubnt.
3. Allocate a SSID, we used "fongtil".
4. Change the password of the GUI on the System menu.
5. Set an IP for the M5. We used 10.130.1.231 for the Access Point and 10.130.1.232 for the Station. I don't think an IP on the mesh network subnet is critical, as the M5s are configured as Layer 2 bridges.
6. Save all changes and check that the changes are fixed by power cycling the M5 and checking again.
5. Repeat for the 2nd M5, configure as "Station WDS", use the same SSID.
6. Test the M5 to M5 link using ping from your laptop, then plug the M5s into the MP01 Ethernet ports.
Notes:
1. Make sure you use "Access Point WDS" and "Station WDS". The plain "Access Point" and "Station" modes don't work properly with Batman. I think the WDS versions implement a pure Layer 2 bridge. This is a subtle point - the Batman scores actually look OK with the "Access Point" and "Station" mode but pings across the mesh network don't work.
2. Some more information on using M5s for bridging, similar to out config but we used static IPs rather than dhcp Ubiquity HowTo on setting up a bridge
