WiFi: 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:~#
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:
# 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.
#!/bin/bash
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
/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:
# iptables --table nat --flush # iptables --flush # iptables --delete-chain
4. On the MP01:
# route # route del default # 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:
; 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.
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 [1].
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.
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 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.
#!/bin/sh INTERFACE=$@ # 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 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
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.
Perform:
telnet <MP-WiFi-IP-address>
or
ssh root@<MP-WiFi-IP-address>
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 it at:
There is a version for Linux and for Windows.
Antoine has some ready-made images for the Nanostation II at:
http://downloads.afrimesh.org/stable.villagetelco/openwrt-atheros-vmlinux.lzma
http://downloads.afrimesh.org/stable.villagetelco/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
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.
Preliminary Mesh Potato firmware disaster recovery HOWTO
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!
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 [2] 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: [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:
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.