Mesh Potato HOWTOs

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 192.168.1.20, 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 192.168.1.20 will work until you set the root password via the GUI or the command line:

$ telnet 192.168.1.20 root@OpenWrt:~# passwd

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

$ ssh root@192.168.1.20 root@OpenWrt:~#

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

http://elektrad.info/download/MESH-POTATO/

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

http://elektrad.info/download/MESH-POTATO/VT-FIRMWARE-TESTING

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 192.168.1.2 interface on your laptop Ethernet, telnet/ssh into the MP01 on say 192.168.1.20. 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:


 * 1) iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
 * 2) iptables --append FORWARD --in-interface eth0 -j ACCEPT
 * 3) 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.

ARGS=2 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 "" exit fi 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 "" exit fi wifi=$1 eth=$2
 * 1) !/bin/bash

/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 "mp_masquerade.sh". I chose to save mine in the /usr/local/bin directory. Make the file executable with

sudo chmod +x /usr/local/bin/mp_masquerade.sh

You will need to run this script as root.

If you get messed up this will reset the laptop:


 * 1) iptables --table nat --flush
 * 2) iptables --flush
 * 3) iptables --delete-chain

4. On the MP01:


 * 1) route
 * 2) route del default
 * 3) route add default gateway 192.168.1.2

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:

sip.conf:

i) In the [general section]

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

ii) At the end of sip.conf:

[elektra] type=friend secret=your-password-here username=elektra context=default disallow=all qualify=yes dtmfmode=rfc2833 canreinvite=no host=dynamic allow=gsm,ulaw

extensions.conf

In the [default] section:

exten => 101,1,Dial(SIP/elektra/4000)
 * 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

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

sip.conf:

i) At the end of [general] section: register = elektra@elektra/elektra ii) At the end of sip.conf:

[elektra] host=asterisk.server.ip secret=same-password-as-server-above username=elektra fromuser=elektra insecure=port,invite type=friend disallow=all allow=gsm,ulaw,alaw dtmfmod=rfc2833 qualify=yes canreinvite=no nat=yes context=default

extensions.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 192.168.1.0/24. For example 10.10.10.0/24. Note this subnetwork address must be unique in the whole mesh network!

MP configuration
Configure the MPs LAN port to use these settings:

10.10.10.1 netmask 255.255.255.0

You can do that with LUCI. Note this will replace the 192.168.1.20 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        10.10.10.0/24

Restart batmand:

/etc/init.d/batmand restart

Laptop configuration
Add the IP 10.10.10.2/24 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 (10.130.1.0/24)

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 10.130.1.0/24 via 10.10.10.1 dev eth0

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

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.

On your PC configure the Ethernet port to use 172.31.255.253/30 (netmask 255.255.255.252). 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 172.31.255.253/30 sudo ifconfig eth0 up

Now you can access the MP @ 172.31.255.254

If you are using Ubuntu, it may be better to do it with the Ubuntu Networkmanager GUI. Networkmanager kept annoying me by deleting settings I made on the CLI after one or two minutes, so I got connection problems all the time. Not sure if it does the same to alias IP adresses, maybe they can coexist - please try and remove this note if it works for you. I'm not using Networkmanager, since it is not capable to do advanced things like setting WiFi IBSSIDs, which is necessary for mesh networking.

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 http://download.open-mesh.net

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 Intel IWLAGN 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 IBSSID: "01:CA:FF:EE:BA:BE" IP: 10.130.1.20 Broadcast: 10.130.1.255 Netmask:255.255.255.0

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 10.130.1.254 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.

INTERFACE=$@
 * 1) !/bin/sh

killall NetworkManager killall NetworkManagerDispatcher
 * 1) We don't want NetworkManager to mess with our settings.

killall batmand
 * 1) Kill previous instances of batmand

ifconfig $INTERFACE down iwconfig $INTERFACE mode ad-hoc ifconfig $INTERFACE up ifconfig $INTERFACE 10.130.1.254/24 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

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.

Perform:

"telnet "

or

"ssh root@"

Execute:

"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 172.31.255.253 netmask 255.255.255.252 (Fallback IP settings)

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

Perform: telnet 172.31.255.254

or

ssh root@172.31.255.254

Execute:

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 192.168.1.20 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.

tbc

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

"ping google.com"

Setting up a SuperNode with an Ubiquiti NS2
Assumptions -- 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:

http://download.villagetelco.org/ns2/open-mesh-flash

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

http://download.villagetelco.org/ns2/openwrt-atheros-vmlinux.lzma

http://download.villagetelco.org/ns2/openwrt-atheros-ubnt2-squashfs.bin

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

which you can flash with open-mesh-flash

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

The default IP is 192.168.10.20. Use telnet 192.168.10.20 (no password) until you set the root password via the GUI or the command line: $ telnet 192.168.10.20 root@OpenWrt:~# passwd After you set the root password telnet will be disabled and ssh enabled: $ ssh root@192.168.10.20 root@OpenWrt:~#

Gateway Mesh Node (NS2) Config --- Check /etc/config/network to make sure it has the following settings: option 'ipaddr' '192.168.10.20' option 'gateway' '192.168.10.1' option 'dns' 192.168.10.1'

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 192.168.10.1 $ iptables -t nat -I POSTROUTING -o $wifi -j MASQUERADE $ route add -net 10.130.1.0/24 gw 192.168.10.20 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 '10.130.1.1'

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:

http://code.google.com/p/afrimesh/wiki/Installation

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 10.130.1.1 set Internet gateway to 192.168.10.20

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.

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

wget http://download.villagetelco.org/vte/afrimesh/954/vis-i386-lucid 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 127.0.0.0/8 pcap_filter: net 10.130.1.0/24 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/snmpd.pid' /etc/snmp/snmpd.conf #com2sec paranoid	default	public com2sec readonly	default	public

Restart snmpd

sudo /etc/init.d/snmpd restart

Test with:

snmpwalk -v 2c -c public 10.130.1.1 .1.3.6.1.2.1.2.2.1.2

7)  Configure rsyslogd Edit /etc/default/rsyslog to reflect the following:  /etc/default/rsyslog    #RSYSLOGD_OPTIONS="-c4"    RSYSLOGD_OPTIONS="-c2 -r"

Restart rsyslogd

sudo service rsyslog restart

Afrimesh Mesh Potato Setup
Get the Afrimesh packages for the Mesh Potato

wget http://download.villagetelco.org/vte/afrimesh/954/netcat_0.7.1-1_mips.ipk wget http://download.villagetelco.org/vte/afrimesh/954/villagetelco-device_1.0pre-r954-1_mips.ipk

If you haven't already set the passwd on the Mesh Potato, do that now by telneting to 192.168.1.20 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@192.168.1.20:/root

Login into the Mesh Potato

ssh root@192.168.1.20

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=10.130.1.1 uci set system.@system[1].log_ip=10.130.1.1 uci commit reboot

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 10.130.1.1/24 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 10.130.1.1 -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 http://vimeo.com/14262841

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.

Try the OpenWrt failsafe mechanism first.
Note: The Reset port is not functional on the beta production MPs. So skip this section if you own a beta unit.

Install netcat (if it isn't installed in your workstation already)

Connect the workstations Ethernet port to the MP WAN/LAN port. Configure your workstations Ethernet port to use IP address 192.168.1.2 / netmask 255.255.255.0.

Open a terminal. Perform the following command:

nc -l -p 4919 -u

Power-cycle the MP. After a while you should see a message appear in the console:

Press reset now, to enter Failsafe!

Press the reset button immediately for about 2 seconds.

If all goes well you should see this message:

Entering Failsafe!

Now you should be able to connect to the web interface of the MP at 192.168.1.1.

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 192.168.1.185

RedBoot> ip_addr IP: 192.168.1.124/255.255.255.0, Gateway: 192.168.1.1 Default server: 192.168.1.180 RedBoot>

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 192.168.1.2-254 | grep "is up" ; done

Configure your workstation to use 192.168.1.1 IP, netmask 255.255.255.0.

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 192.168.1.20. 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.

Perform: 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: 192.168.1.1 Local IP address: 192.168.1.20 Local IP address mask: 255.255.255.0 Default server IP address: 192.168.1.1 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:. RedBoot>

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

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 into the /tftpboot directory.

Set up your workstation Ethernet interface to use 192.168.1.1

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 192.168.1.20) 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 192.168.1.20 (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: 

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:

batmand -cbd1

You should see the IP of the other MP(s) on your mesh. If you see no IPs 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@10.130.1.142") in new stack -- Called 4000@10.130.1.142 -- 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:~# batmand -d1 -c

2/ Ping gives an excellent indication of link quality.

(i) For example:

root@OpenWrt:~# ping 10.130.1.121 -c 10 PING 10.130.1.121 (10.130.1.121): 56 data bytes 64 bytes from 10.130.1.121: seq=0 ttl=64 time=6.907 ms 64 bytes from 10.130.1.121: seq=1 ttl=64 time=3.300 ms 64 bytes from 10.130.1.121: seq=2 ttl=64 time=3.578 ms 64 bytes from 10.130.1.121: seq=3 ttl=64 time=2.597 ms 64 bytes from 10.130.1.121: seq=4 ttl=64 time=3.356 ms 64 bytes from 10.130.1.121: seq=6 ttl=64 time=11.999 ms 64 bytes from 10.130.1.121: seq=7 ttl=64 time=10.328 ms 64 bytes from 10.130.1.121: seq=8 ttl=64 time=8.778 ms 64 bytes from 10.130.1.121: 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 10.130.1.121 -c 10 PING 10.130.1.121 (10.130.1.121): 56 data bytes 64 bytes from 10.130.1.121: seq=0 ttl=64 time=3.348 ms 64 bytes from 10.130.1.121: seq=1 ttl=64 time=4.632 ms 64 bytes from 10.130.1.121: seq=2 ttl=64 time=3.410 ms 64 bytes from 10.130.1.121: seq=3 ttl=64 time=4.206 ms 64 bytes from 10.130.1.121: seq=4 ttl=64 time=3.338 ms 64 bytes from 10.130.1.121: seq=5 ttl=64 time=3.570 ms 64 bytes from 10.130.1.121: seq=6 ttl=64 time=4.892 ms 64 bytes from 10.130.1.121: seq=7 ttl=64 time=4.838 ms 64 bytes from 10.130.1.121: seq=8 ttl=64 time=3.354 ms 64 bytes from 10.130.1.121: 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 10.130.1.121 -c 10 -s 1400 PING 10.130.1.121 (10.130.1.121): 1400 data bytes 1408 bytes from 10.130.1.121: seq=0 ttl=64 time=31.716 ms 1408 bytes from 10.130.1.121: seq=1 ttl=64 time=27.861 ms 1408 bytes from 10.130.1.121: seq=2 ttl=64 time=52.643 ms 1408 bytes from 10.130.1.121: seq=3 ttl=64 time=15.225 ms 1408 bytes from 10.130.1.121: seq=4 ttl=64 time=27.433 ms 1408 bytes from 10.130.1.121: seq=5 ttl=64 time=21.490 ms 1408 bytes from 10.130.1.121: seq=6 ttl=64 time=39.487 ms 1408 bytes from 10.130.1.121: seq=7 ttl=64 time=27.663 ms 1408 bytes from 10.130.1.121: seq=8 ttl=64 time=27.604 ms 1408 bytes from 10.130.1.121: 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 10.130.1.80 -c 100 -i 0.02 -q PING 10.130.1.80 (10.130.1.80) 56(84) bytes of data.

--- 10.130.1.80 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 10.130.1.80 -c 100 -i 0.1 -q -s 1400 PING 10.130.1.80 (10.130.1.80) 1400(1428) bytes of data.

--- 10.130.1.80 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 10.130.1.56 -c 100 -i 0.1 -q -s 1400 PING 10.130.1.56 (10.130.1.56) 1400(1428) bytes of data.

--- 10.130.1.56 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 ? (10.130.1.1) at 00:15:6d:a7:f2:a4 [ether] on ath0 ? (10.130.1.121) at 00:09:45:56:f6:b8 [ether] on ath0 root@OpenWrt:~# wlanconfig ath0 list ADDR              AID CHAN RATE RSSI  DBM  IDLE  TXSEQ  TXFRAG  RXSEQ  RXFRAG CAPS ACAPS ERP    STATE     MODE 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 10.130.1.121 (a node 500m away) has a received signal strength of -72dBm, and 10.130.1.1 (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.