SearchingGateway

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!