Ethereal-cvs: [Ethereal-cvs] cvs commit: ethereal ncp2222.py packet-ncp-int.h packet-ncp.c pac
gram 2002/02/24 14:42:43 CST
Modified files: (Branch: Novell_NCP_branch)
. ncp2222.py packet-ncp-int.h packet-ncp.c
packet-ncp2222.inc ptvcursor.c
ptvcursor.h
Log:
Add "Request Condition" support to NCP decodes. This allows fields
in the Reply packet to be either dissected or not depending on a condition
in the Request packet. This is implemented in the NCP dissector
by using Ethereal's built-in method of analyzing packets --- dfilters.
The Reply packet actually has a constant size, with space for all
the fields that are "conditonally present". But fields which
are "not present" contain junk (or in the traces I have, zeroes)
without meaning. So it's preferrable not to decode them because
their values are meaningless. Only the fields which are "conditionally
present" are decoded.
For instance, in ncp2222.py, you can define a Reply packet as
having an AttributesStruct IFF the Request packet has the Mask attribute
in the ReturnInfo bitfield set via:
srec( AttributesStruct, req_cond="ncp.ret_info_mask_attr == TRUE" )
An interesting result is that the NCP dissector, when dissecting
NCP Requests whose fields need to be dfiltered, *needs* a proto_tree
during the first sequential pass through the packets.
If proto_tree is NULL during the first run, a temporary proto_tree
is created in the ncp2222 dissector so that dfiltering can work.
Once it's not needed, it is freed. CLEANUP_*() routines are
set so that if an exception occurs during dissection, the temporary
proto_tree is indeed freed.
In addition to the changes in ncp2222.py and packet-ncp2222.in to
support this, these changes were also made in support of Request Conditions:
The ncp_hash routines were moved from packet-ncp.c to packet-ncp2222.inc,
because that's the only code that uses the ncp_hash routines.
Removed the ncp.initial_hash_size user preference. It seemed out of
place to have a user preference which didn't have anything to do with
packet decoding, but rather dissector memory allocation.
ptvcursor_advance() was added to ptvcursor.[ch]. It advances the
offset within the tvbuff w/o actually adding anything to the
proto_tree. It uses the reported length, not any length got from
a tvbuff (like from FT_UINT_STRING or FT_STRINGZ), because at least
in our case, we can't use any fields like that because the data
contains junk anyway. We can only rely on reported lengths. This means
that any fields which are "conditionally present" have fixed lengths.
Allow dissectors to register a "final registration routine"
during their init() routine. These final registration routines
are called as the final step of epan_init(). This is
necessary because during ncp2222's registration, display filters
used in "Request Conditions" need to be compiled; it's a one-time
thing that doesn't need to be done for each capture file.
However, display filters cannot be compiled during the proto_init()
step, because epan_init() has not called dfilter_init(), so the dfilter
structures are not set up. Once the dfilter structures are set up, *then*
display filters can be compiled.
The loop in epan.c to prime the proto_tree with "interesting"
fields from the dfilter was moved to the dfilter code itself. The epan
code is no longer the only caller of this routine; the ncp2222
dissector has to prime the Request packet proto_tree before running
the dfilter in order to process the "request conditions".
The tvbuff argument from dfilter_apply() and dfvm_apply() was
removed; it was never used! When I re-wrote the dfilter code, I
apparently thought I needed the tvbuff, but ended up not needing it.
Revision Changes Path
1.14.2.8 +129 -20 ethereal/ncp2222.py
1.6.2.3 +3 -7 ethereal/packet-ncp-int.h
1.55.2.1 +2 -120 ethereal/packet-ncp.c
1.8.2.4 +365 -64 ethereal/packet-ncp2222.inc
1.5.2.1 +9 -1 ethereal/ptvcursor.c
1.5.2.2 +6 -1 ethereal/ptvcursor.h
