[Wireshark-dev] RTP-MIDI strange field masks?

These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me, but I am worried I might be missing something? Looking at an example in RFC 4695 (Song Position Pointer) I think this (on page 157) is saying that is it just a 2-byte field (and should therefore have a non-mask of 0x0)? | Song Position

Re: [Wireshark-dev] Decoding error SS7 SMS-MO (ok) vs SMPP Deliver SM (malformed)

Hi Andreas, Le mer. 7 juil. 2021 à 16:20, Andreas Fink a écrit : > Hello, > > I run into a decoding error in SMPP > > I have a GSM SMS payload which comes in as SMS-MO into a SMSC. > > the GSM-SMS TPDU SMS-submit -> TP-UserData section contains the bytes: >

Re: [Wireshark-dev] Ericsson ppcap sample capture

On Jul 5, 2021, at 7:38 PM, chuck c wrote: > packet-ppcap.c needs the same change that was done for vss in > https://gitlab.com/wireshark/wireshark/-/merge_requests/3526 > > It's a minor change but I would like to test before and after if possible. > > Can anyone point me to a sample capture

[Wireshark-dev] Ericsson ppcap sample capture

packet-ppcap.c needs the same change that was done for vss in https://gitlab.com/wireshark/wireshark/-/merge_requests/3526 It's a minor change but I would like to test before and after if possible. Can anyone point me to a sample capture for "Proprietary PCAP" ?

Re: [Wireshark-dev] here is dead link.

Fixed. Thanks! On 7/1/21 9:59 PM, tchksuz...@hotmail.com wrote: here is dead link. https://www.wireshark.org/download.html the link is  "Homebrew" link to ⇒　http://brewformulas.org/Wireshark Bestregards. ___ Sent

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

Yes. Thanks! On Fri, Jul 2, 2021 at 12:07 PM Graham Bloice wrote: > And backing out MR 3229 with "git revert -n ebb8703a" allows incremental > rebuilds again. > > On Fri, 2 Jul 2021 at 17:44, chuck c wrote: > >> LNK4291 first time after deleting wsbuild64 and rebuilding with >> cmake -G

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

And backing out MR 3229 with "git revert -n ebb8703a" allows incremental rebuilds again. On Fri, 2 Jul 2021 at 17:44, chuck c wrote: > LNK4291 first time after deleting wsbuild64 and rebuilding with > cmake -G "Visual Studio 16 2019" -A x64 ..\wireshark > >

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

LNK4291 first time after deleting wsbuild64 and rebuilding with cmake -G "Visual Studio 16 2019" -A x64 ..\wireshark libmaxminddb.lib(maxminddb.c.obj) : warning LNK4291: module may contain '__except' (Structured Exception Handling) but was not compiled with /guard:ehcont; generating

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

On Fri, 2 Jul 2021 at 17:28, Graham Bloice wrote: > > > On Fri, 2 Jul 2021 at 17:21, Maynard, Christopher via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> > From: Wireshark-dev On Behalf Of >> Graham Bloice >> > Sent: Friday, July 2, 2021 11:53 AM >> > To: Developer support list

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

On Fri, 2 Jul 2021 at 17:21, Maynard, Christopher via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > > From: Wireshark-dev On Behalf Of > Graham Bloice > > Sent: Friday, July 2, 2021 11:53 AM > > To: Developer support list for Wireshark > > Subject: Re: [Wireshark-dev] warning LNK4291:

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

> From: Wireshark-dev On Behalf Of Graham > Bloice > Sent: Friday, July 2, 2021 11:53 AM > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] warning LNK4291: module may contain '__except' > but was not compiled with /guard:ehcont > > I'd be interested to know if you see

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

On Fri, 2 Jul 2021 at 16:36, Maynard, Christopher via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > I’m not sure if these warnings have been seen by anyone yet, but I just > noticed them after updating sources today and compiling. > > From:

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

> From: Pascal Quantin > Sent: Friday, July 2, 2021 11:42 AM > To: Developer support list for Wireshark > Cc: Maynard, Christopher > Subject: Re: [Wireshark-dev] warning LNK4291: module may contain '__except' > but was not compiled with /guard:ehcont > > Hi Chris, > > 2 juil. 2021 17:36:21

Re: [Wireshark-dev] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

Hi Chris, 2 juil. 2021 17:36:21 Maynard, Christopher via Wireshark-dev : > I’m not sure if these warnings have been seen by anyone yet, but I just > noticed them after updating sources today and compiling. >   > From: _https://gitlab.com/wireshark/wireshark/-/jobs/1395187730#L534_ >

[Wireshark-dev] here is dead link.

here is dead link. https://www.wireshark.org/download.html the link is  "Homebrew" link to ⇒　http://brewformulas.org/Wireshark Bestregards. ___ Sent via:Wireshark-dev mailing list Archives:

[Wireshark-dev] I'm broken on the inside, please somebody fix me...

(Not talking about me... ;)). That's the message I'm getting by Wireshark Gitlab Utilily in https://gitlab.com/wireshark/wireshark/-/merge_requests/3544 I have approved the MR and assigned it to the bot, and would have expected the change to be rebased and merged. Am I missing something or is the

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

On Jun 27, 2021, at 6:36 AM, Vincent Randal wrote: > On Sat, Jun 26, 2021 at 9:41 PM Guy Harris wrote: > >> So this isn't really a Wireshark dissector question, it's a protocol design >> and encoding question. > > I'd like it not to be an encoding question beyond this: Given I'm using ASN.1

[Wireshark-dev] Fwd: ASN.1-based dissector decoding by port number vs switch/case using 1st octet

On Sat, Jun 26, 2021 at 9:41 PM Guy Harris wrote: > So this isn't really a Wireshark dissector question, it's a protocol > design and encoding question. > I'd like it not to be an encoding question beyond this: Given I'm using ASN.1 to generate dissectors (for the protocols I am designing),

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

So this isn't really a Wireshark dissector question, it's a protocol design and encoding question. The issue isn't "how do I get a Wireshark dissector to distinguish between different message types without giving each message type its own UDP port", it's "how do I get *the recipient of the

Re: [Wireshark-dev] GRegex deprecated

Has this change actually been committed? It looks like GLib's internal copy of PCRE was removed in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2144 but meson.build still requires an external libpcre in GLib's main branch. As MR 1451 points out, PCRE1 is in maintenance mode so it

[Wireshark-dev] GRegex deprecated

Deprecate GRegex https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1451 I guess deprecated is not the same as removed. Is there a plan to migrate in the future? (last migration: https://www.wireshark.org/lists/wireshark-dev/201108/msg00501.html)

[Wireshark-dev] Requesting feedback and help on a WIP merge request

Hello all! I'm writing to request fresh eyes, and possibly hands, on a somewhat significant potential change to Wireshark. There's an old bug, 14329, requesting support for multiple comments per packet. I've got a proposed solution in merge request #2859: Instead of creating new fields on

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

The protocol does not exist yet. Neither. I am helping develop this protocol for IEEE 1451.0. I do not represent the IEEE. I am simply volunteering (as others) in one of the working groups (IEEE 1451.0). Why on earth did I choose to use ASN.1? Because I was asked to provide some form of IDL for

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

On Jun 22, 2021, at 6:33 PM, Vincent Randal wrote: > We are using PER per the foo example (Simple ASN.1-based dissector). Wow, I > never about all these different encodings. > > Maybe we should be using something other than PER? We think we like PER > because the dissected values agree with

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

We are using PER per the foo example (Simple ASN.1-based dissector). Wow, I never about all these different encodings. Maybe we should be using something other than PER? We think we like PER because the dissected values agree with what we can see in the raw UDP data. On Tue, Jun 22, 2021 at 7:13

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

On Jun 21, 2021, at 11:54 PM, Vincent Randal wrote: > The primary question in this email (but I think it requires some explanation > below): How does one write an ASN.1-based dissector such that the generated > code (per "make asn1") does indeed decode the first octet as the message type >

Re: [Wireshark-dev] Wiki editor permission request

Done. On 6/22/21 3:57 PM, Dr. Matthias St. Pierre wrote: Hi, would you be so kind and grant me permission to edit the WireShark Wiki? I would like upload the IPsec examples demonstrating the decryption of IKEv2 and ESP packets, which I mentioned in [MR 3444], to the [SampleCaptures] page.

[Wireshark-dev] Wiki editor permission request

Hi, would you be so kind and grant me permission to edit the WireShark Wiki? I would like upload the IPsec examples demonstrating the decryption of IKEv2 and ESP packets, which I mentioned in [MR 3444], to the [SampleCaptures] page. Regards, Matthias St. Pierre GitLab: @mspncp [MR 3444]:

Re: [Wireshark-dev] Struggling to build NSIS installation

The Asciidoctor.js project ships self-contained Windows executables with each release: https://github.com/asciidoctor/asciidoctor.js/releases/tag/v2.2.4 I tried setting ASCIIDOCTOR_EXECUTABLE and ASCIIDOCTOR_PDF_EXECUTABLE to /path/to/asciidoctor-win.exe in a Windows VM here, and it was able

Re: [Wireshark-dev] Struggling to build NSIS installation

As far as I can tell, Chocolatey doesn't support alternative package dependencies, so you get too choose between depending on a specific JRE (which might install an unwanted extra copy of java.exe) or none (which requires an extra installation step). The AsciidoctorJ package went with the

Re: [Wireshark-dev] Struggling to setup Windows command-line build

Sorry, I accidentally replied only to Graham. Pasted here. Ah, [image: image.png] The problem was that I began with 'x64_x64 Cross Tools Command Prompt for VS 2019', rather than 'x64 Native Tools Command Prompt for VS 2019'. When I initially pressed the Windows key then typed 'c''m'

Re: [Wireshark-dev] Struggling to setup Windows command-line build

I assume the build is working since there is a further question on java and docbook. What was the solution? On Tue, Jun 22, 2021 at 4:26 AM Graham Bloice wrote: > > On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> Hi, >> >> I am

Re: [Wireshark-dev] Struggling to build NSIS installation

On Tue, 22 Jun 2021 at 13:41, Martin Mathieson via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Does the Java warning sound important? Is there something I should do to > try to increase the java heap size? This machine should have loads > (c20GB) of memory available.. > > [image:

[Wireshark-dev] Struggling to build NSIS installation

Does the Java warning sound important? Is there something I should do to try to increase the java heap size? This machine should have loads (c20GB) of memory available.. [image: image.png] Best regards, Martin ___ Sent

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

Hi, I think you should go for 2. Wouldn’t this type of construct from the goose protocol work? GSEMngtRequests ::= CHOICE { getGoReference[1] IMPLICIT GetReferenceRequestPdu, getGOOSEElementNumber [2]

Re: [Wireshark-dev] Struggling to setup Windows command-line build

On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi, > > I am using Visual Studio 2019 (not community version). > > My cmake step is succeeding, but when I try to build, it is pointing at an > invalid solution configuration. > > [image:

[Wireshark-dev] Struggling to setup Windows command-line build

Hi, I am using Visual Studio 2019 (not community version). My cmake step is succeeding, but when I try to build, it is pointing at an invalid solution configuration. [image: image.png] My cmake command is: [image: image.png] I don't know why it is trying to build with RelWithDebInfo | *x86*.

[Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

Hello everyone in the Wireshare-dev community, The primary question in this email (but I think it requires some explanation below): How does one write an ASN.1-based dissector such that the generated code (per "make asn1") does indeed decode the first octet as the message type using C-style

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 >

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

On Mon, Jun 21, 2021 at 9:28 PM João Valverde via Wireshark-dev < 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 > > mailto:wireshark-dev@wireshark.org>> > wrote: > > > > > > > > On 16/06/21

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: > >> Message: 5

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

On Mon, Jun 21, 2021 at 2:21 PM João Valverde via Wireshark-dev < 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: > > > >> Message: 5 > >> Date: Sat, 29 May 2021 09:32:29 +0200 > >> From: Anders

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

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 (because

Re: [Wireshark-dev] Wiki editor permission request

Done! On 6/17/21 7:04 AM, Ronald Henderson via Wireshark-dev wrote: I would like permission to edit the Wireshark wiki. My GitLab username is Ronald Henderson. Full name: Ronald Henderson User ID 7882719 Email: rwh...@verizon.net I am the Co-Author of the Network Security Toolkit (NST)

[Wireshark-dev] Wiki editor permission request

I would like permission to edit the Wireshark wiki. My GitLab username is Ronald Henderson. Full name: Ronald Henderson User ID 7882719 Email: rwh...@verizon.net I am the Co-Author of the Network Security Toolkit (NST) https://networksecuritytoolkit.org We have implemented a

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

Le 16/06/2021 à 16:36, David Perry a écrit : 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 [...] I wasn't around for that discussion so I don't know the reasons, but how does this sound as a refined

Re: [Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE

On Wed, Jun 16, 2021 at 2:48 PM Anders Broman via Wireshark-dev wrote: > > > > -Original Message- > From: Wireshark-dev On Behalf Of Isaac > Boukris > Sent: den 16 juni 2021 12:52 > To: wireshark-dev@wireshark.org > Subject: [Wireshark-dev] ASN1: How to display an octet-string as UTF16

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

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 Message-ID: Content-Type:

Re: [Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE

-Original Message- From: Wireshark-dev On Behalf Of Isaac Boukris Sent: den 16 juni 2021 12:52 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE Hello, I'd like to add the following asn1 struct to the credssp dissector

[Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE

Hello, I'd like to add the following asn1 struct to the credssp dissector (following MR 3020): TSRemoteGuardPackageCred ::= SEQUENCE { packageName [0] OCTET STRING, credBuffer [1] OCTET STRING } It gets displayed like this: logonCred packageName:

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

Re: [Wireshark-dev] Unit testing dissector code

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). > > Maybe that could be solved by

Re: [Wireshark-dev] IRC channel

It is at least associated with the Wireshark project. 08:23 -!- Irssi: Starting query in freenode with chanserv 08:23 info #wireshark 08:23 -ChanServ(ChanServ@services.)- Information on #wireshark: 08:23 -ChanServ(ChanServ@services.)- Founder: Lekensteyn 08:23 -ChanServ(ChanServ@services.)-

[Wireshark-dev] Fields registered to non-parent protocol (e.g. ftp and ftp-data)

Is it a typo when fields are not registered to the parent protocol or should README.dissector describe if/when this is acceptable? >From README.dissector: "abbrev (FIELDABBREV) A string with an abbreviation of the field. The abbreviation should startwith the abbreviation of

Re: [Wireshark-dev] Email archive download

Hi Chuck, There are a couple of external archives, see https://www.wireshark.org/lists/ In the past GMANE offered a web interface (HTTP) as well as a "news" (NNTP) interface, you could try that as well. See https://gmane.io/ and the gmane.network.wireshark.devel list over NNTP. I have not

[Wireshark-dev] Email archive download

Are the email archives stored in a format (other than the 41801 HTML files) that could be downloaded for searching? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev

Re: [Wireshark-dev] IRC channel

Hi Jason, Please be aware that the Freenode IRC channel #wireshark is a resource not controlled by the Wireshark organisation. Thanks, Jaap > On 10 Jun 2021, at 18:55, Jason Cohen wrote: > > Curious if there is (or I missed) an announcement about the IRC channel on > freenode. Obviously

[Wireshark-dev] IRC channel

Curious if there is (or I missed) an announcement about the IRC channel on freenode. Obviously there is a lot of activity / drama going on there and I've been seeing some rather ugly spam messages in the channel on freenode.

Re: [Wireshark-dev] Wiki editor permission request

Be warned, though, it doesn't seem like the changes to the editable wiki have been reflected in the main public wiki for about a month: https://gitlab.com/wireshark/wireshark/-/issues/17397 It was working before then. John Thacker On Wed, Jun 9, 2021, 1:46 PM Gerald Combs wrote: > Done! > >

Re: [Wireshark-dev] Wiki editor permission request

Thanks Original message From: Gerald Combs Date: Thu, Jun 10, 2021, 01:45To: Developer support list for Wireshark Cc: Sun Lin Subject: Re: [Wireshark-dev] Wiki editor permission requestDone!On 6/8/21 11:41 PM, Sun Lin via Wireshark-dev wrote:> Hi,> > I would like permission to edit

Re: [Wireshark-dev] Wiki editor permission request

Done! On 6/8/21 11:41 PM, Sun Lin via Wireshark-dev wrote: Hi, I would like permission to edit the Wireshark wiki. My GitLab username is @lin.sun . There're two pcap example files for OPUS rtp packets to upload to the  https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures . B.R. Lin

[Wireshark-dev] Wiki editor permission request

Hi, I would like permission to edit the Wireshark wiki. My GitLab username is @lin.sun .  There're two pcap example files for OPUS rtp packets to upload to the  https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures . B.R. Lin

Re: [Wireshark-dev] Issue notifications

Just an update: the issue has been fixed by GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/330033#note_589470025 I checked and everything seems fine now Ivan On Wed, 12 May 2021 at 19:47, Gerald Combs wrote: > > This appears to be a GitLab bug: > >

Re: [Wireshark-dev] Getting captured interface name inside plugin

Thanks for the hint with the interface_id - didn't knew that yet. Mapping between interfaces and message definition files are done in the preferences. Good point with the capture files - listening for UI events wouldn't work there. So probably I should stick with the solution of the

[Wireshark-dev] Visual C++ 2019 redistributable - giveth and taketh

Wireshark.exe - System Error -- The code execution cannot proceed because MSVCP140.dll was not found. Reinstalling the program may fix the problem. No, you're not losing it. The file(s) did disappear. Installers built with current Visual Studio get a vcredist_x64.exe that

Re: [Wireshark-dev] Getting captured interface name inside plugin

On Jun 7, 2021, at 4:15 AM, Jan Mall wrote: > After continuing searching I found this snippet in the UI part: > "epan_get_interface_name(pinfo->epan, > pinfo->rec->rec_header.packet_header.interface_id);" Note that it is permitted to return NULL. Note also that there is no guarantee that

Re: [Wireshark-dev] Getting captured interface name inside plugin

On 07.06.21 02:41, Richard Sharpe wrote: On Sun, Jun 6, 2021 at 5:42 PM Jan Mall wrote: The ultimate goal is an automotive dissector, which takes abstract network descriptions for automotive buses and dissects the messages on the bus accordingly. But as every bus has a different set of message

Re: [Wireshark-dev] Getting captured interface name inside plugin

Also are you running the same protocol on all the different buses, or has each bus its own distinctive protocol? cheers Roland Am Mo., 7. Juni 2021 um 02:58 Uhr schrieb Guy Harris : > On Jun 6, 2021, at 5:41 PM, Jan Mall wrote: > > > The ultimate goal is an automotive dissector, which takes

Re: [Wireshark-dev] Getting captured interface name inside plugin

On Jun 6, 2021, at 5:41 PM, Jan Mall wrote: > The ultimate goal is an automotive dissector, which takes abstract network > descriptions for automotive buses and dissects the messages on the bus > accordingly. But as every bus has a different set of message definitions, So is there a single

Re: [Wireshark-dev] Getting captured interface name inside plugin

On Sun, Jun 6, 2021 at 5:42 PM Jan Mall wrote: > > The ultimate goal is an automotive dissector, which takes abstract > network descriptions for automotive buses and dissects the messages on > the bus accordingly. But as every bus has a different set of message > definitions, I somehow need to

Re: [Wireshark-dev] Getting captured interface name inside plugin

The ultimate goal is an automotive dissector, which takes abstract network descriptions for automotive buses and dissects the messages on the bus accordingly. But as every bus has a different set of message definitions, I somehow need to find out on which bus (physical interface) I receive the

Re: [Wireshark-dev] Getting captured interface name inside plugin

On Jun 6, 2021, at 5:13 PM, Jan Mall wrote: > I'm currently developing a plugin/dissector (C API), which should have a > different dissection behavior depending on the interface Wireshark is > currently listening on. Why? What is the *ultimate* goal of this?

[Wireshark-dev] Getting captured interface name inside plugin

Hello together, I'm currently developing a plugin/dissector (C API), which should have a different dissection behavior depending on the interface Wireshark is currently listening on. So I need to somehow get to know which interface Wireshark is currently capturing on. I've checked the

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] please close issue 12800

Hi Eugene, 4 juin 2021 18:41:53 Eugène Adell : > Hello, > > anyone with sufficient rights please close : > > https://gitlab.com/wireshark/wireshark/-/issues/12800 Done. Best regards, Pascal. ___ Sent via:Wireshark-dev

[Wireshark-dev] please close issue 12800

Hello, anyone with sufficient rights please close : https://gitlab.com/wireshark/wireshark/-/issues/12800 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe:

[Wireshark-dev] Fixing decoding of RDP traffic

Hi, I'm trying to fix the decoding of RDP traffic. My scenario is a typical RDP connection TLS encrypted (well with ciphers lowered so that no PFS is negotiated). So here's the list of my botherings: * I'm setting the TLS key associated with port 3389 and the host, but with RDP, there's 2

Re: [Wireshark-dev] Windows HTML Help

El mié, 2 de jun. de 2021 a la(s) 15:43, Gerald Combs (ger...@wireshark.org) escribió: > > On 6/1/21 8:08 PM, Guy Harris wrote: > > On Jun 1, 2021, at 4:14 PM, Gerald Combs wrote: > > > >> I just discovered that the HTML Help Workshop download link at > >> > >>

[Wireshark-dev] Wireshark 3.4.6 is now available

I'm proud to announce the release of Wireshark 3.4.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 The Windows installers now ship with Npcap 1.31. They previously

Re: [Wireshark-dev] Windows HTML Help

On 6/1/21 8:08 PM, Guy Harris wrote: On Jun 1, 2021, at 4:14 PM, Gerald Combs wrote: I just discovered that the HTML Help Workshop download link at https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/microsoft-html-help-downloads no longer works, and the Chocolatey

Re: [Wireshark-dev] Windows HTML Help

On Jun 1, 2021, at 4:14 PM, Gerald Combs wrote: > I just discovered that the HTML Help Workshop download link at > > https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/microsoft-html-help-downloads > > no longer works, and the Chocolatey package now downloads from

Re: [Wireshark-dev] Windows HTML Help

https://gitlab.com/wireshark/wireshark/-/merge_requests/3213 Wow - quite the change. On Tue, Jun 1, 2021 at 6:15 PM Gerald Combs wrote: > I just discovered that the HTML Help Workshop download link at > > >

Re: [Wireshark-dev] Windows HTML Help

I just discovered that the HTML Help Workshop download link at https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/microsoft-html-help-downloads no longer works, and the Chocolatey package now downloads from archive.org:

[Wireshark-dev] wiki.wireshark.org - down ?

Responds to ping: C:\>ping wiki.wireshark.org Pinging wiki.wireshark.org [104.26.10.240] with 32 bytes of data: Reply from 104.26.10.240: bytes=32 time=92ms TTL=54 Reply from 104.26.10.240: bytes=32 time=97ms TTL=54 Reply from 104.26.10.240: bytes=32 time=159ms TTL=54 Cloudflare returns: Error

[Wireshark-dev] Dealing with wrong Content-Types in HTTP

Hello developers, While looking at traffic from Apple devices, I'm seeing lots of non-browser HTTP(S) requests and responses that have incorrect Content-Type headers. For example, when an iPhone talks to Apple CoreLocation servers, it sends HTTPS requests with Content-Type:

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

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

When I made that change to MQTT I failed to notice that it called other dissectors with different data pointers, and although specifically modified for SparkplugB, felt that passing the topic as data was sufficiently general to be useful. As others have noted, I guess the issue here is that to be

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

Hi, Yes the method is fragile. At the time of development I think it was proposed to pass a struct containing a string and the void pointer where the string could be used as a identifier. But that was voted down. Regards Anders Den lör 29 maj 2021 09:26Guy Harris skrev: > On May 29, 2021, at

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

On May 29, 2021, at 12:12 AM, Anders Broman wrote: > Shouldn't the caller be calling with the right data type or NULL? So a bug in > the MQTT disector? How can the MQTT dissector determine what the right data type *is* - especially given that the dissectors aren't wired in, there's a UAT

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

Makes sense for me. I will change the MQTT dissector to call call_dissector_with_data() only for sparkplug payload. > Am 29.05.2021 um 09:12 schrieb Anders Broman >: > > Hi, > Shouldn't the caller be calling with the right data type or NULL? So a bug in > the MQTT

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

Hi, Shouldn't the caller be calling with the right data type or NULL? So a bug in the MQTT disector? Regards Anders Den lör 29 maj 2021 09:07Uli Heilmeier skrev: > With MR 2706 [1] the MQTT dissector calls now subdissectors with > call_dissector_with_data() [2]. Previously this was

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

With MR 2706 [1] the MQTT dissector calls now subdissectors with call_dissector_with_data() [2]. Previously this was call_dissector(). With this change the JSON dissector crashes WS with a memory access segfault (while using MQTT decode topic as option). This is because for JSON we expect

Re: [Wireshark-dev] wslua: checkNSTime / pushNSTime undefined

Yet more issues surfacing with CMake 3.20. Are these regressions being reported back to Kitware somewhere? On Fri, 28 May 2021 at 02:03, chuck c wrote: > My bad. Upgraded Visual Studio and it now ships with cmake 3.20. > choco installing cmake 3.19 fixed the errors. > > Original working

Re: [Wireshark-dev] wslua: checkNSTime / pushNSTime undefined

My bad. Upgraded Visual Studio and it now ships with cmake 3.20. choco installing cmake 3.19 fixed the errors. Original working system: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29912 for x64 Copyright (C) Microsoft

[Wireshark-dev] wslua: checkNSTime / pushNSTime undefined

Is it a matter of tweaking the build to allow the warning to pass or does this require a code change? W:\Development\wsbuild>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30037 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

Hello Gerald, On Thu, May 27, 2021 at 4:20 PM Martin Mathieson via Wireshark-dev wrote: > > I am using VirtualBox.. After discussing the conditions with Martin, I tried unsuccessfully to replicate the issue with a macOS VM running on Vmware Fusion with NAT. I had initially tried using an

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

I am using VirtualBox. On Thu, May 27, 2021 at 6:29 PM Gerald Combs wrote: > Is your VM host running VMware? I just ran across this > > > https://stackoverflow.com/questions/52415943/trying-to-git-clone-via-ssh-but-getting-broken-pipe-error > > which mentions that adjusting

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

Is your VM host running VMware? I just ran across this https://stackoverflow.com/questions/52415943/trying-to-git-clone-via-ssh-but-getting-broken-pipe-error which mentions that adjusting ServerAliveInterval and IPQoS in your ~/.ssh/config might help. The issue that Jim mentions below was due

Re: [Wireshark-dev] Can the OSS-FUZZ tool be modified to generate a pcap test file?

On Thu, May 27, 2021 at 10:16 AM Moshe Kaplan wrote: > > I believe Peter Wu created a script a while back to do that and published it > here: https://github.com/Lekensteyn/wireshark-fuzztools Thanks for that. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

<    5   6   7   8   9   10   11   12   13   14   >