(and the fact that nbss does not register its conversation)
this caused WANT_PDU_TRACKING to be decremented multiple times between
the dissectors
and thus ethereal could no longer reliably spot SMB PDUs that started in the middle of a tcp segment (unless we do reassembly which we dont do unless we have to since it eats soo many resources)
FIX so that ethereal once again can spot SMB (and other) protocol PDUs that start in the middle of a segment.
svn path=/trunk/; revision=10219
by pass-through proxying dissectors such as the SOCKS dissector; it does
the work of processing a TCP segment, including desegmentation. Export
the "next sequence number" value to subdissectors, so they can use it
when calling "dissect_tcp_payload()".
Use that in the SOCKS dissector.
svn path=/trunk/; revision=9489
I.e. SEQ : seq==0 ack==0
SEQ|ACK seq==0 ack==1
ACK seq==1 ack==1
This looks much more correct.
This change also fixes the problem reported to ethereal-dev
recently with "Follow TCP Stream" dropping the first character of the stream.
svn path=/trunk/; revision=9034
instead of DISABLED.
These features do not consume that much memory or CPU but will greatly enhance the feature set of ethereal. Make it enabled by default so also those that never venture into the preferences dialog will benefit from it.
svn path=/trunk/; revision=8957
and have it return TRUE if we succeeded, FALSE otherwise - and have an
internal "process_tcp_payload()" routine handle the (TCP-specific) PDU
tracking and sequence number analysis, with an argument to indicate
whether it should do that or not (i.e., whether it's being handed a TCP
segment or reassembled data).
svn path=/trunk/; revision=8914
packets/sessions, e.g. MSProxy and SOCKS. It should not cause any of
the TCP-specific stuff such as sequence number analysis or PDU tracking
to be done. (Actually, MSProxy and SOCKS should offer desegmentation
services *themselves* and do their *own* PDU tracking, rather than just
passing stuff on to "decode_tcp_ports()", but that's another matter.)
Make "tcp_tree" once again be a local variable to "dissect_tcp()", and
pass it as an argument to those functions that use it.
svn path=/trunk/; revision=8912
LDAP messages that span multiple segments will throw an exception unless we have reassembly enabled.
Update TCP so that IF an exception was thrown that we still pick up any hints
provided by the subdissector about where the next PDU starts.
Update LDAP so that it will rpovide hints to TCP about where the next LDAP PDU starts in the sequence number space.
Thus now ethereal can find and dissect LDAP PDUs that starts somewhere in the middle of a TCP segment.
svn path=/trunk/; revision=8895
If we have short or malformed PDUs in protocols above TCP this will generate
an exception and thus some of the stateful things such as keeping track of
and printing the tcp analysis data will be shourcutted and not called.
Add a wrapper around the call to the subdissectors above TCP so that
if an exception is generated we will still catch it and explicitely
call tcp_print_sequence_number_analysis() so that also short packets are
handled well.
svn path=/trunk/; revision=8891
It is thus relatively common that a data segment and its ACK being swapped in the capture file.
Therefore, drop the condition that a segment must not have been acked yet in the detection of OutOfOrder segments.
Second, fix a bug where we didnt keep track of the ack numbers properly for relative sequence number analysis.
svn path=/trunk/; revision=8800
moved some variables to the structure where they belonged instead of where they
currently were and reduced the complexity of the code
Fast Retransmission:
Ethereal not tries to detect and flag FastRetransmissions:
The heuristics for this check is:
>=3 dupacks in other direction
this semgent is what the dupacks are asking for
it arrived within 10ms of the last dupack (10ms should be short enough to not confuse with real RTOs)
OutOfOrder segments
Previously all segments that did not advance the right edge of the window was flagged as retransmission now ethereal will try to flag segments that are merely reordered as OutOfOrder segments insteaD
tHE HEURISTICS ARE:
it has not been ACKed yet
we have not seen it before
it arrived within 4ms of the segment immediately to the right in the window
svn path=/trunk/; revision=8775
Small change to the TCP sequence number analysis and relative sequence number code
so that it plays a bit nicer with captures generated by text2pcap.
Change the criterion used to initialize the base sequence and ack numbers
to set these base offsets where it detects that the bookkeeping structures are NULL (as in no previous packet seen for this session) instead of using a hardcoded magic number 0, which might actually occur in normal captures.
svn path=/trunk/; revision=8674
sequence numbers and window scaling" option is set, as that option says
it controls whether we attempt to display the real post-scaling window
size.
Also, don't store it unless the "Analyze TCP sequence numbers" option is
set, as "Relative sequence numbers and window scaling" requires it,
because, unless "Analyze TCP sequence numbers" is set, we don't set up
conversations for TCP connections and don't have a pool of data
structures for per-connection information into which to store the window
scale option value.
svn path=/trunk/; revision=8490
Track window scaling and display the window field after it has been scaled to its real value
If we have seen a SYN packet with a WindowScalingOption
then if the option to use RelativeSequence numbers has been enabled,
then ethereal will change the presented window field to be the window after it has been scaled to the real value.
This obviously only works if we have seen the SYN packet and if the SYN packet contained a window scaling option
svn path=/trunk/; revision=8461
An ACK to a KeepAlive is not a DupACK.
Detect these ACKs and mark them as KeepAliveACK instead of as DupACK
(or maybe dont mark them at all? )
At least they shouldnt be marked as DupACKs
svn path=/trunk/; revision=8411
Supported types are Ethernet/TokenRing/IP/UDP and TCP.
Will add FibreChannel soon.
The framework for this feature needs to be enhanced in the future so that by selecting one entry and click the right mousebutton, this will bring up a menu with Prepare/Match options with suboptions for AnyDirection, ForwardOnly or ReverseOnly which updates the display filter accordingly.
Had to update some of the taps as well to change them to use a proper address structure for the address fields.
We should now be able to to these stats correctly even for ip tunneled over ip tunnelled over ip ...
svn path=/trunk/; revision=8222
dissector, heuristic dissectors should be checked before, or after,
dissectors for specific port numbers.
Add a similar preference for UDP.
Clean up white space.
svn path=/trunk/; revision=8082
"dissect_ip_tcp_options()" but for options that are like IPv6 options
(i.e., the length byte has a value that doesn't include the option code
or length byte).
Add an "ip_opts.h" header to declare it, and move the declaration of
stuff used by it and "dissect_ip_tcp_options()", and the declaration of
"dissect_ip_tcp_options()", to that header.
Use "dissect_ipv6_options()" for Mobile IPv6 options.
Get rid of the unused "mip6_opt_types[]" array in "packet-mip6.h".
svn path=/trunk/; revision=8015
a TCP segment, and probably don't want to hand the segment to a TCP tap,
if the TCP segment is included in an error packet.
svn path=/trunk/; revision=7780
length, we can't get the segment length (although we can at least try to
dissect the header). If that's the case, put in Ronnie's "short
segment" note.
Also, put into the information we pass to TCP taps an indication of
whether the segment length is valid or not.
svn path=/trunk/; revision=7705
knowing the actual length of the packet, as we don't know that length
(IP fragments don't contain the length of the full packet - you don't
know how big the reassembled packet is until you reassemble it).
We don't have to worry about dissecting the TCP header in them, though.
svn path=/trunk/; revision=7703
or the reported tcp header length.
This is probably caused either by a very very short capture length or by
nmap or someone playing firewall fragment games to the tcp flags field.
svn path=/trunk/; revision=7698
the rather brilliant keep-alive packets solaris use.
Solaris does not do RFC793 keepalives at all, instead they do a quite
brilliant workalike that gies them reliable keepalives.
svn path=/trunk/; revision=7685
ONCRPC dissector updated to provide hint to TCP where the next RPCoverTCP
PDU starts as example.
Trivial updates to the other TCP based protocols required to amke them handle
this as well. See the updates to packet-rpc.c as an example.
This is enabled by activating tcp analysis and provides hints to TCP to know where PDUs starts when not aligned to the start of the segment.
svn path=/trunk/; revision=7543
null) to the "fragment_items" structure, and don't pass that value into
"process_reassembled_data()", just have it use the value in the
"fragment_items" structure passed to it.
Make "process_reassembled_data()" capable of handling reassembly done by
"fragment_add_seq_check()", and use it in the ATP and 802.11 dissectors;
give them "reassembled_in" fields. Make "process_reassembled_data()"
handle only the case of a completed reassembly (fd_head != NULL) so that
we can use it in those dissectors without gunking the code up too much.
svn path=/trunk/; revision=7513
Duplicate ACKs that are detected/suspected are now also flagged
with which frame the original ACK was seen in and the dup ack number.
This is displayed both in the summary pane as well as in the tree pane.
svn path=/trunk/; revision=7375
FIN flag would previously only add one to the sequence number if the
FIN packet was empty, i.e. did not carry any payload data.
This caused ethereal to incorrectly flag the ACK to such packets
(FIN+payload data) to be incorrectly flagged as
ACK to previously lost segment.
Change the algorithm to always add 1 to the segment length, and thus the sequence number for all packets with teh FIN bit set.
svn path=/trunk/; revision=7371
when doing reassembly.
In some additional places, use "tvb_bytes_exist()" to check whether we
have enough data to do reassembly, rather than checking to see if the
frame is short (it might be short but we might still have enough data to
do reassembly).
In DCE RPC, use the fragment length from the header as the number of
bytes of fragment data.
There's no need to check "pinfo->fragmented" before doing reassembly in
the DCERPC-over-SMB-pipes code - either we have all the data or we
don't.
In SNA and WTP reassembly, add a check to make sure we have all the data
to be reassembled.
svn path=/trunk/; revision=7282
Ulf Lamping