work (or inferred to work - some lists were changed to "XXX and later",
on the assumption that later releases didn't break anything).
svn path=/trunk/; revision=9592
strict enforcement of SIP/2.0 will be applied.
Add some comments.
From Anders Broman:
Fix the length of content_type_parameter_str.
Fix a typo in a comment.
svn path=/trunk/; revision=9591
Give the appropriate locations for libiconv, gettext, and WinPcap.
Note that the WinPcap package is *not* available from ethereal.com.
Explain a bit more about how to unpack the zip files for development
packages.
svn path=/trunk/; revision=9587
dissectors assume a two's-complement machine (we offer our apologies to
those trying to run it on sign-magnitude IBM 7090/7094's and one's
complement Univac/Unisys 11xx machines :-)).
svn path=/trunk/; revision=9584
capture is read.
"interface_anzahl" is always <= MAX_INTERFACES, so we don't need to
check array indices against MAX_INTERFACES when iterating over all known
interfaces.
svn path=/trunk/; revision=9577
"guint", and make the "labnum" variable to which its return value is
assigned a "guint".
"plen" in "decode_prefix_MP()" can have a 16-bit value assigned to it;
make it a "guint", not just a "guint8".
svn path=/trunk/; revision=9568
dissecting AFP server status - other servers might have different status
formats.
In "dissect_asp_reply_get_status()", put the UTF-8 server name into a
tree, with the length and name in the tree as separate items, and fetch
the length into a 16-bit variable (as it's a 16-bit length in the
packet), as is done in "dissect_dsi_reply_get_status()". (XXX - should
that just be done with an FT_UINT_STRING field, as is done for other
strings?)
Use "tvb_get_string()" to fetch the UTF-8 server name, and set the
length and name from the values we fetched, in both of those routines.
For FT_UINT_STRING fields in "dissect_asp_reply_get_status()" and
"dissect_dsi_reply_get_status()", don't fetch the length separately -
just use the value filled in by "proto_tree_add_item()" (now that a
"proto_item" is no longer opaque, we can do that). That means we don't
have a problem with overflows of the 8-bit "len" variable if the length
is 255.
svn path=/trunk/; revision=9567
the request has no body.
When displaying the body, use the reported length remaining, not the
captured length remaining, as the length.
svn path=/trunk/; revision=9552
Error tokens (at least in one capture) appear to have a server name in
them; handle that as well. (They also appear to have 3 more bytes of
stuff in them.)
svn path=/trunk/; revision=9551
add parsing of message token (Unicode and regular);
add parsing of error token (Unicode only - do not have a non Unicode
sample. Anyone?);
add parsing of done token (only minimal actually);
add parsing of Collation Information structure in Environment
Change token.
svn path=/trunk/; revision=9550
add parsing of message token (Unicode and regular);
add parsing of error token (Unicode only - do not have a non Unicode
sample. Anyone?);
add parsing of done token (only minimal actually);
add parsing of Collation Information structure in Environment
Change token.
svn path=/trunk/; revision=9549
important parameters).
Document the computation of the length field in WTP concatenation after having
looked at a capture with the length field encoded as a WSP uintvar-integer.
Use "common code" for WTP reassembly, by calling process_reassembled_data().
Document the behavior of reassembly as the output of Ethereal differs between
the first and the second pass.
Question: shoud the common reassembly code provide a call-back mechanism to
get access to previously-unreassembled packets that appear to be part of a
reassembled whole, and to be able to update the state and information of
those packets at the time of the reassembly?
svn path=/trunk/; revision=9547
Guy Harris