Comment # 5
on bug 10177
from Guy Harris
(In reply to comment #4)
> Created attachment 12792 [details]
> new_1
>
> I re-captures using just 11n-HT40 pacekts without nay capture filter at all.
>
> One observation is that when same thing tried with Omnipeek (loaner) works
> fine and can see all the TCP data/ack packets.
>
> With Wireshark i see the following two problems:
> 1) The TCP ACK (shown in capture as length 175 bytes - including header) is
> a small packet (no fragmentation) and does not need re-assembling does not
> get decoded beyond LLC. From the point where bytes read 0x08 (type = IP) no
> decode is done.
>
> 2) The TCP DATA packets total around 1600 bytes, shows as re-assembled but
> still does not decoded.
With the current Wireshark trunk:
Frames 1 and 3 are the first IP fragments of fragmented packets.
Frames 2 and 4 are the second IP fragments of those packets; the fragmented
packets are reassembled, and both are recognized as PEEKREMOTE packets
containing 802.11 frames that are TCP data packets. The TCP data is not
dissected, because Wireshark does not know what the protocol is for them.
Frames 5, 6, and 7 are not recognized as PEEKREMOTE packets by default.
Frames 8, 9, 10, and 11 are recognized as PEEKREMOTE packets containing
802.11 frames that are TCP ACK-only packets.
If I use "Decode As..." to decode all traffic between ports 5555 and 5000 as
PEEKREMOTE, frames 5, 6, and 7 are dissected as PEEKREMOTE packets:
Frame 5 is an 802.11 Block Ack;
Frame 6 is an 802.11 Request-to-Send;
Frame 7 is an 802.11 Clear-to-Send.
If that's not what you're seeing, you may be seeing bug 10139, in which case
you will need to use Wireshark 1.8.15 or 1.10.8, both of which have been
released today, or 1.12.0rc2, which has not yet been released.
You are receiving this mail because:
- You are watching all bug changes.