Re: [Wireshark-dev] adding a Group filter option to the expert info dialog

Hi I would take the combobox for "Show" and put a second one for the levels beside it. You than can copy the code that gets triggered by that box "ExpertInfoDialog::limitCheckBoxToggled" and add your code to it. Don't worry about the design (the whole dialog is not really up to date) and just add

Re: [Wireshark-dev] Bug report: Wireshark windows ignores the space character in the "ssh remote capture" feature for "ssh server password" login credentials

Hi Could you file an issue at https://gitlab.com/wireshark/wireshark/-/issues/new ? kind regards Roland Am Mi., 17. Apr. 2024 um 17:17 Uhr schrieb Nicolo Campari < nicolo.camp...@intecs.it>: > Hi, > > Wireshark windows ignores the space character in the "ssh remote capture" > feature for "ssh

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:43 schrieb João Valverde : > >  > >> On 20/12/23 21:21, Roland Knall wrote: >> >>>> Am 20.12.2023 um 22:02 schrieb João Valverde : >>> >>>  >>> >>>> On 20/12/23 20:52, Roland Knall wrote:

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

> Am 20.12.2023 um 22:02 schrieb João Valverde : > >  > >> On 20/12/23 20:52, Roland Knall wrote: >> >> >> Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : >> >> >> >>On 20/12/23 16:06, Roland Knall wrote: >>

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde : > > > On 20/12/23 16:06, Roland Knall wrote: > > Ok, I am not ignoring those points, as I think those points are valid. > > It makes sense, that building debian packages from the repository > > should behave

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

It might be the best for their users, but we also facilitated that approach by our approach to the whole issue. Am Mi., 20. Dez. 2023 um 19:57 Uhr schrieb Bálint Réczey < bal...@balintreczey.hu>: > Roland Knall ezt írta (időpont: 2023. dec. 20., Sze, > 17:06): > > > > Ok, I am

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Ok, I am not ignoring those points, as I think those points are valid. It makes sense, that building debian packages from the repository should behave in the same way as it does with the overall projects. Now, one could argue, that having multiple packages could have been avoided in the beginning

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Balint It would be worth amending the Readme with this information, as well as the packaging section of the wiki, to ensure this information is not getting lost and future discussions may be avoided by pointing to it. kind regards Roland Am Mi., 20. Dez. 2023 um 14:24 Uhr schrieb Bálint

Re: [Wireshark-dev] Changes to the plugin registration API

matches the FSF FAQ, is wrong, >>>> please do >> >> share. I'm very open to a good-faith discussion. >>>> >>>> >>>> > Best regards >>>> > Anders >>>&

Re: [Wireshark-dev] Changes to the plugin registration API

I do not think there is a need for calling someone confused. The whole discussion is not in any way useful for our users. There is the explicit corporate usecase, where in-house versions do exist with their own protocols and plugins. Often times those versions do not even deal with licenses for

Re: [Wireshark-dev] Changes to the plugin registration API

I do not think we need to revert the whole change. I actually like the way the new version check is implemented and think it is beneficial to a lot of users, because it will reduce the number of changes they have to make in order to update their version. But I do think the enforcement of licenses

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi I would recommend that we bring this topic before the technical steering committee. As of right now, that committee needs to be formed in January and this topic is exactly why we are going to have the committee in the first place. The process is in the final steps and should be finished by the

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

As mentioned on the ticket - just putting it here as well - I am against dropping packaging/debian. But I am for having it underneath packaging, and not in the main directory, which is what the original change was about. I respect Joao's opinion as well as yours Balint. In this case here I think,

Re: [Wireshark-dev] Description of Wireshark User's Guide 4.3.0

Hi Yes, the developer and user guides live a somewhat trist live beside the main source code repository. But you can easily change the content, by submitting a merge request. Both are generated by the sources underneath /docbook inside the repository. wsug is the directory for the user guide and

Re: [Wireshark-dev] Building Wireshark From Source MacOS

That version of Wireshark is not supported with Mac OSX 13.x or higher. Please use a later version. But, for that specific protocol, you could also try the following dissector, written in Lua: https://github.com/netspooky/dissectors/blob/main/acble.lua cheers Roland Am Do., 4. Mai 2023 um 16:52

Re: [Wireshark-dev] Wireshark 4.0.1 clone and build fails with test failures and complaints about paths prefixed in the source directory

It is preferred, that WIRESHARK_BASE_DIR is defined at the top directory, and not underneath the source directory. Also, it cannot be omitted as documented in our build documentation. Additionally, it is recommended to do an out-of-source build, to better be able to update the sources if needed.

Re: [Wireshark-dev] macOS Xcode build failure on multiple commands producing same directory

Always Am Fr., 3. März 2023 um 13:27 Uhr schrieb Alexander Kapshuk < alexander.kaps...@gmail.com>: > On Wed, Mar 1, 2023 at 9:21 PM Guy Harris wrote: > > > > On Mar 1, 2023, at 7:18 AM, Alexander Kapshuk < > alexander.kaps...@gmail.com> wrote: > > > > > Pointers on how to proceed with this

Re: [Wireshark-dev] What is the best way to locate [GLib CRITICAL] -- g_string_free: assertion 'string != NULL' failed

Also, more on the point, we have our own memory management system called wmem in which you allocate stuff within a scope and Wireshark handles freeing up the memory. Look for a README.wmem underneath /doc as well as the Wireshark developer guide for usage and the examples Cheers Roland > Am

Re: [Wireshark-dev] Error building from source: /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgpg-error.a(libgpg_error_la-init.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be

Not sure if you can build dumpcap statically. Can you build the whole suite on the same machine, without building it statically? Just to ensure, that all the right libraries are installed at least. regards Roland Am Do., 10. Nov. 2022 um 17:38 Uhr schrieb jorge.pinto.sousa via Wireshark-dev : >

Re: [Wireshark-dev] can't compile wireshark version 4.0

Please attach your cmake outputAm 20.10.2022 um 17:30 schrieb chuck c :Can you add a link to the source bundle you downloaded.On Thu, Oct 20, 2022 at 10:22 AM w...@comcast.net wrote: I can't compile wireshark version 4.0 on Raspberry Pi ubuntu 22.04

Re: [Wireshark-dev] Compile fails with Qt 6.4.0 on windows

Hi For now, 6.4.0 is not supported. 6.3.x are the latest compatible versions. Work is being done on achieving compatibility. regards Roland Am Di., 11. Okt. 2022 um 21:23 Uhr schrieb Anders Broman < a.broma...@gmail.com>: > Hi, > Setting up on a new PC I just grabbed the latest Qt version and

Re: [Wireshark-dev] CARES to old for CentOS8?

officially supports RHEL 8 derived > distributions seems hasty to me. > > John > > On Fri, Sep 30, 2022, 7:43 AM Roland Knall wrote: > >> Hi. >> >> Ok, maybe I have to clarify my thought process here a little bit. The >> original version we required as

Re: [Wireshark-dev] CARES to old for CentOS8?

already shipping (i.e., they'd create a >>>>> version like 1.13.0. rather than upgrading to 1.14.x). They >>>>> work >>>>> hard to avoid changing version numbers for compatibility reasons. >>>>> >>>>> On Thu, Sep 29, 2022 at 6

Re: [Wireshark-dev] CARES to old for CentOS8?

Hi, >> Well a choice to make if we want to support CentOS8/RHEL8 or not. One >> could argue that CVE:s in support libraries might not be for us to >> decide on but rather the OS maintainers. >> Best regards >> Anders >> >> Den tors 29 sep. 2022 kl 08:19

Re: [Wireshark-dev] CARES to old for CentOS8?

The reason for 1.14 was a CVE that was fixed. I would vote strongly against reducing the Version just to support an older version. Regards, RolandAm 28.09.2022 um 18:48 schrieb John Thacker :On Wed, Sep 28, 2022, 10:47 AM Anders Broman wrote:Hi,Is there a workaround

Re: [Wireshark-dev] Future of extcap "API"

Adding another helper may be helpful, as it would probably gives us greater control, and maybe also solve the "helper-script" issue in the future by putting that stuff inside Wireshark? I am just wondering if it is worth the effort. We can obviously strive for a perfect - no user interaction

[Wireshark-dev] Qt6 default for -dev tree

Hi all With the release of the release candidate for 4.0 something else changed in the source-tree and I just wanted to make you aware of that. Over the past few weeks, whenever you built from the source-tree, you had the option to run cmake with the parameter -DUSE_qt6=ON to enable a build

Re: [Wireshark-dev] Future of extcap "API"

One of the benefits of the extcap-cli is, that we can and currently do, send an API version to the extcap utility which would allow breaking changes while still enabling a compatibility mode for older versions. Because of that, I think 2 would be an ideal scenario, just define the response to

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

Policy always was and has been, that we try to achieve consistent guidelines for new files and in general the guidelines for each file should be reflecting that files style. Although I do appreciate applying consistent styles, I acknowledge the fact that we have a really old code base in some

Re: [Wireshark-dev] MSVC gives warnings "qt_ui_utils.cpp(208, 25): warning C4996: 'QProcess::startDetached'"

en if it's an empty > QStringList. > >> On Fri, 11 Feb 2022 at 10:15, Anders Broman via Wireshark-dev >> wrote: >> Hi, >> >> Latest released one >> >> C:\Qt\5.15.2 >> >> Regards >> >> Anders >> >>

Re: [Wireshark-dev] MSVC gives warnings "qt_ui_utils.cpp(208, 25): warning C4996: 'QProcess::startDetached'"

Which Qt version are you on? Am Fr., 11. Feb. 2022 um 11:06 Uhr schrieb Anders Broman via Wireshark-dev < wireshark-dev@wireshark.org>: > Hi, > > Just built and got the following warning: > > > > ..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning C4996: > 'QProcess::startDetached': Use

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

Guy already has updated the documentation yesterday and today a bit on the commandline. But the online manuals could be updated Am Di., 1. Feb. 2022 um 13:15 Uhr schrieb Jaap Keuter : > Hi, > > Cool that this works as intended / expected. > All that is left now, as Guy indicated, is to document

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

olarProxy to > STDOUT and piped that into Wireshark with "-i -". This integration works, > but it's not how I prefer to read packets with Wireshark and it's not a > viable option if PolarProxy and Wireshark are running on different machines. > > /erik > > > Den mån 31 j

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

If udpdump is nothing for you, and you are able to run a capture tool like tshark or tcpdump on the remote machine, you can take a look at sshdump. A sibling of udpdump, it executes the remote capture program via ssh, and then transports the data as-is through a ssh-connection. It can be seen as a

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

er, but >> that was removed in 6e5ba74b. I think it would be worthwhile to try adding >> it back in a more simplified form for release branches, but I'm not sure >> when I would have time to work on that. >> >>> On 1/20/22 7:29 AM, Roland Knall wrote: >>

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

May I suggest that we focus on the discussion at hand here. The discussion about the package itself seems to be better suited for the issue list specific for that package, as is the purpose for that list. The issue here is, that with change

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

. And forcing them by breaking mid-release is not a good idea in my point of view. Now breaking between major releases - I am all for that (within reason). Am Do., 20. Jan. 2022 um 22:25 Uhr schrieb Guy Harris : > On Jan 20, 2022, at 1:12 PM, Roland Knall wrote: > > > But it was

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

Just to add to utilities that utilize such a library is https://github.com/epl-viz/EPL-Viz I agree that such an utility could be added to Wireshark itself, and it is not actively developed anymore (at least to my knowledge). But it was implemented by utilizing heavily a wireshark installation

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

For clarification: " but the change should most certainly happen with a version beyond 3.6" means, that the break should be reverted for 3.6.x, but it should be put in place for -dev to be in the next major release cheers Am Do., 20. Jan. 2022 um 16:28 Uhr schrieb Roland Knall :

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

I think it is reasonable to assume that libraries provided with the project are being used by external programs. I know one utility which is being used in a rather closed-off community (but nonetheless widely adopted by around 200-300 people), which got broken by this. Their solution is to stay on

Re: [Wireshark-dev] Visual Studio 2022

Its the later. Am Sa., 15. Jan. 2022 um 13:38 Uhr schrieb Guy Harris : > On Jan 15, 2022, at 3:09 AM, Gisle Vanem wrote: > > > Anders Broman wrote: > > > >> Hi, > >> Yes sounds like a good idea. Have been contemplating testing it too. > > > > I just installed the "Build Tools for Visual Studio

Re: [Wireshark-dev] Visual Studio 2022

One of the main features I would be looking at was better arm64 support. Right now compiling a native Wireshark version for Windows arm64 is a nightmare The compilers can do it, the tool chain can’t really > Am 15.01.2022 um 12:09 schrieb Gisle Vanem : > > Anders Broman wrote: > >> Hi, >>

Re: [Wireshark-dev] Insecure.Com LLC -> Nmap Software LLC

Personally, I would keep it as it is, unless they explicitly ask for it Am So., 19. Dez. 2021 um 19:39 Uhr schrieb chuck c : > Is it ok to update the name where it appears in the docs and AUTHORS or is > the agreement with the old entity? > > >

Re: [Wireshark-dev] How to troubleshoot extcap applications?

Could we additionally add a note to README.extcap? Just in case, some external extcap tools sumble across this as well? Also, one more thing, have you tested with tshark only or also using qt? Qt in general redirects all std... pipes, which should not matter as we are started through dumpcap.

Re: [Wireshark-dev] Extcap Rust library

That is great. Would you mind sending a pull request mentioning the library in README.extcap? Currently we only provide the python example, and this is by design. But we should at least mention other implementations in the documentation. regards Roland Am Di., 30. Nov. 2021 um 07:28 Uhr schrieb

Re: [Wireshark-dev] Parameters for extcap

Both issues where done so by design. For the password, there was a reasonable concern, that passwords may be read-out. Now, you could argue, that monitoring the cumpcap call gives you the password anyway, which is correct. The intended usecase originally was to use the password together with ssh,

Re: [Wireshark-dev] How to stop extcap gracefully

In the case of ciscodump, there is no closing on the extcap side. Basically it reads packets indefinitely in ssh_loop_read, until you either have a read error on the channel, or you got the end packet. You would need to add another exit condition to the do..while loop there. extcap programs work

Re: [Wireshark-dev] How to stop extcap gracefully

Due to the nature of extcaps, they are not explicitly closed. Instead, you should monitor the created pipes. Dumpcap closes those pipes when the capture has finished. We do send them a kill signal, but due to the nature of the signal handling, this signal may be missed. The sure fire way is, if

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

See https://gitlab.com/wireshark/wireshark/-/merge_requests/4178 for the functionality change Am Mo., 13. Sept. 2021 um 11:37 Uhr schrieb Roland Knall : > Looks to me that we actually have an inconsistency in behavior. If you > click on a byte, the underlying field gets selected in the by

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

Looks to me that we actually have an inconsistency in behavior. If you click on a byte, the underlying field gets selected in the byteview as well as packetdetail pane and stays selected, until you click someplace else. If you do the same the other way around, it does not work, as the selection is

Re: [Wireshark-dev] Triggering "Windows Build" job

Hi Ivan We have a limited number of machines for our build-jobs. Therefore only when we set the merge-request to a semi-done level, buildjobs are triggered. What you can do though, is run your own pipeline, and use our .gitlab-ci.yml file as a template. At this point we do not plan on making the

Re: [Wireshark-dev] remote interfaces issues

I‘ll take a look at it. From a first glance it could be better suited to change the model instead of the browser window Cheers > Am 02.09.2021 um 10:14 schrieb Ramin Moussavi : > >  > hello > > i made a merge request to fix the remote interface settings window > >

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

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

Re: [Wireshark-dev] Custom item not related to the packet

no mer 26 mag 2021 alle ore 14:32 Roland Knall > ha scritto: > >> The data displayed in the subitem is the one from pt, your data variable >> which you used to create the new tvb. The hf_item seems to point to a >> different data structure. How is pt being generated? Are yo

Re: [Wireshark-dev] Custom item not related to the packet

The data displayed in the subitem is the one from pt, your data variable which you used to create the new tvb. The hf_item seems to point to a different data structure. How is pt being generated? Are you using the same length and start offset as for the hf item? regards Roland Am Mi., 26. Mai

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

You can try to just capture a single depth (--depth 1) and see if this works regards Roland Am Mi., 19. Mai 2021 um 15:54 Uhr schrieb Martin Mathieson via Wireshark-dev : > I did take a capture. All I see is a FIN,ACK from the server, after which > it sent another couple of ACKs. > There are

Re: [Wireshark-dev] How to disable QT_MULTIMEDIA_LIB during cmake

A merge request has been generated for this: https://gitlab.com/wireshark/wireshark/-/merge_requests/2849 cheers Am Mi., 28. Apr. 2021 um 14:33 Uhr schrieb Roland Knall : > I have created a change which handles the CMAKE stuff correctly (analog to > extcap & pcap, ...) > > I

Re: [Wireshark-dev] How to disable QT_MULTIMEDIA_LIB during cmake

I have created a change which handles the CMAKE stuff correctly (analog to extcap & pcap, ...) I would need some help from you Jirka for the RTP specifics. kind regards Roland Am Mi., 28. Apr. 2021 um 14:01 Uhr schrieb John Thacker < johnthac...@gmail.com>: > In general some features can be

Re: [Wireshark-dev] Status label for issues

about the os::* labels. We can reduce them to > os::mac, os::windows, os::linux, os::unix. > > > Am 26.04.21 um 23:13 schrieb Roland Knall: > > The list seems to be duplicated with the lists from above. Anyhow, it > seems we just have too many labels already, and I > > am still

Re: [Wireshark-dev] Status label for issues

on the list cheers Roladn Am Mo., 26. Apr. 2021 um 21:17 Uhr schrieb Uli Heilmeier : > > > Am 26.04.21 um 11:49 schrieb Roland Knall: > > > > I suggest we create a wiki page for that discussion first, and if we can > figure that out create the labels. > > > &g

Re: [Wireshark-dev] Status label for issues

I somewhat feel a little bit more sceptical of increasing the numbers of labels. They would require discipline before being enforceable. Also, we would need some form of documentation to allow a lookup what each label is supposed to be and what eventual escalation procedures would be. I suggest

Re: [Wireshark-dev] Wireshark 3.4.5 is now available

Normally it is a cut-off date. Exceptions are only made for bigger bug-fixes and security fixes > Am 25.04.2021 um 09:37 schrieb Constantine Gavrilov : > > A quick question. I have been working on nvme dissector and I see that some > changes from dev tree are in and some are left out. > >

Re: [Wireshark-dev] File formats that extcap programs can write

While correct as an answer, the main Limitation here is dumpcap. You would have to implement a mechanism to let dumpcap know which format to use for the internal pipe to the extcap interrace. DLT could be that. Pcapng has been on the wishlist for a very long time as a format Kind regards

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

i need to > dissect a first level protocol and couldn't open the file to dissect. But i > think, as mentioned by John Thacker, to use the USER_DLT will take function. > > Best regards, > > Björn > > > > Am 27.01.21 um 12:30 schrieb Roland Knall: >> Hi B

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

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

Re: [Wireshark-dev] QT installation

There are two licenses available for Qt. A commercial one and an open-source one. If your company already has registered for commercial licenses, you will not be able to register for the open-source licence with your company email address. In that case you still have the option to register your

Re: [Wireshark-dev] Apple M1 transition for Wireshark build process

There are a few issues with M1 still: A. Not all supporting libraries can be compiled, especially brew supplied libraries vary deeply. B. Rosetta and native are nearly par performance wise. C. Universal binaries would require a real hassle, so I actually would prefer target-specific ones In

Re: [Wireshark-dev] About i18n Translation

We currently have no system in place that would allow you to translate any texts coming from dissectors or anywhere out of epan for that matter Kind regards > Am 19.11.2020 um 14:54 schrieb qiangxiong.huang : > > HI, I have two questions about wireshark i18n: > > 1. Are the files *.po in

Re: [Wireshark-dev] Apple VM for Gui testing

Hi It is against Apples EULA, to run Apple operating systems on non-apple hardware. An exemption had been made for running it on virtualized environments, if they themselve run on Apple hardware. So legally it is not allowed to do so. cheers Roland Am Do., 8. Okt. 2020 um 04:34 Uhr schrieb

Re: [Wireshark-dev] The QT-5.15 disaster and an issue with multi-monitor setups, Windows and Wireshark

Can’t skip, it is the base for Qt 6. Btw, cannot reproduce this on my system, Ubuntu 20 LTS. Have to investigate if this is KDE related though, running Cinnamon over here Cheers > Am 28.08.2020 um 21:03 schrieb Richard Sharpe : > > Hi folks, > > I just came across this article: > >

Re: [Wireshark-dev] GitLab migration update

Peter posted the instructions somewhere for that (either on the main wiki, or the main project). Have to look it up. Basically you have to remove the association of your fork with the "old" version, and then reset it. cheers Am Di., 25. Aug. 2020 um 23:01 Uhr schrieb Dario Lombardo : > > > On

Re: [Wireshark-dev] [Wireshark-users] GitLab migration update

> Am 24.08.2020 um 08:50 schrieb Guy Harris : > > On Aug 23, 2020, at 10:42 PM, Gerald Combs wrote: > >>> On 8/23/20 9:59 PM, Guy Harris wrote: On Aug 23, 2020, at 9:33 PM, Gerald Combs wrote: >>> You can still comment on Gerrit changes, but it should otherwise be

Re: [Wireshark-dev] [Wireshark-users] The Wireshark wiki has a new home

I agree that this is not ideal. I would opt for a second project. MoinMoin is really not good anymore from an op-sec point of view Cheers Roland > Am 12.08.2020 um 21:18 schrieb Gerald Combs : > > On 8/12/20 7:51 AM, Maynard, Chris via Wireshark-users wrote: >>> -Original Message- >>>

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

Putting the complexity in the common code will increase the complexity for a lot of other stuff which relies on this functionality. Also you run the risk of increasing dissection time for more protocols, then if you handle it specifically. That would be my reasoning against it cheers Am Do.,

Re: [Wireshark-dev] Plugin GUI menu and selected packet

It's tricky. Due to the plugin being in a different execution context from the main application, a direct connection cannot be made. It would have to be a callback, similar then the ones from the plugin to select a certain packet. Those have not yet been implemented. Even if they were, you would

Re: [Wireshark-dev] Tie code change to release version

What you can do on the command-line is the following: git log origin/master-2.4 | grep 'extcap: set help' this will give you an indication, if the patch was in 2.4 (for instance here). Coincidentally this is actually the version this patch was first released in. kind regards Roland Am Do.,

Re: [Wireshark-dev] macOS build broken

Feel free to give it a go > Am 24.04.2020 um 15:29 schrieb Lori Jakab : > >  > Hi, > > I'm have been building on macOS Mojave for a while without issues, but for > the last few days the build has been broken. I didn't try a git dissect yet > to see which commit broke it, but the issue seems

[Wireshark-dev] Display Filter Folders - a question to vote

Hi We have a new feature in Wireshark, where you can sort display filters into subfolders. See https://twitter.com/bubbasnmp/status/1252627399201742848 for an example use case. The current implementation requires the name of the folder to be part of the filter name, so in the case of the picture

Re: [Wireshark-dev] Regenerating moc files

moc Files are run, if their accompanying .cpp File changed. I am not aware of a cmake command to run it forcefully, but you can always run “touch” on the wronged file. Cheers > Am 27.03.2020 um 19:17 schrieb Dario Lombardo : > >  > Hi, > is there a cmake target to unconditionally

Re: [Wireshark-dev] Qt availability changes

> Am 30.01.2020 um 15:56 schrieb João Valverde > : > >  > >> On 28/01/20 13:30, Roland Knall wrote: >> A good overview by one of the KDE developers, focussing - obviously - on the >> Linux side: >> >> https://tsdgeos.blogspot.com/2020/01/the-qt

Re: [Wireshark-dev] Qt availability changes

A good overview by one of the KDE developers, focussing - obviously - on the Linux side: https://tsdgeos.blogspot.com/2020/01/the-qt-company-is-stopping-qt-lts.html Long story short - we may have to host our own version at some point. Am Di., 28. Jan. 2020 um 12:44 Uhr schrieb Roland Knall

Re: [Wireshark-dev] Qt availability changes

Am Di., 28. Jan. 2020 um 01:43 Uhr schrieb Peter Wu : > > > I think it is worth emphasizing that it only affects users who build or > develop Wireshark from source. The final Wireshark installer will still > bundle the Qt bits. > We need to get those bundles from somewhere, meaning we either

Re: [Wireshark-dev] Qt availability changes

Well it took me a while to read through all the comments. First of all, I understand their - Qt's - reasoning. It makes sense from a business side of things, and they are getting rather big. Developing that framework is not the easiest task and they need money (sounds too familiar). This sucks,

Re: [Wireshark-dev] Remote fieldbus capture "protocol"

I’ve implemented similar using either udp or serial, using extcap in both cases. You can take a look at udpdump but in my case I wrote it myself using a python extcap on the receiving end. The idea is, that you put all information (including the timing of your original protocol) into a frame,

Re: [Wireshark-dev] Support Opus in WireShark

I can provide some examples if needed, of exactly that. Either multiple OPUS streams, or traces which contain opus and G.711 in the same conversation. Just tell me, if you need a new bug-entry created or have an existing one to attach to. kind regards Roland Am Mo., 20. Jan. 2020 um 12:30 Uhr

Re: [Wireshark-dev] How to add ilbc library to wireshark CMake?

The way here would be to push your patch to gerrit. iLBC seems to be distributed (at least the codec as part of the WebRTC project) with a BSD-Style license, so integration should be doable. Please also check, beside tools/debian-setup.sh there are scripts in there for other Linux distributions as

Re: [Wireshark-dev] Extcap binaries on OSX

run/Wireshark.app/Contents/MacOS/extcap cheers Roland Am Fr., 20. Dez. 2019 um 10:31 Uhr schrieb Dario Lombardo : > Hi, > I'm trying to debug some CI jobs on OSX but I don't have a OSX machine. > I'm trying to find where the extcap binaries are put on OSX using cmake. > > Linux: run\extcap >

Re: [Wireshark-dev] Wireshark for Mac 10.14.5

You can also install the release candidate for 3.2, which has a dmg > Am 14.12.2019 um 01:44 schrieb Guy Harris : > > On Dec 13, 2019, at 9:10 AM, Pooja Vijay via Wireshark-dev > wrote: > >> I am trying to install Wireshark for Mac OS version 10.14.5 but I don’t see >> .dmg file anywhere.

Re: [Wireshark-dev] Missing dumpcap when building 3.1.1

Please take a look at https://wiki.wireshark.org/CaptureSetup/CapturePrivileges to resolve the issue Am Fr., 29. Nov. 2019 um 15:56 Uhr schrieb Tom Bentley < t.j.bent...@gmail.com>: > Great, that worked and I can now capture, but only when running wireshark > under sudo. I tried things like

Re: [Wireshark-dev] Visual studio 2019 from choco

@Dario - I am currently rewriting that section anyway, I'll drop you the patchset as soon as it is uploaded. Am Di., 26. Nov. 2019 um 15:29 Uhr schrieb Dario Lombardo : > I'm chatting with choco maintainers right now. They say it sounds like a > fresh win10 install will fail with dotnetfx

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

In this case, the change has to happen in docbook/release_notes.adoc. I will update them accordingly, so it appears amended for 3.2. Am Di., 19. Nov. 2019 um 18:40 Uhr schrieb Tomasz Moń : > On Tue, Nov 19, 2019 at 4:53 PM chuck c wrote: > > And in the still learning to crawl before walk/run,

Re: [Wireshark-dev] Problems building under Windows 10

Oh, autospell is such a nice feature ;-) I just tested it on a VM, it works as it should Am Mi., 13. Nov. 2019 um 08:43 Uhr schrieb Graham Bloice < graham.blo...@trihedral.com>: > > > On Wed, 13 Nov 2019 at 07:01, Roland Knall wrote: > >> Do you execute canoe from a Vis

Re: [Wireshark-dev] Problems building under Windows 10

Do you execute canoe from a Visual Studio Commandprompt? I recently tried it and it works fine. Cheers > Am 13.11.2019 um 02:52 schrieb Richard Sharpe : > > Hi folks, > > I think I have followed the instructions at > https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html > > I

Re: [Wireshark-dev] Wireshark 3.1.0 No filter available, try another column

Running latest master or dev-build, this error can no longer be reproduced, as that part of the code has been extensively rewritten. Therefore, please either wait for the next 3.1.x RC or upgrade to a nightly build. kind regards Roland Am Do., 7. Nov. 2019 um 08:17 Uhr schrieb Richard Sharpe <

Re: [Wireshark-dev] Warnings from Qt

There is already work being done to address this Am Mo., 4. Nov. 2019 um 15:32 Uhr schrieb Pascal Quantin < pas...@wireshark.org>: > > > Le lun. 4 nov. 2019 à 16:27, Joakim Karlsson a écrit : > >> And I getting some other warnings: >> >> 16:21:36.990 Main Warn CaptureEvent [ 2 ]: 1 >>

Re: [Wireshark-dev] Migrate to GitLab?

Addendum - my initial tl;dr is misleading - I don't like FF because it is extra work, but I definitely prefer it if cherry-picking (as it is applied now) is not an option with gitlab (never looked that up properly). merge is a -2 in any case Am Sa., 12. Okt. 2019 um 12:48 Uhr schrieb Roland Knall

Re: [Wireshark-dev] Migrate to GitLab?

tl;dr - I am also -2 on merge commits, not entirely sure about ff either, they tend to be work, cherry-pick would be preferable. Long version: Currently we do have a strategy in place, that is called "Cherry-Pick". Basically it means, that Gerrit resolves any branch conflicts (the patch had been

Re: [Wireshark-dev] Migrate to GitLab?

Am Di., 8. Okt. 2019 um 10:47 Uhr schrieb Guy Harris : > > And can I then do a "git commit --amend" and another "git push origin > HEAD:feature-number-1" to fix issues found in the review/Petri dish/going > back and looking at what I did process? > > And I'm still on the master branch there, so a

Re: [Wireshark-dev] Migrate to GitLab?

TL;DR - yes - no - somewhat Long version: 1. If you push to GitLab and do it the right way, you create a merge request, which allows you to ammend the change as many times as you want, similar to the method with patchsets in Gerrit. 2. This will not cause merge commits if done properly. 3. Here

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

Hi Jaap I was in contact with the original developer of QCustomPlot. According to his statement, this warning is a false-positive, as it cannot occur with real numbers. FYI, he will create a version 2.0.2 or 2.2.x depending on the changes, sometime by the end of this year, beginning of next. We

  1   2   3   4   5   >