ReBooting

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
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.
> 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
Category:Mesh