"value_string" array, do it the right way, by using "val_to_str()" - the
PDU type is 4 bits, but there aren't 16 entries in the array, so a bogus
PDU type (*don't* assume that can't happen...) can cause a core dump.
svn path=/trunk/; revision=3169
Tvbuffers changed to added the data source name,
GUI and printing code changed to support these changes
and display the multiple hex views.
svn path=/trunk/; revision=3165
organizes the protocols in the same hierarchical order in which
they are found in the packet.
The GUI needs some more refinement (placment of vertical
scrollbar, style of GtkCTree, initial sizing of window).
I need to add an option to honor/not honor the current display filter.
svn path=/trunk/; revision=3162
frame per-frame data indicating
1) what type of transaction it's a reply to
and
2) whether it's the first reply or a continuation reply
as the information supplied by the SMB dissector can only be trusted on
the first pass through the capture.
(If you have two different transactions in the *same* conversation with
the *same* MID, but different transaction types, only on the first pass
will the transaction type in the data structure pointed to by
"si.request_val" reflect the previous request - it reflects the last
request seen which, when the user is clicking on frames in the capture,
needn't be the request corresponding to the reply that they've just
clicked on.
If you have a reply that consists of multiple SMBs,
"si.request_val->trans_response_seen" will be set to 1 as soon as the
first reply is seen, and will *remain* 1 until the request is seen
again; if the user clicks on one of the SMBs in the reply, even if it's
the first SMB in the reply, without having first clicked on the request,
"si.request_val->trans_response_seen" will be 1, and the SMB will be
misdissected as a continuation.)
Use common code to handle the beginning of LANMAN replies, rather than
duplicating it in the code to handle each reply.
svn path=/trunk/; revision=3154
Use "loc_offset" even for the function code in a response (it probably
shouldn't matter, as the function code isn't actually *in* the
response), and set "loc_offset" to SMB_offset in an interim reply.
svn path=/trunk/; revision=3151
request to which it's a response.
Compute the offset of the LANMAN data before putting *any* entries into
the tree, rather than using 0 as the offset for the top-level item for a
response.
svn path=/trunk/; revision=3150
into a "packet-smb-browse.h" header file, and have modules that import
those routines include "packet-smb-browse.h" rather than declaring the
routines themselves; do the same for routines exported from
"packet-smb-logon.c".
Make routines and arrays not exported static, and make routines that
return a true/false return value "gboolean" rather than "guint32".
svn path=/trunk/; revision=3147
Move the declaration of routines exported from "packet-smb-mailslot.c"
into a "packet-smb-mailslot.h" header file, and have modules that import
those routines include "packet-smb-mailslot.h" rather than declaring the
routines themselves; do the same for routines exported from
"packet-smb-pipe.c". Make routines not exported static, and make
routines that return a true/false return value "gboolean" rather than
"guint32".
svn path=/trunk/; revision=3146
There's no need to clear the Info column right before setting it; we
don't use any information from the packet other than stuff we've already
determined is there (as part of the heuristic test for a DCE RPC
packet), so there's no risk that we'll throw an exception before the
Info column is set.
Use "col_set_str()", rather than "col_add_str()" or "col_add_fstr()", to
set the Protocol and Info columns.
svn path=/trunk/; revision=3145
has - or, if it does, it's not "MoveFile()", and "rename()" doesn't use
it, so you have to make sure the target of a rename doesn't exist before
doing the rename.
svn path=/trunk/; revision=3134
DLT_HDLC to it.
Make a separate dissector for Cisco HDLC, and add a dissector for Cisco
SLARP. Have the PPP dissector call the Cisco HDLC dissector if the
address field is the Cisco HDLC unicast or multicast address. Use the
Cisco HDLC dissector for the Cisco HDLC Wiretap encapsulation type.
Add a new dissector table "chdlctype", for Cisco HDLC packet types
(they're *almost* the same as Ethernet types, but 0x8035 is SLARP, not
Reverse ARP, and 0x2000 is the Cisco Discovery protocol, for example),
replacing "fr.chdlc".
Have a "chdlctype()" routine, similar to "ethertype()", used both by the
Cisco HDLC and Frame Relay dissectors. Have a "chdlc_vals[]"
"value_string" table for Cisco HDLC types and protocol names. Split the
packet type field in the Frame Relay dissector into separate SNAP and
Cisco HDLC fields, and give them the Ethernet type and Cisco HDLC type
"value_string" tables, respectively.
svn path=/trunk/; revision=3133
throw an exception.
Fix a comment to reflect that the "location", "info", and
"make-and-model" fields are optional (CUPS 1.0[.x] didn't put them into
its browse packets).
svn path=/trunk/; revision=3132
In the CLNP dissector, set the source and destination network-layer and
"top-level" addresses; this will cause them to show up in the source and
destination columns of the summary display if you're showing the
network-layer or top-level address (although you'll probably have to
widen those columns significantly to see the entire address), and also
makes them available to subdissectors.
svn path=/trunk/; revision=3131
bitfields.
Rename "get_space()" to "skip_space()", to indicate what it does, and
have it return FALSE if the first non-blank character it found was a CR
or LF (meaning "end of packet"). If it returns FALSE, stop dissecting
the packet.
In "get_unquoted_string()", search not only for a space, but also for a
tab, CR, or LF; there is no guarantee that there will be any fields in
the packet past the URI (CUPS 1.0[.x] didn't put anything after the URI,
and that's what I'm running on my machine...).
svn path=/trunk/; revision=3130
beginning of the file before reading anything from the file is bogus -
do that in the loop that tries each of the open routines, instead.
(They may have to reset the seek pointer later if, for example, the
capture file begins with the first packet, and the "open()" routine
looks at that packet to try to guess whether the packet is in the file
format in question.)
Set "wth->data_offset" to 0 while you're at it, so capture file readers
don't have to do that, either.
svn path=/trunk/; revision=3123