don't have to worry about catching exceptions in the payload dissection
and doing the sequence number analysis - we weren't doing so in one
place. That also puts the sequence number analysis *before* the "TCP
payload" entry for payload being reassembled into a later packet.
XXX - should we do the tapping before dissecting the payload, too, so
that it gets done even if we throw an exception?
svn path=/trunk/; revision=15335
dissector says "sorry, I need even more data in this packet", don't flag
that packet as being reassembled in that frame. Indicate that we should
perhaps do all the "partial reassembly" stuff in
"fragment_set_partial_assembly()", which would obviate the need for the
hack in the TCP dissector.
Clean up indentation.
svn path=/trunk/; revision=15139
calculate RTO as the delta between the retransmitted frame and the last previous frame seen for this session (in the same direction).
while this is technically not the RTO this delta is in most cases more important/useful than the tru RTO anyway since this measure represents the amount of thiime that the link went idle while waiting for an RTO.
It would be nice with a statistics tap for TCP where one couls see, seeion by session :
Length in time of the session.
Total bytes transferred
Number of retransmissions
Time spent waiting for an RTO
Time spent waiting for an RTO in % of the total time.
svn path=/trunk/; revision=14890
in a simple approach, I've replaced all g_assert() and g_assert_not_reached() calls by their exception throwing counterparts DISSECTOR_ASSERT() and DISSECTOR_ASSERT_NOT_REACHED()
this will replace application crash by showing a dissector bug, which is the desired behaviour
there were some g_assert calls in the protocol registering functions, which might not be acting as expected now, but to be able to simply search for g_assert in the future I've replaced that calls too
one g_assert remained, the one when someone throws an unknown exception "into" packet_frame.c, but IMHO this one should remain.
svn path=/trunk/; revision=14608
1) Added a setup_frame parameter to conversation_t
2) Used the conversation_t next to maintain a list of conversations with the
same src/dest tuple but different setup_frame number.
3) Changed the signature of find_conversation() and conversation_new() to pass
in the frame number.
4) Adjusted packet-sdp to select RTP conversation if both m=audio and m=image
are present, and T.38 conversation if only m=image is present. I expect that
RTP/T.38 dissecting to be better, but I don't have a way to generate T.38
packets.
svn path=/trunk/; revision=13243
I.e. when a segment is seen that would (as far as ethereal can tell from the ACKs it has seen in the other direction) fill the window completely.
It is similar to but not exactly the same as the XeroWindow detection since there are many instances where ZeroWindow detection would not work (i.e. an ACK where win==0 since many many situations occur where the window is full but no zerowindowack is ever generated)
Someone that has good english could, please, update the Wiki with this option.
It is very very useful to spot performance issues where the tcp window size is too small to accomodate the enmd-to-end latency.
svn path=/trunk/; revision=12774
make ethereal be able to measure the time it took to transfer a PDU atop TCP.
This is great for analyzing performance issues caused by network/frame loss/congestion.
See http://wiki.ethereal.com/TcpPduTime
svn path=/trunk/; revision=12516
Only display this value if we really have some data to ACK
which is not always the case.
This fixes a problem recently reported to the list
svn path=/trunk/; revision=12259
ethereal used to (bug) print in the summary line
"[Continuation to #%d]" where %d was the current frame number.
Fix this bug and let %d print the frame number of the first frame for this multiframe PDU.
(Strange that no one has complained about this one)
svn path=/trunk/; revision=11852
try to access the conversation structures unless the
proper preferences are enabled (so that the structs exists iun the first place)
svn path=/trunk/; revision=11845
If window scaling is NOT offered in the SYN+ACK then window scaling will
not be used at all, so clear it if we saw it offered previously in the SYN packet.
If the window is scaled in a packet, make ethereal display that by appendign the
string " (scaled)" to the end of the tcp.window line in the
decode pane.
svn path=/trunk/; revision=11837
I (hopefully) didn't changed any protocol fields or preference file names, but only the GUI labels appearing in the protocol display and the protocol preferences.
Also added a note to the protocol preferences (where appropriate), that you have to enable "Allow subdissectors to reassemble TCP streams" at the corresponding protocol settings for TCP reassembling to take effect.
If you encounter any mistakes I've made here, please let me know...
svn path=/trunk/; revision=11784
include of <resolv.h> in any system header file gets the system
<resolv.h> (needed for builds on Tru64 with GTK+ 1.2[.x]).
svn path=/trunk/; revision=11615
Also move ncp222.py, x11-fields, process-x11-fields.pl,
make-reg-dotc, and make-reg-dotc.py.
Adjust #include lines in files that include packet-*.h
files.
svn path=/trunk/; revision=11410