Attempting to connect gateway.....

Understand your topology.

January 13, 2005

Since upgrading to Locustworld build 25 dev 88 from dev 83, I have been getting repeated messages of the gateway issue command to all repeater nodes.  Here is the kicker, I only have one gateway.  

I though it was a Wiana setting problem, you set up a prefer gateway or secondary gateway, etc.  It doesn't matter what the Wiana setting are, it still gives the same problem.  What actually happens is the network stops performing for that few seconds then it starts finding the new gateway again. The performance would be considered to be poor.

To illustrate the problem I "Ping" from the 4th hop to the gateway node.  I continue to get a root message that interrupts pings and stop network traffic as seen below:

64 bytes from 1.XXX.XXX.XXX: icmp_seq=26809 ttl=62 time=12.549 ms

Broadcast Message from root@meshbox
(somewhere) at 21:45 ...


Attempting to connect gateway 1.XXX.XXX.XXX


64 bytes from 1.XXX.XXX.XXX: icmp_seq=26810 ttl=62 time=18.269 ms
64 bytes from 1.XXX.XXX.XXX: icmp_seq=26811 ttl=62 time=12.614 ms

Broadcast Message from root@meshbox
(somewhere) at 21:45 ...


New gateway found at 172.XXX.XXX..1


64 bytes from 1.XXX.XXX.XXX: icmp_seq=26812 ttl=62 time=26.199 ms

With help of many people I found that the problems were neither software or hardware related, but more to the point of how my mesh was deployed. To illustrate this, lets examine the MeshAP that are having the problem and look at there relationship to other nodes. I will use my existing an older topology map to illustrate the problem of node setup.

O-39-Ridgemount is the Gateway Node.
E-123-713-La-Ro and O-63-Ridgemount are meshed in a triangle with the Gateway node (O-39-Ridgemount.) A meshed node is a MeshAP that has multiple paths to a gateway node.
S-105-0702-La-R is 2 hops from the gateway. It is not Mesh properly and it is known as a Dog Leg.  Dog Legs are defined as single node, that is not meshed, either from a gateway node or meshed node.
Likewise W-123-1620 La R and O-27-Newell 200 are "Linear route" and are 3 and 4 hops away from the Gateway node. Linear route can be define as two or more nodes that are linked off either a mesh node or gateway node and only have a single pathway to a mesh node or gateway.

Illustration below show the network topology.

attemp1.jpg (25854 bytes)

 

 

 

Dog Legs and Linear are not considered to be Meshed nodes but are considered to routed nodes. My assumption is Locustworld software can tolerate Dog Legs and Linear routes; however, up to a point. Determining the point is not a magic number like "3" hopes but more of how far the nodes are from the actually gateway and other meshed nodes.

As an example S-105-0702-La-R is a dog leg that is 2 hops from the gateway node but only 1 hop from a meshed node.  Currently this dog leg node show no sign of the "Attempting to connect to new gateway" message.  But it once did. 

S-105-0702-La-R node try to mesh itself with the gateway node; however, the location of this node is physically on the other side of a large building to the gateway node.  The signal was being reflect off another building. The reflection signal is as strong as it's closes neighbour.  As the MeshAP tried to connect  to the gateway it would stop and fail and revert back to the closest node.  This back and forth connection was creating problems.

The right solution to this problem was to setup a minimum signal for the node, in other words the node would only mesh with a stronger signal.  The problem occurred is both the reflected signal and the closet node had the same signal strength. The difference was that the noise or the gateway node had poor signal quality. Please note that all MeshAP do not have the same strength radio cards.  The gateway node has 200 mW radio card while the dog leg and the first hop node have regular 32mW radio card. This led to a more complex solution.

The complex solution was to: 

issue a blocknode of the gateway node at the dog leg node and 

also issue a blocknode of the dog leg node at the gateway node.

This create a new problem. In Wiana there is a setting to unblock nodes. It can be set from 10 minutes onward.  What happens is a the interval of time a unblocknode command is issued and everything that was blocked would release and process would again start up. 

To resolve the unblocknode problem a new blocknode Wiana setting was introduced to permanently block these nodes. This solution solve the unblocknode problem; however, the actual syntax of the setting is complex. similar the manual blocknode command, in Wiana, both nodes that required to be block must have each other's IP address.

This created the dog leg topology. The node is stable. The signal from the gateway node to the first mesh node then to the gateway node is clear and is noise free; however, as a result it is not self healing, in the event of a node failure, it is not meshed. 

In my Linear route I continue to have problems.  Similar to the dog leg node the Linear nodes developed as the dog leg due to the reflected and noisy signal problem.  What created an additional problem was that I added another node after the dog leg.  This create an additional problem known as Mesh RingMesh Ring is define as 4 or more linear nodes that start and end in either a gateway nodes or mesh nodes. They are actually meshed but create a circle route.

wpe5.jpg (31966 bytes)

As you can see from the above illustration O-27-Newell  node and the dog leg S-105-0702-La-R linked together and created a Mesh Ring. The problem of this new link is the effect of change of weather and season.  

When the leave fell and the weather is terrible this link appears.  It will disappear after a while then reappear again.  The problem escalated further when E-123-713-La-Ro started to mesh with O-27-Newell node. Again because of the different strength radio cards blocknode command in Wiana blocknode fixed the problem.

The performance actually improve with a Mesh Ring then after a while it started to become poor.  I issued a "sr" command to the gateway from the O-27-Newell node and the result was that ping would get to the gateway in one route then return in another.  In theory this should actually be good but in practice, using radio cards, it turn out to be poor. 

I would like to say that my nodes are being utilize 100% every minute but the sad part is most of nodes go idle.  As a result I sometimes have to send pings from the furthest node to keep nodes up.

As I writing I stop pinging from my 0-27-Newell node.  As soon as I get a some noise between nodes I start getting a "Searching for a gateway to use..."message in my console screen. This problem is one that annoys me to no end because I have only one gateway.  I see this mostly in linear route where the radio card is not direct line of site with the mesh nodes.  

To resolve this problem I tried to setup a directional antenna between the mesh node and the linear route.  It didn't work. I setup a mobile mesh using JB-Mesh and notice that the linear route turn into a mesh nodes and the "Attempting to connect to gateway.." only happen a few times after that. Then node stabilized.

What had happen was that the number of hopes was reduce to 2 rather than 4 and performance was excellent.  I illustrated the effect of adding two more node (blank ovals)  that reduce the problem of linear route. 

wpe7.jpg (24006 bytes)

When adding nodes it important to place them in a triangle as per mesh topology. Dog leg, Linear and Mesh Ring should be avoided.  

 

 
Send mail to webmaster@moskaluk.com with questions or comments about this web site.
Copyright ©  2004, 2005,2006, 2007, 2008, 2009, 2010  Moskaluk Inc.
Last modified: January 16, 2005