USR WAP - Keeps dropping packets/Users lose connection

[Cat1]

i have two buildings 300m apart, connected via a 100mb laser link which is a solid constant connection.

I have a separate USR Wireless Access Point at Each office, and around 10 users connect at each side. The network is set up as one subnet/domain. Servers are Win2K/Clients WinXP.

At one side the WAP is configured to use channel 1/infrastructure mode/128bit open key encryption - this side is working like a dream.

At the other side the WAP is configured to use channel 6/infrastructure mode/128bit open key encryption - this side is being a pain - continuously dropping packets, and cards losing connecting to the WAP all the time.

I've run out of ideas what this could be. The office where the WAP is not working properly is a large open plan room where each user pretty much has direct line of sight to the WAP.

Any ideas? It's driving me nuts!

 

[bcastner]

disable 802.1x authentication on the clients

 

[Cat1]

I already have it disabled. Sometimes the USR utility is showing 100% signal but XP is still showing it as there being no signal & won't let some users connect or renew their dhcp address.

 

[bcastner]

Several things then:

1. For your XP clients, make sure you download and apply the "Wireless" rollup package. This is not pushed down to clients through Windows Update:

http://support.microsoft.com/?kbid=826942

2. Check the APs. To work reliably:

. SSIDs identical (many are case sensitive; e.g. workgroup and Workgroup are not identical);
. Different channels for each AP, never the same channel. For your second AP, use Channel 11 and not 6.
. Wireless Zero Configuration set so that:
. You do not connect to unsecure networks
. You only connect to Access Point (Infrastructure) networks
. You only connect to "Preferred" networks

Make sure then that there is only your AP SSID in the "Preferred Network" lower box under the Wireless Network Configuration.

. Do not disable SSID broadcast on the APs

Notes:

1. Make sure the client can use the XP Wireless Zero service:

http://support.microsoft.com/?kbid=826942

2. Do not disable SSID broadcast by the APs:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q811427

3. If your Bridge is using a PC as one end-point, make sure that the adapter can be and is set for promiscuous mode:

http://support.microsoft.com/default.aspx?scid=kb;en-us;302348

 

[tharder]

Since these are only 300m apart and are set up the same(except for the channel, why not just swap units and see if the trouble moves with the unit or stays with the location. You may be dealing with a faulty unit, or outside interferance. Have you tried doing a site survey at the trouble site looking for rouge AP's or users with bluetooth, cordless 2.4g phones, or other non-802.11 devices? Our lobby Cisco 1200 complains all the time about non-802.11 interferance that we can normally trace to a vendor or guest coming in the building with the above mentioned devices...

 

[Cat1]

Thanks loads for the help - both units are configured with different SSIDs/passwords - so the first thing i'm going to do is change one of them to the same as the working WAP.
We have (i forgot to mention) an 802.11b netgear WAP at the (working) office, which is set at channel 1, so i have set the working WAP to channel 11 (as we were having some problems with this this morning, but changing the channel fixed it), and the non-working one is still on channel 6.

One of the guys at the other office tied the USR WAP down to 11mbps (rather than 54mbps) and it is apparently slightly more stable, but still bombing out. Also users with 802.11b cards seem to have a perfect connection to the USR access point. It seems to be something with the USR 802.11g cards themselves?

With regard to rogue AP's, there is one in the next door suite to us (at the non-working office) totally unsecured and we've even been able to get access to their router configuration utility! They are set to channel 11 & there are probably more in the area that aren't announcing themselves (we are on a rather crammed industrial park).

With regard to Bluetooth etc how come this would cause such interference? We are a software company so all the developers have multitudes of bluetooth phones, palm pilots etc over at the other office....

 

[Cat1]

I've reset the non-working AP to use the same SSID/WEP key as the working AP. No change - the XP patch has been applied and made no difference. When pinging from a client laptop with a 802.11g card, the packets are being dropped all over the place. Two users using 802.11b cards are having a much better time though, and having a much more solid connection.
We've identified two bluetooth palmpilots in the office, but i don't think they're causing any problems as they've transmitted once today for about a minute to update calendars.
I don't think there's any wireless networks (apart from the one i mentioned previously which is on a different channel) in the near vecinity.

Help!!

PS: Products are- USR Wireless Turbo 802.11g Access Point (USR015450) & Wireless Turbo 802.11g PC Card (USR805410).

 

[bcastner]

Are you sure you are using:

. Same SSID
. Different Channels
. Lowest common denominator WEP key

Remove all WEP, 802.1x, and WPA keys from the second AP and all clients that normally associate.

I suspect you are using a 128-bit key on client adapters that can only take half that number.

 

[Cat1]

Do you mean i should turn down the encryption to 64bit on the WEP key?

I'm currently using the same 128bit WEP key, the same SSID & different channels for both 802.11g USR Access Points (which are identical). The 802.11g USR clients (all using the same identical cards) are therefore connecting using this SSID & 128bit encryption key.

Why should some clients be able to get a perfect ping response, and some clients get packets dropped and chucked around all over the place?

I don't think it's interference, as User A could be pinging & getting a solid 1ms response, but User B sitting next to him (with the same laptop, same XP build, same card) could be getting variable 2ms/300ms/4000ms/timeout ping responses.

i just don't geddit!