Microsoft's pile of protocol documentation is probably the best place to
start now that it exists.
Change-Id: I2580379562cb664f3d00473f6be6313306682b89
Reviewed-on: https://code.wireshark.org/review/33524
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, even if we're not building a protocol tree, so that you don't
get protocol tree items, you can get the display string, e.g. to use in
a column.
Replace the use of the "get display string" routines with calls to those
routines.
Change-Id: I23e3e88838bdf837d8660c271f78c79b7d1c5620
Reviewed-on: https://code.wireshark.org/review/33519
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The extra stuff done by that routine isn't needed for SMB2 strings,
which are always aligned on a 2-byte boundary if they're Unicode
strings. Just choosing the right type (FT_STRING or FT_STRINGZ) and
using proto_tree_add_item() - or proto_tree_add_item_ret_string() if the
string value is required - suffices. Using
proto_string_item_get_display_string() means we don't need the string
value in most cases.
Update and move a URL, putting Microsoft's references at the top of the
list of documentation links, and adding MS-FSCC.
Make the string fields STR_UNICODE.
Change-Id: Iad1a31dacad93e7b5ad43033c740fa00abbe86e7
Reviewed-on: https://code.wireshark.org/review/33518
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add a BASE_SHOW_ASCII_PRINTABLE flag for the "display" field, to use
with FT_BYTES and FT_UINT_BYTES fields; it specifies that, if the field
consists solely of printable ASCII characters, its value be displayed as
a string, in quotes. Have a routine hfinfo_format_bytes() to do that
formatting, depending on the display field value.
Add routines to fetch the display value of string and
FT_BYTES/FT_UINT_BYTES fields; for strings, it's the result of
hfinfo_format_text(), and for byte arrays, it's the result of
hfinfo_format_bytes().
Use BASE_SHOW_ASCII_PRINTABLE for extended attribute data in SMB and
SMB2. Use the routines in question for extended attribute names
(string) and data (bytes). That keeps us from displaying non-text
extended attribute data as if it were text.
Document BASE_SHOW_ASCII_PRINTABLE.
Change-Id: I24dcf459c14f00985e4daaf9b58f5933964eabd8
Reviewed-on: https://code.wireshark.org/review/33517
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
packet-sysex.c:753:1: warning: no previous prototype for function 'proto_reg_handoff_sysex' [-Wmissing-prototypes]
Change-Id: I6e78abe0686818dec1c915d4e77c5f84b43f6460
Reviewed-on: https://code.wireshark.org/review/33509
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
packet-dcom-provideclassinfo.c:32:5: warning: no previous prototype for function 'dissect_IProvideClassInfo_GetClassInfo_rqst' [-Wmissing-prototypes]
packet-dcom-provideclassinfo.c:40:5: warning: no previous prototype for function 'dissect_IProvideClassInfo_GetClassInfo_resp' [-Wmissing-prototypes]
Change-Id: I0d4b4f4cf5e3d5d3612a6e01c71dbbfc3a14915f
Reviewed-on: https://code.wireshark.org/review/33508
Reviewed-by: Anders Broman <a.broman58@gmail.com>
packet-dcm.c:3888:6: warning: no previous prototype for function 'col_set_str_conditional' [-Wmissing-prototypes]
packet-dcm.c:3901:6: warning: no previous prototype for function 'col_append_str_conditional' [-Wmissing-prototypes]
Change-Id: I26117b8c3bcb0f88889edd7de5044e57dd0c4b38
Reviewed-on: https://code.wireshark.org/review/33507
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Add a "_loop" header field also when processing attributes
Change-Id: I109b34d8f6cb8fbf3c38dc09f58b740b4d96436b
Reviewed-on: https://code.wireshark.org/review/33460
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
While the actual power parameters are vendor specific and can't be
dissected the mere _presence_ of the MS/BS Power Parameters IE itself is
rather important, since it implies that dynamic MS/BS power control is
active, and does therefore have an impact upon the interpretation of the
(preceding) MS/BS Power IE, too.
Change-Id: I0c6f73ca41d63887a52dcde05b59d5177971f1d0
Reviewed-on: https://code.wireshark.org/review/33439
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Display the default strings in all contexts where usb.bDescriptor is used.
Change-Id: I9f4479ccc0664585fc259927c0b2ee1149b02454
Reviewed-on: https://code.wireshark.org/review/33368
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
By providing such a file, we give the users a basic toolbox
of macros. At the moment 3 macros have been added, for private
mac addresses, as well al IP v4 and v6.
Change-Id: Icc33efce437adef00e268172c184c8b52167df23
Reviewed-on: https://code.wireshark.org/review/33449
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
the 'x_octetx' variables were removed a few years back, replace them with get_CDR_xxx()
Change-Id: I8cf3410d8a152c834e7019f7d1d80de3798530c3
Reviewed-on: https://code.wireshark.org/review/33457
Reviewed-by: Gerald Combs <gerald@wireshark.org>
add a mode to ignore a few optimisations in favor of working output
Change-Id: I875cec5a80e9449e9fd954d4ff6a21e5b128db5e
Reviewed-on: https://code.wireshark.org/review/33459
Reviewed-by: Gerald Combs <gerald@wireshark.org>
wireshark_gen goes into an infinite recursion if it encounters a multi-level
alias, this is prevented
Change-Id: Icec678fb326b7c14344dc6df51015dad980587a9
Reviewed-on: https://code.wireshark.org/review/33458
Reviewed-by: Gerald Combs <gerald@wireshark.org>
convert the "DEBUG" constant to a command line parameter
Change-Id: I7f873d85fa053cb9298bd03444125d0160ef4640
Reviewed-on: https://code.wireshark.org/review/33456
Reviewed-by: Gerald Combs <gerald@wireshark.org>
The code can be called by the GUI, outside of the scope validity.
Bug: 15810
Change-Id: I1f394cb3d1f978d6e99fe15d8238153aad62ebee
Reviewed-on: https://code.wireshark.org/review/33499
Petri-Dish: Pascal Quantin <pascal@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal@wireshark.org>
Reviewed-by: Dario Lombardo <lomato@gmail.com>
This reverts commit 13c5960a2c.
Based on the features that needs integration of "multi-selection" (which this change introduced), it seems that there will be fair amount time and code changes required in packet_list.cpp and possibly other files.
I am reverting this change from the master branch so that people can still continue to use features with single-selection.
Meanwhile, Stig B and others ready to test can import this change to verify which features are missing integration and/or integrated correctly. Once the feature set integration is complete and there is fair amount of approval from all of you, the core committers can decide on it.
Change-Id: I106fd3c54350dd0fd85fc44743e7f5321cb04110
Reviewed-on: https://code.wireshark.org/review/33454
Petri-Dish: Stig Bjørlykke <stig@bjorlykke.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Update dissect_iso7816_class() to return 1 only if both APDU structure
and coding are compliant with ISO 7816. In this case, the iso7816 dissector
can continue dissecting the APDU.
Change-Id: I73d4246fbc234779fceb337c788dd0b680102d61
Reviewed-on: https://code.wireshark.org/review/33480
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Some of the range strings for the ISO 7816 class byte were not correct.
Update them to match the ISO 7816 specification.
Change-Id: Ieae7baac7e2428293525dd940eddc6bf5406a446
Reviewed-on: https://code.wireshark.org/review/33479
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Check whether the byte count includes the padding before skipping it; it
may not be present (at least not if this is at the end of the byte
parameters).
Change-Id: I4385a4713cb6813a6e8519005288d6ef5a28f028
Reviewed-on: https://code.wireshark.org/review/33493
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The file name doesn't appear to be padded, and may have a 1-byte null
terminator (yes, 1 byte, according to MS-CIFS) at the end, not included
in the file name length.
Change-Id: I8510434b3b5aec092290697c336924d6ff6be763
Reviewed-on: https://code.wireshark.org/review/33486
Reviewed-by: Guy Harris <guy@alum.mit.edu>
According to MS-CIFS:
1) the file name is not one of those "buffer format followed by
a string" fields, it's just a string, so there's no buffer
format field;
2) it's always in ASCII, so ignore the "Unicode strings" flag.
Note that, for the *request*, the *directory* name isn't claimed to
always be ASCII, so honor the "Unicode strings" flag there.
Change-Id: I495b7be8257d941ccf4b45126a44d25cf0ab2c12
Reviewed-on: https://code.wireshark.org/review/33482
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Sometimes there appears to be an extra byte before that field; try to
catch some of those cases.
Expand comments discussing various weirdness with that field, including
a note that clients might not pay any attention to it, so maybe we just
have buggy servers talking to clients that don't care about those
particular bugs.
Change-Id: I4d35d2e2c475d4da37debedfed31b891e6f3cfa8
Reviewed-on: https://code.wireshark.org/review/33481
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Note, for all of the different word count values, what protocol or
protocols it represents.
(If we have the Negotiate request, and can thus determine which protocol
was selected based on the set of protocols the client was willing to
accept, should we verify that the server selected a protocol for which
the given word count value was used, and add an expert info if it
didn't?)
Change-Id: I95ad4b1245bf2a04fdef4746815352967d8ac0a6
Reviewed-on: https://code.wireshark.org/review/33475
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It *should*, but a malicious or otherwise malformed packet might not
have them. One of them is the file name length; if it's missing, we
can't dissect the file name, as we don't know how long it is.
Change-Id: Ie259e2d8ec65f5d53d466382d89889902495d2c8
Reviewed-on: https://code.wireshark.org/review/33467
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Display the data in a PLP chunk as just raw bytes, and reassembled all
the chunks and extract the value from the reassembled data.
Showing the chunks as strings doesn't necessarily work - if the string
is an NVarChar string, a chunk might well have an odd number of octets,
meaning you're splitting one of the 16-bit UTF-16LE items in half.
Reassembling handles that, as well as just, in general, showing the
actual value rather than pieces of the value.
If the column is a string, append its value to the top-level item, just
as we do for non-PLP strings.
Also, if a length value was specified, report an error if it doesn't
match the total length of the reassembled chunks.
Change-Id: Iab80da052eb363ee08cd518afbe2556a5ab740b9
Reviewed-on: https://code.wireshark.org/review/33466
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Starting from ArubaOS 8.6.0.0 all 11n, 11ac and 11ax APs are
expected to support type 6 ap packet captures which will be
decoded using the radiotap dissector.
Change-Id: If9e9488271965116e807adbbcf92b9c5e4fb2ac4
Reviewed-on: https://code.wireshark.org/review/33451
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Add dissector for all messages of Bluetooth Mesh Foundation models.
Bug: 15797
Change-Id: Ife831fe24bbbcaf2e99c9bff69b24c0d4fe2d1de
Reviewed-on: https://code.wireshark.org/review/33361
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jonas Jonsson <jonas@ludd.ltu.se>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Dissect the two parameter bytes p1 and p2 for the read record message.
Usually, p1 contains the record number and p2 defines that we want to
read exactly this record in the currently selected file.
Change-Id: I34586d6cfd4293120416507ef1613b9f3278d0df
Reviewed-on: https://code.wireshark.org/review/33448
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Petri-Dish: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Remove the plural. The specification documents use "read record" as well.
Change-Id: Ib7a77f33e2bb0c59720be3e8e89da6be1cd9afd0
Reviewed-on: https://code.wireshark.org/review/33447
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Dario Lombardo
Eric Wild