Re: [Wireshark-dev] Setcap in ubuntu 20.04

On 06/01/21 20:32, Dario Lombardo wrote: Another user on SO suggested a fix https://stackoverflow.com/questions/58255970/wireshark-dumpcap-with-setcap-set-to-no-root-capture-failes-to-start-in-ubuntu-1

Re: [Wireshark-dev] Dissector functions and variables that could be static

Hi Martin, As you said some functions may only be used by third party plugins so indiscriminately removing every exported but not used function would be a bad policy. Even if they're not actually being used right now, who knows, they may be part of some public API for plugins, so for use as n

Re: [Wireshark-dev] File rename impacts Gitlab history

On 26/02/21 16:48, chuck c wrote: https://gitlab.com/wireshark/wireshark/-/commit/50dbe4df7fd7a5e4e1a27fd5046981486d350994 Rename packet-ssl* to packet-tls* Looking through history of https://gitlab.com

Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef

gitlab.com/constg2021/wireshark On 31/03/21 21:00, Gerald Combs wrote: Hi Constantine, You receivied the failure notice because: - You pushed a commit to gitlab.com/constg2021/wireshark. Was this for a merge request for wireshark/wireshark? From GitLab's perspective it dosen't matter. constg

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

It would be nice to fix this in a way that could be used from Lua, to make Lua dissectors first-class citizens and allow them to talk to C dissectors (and vice-versa). On 30/05/21 11:36, Graham Bloice wrote: When I made that change to MQTT I failed to notice that it called other dissectors wit

Re: [Wireshark-dev] Unit testing dissector code

Hi Martin, This is promising. I think dissecting a TVB and walking the proto_tree to assert the result is probably the way to go about implementing a dissector test suite (instead of reading a pcap with tshark and grepping the output). But regarding your PoC having to give extern linkage to

Re: [Wireshark-dev] Unit testing dissector code

On 14/06/21 22:01, Martin Nyhus wrote: On 05/06/2021 02:33, João Valverde wrote: But regarding your PoC having to give extern linkage to the internal dissector code is a big drawback IMO, even if it isn't visible in a DLL (because we use default hidden visibility when the compiler supports it)

Re: [Wireshark-dev] Unit testing dissector code

On 15/06/21 05:02, João Valverde via Wireshark-dev wrote: On 14/06/21 22:01, Martin Nyhus wrote: On 05/06/2021 02:33, João Valverde wrote: But regarding your PoC having to give extern linkage to the internal dissector code is a big drawback IMO, even if it isn't visible in a DLL (be

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

On 16/06/21 15:36, David Perry wrote: Sorry to drag up an old topic, but I've been thinking about this: Message: 5 Date: Sat, 29 May 2021 09:32:29 +0200 From: Anders Broman To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Calling a dissector: Type for data parameter

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

On 22/06/21 01:26, John Thacker wrote: On Mon, Jun 21, 2021 at 2:21 PM João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org>> wrote: On 16/06/21 15:36, David Perry wrote: > Sorry to drag up an old topic, but I've been thinking about this: >

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

On 22/06/21 03:35, John Thacker wrote: On Mon, Jun 21, 2021 at 9:28 PM João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org>> wrote: On 22/06/21 01:26, John Thacker wrote: > On Mon, Jun 21, 2021 at 2:21 PM João Valverde via Wireshark-dev > mail

Re: [Wireshark-dev] Incorrect checksum calculation for UDP packet with ipv6 extension header

Hi, The final destination address for the packet is 505:505:505:505:505:505:505:505. Why would you think it is not? When the kernel is routing the packet (at 4ea1::::11) it does not look at the UDP checksum to accept/reject it. Regards, João On 7/8/21 7:56 PM, Hupfer, Michael via

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 16:52, Evan Huus wrote: I've been thinking recently about starting the process of getting rid of the "global" wmem scope methods (wmem_packet_scope, wmem_file_scope, etc) in favour of passing them around in arguments (or in pinfo, or something). This would let us drop a bunch of in-

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 19:13, Evan Huus wrote: On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev wrote: On 12/07/21 16:52, Evan Huus wrote: I've been thinking recently about starting the process of getting rid of the "global" wmem scope methods (wmem_packet_scope, wmem_

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 19:48, Evan Huus wrote: On Mon, Jul 12, 2021 at 14:42 João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org>> wrote: On 12/07/21 19:13, Evan Huus wrote: > On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev > mailto:w

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 12:28, Marco Davids (SIDN) via Wireshark-dev wrote: Hello, I have an idea for a new feature in Wireshark and would like to hear your take on it: In Wireshark, under the 'Ethernet II'-section (when the 'name resolution' preference is set appropriately) the MAC addresses are 're

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 15:44, Marco Davids (SIDN) wrote: Hi João, Op 30-07-21 om 16:20 schreef João Valverde via Wireshark-dev: Address:    2001:db8::be05:43ff:fefb:281f translates into:    bc:05:43:fb:28:1f is:    'AVM GmbH' There is already an IPv6 "SA MAC" field in

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 18:35, Marco Davids (SIDN) wrote: Op 30-07-21 om 17:29 schreef João Valverde: Address:    2001:db8::be05:43ff:fefb:281f translates into:    bc:05:43:fb:28:1f is:    'AVM GmbH' There is already an IPv6 "SA MAC" field in Wireshark that does what you want. Many thank

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 31/07/21 01:56, Marco Davids (SIDN) wrote: Op 30-07-21 om 21:10 schreef João Valverde via Wireshark-dev: Also, I have not find any aggregate statistics just yet. But nevertheless still happy with this nice feature. The statistics for SLAAC/OUI don't exist. What I was trying to s

Re: [Wireshark-dev] Filtering USB HID fields

On 29/09/21 07:22, Tomasz Moń wrote: Hello, USB HID Usage Tables 1.22 specifies plenty of usages. Usages include for example, keyboard keys, LEDs, buttons, VR controls, etc. Usages are grouped into pages. There are plenty of usages, e.g. button page alone is 65536 items (0x means no button

Re: [Wireshark-dev] Unable to compile latest master

On 04/10/21 14:29, Ivan Nardi wrote: Hi I am not able to compile the latest master, even if I start from scratch (on ubuntu 20.04). Everything was fine until 1-2 weeks ago. ivan@ivan-Latitude-E6540:~/svnrepos/wireshark(master)$ mkdir wireshark-master-asan ivan@ivan-Latitude-E6540:~/svnrepos/wi

Re: [Wireshark-dev] New Warnings on Windows builds? Related to defilter changes?

It's related for sure, I will investigate, thanks. On 05/10/21 07:15, Anders Broman via Wireshark-dev wrote: Hi, Recently these warnings started to show up C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(49,1): warning C4005

Re: [Wireshark-dev] 3.6.0 release schedule

On 10/6/21 19:42, Jaap Keuter wrote: Hi, Are those wmem / pinfo->pool changes completed? Would be nice if that was consistent before branching. Is dfilter stabilised already? I don't really have a roadmap, I'm just taking a fresh look at the code for general improvements, bug fixing, learni

Re: [Wireshark-dev] On MR 4428

On 10/6/21 11:58, Jaap Keuter wrote: Hi, Looking at MR 4428 (cherry picked from commit 96cfaf67 ) it introduces a new symbol in the wiretap 11 library (wtap_uses_lua_filehandler). The debian symbols file contains the addition

Re: [Wireshark-dev] 3.6.0 release schedule

time well IMO. Thanks, Jaap On 7 Oct 2021, at 11:49, João Valverde via Wireshark-dev wrote: On 10/6/21 19:42, Jaap Keuter wrote: Hi, Are those wmem / pinfo->pool changes completed? Would be nice if that was consistent before branching. Is dfilter stabilised already? I don'

[Wireshark-dev] Display filter field variables

Hi, The GUI display filter has an interesting but little-known (?) feature to replace field values for the selected frame with the syntax ${}, which I only learned about in bug #15504, and confused me at first. This all happens before the expression is compiled and is different from display f

Re: [Wireshark-dev] Display filter field variables

gt; https://gitlab.com/wireshark/wireshark/-/commit/9865b6346f6442bc8326cde55e5f012250748131 <https://gitlab.com/wireshark/wireshark/-/commit/9865b6346f6442bc8326cde55e5f012250748131> On Fri, Oct 8, 2021 at 10:10 AM João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org&

Re: [Wireshark-dev] Warning message when starting wireshark "color_filters.c:658 -- read_filters_file(): Could not compile "Checksum Errors" in colorfilters "

I will check. Sorry I missed this. On 08/10/21 11:56, Anders Broman via Wireshark-dev wrote: Hi, Top of trunk I get ** (wireshark:13228) 12:52:43.789284 [Epan WARNING] C:\Development\wireshark\epan\color_filters.c:658 -- read_filters_file(): Could not compile "Checksum Errors" in colorfilter