dissectors to use it, from Ronnie Sahlberg, with additional changes to
handle the case where a frame contains messages that don't run past the
end followed by one that does and where a reassembled chunk has, at the
end, a message that runs past the end of that chunk (because the
reassembly was for an earlier message).
svn path=/trunk/; revision=3923
"dissect_rpc_common()" check, every time it's about to return FALSE,
whether it's being used as a heuristic dissector and, if not, call
"dissect_rpc_continuation()" - we can just have the non-heuristic
dissector call it and, if it returned FALSE, call
"dissect_rpc_continuation()".
svn path=/trunk/; revision=3922
source and destination addresses if the transport is TCP (we use that,
for now, as a proxy for "if the transport is connection-oriented"), as
the endpoint addresses should be the same for all packets.
Have both a heuristic RPC dissector and a non-heuristic version, and
make the non-heuristic version the dissector for the conversations we
create; that version will, if the frame doesn't look like a call or
reply, mark it as continuation data.
svn path=/trunk/; revision=3921
being written, but the 2 bytes of data length and one byte of buffer
type preceding that data; use the data length (which doesn't count
itself or the buffer type byte), rather than the byte count, to
determine how much data is being written.
svn path=/trunk/; revision=3917
buffered data is written out to the file;
headers are written if the capture file header depends on the
number or sizes of the packets;
etc..
svn path=/trunk/; revision=3909
Add comments noting the IPv6 issues for PASV responses.
When adding the FTP dissector for the FTP port, give its protocol as
"proto_ftp", not "proto_ftp_data".
svn path=/trunk/; revision=3904
of protocol-id-plus-datum pairs, so that multiple protocols can attach
information to the same conversation.
Dissectors that attach information to a conversation should not assume
that if they find a conversation it has one of its data attached to it;
the conversation might've been created by another dissector.
svn path=/trunk/; revision=3901
have an unsigned integer as that argument; this squelches some compiler
warnings, and it's the right thing to do in any case.
Don't check whether an unsigned integer value is > 0 - that's the same
as checking whether it's != 0.
svn path=/trunk/; revision=3898
that look up conversations in hash tables, unless they are arguments
that will be ignored; if they're not being ignored, then if the argument
is a null pointer you may get a crash if it's dereferenced, and if it's
not a null pointer you'll only get a match if the conversation has
whatever stuff the arguments points to as its first address or port.
If you match a conversation with a wildcarded address and/or port, and
the address and/or port matched a non-wildcarded search argument, and
the conversation is for a connection-oriented transport protocol, set
the wildcarded address and/or port for the conversation to the value
that matched it.
svn path=/trunk/; revision=3897
rather than the address from which the PASV reply came when setting up a
conversation.
Don't compare the reply code with "227" unless the reply code is 3
characters long.
Set up the conversation for a PASV response only if we haven't already
processed the packet (and thus haven't already set up the conversation).
svn path=/trunk/; revision=3896
"try_conversation_dissector()" does - start with as exact matches as
possible, and then start doing wildcarding - so that it can find
conversations with wildcard addresses or ports even if both address and
port arguments are supplied to it.
svn path=/trunk/; revision=3893
available - just mark it as "authentication flavor unknown". Don't
dissect the next protocol if the authentication flavor is unknown.
This lets us get some more work done on short frames (although if you
really want to analyze ONC RPC traffic, you should make the snapshot
length large enough to capture enough of the frames).
svn path=/trunk/; revision=3891
the lists of source and generated files for plugins.
While we're at it, make all those lists show the files in the same
order.
svn path=/trunk/; revision=3888
"conversation_new()" and "find_conversation()" do not have fixed
identities as source and destination addresses, and to reflect the name
changes we made to arguments and flags to dispel any notion that they
had such fixed identities.
svn path=/trunk/; revision=3887
- Use only basename of CORBA IDL file to generate the dissector
name, and not the fullpath name. Allows idl2eth to generate
valid "C" code no matter where the IDL file lives (doh!)
svn path=/trunk/; revision=3886
"proto_item_set_text()" except that it appends the result of the
formatting to the item's current text, rather than replacing the item's
current text. Use it in the DNS dissector.
svn path=/trunk/; revision=3880
but, before you set the text, you throw an exception while putting stuff
under the subtree, you end up with an absolutely blank protocol tree
item, which is really gross. Instead of calling
"proto_tree_add_notext()", call "proto_tree_add_text()" with at least a
minimal label - yes, it does mean you do some work that will probably be
unnecessary, but, absent a scheme to arrange to do that work if it *is*
necessary (e.g., catching exceptions), the alternative is an ugly
protocol tree display.
svn path=/trunk/; revision=3879
this obviates the need to add cleanup handlers for exceptions, if we
move a free call so that there are no tvbuff references between the
allocation and the free. Checking for that also found some cases where
frees were missing, and one loop where a call was made to allocate stuff
but the free was only done after the exit from the loop.
In cases where we can't move the free up above tvbuff references,
register cleanup handlers, and replace the free with
CLEANUP_CALL_AND_POP.
Eliminate some initializations of pointers to null - the initializations
aren't necessary (or ceased to be necessary after the frees were moved
up).
In the "force an exception" code in "get_CDR_octet_seq()", touch the
first byte after the string, to make it more likely that we'll throw the
correct exception (e.g., throw a "past end of captured data" exception
rather than a "past end of data" exception).
There's no need for "get_CDR_string()" to force an exception, as it just
calls "get_CDR_octet_seq()", which will do it for us.
However, as the result of "get_CDR_string()" is often processed as a
string, if the length is 0 it should just "g_strdup()" a null string,
rather than not doing anything (and relying on the pointer variable
being initialized to null). It's not always safe to treat a null
pointer as if it pointed to a string (in fact, it is often most
definitely unsafe).
svn path=/trunk/; revision=3878
Guy Harris