back to http://scratchpad.wikia.com/wiki/Sasecurity

{{{

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 
but
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 
cards
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 
we
had a bench mark or better understand of what how blocknode actually 
works
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 
to
unblock nodes every 10 minutes again.
Hopefully these combination may give me so clue to your and my 
problems.


Yes I can ssh into the node.. remember the node is not unreadable the 
172.16 tunnel is. That is what is so strange. 1.221.35.250    uses a tunnel called  172.16.244.2  1.221.35.250 is reachable and I can login and all is fine.. but 172.16.244.2 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
172.16.244.2 is unreachable
172.16.248.2 is unreachable       
 but the mesh point itself responds fine.
1.221.35.250 is alive (11.8 ms)------- 172.16.244.2 is unreachable
1.252.243.83 is alive (14.9 ms)------- 172.16.248.2 is unreachable   


I have the gateway 'locked' to the proper gateway and I have blocked 
the
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 
node
further downstream is responding.. abit slow.. and  its mesh ping time 
is
also fine.
1.76.85.159 is alive (14.2 ms)----- 172.16.137.2 is alive (698 ms)

There is no relation to the amount of traffic that is one the network. 
This
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 
there
is not a lot of traffic

When I look at the node they all seem fine.. they just don't respond. 
And
then they do.. but the mesh ip always seems to respond.
People are now calling asking why it is bouncing.

1.85.96.148 is alive (0.34 ms)
1.37.139.122 is alive (7.32 ms)---1st hop
10.203.199.39 is alive (5.38 ms)
1.76.85.159 is alive (14.2 ms)--- 3rd hop
1.252.243.83 is alive (14.9 ms)- 3rd hop
10.133.99.112 is alive (13.1 ms)
1.221.35.250 is alive (11.8 ms)----2nd hop
172.16.194.2 is alive (13.5 ms)
172.16.137.2 is alive (698 ms)
172.16.244.2 is unreachable
172.16.248.2 is unreachable       

Don,

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 
maintain 
link with, then minsig works much better. I use both depends on the 
signal 
levels. Unneccessary links between nodes brings extra load and lowers 
the 
speed in general. But, blocknode goes away with reboots so preference 
should 
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 
is 
disabled.  Next I issue every 10 minutes a blocknode for the same IP 
address 
in Crontab i.e. crontab -e and use vi command to insert and save the 
block 
node.
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 
certain 
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.

Thanks


> Ok folks.. I think I *might* have fixed it.. time will tell..
>
> I really started think about routing.. and how nodes always are 
announcing
> themselves, and I someone mentioned rebooting the gateways every 
night..
> So...
>
> Now the answer.....drum roll please
>
> I rebooted the far gateway that was not having any problems nor the 
nodes
> that it backhauls for.
>
> As soon as that was rebooted, all the problems on the other end of 
the
> 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
> >1.221.35.250@meshbox:~# reporter
> >br0       Link encap:Ethernet  HWaddr 00:02:6F:33:AD:5B
> >          inet addr:1.221.35.250  Bcast:1.255.255.255  
Mask:255.0.0.0
> >wlan0     IEEE 802.11b  ESSID:"SurfnetAP"  Nickname:"1.221.35.250"
> >          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   
Missed
> >beacon:0
> >
> >Connected to the network
> >          inet addr:172.16.244.2  P-t-P:172.16.244.1
> Mask:255.255.255.255
> >          inet addr:172.16.244.2  P-t-P:172.16.244.1
> Mask:255.255.255.255
> >0.0.0.0         172.16.244.1    0.0.0.0         UG    0      0        
0
> >tun2
> >==>      42  DHCP clients
> >Mesh nodes detected
> >
> >1.37.139.122 1.37.139.122 1 109 (100% @ 0)
> >10.128.38.148 1.37.139.122 1 109 (100% @ 0)
> >1.85.96.148 1.37.139.122 2 255
<pre>
}}}