[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

Re: [Wireshark-dev] Markup failure in WSDG

Hi Len, Thanks for letting up know. Change incoming in https://code.wireshark.org/review/#/c/37674/ Jaap > On 2 Jul 2020, at 07:41, Len Chisholm via Wireshark-dev > wrote: > > Hi, > > In the WSDG at >

Re: [Wireshark-dev] Proposal to improve filtration speed by caching fields that are queried recently

HI, Not sure since when the filtering system has been worked on in this depth, but I suspect it has been a while. Finding someone completely up to speed about this may be a challenge. Thanks, Jaap > On 15 Jun 2020, at 05:38, Sidhant Bansal wrote: > > Hi all, > > I want to propose an

Re: [Wireshark-dev] New kafka dissector

Hi, Few words on why this is a non-starter, but also a way forward. The Wireshark code base is written in C (and C++ for the Qt based GUI) to maintain cross platform compatibility. Code written in other languages are therefore a lot of work to integrate into the already complex build system,

Re: [Wireshark-dev] Does a filter expression allow searching with a string of bytes as decimal numbers?

Well, simply entering three digit decimal values in the Wireshark display filter shows that it’s not a valid byte string, so hex only. I do agree that this type could be (more clearly) described in the Users Guide. Jaap > On 9 May 2020, at 17:12, Richard Sharpe wrote: > > Hi folks, > >

Re: [Wireshark-dev] Regenerating packet-parlay.c

On 5/4/20 11:16 AM, Luke Mewburn wrote: > On 20-05-04 10:55, Jaap Keuter wrote: > | Hi Luke, > | > | > Yes, I regenerated the code using that patch to > | > tools/wireshark_gen.py, and it builds fine across a couple of > | > platforms. > | >

Re: [Wireshark-dev] Regenerating packet-parlay.c

On 5/4/20 11:24 AM, Alexis La Goutte wrote: > Hi, > > I have already on the past try to rebuild parlay and remember i don't get the > same output... > but like Luke say, it will be coming from dict don't sort correctly > > Luke, can you push your ./idl-regen on CMakeList.txt ? > we can (need) to

Re: [Wireshark-dev] Regenerating packet-parlay.c

On 5/3/20 10:35 AM, Luke Mewburn wrote: > On 20-05-01 13:46, Jaap Keuter wrote: > | On 5/1/20 12:02 PM, Luke Mewburn wrote: > | > On 20-05-01 07:34, Jaap Keuter wrote: > | > | > | > | > On 1 May 2020, at 04:13, Luke Mewburn > | > | > wrote: Ho

Re: [Wireshark-dev] Regenerating packet-parlay.c

On 5/1/20 12:02 PM, Luke Mewburn wrote: > On 20-05-01 07:34, Jaap Keuter wrote: > | > | > On 1 May 2020, at 04:13, Luke Mewburn wrote: > | > However, looking at the code some more, it appears that generally > | > wireshark_gen.py generates code in the order th

Re: [Wireshark-dev] Regenerating packet-parlay.c

> On 1 May 2020, at 04:13, Luke Mewburn wrote: > > On 20-04-30 20:30, Jaap Keuter wrote: > | On 4/30/20 2:41 AM, Luke Mewburn wrote: > | > On 20-04-30 10:35, Luke Mewburn wrote: > | > | As to the problem; looking at the use of .keys() in wireshark_gen.py, >

Re: [Wireshark-dev] Regenerating packet-parlay.c

On 4/30/20 2:41 AM, Luke Mewburn wrote: > On 20-04-30 10:35, Luke Mewburn wrote: > | As to the problem; looking at the use of .keys() in wireshark_gen.py, > | there's a couple of places where the code is either: > | - get_intlist(), sorted: > | ret = list(ex_hash.keys()) > |

[Wireshark-dev] Regenerating packet-parlay.c

Hi list, While working on the IDL dissectors, so packet-coseventcomm.c, packet-cosnaming.c, packet- gias.c, packet-parlay.c and packet-tango.c, I was able to use the idl2wrs toolchain to regenerate all these dissectors (with minor issues), with the exception of packet-parlay.c. There the diff

Re: [Wireshark-dev] Wiki editor permissions

Done. On 4/17/20 7:41 PM, chuck c wrote: > wiki username: ChuckCraft > > Would like to add to Sample Captures page. > > thanks > chuck > ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] GitLab migration update

> On 4 Apr 2020, at 01:46, Gerald Combs wrote: > > We also have a self-hosted test server up and running at > https://gitlab-test.wireshark.org . Feel > free to create an account, create merge requests, etc. If you'd like to try > out a feature that

Re: [Wireshark-dev] range_string checking

> On 2 Apr 2020, at 23:08, Martin Mathieson via Wireshark-dev > wrote: > > It is common to have a 'catch-all' case for parts or all of the range, which > is Ok if it comes after more specific entries. I'm wondering if its worth > complaining if *part* of an entry is hidden by an earlier

Re: [Wireshark-dev] packet-hislip & tls

Hi Guido, I’m not sure we have another protocol which supports switching back to plain text after going TLS. Therefore I’m not sure if there is intrinsic support for it. My first instinct would be to setup a new conversation, starting the frame after ‘close notify’, with the HiSLIP dissector

Re: [Wireshark-dev] Table 1. Typographic Conventions

Hello, Well, actually there is a distinction between the two. The monospace examples have their contents on the background, as is. The bold monospace examples have their contents on the alternative background. Since the convention in a table is to alternate the backgrounds on a row by row

Re: [Wireshark-dev] Bug 16294, in_progress?

; the status field was for. ;-) > Change will include support for draft-ietf-idr-segment-routing-te-policy-08 > and draft-ietf-idr-tunnel-encaps-15. > > Cheers > Uli > >> Am 27.12.2019 um 20:29 schrieb Jaap Keuter : >> >> Hi Uli, >> >> You’ve changed the bug to IN_

[Wireshark-dev] Bug 16294, in_progress?

Hi Uli, You’ve changed the bug to IN_PROGRESS, do you intend to push a change for this? I’ve got one ready, so if you can’t I can. Thanks, Jaap ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] wiki edition request

That was so simple, I’ve already put them on the SampleCaptures page. Thanks for your contribution, Jaap > On 8 Dec 2019, at 16:41, Eugène Adell wrote: > > Hi guys, > > I would like to add some captures on the dedicated wiki page. My > username : EugeneAdell > > Or if you prefer to edit

Re: [Wireshark-dev] 3.1.1 and 3.2.0 release schedule

Are we gonna give the new Qt a little 'soak time’ in the field before going all in on that one? Would be nice to prevent unexpected regressions. > On 18 Nov 2019, at 18:12, Gerald Combs wrote: > > On 11/18/19 5:53 AM, Maynard, Chris via Wireshark-dev wrote: >>> -Original Message- >>>

Re: [Wireshark-dev] G729 Wiki page

Keep it as reference for Wireshark versions in the field that do not have this capability, which will be for a long time to come. > On 17 Nov 2019, at 21:15, Jiří Novák wrote: > > Dear Graham, > >> Can you update the Wiki page when that occurs? > > I do my best. > BTW what do you expect to

Re: [Wireshark-dev] G729 Wiki page

Hi, We have G.729 decode in the player, but can’t save media in RTP streams other than G.711A/μ. There are probably easier ways to do this now since the page was written. A rework of the decoding pipeline in Wireshark, so that both player and file saving could use them would be best, but

Re: [Wireshark-dev] Wireshark review to release

Hi, Like Roland stated, updates and enhancements are limited to the next version to be released, bug fixes go there too and are back ported. A very quick look at your committed changes seem to suggest to me these are bug fixes, the merger should have picked up on these. These would have to be

[Wireshark-dev] QtCustomPlot: New Defects reported by Coverity Scan for Wireshark

Hi Alexis, Roland, I assume you are aware of these: > Begin forwarded message: > > From: scan-ad...@coverity.com > Subject: New Defects reported by Coverity Scan for Wireshark > Date: 20 September 2019 at 07:46:10 CEST > ... > > ** CID 1453859:(DIVIDE_BY_ZERO) > > >

[Wireshark-dev] Redoing the maintenance release?

Hi, Given bug 16050 (Wireshark 3.0.4 does not start on macOS 10.13 after an upgrade from 3.0.3) and bug 16052 (Upgrade from Wireshark 3.0.2/3.0.3 to 3.0.4/later is confusing and may not complete properly) it may be a good idea to re-engineer the installer specifics for both macOS and Windows

Re: [Wireshark-dev] Wireshark Windows libraries

I think you’re right Pascal, let it soak for a while to see if there are any showstoppers reported. We can pick it up whenever we want/feel that it’s good enough. I would propose to push back the maintenance releases to next week, say Friday Sept. 13th? That should be okay right ;) Jaap >

Re: [Wireshark-dev] Wireshark Windows libraries

So, are the new maintenance releases pending on yet another Npcap release? Noticed that Npcap 0.9983 was just release today. > On 17 Aug 2019, at 10:25, Pascal Quantin wrote: > > Hi Jaap, > > Le sam. 17 août 2019 à 10:18, Jaap Keuter <mailto:jaap.keu...@xs4all.nl>> a

Re: [Wireshark-dev] Qt issue with first section not movable

No problem for me. > On 3 Sep 2019, at 17:38, Roland Knall wrote: > > Would this be a deal breaker for you, if the first column can no longer be > moved around? ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] Wireshark Windows libraries

> On 16 Aug 2019, at 17:43, Pascal Quantin wrote: > > I'm currently working on a patch that will update the 3 dependencies. Thanks Pascal, both changes look good to me (but I’m not a Windows developer, so what do I know ;) ) Thanks, Jaap

Re: [Wireshark-dev] Wireshark Windows libraries

> On 15 Aug 2019, at 18:54, Gerald Combs wrote: > > On 8/14/19 11:33 PM, Jaap Keuter wrote: >> Hi, >> >> In order to prevent a missed update (like last time with Npcap 0.996) it >> might be a good idea to already prepare for the following: >> N

[Wireshark-dev] Wireshark Windows libraries

Hi, In order to prevent a missed update (like last time with Npcap 0.996) it might be a good idea to already prepare for the following: Npcap 0.996 -> 0.9982 USBPcap 1.5.2.0 -> 1.5.3.0 Thanks, Jaap ___ Sent via:

Re: [Wireshark-dev] Glitches in UI when using recent buildbot development versions

Hi Jim, Any dark mode stuff going on? Thanks, Jaap > On 28 Jun 2019, at 18:11, Jim Young wrote: > > Hello, > > I almost exclusively run development versions of Wireshark when doing my day > to day troubleshooting tasks and I typically (but not always) do the analysis > on a macOS system.

Re: [Wireshark-dev] Question about dissector "enhancement" / bug

Hi Jason, Indeed, not so easy to find. The roadmap[1] states the intention to have a decent snapshot of the current developments in 3.1 posted as development build on the front page at about July 18th. Thanks, Jaap [1] https://wiki.wireshark.org/Development/Roadmap

Re: [Wireshark-dev] Bzip2 support

> On 26 Jun 2019, at 19:41, Guy Harris wrote: > > It could probably be done (note that for decompressing capture files that > would require the ability to do random access I/O, It (http://sourceware.org/bzip2/manual/manual.html#limits) now says: "Further ahead, it would be nice to be able to

Re: [Wireshark-dev] IO Graphs wording

Please do. > On 19 Jun 2019, at 14:02, Dario Lombardo wrote: > > Personally I like I/O as well. I am pleased that search engines can > understand both IO and I/O, but I like that applications still use I/O in > labels. > Then, unless someone objects, I'd go with a patch to use I/O everywhere.

Re: [Wireshark-dev] tvb_reported_length vs tvb_captured_length

Hi, When a dissector returns an integer value it returns the amount of packet data it has dissected to its calling dissector. Therefore, if a dissector intends to dissect all data it can return the length of the captured data it is handed. Therefore it uses tvb_captured_length. > On 4 Jun

Re: [Wireshark-dev] core dump when parsed VoIP call with text media

Tried it with current HEAD of master, still same event happens. Packet number seems to be 1, but packet scope assert fails. This will need a deeper look, so please file a bug report with relevant files attached so someone with time available can take a crack at it. Thanks, Jaap > On 31 May

Re: [Wireshark-dev] Git hooks

Hi, Interesting idea, but why the need for a new directory? Point core.hooksPath to tools and be done with it? Thanks, Jaap > On 20 May 2019, at 10:36, Dario Lombardo wrote: > > Hi list > In the current development process we're trying to enforce the contribution > quality by providing git

Re: [Wireshark-dev] Capture Loopback Traffic on Windows

As does using Npcap as capture engine. > On 6 May 2019, at 15:42, Manuel König via Wireshark-dev > wrote: > > Hi, > > I stumbled upon the wiki article about the Loopback capture setup > (https://wiki.wireshark.org/CaptureSetup/Loopback > ).

Re: [Wireshark-dev] Bug #15731 - Make header_field_info.abbrev different than protocol name

Hi, Have a look at packet-tte.c which handles a similar problem. Thanks, Jaap > On 30 Apr 2019, at 16:54, Andrii Vladyka wrote: > > Is there a way to make "protocol" portion of header_field_info.abbrev > structure member different than protocol name? E.g. protocol name is > "docsis",

[Wireshark-dev] Attn: coverity admins

Hi, The Coverity dashboard says "Apr 01, 2019 Last Analyzed”. Are we still sending scans? Thanks, Jaap ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe:

[Wireshark-dev] Logging into Coverity Connect

Hi, Anyone else having problems with getting to view the defects? Logging into scan.coverity.com works as usual, but trying to view the defects fails. It starts off to go to Coverity Connect, then comes back with "It may take a few minutes before you can view your defects, when you change your

Re: [Wireshark-dev] Release lifetime and version number changes?

Does Python release *every* build to the general public, as Wireshark does? If so, how are these identified? I could only find specific defined releases, starting from Alpha so-and-so. > On 12 Apr 2019, at 12:51, Ross Jacobs wrote: > > I agree that even/odd is non-standard and confusing. > >

Re: [Wireshark-dev] Wireshark outside

Hi, Tx is never going to be an input. You’re looking at making a passive tap. See https://wiki.wireshark.org/CaptureSetup/Ethernet for more background info on all capture setups. Thanks, Jaap > On 20 Mar 2019, at 17:20, С.Сергеев via

Re: [Wireshark-dev] Installing Wireshark Ubuntu

You will have to provide some more information than that... What are you doing, and what problem do you run into. > On 20 Mar 2019, at 04:11, RBohling162 wrote: > > I cant seem to get this install right. > ___ Sent via:

Re: [Wireshark-dev] Exposing ieee802.11 reason codes outside of dissect-ieee80211.c

Hi Richard, It’s not ideal, but not unheard of, so I don’t see why it can’t be done here. Thanks, Jaap > On 8 Mar 2019, at 04:32, Richard Sharpe wrote: > > Hi folks, > > One of the other specs, IEEE1905 refers to the reason codes defined in > table 9-45 of IEEE802.11. > > The easiest way to

Re: [Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

> On 26 Feb 2019, at 02:18, Gerald Combs wrote: > > On 2/25/19 2:29 PM, Guy Harris wrote: >> On Feb 25, 2019, at 2:02 PM, Gerald Combs wrote: >> >>> It looks like we need to build GMP for older CPUs. >>> >>> According to your last crash report, you're running a Core i7-3720QM and >>>

Re: [Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

> On 24 Feb 2019, at 21:30, Guy Harris wrote: > > On Feb 24, 2019, at 12:05 PM, Jaap Keuter wrote: > >> Just tried it, no luck. > > And no stack trace, either. > > What capture file are you running this on, and what operation are you > performing on

Re: [Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

> On 24 Feb 2019, at 12:59, Michael Tuexen > wrote: > >> On 24. Feb 2019, at 12:25, Jaap Keuter wrote: >> >> >>> On 23 Feb 2019, at 11:33, Michael Tuexen >>> wrote: >>> >>>> On 23. Feb 2019, at 10:32, Jaap Keuter wrot

Re: [Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

> On 23 Feb 2019, at 11:33, Michael Tuexen > wrote: > >> On 23. Feb 2019, at 10:32, Jaap Keuter wrote: >> >> >>> On 16 Feb 2019, at 20:38, Gerald Combs wrote: >>> >>> We recently switched to a new macOS builder. libssh required a

Re: [Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

On 16 Feb 2019, at 20:38, Gerald Combs wrote:We recently switched to a new macOS builder. libssh required a special workaround when building the application bundle on the old builder, and it requires a slightly different workaround on the new builder. Fix inbound in change

[Wireshark-dev] Wireshark 3.0.0rc1 on macOS Mojave 10.14.3

Hi List, Got this after installing the package over the existing 2.6.6 install, and starting Wireshark from Terminal: Last login: Wed Feb 13 07:59:00 on console aglaea:~ jaap$ Wireshark dyld: Library not loaded: @rpath/libssh.4.dylib Referenced from:

Re: [Wireshark-dev] Memory leak debugging - current master passes all tests!

Nice work Peter, you’re a machine! > On 28 Jan 2019, at 22:02, Peter Wu wrote: > > Hi! > > I am happy to share that current git master passes all tests without > failing on memory leaks (as reported by AddressSanitizer)!

Re: [Wireshark-dev] Editor privileges for Wiki?

Done, go ahead adding the info. > On 15 Jan 2019, at 02:59, Daniel Cervera via Wireshark-dev > wrote: > > Hello! > > I attempted to visit any protocol information hosted on this page, and saw it > was empty: > > https://wiki.wireshark.org/Protocols/x509ce >

Re: [Wireshark-dev] Raspberry

> On 14 Jan 2019, at 21:24, Dario Lombardo wrote: > ... > According to > http://archive.raspbian.org/raspbian/dists/wheezy/main/binary-armhf/Packages > > the wireshark version shipped with raspbian is 1.12. Don't

Re: [Wireshark-dev] Raspberry

Hi Jean, You should install the version from the Raspbian repository itself. That is guaranteed to match with your architecture and software configuration. Regards, Jaap > On 13 Jan 2019, at 20:48, jean CRAVATTE wrote: > > Hello > I am using Wireshark on a windows PC and I admire te power

Re: [Wireshark-dev] Suggestions to improve the Wireshark download web page notes on download page?]

> On 11 Jan 2019, at 03:12, Luke Mewburn wrote: > > Hi, > > [Is there a better list to discuss suggestions and improvements > to the wireshark.org web page?] > This list should be okay. > > I'd like to suggest an improvement to the "Download Wireshark" pages: >

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

> On 6 Jan 2019, at 19:54, Guy Harris wrote: > > On Jan 6, 2019, at 10:30 AM, Jaap Keuter wrote: > >> Rather than simplistic endpoint ID’s I think we need an ID tuple per >> endpoint, > > How is a tuple not itself an ID? It is, just not limited to the address/

Re: [Wireshark-dev] Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

Hi list, Rather than simplistic endpoint ID’s I think we need an ID tuple per endpoint, which may be combined with one (or more) other tuples representing single (and multipoint) connections. Examples are an aggregating tap/monitor port which monitors various VLANs, or an MPLS link. Or even

Re: [Wireshark-dev] pcapng_write_session_header_block

> On 18 Dec 2018, at 23:48, Guy Harris wrote: > > On Dec 18, 2018, at 2:43 PM, Jaap Keuter wrote: > >> writecap/pcapio.h has a function pcapng_write_session_header_block() >> declaration, with matching definition in writecap/pcapio.c >> This name refers

[Wireshark-dev] pcapng_write_session_header_block

Hi list, writecap/pcapio.h has a function pcapng_write_session_header_block() declaration, with matching definition in writecap/pcapio.c This name refers to a block that doesn’t exist in the pcap Next Generation Capture File Format(1) The format does however contain a block called section

Re: [Wireshark-dev] OPC UA plugin in Wireshark

> On 13 Dec 2018, at 13:39, Anders Broman wrote: > > > > Den tors 13 dec. 2018 kl 12:08 skrev Hannes Mezger >: > Hi Anders, > > from time to time I'm developing on and extending the OPC UA plugin of > Wireshark (plugins\epan\opcua). > > First of all, thank

Re: [Wireshark-dev] TRANSUM Enhancements

Hi Paul, It works like this: you add new features to master. Eventually master will become the new stable release. period. Whatever number that will have is rather cosmetic and of no real significance. So far we’ve created a series of gradual improvements in the 2.x series, and now that a few

[Wireshark-dev] BPF filter bytes

Hi list, Do we know of a tool that fills in the pcapng interface description block with a BPF bytes (and hence the BPF length field) instead of a filter string? Thanks, Jaap ___ Sent via:Wireshark-dev mailing list

Re: [Wireshark-dev] Corrupted TCP sequence number calculations?

with trailing whitespace. A very quick > workaround of that (just supplying an end pointer) avoids the reported error, > but doesn’t avoid the TCP sequence number corruption. > > Still investigating; any further suggestions? > > > > d > >> On 30 Nov 2018, at

Re: [Wireshark-dev] New dissectors for BACnet-APDU (packet-bacapp.c)

> On 29 Nov 2018, at 19:27, Jonathan Fleming wrote: > > Hello, > > my name is Jonathan and I am currently working for Optigo Networks in > Vancouver, BC. I recently added several new dissectors to the BACnet-APDU > protocol for my company, all contained within the packet-bacapp.c file. The

[Wireshark-dev] PCAP header clarification request

Hello Guy, I’ve added you to bug 15292, in order to get your view on the matter. The issue at hand is the relation between the PCAP global header, snap length field and the Packet header, included length field. I refer to the specification here:

Re: [Wireshark-dev] Corrupted TCP sequence number calculations?

Your frame 9 dissection errors out (as malformed), which probably trips up the TCP dissector as well, not allowing it to do all it’s work after the payload dissector is done. Thanks, Jaap > On 29 Nov 2018, at 13:34, David Arnold wrote: > > Hi all, > > I’ve discovered an odd issue with my

Re: [Wireshark-dev] This list of packages for RPM-based systems seems long out of date ...

Not since May. commit 338604ad9ec9d0fa6d49626e82f58c84d519fb93 Author: Dario Lombardo Date: Sat May 26 06:19:39 2018 +0200 tools: rename rpm_setup.sh to reflect other similar scripts. Change-Id: Ie686d7c5b808d9b89ff47cd65830ae441de8f8a2 Reviewed-on:

Re: [Wireshark-dev] No Interfaces found issue

HI, Little more context, especially Operating System of the platform you’re building / testing on? Thanks, Jaap > On 6 Oct 2018, at 20:49, Igor Chetverovod wrote: > > Hello list, > > I had compiled wireshark-2.6.3 (I am trying to develop a plugin) and after > start I see Wireshark window

Re: [Wireshark-dev] packet-mgcp.c: also for PacketCable Network-Based Call Signaling (NCS)?

Hi, > On 1 Oct 2018, at 11:02, Bruno Verstuyft wrote: > > Does this mean that parameters that are only defined in > PKT-SP-NCS1.5-I04-120412, and not in RFC 3435 can also be added to this > dissector? > There would be no limitation of the source of protocol information which forms the

Re: [Wireshark-dev] Unused dissector headers

Hi, Do these header files contain a note to the effect that they have other uses as well? Maybe they should, so it is explicitly clear these should not be folded into their C file. Just my €0.02 Thanks, Jaap > On 22 Sep 2018, at 11:49, Roland Knall wrote: > > Hi Gerald > > Specifically the

Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)

> to wireshark-dev@wireshark.org - it would have saved a moderator the effort > of reviewing my email! ; and > b) I should NOT have ticked the email digest option when I did sign up (it > made responding to the suggestions I received just a tiny bit harder than it > shou

Re: [Wireshark-dev] Unable to Decode SSL Message

This is a experimental RFC (https://tools.ietf.org/html/rfc6962 ) to include a TBSCertificate (https://tools.ietf.org/html/rfc5280 ). Someone would have to add the ASN.1 definitions to the relevant dissector. An

Re: [Wireshark-dev] Include Wireshark logos in CC BY/BY-SA 4.0 licensed work?

Tricky, probably Gerald who has to chime in here. > On 14 Sep 2018, at 07:58, panic wrote: > > Any ideas? > > Cheers, > -- panic ___ Sent via:Wireshark-dev mailing list Archives:

Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)

Hi Geoff, Congratulations on your successful build. Now, looking back, what from your experience would be beneficial to add or change in the User’s Guide/Developer’s Guide for the general public, if anything? > On 13 Sep 2018, at 06:21, Geoff Lee wrote: > > Posting this to report success

[Wireshark-dev] Wireshark Debian build with bcg729

Hi Balint, What would it take to get ITP bug 785480 done? Any suggestions who to poke? I’ve done my own packaging, straight from the GitHub repo, and it works fine. It would be nice to have the G.729 decoding capability in the official Debian build also. Thanks, Jaap

Re: [Wireshark-dev] Add an external tool

Hi, Done. On 26-08-18 12:03, Salim Gasmi wrote: > Hello ! > > I just wanted to ask if you could add a new tool in the > https://wiki.wireshark.org/Tools page. > > Details: > Section: Monitoring/tracing tools > Tool name: HPD > Tool link: https://hpd.gasmi.net > The description could be: 

Re: [Wireshark-dev] Gerrit - code review window

> On 12 Aug 2018, at 23:42, Peter Wu wrote: > ... > This is the case with the "Old UI". If you are looking at the "New UI" > (which says "PolyGerrit" in the top left corner"), then I can confirm > that the diff view provides no way to change it. In that case, try to > switch back to the old UI

[Wireshark-dev] Gerrit - code review window

Hi, A change I noticed is the way side-by-side code is presented in the code review window. This used to be two evenly spaced columns on the screen with horizontal scroll bars when the lines were longer than the available width. Both scrollbars were synchronised to help sideways navigation.

Re: [Wireshark-dev] Gerrit problems ?

> On 8 Aug 2018, at 12:39, Peter Wu wrote: > > Hi Dylan. > > On Wed, Aug 08, 2018 at 10:01:38AM +0200, Peter Wu wrote: >> On Tue, Aug 07, 2018 at 09:30:38PM -0400, Dylan Ulis wrote: >>> Anybody else having Gerrit issues after the upgrade? Under Profile, my >>> username is blank. When I try to

Re: [Wireshark-dev] ZigBee APS re-assemble with re-used sequence number

Hi, Not burdened by any ZigBee domain knowledge I would say that a seq# rollover would require a clearing of the non-reassembled fragments. But not all of them because we could still be in the process of reassembling the part of the stream with the not-yet rolled over seq#. A sliding window of

Re: [Wireshark-dev] extcap command line parameter format

> On 27 Jul 2018, at 22:50, Guy Harris wrote: > > On Jul 27, 2018, at 10:40 AM, Guy Harris wrote: > >> Oh, and another thing not to do: >> >> Don't repurpose a command-line flag intended for one purpose for >> another unrelated purpose. >> >> For example, don't repurpose a

Re: [Wireshark-dev] extcap command line parameter format

Hi, Any insights from the extcap developers, Guy? Thanks, Jaap > On 20 Jul 2018, at 19:12, Jaap Keuter wrote: > > Hi, > > While having reviewed extcap documentation [Ref1] I was triggered by bug > 14982 [Ref2] (usbpcap no longer recognized in 2.9) concerning the addit

[Wireshark-dev] extcap command line parameter format

Hi, While having reviewed extcap documentation [Ref1] I was triggered by bug 14982 [Ref2] (usbpcap no longer recognized in 2.9) concerning the addition of --extcap-version parameter to the extcap command line. This stated that the command line parameter "--extcap-version=2.9” causes a problem

Re: [Wireshark-dev] Wireshark User's Guide comment/suggestion

Hi, So you’ve noticed that the community consists more of programmers than documentalists. Getting the software right is difficult enough, let alone the various guides. That being said, the format of the user and developer guide has been converted from DocBook into AsciiDoc, but somehow the

Re: [Wireshark-dev] Help on packet correlation

Hi, There’s a specific README.request_response_tracking on this subject in the doc directory of the repository. Thanks, Jaap > On 28 May 2018, at 17:36, Craig Jackson wrote: > > I'm working improving support for TDS. One part of the Sybase version of TDS > involves correlation between

[Wireshark-dev] MATE in Users Guide

Hi list, Even though MATE has been part of the codebase ‘for a while now’, it is only documented in the Wiki. Pavel has contributed nice graphics to the story, as well as content. But things are still ‘stuck’ on the Wiki for now. My intent is to add the contents, verbatim, to the User Guide.

[Wireshark-dev] Asciidoctor PDF generation

Hi list, Working on a Debian testing system, the packagers have come so far as to package the recent update to Asciidoctor. This allows to generate the Wireshark documentation (WSUG/WSDG) with the proper layout. One stage is PDF generation, which requires an additional backend, being

Re: [Wireshark-dev] Request for Wireshark Wiki: Two additions to CaptureSetup/USB

Done, go ahead. > On 17 May 2018, at 10:15, Hanno Zulla <a...@hanno.de> wrote: > > Am 17.05.2018 um 10:04 schrieb Jaap Keuter: >> What us your wiki username? > > HannoZulla > >> We can add you as editor, then you can add it y

Re: [Wireshark-dev] Request for Wireshark Wiki: Two additions to CaptureSetup/USB

What us your wiki username? We can add you as editor, then you can add it yourself. > On 17 May 2018, at 09:44, Hanno Zulla wrote: > > Hi there, > > as a new registered Wiki user, I cannot add text to the CaptureSetup/USB > wiki page. The page is protected against editing by

Re: [Wireshark-dev] modify wireshark interface

Hi, “Show data as ISO8583”. Thereby you suggest that the data encoding has a specific codepage, currently not supported. From reading up on ISO8583 this is not the case. It defines message layouts (as dissected in the packet details pane) and uses ASCII / EBCDIC for applicable fields. The rest

Re: [Wireshark-dev] Ways to make Wireshark tarball

> On 8 May 2018, at 17:06, Graham Bloice <graham.blo...@trihedral.com> wrote: > > > > On Tue, 8 May 2018 at 15:46, Jaap Keuter <jaap.keu...@xs4all.nl > <mailto:jaap.keu...@xs4all.nl>> wrote: > > >> On 8 May 2018, at 14:20, Graham Bloice <

Re: [Wireshark-dev] Ways to make Wireshark tarball

> On 8 May 2018, at 14:20, Graham Bloice <graham.blo...@trihedral.com> wrote: > > > > On Tue, 8 May 2018 at 13:11, Jaap Keuter <jaap.keu...@xs4all.nl > <mailto:jaap.keu...@xs4all.nl>> wrote: > Hi list, > > In autotools times (i.e., 2.6.x) I

[Wireshark-dev] Ways to make Wireshark tarball

Hi list, In autotools times (i.e., 2.6.x) I was used to run: $ make dist to get a Wireshark source code tarball. It looks like CMake wants to offer something similar $ cmake ../ -DWS_SOURCE_DIR=“/tmp/wireshark” $ make dist But this fails over unreachable target ‘package_source’. So, is this

Re: [Wireshark-dev] New syntax for range support in membership operator: tcp.port in {1662-1664}

Hi, In fact I would suggest to consider double dot (‘..’) in this case. Reasons: * It is a sufficiently unique operator * The minus causes too many conflicts, as you have stated * triple dot (‘...’, i.e. Ellipsis) is too prone to ‘autocorrection’ to the ellipsis symbol, causing copy-paste

Re: [Wireshark-dev] Question about building WSDG

> On 10 Apr 2018, at 02:30, Craig Jackson wrote: > > I'm still learning Cmake, msbuild, and vcxproj files, but this seems like a > bug. Would entering a bug be appropriate? Entering a bug is always(*) appropriate. (*) only when it’s not, but that is when it concerns

Re: [Wireshark-dev] Adding sample capture

> On 17 Mar 2018, at 00:28, e-mail graham.shanks via Wireshark-dev > wrote: > > How do I get permission to enable me to upload a capture file to the Sample > Captures page? In particular I want to add the capture file associated with > Bug: 14441

<    1   2   3   4   5   6   7   8   9   10   >