| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
dissectors to be registered as dissectors for particular ports,
registered as heuristic dissectors, and registered as dissectors for
conversations, and have routines to be used both by old-style and
new-style dissectors to call registered dissectors.
Have the code that calls those dissectors translate the arguments as
necessary. (For conversation dissectors, replace
"find_conversation_dissector()", which just returns a pointer to the
dissector, with "old_try_conversation_dissector()" and
"try_conversation_dissector()", which actually call the dissector, so
that there's a single place at which we can do that translation. Also
make "dissector_lookup()" static and, instead of calling it and, if it
returns a non-null pointer, calling that dissector, just use
"old_dissector_try_port()" or "dissector_try_port()", for the same
reason.)
This allows some dissectors that took old-style arguments and
immediately translated them to new-style arguments to just take
new-style arguments; make them do so. It also allows some new-style
dissectors not to have to translate arguments before calling routines to
look up and call dissectors; make them not do so.
Get rid of checks for too-short frames in new-style dissectors - the
tvbuff code does those checks for you.
Give the routines to register old-style dissectors, and to call
dissectors from old-style dissectors, names beginning with "old_", with
the routines for new-style dissectors not having the "old_". Update the
dissectors that use those routines appropriately.
Rename "dissect_data()" to "old_dissect_data()", and
"dissect_data_tvb()" to "dissect_data()".
svn path=/trunk/; revision=2218
|
|
with conversations and having TCP and UDP check whether a packet is part
of a conversation with a dissector and, if so, using that dissector on
the conversation, and "ethertype()"-style support for allowing a
dissector to call a sub-dissector via the same path that the TCP and UDP
dissectors use, based on port numbers supplied by that dissector.
svn path=/trunk/; revision=1837
|
|
svn path=/trunk/; revision=1421
|
|
svn path=/trunk/; revision=945
|
|
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
|
|
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
|
