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

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

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

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

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 Keuter wrote

[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

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.

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

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

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

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

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

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/

s 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 immediate

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

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

[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

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

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

Re: [Wireshark-dev] 3.6.0 release schedule

at 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

[Wireshark-dev] On MR 4428

Hi, Looking at MR 4428 https://gitlab.com/wireshark/wireshark/-/merge_requests/4428 (cherry picked from commit 96cfaf67) it introduces a new symbol in the wiretap 11 library (wtap_uses_lua_filehandler). The debian symbols file contains the addition of "wtap_uses_lua_filehandler@Base 3.5.1",

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

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

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

[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

[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

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

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

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

HERNET_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 list fo

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:

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

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,

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

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

[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

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

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"

[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

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,

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:

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:

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

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

[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

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

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

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

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

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

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

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 comments i

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

Hi, For now(*) this is done as per https://wiki.wireshark.org/Development/SubmittingPatches#Writing_a_Good_Commit_Message (*) there’s a Big Move coming to a GitLab instance, this will Change

Re: [Wireshark-dev] Some apparent type bugs

Hi, Okay, I’ve pushed a change (38004 ) for the first ones. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > I won't have time to look into these properly for a few days - if anyone else > does please feel

Re: [Wireshark-dev] Some apparent type bugs

Hi, Don’t know, just noticed the UINT part and thought about returning 'a value' should be possible. Will have to look into this more closely to see if and what makes sense. Thanks, Jaap > On 31 Jul 2020, at 14:05, John Thacker wrote: > > > On Fri, Jul 31, 2020 at 7:51 AM

Re: [Wireshark-dev] Some apparent type bugs

Hi, This one you probably have to look into yourself, because that’s not from the published code base, AFAIKT. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > I won't have time to look into these properly for a few days - if anyone else > does

Re: [Wireshark-dev] Some apparent type bugs

Hi, This is the script tripped up by inserted comments I’m afraid. Thanks, Jaap > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > Error: proto_tree_add_item_ret_uint64 (.., hf_epl_od_uint , ...) called at > ./tools/../epan/dissectors/packet-epl.c 2744 with type >

Re: [Wireshark-dev] Some apparent type bugs

Hi, Shouldn’t these be supported? After all, they have a UINT. > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev > wrote: > > Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at > ./tools/../epan/dissectors/packet-ppp.c 2377 with type FT_UINT_BYTES >

Re: [Wireshark-dev] Some apparent type bugs

Hi Anders, This code in packet-pfcp.c, line 7482 looks wrong to me /* Octet 5 to 20 NF Instance ID */ proto_tree_add_item_ret_uint(tree, hf_pfcp_nf_instance_id, tvb, offset, 1, ENC_BIG_ENDIAN, _length); Isn’t this supposed to be /* Octet 5 to 20 NF Instance ID */

Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?

Hi, I can see both points of view. However, I think we can retain the code as is for ENC_NA (== ENC_BIG_ENDIAN) and add code to handle the ENC_LITTLE_ENDIAN case to it. This should not break any existing code, the choice ENC_NA = ENC_BIG_ENDIAN was made in that light. I think it's not in there

Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?

:) > On 30 Jul 2020, at 09:19, Tomasz Moń wrote: > > On Thu, Jul 30, 2020 at 8:58 AM Tomasz Moń <mailto:deso...@gmail.com>> wrote: >> >> On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter wrote: >>> Let’s put a hypothetical here, a 7 bit value spanning 2 octe

Re: [Wireshark-dev] Why tvb_get_bits() assumes Big Endian?

Hi, Let’s put a hypothetical here, a 7 bit value spanning 2 octets: 15 14 13 12 11 10 9 8| 7 6 5 4 3 2 1 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | | 6| 5| 4| 3| 2| 1| 0| | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ This would be the typical

Re: [Wireshark-dev] Code Coverage Measurement of Wireshark - Outdated Instruction

Sounds to me as something that could be made into a build option, but that’s just ’shooting from the hip’, I haven’t looked at the CMake files yet. > On 28 Jul 2020, at 11:11, Peimann, Jannis > wrote: > > Okay, I was able to find a workaround. > > I changed the following inside the main

Re: [Wireshark-dev] GurumNetworks RTPS Vendor ID Request

ou have any updates on the vendor lists, please let me know. > Thank you so much. > > Best, > Daeun Kim > > 2020년 7월 21일 (화) 오전 9:11, 김다은 님이 작성: > Hi, > > Thank you so much for kind reply and updating the vendor list. > > Sincerely, > Daeun Kim > >

Re: [Wireshark-dev] Using FTDI device ids from Linux kernel

Hi, Do you have any idea how volatile this data is, how quickly it’s changing? There are already some data sets which are picked up weekly from external sources (e.g., IEEE manuf, PEN). This could be handled the same way if as volatile as these. Thanks, Jaap > On 26 Jul 2020, at 11:01,

Re: [Wireshark-dev] proto_item_get_display_repr ignoring time zone

That smells like a bug to me. > On 23 Jul 2020, at 18:33, Thomas Wiens wrote: > > Hi, > > I've noticed that when I add a timestamp in UTC time zone > (ABSOLUTE_TIME_UTC) to the tree with proto_tree_add_time() it's displayd > in UTC as expected. But when I get the string from this proto_item

Re: [Wireshark-dev] GurumNetworks RTPS Vendor ID Request

Hi, This request triggered me to have a look at this vendor list as a whole. It seems the currently coded list is outdated. Therefore I’ve taken the opportunity to update the complete list, thereby adding GurumNetworks as well. Thanks, Jaap > On 20 Jul 2020, at 05:57, 김다은 wrote: > > Good

Re: [Wireshark-dev] Issues in synphasor dissector

; machines where simple type punning won't work. > > John Thacker > > > > On Mon, Jul 6, 2020 at 5:51 PM Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> wrote: > Hi, > > So, you want to keep this function call: > > proto_tree_add_item(wgs84_tree, hf

Re: [Wireshark-dev] Issues in synphasor dissector

as a constant type FT_FLOAT. I hope I got this right. Jaap On 7/6/20 10:12 PM, Елисеев Дмитрий Алексеевич wrote: > Hello, Jaap Keuter! > I made some fast cheks and need some help. > I need some function like: > /proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, >

[Wireshark-dev] Issues in synphasor dissector

Hi Dmitriy, There are still some issues with the synphasor dissector. There are a number of fields with the same field abbreviation, but incompatible type. These are lines from the 'conflict check' run by the buildbot: 'synphasor.conf.chnam_len' exists multiple times with NOT compatible types:

[Wireshark-dev] WLAN bug?

Hi Richard, Have you seen these entries from conflict check: ** (process:12824): WARNING **: 08:16:29.502: Field 'Status code' (wlan.fixed.status_code) has a conflicting entry in its value_string: 125 is at indices 125 (Requested TCLAS processing has been terminated by the AP due to conflict

[Wireshark-dev] Nordic_ble bug?

Hi Stig, Have you seen this entry from conflict check: ** (process:12824): WARNING **: 08:16:29.526: Field 'MIC' (nordic_ble.mic_not_relevant) has identical true and false strings ("Only relevant when encrypted", "Only relevant when encrypted”) Do you know how to address this? Thanks, Jaap

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

t how to set orange with buildbot on this case, > some others step (clang analyzer check, pre commit...) need this. > > And also if it is orange, it is not specific to this change.. > Le dim. 5 juil. 2020 à 11:16, Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> a écrit : > Hi A

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

Personally, when review code after Petri dish, I try to look different output > log, because I know don’t fail it is juste warning. > > Le dim. 5 juil. 2020 à 08:53, Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> a écrit : > Hi, > > Due to some recent issues with DHCPv6 t

[Wireshark-dev] Anyone with access to ANSI C12.22

Hi, In light of this change https://code.wireshark.org/review/37697, can anyone with access to ANSI C12.22 confirm that the changes in the ASN.1 is correct? Thanks, Jaap ___ Sent via:Wireshark-dev mailing list

[Wireshark-dev] Why is conflict check on the buildbot green?

Hi, Due to some recent issues with DHCPv6 the buildbot began flagging the 'conflict check' stage as failed. This drew my attention to the fact that there is a long list of warnings in there about wrong use of protocol fields, but once the DHCPv6 issues were fixed the build happily went back to

  1   2   3   4   5   6   7   8   9   10   >