not a lost packet but the tcp ports are being reused. This is often
seen in load-balanced environments where client ports are preserved
on the server-side.
We only want to report port reusage once, so the SYN/ACK is excluded
from TCP_SEQ analysis.
svn path=/trunk/; revision=22762
When a subdissector on top of TCP set ... DESEGMENT_UNTIL_FIN ... then
the subdissector should receive the whole reassembled TCP stream in tvb.
But the bug is it is missing the last payload from the FIN packet.
svn path=/trunk/; revision=22578
add a fix for ack/seq tracking when the tcp is broken and sends a
non-zero ack field for SYN packets.
add a warning to the dissect pane that illustrates that these are broken
packets
svn path=/trunk/; revision=22267
Fix for Bug 1136 (TCP Checksum Validation)
TCP cksum 0xffff should not appear in TCP headers. RFC 1624 explains that it
can be generated by a (not-so-good) algorithm for incremental updates to the
tcp-checksum.
New behavior of wireshark when having cksum == 0xffff :
- use "Checksum: 0xffff [should be 0x0000 (See RFC 1624)]" in the
packet-detail pane
- set tcp.checksum_good to FALSE (just like checksum-offload packets)
- set tcp.checksum_bad to FALSE (just like checksum-offload packets)
- Generate an expert warning: "TCP Checksum 0xffff instead of 0x0000 (See RFC 1624)"
- add "[TCP CHECKSUM 0xFFFF]" instead of "[TCP CHECKSUM BAD]" to COL_INFO
svn path=/trunk/; revision=21295
for the quite unusual case when we need to do this multiple times in a row for the same PDU.
This fixes the issue reported by Xiaoguang Liu on the mailinglist
where wireshark did not manage to properly reassemble a big HTTP header spanning several (more than two) tcp segments.
svn path=/trunk/; revision=20179
it broken in one of the previous bugfixes to tcp
add a function to print an emem tree to the console for easier emem tree debugging
svn path=/trunk/; revision=19877
there used to be a bug in tcp reassembly that even if the dissector only asked for x more bytes from the next segment the entire segment would still be added to reassembly.
this caused some issues when there was a new multisegment pdu that started at the end of the segment but this bug was fixed when tcp reassembly was refactored semi-recently.
there was also another "bug" in the http reassembly that it would only ask for one more byte at a time when doing reassembly.
this did work well however when we still had the bug in tcp reassembly but made wireshark become very very very slow once this tcp bug was fixed since it is very very very slow to reassemble a huge http pdu just one byte at a time.
this patch adds partial support (what we need for http which does not use tcp_dissect_pdus() ) for the desegmentation flag : DESEGMENT_ONE_MORE_SEGMENT and also to the http dissector so that reassembly of http headers spanning multiple semgents now become fast again
svn path=/trunk/; revision=19859
there are many reasons why some protocols actually need to be able to access the pinfo structure while determining the pdu size
svn path=/trunk/; revision=19751
I would like to have a tcp.options field with a name for PMDL output;
I include a patch to packet-tcp.c to provide that.
svn path=/trunk/; revision=19721
reintroducing the ACK_RTT measurement how long it took to ACK a data segment
Gerald this is a trivially correct patch can you apply it to the release branch?
svn path=/trunk/; revision=19669
windows in SYN and SYN+ACK packets are not scaled so dont apply window scaling to them when displaying them in the tree
svn path=/trunk/; revision=19186
add required code to the http (and others) code in req_resp_hdrs.c to signal to tcp
when it wants a session to be reassembled to the FIN.
This is currently done for all HTTP packets where we have a Content-type in the header but no content-length.
svn path=/trunk/; revision=19185
"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
Sake Blok