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

[Wireshark-dev] 90GB pcap file get last frame time stamp

Hi Everyone! Need a help. Is there any library or method to get large pcap file's( offline ) last timestamp. I know capinfos can get this. But i want faster than capinfos. Any suggestion? Thanks Best Regards Raj ___ Sent

Re: [Wireshark-dev] OID not implemented

What version of Wireshark? Supported added here: https://gitlab.com/wireshark/wireshark/-/commit/c529e9110a211bc445a94c2ed68acc14fe108384 TLS: add Signed Certificate Timestamp support (RFC 6962) Feb 14, 2017 5:09pm CST /* Certificate Transparency extensions: 2 (Certificate), 5 (OCSP Response)

Re: [Wireshark-dev] OID not implemented

It appears to be an unregistered OID, On Fri, 26 Feb 2021 at 16:23, Petersen Sean wrote: > Hi, > > > > Could you give me some more context on what the below means: > > > > > > Is this just a wireshark error or is this an indication of something > unhealthy with the communication? > > This

[Wireshark-dev] File rename impacts Gitlab history

https://gitlab.com/wireshark/wireshark/-/commit/50dbe4df7fd7a5e4e1a27fd5046981486d350994 Rename packet-ssl* to packet-tls* Looking through history of https://gitlab.com/wireshark/wireshark/-/commits/master/epan/dissectors/packet-tls.c

[Wireshark-dev] OID not implemented

Hi, Could you give me some more context on what the below means: [cid:image001.png@01D70C59.51FA2690] Is this just a wireshark error or is this an indication of something unhealthy with the communication? Thanks, Sean Petersen | Systems Engineer, New Zealand Mobile +64 21-417-7388

[Wireshark-dev] Unparsed remaining data, dynamically loading protocol descriptions

Hi all, thanks for maintaining this amazing project. I've been using Wireshark for many years and it remains my go-to program for debugging network issues or security problems. :) I'm currently working on polishing the dissector[1] for the Teeworlds[2]/DDNet[3] protocol. Writing the dissector

Re: [Wireshark-dev] Fwd: 64-bit Windows PDB files?

Welp! Guess it's time to roll up my sleeves and do some assembly-level debugging if I want to save this thing. Thanks anyway! -Danielle On Mon, Feb 22, 2021 at 7:46 PM Gerald Combs wrote: > Well, that stinks. There was indeed a copy/paste error in our deployment > script. I fixed the script,

Re: [Wireshark-dev] Fwd: 64-bit Windows PDB files?

Well, that stinks. There was indeed a copy/paste error in our deployment script. I fixed the script, but unfortunately the affected 64-bit PDBs are no longer available. It's kind of surprising that no one noticed this until now. On 2/22/21 3:56 PM, Danielle Church wrote: Hi, who is

[Wireshark-dev] Fwd: 64-bit Windows PDB files?

Hi, who is responsible for website tooling/etc? The downloads folder at https://www.wireshark.org/download/win64/all-versions/ actually has copies of the 32-bit PDB zip files for all builds since December 2019, so I imagine there was some sort of copy-paste error in a script somewhere. I'm very

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

> > It’s not a matter of *what* the program is reading, but *where* it's > > reading in the buffer. This makes it usable for *all* programs reading this > > file format, not just Wireshark. Prefixing it with zero padding (even a > > nibble) would achieve that. > As would changing the spec to

Re: [Wireshark-dev] [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open!

Hello, I don't see any mention to the doc/README.* files in this wiki, which are essential but sometimes a bit harsh. For example README.dissector is almost 4000 lines long without any Table of Content (but there's a numerotation for the paragraphs which could help building it), one doesn't

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

On Feb 19, 2021, at 9:50 PM, Jaap Keuter wrote: > It’s not a matter of *what* the program is reading, but *where* it's reading > in the buffer. This makes it usable for *all* programs reading this file > format, not just Wireshark. Prefixing it with zero padding (even a nibble) > would

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

It’s not a matter of *what* the program is reading, but *where* it's reading in the buffer. This makes it usable for *all* programs reading this file format, not just Wireshark. Prefixing it with zero padding (even a nibble) would achieve that. I’m done. > On 16 Feb 2021, at 10:05, Timmy

Re: [Wireshark-dev] [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open!

Hi Moshe. I found some information for GSoD 2020 on the Wireshark wiki - there are more ideas what to document on this page. It could be a good idea to apply for GSoD 2021. Regards, Alex > On 11 Feb 2021, at 02:45, RAGE wrote: > >

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

> > In practice, this is what I would propose: > > * Wireshark dissector made capable of accepting any whole-byte preamble > > length mPackets. > > * mPacket capture devices are made responsible for detecting any frames > > with non-integer preamble, and correct for it by adding 4 bits extra >

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

On Feb 16, 2021, at 4:03 AM, Timmy Brolin wrote: > In practice, this is what I would propose: > * Wireshark dissector made capable of accepting any whole-byte preamble > length mPackets. > * mPacket capture devices are made responsible for detecting any frames with > non-integer preamble, and

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

I have submitted a proposal here: https://gitlab.com/wireshark/wireshark/-/merge_requests/2137 * Added support for dissecting mPackets with arbitrary preamble length, in accordance with IEEE 802.3br-2016 Changed fpp.preamble type from FT_UINT64 to FT_BYTES * Use

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

Sorry, I forgot answering this: > On the *transmission* side, you're supposed to transmit 7 octet of preamble; > I haven't seen anything about reducing the size of the *transmitted* preamble > being acceptable behavior. The real world does unfortunately not align perfectly with the IEEE

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

> Section 12.9.2 "DTE timing" of IEEE Std 802.3-2018 says: > DTEs shall correctly receive frames that are preceded by 13 or more > bits of preamble plus 8 bits of . > which I assume means that, on the *receiving* end, if you miss up to 43 bits > of the 56-bit preamble - or up to 35 bits of

Re: [Wireshark-dev] Help finding the link layer dissector call (netmon_802_11)

On Feb 16, 2021, at 2:41 AM, Shai Shapira via Wireshark-dev wrote: > I'm researching Microsoft's Network Monitor captures format (.cap files) Unfortunately, you probably can't download NetMon from Microsoft any more, so you probably can't get the help file that documents the capture file

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

At various points in February 2021, Timmy Brolin wrote: > Would anyone mind if I submit a merge request which makes Wireshark capable > of dissecting all valid Ethernet mPackets according to IEEE 802.3br? I.e. according to the spec that says, on page 39: * 99.3.2 Preamble The

[Wireshark-dev] Help finding the link layer dissector call (netmon_802_11)

Hi all, I'm researching Microsoft's Network Monitor captures format (.cap files) and I need a lead in WS's code. Based on the 'link layer type' parsed from the file header the packets might be 802.11 frames with NM's special header. This dissector is known as "netmon_802_11" in wireshark.

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

Hi, Would anyone mind if I submit a merge request which makes Wireshark capable of dissecting all valid Ethernet mPackets according to IEEE 802.3br? It is a reasonably small change. But I don’t want to put in the effort if the merge request would be blocked. Jaap: Note that Figure 99-4 has

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

Hi, A not uncommon, but unfortunate misconception is that of Wireshark being a capture device, or receiver as you put it. In short Wireshark doesn’t capture, it is a program reading files, containing packets conforming to specifications as laid out in the Link Layer Header Types on the tcpdump

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

Yes, the capture device is indeed capturing data completely accurately. You are referring to the transmission section of IEEE 802.3br-2016. If you look at the receive section on page 51, you will find that receivers are required to accept any length preamble. Hence, Wireshark is not compliant

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

Hi,The capture file (View | Reload as File Format/Capture) contains an Interface Descriptor Block which states Link Type 274.According to https://www.tcpdump.org/linktypes.html the Packet Data in the capture file must adhere to "mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the

Re: [Wireshark-dev] How to properly finalize capture in a Wireshark extcap plugin?

Proposed solution I have investigated this in more depth and found that Wireshark simply does not do any kind of graceful termination of extcaps. It always kills extcaps forcefully, which causes loss of data on the capture pipe. Particularly the pcapng “Interface Statistics Block” is always

Re: [Wireshark-dev] Fwd: [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open!

Hi Moshe. It is. For now I can see the wiki has outdated info or not has a description at all for some technologies and tools the Wireshark project accumulates.. my after project time I would still want to help with it's improvement if I can. But if you want to become a participant of gsod either

[Wireshark-dev] Remote Developer Den, February 2021

I've scheduled the next remote Developer Den for next Wednesday, February 17th. This is remote version of the Developer Den at SharkFest, a room that we 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"

Re: [Wireshark-dev] Submitting Replacement Code

Thanks Pascal Sent from my iPad > On 10 Feb 2021, at 17:40, Pascal Quantin wrote: > >  > Hi Paul, > >> Le mer. 10 févr. 2021 à 18:37, Paul Offord a écrit >> : >> Hi, >> >> I need some GitLab guidance. The procedure for submitting code is: >> Commit code changes to the local copy of my

[Wireshark-dev] Fwd: [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open!

Is this worth participating in again? Moshe -- Forwarded message - From: Season of Docs - Announce Date: Tue, Feb 9, 2021 at 1:09 PM Subject: [Season of Docs - Announcements] The 2021 Season of Docs application for organizations is open! To: Season of Docs - Announce We’re

Re: [Wireshark-dev] Submitting Replacement Code

Hi Paul, Le mer. 10 févr. 2021 à 18:37, Paul Offord a écrit : > Hi, > > I need some GitLab guidance. The procedure for submitting code is: > >- Commit code changes to the local copy of my personal Wireshark repo >- Push the changes to my upstream personal repo >- Press the "Create

[Wireshark-dev] Submitting Replacement Code

Hi, I need some GitLab guidance. The procedure for submitting code is: - Commit code changes to the local copy of my personal Wireshark repo - Push the changes to my upstream personal repo - Press the "Create merge request" button Let's imagine that my code fails in the pipeline tests

Re: [Wireshark-dev] Gerrit commit missing in Gitlab

On Feb 9, 2021, at 4:57 PM, Guy Harris wrote: > "Doesn't exist" as in "immediately tells you no such commit" or as in "takes > a long time and eventually gives you a 500 error"? I get the latter; > presumably that's "500 Internal Server Error". > > The commit *is* in repositories I've cloned

Re: [Wireshark-dev] Gerrit commit missing in Gitlab

On Feb 9, 2021, at 3:26 PM, chuck c wrote: > 2eb7b05b - Convert most UDP dissectors to use "auto" preferences. > > Exists in Gerrit: > https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=2eb7b05b8c9c6408268f0d1e81f0a18a02610f1c > > Links to it in Gitlab on these pages: >

Re: [Wireshark-dev] Procedure to solve/close issues in Gitlab

Hi Pascal, > Le mar. 9 févr. 2021 à 12:51, Jirka Novak > a écrit : > > Hi, > >   what is proposed procedure to solve and close issues in Gitlab? > >   During conversion to gitlab all bugzilla issues were created as > issues. I reviewed many voice

Re: [Wireshark-dev] Procedure to solve/close issues in Gitlab

Hi Jirka, Le mar. 9 févr. 2021 à 12:51, Jirka Novak a écrit : > Hi, > > what is proposed procedure to solve and close issues in Gitlab? > > During conversion to gitlab all bugzilla issues were created as > issues. I reviewed many voice related issues, made solutions (e.g. > patches) for

[Wireshark-dev] Procedure to solve/close issues in Gitlab

Hi, what is proposed procedure to solve and close issues in Gitlab? During conversion to gitlab all bugzilla issues were created as issues. I reviewed many voice related issues, made solutions (e.g. patches) for them and updated issues, but they are still open even it makes no sense anymore.

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

Hi, > > Change calls to open() to call ws_open(), instead, so that, on > Windows, they can handle UTF-8 pathnames (by turning them into > UTF-16 pathnames and passing them to routines that take UTF-16 > pathnames, rather than using various code page encodings for strings). > >

[Wireshark-dev] pcapng decoding error when preamble is shortened

Hi, It seems Wireshark fails to decode captured packets with shortened preamble? Normally Ethernet packets have a preamble and SFD like this: 55D5 But during transmission over Ethernet, sometimes the preamble arrives slightly shorter at the receiving end. Some bytes, or even half a

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

Hi, > > Also use ws_close() instead of close().  (The ws_ calls, on > Windows, also call the Visual Studio C library routines that > implement UN*X-style APIs, with an underscore preceding the UN*X API > name.) > > Thank you for explanation and I understand the reasons, but I

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

Hi Jirka, Le mar. 9 févr. 2021 à 09:13, Jirka Novak a écrit : > Hi, > > >> I commited patch and pipeline failed because: > >> > >> ... > >> FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt > >> ... > >> Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: > open > >> Error: Found

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

Hi, >> I commited patch and pipeline failed because: >> >> ... >> FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt >> ... >> Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: open >> Error: Found prohibited APIs in utils/rtp_audio_routing_filter.cpp: open >> >> but message gives me

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

On Feb 8, 2021, at 11:57 PM, Jirka Novak wrote: > I commited patch and pipeline failed because: > > ... > FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt > ... > Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: open > Error: Found prohibited APIs in

[Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

Hi, I commited patch and pipeline failed because: ... FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt ... Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: open Error: Found prohibited APIs in utils/rtp_audio_routing_filter.cpp: open but message gives me no hint what to change.

Re: [Wireshark-dev] warning: unused parameter

Description of _U_ : https://www.wireshark.org/lists/wireshark-dev/200609/msg00226.html Defined in https://gitlab.com/wireshark/wireshark/-/blob/master/ws_attributes.h On Sun, Feb 7, 2021 at 4:33 PM Guy Harris wrote: > On Feb 7, 2021, at 10:58 AM, Paul Offord wrote: > > > • Add

Re: [Wireshark-dev] warning: unused parameter

On Feb 7, 2021, at 10:58 AM, Paul Offord wrote: > • Add conditional compile statements for the sharkd_loop function > declaration and all calls to it? * Add conditional compile statements around the entire sharkd_loop() function, given that the vast majority of its code differs between

Re: [Wireshark-dev] warning: unused parameter

On Sun, Feb 7, 2021 at 10:59 AM Paul Offord wrote: > > I submitted some code to GitLab for merging and I got a couple of warnings > from the pipeline that builds in the Ubuntu environment: > > ../sharkd_daemon.c:361:17: warning: unused parameter 'argc' > [-Wunused-parameter] > sharkd_loop(int

[Wireshark-dev] warning: unused parameter

I submitted some code to GitLab for merging and I got a couple of warnings from the pipeline that builds in the Ubuntu environment: ../sharkd_daemon.c:361:17: warning: unused parameter 'argc' [-Wunused-parameter] sharkd_loop(int argc, char* argv[]) ^ ../sharkd_daemon.c:361:29:

Re: [Wireshark-dev] Adding personal repository remote

A quick follow up to this. There is a misalignment of cloning instructions between the notes in section 2.2.10. Install and Prepare Sources on 2.2. Win32/64: Step-by-Step Guide (wireshark.org) and 3.4. Obtaining The Wireshark

Re: [Wireshark-dev] Adding personal repository remote

Thanks Graham, You are quite right. Best regards...Paul On Sun, Feb 7, 2021 at 11:53 AM Graham Bloice wrote: > > On Sun, 7 Feb 2021 at 11:03, Paul Offord wrote: > >> Hi, >> >> I'm following the instructions here - 3.10. Contribute Your Changes >> (wireshark.org) >>

Re: [Wireshark-dev] Adding personal repository remote

On Sun, 7 Feb 2021 at 11:03, Paul Offord wrote: > Hi, > > I'm following the instructions here - 3.10. Contribute Your Changes > (wireshark.org) > > > There is an instruction to double check my remotes: > > $ git remote -v >

[Wireshark-dev] Adding personal repository remote

Hi, I'm following the instructions here - 3.10. Contribute Your Changes (wireshark.org) There is an instruction to double check my remotes: $ git remote -v $ downstreamg...@gitlab.com:henry.perry/wireshark.git (fetch) $

[Wireshark-dev] Support for Miwi dissector

Hi I am trying to decode some Miwi traffic which is pseudo Zigbee traffic using a CC2531 as a sniffer but miwi has a different payload after the initial 802.15.4 header. If I wanted to add support for Miwi I assume modifying the current zigbee dissector and submitting a PR with the new dissector

Re: [Wireshark-dev] Pipeline stuck?

On Feb 5, 2021, at 1:07 AM, Anders Broman via Wireshark-dev wrote: > In https://gitlab.com/wireshark/wireshark/-/merge_requests/1934 > The pipeline seems stuck, how to reset? That merge request, if it is what its title claims it to be, appears to have succeeded, if you have an up-to-date

[Wireshark-dev] Pipeline stuck?

Hi, In https://gitlab.com/wireshark/wireshark/-/merge_requests/1934 The pipeline seems stuck, how to reset? Regards Anders smime.p7s Description: S/MIME cryptographic signature

[Wireshark-dev] [Outreachy] Internship blog 2020 post #5

Hi all! A new blog entry talking about Career Goals and post-Outreachy hopes, here [1]. Check it out! PS: unrelated to the blog post, MR !1922 [2] ready for your feedback ^^ and another one on the way soon. -- Joey [1] www.jsal.home.blog/2021/02/03/career-goals/ [2]

Re: [Wireshark-dev] New Protocol encapsulation as plugin

Hello all together, thank you all for you suggestions how to solve my problem. I tried it this week to implement and i was able to fix my problem with the encapsulation type. Especially thanks to Guy Harris for answering my other questions, e.g. compiled plugins with binary packages. Best

Re: [Wireshark-dev] Missing Wiki page on Gitlab

> On 3 Feb 2021, at 15:54, Graham Bloice wrote: > > No idea if it got transferred and has subsequently been deleted or failed to > transfer but the old wiki page on ExpertInfo > (https://wiki.wireshark.org/Development/ExpertInfo > ) doesn't

[Wireshark-dev] Missing Wiki page on Gitlab

No idea if it got transferred and has subsequently been deleted or failed to transfer but the old wiki page on ExpertInfo ( https://wiki.wireshark.org/Development/ExpertInfo) doesn't seem to be present in the Gitlab version. -- Graham Bloice

Re: [Wireshark-dev] Revive the happy-shark repository?

Hi, Happy-shark was an attempt at a stricter regression test that catches output changes. By design however it would be very much affected by the tiniest changes in dissector output. The original plan was to have a very rich repository of sample traces, but that clearly has not happened. I would

Re: [Wireshark-dev] Do we see false positives on the prechecks in merge-request runners

On Mon, Feb 1, 2021 at 7:22 AM Pascal Quantin wrote: > > Hi Richard, > > Le lun. 1 févr. 2021 à 16:09, Richard Sharpe a > écrit : >> >> Hi folks, >> >> In one of the builds for my merge request around Robust AV Streaming, >> I got this: >> >>

Re: [Wireshark-dev] Do we see false positives on the prechecks in merge-request runners

Hi Richard, Le lun. 1 févr. 2021 à 16:09, Richard Sharpe a écrit : > Hi folks, > > In one of the builds for my merge request around Robust AV Streaming, > I got this: > > https://gitlab.com/wireshark/wireshark/-/jobs/998246552 > > It is complaining that an ENC_BIG_ENDIAN should be ENC_NA, but

[Wireshark-dev] Do we see false positives on the prechecks in merge-request runners

Hi folks, In one of the builds for my merge request around Robust AV Streaming, I got this: https://gitlab.com/wireshark/wireshark/-/jobs/998246552 It is complaining that an ENC_BIG_ENDIAN should be ENC_NA, but in looking at the code, it already is ENC_NA and I have not changed that for a while

Re: [Wireshark-dev] Finding the new sharkd wiki page

Issue opened to index the new wiki: https://gitlab.com/wireshark/wireshark/-/issues/17194 - wiki: Google index the wiki on Gitlab On Sun, Jan 31, 2021 at 2:57 AM Paul Offord wrote: > Hi, > > A few years ago I created a wiki page covering sharkd. The page was > migrated to the Wireshark

[Wireshark-dev] Finding the new sharkd wiki page

Hi, A few years ago I created a wiki page covering sharkd. The page was migrated to the Wireshark wiki on GitLab about 6 months ago. I’ve rewritten the sharkd page over the last few days - https://gitlab.com/wireshark/wireshark/-/wikis/Development/sharkd If you search for sharkd on Google,

Re: [Wireshark-dev] Wireshark 3.4.3 on macOS crash

> On 30 Jan 2021, at 15:37, Jaap Keuter wrote: > > Just downloaded the update of current stable. Launching it however is not so > fine. Probably something left over in the settings which causes it to crash. > > > > Going down the rabbit hole... Okay, not too deep: #17193

[Wireshark-dev] Wireshark 3.4.3 on macOS crash

Just downloaded the update of current stable. Launching it however is not so fine. Probably something left over in the settings which causes it to crash. Process: Wireshark [46889] Path: /Applications/Wireshark.app/Contents/MacOS/Wireshark Identifier:

[Wireshark-dev] Lua stringz

Hi list, I was successfully using tvbrange:stringz() to retrieve a NULL-terminated string from a tvb, that is until I recently encountered a string containing extended-ASCII characters, at which point things starting failing because the length of the string returned was too long. To work

[Wireshark-dev] Wireshark 3.4.3 is now available

I'm proud to announce the release of Wireshark 3.4.3. 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.10. They previously

Re: [Wireshark-dev] New Protocol encapsulation as plugin

On Jan 27, 2021, at 3:16 AM, Björn wrote: > we use a custom dissector to analyze custom protocol traffic. However, to > further increase the usability, we need to add protocol analysis specific GUI > elements. For now, we are not aware of a way to add a first level plugin > which can be

Re: [Wireshark-dev] New Protocol encapsulation as plugin

I was talking about live capture and how to generate statistic plugins for them. USER_DLTs will certainly work in that regard. regards > Am 27.01.2021 um 14:06 schrieb Björn > : > >  > Hello Roland, > > thank you for your answer, but this will not work for me, because i need to > dissect

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

Even in that tree/version (which is from 9 years ago), packet-xml.c doesn't call the function itself. I don't see any out-of-tree commits to packet-xml.c in the history of that tree. The only file that includes packet-xml.h is packet-xmpp-utils.h (which is included by various XMPP dissectors),

Re: [Wireshark-dev] New Protocol encapsulation as plugin

Hello Björn, if you goal is to dissect non-pcap custom file it is also possible. You can have wiretap plugin type which reads your data format as packets and then these packets can be dissected with the epan plugin. Best regards,  Tomas -- Původní e-mail -- Od: Björn

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

Hi, Did some googling out of curiosity and found https://jelmer.uk/klaus/wireshark/blob/e738b556d72d4db5d7df85969c15117dedd0d063/epan/dissectors/packet-xml.c Search for “xml_get_attrib" So it seems it was part of packet-xml.c at some point so perhaps safe to remove… /Anders From:

Re: [Wireshark-dev] New Protocol encapsulation as plugin

Hello John, thank you for this idea. This is a way i haven't thought about and this could really be the answer for me, but i have still a problem with my custom dissector. I am not able to find my dissector in the preferences dialog for the DTL_USER link type. I call the register_dissector()

Re: [Wireshark-dev] New Protocol encapsulation as plugin

Hello Roland, thank you for your answer, but this will not work for me, because i need to dissect a first level protocol and couldn't open the file to dissect. But i think, as mentioned by John Thacker, to use the USER_DLT will take function. Best regards, Björn Am 27.01.21 um 12:30

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

Hi *João,* *I agree that every function / variable needs to be looked at carefully, but more so if they have *WS_DLL_PUBLIC in a header file. I will reinstate the XML functions in my change. Hopefully, in other places I will find clear comments saying that they are provided for calling from

Re: [Wireshark-dev] New Protocol encapsulation as plugin

On Wed, Jan 27, 2021 at 6:16 AM Björn < bjoern.peter...@missinglinkelectronics.com> wrote: > Hi, > > we use a custom dissector to analyze custom protocol traffic. However, to > further increase the usability, we need to add protocol analysis specific > GUI elements. For now, we are not aware of a

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

Re: [Wireshark-dev] New Protocol encapsulation as plugin

Hi Björn I realized something similar by implementing a tap interface in the original protocol and a UI using a similar code as in the plugin “pluginifdemo” Would it be possible to go that route? Regards, Roland > Am 27.01.2021 um 12:17 schrieb Björn > : > >  > Hi, > > we use a custom

[Wireshark-dev] New Protocol encapsulation as plugin

Hi, we use a custom dissector to analyze custom protocol traffic. However, to further increase the usability, we need to add protocol analysis specific GUI elements. For now, we are not aware of a way to add a first level plugin which can be called through an encapsulation type from a pcap

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

My most recent MR ( https://gitlab.com/wireshark/wireshark/-/merge_requests/1829), has come across some symbols that don't appear to be in used by our repo. dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below 4934

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

I have done a bit more on this - I started picking off the ones at the end of the (alphabetical) list - 2nd one is https://gitlab.com/wireshark/wireshark/-/merge_requests/1817. Please feel free if anyone feels motivated to tackle some of the earlier ones. The script is much tidier now, and also

Re: [Wireshark-dev] Wireshark dissector does not match spec for IEEE P802.1AS-Rev/D8.0

Hello, The specification I linked is newer by several years. The one I linked is 802.1AS-REV, Draft 8.0 (Sponsor Ballot) But latest is a bit newer. Link here: https://1.ieee802.org/tsn/802-1as-rev/ Yours, Ari

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

On Sun, Jan 24, 2021 at 8:27 PM Jirka Novak wrote: > Hi, > > I checked the code I know: > > > epan/dissectors/packet-rtp-events.c (01a0 D> > rtp_event_type_values_ext) is not referred to so could be static? (in> > header) > It is used in UI, outside of dissectors. Therefore it

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

Hi, I checked the code I know: > epan/dissectors/packet-rtp-events.c (01a0 D> > rtp_event_type_values_ext) is not referred to so could be static? (in> header) It is used in UI, outside of dissectors. Therefore it should be exported. > epan/dissectors/packet-rtp.c

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

Hi Moshe, It would be possible. I would still like to hear from people if they think it is worth doing, and we would need to clear the current cases (perhaps with a list of agreed exemptions, like the PDCP key-setting functions I mentioned). I will likely start picking off issues when I have

Re: [Wireshark-dev] Plugin dissector - lookup expert_field_info

I would like to write "prot.has.error" in the filter and find all of my packets that have any condition that my dissector determines to be "an error". Otherwise I have to type a filter like prot && (_ws.expert.severity == "Error" || _ws.expert.severity == "Warn") To do that now, I

Re: [Wireshark-dev] Plugin dissector - lookup expert_field_info

On Jan 23, 2021, at 1:06 PM, jayrturne...@gmail.com wrote: > I want to wrap expert_add_info calls so that I can check the expert_field* > argument, see if the severity is PI_ERROR, and set a generated field in my > protocol that says “this packet has errors”. For what purpose? There's already

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

Would it also be possible to build this script into a GitLab CI job, to detect and prevent the issue from recurring? Moshe On Sat, Jan 23, 2021 at 11:45 AM Martin Mathieson via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi, > > I wrote a script to check whether variables and

[Wireshark-dev] Plugin dissector - lookup expert_field_info

I want to wrap expert_add_info calls so that I can check the expert_field* argument, see if the severity is PI_ERROR, and set a generated field in my protocol that says “this packet has errors”. The EXPERT_REGISTRAR_GET_NTH macro would be great, but the underlying gpa_expertinfo isn’t

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

Hi, I wrote a script to check whether variables and functions in dissector modules that were not static were: - not called by any other dissector modules (including dissectors.c) - mentioned in the header file corresponding to that dissector Reasons to clean up these cases could include: - it

Re: [Wireshark-dev] Revive the happy-shark repository?

Hi, > Years ago we added a repository for dissector regression tests at > https://github.com/wireshark/happy-shark. Unfortunately it hasn't > received much attention, and instead we've been adding dissector tests > in the main repository. Should we > > - Import happy-shark into GitLab and move

Re: [Wireshark-dev] Revive the happy-shark repository?

Hi, As for the options proposed by Dario, 1) git submodules basically pins a specific commit of an external repository into your repository. It also requires additional git commands to checkout and move the ‘pin’ forward when anything is added to the external repo which is desired in the git

Re: [Wireshark-dev] Revive the happy-shark repository?

Talking about your options: 1) my concern here is that we would have 2 repos, with parallel lifecycles, that are not enforced to stay aligned. A change in a dissector would benefit from a test case, but such a testcase in happy-shark would be proposed after the code merge in the main repo. That

[Wireshark-dev] Revive the happy-shark repository?

Hi all, Years ago we added a repository for dissector regression tests at https://github.com/wireshark/happy-shark. Unfortunately it hasn't received much attention, and instead we've been adding dissector tests in the main repository. Should we - Import happy-shark into GitLab and move our

Re: [Wireshark-dev] [Outreachy] Multiple-line parsing of packets dissected over HTTP

Hi Pascal, On Thursday, January 21, 2021 4:21 AM, Pascal Quantin wrote: > Hi Joey, > > Le mer. 20 janv. 2021 à 20:15, Joey Salazar a écrit : > >> Hi Pascal, >> >> On Wednesday, January 20, 2021 4:23 AM, Pascal Quantin wrote: >> >>> Hi Joey, >>> >>> Unfortunately you did not share the

Re: [Wireshark-dev] Multiple-line parsing of packets dissected over HTTP

Hi all, Jonathan, On Tuesday, January 19, 2021 6:09 PM, Jonathan Nieder wrote: > Hi, > > Pascal Quantin wrote: > > > Le mar. 19 janv. 2021 à 17:45, Joey Salazar via Wireshark-dev < > > wireshark-dev@wireshark.org> a écrit : > > > > In commit 33af2649 [1] we can keep dissecting the contents of

<    9   10   11   12   13   14   15   16   17   18   >