back to


We had same problem in one end of our mesh, try to set Transmit Power 
to AUTO on all your nodes, it solved the problem for us: iwconfig wlan0 txpower auto
To much signal is not the solution. After this I found that some nodes 
only needed -2 to +2 db outputpower (from the cards) to maintain a 11 Mbit 
link over 1 km!!

I'm getting the same thing.  I have 5 nodes that dog leg around 18 
apartment buildings.  The reflection from these building I though we giving me 
some weird reading.  For example:

Unit "D" can mesh with unit "A" but between them is 16 floors and 
concrete and metal.  Basically no way no how the signal is going to penetrate 
that building but because of the other building in the area the signal is
bouncing around.  Meshap reports that he can talk with the unit 
directly because of the signal strength but what it is getting is true noise.  I
change the network to "blocknode" these signal in order for them to 
properly " dog leg" around the build.

When "blocknode" is working ReporTer indicates that Unit "D" can see unit "A" via unit "C"

Then what happens is Meshap does an automatic unblock node (even when 
WiaNa setting is set to disable) I assume it is call BroadUnblock then all of 
a sudden the node start see the noisy environment and I start to loose 
units "A" and "C"

I can ping them ok and I can ssh into them.  Remotemanagement fails and
people connected to these Meshap loose connectivity.  I too am using dev 88

Too resolve the problem I reboot the Gateway nodes everyday.  That 
seems to resolve the problem temporarily.

Next I start getting a Broadcast Storm.  I'm not sure if this related 
the outer nodes i.e. "A" and "C" start reporting Broadcast Storm.

I have been battling the network for weeks now.  I have add some 200mW 
to increase sensitivity of Gateway but this only increased the problem.

I'm not sure if the software is buggy or the operators is nuts.  I wish 
had a bench mark or better understand of what how blocknode actually 
and if it is really working.  

I noticed that to use the "walled garden" you have to use dev 88.  

What I will try to do is first reduce power on the 200 mW cards
Second if that doesn't work I will try to add blocknode in crontab 
every 10
minutes to stop the direct connections of the two nodes.
Third If that doesn't work I will try to do the reversal and set Wiana 
unblock nodes every 10 minutes again.
Hopefully these combination may give me so clue to your and my 

Yes I can ssh into the node.. remember the node is not unreadable the 
172.16 tunnel is. That is what is so strange.    uses a tunnel called is reachable and I can login and all is fine.. but the tunnel that everyone uses for internet access is not
reachable  Then a few minutes or seconds later it is reachable. This cause all downloads to stop and restart which kills many internet sessions. If both the mesh IP and the tunnel IP were unreachable, I would  understand,  but when you get great ping times to the mesh ppoint and get unreachable on the tunnel, it make me think something is happening to the tunnels.
All nodes are running dev88

Ken  can you ssh into the unreachable nodes?  Sound like a stupid  question out what dev are you using?

Help please.. I need to understand why or how this is happening.. 

These 2 tunnels report unreachable is unreachable is unreachable       
 but the mesh point itself responds fine. is alive (11.8 ms)------- is unreachable is alive (14.9 ms)------- is unreachable   

I have the gateway 'locked' to the proper gateway and I have blocked 
other routes, so there is no other way to get out.
I was beginning to think this was a wifi problem unitl I noticed that a 
further downstream is responding.. abit slow.. and  its mesh ping time 
also fine. is alive (14.2 ms)----- is alive (698 ms)

There is no relation to the amount of traffic that is one the network. 
problem happens at 6am and 1am at 12noon at 6pm..  I monitor the 
traffic at
the gateway through a mikrotik router so I can watch all traffic.. and 
is not a lot of traffic

When I look at the node they all seem fine.. they just don't respond. 
then they do.. but the mesh ip always seems to respond.
People are now calling asking why it is bouncing. is alive (0.34 ms) is alive (7.32 ms)---1st hop is alive (5.38 ms) is alive (14.2 ms)--- 3rd hop is alive (14.9 ms)- 3rd hop is alive (13.1 ms) is alive (11.8 ms)----2nd hop is alive (13.5 ms) is alive (698 ms) is unreachable is unreachable       


My nodes are dev88 and blocknode works flawlessly. But if the node in 
question has a signal level rather lower than the node you want to 
link with, then minsig works much better. I use both depends on the 
levels. Unneccessary links between nodes brings extra load and lowers 
speed in general. But, blocknode goes away with reboots so preference 
be minsig where applicable.

Routing issues causes some problems time to time but I did not have any 
major problem due to this yet.

Yeap it funny how a reboot fix a routing problem!
The problem that I am having which you feel is not related has been 
temporarily resolve.
First I reboot the Gateway node and it fix the problem - temporarily.
Then I get the following message:
Broadcast Message from root@meshbox
        (somewhere) at 15:24 ...
Unblocking 1.XXX.XXX.XXX

Broadcast Message from root@meshbox
        (somewhere) at 18:54 ...

Unblocking 1.XXX.XXX.XXX

Over and over and over again.  First Wiana is set so that Unblocknode 
disabled.  Next I issue every 10 minutes a blocknode for the same IP 
in Crontab i.e. crontab -e and use vi command to insert and save the 
crontab -l
11,41 * * * * /hj/remotemanagement >/dev/null 2>&1
#46 */8 * * * /hj/swman >/dev/null 2>&1
30 */4 * * * /bin/dmesg -c >/dev/null 2>&1
05 * * * * /hj/healthchecker >/dev/null 2>&1
*/10 * * * * /hj/lontt >/dev/null 2>&1
50 * * * * /hj/sdns >/tmp/work/sdns.wrk 2>&1
*/8 * * * * /hj/splashtest >/dev/null 2>&1
2,12,22,32,42,52 * * * * /hj/blocknode 1.XXX.XXX.XXX >/dev/null 2>&1
3,13,23,33,43,53 * * * * /hj/blocknode 1.YYY.XXX.XXX >/dev/null 2>&1

the two last entries are added to block nodes from the trouble gateway.

For the last 8 hours all my nodes have been checking.

I guess blocknode works but there is still something on the MeshAP that 
continues to unblock even when you disable the command in Wiana.

What in fact I have done is forced the route of the MeshAP through a 
path.  Pretty hard to explain "how to" but so far it works.

If anyone can give me an easier way to do this I will listen.


> Ok folks.. I think I *might* have fixed it.. time will tell..
> I really started think about routing.. and how nodes always are 
> themselves, and I someone mentioned rebooting the gateways every 
> So...
> Now the answer.....drum roll please
> I rebooted the far gateway that was not having any problems nor the 
> that it backhauls for.
> As soon as that was rebooted, all the problems on the other end of 
> network went away.
> So I guess the g/w node was putting out bad routes?

> >Aha.. check this out. When I looked at one of my nodes I notice
> 2 gateways
> >tunnels.. I don't think this is supposed to happen
> > reporter
> >br0       Link encap:Ethernet  HWaddr 00:02:6F:33:AD:5B
> >          inet addr:  Bcast:  
> >wlan0     IEEE 802.11b  ESSID:"SurfnetAP"  Nickname:""
> >          Mode:Master  Frequency:2.437GHz  Access Point:
> 00:02:6F:33:AD:5B
> >          Bit Rate:11Mb/s   Tx-Power=24 dBm   Sensitivity=2/3
> >          Retry min limit:8   RTS thr=250 B   Fragment thr=500 B
> >          Encryption key:off
> >          Power Management:off
> >          Link Quality:0  Signal level:0  Noise level:0
> >          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
> >          Tx excessive retries:1472708  Invalid misc:52581715   
> >beacon:0
> >
> >Connected to the network
> >          inet addr:  P-t-P:
> Mask:
> >          inet addr:  P-t-P:
> Mask:
> >         UG    0      0        
> >tun2
> >==>      42  DHCP clients
> >Mesh nodes detected
> >
> > 1 109 (100% @ 0)
> > 1 109 (100% @ 0)
> > 2 255
[[Category:Mesh cron]]