This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

AP Forward Labeled As Retransmission

0

In an 802.11 infrastructure network, all communication between STAs passes through the AP (access point). This means that when one STA wants to send a packet to another STA in the network, the sending STA sends the packet to the AP, and then the AP forwards the packet to the destination STA.

I am monitoring TCP communications between two STAs on a network, and I have found that Wireshark labels a TCP message's second hop (from the AP to the final destination) as a TCP retransmission. This behavior seems incorrect, because the second hop is not actually a retransmission. In addition to being misleading, this behavior makes it difficult to procure statistics on the true number of TCP retransmissions.

Are there any settings or fixes to alleviate this issue?

I am using Wireshark v1.12.9 on a Windows 7 PC.

asked 12 Jan '16, 12:58

J_Turner's gravatar image

J_Turner
715510
accept rate: 0%


One Answer:

0

I assume you're using monitoring mode, as otherwise you should be unable to see those packets at all.

In such case, the fastest workaround should be to filter out only the frames between any of the two STAs and the AP, using a display filter such as (wlan.da == xx-xx-xx-xx-xx-xx and vlan.ra == xx-xx-xx-xx-xx-xx) or (wlan.sa == xx-xx-xx-xx-xx-xx and wlan.ta == xx-xx-xx-xx-xx-xx) where xx-xx-xx-xx-xx-xx is the MAC of one of the STAs, and then use File -> Export Specified Packets to save the filtered frames into a new pcap(ng) file, choosing the "Displayed" column and "All packets" row when specifying which frames to save.

Using the newly created file for tcp analysis should then be OK.

answered 12 Jan '16, 13:48

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 12 Jan '16, 13:50

Thank you for the quick answer. I have successfully accomplished this using filtering, but this solution is specific to each file (actually to each MAC ID). I would like a solution that is generic and can be used for any capture file/MAC IDs. Otherwise, I have to create a specific filter for every STA/AP combo that I want to analyze.

(12 Jan '16, 13:57) J_Turner

Hehe, you've made me try what I haven't believed would work (because I've always thought that you must compare a dissected protocol field to a constant, not to another dissected protocol field):

(wlan.ta == wlan.sa and wlan.ra == wlan.bssid) or (wlan.ra == wlan.da and wlan.ta == wlan.bssid)

Is this quick workaround generic enough for your purpose?

If not, you'll have to wait for someone deeper into it to answer.

(12 Jan '16, 14:06) sindy

That one was a nonsense as it was selecting all packets again.

wlan.ta == wlan.sa and wlan.ra == wlan.bssid

should be more useful as it chooses only STA -> AP packets.

(12 Jan '16, 22:10) sindy

Good thinking! It is more helpful to me to filter out the duplicate packets, so the filter could be:

!(wlan.sa != wlan.bssid && wlan.fc.ds == 2)

This filter is yellow, but it does yield the expected result. Can you think of another (non-yellow) way to filter out the AP -> STA packets. Note that in my case, it is possible for packets to originate with the AP (embedded system where Ad-hoc is not employed).

(13 Jan '16, 08:15) J_Turner

After thinking a bit more, I'd say that wlan.ta == wlan.sa should be sufficient and "green" for all cases. It will show both the packets for which the AP is the real originator and the packets which are sent by any STAs, it will only block the packets retranslated by the AP.

Once you confirm this works for you, I'll edit also the original response in this sense.

(13 Jan '16, 11:34) sindy

I tried the wlan.ta == wlan.sa, but it filters out the 802.11 acknowledge messages, CTS-to-self, and other short, non-standard messages that I would like to see.

I believe all of these "non-standard" messages are control frames, so I think this will work: (wlan.ta == wlan.sa || wlan.fc.type == 1)

(21 Apr '16, 08:53) J_Turner
showing 5 of 6 show 1 more comments