Mesh Potato HOWTOs

SECN Firmware

What to do if you can not connect to the MP anymore - using the Fallback-IP

This can easily happen if you are messing around with the IP settings of the MP. Luckily the MP has a additional IP subnet at the Ethernet port that can not be changed or disabled from a web interface. If you manage to break the fallback mechanism as well follow the steps in the disaster recovery section [1].

On your PC configure the Ethernet port to use (netmask You can add multiple IP addresses to each interface, so you don't have to reconfigure it if you need other addresses as well. Assuming the Ethernet port is eth0, the CLI (command line interface) command is:

sudo ifconfig eth0:0 
sudo ifconfig eth0 up

Now you can access the MP @

If you are using Ubuntu, it may be better to do it with the Ubuntu Networkmanager GUI.

Preliminary Mesh Potato firmware disaster recovery HOWTO

Reflash the firmware from RedBoot

There is no serial console when the OpenWrt firmware has finished booting. The FXS interface is connected to the single serial port of the AR2317 chip and the drivers for the FXS interface get loaded on bootup. You can use the serial console (with a RS232 level converter) to connect to RedBoot. But you don't need to do that, RedBoot also supports Telnet.

Detect the IP address of the bootloader

I have noted that Atcom has configured a different bootloader (RedBoot) IP address on the beta production MPs - outsch!

The first 500 Mesh Potatoes (September 2010) look for your TFTP is configured in

RedBoot> ip_addr
IP:, Gateway:
Default server:

I don't know if Atcom has set these parameters for all the beta production MPs.

If you need to find out the RedBoot IP I suggest you install "nmap" on your computer and use the following script:

 while (true); do nmap -sP | grep "is up" ; done 

Configure your workstation to use IP, netmask

Start the script and power-cycle the MP. (You can stop the script with Ctrl+C when you are done.)

Scanning the full IP range takes > 5 seconds on my machine. The RedBoot timeout might be configured to 3 or 5 seconds, so you may need more than one try. (i.e. power-cycle the MP, wait a while, if no host is found, power-cyle it again) If you wait for too long the script will detect This response will come from the OpenWrt firmware which if it is already up and running.

You might want to fix this problem once you are connected to RedBoot.


RedBoot> fconfig
Run script at boot: true
Boot script: 
.. fis load -l vmlinux.bin.l7
.. exec
Enter script, terminate with empty line
>>  fis load -l vmlinux.bin.l7
>> exec
Boot script timeout (1000ms resolution): 5
Use BOOTP for network configuration: false
Gateway IP address:
Local IP address:
Local IP address mask:
Default server IP address:
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xa83d0000-0xa83e0000: .
... Program from 0x80ff0000-0x81000000 at 0xa83d0000: .

This will set the RedBoot IP to The TFTP server (your workstation) that RedBoot is trying to connect to if you flash the firmware via RedBoot is now

Setting up your workstation for TFTP flashing

Install a TFTP server. Open a terminal, become system administrator "root":

 sudo su 

Install a TFTP server like atftpd - using Debian or Ubuntu you can just perform:

 apt-get install atftpd 

Create a directory /tftpboot:

 mkdir /tftpboot 

If your Linux distribution installs / runs inetd - stop it.

Start the TFTP server:

 atftpd --daemon 

Copy openwrt-atheros-root.squashfs and openwrt-atheros-vmlinux.lzma from [2] into the /tftpboot directory.

Set up your workstation Ethernet interface to use

Install "putty" (don't use the default Linux telnet client).

Start putty.

Configure putty to connect to the MP IP configured in RedBoot (should be using the Telnet protocol on port 9000. Hint: Save this as a profile in putty, in case you need it again ;-)

Open a console and continuously ping (There will be no response yet)

Power-cycle the MP.

As soon as you get a ping response from the MP hit the "Connect" button in putty. You have got 5 seconds.

You should be connected to the MP bootloader command line interface now.

Reflash the firmware: [3]

Now the MP is back to factory settings.

Help - My Mesh Potato Can't Make Calls!

subtitle "how to debug your Beta Mesh Potato".

You have set up you beta Mesh Potato IPs but can't make calls. Here are some basic tests:

1. Can you hear dial tone in a phone connected to the MP? If not open the box and check if the FXS module is properly seated. Some of the modules have come loose while shipping.

2. Check you mesh network. Telnet/ssh into your MP and:

batctl o 

You should see the MAC addresses of the other MP(s) on your mesh. If you see no other MAC addresses then check your Wifi settings are identical except for the IP. These can be checked in /etc/config/wireless or via the GUI. Also compare "iwconfig ath0" on both MPs and "ifconfig ath0".

3. Try pinging one MP from the other.

4. On each MP, dial 4001. This performs an echo test. Can you hear your own voice coming back to you?

5. Start an Asterisk CLI and see what happens when you dial an IP:

root@OpenWrt:~# asterisk -r
OpenWrt*CLI> set verbose 3

Note : The 'set verbose' command is deprecated, please use 'core set verbose' instead.

Now dial the IP of another MP. You should see something like:

    -- event_offhook
    --   AST_STATE_DOWN:
    -- start mp_new
    -- event_dtmf 1
    -- event_dtmf 4
    -- event_dtmf 2
    -- event_digit_timer
    --   extension exists, starting PBX 142
    -- Executing [142@default:1] Dial("MP/1", "SIP/4000@") in new stack
    -- Called 4000@
    -- event_onhook
    --   default: hangup  sound_on = 1
  == Spawn extension (default, 142, 1) exited non-zero on 'MP/1'
    -- start mp_hangup

Mesh Wifi Tips

1/ You can check the quality of your mesh links with Batman:

root@OpenWrt:~# batctl o

2/ Ping gives an excellent indication of link quality.

(i) For example:

root@OpenWrt:~# ping -c 10
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=6.907 ms
64 bytes from seq=1 ttl=64 time=3.300 ms
64 bytes from seq=2 ttl=64 time=3.578 ms
64 bytes from seq=3 ttl=64 time=2.597 ms
64 bytes from seq=4 ttl=64 time=3.356 ms
64 bytes from seq=6 ttl=64 time=11.999 ms
64 bytes from seq=7 ttl=64 time=10.328 ms
64 bytes from seq=8 ttl=64 time=8.778 ms
64 bytes from seq=9 ttl=64 time=5.107 ms

Note the ping time various greatly. When a packet fails to get through, the Wifi protocols are re-transmit it. Re-transmission leads to variable ping times.

(ii) This is a better result:

root@OpenWrt:~# ping -c 10
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=3.348 ms
64 bytes from seq=1 ttl=64 time=4.632 ms
64 bytes from seq=2 ttl=64 time=3.410 ms
64 bytes from seq=3 ttl=64 time=4.206 ms
64 bytes from seq=4 ttl=64 time=3.338 ms
64 bytes from seq=5 ttl=64 time=3.570 ms
64 bytes from seq=6 ttl=64 time=4.892 ms
64 bytes from seq=7 ttl=64 time=4.838 ms
64 bytes from seq=8 ttl=64 time=3.354 ms
64 bytes from seq=9 ttl=64 time=3.432 ms

(iii) It is useful to try longer packets, as they have a harder time getting through the link. This example shows some re-transmission as the ping times vary:

root@OpenWrt:~# ping -c 10 -s 1400
PING ( 1400 data bytes
1408 bytes from seq=0 ttl=64 time=31.716 ms
1408 bytes from seq=1 ttl=64 time=27.861 ms
1408 bytes from seq=2 ttl=64 time=52.643 ms
1408 bytes from seq=3 ttl=64 time=15.225 ms
1408 bytes from seq=4 ttl=64 time=27.433 ms
1408 bytes from seq=5 ttl=64 time=21.490 ms
1408 bytes from seq=6 ttl=64 time=39.487 ms
1408 bytes from seq=7 ttl=64 time=27.663 ms
1408 bytes from seq=8 ttl=64 time=27.604 ms
1408 bytes from seq=9 ttl=64 time=25.945 ms

(iv) Sending packets a little faster can give you some useful statistics, this simulates VOIP packets:

root@OpenWrt:~# ./ping -c 100 -i 0.02 -q
PING ( 56(84) bytes of data.

--- ping statistics ---
100 packets transmitted, 96 received, 4% packet loss, time 2976ms
rtt min/avg/max/mdev = 2.702/3.614/7.060/0.985 ms

This simulates data traffic:

root@OpenWrt:~# ./ping -c 100 -i 0.1 -q -s 1400
PING ( 1400(1428) bytes of data.

--- ping statistics ---
100 packets transmitted, 96 received, 4% packet loss, time 10944ms
rtt min/avg/max/mdev = 15.880/18.361/81.060/8.031 ms

Both of these links look good (small packet loss), so would support voice and data OK.

This link:

root@OpenWrt:~# ./ping -c 100 -i 0.1 -q -s 1400
PING ( 1400(1428) bytes of data.

--- ping statistics ---
100 packets transmitted, 97 received, 3% packet loss, time 10912ms
rtt min/avg/max/mdev = 9.831/37.701/71.151/10.543 ms

Has a reasonable packet loss but the maximum ping time is very large compared to the minimum. This indicates a marginal link that could be improved.

Voice packets are very short, like a small ping packet. You can often make phone calls over a poor link, even though the link doesn't work well for data (which uses longer packets). Improve the link if you can, as voice quality and the number of calls the link can support will improve.

Note these example used a full function ping, This can be built in OpenWRT and scp-ed to your Mesh Potato. The other examples above used the standard, Busybox ping.

3/ You can determine the signal strength of other nodes using:

root@OpenWrt:~# arp -n
? ( at 00:15:6d:a7:f2:a4 [ether]  on ath0
? ( at 00:09:45:56:f6:b8 [ether]  on ath0
root@OpenWrt:~# wlanconfig ath0 list
00:09:45:56:ac:90    0   10  36M    0  -95     0   3918       1   1402       0              0        1   Normal
00:15:6d:a7:f2:a4    0   10  36M   36  -59     0     17       2   2623       0              0        1   Normal
00:09:45:56:ac:7c    0   10  36M   23  -72     0      2       0   1033       0              0        1   Normal
00:09:45:56:f6:b8    0   10  36M   23  -72     0     67       8   3672       0              0        1   Normal
00:09:45:57:a7:d0    0   10  36M   12  -83     0      0       0   3295       0              0        1   Normal
00:09:45:56:f6:c4    0   10  36M   16  -79     0      0       0   3427       0              0        1   Normal

The "arp" command lets you look up the MAC of each IP. The DBM column of the "wlanconfig" line shows the signal strength of of other nodes, listed by their MAC. In the example above (a node 500m away) has a received signal strength of -72dBm, and (a node 10m away but inside a house) is -54dBm.

If a node is not listed with "arp -n", then ping it. The ARP tables expire after a period of inactivity.

We are not sure how reliable these signal strength measurements are. The may vary from router to router and are not calibrated. End-end performance measures like ping, the Batman score, and voice quality are more reliable. Even with a good signal strength, you may have interference that affects the link quality.

4/ If your nodes are located indoor, multipath interference will be your main problem. Small changes in the router position will have a very big effect. Small changes in the room (like a person moving) can also have a very big effect. You can make the "batman -d1 -c" score double or halve by moving your router a few centimeters.

5/ With outdoor links line of sight is very important. Position your node so it can see the antenna of other nodes. Any objects in the way, such as trees or buildings will block the signal and give you a poor link. Moving the node and making it a little higher can have a very big effect on the link quality.

VT Firmware, based on batmand (layer 3) - Deprecated

The following howtos are based on an earlier firmware for the Mesh Potato which used batmand, a mesh protocol which operates at Layer 3 in the OSI stack. Village Telco has since migrated to the use of batman-adv, which sounds similar but is quite significantly different, operating at Layer 2. The two versions are not in any way compatible. Documentation below has been left for those who prefer to use batmand. It is no longer directly supported by Village Telco but some support may be found within the Village Telco community.

Getting Started with your 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:

1. Point your web browser at, login with user/password root/admin.

2. Change the Wifi IP from 10.130.1.x to 10.130.1.yourchoice.

3. Reboot: Remove the power to your potato then plug the power back in.

This blog post has lots more information on initial configuration, including several alternative ways to configure your Mesh Potato.

Telnet will work until you set the root password via the GUI or the command line:

$ telnet
root@OpenWrt:~# passwd

After you set the root password telnet will be disabled and ssh enabled:

$ ssh root@

Upgrading the Mesh Potato firmware with the potato-flash utility

An easy way to upgrade the Mesh Potato firmware is to use the potato-flash utility developed by Elektra. You can download the utility from

After than you can get the latest firmware for the Mesh Potato from

The potato-flash utility currently only works on Linux systems and has only been tested on recent versions of Ubuntu. Syntax for the potato-flash utility is as follows. It assumes you have put the utility somewhere in your command path such as /usr/local/bin. It needs to be executed as root.

sudo potato-flash eth0 openwrt-atheros-root-rv255.squashfs openwrt-atheros-vmlinux-rv255.lzma

In the above example, substitute whatever port your MP is connected to for eth0. eth0 is pretty common. Also, change rv255 to reflect the latest version of the firmware that you have downloaded e.g. openwrt-atheros-root-rv261.squashfs Make sure the ethernet cable is connected to your Mesh Potato but the Mesh Potato is powered off.

Reading rootfs file openwrt-atheros-root-rv255.squashfs with 2883584 bytes ...
Reading kernel file openwrt-atheros-vmlinux-rv255.lzma with 720896 bytes ...
Note: The device has to be connected directly (not via switch/hub)
Device detection in progress.....................

Now you can power up the Mesh Potato. The dots will continue to progress across the screen until the Mesh Potato is recognised and the firmware begins to update.

At this point,

Connecting a Mesh Potato to the Internet via a Laptop

This technique was used by David at LCA 2010 and by Steve when traveling. You have a laptop (running Linux) with a Wifi Internet connection, and a Mesh Potato that you want to connect to the Internet. The instructions below use your laptop as a NAT router for the Mesh Potato. Once the MP is connected to the Internet you can then use the dial-an-IP function to dial the IP of any other MP on the Internet.

1. Connect Laptop to MP01 with an Ethernet cable (it's auto sense do you probably don't a loopback Ethernet cable).

2. Set up a interface on your laptop Ethernet, telnet/ssh into the MP01 on say I assume Ethernet is eth0 on your laptop.

3. On the laptop connect to the Internet via Wifi. I assume this is eth1 on your laptop.

4. On the laptop open a root shell:

# iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
# iptables --append FORWARD --in-interface eth0 -j ACCEPT
# echo 1 > /proc/sys/net/ipv4/ip_forward

You might need to change eth0 and eth1 above, depends how your laptop is set up. If you think you may be doing this often, you can save the text below as a bash script and automate the above commands.

if [ "$(id -u)" != "0" ]; then
    echo ""
    echo "    Sorry, this script must be run as root."
    echo "    Try sudo $0 name_of_wireless_interface name_of_ethernet_interface"
    echo ""
if [ $# -ne "$ARGS" ]; then 
    echo ""
    echo "    This script sets up IP masquerading from your ethernet port to your wifi Internet connection."
    echo "    usage: $0 name_of_wireless_interface name_of_ethernet_interface"
    echo "    e.g. $0 wlan0 eth0"
    echo ""

/sbin/iptables --table nat --append POSTROUTING --out-interface $wifi -j MASQUERADE
/sbin/iptables --append FORWARD --in-interface $eth -j ACCEPT
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

Open an empty file with your favourite editor (vi, gedit, or similar), paste the above text into it and save the file as "". I chose to save mine in the /usr/local/bin directory. Make the file executable with

sudo chmod +x /usr/local/bin/

You will need to run this script as root.

If you get messed up this will reset the laptop:

# iptables --table nat --flush
# iptables --flush 
# iptables --delete-chain

4. On the MP01:

# route
# route del default
# route add default gateway

Now you should be able to ping IPs on the Internet from the MP01.

5. To get DNS working on your MP01 copy the "nameserver" line in /etc/resolve.conf on your laptop to /etc/resolve.conf on the MP01.

Connecting to an Asterisk Server from behind NAT

The Mesh Potato uses SIP to make phone calls (although IAX2 will be available in future).

If your Mesh Potato is behind a a NAT firewall, there are a few tricks to make SIP work, in particular for the Mesh Potato to receive incoming calls.

By default you can usually make outgoing calls to an IP on the Internet, just dial the IP on the phone, e.g. 87*98*162*247* to call Elektra.

Here are the steps for a more secure approach that supports incoming and outgoing calls from behind NAT. Instructions are includes for the Asterisk server (which is assumed to have a public Internet IP), and the MP01 which is behind a NAT router.

Tip When using vi on the MP01 typing /[def will get your to the default section and G (capital g) will take you to end of a file. This saves a lot of PageDn.

1. On your Asterisk Server, note change "elektra" to a unique name for the SIP trunk connecting to your MP01:


i) In the [general section]

nat=yes                         ; Global NAT settings  (Affects all peers and users)

ii) At the end of sip.conf:



In the [default] section:

; some unique extension for Elektra, e.g. 100, 101, 102....
; this dials extension 4000 on the SIP trunk "elektra",
; extension 4000 is the FXS port on the Mesh Potato
exten => 101,1,Dial(SIP/elektra/4000)

2. On your MP01, note change "elektra" to a unique name for the SIP trunk connecting to your MP01.


i) At the end of [general] section:

register = elektra@elektra/elektra

ii) At the end of sip.conf:



At the start of the [default] section:

; To dial extension XXX (three digit number) on the server dial 1XXX
; on Elektra's MP.  This sends the number XXX on SIP trunk "elektra"
; For example dialling 1100 would dial 100 in the default context of the
; Asterisk server.

exten => _1XXX,1,Dial(SIP/elektra/${EXTEN:1})

3. Then on your Asterisk Server:

$ asterisk -r
CLI> sip reload
CLI> dialplan reload

4. Then on the MP01:

$ asterisk -r
CLI> sip reload
CLI> dialplan reload

5. To check/debug:

CLI> sip show registry
CLI> sip show peers
CLI> show dialplan default
CLI> set verbose 5

If all is well at the MP01 should register with the Asterisk Server, and (with the appropriate dialplan on the Asterisk Server) you should be able to place calls to the MP01.

Connect your computer / laptop to the mesh via the LAN port of a MP

You have to set up a subnet on the LAN port of the MP that is not For example Note this subnetwork address must be unique in the whole mesh network!

MP configuration

Configure the MPs LAN port to use these settings: netmask

You can do that with LUCI. Note this will replace the setting.

Connect to the CLI interface of the MP with ssh. Open /etc/config/batmand with vi.

 vi /etc/config/batmand 

Edit the line "option announce":

 option announce 

Restart batmand:

 /etc/init.d/batmand restart 

Laptop configuration

Add the IP to your laptops LAN port. You should probably do that with the GUI network manager application.

Add a route via the LAN IP of the MP into the mesh. I'm assuming that you are using the default WLAN IP subnet range that the MPs are shipped with (

I don't know how to do that with a graphic network manager (it is the first thing I remove on my machines, so I am clueless how to use them.)

On the CLI it would work this way:

 ip r add via dev eth0 

Now any MP should be able to connect to your laptop and your laptop should be able to ping all WLAN IPs of the MPs.

Laptop system requirements to connect to a wireless mesh

Using your laptops WiFi card

This can be tricky, but I'm sure you'll find it rewarding. You can connect to all MPs in the mesh from your laptop as long as you have a wireless link to at least one MP in the mesh. If you are going to administrate a VT mesh this is surely a must-have. If you dislike or are unfamiliar with Linux there is bad news: You need Linux on your laptop to do this. I'd like to recommend Ubuntu 9.10 or Kubuntu 9.10. Alternatively you can configure a mesh router (a MP, for example) and use it is a mesh gateway that you connect to the LAN port of the laptop.

In order to connect to the mesh you need to set up the WiFi interface of your workstation/laptop and install/start the B.A.T.M.A.N. routing protocol.

If you are using Ubuntu or a recent version of Debian (tested with 9.10 Karmic Koala) you can install B.A.T.M.A.N. from the package repository using the synaptic (or any other) package manager. Just install the "batman" package.

CLI example:

 sudo apt-get install batman 

If your Linux distribution doesn't ship with B.A.T.M.A.N., get it from

Sources and precompiled binaries are available.

Now configure your laptops WiFi interface. The tricky part is the fact that we need ad-hoc mode for mesh networking. Not all wireless cards / drivers support ad-hoc mode properly, but the number is steadily growing. You need a recent Linux kernel > 2.6.30.

Supported wireless chipsets:

Atheros-based PCI/PCI-Express/Cardbus 802.11bg/802.11abg/802.11ab/802.11abgn 
Atheros AR9170USB (Linux >2.6.32)
Ralink RT73 USB
Zydas ZD1211rw USB (now rebranded as Atheros AR5007UG)
(This list is incomplete!)

Connecting to the MP via WiFi

By default the MP WiFi is configured to operate in ad-hoc (WiFi peer-to-peer) mesh mode. The factory settings are:

ESSID: "potato" 
Channel: 1

Assuming your laptop is ready to join a mesh network perform the following steps in a terminal (as sysadmin root). I'm assuming your WiFi card is wlan0 and that the IP is free, this might be different on your side. You can list the Wifi interfaces by performing iwconfig on the CLI. Just copy and paste the following lines into a text file using a programmers editor (joe, nano, kate, vi...) and save it as /usr/local/sbin/mesh.


# We don't want NetworkManager to mess with our settings.
killall NetworkManager
killall NetworkManagerDispatcher

# Kill previous instances of batmand
killall batmand

ifconfig $INTERFACE down
iwconfig $INTERFACE mode ad-hoc
ifconfig $INTERFACE up
ifconfig $INTERFACE
iwconfig $INTERFACE essid potato
iwconfig $INTERFACE channel 1
iwconfig $INTERFACE ap 01:CA:FF:EE:BA:BE
batmand $INTERFACE

Finally make the script executable:

sudo chmod 711 /usr/local/sbin/mesh

Now joining the mesh is a piece of cake:

 sudo mesh wlan0 

Monitor your connectivity to the mesh:

 sudo batmand -cd1 

Connecting the MP to the Internet via Ethernet port

If you are connected to the MP via Wifi

Connect the MP01 Ethernet port to the LAN.

Telnet (if you haven't set a password already) or SSH into the MP.


telnet <MP-WiFi-IP-address>


ssh root@<MP-WiFi-IP-address>


udhcpc -i eth0

The MP should receive a DHCP lease. This includes IP setting, route and DNS server setting.

If you are connected to the MP via Ethernet connection

Configure the Ethernet device of your laptop/workstation to use IP netmask (Fallback IP settings)

Telnet (if you haven't set a password already) or SSH into the MP.




 ssh root@ 


 udhcpc -i eth0 

Note: Using DHCP will change the default Ethernet (eth0) IP of the MP. If you are connected to the MP via LAN using the MP default IP you will be disconnected. (It may be hard to find out which DHCP IP address is now assigned to the MP Ethernet port.) Using the Fallback-IP you should be able to get in at any time. (As long as you don't disable the Ethernet port..)

Connecting the MP to the Internet via a Computer connected to a Wireless AP

Connect to the MP using the LAN port.


You can check this by sending ICMP messages to a well known server i.e.:


Setting up a SuperNode with an Ubiquiti NS2


While we proposed 3 Nanostation IIs as the super-node initially, let's assume a single Nanostation to start with. The Nanostation is the gateway node for the mesh and will also run the batman visualisation server that Afrimesh will draw info from.

Flashing the Nanostation

Antoine pointed out a fabulous tool from OpenMesh which makes flashing a whole lot easier, as least for Ubiquiti, OpenMesh, and some EnGenius routers. You can find the linux version at:

Antoine has some ready-made images for the Nanostation II at:

(current as of 18 Mar 2010, worth checking for updates)

which you can flash with open-mesh-flash [4]

$ sudo ./open-mesh-flash eth0 openwrt-atheros-ubnt2-squashfs.bin openwrt-atheros-Linux.lzma

The default IP is Use telnet (no password) until you set the root password via the GUI or the command line:

$ telnet
root@OpenWrt:~# passwd

After you set the root password telnet will be disabled and ssh enabled:

$ ssh root@

Gateway Mesh Node (NS2) Config

Check /etc/config/network to make sure it has the following settings:

option 'ipaddr' ''
option 'gateway' ''
option 'dns''

Laptop/PC Config

Assuming you are plugging in your nanosation via ethernet to a laptop/pc and your WiFi connection is your upstream Internet connection, run the following comands to set up networking:

$ echo 1 > /proc/sys/net/ipv4/ip_forward
$ ifconfig $eth
$ iptables -t nat -I POSTROUTING -o $wifi -j MASQUERADE
$ route add -net gw

Where $eth and $wifi are your ethernet and wifi devices respectively e.g. eth0 and wlan0

Configuring your Mesh Potatoes

MPs should almost work out of the box but we had to make some changes.

I'm not sure whether these are on the default firmware or something I

managed to screw up myself. Either way, you should make sure that

1) you need to make sure that the files in the /etc/config directory are writable:

$ chmod 0666 /etc/config/*

2) in /etc/config/batmand make sure that batmand.routing_class is set to '1' or '2'

3) finally point the visualisation server to the NS2 e.g.

batmand.visualisation_srv ''

In my case, this still didn't work until I deleted a default route on my laptop.

Setting up Afrimesh

Install Afrimesh on your laptop/PC by following the instructions at:

Once installed, point your browser at http://localhost and if memory serves, the Afrimesh server should come up by default, unless you are already running httpd services.

In settings page:

set visualisation server to set Internet gateway to

That should be it, you should have an NS2 as your mesh gateway and you should be able to visualise the mesh via the Afrimesh software.

Testing Afrimesh Version .954

Afrimesh Server Setup

This installation assumes that you have installed Ubuntu 10.04 (Lucid Lynx) on your server and have since updated and upgraded your packages. It also assumes you have a wireless driver that works in ad-hoc mode.

This has been testing on an Asus EeePC 1005P using Ubuntu 10.04 Netbook Re-mix

1) Add the Afrimesh repository

   sudo apt-add-repository ppa:antoine-7degrees/ppa
   sudo apt-get update

2) Install supporting packages

  sudo apt-get install batmand polipo villagetelco-dashboard

3) Install the batman visualisation server

   sudo mv vis-i386-lucid /usr/local/sbin/

6) Configure pmacct

Edit /etc/pmacctd/pmacctd.conf to reflect the following:

    !aggregate: src_host,dst_host
    aggregate: dst_host,dst_mac
    !pcap_filter: net
    pcap_filter: net
    interface: wlan0   # eth0 on VM

Restart pmacct

 service pmacct restart

6) Configure snmpd

Edit /etc/default/snmpd to reflect the following:

    SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/'
    #com2sec paranoid	default	public
    com2sec readonly	default	public

Restart snmpd

  sudo /etc/init.d/snmpd restart

Test with:

   snmpwalk -v 2c -c public .

7) Configure rsyslogd Edit /etc/default/rsyslog to reflect the following:


Restart rsyslogd

 sudo service rsyslog restart

Afrimesh Mesh Potato Setup

Get the Afrimesh packages for the Mesh Potato


If you haven't already set the passwd on the Mesh Potato, do that now by telneting to and issuing the passwd command. This will enable ssh and you will be able to continue with the following.

Copy the packages to the Mesh Potato.

   scp *ipk root@

Login into the Mesh Potato

   ssh root@

Install and configure the packages

   opkg install netcat_0.7.1-1_mips.ipk
   opkg install villagetelco-device_1.0pre-r954-1_mips.ipk

(Answer 'Y' when asked to replace /etc/config/afrimesh)

   /etc/init.d/provision enable
   chmod -R a+rw /etc/config
   uci set batmand.general.routing_class=3
   uci set batmand.general.visualisation_srv=
   uci set system.@system[1].log_ip=
   uci commit

Start up the Afrimesh Dashboard

You may be able to make this all work with the Network Manager but I ran into problems and disabled it. So, first kill the network-manager and stop any versions of batmand that might be running. You may wish to paste the below into a script for convenience. The commands should be run as root.

   stop network-manager
   killall NetworkManager
   killall NetworkManagerDispatcher
   killall batmand

Then start your wireless interface. Replace wlan0 if necessary with whatever your wireless device. You can also adjust the WiFi channel although don't forget to update this on the Mesh Potatoes as well.

   ifconfig wlan0 down
   iwconfig wlan0 mode ad-hoc
   ifconfig wlan0 up
   ifconfig wlan0
   iwconfig wlan0 essid potato
   iwconfig wlan0 channel 1
   iwconfig wlan0 ap 01:CA:FF:EE:BA:BE

Assuming your wired ethernet port is connected, you can set up that connectivity as well. If you ethernet port is not eth0, adjust as appropriate.

   ifconfig eth0 up
   dhclient eth0
   iptables --flush
   iptables --table nat --flush
   iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE  
   iptables --append FORWARD --in-interface wlan0 -j ACCEPT
   echo 1 > /proc/sys/net/ipv4/ip_forward

Now start the visualisation server. Initially, it is worth doing this in a separate terminal window so that you can monitor the server. Substitute your wireless device if not wlan0.

   /usr/local/sbin/vis-i386-lucid -d1 -j wlan0

Finally start the batman server. Once again, substitute your wireless device if not wlan0.

   batmand -d1 -s -g 100mbit wlan0

You're now ready to test Afrimesh. Launch Firefox and point your browser at http://localhost/afrimesh

Note: Before plugging in any Mesh Potatoes, don't forget to go to the settings page and set the longitude and latitude for your location.

Now you can plug in your Mesh Potato and wait for the bouncing blue ball to appear and the Mesh Potato's phone to ring. You can watch a demo of it in action at

If you want to clear Afrimesh's database and start again, execute the following:

   redis-cli flushdb

Finally, you may wish to setup a proxy with Polipo in Firefox to get better performance where connectivity is variable in quality. To enable Polipo, go to Edit|Preferences, click on the Advanced tab and then the Network tab below it. Then click on settings next to Connection. In the window that opens up click on Manual Proxy configuration and enter 'localhost' in the HTTP proxy field and '8123' in the port field.