One thing I was looking for, but did not find: some way where Ethereal >can
draw my attention to evidence of "problems" in TCP sessions, such as:
- re-transmissions (maybe excessive re-transmissions)
- slow responses
- TCP sessions that don't complete a full start-up handshake
re-transmissions:
There are two ways to detect them
1, in 0.9.6 or later, enable Edit/Preferences/Protocols/TCP/Analyze TCP
sequence numbers this will flag (most)all suspected retransmissions by
keeping track of ACK and SEQ numbers for the conversations. Suspected
retransmisisons will have something like [TCP Retransmission] prepended to
the Info Column.
I think there are a few suspected bugs remaining in the TCP SEQ/ACK analysis
so beware.
It also provides displayfilters you can use so search for those packets.
2, Much better: select a packet for the conversation you are interested in
(for the direction tou are interested in) by clicking it in the middle pane,
then on the menu select Tools/TCP Stream Analysis/Time Sequence Graph
This will give you a graphical representation on how the sequence numbers
change during the selected direction of the selected conversation.
With this tool it is very easy to spot retransmissions and it is a mature
and bugfree feature.
Slow responses:
1, I have plans to add RFC2988 retransmission timeout calculations sometime
in the unknown future which would allow checking for slow responses. I.e.
ACKs that are delatyed until after the calculated RTO.
This may or may not be implemented within the next few months. No
guarantees.
2, Using the excellent Tools/TCP Stream Analysis/... it is possible to spot
sideeffects of slow responses. Try that tool for the time being.
Incomplete handshakes:
Not possible at this point. Could in theory be implemented. Maybe.
It may be difficult to do it since ethereal cant go back and redissect
packets.
==
Maybe we should have a feature to be able to tell the stuff in file.c that
we need to go back and redissect an earlier packet.
This would be useful for the reassembly as well since then we could
dissect/display only (for say IP reassembly) the initial fragment instead of
as now for all fragments (since we dont know which order the fragments
arrive)
That could allow us to only call the subdissectors from packet-ip.c only for
fragment_offset==0, and if we at some later stage have completed reassembly
we can tell ethereal, go back and redissect frame X, perhaps all other
fragments as well so that COL_INFO is updated.
This would be a useful feature.
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
