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

[Michael Mann via Wireshark-dev]

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 when 
switching to a different Wireshark version.  The "obsolete" tag just leaves the 
preference alone and allows users to freely switch between Wireshark versions.


-Original Message-
From: João Valverde 
To: wireshark-dev@wireshark.org
Sent: Thu, Nov 4, 2021 7:46 am
Subject: Re: [Wireshark-dev] a bug or a feature



On 03/11/21 10:50, Zoran Bošnjak wrote:
> Hello wireshark developers,
> I would appreciate some clarification about "making preferences obsolete".
>
> As this problem reports (which is also in accordance with README.dissector)
> https://gitlab.com/wireshark/wireshark/-/issues/17697
> ... is to make each removed preference explicitely obsolete with a call to
> prefs_register_obsolete_preference.
>
> By calling this function, the misconfiguration warning is suppressed.
>
> The reported issue is easy to fix and also easy to modify as suggested by 
> reviewer, but I have some general questions about the preferences. Also, I am 
> not sure if this fix is really wanted, but rather a register_obsolete needs a 
> review.
>
> 1. The original warning looks like a correct behaviour. It's informative and 
> it correctly indicates a misconfiguration to the user.
> Why would one want to suppress the warning?
>
> 2. If each such warning is to be suppressed, then why logging it in the first 
> place?
>
> 3. The mechanism is fragile. It only handles the change once. Once the 
> preference is made obsolete, the call to
> prefs_register_obsolete_preference remains in the code forever. This raises 
> the question:
> How do you re-introduce the same preference back, in particular:
> Do you remove the register_obsolete call from the code or keep it in the code?
> If it's "remove the call": then it was unnecessary in the first place, 
> because the call is exactly
> the negation of a preference being currently present (which we already known 
> from the rest of the code)
> If it's "to keep the call": then it's wrong, because the preference is 
> present and the call says
> it's obsolete.

I assume the intention is to keep the obsolete call indefinitely. It's 
not intended to be re-introduced with a different behavior either. I 
think you raise some valid points but why is the option "keep the call" 
wrong? A more wordy name might be "no_longer_actively_used" instead of 
deprecated. Does that fix whatever is wrong?
> 4. A patch to the reported problem was attempted
> https://gitlab.com/zoranbosnjak/wireshark/-/commit/3e6fe4e0c3eca2b21151176c988ea36adac10b40
> In this case, there is a closed set (256) of possible preferences, so that 
> all not-supported categories can be made obsolete in advance, which 
> effectively suppresses the warnings, regardless of the supported category set.
> A reviewer suggested a "lean" approach which suffers the remove/add problem 
> and it requires hardcoding a category list.
> If the reported issue really is a problem, why "lean" approach? I can not 
> forsee any noticable burden for the preference engine. It's like trying to 
> optimize for assembler, rather than source C code (the dissector C code is 
> generated in this case and is therefore at the lower layer which does not 
> need such optimization, at the cost of the real source code being suboptimal 
> and in this case even (potentially) wrong). Please clarify the reasoning 
> behind this.
>
> regards,
> Zoran
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 not familiar with 
the Bluetooth code, but it seems expansive enough that using proto data could 
more easily need to dissection bugs.



-Original Message-
From: Kanstrup, Mikael 
To: Peter Wu ; Developer support list for Wireshark 

Sent: Fri, Nov 29, 2019 10:26 am
Subject: Re: [Wireshark-dev] LUA chained dissector drops data parameter

#yiv6376871419 P {margin-top:0;margin-bottom:0;}Hi Peter,
Thanks a lot for an extensive answer with links to related discussions! 
Have proto data use been considered for passing data around instead? I suppose 
there's a performance penalty to using that over directly passing the pointer. 
For my scenario the data parameter can quite easily be replaced with 
p_get_proto_data / p_add_proto_data. This works for cases where the LUA script 
itself does not need access the data passed around.
I uploaded a change for this discussion here. I have not done any extensive 
testing but it shows the idea:https://code.wireshark.org/review/35260

Performance wise using callgrind with tshark -V on my packet capture file with 
16000 packets I get around 0.5% higher numbers with proto data compared to 
directly passing the pointer.
/Mikael
Från: Wireshark-dev  för Peter Wu 

Skickat: den 26 november 2019 01:40
Till: Developer support list for Wireshark 
Ämne: Re: [Wireshark-dev] LUA chained dissector drops data parameter Hi Mikael,

On Mon, Nov 18, 2019 at 05:20:54PM +, Kanstrup, Mikael wrote:
> Hi,
> 
> I'm working on dissecting a proprietary protocol that extends Bluetooth 
> HCI_ACL with a LUA dissector. As there's no heuristics dissector list 
> registered for this particular protocol I thought something similar could be 
> achieved with a chained dissector. I retrieve the original HCI_ACL dissector 
> handle and replace it with my own LUA dissector. In LUA dissector apply some 
> heuristics and if it's not my own protocol then call the original HCI_ACL 
> dissector via the handle.
> 
> Code looks like this:
> 
> local proto_test = Proto("test", "Use chaining as heuristic dissector")
> local proto_default_acl
> 
> function is_test_proto(tvb, pinfo)
> -- Apply heuristics to determine if own protocol
> return false
> end
> 
> function proto_test.dissector(tvb, pinfo, tree)
> if not is_test_proto(tvb, pinfo) then
> return proto_default_acl:call(tvb, pinfo, tree)
> end
> 
> pinfo.cols.protocol = "test"
> tree = tree:add(proto_test, tvb)
> return tvb:len()
> end
> 
> function proto_test.init()
> local hci_type = DissectorTable.get("hci_h4.type")
> local pattern = 0x02 -- ACL
> proto_default_acl = hci_type:get_dissector(pattern)
> hci_type:add(pattern, proto_test)
> end
> 
> This unfortunately did not work and I was not able to find out why until I 
> started looking at the HCI_ACL dissector code itself.
> 
> static gint
> dissect_bthci_acl(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void 
> *data)
> {
> <...>
> /* Reject the packet if data is NULL */
> if (data == NULL)
> return 0;
> 
> The above NULL check is hit for all calls coming from the LUA dissector. The 
> LUA dissector function prototype does not have the data parameter and it 
> appears it's simply lost when chaining calls through LUA.

Correct, Lua always passes a NULL parameter. Due to type-safety,
Lua dissectors cannot pass arbitrary data.

> Any suggestions on how to approach this? Would it be possible to
> extend the LUA dissector interface with another function prototype
> that supports the data parameter? Just support relaying the parameter
> in chained dissectors, not modifying or doing any fancy stuff with it.

There is unfortunately no runtime registration of types for the 'data'
parameter. If you can somehow keep track that a C dissector was from a
particular dissector table, and then recognize that the Lua dissector
was registered with the same table, then hopefully it should be possible
to propagate the data parameter as special case.

Long-term, we might have to revisit how to pass data between (multiple
layers of) dissectors. Not just Lua, but also C. For Lua, see also:

Bug 15931 - Add Lua support for arbitrary data parameter in dissector calls.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.wireshark.org_bugzilla_show-5Fbug.cgi-3Fid-3D15931=DwIGaQ=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc=W4de0lx_38xjApzeLJAbvbv2_hc2Iu3XIsdzy2qOqXI=H9rWMwiJyfh8eIuBmZCEEPnMb_oP3346TmGdwbolF00=eVevrJK65E3vVrpXCTbmszr11My9pHoJCnjOqUBRqmE=

(+cc Huang)
Discussion about another mechanism to pass data between dissectors:

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

[Michael Mann via Wireshark-dev]

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 CRC. 


-Original Message-
From: Andrii Vladyka via Wireshark-dev 
To: Developer support list for Wireshark 
Cc: Andrii Vladyka 
Sent: Tue, Sep 17, 2019 9:35 am
Subject: [Wireshark-dev] Do we have a "standard" way to calcucate CRC24?

Hi all,

We have routines for calculating crc6,8,10,16,32, but not crc24. There is a 
sort of implementation for CRC24 calculation in packet-gprs-llc.c, but I would 
prefer to avoid code duplication, if possible. Are there any "standard" WS 
routines I can use?

Regards,
Andrii Vladyka



___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 other 
flags.Payload length (1 byte)"Padding" (3 bytes)  (size based on 
payload length).
Since the CAN ID is not "on the wire" for many CAN protocols (it's just the 8 
byte payload), subdissectors have been set up to accept the 32-bit CAN ID as a 
"data parameter" passed into the dissection function.  Technically, I think 
Maksim Salau expanded it to a full structure (probably to accommodate/mask the 
higher bits of SocketCAN).  This does fall a little under first dissector gets 
to more heavily influence the interface.
All CAN protocols have registered with the "can.subdissector", where the 
"interface" is expecting the "data parameter" structure that is dictated by 
SocketCAN.  However any dissector has access to use the "can.subdissector" 
table.  For example, if the IEEE-1722 "packet format" isCAN ID (4 bytes).  Only 
CAN IDs of 11 or 29 bits, no higher bits setPayload length (1 byte) (size based on payload length)
The IEEE-1722 "CAN dissector" can enumerate the "header fields" of CAN ID and 
Payload length, and reuse the same display names like can.id, and then get a 
handle to the "can.subdissector" table and call dissector_try_payload_new() 
just like the SocketCAN dissector does.  Just be aware that the data parameter 
of dissector_try_payload_new() has to match the structure that SocketCAN uses 
because that is the "interface" that the "can.subdissector" dissector table has 
defined.
With the "can.subdissector" there isn't a way to determine which subdissector 
should be called (so you always have to use Decode As).  Some protocols, like 
TCP or UDP can key off of the "port number" to determine which subdissector to 
call and subdissectors can register by that port number.If the IEEE-1722 
"packet format" has a field to determine which CAN protocol followed (i.e. 1 = 
J1939, 2 = CANOpen), then it should setup its own subdissector table 
("1722can.subdissector"), and then the CAN protocols themselves would need to 
register with that dissector table as well, with the value of the field used to 
call them.
Hope this provides a little more clarity.




-Original Message-
From: Dmitriy Linikov 
To: wireshark-dev 
Sent: Wed, Jan 30, 2019 6:01 am
Subject: Re: [Wireshark-dev] What is best way to use other protocol 
subdissectors?



Date: Wed, 30 Jan 2019 09:42:30 +
From: Anders Broman 
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] What is best way to use other protocol 
subdissectors?

Why do you need to add “fake "can.flags.xxx" to the list of protocol fields”?


I want wireshark to treat ACF-CAN submessages of IEEE1722 like any regular can 
message that is handled by packet-socketcan: decode payload and use the same 
filters. 



I think the reason for that is that you are adding hf variables to a protocol 
whose name is ieee1722 and in that case the expected format is

Ieee1722.can.flags.rtr. I guess you should register your sub protocol and name 
the hf’s accordingly but it’s hard to say with the information given.

Publish you code snippet?

 The example of such code can be seen in packet-caneth.c which is also a 
transport protocol for CAN messages over Ethernet. It defines "can.id" and 
other "can.xxx" hf in addition to its own "caneth.magic", "caneth.version", 
etc.Maksim Salau has already pointed me to the list of exceptions in "sub 
is_from_other_protocol_whitelist" in tools/checkfiltername.pl, but still I'm 
not sure whether it is the right way to do it.

It looks like there is a flaw in wireshark's CAN support which is at the moment 
not abstract and is bound to the Linux-specific SocketCAN driver implementation.
Best regards,Dmitriy Linikov.
___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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, those could go in a header file.  We just don't like to create 
header files for the sake of storing things that will just be used by a single 
.c module.
Currently dissector tables just work with "the last value set to it".  Within 
dissector_add_uint, there is the dissector_add_uint_sanity_check(), but it's 
#if 0ed out.  I think that's very intentional, but I can see the need to make 
it conditionally defined out (like we have for some of the hf_ checks).

-Original Message-
From: Richard Sharpe 
To: Developer support list for Wireshark 
Sent: Thu, Jan 3, 2019 12:07 pm
Subject: [Wireshark-dev] The 802.11 dissector is a big hairy ball of wax that 
needs to be refactored in some way

Hi folks,

I am sure that most people who work on the ieee80211 dissector will
agree that it is a monster that needs taming.

It is currently more than 37,000 lines long and a number of things
that have been done in it make it hard to split it in rational ways.

Perhaps the way that the Wi-Fi community does standards also makes
things difficult, but some of the issues I see are:

1. TAGs and Extended TAGs (for IEs) have to be defined in
packet-ieee80211.c and thus are hard to split out to other files.

It would be nice if there was some way to register new tags and
extended tags with errors if you are registering an already registered
value.

2. The IE handling code handles placing the TAG and length into the
tree, also forcing the handling of IEs into packet-ieee80211.c.

It would be better if there was a function to handle the header, that
could perhaps be passed a function pointer to handle the body so we
can spit things out.

3. It is damn hard to find fixed fields that have been implemented ...

And so on.

I am sure that others can think of further deficiencies.

It would be useful to compile a list so we can look at reworking the
Wi-Fi suite of dissectors to make them more maintainable over time.

Please respond with your thoughts.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] dfilter functions

[Michael Mann via Wireshark-dev]

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 used for strings/bytes 
like len() above, but can also be used for integer fields that vary in length 
(1-4 bytes)
Examples:size(eth.type) == 2       (This is just for demonstration purposes.  
Obviously the size of the eth.type field could only be 2 but I couldn't quickly 
think of a "popular" field with varying integer length)    
size(tcp.options) > 7

count - Number of times a field is found in a single frame.  This can be used 
to help identify "tunneling" or if multiple PDUs are in a single frame.
Examples:count(ip.src) > 1
count(smpp.sequence_number) > 1    (Since sequence_number is required for the 
packet, having more than one shows frames with multiple PDUs.


-Original Message-
From: Dario Lombardo 
To: Developer support list for Wireshark 
Sent: Sun, Jan 6, 2019 4:35 am
Subject: [Wireshark-dev] dfilter functions

HiI've noticed that the online documentation about dfilter functions just talks 
about 2 of them, upper and lower:
https://www.wireshark.org/docs/man-pages/wireshark-filter.html
but there are more that are undocumented AFAICS:
- len- size- count
Can someone explain me their purpose and give a working example on some 
protocol?Thanks.Dario.

-- 
Naima is 
online.___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 dissector using 
p_proto_add_data to remember data "for itself" (which would include some 
interaction with GUI like Decode As).  Just because you can exchange data 
between dissectors this way, doesn't mean you should.  I think it's more 
understandable if there are multiple layers/protocols between the setting of 
data and it's retrieval, but if you are only going a single layer, the data 
parameter of call_dissector_with_data should be used and a "shared structure" 
should be defined that includes the input/output parameters.
 
 
-Original Message-
From: Dario Lombardo 
To: Developer support list for Wireshark 
Sent: Wed, Jul 4, 2018 5:28 am
Subject: Re: [Wireshark-dev] Retrieving dissection result from another dissector






On Tue, Jul 3, 2018 at 8:49 PM Guy Harris  wrote:


Should we, instead, get rid of the scope arguments to those functions and, 
instead, have separate functions, one of which serves the original purpose, 
using file scope, and one of which serves this new purpose, using pinfo->pool 
scope?




It looks neat, but I see 2 issues:


1) grep -r  "p_\(add\|get\|remove\)_proto_data" ../epan/dissectors/* | wc -l 
gives me 881 calls to those functions. It could be harsh to change all of them 
as well as breaking compatibility with existing code outside wireshark 
(plugins?).


2) are we sure that a call to (eg.) 
p_proto_add_data_with_file_scope_or_another_name() is more meaningful than 
p_proto_add_data(wmem_file_scope(), ...)? How could those 2 functions be named 
to recall the actual goal?


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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.  Other than some 
"shorthand" in syntax, I don't see the necessity to "upgrade".  Are we missing 
out on some Qt features because of no C++ 11 support?
 
 
 
-Original Message-
From: Michał Łabędzki 
To: Developer support list for Wireshark 
Sent: Fri, Jun 1, 2018 5:21 pm
Subject: [Wireshark-dev] Switch to C++11 or C++14


Hello,

Is there (still) a problem to switch to C++11 or C++14? Petri-Dish seems to 
support it for Windows, but there is old standard used for Ubuntu.
___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 example trace,> with which we could demonstrate this 
behavior ?There is still an issue with this. Should I reopen the bug or create 
anew one?The subtree is now opened correctly, but only if you have selected 
atree element under the root tree.For the sample capture within tcp tree:select 
#1, expand tcp, expand tcp.flagsselect #2, tcp is expanded down to tcp.flags as 
expectedselect the ip root nodeselect #1, tcp is closed-- 
CheersThomas___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt 4 and template support

[Michael Mann via Wireshark-dev]

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 parent/child 
relationship of a tree as well representation of that tree through a 
QAbstractItemModel derived class.  After converting a few of a the dialogs I 
noticed a "pattern" and thought template classes could be created to save some 
typing and enforce type safety (see https://code.wireshark.org/review/24988).

What I didn't realize was that this isn't supported for Qt 4.8. I thought 
"templates are templates" and since Qt already uses them for lists and vectors 
this shouldn't be a problem.  However, Roland pointed out that the template 
support I want doesn't work with Qt 4.8 
(http://doc.qt.io/archives/qt-4.8/templates.html). I know there has been talk 
of dropping support for Qt 4, but I'm not sure where that's at.  I thought 
there was enough stuff already in place that would mean Qt 4 support would be 
dropped for 2.6 release, but I thought I'd send a note here before committing 
https://code.wireshark.org/review/24988

Michael
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] OSCORE dissector

[Michael Mann via Wireshark-dev]

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 need a few dissectors to 
get the proper layering that you desire.
You can always submit a patch for review even if it's just a "WIP" (work in 
progress).  Reviewers may be able to better steer you in a direction by seeing 
the code itself (I know I work better that way, anyway).

Michael

 
 
-Original Message-
From: Mališa Vučinić 
To: wireshark-dev 
Sent: Tue, Dec 19, 2017 10:48 am
Subject: [Wireshark-dev] OSCORE dissector


Hello all,


I am looking for an advice how to organize the dissector code of OSCORE 
(https://tools.ietf.org/html/draft-ietf-core-object-security-07).


OSCORE is a mechanism to encrypt *part* of CoAP-RFC7252 message, leaving CoAP 
header in the clear. Encryption is signaled with a special CoAP option called 
Object-Security. The plaintext of OSCORE contains CoAP code, *some* CoAP 
options and CoAP payload. This means that once decryption has taken place, 
functions specific to CoAP dissector are needed to dissect it.


OSCORE message can also be carried with HTTP, in order to support HTTP-to-CoAP 
proxies, and is signaled by the presence of a special HTTP header.


Another data point is that IETF CORE has also standardized CoAP to be used over 
TCP and Websockets 
(https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-11) with a different 
on-the-wire format from CoAP over UDP currently implemented in Wireshark. I do 
not intend to implement this now but would like to organize my OSCORE 
dissection code in a way that will facilitate this extension of CoAP.


I started implementing OSCORE as a separate dissector, explicitly called from 
CoAP for now. To dissect OSCORE plaintext after decryption, I plan on exporting 
some CoAP functions and calling them from the OSCORE dissector. I will need to 
refactor the CoAP dissector code a bit to facilitate this. CoAP over TCP can 
then be implemented as a separate dissector using the same exported CoAP 
functions. 


I would like to check whether this is the right approach and if I should pursue 
it. Another option is to put everything within the CoAP dissector but I am not 
sure if that would cover OSCORE over HTTP case.


Any feedback would be greatly appreciated.


Mališa





___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 before the fix had something 
to do with it, but I chased some red herrings [1] due to corrupted preferences 
that must have gotten saved doing unrelated work.

Michael


[1] https://en.wikipedia.org/wiki/Red_herring
 
 
-Original Message-
From: Anders Broman 
To: wireshark-dev 
Sent: Mon, Dec 18, 2017 10:17 am
Subject: [Wireshark-dev] GTK version broken in master?



Hi,
I think the GTK version is broken in master – if anyone cares
 
Starting a capture a protocol hierarchy table pops up and the application 
cannot be closed again.
 
Regards
Anders


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Multiple TRANSUM fixes

[Michael Mann via Wireshark-dev]

When the Gerrit hooks into Bugzilla used to work, it would close multiple bugs 
if multiple bugs were listed.
Now it will just add the "patch XXX has been merged" message to all bugs in the 
list but not change bug state.
 
 
-Original Message-
From: Dario Lombardo <dario.lombardo...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Cc: Michael Mann <mman...@netscape.net>
Sent: Tue, Nov 14, 2017 2:53 am
Subject: Re: [Wireshark-dev] Multiple TRANSUM fixes



Apart from broken ability, how should gerrit behave with multiple "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> 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 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 closed state has been broken for 
awhile, so typically the core developer who submits the patch ends up 
"manually" closing the bugs referenced in the commit message.
 
 
-Original Message-
From: Paul Offord <paul.off...@advance7.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Sent: Mon, Nov 13, 2017 1:33 pm
Subject: Re: [Wireshark-dev] Multiple TRANSUM fixes

Hi Richard,Yes that does sound best.  You know when you enter the line:Bug:  
12345into the commit comment, can I list the bugs?  And if I do, will gerrit 
update Bugzilla?  I'm guessing not for all, so what the best way to handle 
this?Thanks and regards...Paul-Original Message-From: Wireshark-dev 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Richard SharpeSent: 
13 November 2017 18:13To: Developer support list for Wireshark 
<wireshark-dev@wireshark.org>Subject: Re: [Wireshark-dev] Multiple TRANSUM 
fixesOn Mon, Nov 13, 2017 at 10:09 AM, Paul Offord <paul.off...@advance7.com> 
wrote:> Hi,>>>> I want to submit a patched packet-transum.c file.  It fixes 
three > bugs, none of which are currently on Bugzilla.  Should I submit three > 
bugs and then refer to all three bugs in the patch commit comments?  > Or can I 
specify all three bugs in one Bugzilla report?  What’s the correct form?I would 
say submit three separate bugs. This eases management, because if later one of 
your fixes is found to be incomplete, and you only filed one bug, it becomes 
confusing when we reopen that one bug.--Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe__This
 message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.Any views or opinions expressed are solely those 
of the author and do not necessarily represent those of Advance Seven Ltd. 
E-mail transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message, which arise as a 
result of e-mail transmission.Advance Seven Ltd. Registered in England & Wales 
numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 
1SJ__This 
email has been scanned by the Symantec Email Security.cloud service.For more 
information please visit 
http://www.symanteccloud.com_Sent
 via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lis

Re: [Wireshark-dev] Multiple TRANSUM fixes

[Michael Mann via Wireshark-dev]

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 closed state has been broken for 
awhile, so typically the core developer who submits the patch ends up 
"manually" closing the bugs referenced in the commit message.
 
 
-Original Message-
From: Paul Offord 
To: Developer support list for Wireshark 
Sent: Mon, Nov 13, 2017 1:33 pm
Subject: Re: [Wireshark-dev] Multiple TRANSUM fixes

Hi Richard,Yes that does sound best.  You know when you enter the line:Bug:  
12345into the commit comment, can I list the bugs?  And if I do, will gerrit 
update Bugzilla?  I'm guessing not for all, so what the best way to handle 
this?Thanks and regards...Paul-Original Message-From: Wireshark-dev 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Richard SharpeSent: 
13 November 2017 18:13To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Multiple TRANSUM 
fixesOn Mon, Nov 13, 2017 at 10:09 AM, Paul Offord  
wrote:> Hi, I want to submit a patched packet-transum.c file.  It fixes 
three > bugs, none of which are currently on Bugzilla.  Should I submit three > 
bugs and then refer to all three bugs in the patch commit comments?  > Or can I 
specify all three bugs in one Bugzilla report?  What’s the correct form?I would 
say submit three separate bugs. This eases management, because if later one of 
your fixes is found to be incomplete, and you only filed one bug, it becomes 
confusing when we reopen that one bug.--Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe__This
 message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.Any views or opinions expressed are solely those 
of the author and do not necessarily represent those of Advance Seven Ltd. 
E-mail transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message, which arise as a 
result of e-mail transmission.Advance Seven Ltd. Registered in England & Wales 
numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 
1SJ__This 
email has been scanned by the Symantec Email Security.cloud service.For more 
information please visit 
http://www.symanteccloud.com_Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 Wireshark with VS2013 on Windows 10.  I’ve pulled a fresh copy of 
MASTER.  I can’t get it to build.  I get:
 
1>  inet_addr.c
1>C:\Development\wireshark\wsutil\inet_addr.c(50): error C2220: warning treated 
as error - no 'object' file generated
1>C:\Development\wireshark\wsutil\inet_addr.c(50): warning C4013: 'inet_pton' 
undefined; assuming extern returning int
1>C:\Development\wireshark\wsutil\inet_addr.c(58): warning C4013: 'inet_ntop' 
undefined; assuming extern returning int
1>C:\Development\wireshark\wsutil\inet_addr.c(58): warning C4047: 'return' : 
'const gchar *' differs in levels of indirection from 'int'
1>C:\Development\wireshark\wsutil\inet_addr.c(70): warning C4047: 'return' : 
'const gchar *' differs in levels of indirection from 'int'
 
I can see that inet_pton and inet_ntop are provided by Windows, defined in 
WS2tcpip.h, e.g.
 
#if (NTDDI_VERSION >= NTDDI_VISTA)
WINSOCK_API_LINKAGE
INT
WSAAPI
inet_pton(
_In_  INT Family,
_In_  PCSTR   pszAddrString,
_Out_writes_bytes_(sizeof(IN6_ADDR))  PVOID   pAddrBuf
);
.
.
 
The include is in C:\Program Files (x86)\Windows Kits\8.1\Include\um
 
What am I doing wrong?
 
Cheers…Paul

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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.

To me there are 2 solutions
1. Create "placeholder" protocols with proto_register_protocol().  The 
"protocol lD" returned can be used to differentiate the different dissector 
function handles
2. Create a "pino" (protocol in name only) with 
proto_register_protocol_in_name_only.  This allows you to create "helper" 
protocols, with most of the "control" still with the "parent" protocol created 
with proto_register_protocol.
 
I believe #2 is the "preferred" solution.
 
 
 
-Original Message-
From: John Dill 
To: wireshark-dev 
Sent: Wed, Oct 25, 2017 4:44 pm
Subject: [Wireshark-dev] Duplicate dissectors (anonymous) and (anonymous) for 
protocol xxx



I just happened to turn on console printing to troubleshoot a different problem 
and I'm getting a couple of interesting messages when I change my protocol 
preferences.
 
Duplicate dissectors (anonymous) and (anonymous) for protocol xxx in dissector 
table tcp.port
Protocol  is already registered in "udp" table.
 
I have a proto_reg_handoff_xxx that creates a couple of TCP port dissector 
handles using 'dissector_add_uint("tcp.port", MY_TCP_PORT, tcp_handle)', and a 
UDP heuristic dissector 'heur_dissector_add("udp", dissect_xxx_udp_heur, 
"", "xxx", proto_xxx, HEURISTIC_ENABLE)'.
 
My question is whether I'm doing something not recommended.  The protocol uses 
both TCP and UDP packets to send data, and I've lumped it under one "xxx" 
protocol.  For the most part, it hasn't been an issue operationally, but I'm 
wondering if there's a better way to do it so I don't have these messages.  I 
haven't looked at the console output in detail before, so I've missed this up 
till now.
 
Is there any advice about dissecting a protocol that appears on both TCP and 
UDP streams and using the same name, or what I'm doing specifically that's 
causing it?  The messages have the same format, but the packaging in the TCP vs 
the UDP streams is slightly different.
 
Best regards,
John D.
 

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

 
 
 
-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 Multi-AP technical
> specification draft from August 2017. The work was done for an
> organization in the industry. It is pretty complete and has undergone
> testing with real traffic.
> 
> Unfortunately, they make references to elements in IEEE802.11 2016.
> 
> One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
> There is another such reference as well.

I'm not familiar enough with the protocols to know where exactly this is in the 
dissector.  I recently created a dissector table for tagged fields 
("wlan.tag.number").  I'm guessing this is where the beacon stuff is, so yes 
existing dissector tables should handle this.

> 
> These raise problems:
> 
> 1. I don't want to duplicate code
> 2. The code in the current packet-ieee80211.c dissector is incomplete
> WRT the 2016 version of the spec. (Eg, it does not handle Vendor
> specific  or Wide Bandwidth Channel Switch optional sub-elements.)

I also created a few dissector tables in packet-ieee80211.c for vendor specific 
extensions.  Most of the cases involved multiple vendors that were already in 
the dissector.  I think a few more could probably be created.  Most of the ones 
I left only had OUI_WFA as the only vendor, so I lost interest in the 
conversion to adding more dissector tables.

> 3. The references in IEE1905 are to the underlying structures not the
> tagged structures.
> 4. The code in packet-ieee80211.c is declared static so I can't call
> it if I wanted to.

Again, specifics about the code are more helpful to me.

> 
> We have mechanisms for dealing with this. One is dissector tables.
> Another is to declare certain functions non-static and put the
> definitions in header files. There might be others.
> 
> Are there any suggestions?

Without seeing the code, I would lean towards suggesting dissector tables as 
the solution for most of it.  Removing "static" from functions and declaring 
them in header files should be more of a last resort.
You can put your patch up for review, even if it is just a WIP.  Marking where 
you don't want to duplicate code or where you want to call (currently static) 
packet-ieee80211.c functions would be helpful.


> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 
frame.protocols field



Hi Roland,



2017-10-06 8:23 GMT+02:00 Roland Knall :

Personally I think moving to a set would reduce functionality for some 
applications. Industrial ethernet applications for instance heavily rely on 
multiple protocols being transported in single frames multiple times (one UDP 
packet contains a lot of openSAFETY frames, which themselve could contain data 
dissectors). 


So -1 for me for moving to a set.


 @Pascal - could you point me in the direction of Michael's change you 
mentioned (pino stuff)?



Here it is: https://code.wireshark.org/review/19464

 





On Fri, Oct 6, 2017 at 7:01 AM, Pascal Quantin  wrote:




Hi Guy,



Le 5 oct. 2017 23:20, "Guy Harris"  a écrit :

A given frame's dissection can have multiple packets for a given protocol, if, 
at any protocol layer, a PDU can contain multiple PDUs for the next layer above 
it (or parts of multiple PDUs, as with byte-stream protocols such as TCP).

Some recent changes have been submitted to fix that for particular protocols.

However, the underlying problem is that frame.protocols is intended to be a set 
(in which a given item can occur only once) rather than a bag (in which a given 
item can occur multiple times).  Perhaps it should be implemented as a set, 
with uniqueness enforced, so that individual dissectors don't need to keep from 
putting another  in the bag if there's already one there?





What I like also with frame.protocols field is that it shows the protocol 
encapsulation order within the packet. So in case of an IP packet encapsulated 
inside a protocol running in top of IP, I think it makes sense to display up 
twice. Changing it to a set would lose this property.


The problem with S1AP and Co is that it uses some dissector tables internally 
to decode the fields, leading to fake multiple occurrences within 
frame.protocols field. By the way, I realize that the pino functionality 
introduced by Michael might have been used here also instead of the simple 
patch I did. It might be an opportunity for me to see how this pino stuff 
behaves exactly ;)


Cheers,
Pascal. 


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe





___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 layers.
 
Many Wireshark dissectors are developed using copy/paste, it's just a matter of 
finding what you need to copy.  Many times assistance will be in the form of 
"go look at this dissector as an example", because with 1300 dissectors, 
"there's an example for that".

packet-PROTOABBREV.c certainly gives you a good skeleton, but the specifics of 
where your dissector will be called (like over TCP or UDP) can give you a good 
jump because you can just create a protocol field in the tree and have it show 
up in Wireshark.
 
 
-Original Message-
From: Christopher M. Lusardi via Wireshark-dev 
To: wireshark-dev 
Cc: Christopher M. Lusardi 
Sent: Fri, Sep 22, 2017 11:31 am
Subject: Re: [Wireshark-dev] Is there any example C dissectors I can study?



Is there a description available on all these files?

I enjoyed one of you SharFest15 videos on Youtube:


https://www.youtube.com/watch?v=bwqv_OzCZC8



Thank you,
Christopher M. Lusardi



-Original Message-
From: Graham Bloice 
To: Developer support list for Wireshark 
Sent: Thu, Sep 21, 2017 11:01 am
Subject: Re: [Wireshark-dev] Is there any example C dissectors I can study?







On 20 September 2017 at 19:45,   wrote:


Are there any large databases with example C dissectors that I can access?
 
Thanks,






Do you mean dissectors for large databases or a large collection of dissectors?


If the latter, then there are 1300 or so or so here: 
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=tree;f=epan/dissectors;h=6b9af4c25edd6252b636e2d64e8d994507e9d66e;hb=HEAD


-- 


Graham Bloice



___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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)
 
 
-Original Message-
From: Pascal Quantin 
To: Developer support list for Wireshark 
Sent: Mon, Sep 18, 2017 3:03 pm
Subject: Re: [Wireshark-dev] Best way to give configuration information to a 
protocol



Hi Juan Jose,



2017-09-18 17:12 GMT+02:00 Juan Jose Martin Carrascosa :

Hi all,


Which is the best way to pass configuration to a protocol? Do we have any 
builtin mechanisms? I tried to upload a patch using CSV at some point but it 
didn't succeed. So I wonder if there is any recommended way I can implement: 
table or list in the Preferences, XML file, CSV file...


My goal is to pass ("GUID", "plugin_name") pairs to the RTPS protocol so 
Wireshark knows dynamically what plugin it should call to deserialize data that 
is written by the DataWriter with id = "GUID". The GUID is part of the DATA 
packet and it is already dissected and known at that point.



A UAT dialog could be appropriate for your needs. Several dissectors are 
already using it and can be taken as an example (packet-ipsec.c, packet-http.c, 
...).
Or if the GUID / plugin mapping never changes, you could create a dissector 
table and have your plugin register to this table (see 
register_dissector_table() / register_custom_dissector_table() and the 
corresponding dissector_add_XXX() functions).



Best regards,

Pascal.




___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 dissect the (next) 
payload.  For example "Ethernet" has a type, IP has a protocol, TCP/UDP have a 
port.  In this case you set your dissector table up with the "unique identifier 
type" (typically numeric, but there are string and GUID examples).  Then you 
need to be able to save that "unique identifier" during dissection to provide 
to decode as functionality (as part of decode_as_t structure).  Your plugins 
will also call dissector_add_() to register their "unique identifier".  
dissector_add_ calls dissector_add_for_decode_as() internally, so there 
isn't a need for plugins to call it explicitly.  packet-ip.c is probably a good 
example to follow.
 
2. There is no unique identifier and payload must be determined by Decode As.  
You still need a dissector table and plugins will still need to call 
dissector_add_for_decode_as(), but "setting up the dissector table for decode 
as" has been made simpler by register_decode_as_next_proto().  See 
https://code.wireshark.org/review/22575 for example uses.
 
 
 
-Original Message-
From: Pascal Quantin 
To: Developer support list for Wireshark 
Sent: Mon, Sep 18, 2017 3:05 pm
Subject: Re: [Wireshark-dev] Add a protocol to the "decode as" option



Hi Juan Jose,



2017-09-18 16:21 GMT+02:00 Juan Jose Martin Carrascosa :

Hi everybody,


I have a set of plugins that work on top of the RTPS protocol. Which is the 
cleanest and right way to get this set of plugins available when I click in 
"decode as" in a RTPS packet?



If you create a dissector table for your RTPS payload (presumably that's what 
would need to be decoded as), then your plugins can register themselves using 
the dissector_add_for_decode_as() function.


Best regards,

Pascal.




___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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.
That's the only thing I can think of.
 
Is your protocol displayed otherwise in the packet tree?  Is there 
fragmentation (and possibly faulty logic for reassembly)?
 
 
-Original Message-
From: John Dill 
To: wireshark-dev 
Sent: Fri, Sep 15, 2017 5:09 pm
Subject: [Wireshark-dev] causes for losing COL_PROTOCOL or COL_INFO data



I'm setting the column fields and they appear to be set fine when I first open 
Wireshark, but when I apply a packet filter, I lose information from the fields 
even though it appears that I'm still calling the same col_* functions in the 
dissection.  Then when I remove the filter expression, and the COL_INFO I set 
is still missing.  Is there a usual cause for this behavior?  I can't seem to 
discover what's causing it.
 
Thanks,
John D.
 

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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, but hopefully I got 
a few of the popular ones.
If you have a capture file (.cap) that can't be read by Wireshark (or you want 
more ProviderIDs dissected), open a bug report in Bugzilla 
(https://bugs.wireshark.org) and attach the capture.
 
 
-Original Message-
From: Christopher Smith 
To: wireshark-dev 
Sent: Tue, Sep 12, 2017 2:18 am
Subject: Re: [Wireshark-dev] Improving Network Monitor (and Message Analyzer) 
dissection supp



For Michael Mann, thanks for your message dated “Sat, 9 Sep 2017 11:30:31 
-0400” – and does it work for you now?  Opening a *.cap exported out from – say 
– Message Analyzer?  Specifically, Media Type = “ETW provider message 
(NetEvent)”, Value = “0xFFe0”
 
https://technet.microsoft.com/en-us/library/mt146756.aspx


'Grant Thornton' refers to the brand under which the Grant Thornton member 
firms provide assurance, tax and advisory services to their clients and/or 
refers to one or more member firms, as the context requires. Grant Thornton 
Australia Ltd is a member firm of Grant Thornton International Ltd (GTIL). GTIL 
and the member firms are not a worldwide partnership. GTIL and each member firm 
is a separate legal entity. Services are delivered by the member firms. GTIL 
does not provide services to clients. GTIL and its member firms are not agents 
of, and do not obligate one another and are not liable for one another’s acts 
or omissions. In the Australian context only, the use of the term 'Grant 
Thornton' may refer to Grant Thornton Australia Limited ABN 41 127 556 389 and 
its Australian subsidiaries and related entities. GTIL is not an Australian 
related entity to Grant Thornton Australia Limited. 



Liability limited by a scheme approved under Professional Standards Legislation.

Registered Office, Level 30, 525 Collins Street, Melbourne VIC 3000

DISCLAIMER
This email message and any related attachments are confidential and should only 
be read by those persons to whom they were addressed. They may contain 
copyright, personal or legally privileged information. If you are not the 
intended recipient of this email, any use, copying or disclosure of this 
information is strictly prohibited. If you have received this email in error 
please notify the sender and delete this email immediately. Any 
confidentiality, privilege or copyright is not waived or lost because this 
email has been sent to you in error. Views expressed in this message are the 
views of the sender and are not necessarily views of Grant Thornton, except 
where the message expressly states otherwise. Any advice contained herein 
should be treated as preliminary advice only and subject to formal written 
confirmation. Although this email and any attachments are believed to be free 
of any virus or any other defect which may cause damage or loss, it is the 
responsibility of the recipient to ensure that they are virus‐free. Grant 
Thornton accepts no liability for any loss or damage that may occur as a result 
of the transmission of this email or its attachments to the recipient.



___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 as numbers 
have more flexibility with comparison and math operations.

To me there isn't an argument here to have support for "true" strings and the 
proto_tree_add_string_format or proto_tree_add_string_format_value seems more 
appropriate.
 
 
 
-Original Message-
From: John Dill 
To: wireshark-dev 
Sent: Mon, Sep 11, 2017 4:56 pm
Subject: [Wireshark-dev] unit_name_string for FT_STRING field types?



I have a dissector for a protocol sending packets containing ASCII strings of a 
delimited format over a TCP stream.
 
/AREA/NAME/FILLED/GREEN/1/2000/4000//
 
Sometimes the values are floating point, like
 
/ENV/-/-/1.0/90.0/100.0/-/-/-/5000.0//
 
I'm dissecting the format ok, but I can't use unit_name_string for these 
FT_STRING defined header fields.
 
I see (in 2.4.1) that unit_name_string is disabled for FT_STRING 
(​tmp_fld_check_assert is not allowing hfinfo->strings), so I've been using 
proto_tree_add_string_format..., but wondering if there's potential to allow 
FT_STRING to use unit_name_string.
 
One could classify the string contents as an integer or floating point value to 
pass to one of these functions:
 
unit_name_string_get_value
unit_name_string_get_value64
unit_name_string_get_double
 
If the string is not a valid number, or out of range, I'm not sure what the 
proper error behavior should be.  Could be to ignore the 'strings' value, throw 
an assert, or malformed packet.  It's possible that a value is missing '-' but 
I wouldn't want it to mark the packet as bogus because of it.
 
Mostly, it'd be easier putting the units in the header field definition instead 
of having a separate table of header field -> unit_name_string for these 
FT_STRING types and doing the checking/formatting myself.
 
Does this idea seem compatible with proto.c?
 
Thanks,
John Dill
 

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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").  I thought it 
was worth sharing some of that information on the -dev mailing list to give 
guidance in case anyone else wants to expand Wireshark's support of Netmon 
files. I do not have any plans to further expand the dissection, but will 
gladly answer any questions if others want to give it a try. Note this is only 
related to .cap files.  Support for .etl files has NOT been added (see bug 
6694), and I'm not sure how much of this information may apply to .etl files.

.cap files use NPL (NetMon Parsing Language?), which is a combination of a 
C-like language mixed with IDL.  It is certainly "human readable", but I think 
the meaning of some of the "IDL" parts would make it a bit too complex to make 
it worthwhile to have a "npl2wrs" tool.  However, I did notice what appears to 
be some work towards that in the Wireshark tools directory.  Jakub, any 
comments?
Message Analyzer appears to use NPL files, but also OPN files, which seem to 
have a similar format.  Not sure of the details/differences, but I used both 
for reference when adding to Wireshark functionality.

Some of the functionality I added to Wireshark for .cap support was in wiretap. 
 Most of the rest, while done with dissectors, could be considered "metadata" 
and may be "translated" into pcapng blocks.  But since .cap files were treating 
them as "frames", I did as well as that's why they ended up with dissectors.  
One of the key "frame types" would be "NetMon events".  It has an architecture 
that aligns with using a Wireshark dissector table.  I believe the "event frame 
types" can hold protocol dissection data, but I focused on the "metadata" since 
that's what was present in the captures I had (retrieved from Bugzilla)
I stayed away from protocol dissection mostly because I didn't have capture 
files for it, but also because I know Wireshark is already pretty good at that. 
 I was focused on how to "connect the dots" so that data could easily be passed 
to existing (protocol) dissection.

My two key sources of information were:
1. https://NMParsers.svn.codeplex.com/svn (just grab it with SVN client).  It's 
basically the "parser source" for NetMon. There are 2 directories, 
"Develop_Branch" and "Verified_Build_Branch".  For what I've done, I haven't 
seen a difference between the two, but I've also not done a full compare.  
Given that I believe work on Network Monitor has stopped, these may not be 
updated anymore.
2. C:\Program Files\Microsoft Message Analyzer\OPNAndConfiguration.  This is 
the parser information installed with MessageAnalyzer.  Bug 10556 
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10556) seems to give some 
information on how to extract the information without installing Message 
Analyzer, but since I'm mostly a Windows developer, this wasn't an issue for me.

To me both are comparable to Wireshark's dissector directory (with a little bit 
of wiretap mixed in to handle "metadata").

Sharkbytes:
1. frame.npl, netmon.npl and MAExported.npl (from 
NMParsers\Develop_Branch\NPL\common directory is information for wiretap 
(netmon.c).  I implemented what I thought was "most popular" and things that I 
found sample captures for.

2. grep "NetEvent.UserData" in the NMParsers directory and you'll see all of 
the potential GUIDs used for Provider IDs.  Provider IDs are the "identifier" 
to the layer following a "NetMon event".  Again, I focused on "metadata" 
dissectors, but there were over 100 GUIDs registered with "NetEvent.UserData", 
most of which are probably protocol related.

3. grep "EventDescriptor.DefaultKeyword" for a potential match with a GUID from 
NetEvent.UserData.  The "NetMon event dissector" displays the keyword (and a 
few other fields), but its the subsequent layer that really defines its meaning.

4. packet-netmon.c was used mostly for functionality I found from NPL code, 
packet-messageanalyzer.c was for code I associated with MessageAnalyzer (either 
from OPN files or NPL files that used "MA" or other indications to show it was 
for MessageAnalyzer).  Protocol dissection may go in existing dissectors (if 
related/similar) or there may be new protocols that justify new dissection 
files. packet-netmon.c, packet-messageanalyzer.c, and packet-usb.c can be used 
as current examples of how to hook into the ProviderID dissector table 
("netmon.provider_id") used by "NetMon events"

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 

Re: [Wireshark-dev] Enrich tshark data

[Michael Mann via Wireshark-dev]

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 code as string" is 
populated through a "value_string" which is a structure that translates 
integers to strings.  Typically value_strings are part of the definition of an 
integer field, so that "both" can be displayed for the field (typically string 
first).
 
One question is if its possible to filter on the string of a field that is 
defined as a "integer", but has a value_string associated with it.  I thought I 
remember some special cases (like tcp.port), but it may be that in general, you 
can't do it.  That's one reason why there is the additional "HTTP status code 
as string" field.
 
Now I presume you can pick the fields outputted for JSON, and it may be that 
you're just not including the "http.response.code.desc" field in your list.  
"http.response.code.desc" is also considered a "generated" field by the 
dissector and I'm not sure if JSON would specifically filter those out, but if 
it is, that's a bug.
 
In writing this up, I thought it may make sense to just have the 
"http.response.code" field have the value_string used by 
"http.response.code.desc", but I'm guessing it's intentionally separate because 
users want to make columns out of the "http.response.code" field and it would 
need to be "extra wide" to accommodate the long strings of the "meaning" (which 
is probably undesirable to many).

So Conall, I think the "resolution" to your problem is just to include the 
"http.response.code.desc" field in your JSON output.  If it then doesn't become 
part of the output, file a bug (https://bugs.wireshark.org) and we can take a 
look at it.
 
 
 
-Original Message-
From: Jaap Keuter 
To: Developer support list for Wireshark 
Sent: Sat, Sep 9, 2017 6:25 am
Subject: Re: [Wireshark-dev] Enrich tshark data



Hi Conall,


You’re quite in the right place here to put forward these questions. I’ll have 
a go and try to answer them.


What you spotted is the HTTP dissector adding the HTTP status field to the 
protocol tree 
(https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-http.c;hb=HEAD#l1778)


Now we’ve to look a bit at Wireshark’s design. In its core there’s EPAN, the 
dissection engine. This is where the HTTP dissector lives.
The output of the dissection engine is used in various ways. In Wireshark it’s 
used to fill the GUI, in tshark it’s used to generate the text output. 
What format this tshark text output has is determined by the command line 
parameters. Then it’s up to the output routines to include the data in the 
selected format.
Now, the question remains how is the HTTP response code description processed 
by the JSON output routines. 





On 8 Sep 2017, at 15:21, Conall Prendergast  wrote:


Hi All,


Wireshark has the ability to enrich some of the numeric values it sees. For 
example, if is sees a http status code of 200, it might print "OK" beside it, 
because HTTP 200 means OK (This is just a guess, Im not sure what it does for 
HTTP status codes).


Is it possible to add this kind of enrichment to tshark's json output? 


Regards,
Conall





___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Default encodage for FT_ABSOLUTE_TIME

[Michael Mann via Wireshark-dev]

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 specified.
All of the encoding formats still display the same way in Wireshark, the 
encoding is just to tell the dissection engine how to interpret the bytes its 
being passed from tvb.
 
 
 
-Original Message-
From: Remy Leone 
To: Developer support list for Wireshark 
Sent: Fri, Sep 8, 2017 10:38 am
Subject: [Wireshark-dev] Default encodage for FT_ABSOLUTE_TIME



Hello,


I'm looking currently at epan/dissectors/packet-zep.c and I don't see any 
encoding specified for FT_ABSOLUTE_TIME. If nothing is specified, which one is 
the default? Here is a reminder of the different encoding taken from the 
documentation that don't specify that:



 For FT_ABSOLUTE_TIME fields, the encoding specifies the form in which
 the time stamp is specified, as well as its byte order.  The time stamp
 encodings that are currently supported are:
 
 ENC_TIME_TIMESPEC - 8 bytes; the first 4 bytes are seconds since
 the UN*X epoch (1970-01-01 00:00:00 UTC) and the next 4 bytes
 are nanoseconds since that second.  (I.e., a UN*X struct
 timespec with a 4-byte time_t.)
 
 ENC_TIME_NTP - 8 bytes; the first 4 bytes are seconds since the NTP
 epoch (1900-01-01 00:00:00 GMT) and the next 4 bytes are 1/2^32's of
 a second since that second.  (I.e., a 64-bit count of 1/2^32's of a
 second since the NTP epoch, with the upper 32 bits first and the
 lower 32 bits second, even when little-endian.)
 
 ENC_TIME_TOD - 8 bytes, as a count of microseconds since the System/3x0
 and z/Architecture epoch (1900-01-01 00:00:00 GMT).
 
 ENC_TIME_RTPS - 8 bytes; the first 4 bytes are seconds since the UN*X
 epoch and the next 4 bytes are are 1/2^32's of a second since that
 second.  (I.e., it's the offspring of a mating between UN*X time and
 NTP time.)  It's used by the Object Management Group's Real-Time
 Publish-Subscribe Wire Protocol for the Data Distribution Service.
 
 ENC_TIME_TIMEVAL - 8 bytes; the first 4 bytes are seconds since the
 UN*X epoch and the next 4 bytes are microseconds since that
 second.  (I.e., a UN*X struct timeval with a 4-byte time_t.)
 
 ENC_TIME_SECS - 4 to 8 bytes, representing a value in seconds since
 the UN*X epoch.
 
 ENC_TIME_MSECS - 6 to 8 bytes, representing a value in milliseconds
 since the UN*X epoch.
 
 ENC_TIME_SECS_NTP - 4 bytes, representing a count of seconds since
 the NTP epoch.  (I.e., seconds since the NTP epoch.)
 
 ENC_TIME_RFC_3971 - 8 bytes, representing a count of 1/64ths of a
 second since the UN*X epoch; see section 5.3.1 "Timestamp Option"
 in RFC 3971.
 
 ENC_TIME_MSEC_NTP - 4-8 bytes, representing a count of milliseconds since
 the NTP epoch.  (I.e., milliseconds since the NTP epoch.)



Best regards


Rémy

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 looking at CCO and the heuristic function when I received 
your last email.
After some reading of the C dissector and some tests I arrived at the 
same conclusions, I will see now what I will implement, and how.

> In the CIP specs, they focus on  being an object class and 
> instance, but
> for some Rockwell PLCs, the  is just a string (and there is 
> no class in the message).
> That's what I mean when I refer to "classless" requests.

I never encountered this case but indeed this notion of segment is 
present in the CIP documentation, I didn't read it enough!

 
 
I believe the only time you will encounter this is with Rockwell PLCs and its 
use is starting to go towards "legacy"
status (not deprecated I'm guessing just because of backwards compatibility), 
so I wouldn't worry about it too much.  
 
 

>  >> 2. If you want to add vendor specific services to already supported
>  >> objects, that would be more difficult to do in Lua because there isn't a
>  >> dissector table hook for them.  I'm not sure there would be a way to
>  >> handle the "general" case of registering service + class into a
>  >> dissector table, but you could add dissector tables (patching
>  >> packet-cip.c) for specific objects (Identity, ConnectionManager, etc)
>  >> and submit just that part as a patch for inclusion in base Wireshark 
> code.
> This is where I started to steer you incorrectly.  The heuristic 
> functionality should
> be able to handle this case without issue.

I think in this case it would be the dissector, since the heuristic only 
triggers for common services (and we want to support vendor-specific 
services for common objects).
 
 
I believe what you want is:
1. A dissector for each vendor specific object
2. A (single) heuristic dissector for all vendor specific objects that use 
common services.
I thought I could simplify the existing CIP dissector and only use one 
heuristic dissector (and just use a switch
statement for the object IDs), but the "built in" objects have a way to list 
their attributes so they can be dissected
by the common service dissection routines (GAA, GAS, GAL, etc).  I think part 
of the reason I never added an
"external" interface for the attribute lists was I wasn't sure how to make it 
generic enough to fit into existing
Wireshark APIs.
Your 1 heuristic dissection function should look like dissect_class_cco_heur(), 
but have a switch statement for
calling each of the object classes after you've parsed the EPATH for a request. 
 A "response" should be handled
exactly like the CCO object (but I'm not sure how all of that would translate 
to Lua, trying to directly access a
C structure from p_get_proto_data)
 


> I think the intent of the cip.data_segment.iface dissector table was to 
> handle the "string"
> identifiers I mentioned with the Rockwell PLCs.  It's probably something 
> that should actually
> be removed from the dissector.

It makes sense. Why remove it though, since it can be used to support 
"classless" services?
 
 
 
Architecturally it seems simpler to have a heuristic function that registers 
with "cip.sc" table and dissects the EPATH
for the "classless" services to determine if they are truly "classless".  
Again, the only ones that use this is Rockwell
PLCs and because the information isn't in the CIP specs, I consider it 
proprietary, much like vendor-specific objects.


>  >> 4. I believe Lua will "override" any value registered to a dissector
>  >> table, so you could write the "vendor specific" portion, for say the
>  >> Identity object, but then you'd have to duplicate all of the dissection
>  >> currently being done for it in your Lua script.
>  > I did test with setting a lua dissector for Identity in the 
> cip.class.iface, and on packets
>  > with common services it wasn't triggered (I didn't have packets with 
> vendor-specific
>  > services call for Identity).  So apparently it does not override the 
> default dissector
>  > with the lua one (at least with a common service).
> Again, this issue can be handled with the heuristic dissection mentioned 
> above.

True in this case.


So to clarify I could now cover the following cases:
- Vendor-specific class, vendor-specific services with a dissector (one 
per class)
- Vendor-specific class, common services with a heuristic (to handle the 
epath and attributes)
- Common class, vendor-specific services with a dissector (again, one 
per class)

An implementation in lua seems extremely tedious, since I will have to 
re-write most of the dissection code already present in C (status, 
epath, and attribute-related services).
 
 
 
I hope you can 

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

[Michael Mann via Wireshark-dev]

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 just that we don't have a Qt 4 build environment to catch build 
errors, so they go unnoticed until someone brings them up (like bug 13909 or 
what you're doing now).
 
Is this list of compile errors in addition to the ones you found on master?  If 
you can submit a patch for the master-2.4 branch, that would certainly be 
appreciated (and accepted).   Since the 2.4 branch is mostly bugfixes (the rare 
exception being horrific UI issues), I don't think additional compile errors 
should result going forward.
 
 
-Original Message-
From: Kilian, Jens 
To: wireshark-dev 
Sent: Thu, Aug 31, 2017 10:36 am
Subject: [Wireshark-dev] Wireshark 2.4.1 build errors (with Qt 4)

Is Wireshark v2.4.1 supposed to support Qt 4 still?  I get the following 
compile errors when trying to build it in RedHat EL 7.2:

main_window.cpp:786:46:   required from here
/usr/include/QtCore/qmetatype.h:169:80: error: 'qt_metatype_id' is not a member 
of 'QMetaTypeId'
 static inline int qt_metatype_id() { return 
QMetaTypeId::qt_metatype_id(); }
  ^
main_window_slots.cpp:499:62:   required from here
/usr/include/QtCore/qmetatype.h:169:80: error: 'qt_metatype_id' is not a member 
of 'QMetaTypeId'
 static inline int qt_metatype_id() { return 
QMetaTypeId::qt_metatype_id(); }
 ^
rtp_player_dialog.cpp:207:104:   required from here
/usr/include/QtCore/qmetatype.h:169:80: error: 'qt_metatype_id' is not a member 
of 'QMetaTypeId'
 static inline int qt_metatype_id() { return 
QMetaTypeId::qt_metatype_id(); }
  ^
rtp_player_dialog.cpp:277:95:   required from here
/usr/include/QtCore/qmetatype.h:169:80: error: 'qt_metatype_id' is not a member 
of 'QMetaTypeId'

wireless_timeline.cpp: In member function 'virtual void 
WirelessTimeline::mousePressEvent(QMouseEvent*)':
wireless_timeline.cpp:118:31: error: 'class QMouseEvent' has no member named 
'localPos'
 start_x = last_x = event->localPos().x();
   ^
wireless_timeline.cpp: In member function 'virtual void 
WirelessTimeline::mouseMoveEvent(QMouseEvent*)':
wireless_timeline.cpp:127:27: error: 'class QMouseEvent' has no member named 
'localPos'
 qreal offset = event->localPos().x() - last_x;
   ^
wireless_timeline.cpp:128:21: error: 'class QMouseEvent' has no member named 
'localPos'
 last_x = event->localPos().x();
 ^
wireless_timeline.cpp: In member function 'virtual void 
WirelessTimeline::mouseReleaseEvent(QMouseEvent*)':
wireless_timeline.cpp:144:27: error: 'class QMouseEvent' has no member named 
'localPos'
 qreal offset = event->localPos().x() - start_x;
   ^
wireless_timeline.cpp:151:36: error: 'class QMouseEvent' has no member named 
'localPos'
 guint num = find_packet(event->localPos().x());
   ^
wireless_timeline.cpp: In member function 'virtual void 
WirelessTimeline::paintEvent(QPaintEvent*)':
wireless_timeline.cpp:483:31: error: 'class QPaintDevice' has no member named 
'devicePixelRatio'
 float ratio = p.device()->devicePixelRatio();
   ^
wireshark_application.cpp: In constructor 
'WiresharkApplication::WiresharkApplication(int&, char**)':
wireshark_application.cpp:850:24: error: 'QGuiApplication' has not been declared
 QPalette gui_pal = QGuiApplication::palette();
 ^

Best regards,

Jens.
___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 extra functionality in wireshark.



Sir 
   My research paper related to identifying DOS and DDOS attack.research paper 
parameter is Tx power rate.Now I want to add this functionality into wireshrak 
so the software also identify the attacks defaultly.I want your team guidance 
so we develop a better concept in wireshark. we can improve this product.

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 :
>> 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").  There should be
>> numerous examples of Lua using a dissector table (just not specifically
>> for CIP).

> I have to admit the way dissector tables work is not clear for me.
 
There are 2 types of dissector tables, one for heuristics, one for fixed values.
For the "fixed" values one, you associate a value with a dissection function.
Using "cip.class.iface" as an example, you are associating the numeric value
of your object class with the dissector table, so the CIP dissector can use
that table to decide how/what to dissect next.
With a heuristic dissection table, you just register a "heuristic" function with
the dissector table.  Within that function could can decide if the "packet" 
should
be handled by your dissector.

I mention both because I forgot that there is a heuristic dissector for service 
codes
("cip.sc").  It looks like you need a combination of a dissector function for 
your
vendor-specific class as well as a heuristic function to handle the common 
services
within your vendor specific class.
 
You can mimic the behavior of the Connection Configuration Object dissection 
for your
vendor-specific objects.  It first registers a "(CIP) object dissection 
function" with:
 
cip_class_cco_handle = create_dissector_handle( dissect_cip_class_cco, 
proto_cip_class_cco );
dissector_add_uint( "cip.class.iface", CI_CLS_CCO, cip_class_cco_handle );
 
But it also adds a huerisitic function:

heur_dissector_add("cip.sc", dissect_class_cco_heur, "CIP Connection 
Configuration Object", "cco_cip", proto_cip_class_cco, HEURISTIC_ENABLE);
 
The dissect_class_cco_heur() basically checks the EPATH for the Connection 
Configuration
Object class value and then calls the main object dissection function, 
dissect_cip_class_cco.
 
> I registered my dissector for a vendor-specific class, and I observed the 
> following
> behaviour: - When the service is common (Get_Attribute_List for example), the 
> dissector
> is not called.
> - when the service is vendor-specific, the dissector is then called.
> So I can implement the vendor-specific services for vendor-specific classes 
> at least,
> with a new dissector.
> But I don't understand why discriminate dissector in the class dissector 
> table based
> on the service being known or not, any idea why it was implemented this way? 
> Since the
> service is parsed and interpreted before the path (so the class), > wouldn't 
> it make more sense to actually make a dissector table based on the service?
 
Hopefully the explanation above satisfies your questions.

>> 2. There is no support currently for "classless" service codes (like
>> those used in Rockwell Automation PLCs), which is what
>> _https://www.wireshark.org/lists/ethereal-dev/200601/msg00174.html_ appears
>> to be talking about.

> As I understand it the service codes mentioned in that thread are class 
> specific.
> I have never encountered "classless" service codes until now, I didn't even 
> know that
> existed (as CIP doesn't implement this behaviour, or at least I couldn't find 
> it in the documentation).
 
To me, in layman's terms, the format of a CIP message is 
In the CIP specs, they focus on  being an object class and 
instance, but
for some Rockwell PLCs, the  is just a string (and there is no 
class in the message).
That's what I mean when I refer to "classless" requests.

>> 2. If you want to add vendor specific services to already supported
>> objects, that would be more difficult to do in Lua because there isn't a
>> dissector table hook for them.  I'm not sure there would be a way to
>> handle the "general" case of registering service + class into a
>> dissector table, but you could add dissector tables (patching
>> packet-cip.c) for specific objects (Identity, ConnectionManager, etc)
>> and submit just that part as a patch for inclusion in base Wireshark code.
 
This is where I started to steer you incorrectly.  The heuristic functionality 
should
be able to handle this case without issue.

>> 3. Vendor specific attributes of an object would have the same
>> difficulty in Lua

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

[Michael Mann via Wireshark-dev]

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").  There should be numerous examples of 
Lua using a dissector table (just not specifically for CIP).
2. There is no support currently for "classless" service codes (like those used 
in Rockwell Automation PLCs), which is what 
https://www.wireshark.org/lists/ethereal-dev/200601/msg00174.html appears to be 
talking about.
2. If you want to add vendor specific services to already supported objects, 
that would be more difficult to do in Lua because there isn't a dissector table 
hook for them.  I'm not sure there would be a way to handle the "general" case 
of registering service + class into a dissector table, but you could add 
dissector tables (patching packet-cip.c) for specific objects (Identity, 
ConnectionManager, etc) and submit just that part as a patch for inclusion in 
base Wireshark code.
3. Vendor specific attributes of an object would have the same difficulty in 
Lua and would need dissector tables.
4. I believe Lua will "override" any value registered to a dissector table, so 
you could write the "vendor specific" portion, for say the Identity object, but 
then you'd have to duplicate all of the dissection currently being done for it 
in your Lua script.
5. Also note that not all "open" objects are supported in packet-cip.c.  It 
would be appreciated that if you added dissection for any of those, that you 
provide a patch for integration here: https://code.wireshark.org/review (see 
https://wiki.wireshark.org/Development/SubmittingPatches for more details).  If 
you're more familiar with Lua than C, you can put the Lua script here: 
https://wiki.wireshark.org/Contrib, but I'd probably end up taking it and 
converting it to C.
 
 
-Original Message-
From: Samuel Groot 
To: wireshark-dev 
Sent: Tue, Aug 29, 2017 10:20 am
Subject: [Wireshark-dev] [RFC] Vendor-specific dissector extension for 
EtherNet/IP

Hi,I am considering writing a chained dissector in lua to support some 
vendor-specific classes, services and attributes for EtherNet/IP.After digging 
around on google or ask.wireshark.org, I couldn't find anything that would fit 
my needs (except this[1], but it's more than 10 years old), so I'm coming to 
you to have maybe some advice.Vendor-specifics in EtherNet/IP are particular in 
the sense that we need to rewrite certain things in the tree and only re-parse 
certain things.Is it the correct way to do it, or do I have to patch 
epan/dissectors/packet-cip.c and rebuild wireshark entirely?Regards,Sam 
Groot[1] 
https://www.wireshark.org/lists/ethereal-dev/200601/msg00174.html___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 ...
> 
>>
>> It also looks like we're the only people on the planet trying to integrate 
>> Gerrit and Bugzilla.
> 
> things like this makes this such a cool project to work on. :)

As an alternative to its-bugzilla we could ping and close bugs using hook 
scripts:
https://code.wireshark.org/review/Documentation/config-hooks.html
Anyone feel like writing (and debugging) a script?
 
 


I've been trying to keep up "manually" with closing bugs (especially if I'm the 
one giving the +2 and submitting) because I'm not a script writer, but until 
the issue is addressed, it would be appreciated if developers would close their 
bugs once patches with Bug:  tagline are submitted.


 
-Original Message-
From: Jaap Keuter 
To: Developer support list for Wireshark 
Sent: Fri, Aug 25, 2017 11:17 am
Subject: [Wireshark-dev] Bugs no longer autoclose?

Hi,Could it be that Gerrit-Bugzilla interaction is partially broken wrt. bug 
status?e.g. bug 14004 has a change uploaded and merged (as noted in the 
comments) but its status is still stuck at ‘UNCONFIRMED’.Even though it should 
have been moved to “IN_PROGRESS”, now that the change is merged I would expect 
the bug to be “RESOLVED”/“FIXED”.Is that a degradation between Gerrit and 
Bugzilla?Thanks,Jaap___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

If you want I can take a look.  I've added a few FT_ types in the past.
 
 
-Original Message-
From: Richard Sharpe <realrichardsha...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Sent: Sat, Aug 19, 2017 11:29 am
Subject: Re: [Wireshark-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 enough fields with the same "custom"> formatting, it's probably time 
to make it a field type (or add BASE_ type)OK, it does go back that far.In 
looking at adding FT_OUI, some of it is obvious, but I am not surewhat this 
code is doing in proto_item_fill_labelcase FT_ETHER:  
bytes = (guint8 *)fvalue_get(>value);addr.type = 
AT_ETHER;addr.len  = 6;
addr.data = bytes;addr_str 
=(char*)address_with_resolution_to_str(NULL, );
g_snprintf(label_str, ITEM_LABEL_LENGTH,   "%s: 
%s", hfinfo->name, addr_str);wmem_free(NULL, addr_str); 
   break;and I suspect that the code I need to add is more 
like this:case FT_OID:bytes = (guint8 
*)fvalue_get(>value);name = 
oid_resolved_from_encoded(NULL, bytes,fvalue_length(>value));  
tmp = oid_encoded2string(NULL, bytes,fvalue_length(>value));   
if (name) {label_fill_descr(label_str, 0, 
hfinfo,tmp, name);wmem_free(NULL, name);  } 
else {label_fill(label_str, 0, hfinfo, tmp); }  
  wmem_free(NULL, tmp);break;with 
oid_resolved_from_encoded etc replaced withget_manuf_name_if_known and a few 
other changes.Does that seem reasonable to you?There's a couple of other places 
in there where I am not sure what isgoing on, but I can stumble through ...-- 
Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 field type (or add BASE_ type)
 
 
-Original Message-
From: Richard Sharpe <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<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.This is an idea I like. However, how far back does BASE_CUSTOM 
go?> -Original Message-> From: Roland Knall <rkn...@gmail.com>> To: 
Developer support list for Wireshark <wireshark-dev@wireshark.org>> Sent: Sat, 
Aug 19, 2017 7:16 am> Subject: Re: [Wireshark-dev] Making oui_base_custom 
available more generally>> Which OUI are we talking about? Generally speaking, 
a wsutil/oui_handler.?> could be useful, as for instance, openSAFETY uses 
OUI-24 as well. So it> could be made the case, to move the OUI handling outside 
of the dissector> and into a generic wsutil or epan structure.>> cheers,> 
Roland>> On Sat, Aug 19, 2017 at 1:04 PM, Dario Lombardo> 
<dario.lombardo...@gmail.com> wrote:>> I don't think that's enough. The linker 
should be able to resolve the symbol> this way, but the compiler shouldn't. 
Then you'd have to declare it extern.> But the right thing to do is to create a 
.h file that holds the public> declaration of the .c file, and include it. This 
is a best practice> generally speaking, and it's whas is done in wireshark as 
well. Have a look> at packet-dns.c/h that do what you think. Moreover, there is 
already a file> packet-ieee80211.h: that should be the place.> Cheers,> 
Dario.>> On Sat, Aug 19, 2017 at 4:14 AM, Richard Sharpe> 
<realrichardsha...@gmail.com> wrote:>> Hi folks,>> I have a need to deal with 
OUIs in a dissector I am writing and find> that it is defined as static void in 
packet_ieee80211.c.>> Should I simply remove static from that declaration, or 
should we> promote it to some other file to make it generally available?>> --> 
Regards,> Richard Sharpe> (何以解憂？唯有杜康。--曹操)> 
___> 
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>> 
Archives:https://www.wireshark.org/lists/wireshark-dev> Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev>  
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>>>> 
___> 
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>> 
Archives:https://www.wireshark.org/lists/wireshark-dev> Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev>  
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>>> 
___> 
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:> 
https://www.wireshark.org/lists/wireshark-dev Unsubscribe:> 
https://www.wireshark.org/mailman/options/wireshark-dev> 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>> 
___> 
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>> 
Archives:https://www.wireshark.org/lists/wireshark-dev> Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev>  
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe-- 
Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

I think there may be 2 types of OUIs (so I may need help distinguishing them)
There is oui_vals (in epan/oui.h) which could useFT_UINT24 + VALS(), but then 
there is the code in packet-ieee80211.c that integrates 
get_manuf_name_if_known() (and treats FT_UINT24 as a byte array).  I had 
presumed FT_OUI would support the latter.
 
 
 
-Original Message-
From: Alexis La Goutte <alexis.lagou...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
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 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_UINT24) will be work 
too ? 



 
 
-Original Message-
From: Roland Knall <rkn...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Sent: Sat, Aug 19, 2017 7:16 am
Subject: Re: [Wireshark-dev] Making oui_base_custom available more generally



Which OUI are we talking about? Generally speaking, a wsutil/oui_handler.? 
could be useful, as for instance, openSAFETY uses OUI-24 as well. So it could 
be made the case, to move the OUI handling outside of the dissector and into a 
generic wsutil or epan structure.


cheers,
Roland



On Sat, Aug 19, 2017 at 1:04 PM, Dario Lombardo <dario.lombardo...@gmail.com> 
wrote:

I don't think that's enough. The linker should be able to resolve the symbol 
this way, but the compiler shouldn't. Then you'd have to declare it extern. But 
the right thing to do is to create a .h file that holds the public declaration 
of the .c file, and include it. This is a best practice generally speaking, and 
it's whas is done in wireshark as well. Have a look at packet-dns.c/h that do 
what you think. Moreover, there is already a file packet-ieee80211.h: that 
should be the place.
Cheers,
Dario.




On Sat, Aug 19, 2017 at 4:14 AM, Richard Sharpe <realrichardsha...@gmail.com> 
wrote:

Hi folks,

I have a need to deal with OUIs in a dissector I am writing and find
that it is defined as static void in packet_ieee80211.c.

Should I simply remove static from that declaration, or should we
promote it to some other file to make it generally available?

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___Sent 
via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___Sent 
via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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 available more generally



Which OUI are we talking about? Generally speaking, a wsutil/oui_handler.? 
could be useful, as for instance, openSAFETY uses OUI-24 as well. So it could 
be made the case, to move the OUI handling outside of the dissector and into a 
generic wsutil or epan structure.


cheers,
Roland



On Sat, Aug 19, 2017 at 1:04 PM, Dario Lombardo  
wrote:

I don't think that's enough. The linker should be able to resolve the symbol 
this way, but the compiler shouldn't. Then you'd have to declare it extern. But 
the right thing to do is to create a .h file that holds the public declaration 
of the .c file, and include it. This is a best practice generally speaking, and 
it's whas is done in wireshark as well. Have a look at packet-dns.c/h that do 
what you think. Moreover, there is already a file packet-ieee80211.h: that 
should be the place.
Cheers,
Dario.




On Sat, Aug 19, 2017 at 4:14 AM, Richard Sharpe  
wrote:

Hi folks,

I have a need to deal with OUIs in a dissector I am writing and find
that it is defined as static void in packet_ieee80211.c.

Should I simply remove static from that declaration, or should we
promote it to some other file to make it generally available?

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Vendor-specific dissectors for 802.11

[Michael Mann via Wireshark-dev]

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 is only a case or two.  Then a situation like 
yours comes along, and it gets changed. It also looks like "public fields" may 
need its own dissector table for vendor specific functionality too.

 
 
-Original Message-
From: Иван Николов 
To: wireshark-dev 
Sent: Sun, Aug 13, 2017 10:55 am
Subject: [Wireshark-dev] Vendor-specific dissectors for 802.11



Hello,

I'm working on a way to parse a vendor-specific packets IEEE 802.11 packets, in 
particular I want to analyze packet captures from ESP8266 (the ESP-NOW 
protocol). I wrote a proof-of-concept dissector for the protocol and edited the 
`epan/dissectors/packet-ieee80211.c` file and inserted my dissector manually in 
the `add_ff_action_vendor_specific` function then recompiled Wireshark from the 
modified source. While this did work for me, I can't help but feel like this is 
a problem that could be solved better - right now I have to recompile Wireshark 
from source on every release.

The function I'm referencing has a `switch` statement for the OUI with 2 cases 
(OUI_MARVELL and OUI_WFA) and a default case, which has a comment "Don't know 
how to handle this vendor".

I'd like to ask whether the community is interested in a patch, including 
another dissector table for that very purpose - allowing Wireshark users to 
write dissectors in Lua and to not have to patch C code in order to analyze 
traffic, containing unknown 802.11 vendor-specific data.

I'm interested in implementing this functionality, but I'm unsure if I have the 
required knowledge of the inner workings of Wireshark. Moreover, I'm not sure 
if the decision to NOT include such a dissector table is intentional.

I'm hoping someone can point me to the 'correct' way to solve the problem of 
dissectors for vendor specific data, or in case this is not currently possible, 
this post starts a discussion on the topic of whether this is needed in 
Wireshark and how to properly implement this at the architecte level.

I previously asked a similar question in the ask.wireshark.org portal - 
https://ask.wireshark.org/questions/56816/ieee-80211-vendor-specific-action . 
It includes an example capture (relevant part starts at packet No. 587).

Best regards, Ivan


___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checkapi prefs

[Michael Mann via Wireshark-dev]

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: [Wireshark-dev] checkapi prefs



I've got this error from checkAPI_epan target:



prefs.c: error: found these preference variables used in more than one 
prefs_register_*_preference:
guint *var, const char **var, , range_t **var



I can't figure out what does it mean. Can anyone help?

___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

The issue is that extcaps are started before preferences are read/loaded.  I 
believe this was discovered when talking able enabling/disabling extcaps 
through preferences to help startup times (because many users don't use extcaps)
I thought about maybe creating an "early preferences" grouping (reuse 
preference architecture, but for things needed a lot closer to startup), but it 
hasn't materialized.
 
 
 
-Original Message-
From: Dario Lombardo <lom...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Cc: Michael Mann <mman...@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 thought we already had)?  Or 
build configuration? (or "other")
 
 
-Original Message-
From: Dario Lombardo <lom...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
Sent: Sat, Jul 29, 2017 11:23 am
Subject: Re: [Wireshark-dev] Conditional compilation (debug)


We don't have an extcap branch in the config,  do we? Wouldn't be worth to have 
one for such a configurations?

On Friday, July 28, 2017, Roland Knall <rkn...@gmail.com> wrote:

I would not distinguish between self-builds and buildbot builds. There are 
extcap developers out there, who use the released Wireshark version to develop 
extcap interfaces and also would benefit greatly from using such debug 
scenarios. And I would not want to tell them to explicitly build a development 
version, just to develop an extcap. More specifically, if they develop the 
extcap with Python, they may not even be able easily to build Wireshark at all.


On the other side, not every dev wants to see the debug functionality for 
extcap, so having those users stuck with debug output may also not be 
advisable. 


Last, some issues can come up, especially with printf stuff, where debug 
outputs actually hinder development. If you have a timing-constraint related 
bug, it may not appear in a debug version, because the debug code may slow down 
the utility enough, so that the issue may not appear, but it would appear in 
the release version. Not every developer thinks of such a thing and would end 
up hunting bugs they cannot see.



So, please do integrate such a feature in the normal code, but make it 
configurable via preference for instance, to enable/disable the functionality. 
Do not distinguish, if it is a dev-build or release build



cheers
Roland



On Thu, Jul 27, 2017 at 10:11 PM, Dario Lombardo <dario.lombardo...@gmail.com> 
wrote:

I was thinking to something like CMAKE_BUILD_TYPE (Debug/Release), but I'm not 
sure it fits the purpose and anyway it is cmake specific.


The goal is: I want to make the debug of the interaction between ui and extcaps 
easier. For that I'd like to use some debug entries in the extcap interface 
dialog. Those flags are mostly developer-oriented, then I'd like to get rid of 
them in release builds, although I don't know if wireshark release builds and 
others differ in some way.


I'd like something that mimics assert() behavior, if I'm not mistaken.




On Thu, Jul 27, 2017 at 6:58 PM, Jeff Morriss <jeff.morriss...@gmail.com> wrote:







On Thu, Jul 27, 2017 at 12:34 PM, Dario Lombardo <dario.lombardo...@gmail.com> 
wrote:

Hi
I'd like to add some code that appears only in development builds of wireshark. 
Is there some define that helps me understand if I am in such a case, both in 
autotools and cmake?



Define "development build."  Do you mean 2.3.x or 2.5.x or do you mean anything 
not built on a buildbot?  For the latter we frequently just check if we're 
running in a build directory (there's also an environment variable for that).



___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe





-- 


Naima is online.



___Sent 
via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/opt

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

[Michael Mann via Wireshark-dev]

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 (debug)


We don't have an extcap branch in the config,  do we? Wouldn't be worth to have 
one for such a configurations?

On Friday, July 28, 2017, Roland Knall  wrote:

I would not distinguish between self-builds and buildbot builds. There are 
extcap developers out there, who use the released Wireshark version to develop 
extcap interfaces and also would benefit greatly from using such debug 
scenarios. And I would not want to tell them to explicitly build a development 
version, just to develop an extcap. More specifically, if they develop the 
extcap with Python, they may not even be able easily to build Wireshark at all.


On the other side, not every dev wants to see the debug functionality for 
extcap, so having those users stuck with debug output may also not be 
advisable. 


Last, some issues can come up, especially with printf stuff, where debug 
outputs actually hinder development. If you have a timing-constraint related 
bug, it may not appear in a debug version, because the debug code may slow down 
the utility enough, so that the issue may not appear, but it would appear in 
the release version. Not every developer thinks of such a thing and would end 
up hunting bugs they cannot see.



So, please do integrate such a feature in the normal code, but make it 
configurable via preference for instance, to enable/disable the functionality. 
Do not distinguish, if it is a dev-build or release build



cheers
Roland



On Thu, Jul 27, 2017 at 10:11 PM, Dario Lombardo  
wrote:

I was thinking to something like CMAKE_BUILD_TYPE (Debug/Release), but I'm not 
sure it fits the purpose and anyway it is cmake specific.


The goal is: I want to make the debug of the interaction between ui and extcaps 
easier. For that I'd like to use some debug entries in the extcap interface 
dialog. Those flags are mostly developer-oriented, then I'd like to get rid of 
them in release builds, although I don't know if wireshark release builds and 
others differ in some way.


I'd like something that mimics assert() behavior, if I'm not mistaken.




On Thu, Jul 27, 2017 at 6:58 PM, Jeff Morriss  wrote:







On Thu, Jul 27, 2017 at 12:34 PM, Dario Lombardo  
wrote:

Hi
I'd like to add some code that appears only in development builds of wireshark. 
Is there some define that helps me understand if I am in such a case, both in 
autotools and cmake?



Define "development build."  Do you mean 2.3.x or 2.5.x or do you mean anything 
not built on a buildbot?  For the latter we frequently just check if we're 
running in a build directory (there's also an environment variable for that).



___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe





-- 


Naima is online.



___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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



Hi Paul,



2017-07-28 19:34 GMT+02:00 Paul Offord :


Hi,
 
I’d like to use the function proto_deregister_protocol in a dissector.  The 
problem is that when I build the dissector I get:
 
packet-bds.obj : error LNK2019: unresolved external symbol 
proto_deregister_protocol referenced in function clean_up
 
I’ve included proto.h in the source code.  Why isn’t the linker finding this 
function?




Are you building a plugin?  proto_deregister_protocol() symbol is not exported 
currently (it does not have WS_DLL_PUBLIC in its declaration)


Best regards,

Pascal.
 



 
I’m using VS2013 on Windows 10 and I pulled the latest version of the master 
branch.
 
Thanks and regards…Paul
 
 

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe





___Sent 
via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt translations when refactoring

[Michael Mann via Wireshark-dev]

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 headers are 
stored in the .ui file, but with the model the data of the .ui file isn't used. 
 Is there any reason to keep the column info in the .ui file?  Does it help 
provide context to translators?  (Although my understanding is that the 
developers that have provided translation are familiar with Wireshark, unlike 
some general software translation services) If it's removed, do the translators 
have to do some rework even those the column names haven't changed?   I'm just 
wrapping the existing English names with the tr() function.
Any guidance on how to approach this (and future) refactors would be 
appreciated.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

If you filter string is "smb2", "dns", the reason the filter works is there is 
a field added to the tree with that name (typically the proto_id).   There is 
no "col.proto == smb2" filter.  Many dissectors have the proto id as the first 
field in their tree and that allows the filterability.  
 
 
 
-Original Message-
From: Richard Sharpe <realrichardsha...@gmail.com>
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
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 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 seems to work for some protocols. Ie, if Isearch on smb2, dns, etc, 
it works.I wonder what the difference is ...>> -Original Message-> 
From: Richard Sharpe <realrichardsha...@gmail.com>> To: Developer support list 
for Wireshark <wireshark-dev@wireshark.org>> Sent: Sat, Jul 1, 2017 2:31 pm> 
Subject: Re: [Wireshark-dev] Using col_set_str(pinfo->cinfo, COL_PROTOCOL,> 
"some_string") but cannot filter on some_string>> On Sat, Jul 1, 2017 at 10:20 
AM, Darien Spencer <cusn...@mail.com> wrote: >>> The protocol filter isn't 
based on the value in the protocol column. >> Instead it's based on the value 
given to the protocol registration method> 'proto_register_protocol' > Look at 
the example here: >> 
https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html > the> 
filter will be 'foo' since the 3rd argument to this method is 'foo'. > Did> you 
use 'some_string' there as well? Yeah, I just went back and made sure> that the 
third argument was the same, including case, as what I used in> col_set_str. -- 
Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)> 
___> 
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:> 
https://www.wireshark.org/lists/wireshark-dev Unsubscribe:> 
https://www.wireshark.org/mailman/options/wireshark-dev> 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>> 
___> 
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>> 
Archives:https://www.wireshark.org/lists/wireshark-dev> Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev>  
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe-- 
Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Michael Mann via Wireshark-dev]

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, 
"some_string") but cannot filter on some_string

On Sat, Jul 1, 2017 at 10:20 AM, Darien Spencer  wrote:>> The 
protocol filter isn't based on the value in the protocol column.> Instead it's 
based on the value given to the protocol registration method 
'proto_register_protocol'> Look at the example here:> 
https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html> the filter 
will be 'foo' since the 3rd argument to this method is 'foo'.> Did you use 
'some_string' there as well?Yeah, I just went back and made sure that the third 
argument was thesame, including case, as what I used in col_set_str.-- 
Regards,Richard 
Sharpe(何以解憂？唯有杜康。--曹操)___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] The "right" Qt header files

[Michael Mann via Wireshark-dev]

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 generated header 
files (that I rarely have to reference because they are generated).  In order 
to get the "real" header files, I have to search through the External 
Dependencies folder, which makes it much more unmanageable.  Is this just a 
CMake "feature"?  Is there something simple that can be done to either:
1. Create a new (virtual) folder for the "real" header files
2. Create a new (virtual) folder for the "Qt generated" header files (so the 
"real" ones can go in the Header Files folder.
3. While we're at it, create a (virtual) folder for the .ui files

I will gladly work on a patch if someone can point me in the right direction of 
places to modify.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe