[Wireshark-dev] Remote Developer Den, November 2021

Hi all, I've scheduled the next remote Developer Den for Tuesday, November 23rd. This is a remote version of the Developer Den at SharkFest, a room that is set aside for office hours where everyone is welcome to stop in, say hello, ask questions, etc. The link below has a "join from browser"

[Wireshark-dev] Wireshark 3.6.0rc3 is now available

I'm proud to announce the release of Wireshark 3.6.0rc3. This is the third release candidate for Wireshark 3.6. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. What’s New Many

[Wireshark-dev] Lint for Qt Slots/Signals

This is a pretty old forum question: https://www.qtcentre.org/threads/44762-Static-connection-analysis-tool Should the make or compiler catch missing slots? ___ Sent via:Wireshark-dev mailing list Archives:

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

One of the other main reasons is that some users switch between different versions of Wireshark and if a preference has been "removed" (not registered as obsolete) the preferences file will be modified to have that preference removed, which would result in it being restored to a "default"

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

[Wireshark-dev] a bug or a feature

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

Re: [Wireshark-dev] Wiki editor permission request

Done. On 10/31/21 12:59 AM, manabu hirose wrote: Hi, I would like permission to edit the Wireshark wiki. My GitLab username is @manabapp. ___ Sent via:Wireshark-dev mailing list Archives:

[Wireshark-dev] Wiki editor permission request

Hi,I would like permission to edit the Wireshark wiki. My GitLab username is @manabapp. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe:

Re: [Wireshark-dev] How to generate epan/dissectors/packet-skinny.c?

Hi ALexis, > from packet-skinny.c.in > # Dependencies: > # - python2.x > # - cog.py: (pip install cogapp / http://nedbatchelder.com/code/cog/ > ) > # - python.xml > # - python.xml.sax > # > > Tested on Ubuntu 18.04 (TLS) (with

Re: [Wireshark-dev] How to generate epan/dissectors/packet-skinny.c?

Hi Jirka, from packet-skinny.c.in # Dependencies: # - python2.x # - cog.py: (pip install cogapp / http://nedbatchelder.com/code/cog/) # - python.xml # - python.xml.sax # Tested on Ubuntu 18.04 (TLS) (with python2) and work for me.. On Sat, Oct 30, 2021 at 4:39 PM Jirka Novak wrote: > Hi, >

[Wireshark-dev] How to generate epan/dissectors/packet-skinny.c?

Hi, based on notice of Jörg Mayer (thank you), I tried to generate epan/dissectors/packet-skinny.c from epan/dissectors/packet-skinny.c.in. The command line should be: cog.py -D xmlfile=tools/SkinnyProtocolOptimized.xml -d -c -o epan/dissectors/packet-skinny.c

Re: [Wireshark-dev] Gitlab missing feature compared to Github

Hi, What about just entering the commit in the GitLab search box? There you get the commit, parent commit, the merge request, the pipeline, etc. all just one click away. Basically the same thing. Thanks, Jaap > On 30 Oct 2021, at 11:02, Joerg Mayer wrote: > > Hello, > > there is one very

Re: [Wireshark-dev] Gitlab missing feature compared to Github

> there is one very valuable feature of github that was lost in the transition > to giblab: > The commit message does no longer reference the merge request, making it way > harder to > look at the discussion leading to a merge. +1. I really miss this feature (of Gerrit)! Incredibly useful Ivan

[Wireshark-dev] Gitlab missing feature compared to Github

Hello, there is one very valuable feature of github that was lost in the transition to giblab: The commit message does no longer reference the merge request, making it way harder to look at the discussion leading to a merge. Can this feature please be readded? Thanks! Jörg -- Joerg Mayer

Re: [Wireshark-dev] make rpm-package does not build custom dissectors ...

On Fri, Oct 29, 2021 at 7:56 AM Richard Sharpe wrote: > > Hi folks, > > In one project I have a bunch of custom dissectors in a 3.5.0 build. > > They are all defined in epan/dissectors/CMakeListsCustom.txt. > > When I run cmake it tells me it found the custom stuff. > > Then when I run make it

[Wireshark-dev] make rpm-package does not build custom dissectors ...

Hi folks, In one project I have a bunch of custom dissectors in a 3.5.0 build. They are all defined in epan/dissectors/CMakeListsCustom.txt. When I run cmake it tells me it found the custom stuff. Then when I run make it builds them (it logs each custom dissector being build.) However, when I

Re: [Wireshark-dev] pipeline failed

On 10/28/21 12:29 PM, Zoran Bošnjak wrote: Hello wireshark developers, please advice how do I reproduce the pipeline build failure in local environment. In particular, this one: https://gitlab.com/zoranbosnjak/wireshark/-/pipelines/397393242 The following problems are reported on merge

[Wireshark-dev] pipeline failed

Hello wireshark developers, please advice how do I reproduce the pipeline build failure in local environment. In particular, this one: https://gitlab.com/zoranbosnjak/wireshark/-/pipelines/397393242 The following problems are reported on merge request: 1. Checking cache for Code Checks + Clang

Re: [Wireshark-dev] Issue with the NR-RRC Di-sector

Hi, Le jeu. 28 oct. 2021 à 17:45, Chilla Sunil Kumar-Trainee < csku...@parallelwireless.com> a écrit : > Hi, > > I had an issue with RRC messages. > >1. In F1Setup Request message , it is not Showing the complete message >information. SIB1 Information is missing and showing that

Re: [Wireshark-dev] How to test legacy (glib-compat) code

On Wed, Oct 27, 2021, 12:54 PM Gerald Combs wrote: > The oldest version of GLib that we build with is 2.56.1 on the CentOS 7 > builder: > > CentOS 7 2.56.1 > CentOS 8 2.56.4 > Debian 2.66.8 > Fedora 2.68.4 > macOS ARM 2.68.4 > macOS Intel2.58.3 > openSUSE

Re: [Wireshark-dev] How to test legacy (glib-compat) code

On Wed, Oct 27, 2021 at 09:53:43AM -0700, Gerald Combs wrote: > The oldest version of GLib that we build with is 2.56.1 on the CentOS 7 > builder: > > CentOS 7 2.56.1 ... > Is there any reason we shouldn't increase the minimum GLib version to 2.56 in > the master and 3.6 branches? That

Re: [Wireshark-dev] How to test legacy (glib-compat) code

The oldest version of GLib that we build with is 2.56.1 on the CentOS 7 builder: CentOS 7 2.56.1 CentOS 8 2.56.4 Debian 2.66.8 Fedora 2.68.4 macOS ARM 2.68.4 macOS Intel2.58.3 openSUSE 15.2 2.62.6 Ubuntu 2.64.6 Win32 2.66.4 Win64

[Wireshark-dev] How to test legacy (glib-compat) code

Hello, I've created a merge request (https://gitlab.com/wireshark/wireshark/-/merge_requests/4820) that requires a newer version (2.56) of glib than the minimum we require in cmake (2.38), so I created a glib-compat entry to emulate the required functionality via an older function that has

Re: [Wireshark-dev] USB Attached SCSI dissector

On Monday, October 25th, 2021 at 8:11 PM, Tomasz Moń wrote: > If you have some major questions, then in my opinion it is best to > open it as early as possible - just make sure to mark it as draft. I've already opened a merge request. (Things ended up being easier than I anticipated.) I think

Re: [Wireshark-dev] USB Attached SCSI dissector

On Monday, October 25th, 2021 at 3:57 PM, Kennedy, Smith (Wireless & IPP Standards) wrote: > The "Universal Serial Bus Common Class Specification" > (https://usb.org/sites/default/files/usbccs10.pdf) > discusses matching "drivers" to devices based on the device's or > interface's class, subclass

[Wireshark-dev] Zigbee stack NCP dissector: new WTAP_ENCAP or extension to 802.15.4?

Hi all, We are developing Zigbee protocol stack ZBOSS. The stack has serial commands interface - NCP. We implemented a dissector of that NCP protocol for Wireshark and want to publish it. The idea is that we can display NCP commands and Zigbee traffic between the stack and Zigbee transceiver

Re: [Wireshark-dev] USB Attached SCSI dissector

On Mon, Oct 25, 2021 at 9:08 PM Guy Harris wrote: > On Oct 25, 2021, at 12:03 PM, Tomasz Moń wrote: > > The heuristic should not be the main USB traffic detection method > > IMHO. The main thing is that people don't necessarily understand that > > capturing full enumeration sequence (aka

Re: [Wireshark-dev] USB Attached SCSI dissector

On Sat, Oct 23, 2021 at 3:07 AM Aidan MacDonald via Wireshark-dev wrote: > I have two questions. First, is it fine to open a merge request early on and > keep updating it as I add functionality? Or is it preferred to wait until > it's more complete? If you have some major questions, then in my

Re: [Wireshark-dev] USB Attached SCSI dissector

On Oct 25, 2021, at 12:03 PM, Tomasz Moń wrote: > The heuristic should not be the main USB traffic detection method > IMHO. The main thing is that people don't necessarily understand that > capturing full enumeration sequence (aka starting capture before > plugging in the device) will give you

Re: [Wireshark-dev] USB Attached SCSI dissector

On Mon, Oct 25, 2021 at 4:57 PM Kennedy, Smith (Wireless & IPP Standards) via Wireshark-dev wrote: > The "Universal Serial Bus Common Class Specification" > (https://usb.org/sites/default/files/usbccs10.pdf) discusses matching > "drivers" to devices based on the device's or interface's class,

Re: [Wireshark-dev] Non-core cherry pick

Long time listener. First time cherry-picker. I was just hoping to get the tick marks around tshark -G folders in the 3.6 release notes. Otherwise no need for me to cherry pick. If the MRs I submit need to be in releases it's done by the person doing the actual merge. There is a News.txt in

Re: [Wireshark-dev] USB Attached SCSI dissector

On Oct 22, 2021, at 10:36 PM, Guy Harris mailto:ghar...@sonic.net>> wrote: On Oct 22, 2021, at 6:06 PM, Aidan MacDonald via Wireshark-dev mailto:wireshark-dev@wireshark.org>> wrote: > Second, the hooks provided by the generic USB dissector seemingly aren't a > good fit. Basically, it seems

Re: [Wireshark-dev] Non-core cherry pick

On Sun, Oct 24, 2021 at 9:59 PM chuck c wrote: > > https://gitlab.com/wireshark/wireshark/-/commit/51e1381b235b3fad563f5ec7467ea4e001f2605b > > When I select cherry-pick to release-3.6, I get the message "You can only > create or edit files when you are on a branch". > > What's the best way to

[Wireshark-dev] Non-core cherry pick

https://gitlab.com/wireshark/wireshark/-/commit/51e1381b235b3fad563f5ec7467ea4e001f2605b When I select cherry-pick to release-3.6, I get the message "You can only create or edit files when you are on a branch". What's the best way to have this added to 3.6? thanks chuckc

Re: [Wireshark-dev] I have added another file to wireshark but keep getting unresolved references

On Sun, Oct 24, 2021 at 7:07 AM Anders Broman via Wireshark-dev wrote: > > Hi, > Did you try to delete the build dir and re-run CMake? I did, but it turned out to be a stupid mistake. The function in question had a forward declaration earlier on in the code that declared it static :-( > Regards

Re: [Wireshark-dev] I have added another file to wireshark but keep getting unresolved references

Hi, Did you try to delete the build dir and re-run CMake? Regards Anders -Original Message- From: Wireshark-dev On Behalf Of Richard Sharpe Sent: den 24 oktober 2021 15:17 To: Developer support list for Wireshark Subject: [Wireshark-dev] I have added another file to wireshark but keep

[Wireshark-dev] I have added another file to wireshark but keep getting unresolved references

Hi folks, I have added another file to Wireshark but when I build I keep getting this: -- [ 79%] Linking C executable run/sharkd /usr/bin/ld: run/libwireshark.so.14.0.8: undefined reference to `dissect_neighbor_report' collect2: error: ld returned 1 exit status make[2]:

Re: [Wireshark-dev] USB Attached SCSI dissector

On Oct 22, 2021, at 6:06 PM, Aidan MacDonald via Wireshark-dev wrote: > Second, the hooks provided by the generic USB dissector seemingly aren't a > good fit. Basically, it seems to use only the interface class to decide what > sub-dissector to call, but UASP uses the mass storage class like

[Wireshark-dev] USB Attached SCSI dissector

I'm starting to write a USB Attached SCSI dissector, since Wireshark seems to be lacking one. It's my first time contributing to Wireshark. I'm in the very early phases, I have it dissecting some UASP-specific descriptors and packet header fields but I'm not yet handing off any SCSI stuff. I

Re: [Wireshark-dev] Debianbuild fails on Ubuntu 18.04

Hi, Thanks a lot Balint! I will try it out as soon as I can. Regards Anders -Original Message- From: Bálint Réczey Sent: den 21 oktober 2021 10:48 To: Developer support list for Wireshark Cc: Anders Broman Subject: Re: [Wireshark-dev] Debianbuild fails on Ubuntu 18.04 Hi Anders,

Re: [Wireshark-dev] Debianbuild fails on Ubuntu 18.04

Hi Anders, Anders Broman via Wireshark-dev ezt írta (időpont: 2021. okt. 20., Sze, 11:24): > > Hi, > > I can no longer create a debian package on Ubuntu 18.04... The build fails due to a debhelper bug. I've submitted the workaround at https://gitlab.com/wireshark/wireshark/-/merge_requests/4755

[Wireshark-dev] Debianbuild fails on Ubuntu 18.04

Hi, I can no longer create a debian package on Ubuntu 18.04... Best regards Anders # check all necessary headers are included cc -c debian/headers-check.c -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2

Re: [Wireshark-dev] Is this the bug of wmem_tree_lookup32_array_le()?

Another option, which should work with the existing API, is to have a wmem_tree with keys the upper 32 bits whose data nodes are also trees, with keys the lower 32 bits. (You store it by doing an exact wmem_tree_lookup32() match, adding a new tree if not found.) Then you do a normal

Re: [Wireshark-dev] Is this the bug of wmem_tree_lookup32_array_le()?

John Thacker, Thank you for your information. I may try to add xxx_insert64/lookup64(). --Original-- From: "Developer support list for

Re: [Wireshark-dev] Is this the bug of wmem_tree_lookup32_array_le()?

On Sun, Oct 17, 2021 at 5:41 AM qiangxiong.huang via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > > Who knows that the current behavior of the wmem_tree_lookup32_array_le() > is designed in this way or it is just a bug? > If I want to fix the issue #17633, should I modify this >

Re: [Wireshark-dev] Swap 'v'|'V' options for editcap and mergecap

#15483 - Longest journey, first steps... https://gitlab.com/wireshark/wireshark/-/merge_requests/4611 I was hoping to work towards (for -h and -v) something like LONGOPT_CAPTURE_COMMON in https://gitlab.com/wireshark/wireshark/-/blob/master/capture_opts.h and ws_log_print_usage() in

Re: [Wireshark-dev] Swap 'v'|'V' options for editcap and mergecap

It would be nice if they were all documented too. See also: https://gitlab.com/wireshark/wireshark/-/issues/15483. - Chris > -Original Message- > From: Wireshark-dev On Behalf > Of Gerald Combs > Sent: Monday, October 18, 2021 9:48 PM > To: Developer support list for Wireshark ; >

Re: [Wireshark-dev] Swap 'v'|'V' options for editcap and mergecap

I'm not sure if we've ever swapped flags, but Wireshark's "-m" flag was marked as deprecated prior to the 2.2 release (bcae998048) and removed prior to 2.4 (37252634c4). I don't have any objections to doing something similar for the "-v" and "-V" flags. On 10/16/21 11:35 AM, chuck c wrote: Is

[Wireshark-dev] Is this the bug of wmem_tree_lookup32_array_le()?

I investigate the issue https://gitlab.com/wireshark/wireshark/-/issues/17633, and find that the bug is caused by using wmem_tree_lookup32_array_le(). HTTP2 streaming mode reassembly need to store reassembly information indexed by http2 frame number (as the key), and look up the information

[Wireshark-dev] Swap 'v'|'V' options for editcap and mergecap

Is there any precedent for changing command line options after a program has been in production for some time? Swapping "v" and "V" for editcap and mergecap would bring them in line with the other binaries for calling show_version(). And also align with the verbose option ('V') for tshark and

[Wireshark-dev] Default value for new UAT field

With commit d38de4c0 [1] a new field for the I/O graphs UAT has been introduced. With this using io_graphs settings generated with 3.4 (or before) fails in 3.6 [2]. Before releasing 3.6.0 I really want to fix this issue by setting a default value when the field is missing in the io_graphs file.

[Wireshark-dev] Does it make sense to have an FT_BOOLEAN field and > 1 bit set in mask?

I added this check to tools/check_typed_item_calls.py --mask I am hoping that someone will recognise a protocol they know and check out what is reported, and to be able to work out if this check makes sense to do. Quite a few of the current cases have to do with multi-bit reserved fields, where

Re: [Wireshark-dev] please close issue 12805

Done, thanks for pointing it out! On Wed, Oct 13, 2021 at 3:53 PM Eugène Adell wrote: > Hello, > > anyone with sufficient rights please close : > > https://gitlab.com/wireshark/wireshark/-/issues/12805 > > I didn't pay attention but it's in fact the very same than 16919 that > was solved some

[Wireshark-dev] please close issue 12805

Hello, anyone with sufficient rights please close : https://gitlab.com/wireshark/wireshark/-/issues/12805 I didn't pay attention but it's in fact the very same than 16919 that was solved some time ago (cause : SRC < DST leading to a wrong identification of the conversation initiator). best

Re: [Wireshark-dev] captype program not in Windows installers

It looks like it was simply forgotten. The RPM and macOS packages pick up new binaries automatically, but they have to be added explicitly to the NSIS and WiX packages. Fix inbound in MR 4605. On 10/12/21 7:31 PM, chuck c wrote: Is there a reason the "captype" binary and HTML file are not

[Wireshark-dev] captype program not in Windows installers

Is there a reason the "captype" binary and HTML file are not included in the Windows installers? C:\Development\wsbuild64\run\RelWithDebInfo>captype.exe Usage: captype ... C:\Development\wsbuild64\run\RelWithDebInfo>captype.exe -v Captype (Wireshark) 3.7.0-CDC_211006

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

Re: [Wireshark-dev] Display filter field variables

Thanks a lot. :-) Seems like I was wrong and it's a macro after all. On 08/10/21 16:31, chuck c wrote: Display Filter Macros of currently selected packet fields https://gitlab.com/wireshark/wireshark/-/wikis/DFilterMacro

Re: [Wireshark-dev] Display filter field variables

Display Filter Macros of currently selected packet fields https://gitlab.com/wireshark/wireshark/-/wikis/DFilterMacro https://gitlab.com/wireshark/wireshark/-/commit/9865b6346f6442bc8326cde55e5f012250748131 On Fri, Oct 8, 2021 at 10:10 AM João Valverde via Wireshark-dev <

[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

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

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 colorfilters file "C:\Development\wsbuild-gpl\run\RelWithDebInfo\colorfilters". "Bad" cannot be converted

Re: [Wireshark-dev] Sample of IAX2 with RTP

Hi, first: I didn't received this response from mailing system even I'm receiving other wireshark-dev communication as expected. I noticed it in archive... > Be very careful to not change any calculation made in accordance to > RFC 3550. > People depend on these algorithms as well as the

Re: [Wireshark-dev] 3.6.0 release schedule

The release-3.6 branch has been created. I'll probably wait a few days to release 3.6.0rc1. On 9/30/21 2:29 PM, Gerald Combs wrote: Hi all, I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1 instead.

Re: [Wireshark-dev] 3.6.0 release schedule

On 10/7/21 17:19, Jaap Keuter wrote: Hi João, Thanks for the feedback.It’s been a while since someone seriously looked at this so it’s much appreciated. It also makes you kind of the resident expert on the thing ;).  So, in your judgement, are there things that really should be done to make

Re: [Wireshark-dev] 3.6.0 release schedule

Hi João, Thanks for the feedback.It’s been a while since someone seriously looked at this so it’s much appreciated. It also makes you kind of the resident expert on the thing ;). So, in your judgement, are there things that really should be done to make things, I would say, consistent at

Re: [Wireshark-dev] 3.6.0 release schedule

Hi Evan, Thanks for the insight. So the first item should be done then, the last one will unfortunately not be ready in time. So be it I guess. Thanks, Jaap > On 6 Oct 2021, at 20:51, Evan Huus wrote: > > On Wed., Oct. 6, 2021, 14:43 Jaap Keuter, > wrote: >

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

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,

[Wireshark-dev] Wireshark 3.4.9 is now available

I'm proud to announce the release of Wireshark 3.4.9. What is Wireshark? Wireshark is the world’s most popular network protocol analyzer. It is used for troubleshooting, analysis, development and education. What’s New Bug Fixes The following bugs have been fixed: • TShark

Re: [Wireshark-dev] 3.6.0 release schedule

On Wed., Oct. 6, 2021, 14:43 Jaap Keuter, wrote: > Hi, > > Are those wmem / pinfo->pool changes completed? Would be nice if that was > consistent before branching. I have three things left on my list: - a few last changes in to_str macros - small and easy - figure out what to do with

Re: [Wireshark-dev] 3.6.0 release schedule

Hi, Are those wmem / pinfo->pool changes completed? Would be nice if that was consistent before branching. Is dfilter stabilised already? These are the things that come to mind. Thanks, Jaap > On 30 Sep 2021, at 23:29, Gerald Combs wrote: > > Hi all, > > I have the 3.5.1 release scheduled

Re: [Wireshark-dev] On MR 4428

On Wed, Oct 6, 2021 at 12:58 PM Jaap Keuter wrote: > Looking at MR 4428 > (cherry > picked from commit 96cfaf67 > ) > it introduces a new symbol in the

[Wireshark-dev] On MR 4428

Hi, Looking at MR 4428 https://gitlab.com/wireshark/wireshark/-/merge_requests/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 of "wtap_uses_lua_filehandler@Base 3.5.1",

[Wireshark-dev] Does this apply to 3.2 too?

Hi, When building release-3.2 I'm greeted by a stream of warnings from CMake first, like these: -- Configuring done CMake Warning (dev) in CMakeLists.txt:

Re: [Wireshark-dev] Filtering USB HID fields

On Wed, Sep 29, 2021 at 2:13 PM João Valverde via Wireshark-dev wrote: > > A completely different approach > > would be to have generic hf and make the filter value somehow encode > > usage page, id and value (if any). > > How about having an fvalue type FVALUE_USB_HID and a display filter >

Re: [Wireshark-dev] Sample of IAX2 with RTP

Hi, Be very careful to not change any calculation made in accordance to RFC 3550. People depend on these algorithms as well as the naming used. Regards, Jaap > Op 04-10-2021 21:08 schreef Jirka Novak : > > > Hi, > > there is observed misbehaving in RTP jitter mean calculation >

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

Re: [Wireshark-dev] Compilation on Windows taking a very long time?

On Tue, Oct 5, 2021 at 7:43 AM Anders Broman via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Is it just me or is compilation time on Windows much longer now? > I don't know about the Windows build, but I recently discovered that changes in one ui/qt/*.cpp file triggers a build of all

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

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: 'INT8_MIN': macro redefinition [C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj] C:\Program

[Wireshark-dev] Compilation on Windows taking a very long time?

Hi, Is it just me or is compilation time on Windows much longer now? Regards Anders smime.p7s Description: S/MIME cryptographic signature ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] WSDG: "foo" protocol sample capture

Could this be a "Dissectors 101" page on the Wiki Development page ( https://gitlab.com/wireshark/wireshark/-/wikis/Development)? Protocol "foo" is probably deserving of a mini-RFC (complete with Ascii art of the fields) and the text2pcap notes broken out as a real example of how to use it. Links

Re: [Wireshark-dev] WSDG: "foo" protocol sample capture

I don't know if there's ever been a companion capture file to test the sample "Foo" dissector or not, so I created one. I also created a comparable "Foo" dissector written in Lua to complement the C dissector for those who are just getting started with Lua. The Lua dissector contains many

[Wireshark-dev] Sample of IAX2 with RTP

Hi, there is observed misbehaving in RTP jitter mean calculation (https://gitlab.com/wireshark/wireshark/-/issues/17600). I'm going to fix it. There is very similar code in IAX2 analysis and it looks there is same issue too. I plan to fix it too, but I have no IAX2 sample with RTP to verify

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

Hi João, after executing these commands, everything worked! Thanks very much Not sure what happened, though (git status was "clean") Anyway, thanks a lot Ivan On Mon, 4 Oct 2021 at 18:04, João Valverde via Wireshark-dev wrote: > > > > On 04/10/21 14:29, Ivan Nardi wrote: > > Hi > > I am not

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

[Wireshark-dev] Unable to compile latest master

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/wireshark(master)$ cd

[Wireshark-dev] WSDG: "foo" protocol sample capture

https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html `Let’s step through adding a basic dissector. We’ll start with the made up "foo" protocol. ...` Has there ever been a companion capture file to test the sample dissector in the WSDG?

Re: [Wireshark-dev] Bug in Stаtistics→TCP Stream graphs

Can you extend the capture length (snaplen) to capture the full headers? In the capture file, frame.cap_len = 64 bytes. The header lengths (in bytes) are ethernet (14) + VLAN (4) + IP (20) + TCP (20 + options). The TCP header lengths (tcp.hdr_len) in the capture are all 32 bytes. 14 + 4 + 20 +

[Wireshark-dev] Bug in Stаtistics→TCP Stream graphs

Version 3.4.8 (v3.4.8-0-g3e1ffae201b8) Copyright 1998-2021 Gerald Combs and contributors. License GPLv2+: GNU GPL version 2 or later This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or

Re: [Wireshark-dev] pod2adoc and the man pages

On 9/25/21 9:59 AM, Gerald Combs wrote: On 9/25/21 1:17 AM, Jaap Keuter wrote: Hi, In reference to https://gitlab.com/wireshark/wireshark/-/merge_requests/4294 What is supposed to happen to the man pages themselves? Will they now be generated from the AsciiDoc files? I think I’m missing the

[Wireshark-dev] 3.6.0 release schedule

Hi all, I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1 instead. Unless anyone needs to delay the 3.6 branch I plan on doing the following: Oct 6 : Release 3.4.9 & 3.2.17 Oct 7 : Create the

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

[Wireshark-dev] Filtering USB HID fields

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 pressed, 0x0001 means button 1, ...,

[Wireshark-dev] Reopen issue or create new and reference closed?

https://gitlab.com/wireshark/wireshark/-/issues/15588 This depends on the setting for View->Time Display Format` and whether the filter is created in the packet list or the packet details. Before documenting the details - should this existing issue be reopened or a new one created and reference

[Wireshark-dev] Add generated hf_register_info during proto_register_...

Hi, I've got a bunch of statically entered entries for the "normal" way of registering the field array: I.e. using static hf_register_info hf[] = { ...} proto_register_field_array(proto_ublox, hf, array_length(hf)); Now I have chunk of code were I want to do this: #defineNUM_PORT_VALS

Re: [Wireshark-dev] Testing Someone Else's Merge Request

Thanks! https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html#idp2 I broke the WSDG rule "Unless you know exactly what you are doing, you should strictly follow the recommendations below." and modified my git flow. Since gitlab mirrors my fork in the background, there is just a

Re: [Wireshark-dev] Testing Someone Else's Merge Request

The main GitLab repository (assuming it’s called ‘origin’) automatically maintains references to the head of the pull requests and their merge commits with the target branch: refs/merge-requests//head refs/merge-requests//merge So instead of looking up the owner and the branch name for merge

[Wireshark-dev] Testing Someone Else's Merge Request

https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches#testing-someone-elses-merge-request "If you would like to test someone else's merge request or personal repository branch you can do the following: # Fetch their branch to a local branch named FETCH_HEAD. git fetch

Re: [Wireshark-dev] pod2adoc and the man pages

On 9/25/21 1:17 AM, Jaap Keuter wrote: Hi, In reference to https://gitlab.com/wireshark/wireshark/-/merge_requests/4294 What is supposed to happen to the man pages themselves? Will they now be generated from the AsciiDoc files? I think I’m missing the point to this change. The man pages

[Wireshark-dev] pod2adoc and the man pages

Hi, In reference to https://gitlab.com/wireshark/wireshark/-/merge_requests/4294 What is supposed to happen to the man pages themselves? Will they now be generated from the AsciiDoc files? I think I’m missing the point to this change. Thanks, Jaap

<    3   4   5   6   7   8   9   10   11   12   >