them in "packet-ncp2222.inc".
The page at
http://www.odyssea.com/whats_new/tcpipnet/tcpipnet.html
indicates that a positive ACK (0x9999) NCP packet has the same
completion code and connection status fields as a reply (0x3333) packet
(but nothing after them); hand "dissect_ncp_reply()" the packet type as
one of its arguments, and have it handle positive ACK packets as well as
reply packets.
It also indicates that bit 4 of the connection status indicates that the
server is unavailable, and the page at
http://www.unm.edu/~network/presentations/course/appendix/appendix_f/tsld088.htm
speaks of that and of the significance of other bits; put a comment in
"ncp2222.py", before the "hf_ncp_connection_status" field, about that.
From looking at a capture, it appears that a "destroy service
connection" (0x5555) packet should be treated like a "create service
connection" (0x1111) packet and be handed to "dissect_ncp_request()".
Note that perhaps watchdog packets should be handled by
"dissect_ncp_reply()" as well.
svn path=/trunk/; revision=5489
A little work still needs to be done on the new NCP dissector -- make
some of the COL_INFO texts more useful, handle a Unicode issue, and
modify some of the cases that use "request conditions".
But the NCP dissector as it stands is very usable now.
Note: I didn't merge in the PROTO_LENGTH_UNTIL_END macro... I wanted
to think about the various possible macros and review an email conversation
I had with Guy on the subject.
svn path=/trunk/; revision=5432
sub-trees, I added new functions to ptvcursor:
ptvcursor_add_no_advance()
ptvcursor_tvbuff()
ptvcursor_current_offset()
Note that no NCP type that actually uses bitfields has been
checked in yet.
svn path=/trunk/; revision=4509
variables wrap-around. Since the request/reply packets are related via
a hash based on these uniqueness variables, long NCP traces can
have mis-matches reqeust/reply records.
Thus, only do the hash-lookup for the reply packet during the first
sequential scan of the trace file. Once the pertinent info is found,
store it in the packet's private data area.
Since the memory allocated for the hash and for the structures that make
up the keys are no longer needed after the first sequential run through
the trace file, arrange to free that memory after the first sequential
run. Similar to the register_init_routine() that allows dissectors
to register callbacks for calling *before* a capture file is loaded,
set up a register_postseq_cleanup_routine() function that allows
dissectors to register callbacks for calling *after* the first
sequential run-through of the trace file is made. This is not
a *final* cleanup callback, since Ethereal will still have that trace file
open for random-access reading.
I didn't have tethereal call postseq_cleanup_all_protocols() since
tethereal doesn't keep the trace file open for random-access reading.
I could easily be swayed to make tethereal call that function, however.
svn path=/trunk/; revision=4484
structure to the "packet_info" structure; only stuff that's permanently
stored with each frame should be in the "frame_data" structure, and the
"column_info" structure is not guaranteed to hold the column values for
that frame at all times - it was only in the "frame_data" structure so
that it could be passed to dissectors, and, as all dissectors are now
passed a pointer to a "packet_info" structure, it could just as well be
put in the "packet_info" structure.
That saves memory, by shrinking the "frame_data" structure (there's one
of those per frame), and also lets us clean up the code a bit.
svn path=/trunk/; revision=4370
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
Guy Harris