ReBooting
From Scratchpad
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
