One of the other main reasons is that some users switch between different
versions of Wireshark and if a preference has been "removed" (not registered as
obsolete) the preferences file will be modified to have that preference
removed, which would result in it being restored to a "default" value
Using proto data "works" and I believe is used in a few places, but is not a
preferred solution because it makes "dissector flow" much harder to follow and
maintenance more difficult. I have spend some time converting dissectors to
pass dissector data directly instead of using proto data. I'm n
If you would like to use the CRC24 calculation from packet-gprs-llc.c, my
recommendation would be to move it to a new crc24.[c|h] file in /wsutil and
probably a crc24-tvb.[c|h] in /epan directory. As you can see from the other
CRC files, there isn't always a single "standard" way to calculate a
What is the format of the IEEE-1722 "CAN message"? From my experience there
are many different formats for CAN, so I think it's abstracted as best it can
be. The SocketCAN "packet format" isCAN ID (4 bytes). Since CAN IDs are
typically 11 or 29-bits, SocketCAN uses some of the higher bits for
There are a number of dissector tables used, so I thought the TAGs and Extended
TAGs could be moved around. You would just have to move
thedissector_add_uint("wlan.tag.number", …
along with the function.
If enums/value_strings need to be shared for breaking the dissector up into
multiple files,
len - Checks the string length of "string types" (FT_STRING, FT_STRINGZ,
FT_UINT_STRING, FT_STRINGZPAD) or array length of "byte types" (FT_BYTES,
FT_UINT_BYTES) and does a compare.
Examples:len(smpp.message_id) > 10len(smpp.message) > 25
size - Checks the size of the field in a packet. Can be
My objection to using p_proto_add_data in the particular case (passing data
between dissectors) is that it makes the code/flow much harder to read and
mistakes can result (usually found through fuzztesting) because the data flow
isn't obvious. I think the most "common" case is still a dissecto
What features of C++11 and 14 do you plan to use and where? I know we've had
the C vs C++ discussion before and I'd still vote for keeping things where they
are as far as "GUI" is C++ and epan + dissectors (i.e. libwireshark) as C. I'm
a little more indifferent to the "peripherals"/tools. Ot
I'd just reopen the existing bug.
-Original Message-
From: Thomas Wiens
To: wireshark-dev
Sent: Mon, Jan 15, 2018 12:51 pm
Subject: Re: [Wireshark-dev] Subtree expand/collapse tracking
On 13.01.2018 08:31, Roland Knall wrote:> Could you create a bug entry for
this, including an exa
I've been working on converting a lot of the Qt GUI that uses QTreeWidgetItem
into using a model/view architecture that better separates data from GUI. Some
of the dialogs I've converted have a simple tree/leaf architecture that lends
itself to creating a simple "data" class that holds the par
Mališa,
I think you are approaching this correctly in making OSCORE a separate protocol
for now. The deciding point may be overall size of "OSCORE only" code and how
much of the CoAP dissector API you have to put in a header file. Remember
dissectors don't always equal protocols, so you may
Well it was nice of you to break it ;)
See https://code.wireshark.org/review/24885.
I had a heck of time hunting this down. Part of the problem was that I had
(capture) preferences changed (capture.real_time_update) and I'm not sure how
they were changed. Not sure if the bug created befor
t what
happens with multiple tags when just one gets merged?
Just curious, if anyone knows...
On Mon, Nov 13, 2017 at 8:00 PM, Michael Mann via Wireshark-dev
wrote:
You need separate line for each bug, ie.
Bug: 12345
Bug: 12346
Bug: 12347
When you do that on the initial push, gerrit will ma
You need separate line for each bug, ie.
Bug: 12345
Bug: 12346
Bug: 12347
When you do that on the initial push, gerrit will mark the bugs. If you do it
after the initial commit, the bugs will only be notified when patch is
submitted to master.
The ability for Gerrit to actually move bug to
I'm having the same problem. https://code.wireshark.org/review/24080/ fixed
it for me.
-Original Message-
From: Paul Offord
To: Developer support list for Wireshark
Sent: Thu, Oct 26, 2017 1:15 pm
Subject: [Wireshark-dev] MASTER wsutil.lib won't build
Hi,
I’m building Wires
If you create separate dissector handles with a protocol, how is a user using
"Decode As" functionality supposed to know which dissection function will be
picked? That's why the check was added.
You can have the same protocol ID between TCP and UDP, but you can't have the
same one twice in TCP
-Original Message-
From: Richard Sharpe
To: Developer support list for Wireshark
Sent: Sat, Oct 14, 2017 1:47 pm
Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11 in
other dissectors ...
> Hi folks,
>
> I am almost finished a dissector for the IEEE1905 M
There's also this explanation:
https://www.wireshark.org/lists/wireshark-dev/201701/msg5.html
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Fri, Oct 6, 2017 3:06 am
Subject: Re: [Wireshark-dev] : avoid appending multiple times to
Description beyond the filename? No.
But I'd turn it around and ask "what kind of dissector are you trying to make"?
If its a protocol that runs over TCP or UDP, we can probably point you to some
of the "simpler" ones to get started. There are also many dissectors for other
underlying layer
I would agree that a dissector table for the GUIDs is probably the best way to
go. I also just created a GUID dissector table in my recent work with Netmon.
grep "netmon.provider_id" for example of how to setup a GUID dissector table
(it's much more straightforward than the DCE/RPC one)
--
Juan Jose,
Pascal is correct that you need to setup a dissector table, but you also need
to set and register a "decode as structure" (decode_as_t) using
register_decode_as.
Your "RTPS payload" should fall into one of 2 categories:
1. You have a "unique identifier" that determines how to di
I would have blamed having logic under pinfo->fd->flags.visited, but since
Wireshark does 2 passes (one with visited = FALSE, other visited = TRUE), your
columns should never be populated. Subsequent dissection from changing display
filters will continue to have pinfo->fd->flags.visited = TRUE
Yes that specific message type should work and you should get at least partial
dissection. The NetEvent structure contains the "ProviderID" which is the
payload of the NetEvent. Looking at the NPL source there is over 100 different
ProviderIDs, so not all have been implemented in Wireshark,
Are you suggesting "unit types" for "strings" or are you suggesting "unit
types" for "string values that should really be considered integers or floats"?
It certainly sounds like the latter and in which case I would suggest
converting them in your dissector. Numeric fields that are treated a
I started working on the problem of having Wireshark read packet comments from
Network Monitor (NetMon) (.cap) files. It escalated quickly and I found myself
implementing way more functionality than I had intended just because of the
information I stumbled across (and being "in the neighborhood
Adding on to Jaap's comments, because this is a particularly interesting case
that you picked.
There are 2 fields here, the "HTTP status code" (as an integer),
"http.response.code" and the "HTTP status code 'meaning'" (as a string, i.e.
"OK"), "http.response.code.desc". The "HTTP status cod
I just took a look at packet-zep.c, and the "timestamp field" is being added
explicitly with proto_tree_add_time, which negates the need for an encoding.
Are you looking to convert that to proto_tree_add_item and pass the correct
encoding? That's the only time the encoding needs to be specifi
Hopefully inlining comments will work...
-Original Message-
From: Samuel GROOT
To: Developer support list for Wireshark
Cc: Michael Mann
Sent: Thu, Aug 31, 2017 8:58 am
Subject: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for
EtherNet/IP
Hi,
I was already looki
Per the conversation that started with
https://www.wireshark.org/lists/wireshark-dev/201707/msg00132.html, I would say
that yes Qt 4 is still supported by Wireshark 2.4, but it looks like it won't
be supported for Wireshark 2.6 release (in what is now current master branch).
The problem is ju
I think the first step is just to submit your patch for review. See
https://wiki.wireshark.org/Development/SubmittingPatches for more details.
-Original Message-
From: krishna Kulkarni
To: wireshark-dev
Sent: Tue, Aug 29, 2017 10:20 am
Subject: [Wireshark-dev] Idea about Adding ext
My mail client decided to butcher the formatting of your email, so I manually
tried to reformat it so that my inline replies make sense.
Hopefully the mail client doesn't butcher it on the way out too. Sorry for the
inconvience.
Le 29/08/2017 à 21:34, Michael Mann via Wireshark-dev a
The answer depends on exactly what you are trying to do, some things will be
easier than others.
1. If you want to add vendor specific objects, that can easily be done in Lua
because there is a dissector table that you can just register your vendor
specific class with ("cip.class.iface"). T
This was briefly discussed on -core back in March (when you brought it up then).
Copy/pasted the comments from there (conversation between you and Gerald):
>> It looks like we've run into j2bugzilla issue:
>>
>> https://github.com/TomRK1089/j2bugzilla/issues/14
>
> That is unfortunate, but ..
ug 19, 2017 at 8:10 AM, Michael Mann via
Wireshark-dev wrote:> I don't know exactly how far
BASE_CUSTOM goes back, but it is for "custom"> display of a field. But if
there are enough fields with the same "custom"> formatting, it's probably time
to make it a
Richard Sharpe
To: Developer support list for Wireshark
Sent: Sat, Aug 19, 2017 10:16 am
Subject: Re: [Wireshark-dev] Making oui_base_custom available more generally
On Sat, Aug 19, 2017 at 5:19 AM, Michael Mann via
Wireshark-dev wrote:> If you're talking about
oui_base_custom(), I think
FT_OUI would support the latter.
-Original Message-
From: Alexis La Goutte
To: Developer support list for Wireshark
Sent: Sat, Aug 19, 2017 8:33 am
Subject: Re: [Wireshark-dev] Making oui_base_custom available more generally
On Sat, Aug 19, 2017 at 2:19 PM, Michael Mann via
If you're talking about oui_base_custom(), I think the better idea would be to
create a field type (FT_OUI) for it.
-Original Message-
From: Roland Knall
To: Developer support list for Wireshark
Sent: Sat, Aug 19, 2017 7:16 am
Subject: Re: [Wireshark-dev] Making oui_base_custom avai
See https://code.wireshark.org/review/23065
It could probably use some review for "naming". I'm not familiar enough with
the dissector to know if fields/dissector table name makes sense.
In regards to not already having a dissector table, not all developers think
about it, especially if there
See https://code.wireshark.org/review/22974
This was added to help developer mistakes, but maybe there is a legitimate
reason? (or regex in checkAPI needs tweeking)
-Original Message-
From: Dario Lombardo
To: Developer support list for Wireshark
Sent: Aug 8 5:33 am
Subject: [Wire
l compilation (debug)
I mean preferences.
On Saturday, July 29, 2017, Michael Mann via Wireshark-dev
wrote:
Define "config". Do you mean preferences (which I thought we already had)? Or
build configuration? (or "other")
-Original Message-
From: Dario
Define "config". Do you mean preferences (which I thought we already had)? Or
build configuration? (or "other")
-Original Message-
From: Dario Lombardo
To: Developer support list for Wireshark
Sent: Sat, Jul 29, 2017 11:23 am
Subject: Re: [Wireshark-dev] Conditional compilation (d
See some discussion on the issue here: https://code.wireshark.org/review/21490/
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Fri, Jul 28, 2017 1:41 pm
Subject: Re: [Wireshark-dev] LNK2019: unresolved external symbol
proto_deregister_protocol
I'm working on refactoring the Decode As dialog into using model/view
functionality (https://code.wireshark.org/review/22625). The model appears to
be "forced" to provide the names of the column headers that are part of the
"table" in the Decode As dialog. Currently the names of the column he
that allows the filterability.
-Original Message-
From: Richard Sharpe
To: Developer support list for Wireshark
Sent: Sat, Jul 1, 2017 5:02 pm
Subject: Re: [Wireshark-dev] Using col_set_str(pinfo->cinfo, COL_PROTOCOL,
"some_string") but cannot filter on some_string
On Sa
I think you're running into this:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4684
-Original Message-
From: Richard Sharpe
To: Developer support list for Wireshark
Sent: Sat, Jul 1, 2017 2:31 pm
Subject: Re: [Wireshark-dev] Using col_set_str(pinfo->cinfo, COL_PROTOCOL,
"s
I use Visual Studio (VS2013 for the moment) for my development, but up until
Sharkfest I hadn't done much GUI development. Now that I've dipped my toe in
the water, I'm paying more attention to the project organization done by VS.
Why is the "Header Files" folder under UI/qtui only contain Qt
46 matches
Mail list logo
