Noise and tunnels

I originally brought up the problem with "Searching for Gateways" over six months ago and wrote a brief article on it http://www.moskaluk.com/attempting_to_connect_gateway.htm

Since then the problem has appeared and reappeared and I'm not closer to the answer. Lately on the Locustworld mail list I posted the question and it getting better response then it did six months ago. It looks like I'm not the only one. The latest thinking about "Searching for Gateway" is a brief interruption due to radio overlap of another device. This cause the tunnels in wireless Mesh to stop communicating. After a while the tunnels reset themselves and everything goes back to normal.

The question is how do the tunnels establish themselves and is there away to force the issue?

I'm glad that many more people are on top of this problem. We many finally get resolution.

Cause and Effect

I remember the Matrix movie and there was a line about Cause and Effect. Nevertheless, I had a problem with one of MeshAP, it would link to the mesh and I was able to ping it but I was not able to SSH into the node. The client was complaining that he was not able to get in and was having problems.

I wasn't able to talk with the client directly but a reboot would have corrected the problem. I couldn't get the client to reboot nor was I able to physically go to the client Meshap. However, asking the Locustworld list for a solution gave me a number of different responses, of which none of them resolve the problem.

This morning I got up and it came to me that the problem may not be the Client's MeshAP but the Uplink Node. So I rebooted the uplink node and the clients node in question started to operate again. I notice that this sometimes happens with the intel boards. I use a Compaq computer for my uplink nodes and every few weeks they need a little reboot.

I instantly ssh into the MeshAP and did a remotemanagement and everything worked ok. I also noticed that some of the other Mesh nodes where now talking with each other. Rebooting the uplink node is sometimes more important that booting the MeshAP.

Beyond Wiana

Did ever want Wiana to be a local server? Yeah me too. Unfortunately I do not have the time to re-engineer the server. The next best thing is to create a server that you can run your MeshAP from. Locustworld's OS does not give you the ability to save your changes or customization to the MeshAP. What it does reset all the setting after a reboot and then configures them as per Wiana. In other words Wiana feed the configuration file into the MeshAP and the file is used to configure the MeshAP.

When you want to automate a task in the MeshAP like reboot everyday at a certain time the crontab does not give you the ability to save your setting after the reboot. It becomes a pain to constant add it back in manually.

The solution has always been to have a Linux server between the router of the uplink node and the uplink Mesh Node. This gives you the ability to control the and customize each MeshAP.

The Linux server can SSH into each one of the meshap and perform the same actions. As a result centralizing the automation becomes a true reality.

Susanna Dorr wrote a script to simply reboot the MeshAP's using the above method:

1. Get the mesh set up in the server routing table so the server can talk to every node.
For example, my subnet is 123.123.123.nnn, with my base node radio set with a static ip of 123.123.123.100.
So in my rc.local file, I have a routing table entry for each of my remote nodes -- e.g.,
route add -host 172.16.130.2 gw 123.123.123.100 [130 is the CELLIP of this node]
route add -host 172.16.160.2 gw 123.123.123.100 [160 is the CELLIP of this node]
etc.
2. Get /root/.ssh/authorized_keys and known_hosts set up on the server and the radios for passwordless authentication -- so that the server can ssh to the nodes without passwords. This is done the way you'd do it for any pair of linux boxes. I have mine set so that the server can passwordlessly ssh to each node, but not vice versa. In brief, this involves loading the server's public key into /etc/.ssh/authorized_keys on the radio. It also involves changing a setting in the radio's /etc/ssh/sshd_config file: this line must be uncommented and set to no -- StrictModes no.

3. Create a shell script to reboot each node from the outside of the mesh in. For example,
ssh root@172.16.130.2 reboot
ssh root@172.16.160.2 reboot
. . .
ssh root@123.123.123.100 reboot [ base node last ]

4. Call the shell script at whatever interval in the /etc/crontab file.

As you can see automation then becomes simple. I believe that anyone that wants to make a carrier grade meshap will need the additional equipment other than WIANA.

Mechanical reboot of MeshAP

One of the greatest things about open source is everyone has a solution. Recently a posted a question on a Locustworld's email list and received a number of great response.

I am having a problem with a few of my nodes. They tend to lock or have a kernel panic. A hard boot is required. I have been pushing for years to have reboot command placed in WIANA that would automatically reboot the node on a timed basis. A smart guy from Germany indicated to get a electronic or mechanical timer that would hard boot the system everyday. Now this will bring wear and tear on the power supply but the idea is actually pretty smart.

If you set up your mesh to have your signal overlap, then a reboot of any node will not stop the coverage of the signal. Since the design of the mesh network is intended to be fully redundant. Having nodes rebooting at intervals makes a lot of sense.

I know that most of my mesh is covered with at least two nodes covering every signal. I going to try it and verify this claim.

Links not being used

I keep my web site up for a number people to continue to learn how to use wireless mesh using locutworld open source. Unfortunately I have seen a dramatic decline.

Many of my articles can be seen at http://www.moskaluk.com/papers.htm

I hope these papers were informative.

Thanks you for your interest this year!