"struct tcp_multisegment_pdu"; that lets it be used in one case where
the code in it was duplicated.
Make "desegment_tcp()" loop rather than recursing - not all compilers
will necessarily recognize the tail recursion.
Catch heuristic dissectors that reject a packet but also request
(whether deliberately or accidentally) that more data be added.
svn path=/trunk/; revision=18050
use tcp_multisegment_pdu and se_tree_lookup32_le() to track pdu boundaries for tcp reassembly just as this structure is used for the same purpose when reassembly is not enabled.
get rid of a hashtable and two memchunks we no longer need
tcp_segment_table tcp_segment_key_chunk and tcp_segment_address_chunk
This makes tcp reassembly work for out-of-order segments as well as when reassembly completes in one segment and when the tail of the segment contains the head of the next pdu which we did not handle before.
tcp reassembly should be much better and efficient now modulo introduced regressions.
svn path=/trunk/; revision=18046
now that we have se_tree_lookup32_le we can do the tracking of pdu boundaries much more efficiently.
track pdu boundaries by a new tcp_multisegment_pdu structure that is indexed by sequence numbers and let this structure replace the older tcp_next_pdu structure.
with se_tree_lookup32_le we no longer need to track segment by segment and can get rid of the two hash tables
tcp_pdu_tracking_table
tcp_pdu_skipping_table
Neither do we need the tree tcp_pdu_time_table anymore so that one is gone as well.
remove various other functions that are no longer needed due to removing the structure and the tables/tree
this part of the code shoul;d be much more readable now and also a bit faster
svn path=/trunk/; revision=18024
while this should improve performance by unmeasurably little it does have the sideeffect that once we finish the rewrite tcp analysis might actually work and work well even for tcp over tcp tunnelling.
this also means that if you include packet-tcp.h you also need to include emem.h .
svn path=/trunk/; revision=17681
and if the checksum is wrong
and if the checksum field is 0x0000
mark the packet as [Checksum Offloaded] and still allow reassembly of
tcp segmetns
since it is most likely just a tco checksum offload engine and not a real checksum error
svn path=/trunk/; revision=17612
only call subdissectors for packets that are NOT keepalives nor zerowindowprobes.
keepalives only contain garbage anyway
and zerowindowproes just contain a single byte of incomplete data so whats the point trying to dissect it further.
svn path=/trunk/; revision=17443
i have tested it with many captures but this used to be fragile and delicate code so there might be some regressions that will need to be addressed once identified.
svn path=/trunk/; revision=17107
packet-ntp.c: Rather confused and incorrect use of g_snprintf return value
packet-pim.c: whitespace change
packet-icmpv6.c: g_snprintf takes trailing \0 into account, fix off by 1 error
packet-clnp.c: Fix incorrect use of g_snprintf return value
packet-isakmp.c: g_snprintf takes trailing \0 into account
packet-tr.c: Fix incorrect use of g_snprintf return value
packet-radius.c: Fix incorrect use of g_snprintf return value
packet-radius.h: constify a string variable
packet-ldap.c: The return value isn't needed, so don't use it incorrectly
packet-tcp.c: Fix incorrect use of g_snprintf return value
packet-windows-common.c: Remove unneeded DISSECTOR_ASSERT
packet-smb-sidsnooping.c: g_snprintf takes trailing \0 into account
packet-pvfs2.c: g_snprintf takes trailing \0 into account
packet-ptp.c: Remove #include snprintf
packet-ppp.c: Fix incorrect use of g_snprintf return value
packet-ospf.c: Fix incorrect use of g_snprintf return value
packet-mip6.c: snprintf -> g_snprintf
packet-bootp.c: Remove a commented out bad use of g_snprintf
packet-ber.c: snprintf -> g_snprintf, g_snprintf takes trailing \0 into account
2do:
52 packet-ieee80211.c: 2DO
2 packet-nfs.c: 2DO - too many side effects
33 packet-bgp.c: 2DO
18 packet-dns.c: 2DO
14 packet-dcm.c: 2DO
13 packet-x11.c: 2DO
11 packet-kerberos.c: 2DO
10 packet-diameter.c: 2DO
9 packet-snmp.c: 2DO
9 packet-pgm.c: 2DO
7 packet-nbns.c: 2DO
6 packet-fcswils.c: 2DO
5 packet-wccp.c: 2DO
5 packet-cops.c: 2DO
4 packet-wtp.c: 2DO
svn path=/trunk/; revision=17038
instead of calling the tcp analysis (and prepend colingo) eitehr after the subdissector returned normally or if an exception caused by a subdissector was rised.
this as a sideffect caused tcp analysis data to be overwritten if the subdissector caused any output to the info column. (and made tcp analysis suboptimal)
this change adds a new function col_prepend_fence_fstr() that will prepend
the info column with the string and also, if there was no fence already defined, create a fence and set it after the prepended col info text.
This way, even if the subdissectors generate and rewrite col info, the tcp analysis data will still be displayed on the info column.
svn path=/trunk/; revision=16116
directory to the epan directory. Some of them should perhaps ultimately
be moved to epan/dissectors, if they pertain only to stuff exported by a
particular dissector.
Fix Gerald's e-mail address in files we're moving.
svn path=/trunk/; revision=15844
Please see: http://wiki.ethereal.com/Development/ExpertInfo for a complete overview of the intended feature and it's current state of implementation.
While I'm working on this, I've also added some more status result codes to the DCE/RPC and DCOM dissectors.
svn path=/trunk/; revision=15754
around until they have been acked.
Use a slab allocator for these structs so that we dont keep the structs around in memory longer than we need to.
svn path=/trunk/; revision=15546
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...
What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.
As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.
Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...
As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...
svn path=/trunk/; revision=15520
Add some more optional flags to the protocol items, so more "special cases" can be marked in the protocol tree.
New flags:
/** The protocol field has a bad checksum */
FI_CHECKSUM_ERROR
/** The protocol field has an unusual sequence (e.g. TCP window is zero) */
FI_SEQUENCE_WARNING
/** The protocol field has a bad sequence (e.g. TCP segment is lost) */
FI_SEQUENCE_ERROR
svn path=/trunk/; revision=15499
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
Ulf Lamping