"data source" has a name and a top-level tvbuff, and frames can have a
list of data sources associated with them.
Use the tvbuff pointer to determine which data source is the data source
for a given field; this means we don't have to worry about multiple data
sources with the same name - the only thing the name does is label the
notebook tab for the display of the data source, and label the hex dump
of the data source in print/Tethereal output.
Clean up a bunch of things discovered in the process of doing the above.
svn path=/trunk/; revision=4749
support for the "b" descriptor item in data, for pointers that point to
arrays of bytes - the descriptor item includes a byte count giving the
number of bytes in the array.
Handle the "logon hours" bitmask in that fashion.
Sometimes it appears that -1 means "unknown", and sometimes it appears
that 0 means "unknown", for the last logoff date/time; interpret both of
them as "unknown" (or "never").
svn path=/trunk/; revision=4612
wrong type.
Don't have routines that create subtrees for the data in a RAP reply -
just have a string for the name to give the subtree. Create the subtree
iff the reply has an entry count; if there's no name, use "Entries", and
if there's no ett_ value for it, use a generic one.
If there's no routine to create a subtreee for an entry in a RAP reply,
don't create the subtree - some entries have only one member, so there's
no point in creating a subtree for them. Provide an ett_ value to use
if we don't know what the entry looks like.
Properly terminate "lm_null_list[]".
Fix the tables for the NetUserGetInfo API.
Add tables for the NetUserGetGroups API.
Add #defines and names for all the APIs in the SNIA CIFS spec (but fix
up some of the names to reflect what the actual API names appear to be).
Display the RAP API number in decimal, not hex, for unknown APIs.
Use the right hf_ value when displaying the auxiliary data descriptor.
svn path=/trunk/; revision=4611
"epan/..." pathnames, so as to avoid collisions with header files in any
of the directories in which we look (e.g., "proto.h", as some other
package has its own "proto.h" file which it installs in the top-level
include directory).
Don't add "-I" flags to search "epan", as that's no longer necessary
(and we want includes of "epan" headers to fail if the "epan/" is left
out, so that we don't re-introduce includes lacking "epan/").
svn path=/trunk/; revision=4586
items to the protocol tree; it's interpreted as "the rest of the data in
the tvbuff". This can be used if
1) the item covers the entire packet or the remaining payload in
the packet
or
2) the item's length won't be known until it's dissected, and
will be then set with "proto_item_set_len()" - if an
exception is thrown in the dissection, it means the item ran
*past* the end of the tvbuff, so saying it runs to the end of
the tvbuff is reasonable.
Convert a number of "proto_tree_add_XXX()" calls using
"tvb_length_remaining()", values derived from the result of
"tvb_length()", or 0 (in the case of items whose length is unknown) to
use -1 instead (using 0 means that if an exception is thrown, selecting
the item highlights nothing; using -1 means it highlights all the data
for that item that's available).
In some places where "tvb_length()" or "tvb_length_remaining()" was used
to determine how large a packet is, use "tvb_reported_length()" or
"tvb_reported_length_remaining()", instead - the first two calls
indicate how much captured data was in the packet, the latter two calls
indicate how large the packet actually was (and the fact that using the
latter could cause BoundsError exceptions to be thrown is a feature - if
such an exception is thrown, the frame really *was* short, and it should
be tagged as such).
Replace some "proto_tree_add_XXX()" calls with equivalent
"proto_tree_add_item()" calls.
Fix some indentation.
svn path=/trunk/; revision=4578
"dissect_frame()" to indicate whether a ReportedBoundsError was due to
the packet being malformed (i.e., the packet was shorter than it's
supposed to be, so the dissector went past the end trying to extract
fields that were supposed to be there) or due to it not being
reassembled (i.e., the packet was fragmented, and we didn't reassemble
it, but just treated the first fragment as the entire packet, so the
dissector went past the end trying to extract fields that were partially
or completely in fragments after that). Mark the latter as being
unreasembled rather than malformed.
Properly initialize, save, and restore that field, and properly set it,
so that works.
svn path=/trunk/; revision=4555
the beginning, and to use underscores rather than periods where the
preference's name really isn't part of a hierarchical namespace.
Use "%u" rather than "%d" to print unsigned quantities.
svn path=/trunk/; revision=4543
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
"smb_saved_info_t" in the table of requests whose replies have been
found, don't look it up in the table of requests whose replies have not
been found - if the request in question has no reply in the capture,
that may find some later frame in the same conversation with the same
MID, and we don't need that information anyway - the only reason we
*need* that structure is to save information in it for use when
processing its reply, and we already did that the first time we
processed the request. (The information for the later frame may be bad,
e.g. having a null "extra_info" pointer, or having one that points to
information for another request.)
Arrange that we don't use the pointer to the "smb_saved_info_t" when
processing a request except to save information if the request hasn't
already been processed, as that pointer may not be valid if the request
has already been processed, as per the above.
svn path=/trunk/; revision=4292
Add some checks for null tvbuff arguments.
When dissecting transaction setup, parameters, and data when we couldn't
dissect it as a pipe or mailslot transaction, use the reported length of
the supplied tvbuff, not the actual length, as the amount of data
present.
svn path=/trunk/; revision=4291
indicate that it's to be used for SMB transactions; a different table,
using different dissectors, would be needed for, say, reads and writes
over a named pipe, as those are byte streams and SMB transactions are
packets, so the dissectors for the first one need to worry about
multiple PDUs per segment and desegmentation, while the dissectors for
the second one don't - and, in fact, can't do desegmentation stuff.
svn path=/trunk/; revision=4286
if (and only if) the length of the item being added is 0 (so that it has
no data backing it).
This means the data stream name pointer for the item in question is
null; make sure we handle that.
Use that for some "uses the value from the matching request" fields in
the SMB Pipe protocol.
svn path=/trunk/; revision=4231
routines used for that.
Rename some named pipe functions as per the SNIA CIFS spec.
Label the "number of files moved" field of the reply to a Move SMB as
such, rather than as an unspecified "Count".
svn path=/trunk/; revision=4229
obviates the need to have a protocol tree item for "MSRPC-over-SMB", as
the setup words for it are just standard TransactNmPipe setup words
(0x26 is the TransactNmPipe function code, and the next setup word is
the FID for the pipe in question.)
Pass to the pipe dissector tvbuffs for setup-words-plus-pipe (which is
the data for the pipe protocol) and parameters-plus-data (which is the
data for the protocol running atop the pipe protocol); use the former
for the top-level protocol tree item for the pipe protocol, and the
latter for the top-level protocol tree item for the LANMAN protocol.
svn path=/trunk/; revision=4223
mailslot-based logon protocols just be regular register routines,
detected by the script that generates the "register.c" file, rather than
special stuff known to the SMB dissector.
svn path=/trunk/; revision=4222
"dissect_pipe_smb()", a tvbuff containing the setup words and the
pipe/mailslot pathname, as those are arguably the part of the packet
that contains the "mailslot protocol" and the "pipe protocol", as
opposed to the protocol running atop mailslots or pipes.
Pass a setup tvbuff to "dissect_pipe_smb()" for it to pass on to the
MSRPC-over-named-pipe dissector, and have the setup tvbuff passed to it
and "dissect_mailslot_smb()" contain *only* the setup words; don't
extract anything other than the setup words from it.
Declare "register_proto_smb_mailslot()" in "packet-smb-mailslot.h"
rather than "packet-smb.c", and declare "register_proto_smb_pipe()" in
"packet-smb-pipe.h" rather than "packet-smb.c".
Add a protocol for MSRPC-over-named-pipes.
Move the stuff to handle the FID in the setup words of
MSRPC-over-named-pipe transactions out of the SMB Transaction dissector
into the MSRPC dissector. Add a routine to "packet-smb.c", callable
from outside "packet-smb.c", to put an "smb.fid" field into the protocol
tree, and to add ", FID: XXXX" to the Info column, for use by the
MSRPC-over-named-pipe dissector; use it in the SMB dissector as well, in
all the places where we put a FID into the protocol tree.
Move the stuff to check whether the LANMAN protocol is enabled, and to
set "pinfo->current_proto" to "LANMAN" if it is, into the LANMAN
API-over-named-pipe dissector out of the named pipe protocol dissector.
If we didn't dissect a Transaction request or reply as a named pipe or
mailslot message, put any setup words, parameters, and data it has into
the protocol tree as separate items.
Don't put a "Response in" item into the protocol tree for an NT Cancel
request, as there are no responses to NT Cancel requests.
svn path=/trunk/; revision=4221
structure, so that it can be updated by subdissectors; this way the
updates affect the structure immediately, and don't get lost if the
subdissector later throws an exception.
Use "tvb_reported_length()" to check for an interim mailslot reply;
"tvb_length()" could give the wrong answer if a short snapshot length
was given in the capture.
svn path=/trunk/; revision=4218
"smb_saved_info_t". Put all the information needed to dissect NT
Transaction replies, Transaction2 replies, or Transaction replies into
separate data structures, allocated separately, and put a pointer to
that data structure in the "void *" in question.
Use the return value of "dissect_pipe_smb()" and
"dissect_mailslot_smb()" to control whether to display as data the stuff
those routines were asked to dissect.
If we've seen a request before, but its "smb_saved_info_t" isn't in the
"matched" hash table, look in the "unmatched" hash table - perhaps we
haven't seen the reply yet.
svn path=/trunk/; revision=4216
Get rid of "Response to" stuff in the LANMAN dissector, as that's now
done in the SMB dissector.
Add a routine for dissecting unknown SMBs (gets the word and byte
counts, and just adds text entries for the word and byte parameters, if
any), and replace null pointers in the dissector table with pointers to
that routine. Get rid of the check for a null dissector pointer.
svn path=/trunk/; revision=4212
formatting the string as text.
In "add_pointer_param()", make the offset in the text item for the
string the offset in the string area, not the offset of the pointer
itself.
Fix some items in item lists to have "lm_null" rather than a null
pointer, so that if we don't find an entry for the detail level, we
don't blow up dereferencing a null pointer, we just dissect all the
items based on the type in the descriptor string.
If we don't have a data descriptor for response data, just put in an
entry for the data; that may happen if we only dissected part of the
request to which the stuff we're dissecting is a reply, e.g. because the
snapshot length didn't let us capture all of the request.
svn path=/trunk/; revision=4085
aux_count_p value was NULL the program would SIGSEGV when *aux_count_p
was initially set to 0. Added NULL pointer test.
svn path=/trunk/; revision=4036
Protocol", not just the "Microsoft Windows Lanman Protocol"; LAN Manager
had a number of protocols layered atop SMB, and this is the one used for
remote execution of various APIs.
svn path=/trunk/; revision=3872
sense; instead, it's a "multiplex ID" used when there's more than one
request *currently* in flight, to distinguish replies.
This means that the MID and PID don't uniquely identify a request in
a conversation.
Therefore, we have to use some other value to distinguish between
requests with the same MID and PID.
Add a mechanism to do so.
svn path=/trunk/; revision=3829
places) dissector tvbuffified, from Ronnie Sahlberg and me.
Additional "are we past the end of the buffer" checks added, so that we
don't hand random junk to the transaction and transact2 dissectors.
svn path=/trunk/; revision=3824
that rather than passing another copy of that flag to dissectors of
particular messages.
Pass that structure to the pipe subdissector by making "pi.private"
point to it, rather than by passing it as an explicit argument.
Change more of the
if (dirn == 1) {
...
}
if (dirn == 0) {
...
}
stuff to
if (dirn == 1) {
...
} else {
...
}
and then, as per the first paragraph, check the "request" flag in the
"smb_info" structure rather than checking a "dirn" flag.
Set "last_transact2_command" to -1 in the "smb_request_val" structures
for TRANSACTION requests, as it doesn't apply to those requests.
As "dissect_transact_params()" doesn't do any work if the "TransactName"
argument is null, don't bother calling it for a reply if we don't have an
"smb_request_val" for the corresponding request, as that means we can't
find out the value to pass as the "TransactName" argument.
svn path=/trunk/; revision=3822
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