[Wireshark-dev] Re: Confirm

Hi > On 11 Jul 2025, at 07:18, tabby Smith wrote: > > ___ > Wireshark-dev mailing list -- wireshark-dev@wireshark.org > To unsubscribe send an email to wireshark-dev-le...@wireshark.org ___ Wireshark-dev mai

[Wireshark-dev] Re: Regarding ISIS TLV - 139 support in wireshark

Hi, Since this is an all volunteer project there’s no Grand Plan of implementation of features. It all depends on who has the time and inspiration to implement the required code. If you can to that yourself, great. We welcome your merge request. If not, the best way forward is creating an issue

[Wireshark-dev] Re: Latest version of rfc6775 and rfc8505

> On 20 Jun 2025, at 12:34, Adnan Rashid wrote: > > Dear All, > > I would like to know if you have implemented the rfc6775 and rfc8505 in the > latest version of the Wireshark. > > > Thanks > -- > Regards, > > Adnan Hi, Packet-icmpv6.c, found in current stable branch, makes mention of

[Wireshark-dev] Re: g_new0() allocation in init_iousers()

> On 14 Jun 2025, at 22:24, Rustam Kovhaev wrote: > > On Sat, Jun 14, 2025 at 07:53:17PM +0200, Jaap Keuter wrote: >>> On 14 Jun 2025, at 18:52, Rustam Kovhaev via Wireshark-dev >>> wrote: >>> >>> Hi, >>> First of all, thank you for Wi

[Wireshark-dev] Re: g_new0() allocation in init_iousers()

Hi, Unless there’s an error, no we don’t. Because it’s passed in register_tap_listener(). Thanks, Jaap > On 14 Jun 2025, at 18:52, Rustam Kovhaev via Wireshark-dev > wrote: > > Hi, > First of all, thank you for Wireshark! I am using it a lot, and I mean > it, and I love it. > Quick sanity ch

[Wireshark-dev] Re: launchpad.net repository

Thanks Balint > On 18 May 2025, at 14:44, Bálint Réczey wrote: > > Hi Yves, > > It is available now. > > Cheers, > Balint > > On 2025. May 16., Fri at 16:40, ROGGEMAN Yves via Wireshark-dev > mailto:wireshark-dev@wireshark.org>> wrote: >> Any hope for a Plucky version in Wireshark stable rep

[Wireshark-dev] Re: Inquiry Regarding Protocol Identification Process in Wireshark

Hi Yoon-Seong Jang, Thank you for taking an interest in Wireshark and its internals. Let me try to discuss your inquiry. As you may be aware Wireshark is designed to handle all kinds of protocols, at any layer of the OSI model (apart from the Physical layer that is). To that end it has support

[Wireshark-dev] Re: On dissection of GSM A DTAP BCC Call State

Thanks Pascal, Fixed in !19256 > On 10 Mar 2025, at 09:54, Pascal Quantin via Wireshark-dev > wrote: > > Hi Jaap, > > Le dim. 9 mars 2025 à 17:12, Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> a écrit : >> Hi, >> >> When stumbling on pac

[Wireshark-dev] On dissection of GSM A DTAP BCC Call State

Hi, When stumbling on packet-gsm_a_dtap.c:de_bcc_call_state() I became thoroughly confused. What size are we handling here? 1) de_bcc_call_state() returns 1, indicating that only _one_ octet is consumed. 2) de_bcc_call_state() contains the following statement proto_tree_add_item(tree, hf_gs

[Wireshark-dev] Re: DHCP dissector giving up too early ?

Hi Chris, You could try the development version, which already has a solution to this issue implemented. Thanks, Jaap > On 5 Mar 2025, at 16:09, Chris Hall wrote: > > > I enclose a short .pcapng which includes one DHCP Discover and one DHCP > Request message. Both contain the same malform

[Wireshark-dev] Re: What to do with tvb_get_bits()

Hi, Ehm, yes, this is what you can do with tvb_get_bits32(), ie., read 1-32 bits into a 32 bit variable. That won’t change, only the implicit tvb_get_bits(), which is an alias for the explicit tvb_get_bits32(), would be deprecated. Thanks, Jaap > On 19 Feb 2025, at 23:28, Anders Broman wrote:

[Wireshark-dev] What to do with tvb_get_bits()

Hi List, Following [1] we should have no more calls to tvb_get_bits() in our code base anymore. This then opens up the possibility to deprecate this function in favour of tvb_get_bits_[8|16|32](). Would this deprecation cause unforeseen problems, or would this help to clean up our API? Thanks,

[Wireshark-dev] Re: Possible Typographical Error in Wireshark Documentation

Source text has been fixed, should eventually end up in published documentation. Thanks, Jaap > On 13 Feb 2025, at 12:35, Антон Дьяченко wrote: > > I believe in the Next Packet In Conversation item the same > Thank You > > чт, 13 лют. 2025 р. о 13:29 Антон Дьяченко

[Wireshark-dev] Re: a bug about MQTT

FWIW: ENC_LITTLE_ENDIAN is missing at https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-mqtt.c?ref_type=heads#L822 > On 17 Jan 2025, at 12:15, Alexis La Goutte wrote: > > Hi, > > Can you post the issue with the pcap on gitlab ? > > Cheers > > On Thu, Jan 16, 2025 at

[Wireshark-dev] Re: help - after building the Wireshark 4.5 cannot capture packets

Hi yeah, you’re at the right place. Figuring out permission issues is hard when you’re not at the system itself. My first thing would be to look for remnants of previous installations still lingering and being picked up. > On 2 Feb 2025, at 15:51, Mayank wrote: > > In addition to the above,

[Wireshark-dev] Re: Stratoshark 0.9 and 1.0 release planning

Hi, How much conflict would it create to ‘enhance’ the tag format throughout? I’m not particularly found of having a temporal influence on the format. Would the following work, avoiding ambiguity: - Release tags: wireshark-x.y.z / stratoshark-x.y.z - Release tags: wsvx.y.z / ssvx.y.z - RC tags:

[Wireshark-dev] Re: Adding Wireshark Samples

Hi, They're added to the editor-wiki, which should propagate to the general wiki shortly. Thanks, Jaap On 10/17/24 2:38 PM, Christina Quast wrote: Hi there! I have two samples of MDB data (Multi drop bus) that I created myself attached to this mail. I don't really want to have the right to

[Wireshark-dev] What to clean up before 4.4.1

Hi all, It would be nice to clean up before 4.4.1 rolls of the presses. I can think of one issue we need to decide on. https://gitlab.com/wireshark/wireshark/-/issues/20031 The proper answer doesn’t seem obvious, but apparently a change is required. Which change shall we make? Without testing i

[Wireshark-dev] Re: Question on tcp_dissect_pdus

Hi Martin, Good question. That is currently not possible. Also, this would also have to work with live capture, so we’re currently at the end of file, but it’s being extended with the packets we’re waiting for. At least that’s what I quickly can come up with. Thanks, Jaap > On 19 Sep 2024, a

[Wireshark-dev] packetBB and MANET

Hi, Should we go ahead and rename the packetBB dissector to MANET? PacketBB seems to be used in the early days, when RFC 5444 was being developed as draft-ietf-manet-packetbb. Now it has the title "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format”. Not sure if the term packetBB i

Re: [Wireshark-dev] [PATCH] Fix 80211be u-sig decode.

> On 18 Jul 2024, at 02:10, Ben Greear wrote: > > On 7/17/24 17:07, gree...@candelatech.com wrote: >> From: Ben Greear >> It is 32-bit instead of 16-bit. This fixes invalid parsing of the >> bandwidth, probably among other things. >> Signed-off-by: Ben Greear >> --- >> epan/dissectors/packe

Re: [Wireshark-dev] Compile error on debian

On 7/18/24 2:13 AM, Ben Greear wrote: Hello, I re-ran the setup script, but cmake is still failing on a missing pkg. Any idea what needs to be done to fix this? -- Check size of LUA_INTEGER - done -- Checking for one of the modules 'libilbc' -- Could NOT find ILBC (missing: ILBC_LIBRARY ILBC_IN

Re: [Wireshark-dev] Patch submission via e-mail/mailing list

Zigbee NCP dissector update in wireshark. >>> > >>> > I also attached a pcap which contains the added packets. >>> > >>> > Running wireshark (without the patch) shows a bunch of "Unknown Call >>> > ID" for packets which are no

Re: [Wireshark-dev] Patch submission via e-mail/mailing list

Hi, First of all, sorry that GitLab gives you grief. Please do follow up on the ticket, they usually seem to be open to address such issues AFIACT. As for the patch, this used to be the channel through which these were collected, before GitLab^WGerrit^WBugzilla. So please go ahead and attach on

Re: [Wireshark-dev] Wireshark Developer's Guide feedback

Hi, Thank you. I've created MR 15081 to address most of these concerns. I leave to update to the text the someone more in tune with the Lua API, I'm not sure what the best way to document this polymorphic beast is. Thanks, Jaap

[Wireshark-dev] Tracking branches, GitHub and Launchpad

Hi, A few observations which probably needs attention. 1. The GitHub mirror is picking up all our cherry-pick branches, which now run in the hundreds. IMHO, these should not be mirrored in the first place. How can we clean this up? 2. Launchpad upstream repo mirrors of GitHub. IMHO, it should

Re: [Wireshark-dev] wireshark handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none

Hi, With what Wireshark version in this? And a (synthetic) sample capture would go a long way investigating this. Thanks, Jaap > On 6 Dec 2023, at 12:08, Ariel Burbaickij wrote: > > Hello all, > > we have a special setup here: SS7 E1 is converted to SCTP traffic with the > following basic

[Wireshark-dev] The If_fcslen option unit mismatch

Hi, There’s a recent issue raised on a mismatch between the pcapng spec and Wireshark interpretation of it. The issue revolves around the unit used for the If_fcslen option in the pcapng file format. The Wireshark issue is here: https://gitlab.com/wireshark/wireshark/-/issues/19174 Apparently t

Re: [Wireshark-dev] Remove GPL (v3 or later) (with Bison parser exception) from our allowed license list?

Hi, It sounds like a reasonable choice to drop a (niche) unused licence. Thanks, Jaap > On 8 Oct 2023, at 23:49, Gerald Combs wrote: > > Hi all, > > We currently have "GPL (v3 or later) (with Bison parser exception)" in the > list of allowed licenses in checklicenses.py. Presumably that was

Re: [Wireshark-dev] 4.2.0 release schedule

Hi, This starts to resemble the Linux kernel merge window challenges. There's always a tradeoff between ease of development vs. churn. Things do need to settle down before a branch can be made, that's what we're here for. Personally I'm in the process of finalizing a new dissector (for iperf3)

[Wireshark-dev] SCTP statistics

Hi, Who knows what the current status of the SCTP statistics is? I’ve tried a few files, but couldn’t make sense of it. It looked like information was missing or not filled at all. Thanks, Jaap Send from my iPhone ___ Sen

Re: [Wireshark-dev] About the DNS resolver

:47, Gerald Combs wrote: > > Sounds fine to me. We had overlapping support for c-ares and ADNS for a > while, so this isn't new territory. Can you open an issue and set the > milestone to "Wireshark 5.x" so this doesn't get lost? > > On 8/20/23 12:08 PM, Jaap Ke

[Wireshark-dev] About the DNS resolver

Hi, So we’ve been using the c-ares name resolver for a while now and it’s serving its purpose. However, this is not the only one out there. DNS technologies have evolved somewhat and c-ares does not provide for them. Would it make sense to start looking into using libunbound[1] as a replacement

Re: [Wireshark-dev] add a BASE_DEFAULT_VALS

Hi, Use range_string rather than value_string. Jaap > On 14 Aug 2023, at 17:22, John Dill wrote: > > I've recently been doing a lot of enums that have multiple illegal values, > and the illegal value shouldn't be displayed as "Unknown" as it's hard coded > in proto.c (in 3.6.x). ___

Re: [Wireshark-dev] Help regarding CI failure in gitlab

Hi, Preliminary review comments you could address before making an MR: - Recreate the files using the dissector boilerplate doc/packet-PROTOABBREV.c - Get rid of the header file - The PCAP doesn’t go into a commit, it has to got into either a protocol page on the wiki, or in Sample Captures on t

Re: [Wireshark-dev] Wireshark ERROR While Running Cmake

Hi, It looks to me like you’re missing some required development packages. Not sure what environment you have, but you could refer to the setup scripts in the tools directory, e.g., arch-setup.sh Regards > On 30 May 2023, at 13:38, Anshula Singla wrote: > > > > Hi , > > Regarding I am

Re: [Wireshark-dev] Wiki: Backporting A Change To A Release Branch

Hi, Yes, the text is still relevant, in case you’re looking to back port a change from master to release-X.Y. What you’re seem to be looking at is making a change in release-4.0 only. So, checkout release-4.0 first. Then create a branch from that and put your change on there and push that. Reg

Re: [Wireshark-dev] First 4 bytes in SNMP application data

Hi, What you’re looking at is the SNMP encoding according to the Basic Encoding Rules[2] (BER). These octets define the BER structure. For example a 64 octet SNMPv3 message starts as such: SNMPv3Message ::= SEQUENCE { 30 3E msgVersion INTEGER ( 0 .. 2147483647 ), 02 01 03 Where 30 defi

Re: [Wireshark-dev] Editor config and code formatting

Hi, As consistent formatting not always translates into readable formatting (although in many/most cases it does) I’m not in favour of forced automatic formatting. And that is where great freedom comes with great responsibility. I’m already pleased if we can have a consistent style _per file_

Re: [Wireshark-dev] On building better statistics

> On 15 Feb 2022, at 13:20, João Valverde wrote: > > And also, it's not really correct to include IP inside ICMP as IP bytes, but > that's another issue entirely. Looking at the Protocol Hierarchy statistics, only the ‘top level’ protocols are counted. So, an IP header in a ICMP packet don’t

[Wireshark-dev] On building better statistics

This discussion was brought on by issue 17877 titled “Non-visible photo items cannot change length after construction”. In there it is correctly stated that calls to set proto_item length (either proto_item_set_len() or proto_item_set_end()) are not effective when proto_items are not visible. W

Re: [Wireshark-dev] PCAP-over-IP in Wireshark?

Hi, Cool that this works as intended / expected. All that is left now, as Guy indicated, is to document this properly. Chuck, feeling up to it? ;) Thanks, Jaap > On 1 Feb 2022, at 12:18, Erik Hjelmvik wrote: > > Thank you Guy and Chuck! > > Adding a Pipe interface with the path "TCP@127.0.0.

Re: [Wireshark-dev] Reassembly of split fragments

Hi, Few remarks. The mix-27010 dissector is made to dissect frames of type WTAP_ENCAP_MUX27010, or PCAP link layer header type, as defined at https://tcpdump.org/linktypes/LINKTYPE_MUX27010.html There it states what the layout in the PCAP

Re: [Wireshark-dev] Issues with cross-compiling

Hi, Maybe buildroot can give some inspiration: https://git.buildroot.net/buildroot/tree/package/wireshark Thanks, Jaap > On 17 Jan 2022, at 03:01, Glen Huang wrote: > > Hi, > > I’m trying to create an OpenWrt package for Wireshark. > > I think I’m pretty close. However, I got stuck at lemon

Re: [Wireshark-dev] MPLS Echo Packet containing FEC stack change Sub-TLV in DDMAP TLV is not decoded by wireshark or https://hpd.gasmi.net/

bytes sent in mail below are complete encapsulation with all headers > and those bytes can be directly copied to online hex-decoder for a quick look. > > > On Fri, Jan 7, 2022 at 12:31 PM Jaap Keuter mailto:jaap.keu...@xs4all.nl > wrote: > > > Hi, > > > > The

Re: [Wireshark-dev] MPLS Echo Packet containing FEC stack change Sub-TLV in DDMAP TLV is not decoded by wireshark or https://hpd.gasmi.net/

Hi, The immediate response by Alexis was to open an issue on the Wireshark issue tracker. My response would be to attach a small sample capture file with the packets, instead of some bytes or screenshot to the email. Can you do either of those? Jaap > On 6 Jan 2022, at 06:31, max payne.. wr

Re: [Wireshark-dev] Need help figuring out a large gap in trace | Windows 11

Hi, Not sure what’s going on here, but there’s one thing I would like to point out. For long term capture I would *strongly* recommend using dumpcap instead. Reason behind this is that Tshark invokes the dissection engine for the captured packets, which in this case is not what’s needed, but sti

[Wireshark-dev] ISO-8601 date support

Hi Jörg, With commit a0173cd7 you’ve added ISO-8601 date support to text2pcap. The “Import from Hex dump...” feature of Wireshark is supposed to be equally capable. Would you be able to add this capability there as well? Thanks, Jaap ___

Re: [Wireshark-dev] Is there some reasonable way to split up epan/dissectors/packet-ieee80211.c into smaller files?

Hi Richard, Indeed it’s a rather monolithic block. Quick look at the code, here are some suggestions . - Extract the dissection of the fixed management fields. All these add_ff_... functions count up to a lot. Not sure how they are dependant on other parts of the dissector, but these at least o

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 v

Re: [Wireshark-dev] 3.6.0 release schedule

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

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, <mailto:jaap.keu...@xs4all.nl&g

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 f

[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", whi

[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] 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 > (https://gi

[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 _

Re: [Wireshark-dev] Byte view mouse hover behaviour

> Roland > > Am Sa., 11. Sept. 2021 um 15:45 Uhr schrieb John Thacker > mailto:johnthac...@gmail.com>>: > On Sat, Sep 11, 2021 at 7:23 AM Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> wrote: > Hi all, > > Often when working with captured data from so

[Wireshark-dev] Byte view mouse hover behaviour

Hi all, Often when working with captured data from some development setup I wonder around the packet bytes with the mouse pointer to try and follow where in the code under development certain parts of a packet contents is being created. What happens now is that the highlighting of the field whe

Re: [Wireshark-dev] Unknown CMake command "check_function_exists".

ake-rpm-macros-3.11.4-7.el8.noarch > cmake-3.11.4-7.el8.x86_64 > cmake-filesystem-3.11.4-7.el8.x86_64 > cmake-data-3.11.4-7.el8.noarch > > Thanks, > > --Jorge > > From: Wireshark-dev <mailto:wireshark-dev-boun...@wireshark.org>> on behalf of Jaap Keuter >

Re: [Wireshark-dev] Unknown CMake command "check_function_exists".

Hi, The module CheckFunctionExists [1] has been around from at least cmake 3.0, so that’s not new. The first question then would be if, besides cmake, the cmake modules are installed as well? [1] https://cmake.org/cmake/help/v3.11/module/CheckFunctionExists.html Thanks, Jaap > On 10 Aug 2021

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 th

Re: [Wireshark-dev] Proposal: New set of help pages for VoIP dialogs

Hi, You could instead think about adding to the user guide, where this stuff should be in the first place. Thanks, Jaap > On 29 Mar 2021, at 08:36, Jirka Novak wrote: > > Hi, > > I'm working on VoIP dialogs for several weeks. RTP Player was > significantly changed, there are more available

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

ETHERNET_MPACKET” > should be able to hold any and all valid Ethernet mPackets according to IEEE > 802.3br. > > Regards, > Timmy Brolin > > > > From: Wireshark-dev On Behalf Of Jaap > Keuter > Sent: den 15 februari 2021 21:12 > To: Developer support li

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

bug everything from the lowest to the highest level aspects of > Ethernet. > All specification-compliant packets on the wire should decode properly in > Wireshark, and Wireshark should not lie to the user about how the packet > looks on the wire. > > Regards, > Timmy Brolin &g

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] 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

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

[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:org

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

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

> On 20 Jan 2021, at 11:46, Ari Timonen wrote: > > The specification IEEE P802.1AS-Rev/D8.0 page 155 has the correct TLV flags. Hi, Looking in IEEE Std 802.1AS-2011, at table 10-14 it lists Bit Name 1 computeNeighborRateRatio 2 computeNeighborPropDelay What draft are you referencing?

Re: [Wireshark-dev] Setcap in ubuntu 20.04

Hi, Yes, I’ve seen this some time ago, and Gerald bumped into it also. What I do as a workaround, is to add a symlink in the build directory: libwsutil.so.0 -> run/libwsutil.so.0 Thanks, Jaap > On 6 Jan 2021, at 22:19, João Valverde via Wireshark-dev > wrote: > > > > On 06/01/21 20:32, D

Re: [Wireshark-dev] Software requirements specification

On 30-12-2020 10:37, Anna Gkika Zosan wrote: Greetings, My name is Anna and I am relatively new to open source programming. I’m really interested in writing a SRS about Wireshark. Is there already one or having one is something that could be used? Thank you in advance Hello, Welcome to t

Re: [Wireshark-dev] Documentation : 9.6. How to produce protocol stats

Hi, Thanks for having a look and reporting back. This could have been done as a merge request, this works as well. I’ve created one on your behalf, see WSDG: update protocol stats section to match current API Further comments are i

[Wireshark-dev] ZLIB on macOS build discrepancy?

Hi, Not that it bothers me too much but I noticed (another) library mismatch in 3.4.2 tools/macos_setup.sh sports ZLIB_VERSION=1.2.11, while About Wireshark (3.4.2) states “with zlib 1.2.8,”. Looking at my currently installed 3.4.0, it says "with zlib 1.2.11,” so it seemed to have rolled bac

Re: [Wireshark-dev] Regarding Wireshark plugin project

Hi Martin, FYI: the OBD-II dissector was already included in Wireshark 3.4 Hope someone can help you out. Thanks, Jaap > On 11 Dec 2020, at 08:49, Martin Falch wrote: > > Hi Wireshark Developers, > > I tried sending a mail some time ago for a paid project on a Wireshark > plugin, but I don't

Re: [Wireshark-dev] clang-tools on Windows source code

> On 11 Dec 2020, at 22:36, Gerald Combs wrote: > > validate-clang-check.sh doesn't exist in master-3.2. It started out as > validate-clang-check.py, but was migrated to a shell script in master in > August in b586f2578. We should probably cherry-pick that to 3.2 and add > "#ifdef _WIN32" gu

[Wireshark-dev] clang-tools on Windows source code

Hi, When changing Win32 code the jobs run for master and release-3.4 borked on this: 4882$ sh -c '[ ! -e ../tools/validate-clang-check.sh ] || ../tools/validate-clang-check.sh' 4883/builds/wireshark/wireshark/build/../ui/win32/file_dlg_win32.c:13:10: fatal error: 'tchar.h' file not found 4884#i

Re: [Wireshark-dev] How does this not blow up?

can’t see a user following this code path. Still going to fix the code though. Thanks, Jaap > On 11 Dec 2020, at 00:15, chuck c wrote: > > It does "blow up" with 3.5.0rc0. Not sure why it works with 3.4.1. > > > On Thu, Dec 10, 2020 at 4:06 PM Jaap Keuter <mailt

[Wireshark-dev] How does this not blow up?

Hi, In "ui/win32/file_dlg_win32.c" static void format_handle_wm_initdialog(HWND dlg_hwnd, print_args_t *args) { HWND cur_ctrl; ... switch (args->print_dissections) { case print_dissections_none: case print_dissections_collapsed: SendMessage(cur_ctrl, CB_SETCURS

Re: [Wireshark-dev] Problem with ENC_BCD_DIGITS_0_9 odd/even

Hi, Indeed a nasty one. You need sub-octet length indication here, which doesn’t exist. But since it’s limited to nibbles, a single flag is all that’s really needed. Anything above the ENC_CHARENCODING_MASK would be fine. This would be the minimalist implementation of this: proto_tree_add_item

Re: [Wireshark-dev] G729

Hi Balint, Thank you for paying attention to this. Regards, Jaap > On 8 Dec 2020, at 23:00, Bálint Réczey wrote: > > Hi Jaap, > > Thanks for the heads up!: > https://salsa.debian.org/debian/wireshark/-/commit/4f3b519334121ee8115f255d21c22f305e233cc2 > > Cheers, &

Re: [Wireshark-dev] G729

eve that the bug you reported is fixed in the latest version of bcg729, which is due to be installed in the Debian FTP archive. ---8<--- This opens the path to having G.729 capability in regular Debian and derivatives builds. Jaap > On 6 Aug 2017, at 10:47, Jaap Keuter wrote: >

[Wireshark-dev] PAD file updates desired

Hi, Looking at the PAD file published for Wireshark 3.4.0 it seems it needs some tweaks. - The Program_OS_Support item still lists Win7 x32 and Win7 x64, while support is supposed to be ended. - The Application_Screenshot_URL links to an image that shows the GTK+ interface, which can no longer

[Wireshark-dev] Automatic updates fail

Hi Gerald, Good morning. The submission of automatic updates seems to fail, see https://gitlab.com/wireshark/wireshark/-/merge_requests/994 Thanks, Jaap ___ Sent via:Wireshark-dev mailing list Archives:https://www.

Re: [Wireshark-dev] Tshark closing unexpectedly due to failure reading from file

Hi, From the issue report I saw that you’re using some development version “TShark (Wireshark) 3.1.0 (v3.1.0rc0-268-g09a04829)”. Can’t say it makes a difference in this case, but this is not recommended. If you could update to the latest 3.2, or 3.4 release that would at least give us some stab

Re: [Wireshark-dev] Marking GitLab issues as duplicates

"Clear as mud” ;) Thanks for sharing > On 6 Nov 2020, at 02:57, Guy Harris wrote: > > If you type a / at the beginning of a comment, it pops up a menu of "quick > actions". > > One of those actions is /dup{licate}. If you type > > /duplicate #N > > and save that comment, GitLab w

[Wireshark-dev] Tweak bug template to get _all_ version info

Hi, Again it’s seems difficult to get people to add _all_ version informalities when filing a bug report. Only the version string is copied then. We’ve introduced a “Copy to clipboard’ button on the About Wireshark dialog for this. Can the template be adjusted to direct users to use that button

Re: [Wireshark-dev] MATE not extracting fields as requested

Hi Harald, I've created issue 16961[1] on your behalf. Thanks, Jaap [1] https://gitlab.com/wireshark/wireshark/-/issues/16961 On 24-10-2020 18:43, Harald Welte wrote: > Hi Jaap, > > thanks for your insight into the matter. As you confirm there is an actual > bug, I will raise > it in gitlab,

Re: [Wireshark-dev] MATE not extracting fields as requested

, ieee80211-radio, pcomtcp, pktc, atalk, mgcp(!), epon, hci_h4, f5ethtrailer, aruba-erm, cisco-sm, pflog, clip, aruba-adp, mtp3. These would potentially fall victim to the same problem. Thanks, Jaap > On 23 Oct 2020, at 13:12, Jaap Keuter wrote: > > Hi, > > Quick test shows that thi

Re: [Wireshark-dev] MATE not extracting fields as requested

Hi, Quick test shows that this is indeed the interaction between setting lengths after prototree item creation and post dissectors. In fact _all_ proto item modification functions need to be reviewed in this light. Thanks, Jaap > On 23 Oct 2020, at 12:33, Jaap Keuter wrote: >

Re: [Wireshark-dev] MATE not extracting fields as requested

Hi, Okay this is indeed weird. The MATE engine picks up the protocol but determines that the protocol fields are in a zero length part of the packet. It sees the fields, but these all fall outside of the zero length part of the packet (obviously). There is something specific about how the MGCP

Re: [Wireshark-dev] MATE, ip_addr and same source/est IP / loopback traffic

Hi, This is a tough one. Our resident MATE developer hasn’t been active for a while now, and so far no one has really picked it up. I did a quick test (after getting debugging working again) and found that the protocol fields are added to an ‘Address-Value-Pair-List’ (AVPL) on basis of uniquene

Re: [Wireshark-dev] Trouble uploading Wireshark enhancement

> On 23 Oct 2020, at 04:21, Fulko Hew wrote: > > I've enhanced a Lua based dissector, and have also rewritten it > in 'C' so that it can be included in the next release of Wireshark. > > Now I'm trying to submit it. My last submission was back in 2007, > and things have changed a little since

[Wireshark-dev] Working with the wiki clone

Hi, So, the GitLab Wiki has a ‘clone repository’ option and I thought to try it out. It simply lists what needs to be done, i.e. installing the gollum gem, cloning the Wiki repo and launching gollum from the directory when the clone is. Helas, no Wiki, just a 'Create page' for Home. After som

Re: [Wireshark-dev] So how are fixes cherry-picked to release branches?

+1 Still working out the nooks and crannies of the review procedure itself, so this would be welcome. > On 2 Sep 2020, at 10:02, Guy Harris wrote: > > Searching for "cherry" on the Wiki finds these pages: > > https://gitlab.com/wireshark/wireshark/-/wikis/Development/Backporting > >

Re: [Wireshark-dev] Gitlab wiki search

Indeed it’s a bit coarse. It seems improvements are planned, see https://docs.gitlab.com/ee/user/project/wiki/#customizing-sidebar , not sure what that will bring. > On 22 Aug 2020, at 13:43, Graham Bloice wrote: > > Maybe I'v

Re: [Wireshark-dev] GSoD approved technical writer - community bonding phase

> On 17 Aug 2020, at 16:07, Moshe Kaplan wrote: > > 1. The Wireshark manuals are written with docbook. The text is in the > wsug_src directory here: > https://gitlab.com/wireshark/wireshark/-/tree/master/docbook > . Information >

Re: [Wireshark-dev] Filtering on a field when there is more than one such field in a Wi-Fi packet

Hi Richard, The display filter engine has no concept of individual instances of a field, either it’s there in a packet or not and its value is used in the expression. Where it is in the packet and in what relation to other fields in a display filter expression is of no concern of the display fi

Re: [Wireshark-dev] Protocol to tie Bugzilla entry to Gerrit change

> On 13 Aug 2020, at 09:37, Guy Harris wrote: > > On Aug 13, 2020, at 12:24 AM, Jaap Keuter wrote: > >> For now(*) this is done as per >> https://wiki.wireshark.org/Development/SubmittingPatches#Writing_a_Good_Commit_Message > > He's talking about comme

  1   2   3   4   5   6   7   8   9   10   >