Can our wifi network be knocked out or blocked from outside?

"ChrisPC" hath wroth:

So far, you've done everything correctly.

Probably V5 or V6. These are marginal dogs even with the latest firmware. However, the usual symptoms (hangs and disconnects) do not match your description.

That would have been my first suggestion. Did you try moving the router to a different RF channel? Channel 1,

6, and 11.

Probably WG614 or WGR614.

Hmmmm... I smell some hacking.

Oh yes. It's very easy. My guess is that you have a fake AP problem. Someone has setup a router with the same SSID as what you're using. The problem is that they do not need to know your WPA key in order to disrupt the system. The clients will connect (err... associate) with either access point, and attempt to negotiate the shared WPA key. Some will work, some will fail depending on which AP they connect.

The problem then moves to the client end, where the client software is suppose to be smart about finding the "correct" access point. They're not. They stay with whichever MAC address they find first. Most client software does NOT allow selection of access point by MAC address, only by SSID. So, the "view available networks" and such only show the SSID and not the MAC address. I suggest you try an active sniffer such as Netstumbler, Wi-Fi Hopper, or Kismet, which will show MAC addresses with identical SSID's.

Don't assume that the evil competition is doing this to you. There is also software that simulates an access point on a client computer. Also, look around at the local laptops for "hostAP" and possibly Microsoft's "Virtual WiFI" and such.

There are other ways of disrupting a network, but I don't want to unload my laundry list of dirty tricks.

Yes. Your best bet is to use Kismet under Linux for passive sniffing. Use a LiveCD such as: |

| sure you have supported hardware: | Kismet from the CD and see what's happening. If you find multiple access points with your SSID, there's the probable culprit.

Another way it to enable debug trace and logging in Windoze WZC. |

| | (maybe) There's a page (on MSDN??) with the interpretations of the various error codes and gibberish generated, but I couldn't find it. The log file will show the reason for the disconnects, reconnect attempts, and probably offer some clues.

I'm not sure of the exact mechanism. It's really a client issue. For example, Windoze WZC acts quite differently than Intel Proset and the various wireless managers supplied by IBM, Toshiba, Dlink and Linksys. Proset is amazingly smart about find the "right" access point. WZC is amazingly stupid.

I probably should have asked which party you were supporting.

Yes.

Not easily, but you could use Kismet (a linux program) to do some network snooping. You could walk around with a laptop running kismet and try to narrow down where the offending device is located.

Try using an SSID that's something other than the default or an obvious name. As in, not the candidate's name. Pick something completely unrelated. And try different channels. There may be some other 2.4ghz devices (like cordless phones) that are causing interference. Not much you can do about.

Technically you can cover the walls with an RF blocking paint. And window tinting that does the same. But it's doubtful you'd get that done in time (or within budget).

Bill and Jeff, thank you very much for your suggestions! I'll try Kismet or Netstumbler next time I'm at the office. BTW, their office was "skunked" last night (the night before the election). Somehow somebody sprayed essence d'skunk inside their office--I'm guessing via a crack under a door. The did the same to the car of a campaign worker.

I tried changing the channel too (from 1 to 11, I think), but that didn't fix the problem.

To be more exact (if my memory is working), these are the things I tried....

1. Changed the SSID to just a number, but let it broadcast for a while,

10 minutes at the most. I then disabled broadcasting of the SSID, and everything worked great for about 20 minutes, when the original problems returned. I was using the same exact WPA-PSK settings.

1. Because the problems were appearing regardless of which router I used, I swapped the Netgear out and the Linksys back in, changed the SSID again (never broadcast the signal), used the same WPA-PSK settings, but still consistently had that problem.
2. I swapped the routers again (back to Netgear), but this time I configured it with a new, numeric SSID and used 128-bit WEP encryption instead of WPA-PSK, and that worked OK and is working still (despite the skunk smell).

So, I now have two theories:

A. The method used to block our wifi required knowledge of either the SSID or the access point's MAC address. Only in step #3 did I change both.

B. The mechanism of this attack is related to WPA. Maybe it interferes with the key-exchange process. The would explain why people were able to connect for a while, then lost connectivity.

If I learn more I'll post it here. Thanks again!

Man, thats freaky...I was about to say the exact same thing after reading all of the previous posts...damn, and I was looking forward to giving advice.

Chris, follow this guys directions, you will seriously catch this hacker if you do ti correctly. Its old fashoined but it will work, espically with the wifi-meter on 'Net Stumbler'.