Forum

I do some consulting for a local WISP. They called me the other day with unexplainable slowdowns.

I did a packet capture and here is one of the problems I found. When the AP sends a TCP frame the duration values are either 50574 or 35864 microseconds. The other frames have normal duration values. I'm not even sure how a STA would respond to a duration value of that size.

Thoughts?

Is this one of those MERU APs?

http://www.unstrung.com/document.asp?doc_id=111677&page_number=5


Is the radio failing or are they under attack?

http://manageengine.adventnet.com/products/wifi-manager/duration-attack.html

The AP is a Senao which isn't a high end brand.

I guess what is weird is of the 4 AP's on this tower, the other three have a high concentration of HTTP traffic, which is what you would expect on a WISP tower.

This AP had a high concentration of TCP traffic (80%) and those weird duration values. Notice that the duration values are higher than the standard allows so I'm wondering how the STA's would respond. We are going to reboot the AP to see if it is just a glitch, but if that doesn't work we'll have to replace it. If it is replaced I'm going to mess with it to see how a STA reacts to an out of standard duration value.

Wait a second, how is it even possible in binary to get a duration value like that? The only way to get duration values that high is to have bit 15 of the duration value on, which shouldn't be done. Here is the duration value binary for anyone that is curious. 1000 1110 1100 0101

I think this AP has just hiccupped and is doing weird stuff, but I think this is a neat example of how a problem can only be found by packet capture.

Been there, seen that. Those are corrupted frames amigo. Check your flags.

Devinator

No way amigo. I have about 2500 frames doing the same thing. I'm not a CWNE for nothing. :)

:-D I was hoping you'd say that. I *have* however seen LOTS of corrupted frames with outrageous duration values. Thanks for the sending me the capture - I'll review. Yes, CWNEs rule. hehe.

Devinator

When you say a TCP segment being sent from the AP, is this a segment from the DS or is it originated from the AP (via a management interface or something)? Are they from the same source?

You've definitely piqued my curiosity. Also, to make sure, you're reading the 802.11 frame duration value, which happens to be a TCP segment, right?

Honestly the first thing I thought of was corruption. The funny thing is that 4 APs on a tower...hmmm...tower of babel if not done correctly. (i.e. separation, antenna gain, shielding, etc.) Wondering if this is playing into the corruption. Does this happen to be coming from the AP that one of the other 3 is set to?

All I know is that I've chased down the wrong hole many-a-day by not realizing that it was a corrupt frame(s).

If this still leads to confusion, I'm thinking that it would be nice to trace this back to an 802.3 capture and analyze what is happening to the traffic.

Not only are these frames coming from the AP, they come from the same manufacturer in bridge mode (CPE). The frames are not corrupt. The best I can figure is that they are TCP ACK frames. Can we not attach images to these posts?

PM or email me and I'll send you the captures. I have already contacted the manufacture and told them of their error. Also in their new code, RTS/CTS doesn't work. It is a dummy configuration. I have to get back to class.
[/img]

To attach images, you need to host them on a web server and point to their URL in the post.

Devinator