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
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
