Re: [Wireshark-dev] a bug or a feature

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"

Re: [Wireshark-dev] LUA chained dissector drops data parameter

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

Re: [Wireshark-dev] Do we have a "standard" way to calcucate CRC24?

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

Re: [Wireshark-dev] What is best way to use other protocol subdissectors?

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

Re: [Wireshark-dev] The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way

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

Re: [Wireshark-dev] dfilter functions

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

Re: [Wireshark-dev] Retrieving dissection result from another dissector

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

Re: [Wireshark-dev] Switch to C++11 or C++14

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.

Re: [Wireshark-dev] Subtree expand/collapse tracking

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

[Wireshark-dev] Qt 4 and template support

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

Re: [Wireshark-dev] OSCORE dissector

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

Re: [Wireshark-dev] GTK version broken in master?

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

Re: [Wireshark-dev] Multiple TRANSUM fixes

"Bug:" tags? With one, once the change gets merged, it closes the bug on bugzilla. But 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 <wireshark-dev@wireshark.org> wro

Re: [Wireshark-dev] Multiple TRANSUM fixes

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

Re: [Wireshark-dev] MASTER wsutil.lib won't build

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]

Re: [Wireshark-dev] Duplicate dissectors (anonymous) and (anonymous) for protocol xxx

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

Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...

-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

Re: [Wireshark-dev] XXXX: avoid appending xxxx multiple times to frame.protocols field

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:

Re: [Wireshark-dev] Is there any example C dissectors I can study?

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

Re: [Wireshark-dev] Best way to give configuration information to a protocol

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)

Re: [Wireshark-dev] Add a protocol to the "decode as" option

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

Re: [Wireshark-dev] causes for losing COL_PROTOCOL or COL_INFO data

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 =

Re: [Wireshark-dev] Improving Network Monitor (and Message Analyzer) dissection supp

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,

Re: [Wireshark-dev] unit_name_string for FT_STRING field types?

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

[Wireshark-dev] Improving Network Monitor (and Message Analyzer) dissection support in Wireshark

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

Re: [Wireshark-dev] Enrich tshark data

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

Re: [Wireshark-dev] Default encodage for FT_ABSOLUTE_TIME

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

Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for EtherNet/IP

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]

Re: [Wireshark-dev] Wireshark 2.4.1 build errors (with Qt 4)

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

Re: [Wireshark-dev] Idea about Adding extra functionality in wireshark.

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

Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for EtherNet/IP

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 écrit

Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for EtherNet/IP

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").

Re: [Wireshark-dev] Bugs no longer autoclose?

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

Re: [Wireshark-dev] Making oui_base_custom available more generally

-dev] Making oui_base_custom available more generally On Sat, Aug 19, 2017 at 8:10 AM, Michael Mann via Wireshark-dev<wireshark-dev@wireshark.org> 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 e

Re: [Wireshark-dev] Making oui_base_custom available more generally

arpe <realrichardsha...@gmail.com> To: Developer support list for Wireshark <wireshark-dev@wireshark.org> 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<

Re: [Wireshark-dev] Making oui_base_custom available more generally

re generally On Sat, Aug 19, 2017 at 2:19 PM, Michael Mann via Wireshark-dev <wireshark-dev@wireshark.org> wrote: If you're talking about oui_base_custom(), I think the better idea would be to create a field type (FT_OUI) for it. Yes it is a idea but a BASE_OUI with VALS() (and use FT_UI

Re: [Wireshark-dev] Making oui_base_custom available more generally

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] Vendor-specific dissectors for 802.11

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

Re: [Wireshark-dev] checkapi prefs

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

Re: [Wireshark-dev] Conditional compilation (debug)

man...@netscape.net> Sent: Sat, Jul 29, 2017 4:36 pm Subject: Re: Conditional compilation (debug) I mean preferences. On Saturday, July 29, 2017, Michael Mann via Wireshark-dev <wireshark-dev@wireshark.org> wrote: Define "config". Do you mean preferences (which I thoug

Re: [Wireshark-dev] Conditional compilation (debug)

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

Re: [Wireshark-dev] LNK2019: unresolved external symbol proto_deregister_protocol

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]

[Wireshark-dev] Qt translations when refactoring

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

Re: [Wireshark-dev] Using col_set_str(pinfo->cinfo, COL_PROTOCOL, "some_string") but cannot filter on some_string

L_PROTOCOL, "some_string") but cannot filter on some_string On Sat, Jul 1, 2017 at 1:48 PM, Michael Mann via Wireshark-dev<wireshark-dev@wireshark.org> wrote:> I think you're running into this:> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4684What is strange is that it

Re: [Wireshark-dev] Using col_set_str(pinfo->cinfo, COL_PROTOCOL, "some_string") but cannot filter on some_string

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] The "right" Qt header files

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