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 |
One Answer:
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 Using the newly created file for tcp analysis should then be OK. answered 12 Jan '16, 13:48  sindy edited 12 Jan '16, 13:50 showing 5 of 6 show 1 more comments |
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.
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.
That one was a nonsense as it was selecting all packets again.
wlan.ta == wlan.sa and wlan.ra == wlan.bssidshould be more useful as it chooses only STA -> AP packets.
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).
After thinking a bit more, I'd say that
wlan.ta == wlan.sashould 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.
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)