Strange Receive Errors...

Hi,

I thought I had everything up and running, seamlessly, but a recent look at my logs showed an incredibly high receive error rate on my 802.11g SSID on an AP connected (ethernet) to a wireless router.

Breakdown is the following: Wireless Router/AP (DI-764), putting both

802.11a and 802.11b SSID 's. The log files for this router/AP, show those two SSID's being exceptionally clean -- very low frame errors (transmit/receive "success" is logged as 100%). Connected to the router/AP, by straight-through CAT5, is a second AP (DWL-7100). Its connected by LAN port out on Router/AP to WAN port in on second AP. This AP is putting out two SSID's as well, one is 802.11a and the other is 802.11g. Log files for this AP show the 802.11a to be exceptionally clean, however the 802.11g SSID is showing a very large number of steadily increasing receive errors such as "Received Frame FCS Error Count", "Ack Receive Failure Count", and "RTS Failure Count". I'm by no means an expert on this 802.11 stuff and haven't been able to locate clear documentation, but I'm assuming what is going on here is that it is logging received packets that are failing checksums, can't be acknowledged and AKD'd back to sender, etc.

Naturally, the first thing I thought was that perhaps the 802.11b SSID from the wireless router/AP was interfering with the 802.11g SSID. I tried using channels as far apart as possible to see the effects. I put the 802.11b SSID on channel 1 and the 802.11g SSID on channel 11. Thinking it would even further block packets from non-intended sources to get in, I even ensured that the 802.11b and 802.11g SSID's were using different crypto keys. I even went further by enabling MAC filtering on the 802.11g, to only allow my intended source to communicate with it. This seemed to help quite a bit (receive errors were cut down to about a 1/4 of what they were previously), but they still are steadily cropping up. This AP isn't on or near any RF generating appliance.

Next, I disabled everything in my network that is putting out 802.11b -- including the wireless router/AP's 802.11b. The only 2.4 Ghz going into the air at this point should be this 802.11g SSID. (I even unplugged a cordless phone!) This is when things got interesting. Its still receiving frames! I went through every channel, 1 to 11, and while some seem "cleaner" than others, they all still are getting frames -- from somewhere. Channel 6 seemed to be exceptionally "dirty". Ok. Perhaps something outside is going on here? So, I bring my laptop (and a PDA) to where this AP is located and do a scan. Sure enough, I find other 2.4 Ghz (neighbors') SSIDs in the air -- with varying strength between 7 to 18 percent. (Wish my software gave RSL's in dbm, and not percentages.) Could these types of errors (Receive Frame FCS Error, Ack Receive Failure, RTS Failure) be indicative of this AP receiving these outside SSIDs? One of these outside SSIDs in WEP encrypted, while the other is not. I believe that both of these outside SSIDs are using 802.11g (SuperG), which if I understand correctly utilizes all channels -- 1 through 11, but has a center frequency at channel 6. This would explain why I would see receive errors on all channels to some degree, but more so on channel 6, I'm assuming. (?)

Another strange thing, but also seems to go along with these errors coming from outside interference, is that the error rates seem to dramatically drop when I have actual traffic from my network passing through this 802.11g SSID. As of right now, I'm only using this 802.11g SSID with a wireless-ethernet bridge in order to give connectivity to a game console in another part of the house. The wireless-ethernet bridge is an 802.11b device, but is working beatifully with the 802.11g SSID. The log files for the bridge show an exceptional transmit/receive rate with the 802.11g SSID. (All transmit and receive errors have literally strayed at zero, even though the total number of transmitted and received frames is quite large.) I've monitored the 802.11g AP while actual traffic was passing through and the receive "success" percentage jumps up into the 90+ percentage. It still receives the "bad frames", but at lesser degree. Its only when there is no traffic (or even a signal, from my stuff anyway) that these receive error rates incrementally climb. If left un-attended for 24 hours, with nothing from my network coming in, the number of these frame errors will climb to

100,000+!

Is this in line with what you may expect from an AP attempting to receive other people's SSID's, with strength of 7 to 18 percent? (It may even jump higher than 18 percent, I only monitored it for about 10 minutes.) If so, I will rule out that the AP has a hardware problem. It was recently purchased and exchanging it would be no problem, but I'm wondering if the receive errors are from these outside SSIDs. If it is just outside interference, I won't worry about it and simply just choose a channel far away from these two outside SSID's (both of which are channel 6, however I do believe both are SuperG - so they possibly are using all the channels.) As for 802.11a, both my wireless router/AP and second AP's 802.11a SSID's are clean as a whistle -- which also seems to re-enforce my belief that the second AP doesn't have any hardware problems. I'm assuming if it did have a hardware problem, I'd probably be seeing a lot of receive errors on the 802.11a SSID in addition to the 802.11g SSID.

Thanks! (Still learning this 802.11 stuff, but having fun doing so.) :^)

Reply to
Eras
Loading thread data ...

After moving my "repeater" (same model as this AP, but in "Repeater Mode") to the location that the AP is at and checking it's performance (in "AP Mode") , I've concluded that it is indeed a hardware problem. The other "AP" (same model) is holding clean 802.11a and 802.11g connections -- without losing a single frame. It ran for four hours with only two FCS mismatches (which took place when first bringing it up), despite the outside SSID's which are still visable. I'm left to believe that the frame errors with the AP in question are due to an internal hardware problem. I would expect cyclic redundency checks to error out much more often with frames flying through the air (due to EMI) over a hard wired connection, but the FCS errors this AP was experiencing was well beyond acceptable tolerance. (I.e., 10,000 re-transmits requests an hour?) The second AP, which is running rock solid, is using the same exact configuration as the problem AP. (In fact, I just loaded it's configuration straight into it.) Its definetly not a configuration problem (frame alignment, mode, crypto, etc), but hardware. It'll be returned for a replacement...

Reply to
Eras

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.