Fix a bug in the dissection of multiple NDS messages being sent
at the same time that the dissector was attempting to desegment
data spanning multiple packets. When a message was encountered
during the desegmentation code the dissector would
misinterpret the new message as an element in the data stream.
Code was added to validate the desegmentation handle and
validate which messages actually contain segmented data.
svn path=/trunk/; revision=11147
column, and we need stuff from the protocol tree for the Info column.
Go back to the previous scheme for constructing the Info column; the
previous change fixes the problems for which the Info column changes
were fixes.
svn path=/trunk/; revision=8526
1. Some NCP's that displayed the file/directory path in the
summary window would display blank lines on Windows based
machines. This was due to unicode or non-displayable
characters contained in the character string being added to
the column data. I made a change to format/strip out
non-displayable characters prior to adding to the column
data.
2. Moved ncp_req_hash_value struct to packet-ncp-int.h so that
I can use it within a future dissector (NMAS).
Clean up white space.
svn path=/trunk/; revision=7560
1. Secret Store Services (NCP 94) (ncp2222.py)
2. NMAS (NCP 92) (ncp2222.py)
3. NDS information in summary screen (packet-ncp.c & packet-ncp2222.inc)
4. Sever broadcast packets (NCP type 0xbbbb) to notify workstation to clear op-lock (packet-ncp.c)
5. Large Internet Packets (LIP) (packet-ncp.c)
6. Unicode Support. (unicode_to_string function in packet-ncp2222.inc & ncp2222.py)
svn path=/trunk/; revision=6069
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
- add <stdarg.h> or <varargs.h> in snprintf.h
and remove those inclusions in the other #ifdef NEED_SNPRINTF_H codes
- remove the check of multiple inclusions in source (.c) code
(there is a bit loss of _cpp_ performance, but I prefer the gain of
code reading and maintenance; and nowadays, disk caches and VM are
correctly optimized ;-).
- protect all (well almost) header files against multiple inclusions
- add header (i.e. GPL license) in some include files
- reorganize a bit the way header files are included:
First:
#include <system_include_files>
#include <external_package_include_files (e.g. gtk, glib etc.)>
Then
#include "ethereal_include_files"
with the correct HAVE_XXX or NEED_XXX protections.
- add some HAVE_XXX checks before including some system header files
- add the same HAVE_XXX in wiretap as in ethereal
Please forgive me, if I break something (I've only compiled and regression
tested on Linux).
svn path=/trunk/; revision=2254
a framework for the dissector; of the more than 400 NCP packet types, only
a handful are defined. But this dissector framework is much better than
the previous one.
svn path=/trunk/; revision=2173
Guy Harris