SearchingGateway

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
=== gateway to use ===
Yeah, yet again I am systematically rebooting each node and it does not 
seem
to help. I noticed with weather we received and the fact that 
everything
once again has frozen over. I'm getting reflections and links that I 
never
had before. I have setup a few block nodes and I've seen a marginal
improvement but anything that is two hops or more does not seem to be
connecting to the gateway. I get a message "attempting to connect" and 
no
connection is established.
I don't think this is a reflection problem or atmospheric problem. Two 
hops
out everything have stopped meshing.
The "Searching for a gateway to use" problem does not seem to go away,
as Don has found (below). I have been doing some testing involving 4 or
5 hops (depending on what the Mesh feels like) with a PuTTY window open
onto my local node. All too frequently the dreaded message appears and
perfectly good communication ceases for a minute or two. Usually a
connection to the same gateway (the preferred one) comes back.
It may be that something interrupts the tunnel being used, but the 
links
all seem good. If a bird wobbled an antenna (say) I would far rather a 
5
second outage than whatever it is that occurs.
One thought: Would it be possible to establish a "reserve" tunnel 
using
as different a route as possible and switch to it instantly if
necessary? There would need to be a background monitor process to keep
an eye on it.
Regards,
Richard Bowers - Rural-WEB
Don Moskaluk wrote under "Can ping but can't connect":
>I think something else is going on ........
>
>This first indication is "Searching for a gateway to use..." once I 
see
>this message I can't believe that after two years of operation I am 
again
>seeing this problem.
>
>The only way I can resolve the problem is to start pinging the gateway 
node
>form the nodes that are searching for gateways. Does anybody have 
another
>solution?
>
>
>
>Don Moskaluk ....snip.......
>
>
>
Ok once again my nodes are meshing. The exception is two of my 
strongest
nodes now do not want to talk with each other. Each one is meshing 
with
another node for now. Sigspy reporters to have two nodes that seem to 
be
running interference:
 44:44:44:44:44:44 : Quality:0/92 Signal level:-100 dBm Noise
level:-100 dBm
 00:04:E2:80:6D:94 : Quality:0/92 Signal level:-100 dBm Noise
level:-100 dBm
Can everyone check to see if they have seen this type MAC addresses on 
their
nodes? I bet you some one else has.
The two nodes have over 8 degrees of separation as reported by sigspy.
There is not reason why they shouldn't be meshing.
Today is just weird.
I am also getting the following symptoms from these nodes:
Clients connected to another node 1 and 2 hops in are getting really 
slow
connections and FTP's are failing 1/4 of the way into the download.
I checked almost everything from signal to routing tables and can't see 
the
problem.
It certainly seems to be a problem caused by the main node however 
there
have been no changes on that node for months.
Yeah, yet again I am systematically rebooting each node and it does not 
seem to help. I noticed with weather we received and the fact that 
everything once again has frozen over. I'm getting reflections and links that I 
never had before. I have setup a few block nodes and I've seen a marginal
improvement but anything that is two hops or more does not seem to be
connecting to the gateway. I get a message "attempting to connect" and 
no connection is established.
I don't think this is a reflection problem or atmospheric problem. Two 
hops out everything have stopped meshing.
The "Searching for a gateway to use" problem does not seem to go away,
as Don has found (below). I have been doing some testing involving 4 or
5 hops (depending on what the Mesh feels like) with a PuTTY window open
onto my local node. All too frequently the dreaded message appears and
perfectly good communication ceases for a minute or two. Usually a
connection to the same gateway (the preferred one) comes back.
It may be that something interrupts the tunnel being used, but the 
links
all seem good. If a bird wobbled an antenna (say) I would far rather a 
5
second outage than whatever it is that occurs.
One thought: Would it be possible to establish a "reserve" tunnel 
using
as different a route as possible and switch to it instantly if
necessary? There would need to be a background monitor process to keep
an eye on it.
>I think something else is going on ........
>
>This first indication is "Searching for a gateway to use..." once I 
see
>this message I can't believe that after two years of operation I am 
again
>seeing this problem.
>
>The only way I can resolve the problem is to start pinging the gateway 
node
>form the nodes that are searching for gateways. Does anybody have 
another
>solution?
I have a saying: "signal is everything".
I used to see this on a 3rd & 4th hop in one part of my network. I
went to that location and found that there were two Netgear routers on
the same freq. What happens is that when one of them would fire up and
start a download, it seemed to shut me down. Under normal
circumstances (basic web browsing) things worked OK. When they would
start transmitting a lot of data, my mesh would collapse. You could
still ping the remote node - the tunnel would fall apart.
OK, now - how to find this out on the cheap. First you have to have
some free time, and lots of patience. If you have Intel, get a
Knoppix-STD and use the Kismet program. If you have a Mac, get KisMac
and learn to use it. These programs will let you see not only the
other access points, but what channel they are on, and the number of
packets being sent by them and their clients.
Put your wireless card into "passive mode". This basically makes it
nothing more than a monitor, but the amount of data it gives you is
incredible. While in passive mode, you can not connect to your
network, so it helps to have another laptop logged on and pinging some
remote device.
Chaces are, when your tunnel collapses, you'll see a station sending
and receiving lots of packets at the same time. Your node can probably
ping other devices, but you're throughput will be terrible or
non-existant.
I have also found that improperly grounded (earthed) radios will
experience this problem - but that point was made last week.
The point of all of this is that software is going to do just what it
was designed to do. It should work right, or be buggy as hell. It is
not likely that it will work perfectly for a long time, then just go
crazy for no reason. There has to be something (else) doing it
external from the software. The primary place to look is RF.
Back to my network: I tried to work with the two parties that were
causing the problems, but they both refused to move their access
points off of channel 11 (where I was also operating). Therefore, I
re-mapped my network, installed a high-gain (parabolic dish) antenna
to link with a distant node, and moved the problem segment to channel
one. That cut one hop out as well and solved everything.
Also - as I previously stated, the new MIMO devices (pre-N) are
spectrum hogs, and I had another person email me offlist and state the
"Super-G" units have caused them headaches.
> Ok once again my nodes are meshing. The exception is two of my 
strongest
> nodes now do not want to talk with each other. Each one is meshing 
with
> another node for now. Sigspy reporters to have two nodes that seem 
to be
> running interference:
>
> 44:44:44:44:44:44 : Quality:0/92 Signal level:-100 dBm Noise
> level:-100 dBm
> 00:04:E2:80:6D:94 : Quality:0/92 Signal level:-100 dBm Noise
> level:-100 dBm
>
> Can everyone check to see if they have seen this type MAC addresses 
on their
> nodes? I bet you some one else has.
>
> The two nodes have over 8 degrees of separation as reported by 
sigspy.
> There is not reason why they shouldn't be meshing.
>
> Today is just weird.
>
> I am also getting the following symptoms from these nodes:
>
> Clients connected to another node 1 and 2 hops in are getting really 
slow
> connections and FTP's are failing 1/4 of the way into the download.
> I checked almost everything from signal to routing tables and can't 
see the
> problem.
>
> It certainly seems to be a problem caused by the main node however 
there
> have been no changes on that node for months.
>
> The "Searching for a gateway to use" problem does not seem to go 
away,
> as Don has found (below). I have been doing some testing involving 4 
or
> 5 hops (depending on what the Mesh feels like) with a PuTTY window 
open
> onto my local node. All too frequently the dreaded message appears 
and
> perfectly good communication ceases for a minute or two. Usually a
> connection to the same gateway (the preferred one) comes back.
>
> It may be that something interrupts the tunnel being used, but the 
links
> all seem good. If a bird wobbled an antenna (say) I would far rather 
a 5
> second outage than whatever it is that occurs.
>
> One thought: Would it be possible to establish a "reserve" tunnel 
using
> as different a route as possible and switch to it instantly if
> necessary? There would need to be a background monitor process to 
keep
> an eye on it.
> >I think something else is going on ........
> >
> >This first indication is "Searching for a gateway to use..." once I 
see
> >this message I can't believe that after two years of operation I am 
again
> >seeing this problem.
> >
> >The only way I can resolve the problem is to start pinging the 
gateway node
> >form the nodes that are searching for gateways. Does anybody have 
another
> >solution?
A fix for the unfriendly AP's in your region.
I would not recommend doing this for long periods of time as it also 
has
a negative effect on your own network.
Had a situation were some nice person was sitting very close to one of
our nodes and was causing some really strange problems, even to this 
day
im not sure what the exact problem was but after asking them several
times if they would mind changing channels to one of the other free 
ones
they refused and left me with no other choice.
I would have changed channel however to do so would be a real pain as 
we
have gone to great lengths to tune the coax runs, tune the antennas and
align / peak the antennas for optimal performance.
So....
NOTICE: I take no responsibility for any damage this may cause, and you
must keep in mind that intentional interference is against the law and
you could be prosecuted for it. I do not recommend you take the steps
and this information is being provided to you so as to enable you to
enhance your knowledge of wireless communications.
This will depend on what radio you are using and what drivers are being
used. 
iwpriv
will dump a list of internal commands and settings for the device you
are using.
Look for something like beacon_int
Not the one getbeacon_int
beacon_int will allow you to lower the beacon period of your network... 
default it is set to 100 meaning that every 100usec the AP broadcasts
stuff like the ESSID. Dropping this to a lower number like 5 can have a
really bad effect on devices on the same channel.
From memory the command below is how you set it, however don’t forget 
to
set it back to its default as even a reboot will not reset this 
setting.
"iwpriv beacon_int 5" 
Also we found another issue where a group of AP's in between one of our
links were killing packets on our network, after we investigated 
further
it turned out that some bright spark who set up the network dropped the
fragmentation way down. I think its set as auto on most mesh boxes but
if you set it to a low number like 128 say goodbuy to any performance 
of
the surrounding networks as the radio is going to be flooding out the
channel space especially if you force your radio to full power and rate
to 11mb
Kenny I was surprise on your comments on the Locustworld software. I'm 
not
sure what it is. That's why I am asking the list. If I suspected it 
was a
software related issue I would have asked Jon directly. No I think 
this is
something else. The signal strength is strong and the separation is as 
it
should be but the two nodes have stop communicating. Need to 
understand
why!