I have an Actiontec GT701 DSL router with 802.11b/g wireless (from Qwest) and use an IBM R51 laptop with an internal Intel 2200BG WiFi card. I have the latest firmware and drivers installed for both devices. I run WinXP Pro SP2 on the laptop, and use WPA security on the WiFi link.
Just recently, I've started seeing all sorts of errors at the TCP/IP level. Both Ethereal (a Windows packet trace utility) and a number of Websites running the Web100 network diagnostic tool
formatting link
show numerous instances of "packet out of order", "duplicate ACK" and "retransmission request", but only on the wireless link. My desktop machine, which is plugged directly into the single ethernet port on the GT701 shows no such errors.
Usually when I'm using the wireless connection, and specifically when I was testing this problem, I'm within 8 feet of the AP and can look right at it, so signal strength is very good. The Actiontec's admin Web pages show no errors.
I can replace either the GT701 or the 2200BG for $60, but before I start spending money, is there any reasonable way to determine what the actual problem is?
I don't have easy access to another WiFi network or I'd have tried that already :-)
All sorts? Could you be a bit more specific? Different types of errors have rather specific causes. Run in an MSDOS window: netstat -es | more and see if there are any errors that are a high percentage of packets sent or received. It's the TCP and UDP statistics at the bottom. Anything less than about 0.5% is considered excellent.
How numerous? As a percentage of traffic passed please. Web100 tweaks the hell out of the TCP/IP timing. It allegedly dynamically optimizes a server for traffic to given PC. It may NOT do a decent job of optimizing two or more connections to the same machine. Also, running the timing to the bitter edge of collision and overrun is not my idea of reliable operation. I guess anything is justified in the search for more performance, but methinks sacrificing reliability is not a great idea. Web100 settings may be stable on a wired connection, but wireless conditions tend to change. The question is how good is the dynamic optimization.
Well, let's take them one at a time. It's kinda difficult without real numbers but you can fill in the guesswork.
"Packet Otto Order" means that a series of packets arrived with one missing. The missing packet was later re-transmitted and of course arrive after earlier packets with earlier sequence numbers. TCP is quite good at re-assembling out of order packets. This should not affect thruput but is an indication that some packets are getting lost.
"Duplicate ACK" is the same thing as above, where the TCP acknowledgement packet was lost instead of the sent packet. The effect is the same as the packet is sent twice and acknowledged twice. Again, this is an indication of packet loss.
"Retransmission request" is the mechanism by which TCP retransmits lost packets. In will generate a retransmission error for lost packets in BOTH direction. Therefore, a single lost packet may cause the entire (variable) window size of packets to be resent as one error, but the number of packets to be resent may be up to 7 times larger.
I would say you have a lost packets problem at the TCP layer. It's very difficult to get data on lost packets at the MAC (hardware) layer. Some "managed" access points have this feature. Others display it on the status page. By the time it gets to the TCP layer, where it's visible to netstat and other diagnostics, the MAC layer may have initiated several retransmissions. Hard to tell from here.
Incidentally, there's no requirement that packets go via any particular path between the computah and the access point. If you cleverly have BOTH the wired and wireless connections active at the same time, packets can go via either path. This can create some rather bizarre looking statistics. One at a time until you figure out if anything is broken.
My astute guess is that there's nothing wrong if the errors are a sufficiently small percentage of the packets sent. There's also a possibility that the errors are cause by co-channel interference, microwave ovens, cordless phones, and such. Being close does not prevent inter-symbol interference from these devices. However, my best guess is that the web100.org software might be causing a problem.
Well, it the access point shows no errors, then all the errors are at the TCP layer and/or all on the client radio end. It would be fun to try the same test using streaming audio or video which use UDP that does not require an ACK and therefore should not show any ACK or packet loss errors.
Sure. Drag your laptop to the local free wireless hot spot and run the same test. If it has the same errors, then the problem is in the laptop. If the problem magically goes away, it's in the access point. Similarly, you can drag a borrowed laptop to your access point and repeat the same tests.
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.