Wireshark-bugs: [Wireshark-bugs] [Bug 1694] TCP does NOT decode correctly in the presence of 802
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1694
------- Comment #3 from guy@xxxxxxxxxxxx 2007-07-18 17:24 GMT -------
The lack of an ACK doesn't help - remember, this all has to work in a strictly
one-pass environment.
The higher-level dissectors don't know whether the frame has an ACK - this is
by intent and design. The frame might not even have come from 802.11 - it
might have come from Ethernet, or FDDI, or PPP, or ATM, or the loopback
adapter, or.... What would have to be done would be for the 802.11 dissector
not to hand the packet to the next higher-level dissector in the first place.
To do that for frames without an ACK would require some major re-architecture
of *Shark, e.g. to "buffer" frames and not fully dissect them until later
dissection indicates that they should, or shouldn't, be fully dissected. That
can't happen in the short term; it would be a major undertaking.
Note also that ACK frames aren't necessarily captured - I assume that in
monitor mode they'll be seen, but, if not, it would be a bit difficult to
detect un-ACKed frames.
One thing that could be done would be to detect the retransmission and not to
hand the *retransmitted* frames to subdissectors. (Note that this would mean
that service response times would be measured from the time of the *first*
transmission of the request to the time of the first transmission of the
response - the ideal would be to measure it from the time of the first
transmission of the request to the time of the *last* transmission of the
response, as that includes retransmission delays in the SRT delay, but, again,
detecting the last transmission is tricky.)
In addition, *IF* the FCS is present in the frame, the 802.11 dissector could
check the FCS and not hand frames with a bad FCS to higher-level dissectors.
That means that if you don't see the retransmission, the frame won't be
dissected, and you won't know what the bad frame was (not that the dissection
would necessarily be perfect, if the packet data is corrupted, but you might at
least be able to see some information to indicate what it was).
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
