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
belongs, as that's redundant.
Fix a bunch of cases where that was done, and map the old name to the
new name.
Instead of marking "mtp3.mtp3_standard" as obsolete, map it to
"mtp3.standard".
svn path=/trunk/; revision=7030
qualifiers as necessary to ensure that we don't have to.
"strcmp()", "strcasecmp()", and "memcmp()" don't return booleans; don't
test their results as if they did.
Use "guint8", not "guchar", for a pointer to (one or more) 8-bit bytes.
Update Michael Tuexen's e-mail address.
svn path=/trunk/; revision=6726
ZeroWindow: ZeroWindow segments are detected and flagged
ZeroWindowProbe: detected and flagged
ZeroWindowViolation: attempts to write >1 byte of data to a zerowindow is detected and flagged.
svn path=/trunk/; revision=6543
its starting sequence number, as the "fragment ID" when reassembling,
and include the source and destination port numbers in a
"tcp_segment_key" structure and use that as part of the key in the hash
table for segments, so that we don't get spoofed by segments in two
directions in the same conversation, or by segments in two separate
conversations between the same hosts, having the same starting sequence
number (which is not unlikely to happen if relative sequence numbers are
being used).
svn path=/trunk/; revision=6443
If the addresses are equal, compare the ports with '>' instead of '-'
since '>' will work regardless of whether the values are unsigned or not.
svn path=/trunk/; revision=6268
guaranteed to return 0, a positive number, or a negative number, based
on the result of the comparison. Furthermore, if it returns 0, meaning
the source and destination addresses are the same, we have to look at
the port numbers to decide which side of the conversation the frame is
from.
svn path=/trunk/; revision=6064
tcp sequence number analysis flags, such as retransmission , lost-segment, etc
to make it easier to search for all these conditions.
svn path=/trunk/; revision=6056
into it, as soon as we've extracted the source and destination ports
from the packet, so that if we throw an exception fetching something
else from the packet, we still have the protocol tree and ports.
svn path=/trunk/; revision=5943
equivalents for the toplevel directory. The removal of winsock2.h will
hopefully not cause any problems under MSVC++, as those files using
struct timeval still include wtap.h, which still includes winsock2.h.
svn path=/trunk/; revision=5932
1, Analyze TCP sequence numbers.
This option will keep track of sequence numbers for all tcp sessions
and flag the following:
a, If a new segment is seen which is beyong the right edge this is
an indication that the previous segment was lost and this will be
flagged as previous segment lost.
b, If a segment is seen which lies left of the right edge this is flagged
as retransmission.
c, if a keep-alive is seen (empty segment, seq==expected seq-1)
this is flagged as a retransmission.
d, if an ACK is seen which is beyond the right edge this is an indication
that a segment has been lost and it will be flagged as segment lost.
All ACKs which advance the left edge get the RTT displayed between the ACKed
segment and the ACK itself. The ACK also gets an indication of WHICH segment
it is an ACK for.
2, Relative sequence numbers. This option needs the first option to be selected
as well. This option will as best as it can try to get ethereal to use
relative sequence numbers instead of absolute ones.
The patch does not handle sequence number wrapping and unexpected results
can probably happen for such.
svn path=/trunk/; revision=5931
dftest.c:
Remove #if-0-ed includes
packet-ieee80211.c, packet-wtls.c, packet-afp.c, packet-wsp.c,
packet-wtp.c, ethereal_gen.py:
Remove redundant include varargs (already in snprintf.h,
and required only for snprintf.h)
Remove unused include of snprintf.h from files not using
"snprintf()".
svn path=/trunk/; revision=5889
fetched the source and destination port numbers, so that they're
available to the "Follow TCP Stream" code even if we throw an exception
dissecting the rest of the TCP header.
svn path=/trunk/; revision=5811
in TCP, UDP, and SCTP, try the lower port number first, and then the
higher port number; this means that, for packets where a dissector is
registered for *both* port numbers:
1) we pick the same dissector for traffic going in both directions;
2) we prefer the port number that's more likely to be the right
one (as that prefers well-known ports to reserved ports);
although there is, of course, no guarantee that any such strategy will
always pick the right port number.
Ignore port numbers of 0, as some dissectors use a port number of 0 to
disable the port, and as RFC 768 says that the source port in UDP
datagrams is optional and is 0 if not used.
svn path=/trunk/; revision=5656