Re: [Wireshark-dev] Is wireshark.org possibly hacked?

[Roland Knall]

We will be looking into it

kind regards
Roland

Am Di., 25. Juni 2024 um 18:24 Uhr schrieb Triton Circonflexe <
triton+enu...@kumal.info>:

> It seems to be an issue with the placement of the clear/dark theme
> javascript.
>
> I checked the about.html page with a simple "view source" and Firefox
> is also complaining about the fact that the  tag is not the root
> of the document.
>
> In fact, we see
>
> 
>
> 
> const currentTheme = localStorage.getItem("theme");
> document.documentElement.className = currentTheme;
> 
>
> …
>
> in all pages while the script tag should probably be inside the 
> tag (but my last go at HTML was with HTML 4.01 so I’ll let someone
> more competent take over from there.
>
> Le mar. 25 juin 2024 à 16:05, Kate  a écrit :
> >
> > or possibly a code review(of the website)?
> >
> >
> > checked sucuri sitecheck :
> >
> >
> > https://sitecheck.sucuri.net/results/https/www.wireshark.org
> >
> > warning.html_anomaly
> >
> > Description:
> > We detected anomaly in HTML code placement. Typical anomalies are
> placement of scripts and iframes outside of the .. block,
> which means that it was don't by someone who is not familiar with the web
> page generation process of this particular site (massive automated
> infection) or simply doesn't have access to the code that generates
> webpages (for example, server-level infections that append malware to every
> server response). This is a strong signal that a stranger tried to modify
> web pages.
> >
> >
> >
> > Site Issue Detected
> >
> > http://www.wireshark.org/ (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/ (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/about.html (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/docs/ (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/download.html (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/faq.html (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/learn (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> > Site Issue Detected
> >
> > https://www.wireshark.org/lists/ (More Details)
> >
> >
> > Anomaly behavior detected (possible malware): warning.html_anomaly?1
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 your code to it. If you do want to worry about the design, I would put
both in a GroupBox and maybe rearrange them underneath? That acn be easily
done by opening the .ui file for the dialog "expert_info_dialog.ui" in
QtDesigner and do it there. You will have to edit the file anyhow as you
need to add your combobox to it. If you do, put a label in front of it, so
that it becomes clear what each box does.

If you want, you can tag me on the merge request and I will take a look at
it

cheers
Roland


Am Fr., 10. Mai 2024 um 00:08 Uhr schrieb John Dill <
john.d...@greenfieldeng.com>:

> I have been implementing some extra categories in the severity and group
> level to help categorize events that happen in packet captures in my local
> wireshark source tree.
>
>
> For example, I've added PI_UNEXPECTED, PI_DEGRADED, PI_FAIL, and PI_FATAL,
> and added PI_INTEGRITY and PI_OPERATION to the groups specific for my
> protocol domain.
>
>
> I've been able to update the existing code for filtering the added
> severity levels, but I also want to add capability to filter on group from
> the Analyze -> Expert Info dialog box.  How difficult would that be?
>
>
> Not expecting a detailed analysis, just want to know at a high level what
> I'd be getting into.  I'm not experienced in Qt development.
>
>
> Thanks,
>
> John D.
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 server password" login credentials and does not save it
> when saving credentials. Even mixing normal ascii char and spaces does not
> work. I am using wireshark Version 4.2.4 (v4.2.4-0-g1fe5bce8d665) on
> windows 11.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

> 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:
>>>> 
>>>> 
>>>> So people can link to our libraries to write other projets? And expect it 
>>>> to work reliably? That is news to me. I have made this question many times 
>>>> over the years but I guess I was not worthy of a clear answer until now.
>>>> 
>> I am not saying they should do it or that I appreciate it happening. All I 
>> am saying is that it happens and is happening and we did not put a stop to 
>> it in time. Should they expect it to be reliable? Of course not as I 
>> answered also in other threads on this matter. But at the same time I see no 
>> point in having them hit a wall face on, rather work in such cases where we 
>> know about it, to ensure them moving to a saner approach.
> 
> What?! I'm back to confused... So you don't like the situation, you say. 
> Here's a thought.. maybe if Debian didn't publish system libraries in our 
> name with these stupid symbol lists then people wouldn't get the crazy idea 
> they could use these libraries that were published for this exact purpose and 
> build their own software on top of it and expect it to work reliable and not 
> break every other release, like most other non-Wireshark Debian libraries.
> 
> I wonder what could be done about that. I guess Debian would get that clue 
> pretty darn quick if we weren't mirroring their broken setup in our 
> repository, thereby sanctioning it.
> 
> I don't know, call me crazy. Or did I misunderstand again? Sure seems 
> complicated to get my head around this for such a simple topic as is software 
> release and distribution.

Just a thought, libvirt was not created by debian but RedHat so the state of 
debian packaging has nothing to do with them. Debians package is merely moving 
their approach onto Debian, but the decision to implement libvirts plugin in 
such a way had been done by RedHats folks. And most other packages I know that 
use this approach as well are Windows based. Again nothing to do with Debian. 
So could we separate these issues please? 

> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

> 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:
>>> 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 or it should be changed, that would be a
>>> valid discussion being had, but I do not think it invalidates those
>>> points and arguments. Yes, debian is different but it is also
>>the base
>>> (through ubuntu) for the majority of linux distributions as
>>> wells Microsofts own variety in wsl2 (at least if you go with the
>>> default one), and therefore it should be considered as such.
>> 
>>I don't know what you are trying to get at. I'm not trying to say
>>what
>>Debian should or shouldn't do.  They are free to decide for
>>themselves.
>>I would never presume to tell them what they should do, although I
>>have
>>strong opinions on that. There are lots of problems with their
>>package
>>but that is something to be discussed in the Debian bug tracker, not
>>here. This project isn't part of Debian. This fact seems to be
>>lost on
>>some people.
>> 
>> 
>> The idea Balint had is, that no matter if you are using the official package 
>> or build it yourself with our repository, you will not be locked out of 
>> updating the package or distribution, and most certainly it will not lead to 
>> any issues with package management. This might be a speciality of Debian, 
>> but I think it is something we can support as it does not really hinder us, 
>> except for the issue with the lib manifest, which now seems to be resolved. 
>> And I do think that supporting this choice by our users is something that is 
>> worth supporting.
>> 
>> 
>>>
>>> The libvirt plugin is a valid example of where we messed up. And
>>with
>>> we I mean the whole project. We provided this path and we kept it
>>> maintained for far too long, but it is here now and a solution
>>needs
>>> to be found. We started on that road with stating that we allow
>>> invalidating the api in major version releases and also minor
>>version
>>> releases to some extend. The argument, that libvirt is still doing
>>> something they should not be doing is valid. But the solution
>>here is
>>> not hindering the compatibility, but getting in touch with them and
>>> figuring out how to do it properly together. We created this
>>path, we
>>> should not destroy it but help others find a safer route. And
>>libvirt
>>> is indeed being used by quite a few people.
>> 
>>I don't understand what any of this means, sorry. I'm not being
>>facetious, could be my own fault. I have written many Wireshark
>>plugins
>>so I know a lot about that topic. What problems are the libvirt
>>people
>>experiencing that I am not? What strange and mystical path is this
>>that
>>we are on? Why did we mess up? Please enlighten me. Really, I
>>would like
>>to know so we can have a fruitful conversation about this because
>>right
>>now I am really confused.
>> 
>> 
>> We made the initial mistake of staying in a patch that allowed for a 
>> situation like this to occur. We made sure that you could link against our 
>> libraries and build your own projects from it. To revert this now, will lead 
>> to issues and pains in various places outside of the project, which might 
>> not seem to be a big thing initially, but it can hurt us in the long run. 
>> Think the whole Gnome 2/3 transition which drove quite a few people made, 
>> although they had a good reason for it.
> 
> So people can link to our libraries to write other projets? And expect it to 
> work reliably? That is news to me. I have made this question many times over 
> the years but I guess I was not worthy of a clear answer until now.
> 

I am not saying they should do it or that I appreciate it happening. All I am 
saying is that it happens and is happening and we did not put a stop to i

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

[Roland Knall]

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 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 or it should be changed, that would be a
> > valid discussion being had, but I do not think it invalidates those
> > points and arguments. Yes, debian is different but it is also the base
> > (through ubuntu) for the majority of linux distributions as
> > wells Microsofts own variety in wsl2 (at least if you go with the
> > default one), and therefore it should be considered as such.
>
> I don't know what you are trying to get at. I'm not trying to say what
> Debian should or shouldn't do.  They are free to decide for themselves.
> I would never presume to tell them what they should do, although I have
> strong opinions on that. There are lots of problems with their package
> but that is something to be discussed in the Debian bug tracker, not
> here. This project isn't part of Debian. This fact seems to be lost on
> some people.
>
>
The idea Balint had is, that no matter if you are using the official
package or build it yourself with our repository, you will not be locked
out of updating the package or distribution, and most certainly it will not
lead to any issues with package management. This might be a speciality of
Debian, but I think it is something we can support as it does not really
hinder us, except for the issue with the lib manifest, which now seems to
be resolved. And I do think that supporting this choice by our users is
something that is worth supporting.


>
> >
> > The libvirt plugin is a valid example of where we messed up. And with
> > we I mean the whole project. We provided this path and we kept it
> > maintained for far too long, but it is here now and a solution needs
> > to be found. We started on that road with stating that we allow
> > invalidating the api in major version releases and also minor version
> > releases to some extend. The argument, that libvirt is still doing
> > something they should not be doing is valid. But the solution here is
> > not hindering the compatibility, but getting in touch with them and
> > figuring out how to do it properly together. We created this path, we
> > should not destroy it but help others find a safer route. And libvirt
> > is indeed being used by quite a few people.
>
> I don't understand what any of this means, sorry. I'm not being
> facetious, could be my own fault. I have written many Wireshark plugins
> so I know a lot about that topic. What problems are the libvirt people
> experiencing that I am not? What strange and mystical path is this that
> we are on? Why did we mess up? Please enlighten me. Really, I would like
> to know so we can have a fruitful conversation about this because right
> now I am really confused.
>

We made the initial mistake of staying in a patch that allowed for a
situation like this to occur. We made sure that you could link against our
libraries and build your own projects from it. To revert this now, will
lead to issues and pains in various places outside of the project, which
might not seem to be a big thing initially, but it can hurt us in the long
run. Think the whole Gnome 2/3 transition which drove quite a few people
made, although they had a good reason for it.

I agree with you btw on the fact that the way libvirt does this plugin is
not a good one. I think they should stop pretending to be extra smart in
this case and revert to a model, where one plugin version may be compatible
with multiple libvirt versions or vice versa. That would resolve this whole
issue. But unless we are willing to fight this fight (and I for one am not
particularly interested in that pandora's box) I do not see a reason why we
should actively undermine their approach, just for the sake of "being
right". I agree that it would be a better approach, but it would also open
up quite a few birthing pains and that at least would violate our "no
breaking unless major version release" policy. Another one of those we
never actively charted down, but try to uphold.

Hope this clears up the point I was trying to make

kind regards
Roland



> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
__

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

[Roland Knall]

We messed up in a sense, that we should have found an argument and final
position on API compatibility. Not that it did not work out well, but it
"happened" instead of being planned

That was, what I meant with "messed up".

I read their argument and I still disagree. 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 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 or it should be changed, that would be a valid discussion being
> had, but I do not think it invalidates those points and arguments. Yes,
> debian is different but it is also the base (through ubuntu) for the
> majority of linux distributions as wells Microsofts own variety in wsl2 (at
> least if you go with the default one), and therefore it should be
> considered as such.
> >
> > The examples listed here are valid, although not very widely distributed
> ones. Just because they are not distributed with a debian distribution is
> not a counterargument to the update argument Balint raised. I am also not
> certain, why arguing against that on the pure merit of not being part of a
> distribution is a technical argument.
> >
> > The libvirt plugin is a valid example of where we messed up. And with we
> I mean the whole project. We provided this path and we kept it maintained
> for far too long, but it is here now and a solution needs to be found. We
> started on that road with stating that we allow invalidating the api in
> major version releases and also minor version releases to some extend. The
> argument, that libvirt is still doing something they should not be doing is
> valid. But the solution here is not hindering the compatibility, but
> getting in touch with them and figuring out how to do it properly together.
> We created this path, we should not destroy it but help others find a safer
> route. And libvirt is indeed being used by quite a few people.
>
> I generally agree with you on the other points, but why do you believe
> we messed up? We allow and help external plugin development and did it
> in a widely followed way of maintaining the shared library ABI and
> headers. I think we did great in that regard and libvirt just
> maintains an external plugin, the way we advertised to be possible. I
> also think that there is no better way, but I'll be ready to be proven
> wrong.
>
> We talked about the libvirt plugin and this is why I believe that the
> status quo is the best for the users:
>
> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830
>
> I also reached out to them prior to our conversation and they
> elaborated on their decision to ship the plugin separately and I'm
> convinced that that's the best option of the users:
> https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469
>
> Cheers,
> Balint
>
> >
> > As for the straw man argument, the Code of Conduct defines how
> collaboration and social interaction should happen. As such, I do not see
> this as a straw man argument but a valid reason, why Balint chose the paths
> he chose in the past and why this package exists as it does now. In a
> technical discussion it is as important to understand why somebody did
> something as it is to listen to each others arguments. And this gives
> reason to why the current situation is what it is, and should be validated
> in choosing a solution for the future.
> >
> > kind regards
> > Roland
> >
> > Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :
> >>
> >> Keep in mind I am just a user but I'm not one to skip a good technical
> >> discussion.
> >>
> >> I'm ignoring your other points on purpose, there is only so much I can
> >> handle in one sitting.
> >>
> >> On 20/12/23 13:24, Bálint Réczey wrote:
> >> > Having separate packages follows Debian packaging best practices and
> >> > served external projects extending wireshark such as netexpect (
> >> >
> https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
> >>
> >> I lookup up what netexpect is. Your link is from 2011. Actual link
> >> (https://tracker.debian.org/pkg/netexpect) says "This package is not
> >> part of 

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

[Roland Knall]

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 or it should be changed, that would be a valid discussion being
had, but I do not think it invalidates those points and arguments. Yes,
debian is different but it is also the base (through ubuntu) for the
majority of linux distributions as wells Microsofts own variety in wsl2 (at
least if you go with the default one), and therefore it should be
considered as such.

The examples listed here are valid, although not very widely distributed
ones. Just because they are not distributed with a debian distribution is
not a counterargument to the update argument Balint raised. I am also not
certain, why arguing against that on the pure merit of not being part of a
distribution is a technical argument.

The libvirt plugin is a valid example of where we messed up. And with we I
mean the whole project. We provided this path and we kept it maintained for
far too long, but it is here now and a solution needs to be found. We
started on that road with stating that we allow invalidating the api in
major version releases and also minor version releases to some extend. The
argument, that libvirt is still doing something they should not be doing is
valid. But the solution here is not hindering the compatibility, but
getting in touch with them and figuring out how to do it properly together.
We created this path, we should not destroy it but help others find a safer
route. And libvirt is indeed being used by quite a few people.

As for the straw man argument, the Code of Conduct defines how
collaboration and social interaction should happen. As such, I do not see
this as a straw man argument but a valid reason, why Balint chose the paths
he chose in the past and why this package exists as it does now. In a
technical discussion it is as important to understand why somebody did
something as it is to listen to each others arguments. And this gives
reason to why the current situation is what it is, and should be validated
in choosing a solution for the future.

kind regards
Roland

Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :

> Keep in mind I am just a user but I'm not one to skip a good technical
> discussion.
>
> I'm ignoring your other points on purpose, there is only so much I can
> handle in one sitting.
>
> On 20/12/23 13:24, Bálint Réczey wrote:
> > Having separate packages follows Debian packaging best practices and
> > served external projects extending wireshark such as netexpect (
> >
> https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
>
> I lookup up what netexpect is. Your link is from 2011. Actual link
> (https://tracker.debian.org/pkg/netexpect) says "This package is not
> part of any Debian distribution." OK... Starting strong there.
>
> > ) and the separately maintained libvirt dissector (
> > https://packages.debian.org/unstable/libvirt-wireshark ).
>
> You keep coming back to the libvirt plugin. What do you expect to prove
> with this? You really think maintaining separate Debian packages is a
> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
> non-sensical statements. Do you want me to build the libvirt-wireshark
> plugin against our RPM package just to put this argument to rest once
> and for all?
>
>
> > As I interpret our Code of Conduct collaboration with other projects
> > is highly encouraged no matter if Wireshark builds on them or they
> > build on Wireshark. I acted according to that in maintaining the
> > Debian packaging both here and in the official Debian repository.
> >
>
> Straw man argument. No one said collaboration is bad.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 Réczey <
bal...@balintreczey.hu>:

> Hi,
>
> João Valverde  ezt írta (időpont: 2023. nov. 27., H, 21:42):
> >
> >
> >
> > On 27/11/23 16:26, Jeff Morriss wrote:
> > > On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:
> > >
> > >
> > > On 22/11/23 15:37, John Thacker wrote:
> > >> On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:
> > >>
> > >>
> > >> There are a myriad issues I have touched upon. To recap, in
> > >> my opinion, if we want to provide public shared libraries
> > >> (libwireshark, wiretap, wsutil... for what I don't know) we
> > >> should do a better job of that collectively as a project. If
> > >> we don't want to do that we should kill the Debian package
> > >> inanity.
> > >>
> > >> A third alternative is just to keep the status quo and I'll
> > >> try to avoid this subject entirely because of how much it
> > >> bothers me to just ignore all these technical issues.
> > >>
> > >>
> > >> My understanding of the Debian packaging scripts (and similar for
> > >> the RPM package) use case is that people might be running one of
> > >> those distributions and want to upgrade Wireshark on their system
> > >> using their distribution's native package manager by taking
> > >> either a git repository or a tarball and building a package that
> > >> they can upgrade their distribution-provided package to.
> > >>
> > >> That isn't necessarily to add custom dissectors and provide
> > >> public shared libraries, though it could be. Oftentimes it's as
> > >> simple as "my distribution is capable of compiling 3.6.x or
> > >> later, but for stability reasons it's still shipping 2.6.x
> > >> (Debian buster/oldstable, RHEL 8 and clones)," and someone wants
> > >> to update wireshark without any of their own changes, just
> > >> without upgrading their distribution. It's handy to be able to
> > >> accommodate that if possible.
> > >
> > > Thanks for the feedback. Let me try to break down my response to
> that:
> > >
> > > 1. I think spending resources on distro packaging is unwise in
> > > general. "Make install" works fine and there are great maintainers
> > > already doing that work for Linux distributions. RPM is just
> > > low-effort low-intrusion enough that it doesn't bother me to
> > > divert from other tasks to work on it when I have to.
> > >
> > >
> > > I used to maintain a custom Wireshark build.  The packaging stuff was
> > > invaluable for that: it allowed me to compile (and easily package)
> > > once and push the resulting RPMs to hundreds of systems.  "make
> > > install" would not have worked for me as the end (user) systems were
> > > not capable of compiling Wireshark.
> > >
> > > I also, for a while, used our RPM stuff as an upstream example for
> > > Fedora/Red Hat to improve their packaging, including (IIRC) bringing
> > > in all the freedesktop integration stuff.  It was a lot easier to
> > > check that stuff into Wireshark and point them to it than try to do
> > > all the work in their world/repo (which is unfamiliar to me).
> > >
> >
> > I was addressing the user-wants-to-build-locally use case with the "make
> > install" comment.
> >
> > To address your use-case:
> >
> > 1. Someone whose job is to maintain a custom build for a medium/large
> > organization does not depend on us to create a package, although it can
> > help of course. At the end of the day resources are limited and need to
> > be prioritized for a volunteer project. Like I said, RPM doesn't bother
> > me, it rarely gets in my way or demands much of my time.
> >
> > 2. If someone on the Wireshark team wants to assume the package
> > maintainer role that could work if they are responsive and not putting
> > some distribution's priorities above our own.
>
> I tried to assess the amount of work required by the presence of the
> Debian packaging scripts in the repository.
> This is what I found covering roughly one year of development in the
> master branch between branching off the 4.0 and 4.2 releases:
>
> $ git merge-base origin/release-4.2 origin/master | xargs git describe
> v4.1.1rc0-386-geb539196a9
> $ git merge-base origin/release-4.2 origin/release-4.0  | xargs git
> describe
> v3.7.3rc0-146-g7d583e1340
> $ git log --oneline v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 |
> wc -l
> 3925
> $ git log --oneline
> v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
> packaging/debian/ | wc -l
> 64
> $ git log --oneline
> v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
> packaging/debian/*.symbols | wc -l
> 50
>
> 1.6% of all the commits touched the 

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

[Roland Knall]

s is permitted under the GPL if
>>using a
>>>> GPL-compatible license for your software. It's the main
>>difference
>>>> between the GPL and so-called "permissive" licenses.
>>>>
>>>> >
>>>> > As I understand it that is no longer possible? To me
>>that's an
>>>> > unnecessary restriction which we do not need to put on
>>our users
>>>> and I
>>>> > see no point/gain in doing so.
>>>>
>>>> If you don't want to use the GPL you can choose a
>>GPL-compatible
>>>> license
>>>> (BSD for example, there are many) and register your plugin with
>>>> WS_PLUGIN_IS_GPLv2_COMPATIBLE. The SPDX ID is optional but
>>helpful.
>>>>
>>>> You may also use GPLv2 and just not distribute your binary
>>(in the
>>>> case
>>>> of businesses and corporations outside of the collective
>>entity that
>>>> legally comprises it).
>>>>
>>>> So it's not really restricting your freedom to use
>>Wireshark, it's
>>>> just
>>>> respecting the terms of the GPL under which developers
>>contribute
>>>> to the
>>>> project.
>>>>
>>>> This is my understanding of the terms under which I choose to
>>>> contribute
>>>> to Wireshark. If anyone has a better understanding or
>>reason why
>>>> this
>>>> interpretation of the GPL, that matches the FSF FAQ, is wrong,
>>>> please do
>>    >> share. I'm very open to a good-faith discussion.
>>>>
>>>>
>>>> > Best regards
>>>> > Anders
>>>> >
>>>> > Den mån 4 dec. 2023 14:05João Valverde  skrev:
>>>> >
>>>> > Confused was not an offense, "GPL license" is
>>patently not the
>>>> > same as
>>>> > "GPL-compatible license" so it is a legitimate reason
>>to be
>>>> confused.
>>>> > Please avoid unnecessary and unfair characterizations
>>of my
>>>> words.
>>>> >
>>>> > And I will not revert it on that basis. I will revert
>>it if my
>>>> > understanding of the our license requirements is wrong or
>>>> flawed.
>>>> > It is
>>>> > not OK for you to exempt some use-case from the license
>>>> terms under
>>>> > which every developer contributes to this project.
>>>> >
>>>> > Gerald can revert it if he wishes and I will respect
>>it. As
>>>> > project lead
>>>> > he can make that call.
>>>> >
>>>> > On 04/12/23 12:35, Roland Knall wrote:
>>>> > > 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 those modifications at
>>all, and
>>>> > going from
>>>> > > the point that they change the CMakeListsCustom.txt
>>>> files, one
>>>> > could
>>>> > > argue, that this is not a source code modification
>>in the
>>>> sense
>>>> > meant
>>>> > > by the gpl license.
>>>> > >
>>>> > > Joao, I agree with having a clear path for license
>>>> application,
>>>> > and I
>>  

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

[Roland Knall]

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 those modifications at all, and going from the point that they
change the CMakeListsCustom.txt files, one could argue, that this is not a
source code modification in the sense meant by the gpl license.

Joao, I agree with having a clear path for license application, and I also
agree that we should be prudent on what parts a user can use and which he
can't. I would even be ok if we have a warning in the build-process,
explicitly stating that the code being linked is not fully compliant and
therefore not allowed to be distributed. But I strongly disagree cutting
off the leg we are standing on just on pure principle. The corporate users
are a HUGE part of our userbase. And if we go down this route, we need to
have a proper discussion about this. Just adding license enforcement
without having the discussion is NOT the way to move forward here.

Please add another patch, which keeps the ABI versioning in (which I really
appreciate and think is a good thing to do), but reverts the enforcement of
the licenses. Then we can start to properly discuss how to move forward
with this topic. It will - most likely - require a vote by the technical
steering comittee.

kind regards
Roland

Am Mo., 4. Dez. 2023 um 13:23 Uhr schrieb João Valverde :

>
>
> On 04/12/23 12:19, João Valverde wrote:
> >
> >
> > On 04/12/23 12:12, Bálint Réczey wrote:
> >> João Valverde  ezt írta (időpont: 2023. dec. 4., H, 12:59):
> >>>
> >>>
> >>> On 03/12/23 23:25, João Valverde wrote:
>  Hi,
> 
>  There are some changes in progress to the plugin registration API that
>  break compatibility and require manual intervention from plugin
>  authors maintaining plugins out-of-tree. These changes are rather
>  minor and concern only plugin registration, not other APIs accessible
>  to plugins.
> 
>  See MR 13524:
>  https://gitlab.com/wireshark/wireshark/-/merge_requests/13524
> 
>  Changes required are rewriting the registration code (very easy to do
>  [1]) and declare (using a C enum) that the plugin is released either
>  under GPLv2 or later, or a GPLv2 compatible license. The other changes
>  to the ABI version number are
> >>> The choice of the word "released" here was unfortunate, because it may
> >>> imply distribution. Please consider "licensed" instead.
> >>>
> >>> The license declaration field just affirms what was already implicit:
> >>> Wireshark plugins must use licensing terms compatible with the GPL
> >>> version 2, so there is no policy change there.
> >> GPL allows linking and using GPL-licensed software with
> >> non-GPL-licensed software locally. This is an important use case of
> >> many Wireshark users who do not wish releasing their plugins and your
> >> change broke that. Please revert it.
> >>
> >
> > https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
>
> Also it does not require a GPL license, it requires a GPL-compatible
> license, so you may just be confused.
>
> >
>  currently not relevant to plugin authors (no policy change is
>  implied), it just uses less boilerplate with macros.
> 
>  This should improve the plug-in experience for both developers and
>  users and may improve compatibility in the future.
> >>
>  Comments welcome.
> 
>  Regards,
> 
>  João
> 
>  [1]
> https://gitlab.com/wireshark/wireshark/-/commit/90b16b40921b737aadf9186685d866fd80e37ee6#4a1fe9011e8240918e5fc6230c0bcd2e4d3b9c34
> 
> 
> 
> ___
> 
> 
>  Sent via:Wireshark-dev mailing list 
>  Archives:https://www.wireshark.org/lists/wireshark-dev
>  Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >>>
> ___
> >>>
> >>> Sent via:Wireshark-dev mailing list 
> >>> Archives:https://www.wireshark.org/lists/wireshark-dev
> >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >>
> ___
> >>
> >> Sent via:Wireshark-dev mailing list 
> >> Archives:https://www.wireshark.org/lists/wireshark-dev
> >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >
> >
> ___
> >
> > Sent via:Wireshark-dev mailing list 
> > Archives:

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

[Roland Knall]

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 is a too strict reading of GPL
v2. Overmore it is a major change, and I think it should be avoided as it
will kill a lot of legitimate use-cases for Wireshark. I understand that we
need to be as open as possible, but this is actually killing the
openess instead of helping it.

As much as it pains us, we must allow corporate users to maintain their own
plugin and manage it with future versions of Wireshark. Everything else is
not in the best interest of the application.

Just my 2 cents

Roland

Am Mo., 4. Dez. 2023 um 13:12 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:

> João Valverde  ezt írta (időpont: 2023. dec. 4., H, 12:59):
> >
> >
> >
> > On 03/12/23 23:25, João Valverde wrote:
> > > Hi,
> > >
> > > There are some changes in progress to the plugin registration API that
> > > break compatibility and require manual intervention from plugin
> > > authors maintaining plugins out-of-tree. These changes are rather
> > > minor and concern only plugin registration, not other APIs accessible
> > > to plugins.
> > >
> > > See MR 13524:
> > > https://gitlab.com/wireshark/wireshark/-/merge_requests/13524
> > >
> > > Changes required are rewriting the registration code (very easy to do
> > > [1]) and declare (using a C enum) that the plugin is released either
> > > under GPLv2 or later, or a GPLv2 compatible license. The other changes
> > > to the ABI version number are
> >
> > The choice of the word "released" here was unfortunate, because it may
> > imply distribution. Please consider "licensed" instead.
> >
> > The license declaration field just affirms what was already implicit:
> > Wireshark plugins must use licensing terms compatible with the GPL
> > version 2, so there is no policy change there.
>
> GPL allows linking and using GPL-licensed software with
> non-GPL-licensed software locally. This is an important use case of
> many Wireshark users who do not wish releasing their plugins and your
> change broke that. Please revert it.
>
> >
> > > currently not relevant to plugin authors (no policy change is
> > > implied), it just uses less boilerplate with macros.
> > >
> > > This should improve the plug-in experience for both developers and
> > > users and may improve compatibility in the future.
>
>
> > >
> > > Comments welcome.
> > >
> > > Regards,
> > >
> > > João
> > >
> > > [1]
> https://gitlab.com/wireshark/wireshark/-/commit/90b16b40921b737aadf9186685d866fd80e37ee6#4a1fe9011e8240918e5fc6230c0bcd2e4d3b9c34
> > >
> > >
> ___
> > >
> > > Sent via:Wireshark-dev mailing list 
> > > Archives:https://www.wireshark.org/lists/wireshark-dev
> > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> > > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 end of the year anyway.

I do not think that further discussing this issue is actually beneficial
for the long term resolution of this situation. Both sides have valid
arguments and good pointers and I would suggest as soon as the committee
has taken up the topic we collectively create a single mission statement as
suggested by Joao above. Until then, personally I will refrain from
discussing this further, as I have said everything there is to say from
my perspective.

Do you agree Gerald?

kind regards
Roland



Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
> Since you've got the experience and actually use it?
>
> There are loads of lintian warnings waiting to be fixed, or there were
> until recently. Maybe you'd like to start there, and be more active staying
> on top of the all-important symbol lists. Just a thought.
>
> On 21/11/23 15:00, Anders Broman wrote:
>
> Hi,
> I found it useful to be able to do Debian packages easily to provide
> internal installation packages and even ppa for Ubuntu.
> So I have been using the Debian build system.
> Best regards
> Anders
>
> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>
>> 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,
>> we can provide assistance for future implementors and as a starting point,
>> by keeping the directory underneath packaging/debian.
>>
>> just my thoughts
>> Roland
>>
>>
>> Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
>> bal...@balintreczey.hu>:
>>
>>> Hi All,
>>>
>>> João shared his opinion about the project's commitment to maintain the
>>> packaging/debian/ in the project's repository:
>>>
>>>
>>> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952
>>>
>>> I believe the current practice is reasonable and beneficial enough for
>>> many parties to warrant the work, but I could be wrong.
>>>
>>> Probably the most important question is if there is anyone relying on
>>> the packaging scripts there. If you are, please speak up otherwise the
>>> directory may be dropped.
>>>
>>> Comments are welcome.
>>>
>>> Cheers,
>>> Balint
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
> ___
> Sent via:Wireshark-dev mailing list  
> 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> 
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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,
we can provide assistance for future implementors and as a starting point,
by keeping the directory underneath packaging/debian.

just my thoughts
Roland


Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:

> Hi All,
>
> João shared his opinion about the project's commitment to maintain the
> packaging/debian/ in the project's repository:
>
>
> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952
>
> I believe the current practice is reasonable and beneficial enough for
> many parties to warrant the work, but I could be wrong.
>
> Probably the most important question is if there is anyone relying on
> the packaging scripts there. If you are, please speak up otherwise the
> directory may be dropped.
>
> Comments are welcome.
>
> Cheers,
> Balint
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 wsdg the one for the development guide.

kind regards
Roland

Am Mo., 6. Nov. 2023 um 22:15 Uhr schrieb Eugène Adell <
eugene.ad...@gmail.com>:

> Hi Machiko,
>
> it seems this Guide did not always evolve at the same pace than the
> implementation for this part.
> I confirm that in fact a Spurious Retrans cannot be SYN or FIN flagged
> as it is an ordinary data packet for which Wireshark has already seen
> an acknowledgement ( = that ACK was either lost, ignored by the its
> receiver, or received too late ). The whole interpretation is built on
> what's in the capture obviously, but also on what could be missing
> (from sequence or ack gaps), hence some difficulties maybe to document
> with only 2-3 conditions what triggers such packet marks.
>
> regards
> E.A.
>
>
> Le lun. 6 nov. 2023 à 17:31, Machiko Ichihashi  a
> écrit :
> >
> > To whom it may concern,
> >
> >
> >
> > My name is Machiko Ichihashi, and I work as an engineer in Japan.
> >
> > I use Wireshark for my work, and I want to express my gratitude for its
> usefulness.
> >
> >
> >
> > I would like to ask for an explanation of the specifications described
> in Wireshark User's Guide 4.3.0.
> >
> > TCP Spurious Retransmission
> >
> > https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html
> >
> > I would like to request a clarification regarding a specification
> mentioned in the Wireshark User's Guide 4.3.0.
> >
> >
> >
> > In this section, the first condition states,
> >
> > "The SYN or FIN flag is set."
> >
> > Is this condition really necessary?
> >
> > It seems that these packets should be required to be data packets, so I
> don’t think the SYN or FIN flags are necessary.
> >
> >
> >
> > Could you please confirm this?
> >
> >
> >
> > Regards,
> >
> > Machiko Ichihashi/TOYO Corporation
> >
> >
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 Uhr schrieb Inga :

> Hello everybody,
>
> I am trying to build wireshark from source on my MacBook Pro with MacOs
> Ventura 13.2.1 because I want to capture BLE packets with the following
> dissector:
> https://github.com/furiousMAC/continuity/tree/master/dissector/3.4.4
>
> For that, I downloaded wireshark-3.4.4 from this source:
> http://ftp.uni-kl.de/pub/wireshark/src/all-versions/
>
> I followed the README.macos and installed the required libraries with the
> tools/macos-setup.sh script.
>
> After that I ran cmake -G Ninja .. in my build directory. The output is
> attached. Then I ran ninja what resulted in multiple fatal errors (also
> attached).
>
> Does anybody know what I am doing wrong? Or how I can troubleshoot this
> problem?
>
> Thank you very much in advance!
>
> Inga
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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.

So, create a directory called c:\projects\wireshark. Checkout the
sourcecode to c:\projects\wireshark\wireshark, create a directory
c:\projects\wireshark\build and start your cmake with that directory as
build, c:\projects\wireshark\wireshark as src and WIRESHARK_BASE_DIR as
c:\projects\wireshark.

If you still run into issues, jump on the Discord and we will try to
figure it out. The link for it, you will find on the Wireshark start page.

cheers
Roland

Am Do., 4. Mai 2023 um 04:10 Uhr schrieb :

> The issues with building from a git clone are:
>
>1. I clone into C:\Project\wireshark. The make adds libraries to
>C:\Project\wireshark\wireshark-win64-libs and then complains at the end
>that targets contain paths that are prefixed in the source directory.
>2. I want to use C:\Project\wireshark and place libs in
>C:\Project\wireshark-win64-libs, but I have other problems if I don’t
>define the WIRESHARK_BASE_DIR and just define WIRESHARK_LIB_DIR as
>C:\Project\wireshark-win64-libs and execute cmake from C:\Project\wsbuild.
>3. The cmake command says “Working in
>C:\Project\wireshark\wireshark-win64-libs” even though I start in
>C:\Project\wsbuild
>4. Setup does “Looking for …” and does not find lots of header files
>(i.e. arpa.h, grp.h, sys/types.h etc.)
>5. Performing Test HAVE_STRUCT_* routines fail
>6. After “Configuring done”, many CMake Errors in epan/CmakeLists.txt
>occur. These all complain about Target … contain paths that are prefixed in
>the source directory. But CMake and Wireshark placed the libraries in
>wireshark-win64-lib under the source directory.
>
> I’ve developed a custom dissector and maintained in for 20 years, but
> that’s all before version 4.x. I’ve read the Developer’s Guide and I think
> I’ve performed the steps correctly.
>
>
>
> Here is the command line listing of my process:
>
>
>
> C:\Project>git clone https://gitlab.com/wireshark/wireshark.git
>
> Cloning into 'wireshark'...
>
> remote: Enumerating objects: 692482, done.
>
> remote: Counting objects: 100% (1388/1388), done.
>
> remote: Compressing objects: 100% (613/613), done.
>
> remote: Total 692482 (delta 785), reused 1369 (delta 774), pack-reused
> 691094
>
> 8.48 MiB | 10.42 MiB/s
>
> Receiving objects: 100% (692482/692482), 750.34 MiB | 10.87 MiB/s, done.
>
> Resolving deltas: 100% (558635/558635), done.
>
> Updating files: 100% (6567/6567), done.
>
>
>
> C:\Project>choco upgrade all
>
> Chocolatey v1.3.1
>
> Upgrading the following packages:
>
> all
>
> By upgrading, you accept licenses for the packages.
>
> asciidoctorj v2.5.7 is the latest version available based on your
> source(s).
>
> chocolatey v1.3.1 is the latest version available based on your source(s).
>
> chocolatey-compatibility.extension v1.0.0 is the latest version available
> based on your source(s).
>
> chocolatey-core.extension v1.4.0 is the latest version available based on
> your source(s).
>
> chocolatey-windowsupdate.extension v1.0.5 is the latest version available
> based on your source(s).
>
> cmake v3.26.3 is the latest version available based on your source(s).
>
> docbook-bundle v1.0.2 is the latest version available based on your
> source(s).
>
> doxygen.install v1.9.6 is the latest version available based on your
> source(s).
>
> KB2919355 v1.0.20160915 is the latest version available based on your
> source(s).
>
> KB2919442 v1.0.20160915 is the latest version available based on your
> source(s).
>
> KB2999226 v1.0.20181019 is the latest version available based on your
> source(s).
>
> KB3033929 v1.0.5 is the latest version available based on your source(s).
>
> KB3035131 v1.0.3 is the latest version available based on your source(s).
>
> nsis v3.08 is the latest version available based on your source(s).
>
> nsis.install v3.08 is the latest version available based on your source(s).
>
> python3 v3.11.3 is the latest version available based on your source(s).
>
> python311 v3.11.3 is the latest version available based on your source(s).
>
> strawberryperl v5.32.1.1 is the latest version available based on your
> source(s).
>
> vcredist140 v14.34.31938 is the latest version available based on your
> source(s).
>
> vcredist2015 v14.0.24215.20170201 is the latest version available based on
> your source(s).
>
> winflexbison v2.4.9.20170215 is the latest version available based on your
> source(s).
>
> winflexbison3 v2.5.24.20210105 is the latest version available based on
> your source(s).
>
> xsltproc v1.1.28.0 is the latest version available based on your source(s).
>
>
>
> C:\Project> set
>
> ...
>
> WIRESHARK_BASE_DIR=C:\Project\wireshark
>
> 

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

[Roland Knall]

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 would be much appreciated.
> >
> > Short-term?
> >
> > Build with make - or Ninja - instead (that's how the Wireshark buildbots
> operate).  Attempting to figure out why this is an issue with Xcode will
> probably take time.
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
> Understood. Thanks.
>
> Is it worth filing an issue for this via the issue tracker?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 24.12.2022 um 07:40 schrieb Guy Harris :
> 
> On Dec 23, 2022, at 4:17 PM,  
>  wrote:
> 
>> I run Wireshark 4.1.0 with my plugin dissector. It runs well, dissects 
>> packets, reports issues, and behaves as expected. I can load a capture file, 
>> that has packets of my protocol, exit Wireshark, and get no output to the 
>> command line. I can load another capture file, that has packets of my 
>> protocol, and get many many errors like:
>> ** (wireshark:n) hh:mm:ss.fff [GLib CRITICAL] -- g_string_free: 
>> assertion 'string != NULL' failed
>> where:
>>• n is always the same number within a single run of Wireshark, and 
>> changes from run to run.
> 
> It's the process ID of the process running Wireshark.
> 
>>• The timestamps can be 0.01 to 0.03 seconds apart and give me more than 
>> 60 in a second.
> 
> The code that's trying to free something "pointed to" by a null pointer is 
> being executed many times within a second.
> 
>>• The list is output whenever I run a display filter or clear the display 
>> filter.
> 
> The packets are redirected when that happens, so it's probably happening 
> within a dissector.
> 
>>• The list seems to be the same size whether the filter returns all 
>> packets, or some, or even two.
> 
> When a display filter is applied, it's applied to *all* packets.
> 
>> Maybe it is getting this error in my dissector or in another one.
> 
> Almost certainly.  My guess is that it's your dissector; what happens if you 
> remove your dissector?
> 
>> Is the error saying that it is trying to free a non-null string that has 
>> already been freed?
> 
> The beginning of g_string_free() is
> 
>gchar *
>g_string_free (GString  *string,
>   gboolean  free_segment)
>{
>  gchar *segment; 
> 
>  g_return_val_if_fail (string != NULL, NULL);
> 
> and the g_return_val_if_fail() call is what's failing.
> 
>> In any event, are there any recommendations for trying to locate this error?
> 
> Look for all places in your code where you're calling g_string_free() and 
> make sure they can't be called with a null pointer.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 :

> Hello,
>
> I'm trying to build from source, on this hash 
> 99e93e24b89e13e9e1ccf6c3665814e61f59fa48
> using the cmd line:
>
> cmake -DUSE_qt6=off -DUSE_STATIC=on -DBUILD_wireshark=OFF
> -DBUILD_tshark=OFF   -DBUILD_editcap=OFF -DBUILD_capinfos=OFF
>  -DBUILD_captype=OFF -DBUILD_mergecap=OFF -DBUILD_reordercap=OFF
> -DBUILD_text2pcap=OFF -DBUILD_dftest=OFF -DBUILD_randpkt=OFF
>  -DBUILD_rawshark=OFF -G Ninja ..
>
> (I just want to statically build dumpcap)
>
>
> I'm getting the following error:
> *[2/415] Linking C shared library run/libwsutil.so.0.0.0*
> FAILED: run/libwsutil.so.0.0.0
> : && /usr/bin/gcc -fPIC -fvisibility=hidden  -fexcess-precision=fast -Wall
> -Wextra -Wendif-labels -Wpointer-arith -Wformat-security -fwrapv
> -fno-strict-overflow -Wvla -Waddress -Wattributes -Wdiv-by-zero
> -Wignored-qualifiers -Wpragmas -Wno-overlength-strings -Wno-long-long
> -Wredundant-decls -Wno-error=maybe-uninitialized
> -Wno-error=alloc-size-larger-than= -Wno-error=stringop-overflow=
> -Wno-format-truncation -Wno-error=deprecated-declarations
> -Werror=unused-but-set-variable -Wframe-larger-than=32768
> -fdiagnostics-color=always -Wunused-const-variable -Wshadow
> -Wold-style-definition -Wstrict-prototypes -Wlogical-op -Wjump-misses-init
> -Werror=implicit -Wno-pointer-sign
>  -fmacro-prefix-map=/home/sousajo/etudes/wireshark/=
> -fmacro-prefix-map=/home/sousajo/etudes/wireshark/build/=
> -fmacro-prefix-map=../= -O2 -g -DNDEBUG  -Wl,--as-needed -shared
> -Wl,-soname,libwsutil.so.0 -o run/libwsutil.so.0.0.0
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_array.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_core.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_allocator_block.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_allocator_block_fast.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_allocator_simple.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_allocator_strict.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_interval_tree.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_list.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_map.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_miscutl.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_multimap.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_stack.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_strbuf.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_strutl.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_tree.c.o
> wsutil/wmem/CMakeFiles/wmem.dir/wmem_user_cb.c.o
> wsutil/CMakeFiles/wsutil.dir/802_11-utils.c.o
> wsutil/CMakeFiles/wsutil.dir/adler32.c.o
> wsutil/CMakeFiles/wsutil.dir/base32.c.o
> wsutil/CMakeFiles/wsutil.dir/bitswap.c.o
> wsutil/CMakeFiles/wsutil.dir/buffer.c.o
> wsutil/CMakeFiles/wsutil.dir/codecs.c.o
> wsutil/CMakeFiles/wsutil.dir/crash_info.c.o
> wsutil/CMakeFiles/wsutil.dir/crc10.c.o
> wsutil/CMakeFiles/wsutil.dir/crc16.c.o
> wsutil/CMakeFiles/wsutil.dir/crc16-plain.c.o
> wsutil/CMakeFiles/wsutil.dir/crc32.c.o
> wsutil/CMakeFiles/wsutil.dir/crc5.c.o wsutil/CMakeFiles/wsutil.dir/crc6.c.o
> wsutil/CMakeFiles/wsutil.dir/crc7.c.o wsutil/CMakeFiles/wsutil.dir/crc8.c.o
> wsutil/CMakeFiles/wsutil.dir/crc11.c.o
> wsutil/CMakeFiles/wsutil.dir/curve25519.c.o
> wsutil/CMakeFiles/wsutil.dir/dot11decrypt_wep.c.o
> wsutil/CMakeFiles/wsutil.dir/eax.c.o
> wsutil/CMakeFiles/wsutil.dir/feature_list.c.o
> wsutil/CMakeFiles/wsutil.dir/filesystem.c.o
> wsutil/CMakeFiles/wsutil.dir/g711.c.o
> wsutil/CMakeFiles/wsutil.dir/inet_addr.c.o
> wsutil/CMakeFiles/wsutil.dir/interface.c.o
> wsutil/CMakeFiles/wsutil.dir/introspection.c.o
> wsutil/CMakeFiles/wsutil.dir/jsmn.c.o
> wsutil/CMakeFiles/wsutil.dir/json_dumper.c.o
> wsutil/CMakeFiles/wsutil.dir/mpeg-audio.c.o
> wsutil/CMakeFiles/wsutil.dir/nstime.c.o
> wsutil/CMakeFiles/wsutil.dir/cpu_info.c.o
> wsutil/CMakeFiles/wsutil.dir/os_version_info.c.o
> wsutil/CMakeFiles/wsutil.dir/please_report_bug.c.o
> wsutil/CMakeFiles/wsutil.dir/privileges.c.o
> wsutil/CMakeFiles/wsutil.dir/regex.c.o wsutil/CMakeFiles/wsutil.dir/rsa.c.o
> wsutil/CMakeFiles/wsutil.dir/sober128.c.o
> wsutil/CMakeFiles/wsutil.dir/socket.c.o
> wsutil/CMakeFiles/wsutil.dir/strnatcmp.c.o
> wsutil/CMakeFiles/wsutil.dir/str_util.c.o
> wsutil/CMakeFiles/wsutil.dir/strtoi.c.o
> wsutil/CMakeFiles/wsutil.dir/report_message.c.o
> wsutil/CMakeFiles/wsutil.dir/tempfile.c.o
> wsutil/CMakeFiles/wsutil.dir/time_util.c.o
> wsutil/CMakeFiles/wsutil.dir/to_str.c.o
> wsutil/CMakeFiles/wsutil.dir/type_util.c.o
> wsutil/CMakeFiles/wsutil.dir/unicode-utils.c.o
> wsutil/CMakeFiles/wsutil.dir/ws_getopt.c.o
> wsutil/CMakeFiles/wsutil.dir/ws_mempbrk.c.o
> wsutil/CMakeFiles/wsutil.dir/ws_pipe.c.o
> wsutil/CMakeFiles/wsutil.dir/wsgcrypt.c.o
> wsutil/CMakeFiles/wsutil.dir/wsjson.c.o
> wsutil/CMakeFiles/wsutil.dir/wslog.c.o
> wsutil/CMakeFiles/wsutil.dir/xtea.c.o
> 

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

[Roland Knall]

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

Here is the error from make.
I've attached cmake success and make error logs.txt,
  CMakeError.log and CMakeOutput.log

[ 84%] Building CXX object
ui/qt/CMakeFiles/qtui.dir/sequence_dialog.cpp.o
[ 84%] Building CXX object
ui/qt/CMakeFiles/qtui.dir/service_response_time_dialog.cpp.o
[ 84%] Building CXX object
ui/qt/CMakeFiles/qtui.dir/show_packet_bytes_dialog.cpp.o
/home/wptracy/wireshark/ui/qt/show_packet_bytes_dialog.cpp: In
member function ‘void
ShowPacketBytesDialog::symbolizeBuffer(QByteArray&)’:
/home/wptracy/wireshark/ui/qt/show_packet_bytes_dialog.cpp:474:20:
error: comparison is always false due to limited range of data
type [-Werror=type-limits]
  474 | if ((ba[i] < '\0' || ba[i] >= ' ')
&& ba[i] != (char)0x7f &&
!g_ascii_isprint(ba[i])) {
cc1plus: all warnings being treated as errors
make[2]: *** [ui/qt/CMakeFiles/qtui.dir/build.make:1806:
ui/qt/CMakeFiles/qtui.dir/show_packet_bytes_dialog.cpp.o] Error
1
make[1]: *** [CMakeFiles/Makefile2:10816:
ui/qt/CMakeFiles/qtui.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
wptracy@wptracy-desktop:~/wireshark/build$ 
  
I have these libraries installed:
wptracy@wptracy-desktop:~/wireshark/build$
sudo apt install gcc \
    g++\
    libglib2.0-dev \
    libc-ares-dev \
    libpcap-dev \
    libpcre2-dev \
    flex \
    make \
    python3 \
    libgcrypt-dev\
    qttools5-dev \
    qttools5-dev-tools \
    libqt5svg5-dev \
    qtmultimedia5-dev \
    qtbase5-dev \
    qtchooser \
    qt5-qmake \
    qtbase5-dev-tools\
    qt6-base-dev \
    qt6-multimedia-dev \
    qt6-tools-dev \
    qt6-tools-dev-tools \
    qt6-l10n-tools \
    libqt6core5compat6-dev \
    libxkbcommon-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'libgcrypt20-dev' instead of 'libgcrypt-dev'
flex is already the newest version (2.6.4-8build2).
g++ is already the newest version (4:11.2.0-1ubuntu1).
gcc is already the newest version (4:11.2.0-1ubuntu1).
libc-ares-dev is already the newest version (1.18.1-1build1).
libgcrypt20-dev is already the newest version (1.9.4-3ubuntu3).
libglib2.0-dev is already the newest version (2.72.1-1).
libpcap-dev is already the newest version (1.10.1-4build1).
libvulkan-dev is already the newest version (1.3.204.1-2).
libxkbcommon-dev is already the newest version (1.4.0-1).
make is already the newest version (4.3-4.1build1).
freeglut3-dev is already the newest version (2.8.1-6).
libqt5svg5-dev is already the newest version (5.15.3-1).
libqt6core5compat6-dev is already the newest version (6.2.4-1).
qt6-base-dev is already the newest version
(6.2.4+dfsg-2ubuntu1).
qt6-l10n-tools is already the newest version (6.2.4-1).
qt6-multimedia-dev is already the newest version (6.2.4-1).
qt6-tools-dev is already the newest version (6.2.4-1).
qt6-tools-dev-tools is already the newest version (6.2.4-1).
qtchooser is already the newest version (66-2build1).
qtmultimedia5-dev is already the newest version (5.15.3-1).
qttools5-dev is already the newest version (5.15.3-1).
qttools5-dev-tools is already the newest version (5.15.3-1).
libpcre2-dev is already the newest version (10.39-3ubuntu0.1).
python3 is already the newest version (3.10.6-1~22.04).
qt5-qmake is already the newest version
(5.15.3+dfsg-2ubuntu0.2).
qtbase5-dev is already the newest version
(5.15.3+dfsg-2ubuntu0.2).
qtbase5-dev-tools is already the newest version
(5.15.3+dfsg-2ubuntu0.2).
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
wptracy@wptracy-desktop:~/wireshark/build$ 
  

-- 
Pat Tracy | +1 303-933-9035
  

___
Sent via:    Wireshark-dev mailing list 
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             

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

[Roland Knall]

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
> compilation fails on:
>
>(ClCompile target) ->
>
>  C:\development\wireshark\ui\qt\widgets\detachable_tabwidget.cpp(158,56):
> error C2220: the following warning is treated as an error
> [C:\development\build\ui\qt\qtui.vcxproj]
>
>  C:\development\wireshark\ui\qt\widgets\detachable_tabwidget.cpp(158,56):
> error C2220: QMouseEvent * finishMouseMove = new
> QMouseEvent(QEvent::MouseMove, event->pos(), Qt::NoButton, Qt::NoButton,
> Qt::NoModifier); [C:\development\build\ui\qt\qtui.vcxproj]
>
>  C:\development\wireshark\ui\qt\widgets\detachable_tabwidget.cpp(158,56):
> error C2220:^
> [C:\development\build\ui\qt\qtui.vcxproj]
>
> Used the built in Cmake and git.
> Best regards
> Anders
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

The c-ares library is not the reason for 3.6 being RHEL 8 last edition. The
reason is Qt6 which is still not officially supported and therefore, as we
recommend it at least for Windows and macOS makes an obvious difference. I
took a look at the version used for centOS https://pkgs.org/search/?q=c-ares
and as you said, it includes the changes required for the CVE. Now, I have
not an issue (as stated before) to move back a version number to 1.13. It
was never my intention to make this minute detail a dipping point for RHEL
8.

But, RHEL 8 is being supported until 2029. I would be very careful how we
proceed with this line of argumentation in the future. Having the
possibility to remove support for some version on a major (!!) version
change for Wireshark is something we still should consider. RHEL 8 might be
an edge case here, but I would always consider dropping support for still
active distributions on major version changes, if it allows us to avoid
having that many #if/#else combinations in code. We have too many already.

I put a change online for moving to 1.13 (
https://gitlab.com/wireshark/wireshark/-/merge_requests/8321) which I will
move to 4.0 once merged and also adapt the releasenotes there. Will be in
time for the release of 4.0, but I would recommend maybe doing another rc
for it?

cheers
Roland

Am Fr., 30. Sept. 2022 um 14:04 Uhr schrieb John Thacker <
johnthac...@gmail.com>:

> I agree with bumping the version in general, and I can agree that there
> are cases where increasing the minimum version saves a lot of headaches
> even if we don't need a new API call.
>
> However, minimum version increases can mean effectively dropping support
> for a given Linux distribution (at least out of the box, and in a corporate
> environment changing things from "I need to bring in Wireshark and compile
> it in a local directory after installing packages from the official
> repository" to "and I also need to bring in some other libraries, and link
> against the local version instead of the installed version" can be a
> non-starter or at least complicated with security policies.)
>
> I like to consider exactly which library changes will drop a distribution
> (see
> https://gitlab.com/wireshark/wireshark/-/wikis/Development/Support_library_version_tracking
> ) and in the particular case the gain from c-ares 1.14 vs 1.13 doesn't seem
> very large compared to dropping a fairly popular family of distributions,
> especially one that has a lot of use in corporate and server environments
> where security policies can be strict.
>
> Making 3.6 is the last version that 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 absolute minimum was released nearly 12
>> years (!!) ago. I needed a newer API call that would have been sufficiently
>> supported with 1.11 or 1.12. But there were two considerations: first, we
>> already used 1.14 on our Windows build server and it is sufficiently
>> supported on all current and max-3 year old system we support. And second,
>> 1.13 and 1.14 both had CVE fixes attached. That's why I chose 1.14.
>>
>> I am totally fine to backtrack that if it is absolutely necessary, there
>> was no deeper consideration than to update a mandatory minimum version that
>> was looong overdue. There was no current security concern, or otherwise I
>> would have chosen an even higher version.
>>
>> As for Qt, glib and others, absolutely, if there is a security issue that
>> affects our released binaries, we should update our
>> buildsystems accordingly. I would not necessarily require a newer version
>> though.
>>
>> Btw, for Qt, there is a precondition we cannot control. Every Qt version
>> seems to require an even higher version of macos as a minimum requirement.
>> Here we are in need to update to higher versions for the buildsystems or
>> otherwise would not be able to ship.
>>
>> cheers
>> Roland
>>
>> Am Fr., 30. Sept. 2022 um 12:09 Uhr schrieb Anders Broman <
>> a.broma...@gmail.com>:
>>
>>> Hi,
>>> I just have a problem with our policy here. If we require a certain
>>> minimum version of a library to keep our code simple and keep up with
>>> depreciation and API changes that is fine. But if we start to look at
>>> vulnerabilities where do we draw the line then? Latest qt? Glib? Etc.
>>> Why make it harder to build the latest ws on rhel8 when in my opinion we
>>> don't need to and our code does not get cleaner by this decision?
>&

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

[Roland Knall]

Hi.

Ok, maybe I have to clarify my thought process here a little bit. The
original version we required as absolute minimum was released nearly 12
years (!!) ago. I needed a newer API call that would have been sufficiently
supported with 1.11 or 1.12. But there were two considerations: first, we
already used 1.14 on our Windows build server and it is sufficiently
supported on all current and max-3 year old system we support. And second,
1.13 and 1.14 both had CVE fixes attached. That's why I chose 1.14.

I am totally fine to backtrack that if it is absolutely necessary, there
was no deeper consideration than to update a mandatory minimum version that
was looong overdue. There was no current security concern, or otherwise I
would have chosen an even higher version.

As for Qt, glib and others, absolutely, if there is a security issue that
affects our released binaries, we should update our
buildsystems accordingly. I would not necessarily require a newer version
though.

Btw, for Qt, there is a precondition we cannot control. Every Qt version
seems to require an even higher version of macos as a minimum requirement.
Here we are in need to update to higher versions for the buildsystems or
otherwise would not be able to ship.

cheers
Roland

Am Fr., 30. Sept. 2022 um 12:09 Uhr schrieb Anders Broman <
a.broma...@gmail.com>:

> Hi,
> I just have a problem with our policy here. If we require a certain
> minimum version of a library to keep our code simple and keep up with
> depreciation and API changes that is fine. But if we start to look at
> vulnerabilities where do we draw the line then? Latest qt? Glib? Etc.
> Why make it harder to build the latest ws on rhel8 when in my opinion we
> don't need to and our code does not get cleaner by this decision?
> I'm sure all packages we use have vulnerabilities.
> Best regards
> Anders
>
> Den fre 30 sep. 2022 11:50Dario Lombardo  skrev:
>
>> Hi Anders,
>> unfortunately this is a hairy issue. Redhat's policy about security is a
>> bit puzzling. They patch (as told before) old versions to make them not
>> vulnerable, maintaining the same version number. This is weird since being
>> vulnerable or not is something everyone in the world points out by looking
>> at the version number. XX is vulnerable, XX+1 is not... but for redhat XX
>> is not vulnerable also. This is something I hit personally (think how many
>> times RH has patched vulnerable kernels), that basically makes vulnerable
>> systems untrackable. I don't know the rationale behind their policy, but
>> for regular people, this is something hard to manage.
>> So I get your point and I would really like another solution, but I agree
>> that we should not solve an issue they created.
>> Since they patched libcares, they keep track of what is vulnerable and
>> what is not: they should patch wireshark accordingly to make it compile
>> with the older one... if they shipped a recent wireshark, and we know they
>> don't.
>> Ciao.
>> Dario.
>>
>> On Thu, Sep 29, 2022 at 10:27 PM Anders Broman 
>> wrote:
>>
>>> Hi,
>>> No problem. Just so we are aware we dropp support for rhel8 and similiar
>>> due to a minor technicality in my opinion.
>>> Best regards
>>> Anders
>>>
>>>
>>> Den tors 29 sep. 2022 16:32Roland Knall  skrev:
>>>
>>>> That library was not the only consideration. The main consideration was
>>>> to cut-off at a certain point for 4.0 so that we can avoid having too many
>>>> things to consider going forward. There was a message about this on the
>>>> list a while back as well as a discussion at SF.
>>>>
>>>> Now, I get the argument to have compatibility for self-built versions,
>>>> and I could see a point, where we make a switch for a certain library to
>>>> have a compatibility mode. But I am not sure if this should be the way
>>>> forward in this case. Much rather have the nuisance to compile a more
>>>> recent version together with Wireshark, than have one more thing to support
>>>>
>>>> regards
>>>> Roland
>>>>
>>>> Am Do., 29. Sept. 2022 um 15:03 Uhr schrieb Jeff Morriss <
>>>> jeff.morriss...@gmail.com>:
>>>>
>>>>> Also keep in mind that if RHEL decides to fix the CVE(s) in question
>>>>> in version 8 of their OS, they would likely apply the fix for the CVE to
>>>>> the version of CARES that they are 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 

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

[Roland Knall]

That library was not the only consideration. The main consideration was to
cut-off at a certain point for 4.0 so that we can avoid having too many
things to consider going forward. There was a message about this on the
list a while back as well as a discussion at SF.

Now, I get the argument to have compatibility for self-built versions, and
I could see a point, where we make a switch for a certain library to have a
compatibility mode. But I am not sure if this should be the way forward in
this case. Much rather have the nuisance to compile a more recent version
together with Wireshark, than have one more thing to support

regards
Roland

Am Do., 29. Sept. 2022 um 15:03 Uhr schrieb Jeff Morriss <
jeff.morriss...@gmail.com>:

> Also keep in mind that if RHEL decides to fix the CVE(s) in question in
> version 8 of their OS, they would likely apply the fix for the CVE to the
> version of CARES that they are 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:59 AM Anders Broman 
> wrote:
>
>> 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 skrev Roland Knall :
>>
>>> 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, Roland
>>>
>>> Am 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 for
>>>> CMake Error at
>>>> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
>>>>   Could NOT find CARES: Found unsuitable version "1.13.0", but required
>>>> is at
>>>>   least "1.14.0" (found /usr/lib64/libcares.so)?
>>>> I would like to build for CentOS8...
>>>>
>>>
>>> It doesn't actually need anything from 1.14.0, so changing the line in
>>> CMakeLists.txt that sets the minimum version should be fine. Look at the
>>> commit below and change one line to 1.13.0
>>>
>>>
>>> https://gitlab.com/wireshark/wireshark/-/commit/5991a75d78a31ba61de6c162c79c2928da19c302
>>>
>>> John
>>>
>>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 forCMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):  Could NOT find CARES: Found unsuitable version "1.13.0", but required is at  least "1.14.0" (found /usr/lib64/libcares.so)?I would like to build for CentOS8...It doesn't actually need anything from 1.14.0, so changing the line in CMakeLists.txt that sets the minimum version should be fine. Look at the commit below and change one line to 1.13.0https://gitlab.com/wireshark/wireshark/-/commit/5991a75d78a31ba61de6c162c79c2928da19c302John

___Sent via:    Wireshark-dev mailing list Archives:    https://www.wireshark.org/lists/wireshark-devUnsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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
required - solution, but do we really need to be perfect here?

In my experience, as long as we can solve the real issue - the zombie
processes - and have minimal interaction by the creators of the original
extcaps we should be fine. Now as I understand it, we can achieve that at
some level with one of the proposed solutions above, just not in an ideal
way, right?

I am fine with having developers adapt their script, as long as there is
some form of compatibility mode, and maybe some warning displayed before
starting a non-converted extcap

kind regards
Roland


Am Di., 23. Aug. 2022 um 10:38 Uhr schrieb Tomasz Moń :

> On Mon, Aug 22, 2022 at 9:37 PM Jirka Novak  wrote:
> > >> What do you think about that options?
> > >
> > > I have no idea why you didn't even consider sending CTRL_BREAK_EVENT
> > > using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on
> > > Windows. Wireshark creates all extcaps with a hidden console window
> > > (CREATE_NEW_CONSOLE and SW_HIDE flags set).
> > >
> > > CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only
> > > requires calling SetConsoleCtrlHandler() to register a handler. The
> > > handler will be called in separate thread (unlike UNIX signals), but
> > > the issues related to the separate thread are exactly the same in any
> > > of the three methods you proposed. Registering handler is really an
> > > opt-in, as the default handler simply terminates the process.
> >
> > I'm sorry, my understanding was it is in !2063. I was wrong, I will try
> it.
>
> The problem with GenerateConsoleCtrlEvent() is that the caller has to
> be attached to the target process console. While we could technically
> do so, it requires freeing any already open console because process
> can be attached to at most one console. The pretty much only sane
> solution to the problem is to have a helper program between Wireshark
> and extcap.
>
> The helper would simply spawn extcap with provided parameters and
> accept commands from Wireshark e.g. on pipe. The commands would be to
> gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully
> terminate (TerminateProcess()). Note that the helper must not be
> forcefully terminated as it would leave the extcap running.
>
> While far from ideal, I think the helper is the only sensible
> approach. Note that GLib gspawn-win32-helper does something different,
> so going back to the GLib helper is not what this is all about.
>
> Best Regards,
> Tomasz Moń
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt6 default for -dev tree

[Roland Knall]

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
using Qt6 as default. That changed today, and Qt6 is now the default
instead of Qt5 for new builds.

You are still able to build with Qt5, and we will continue to support that
throughout 4.0 and future releases. To enable builds for Qt5, just reverse
the parameter above and use -DUSE_qt6=OFF (which coincidently should be
part of your configuration if you build over the past few months anyhow).

The rc for Windows & macOS are already Qt6, our internal builds for most
Linux distros still rely on Qt5. This will likely change over the course of
the coming months as well.

One final note. Qt sees 6.3.x as a compatibility step, meaning that with Qt
6.4 some things become obsolete. If you have warnings treated as errors
(the default option in Wireshark), you are currently not able to build
using the Qt 6.4 beta. Just disable the warning for now, or wait until the
adaptions are finished. As Qt 6.4 has not left beta-state yet and no rc had
been released no changes have been made on our side as of yet, as this may
change until the -rc versions are here.

kind regards
Roland
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 the API call. 

1) is not an option. We have extcaps implemented in C, Python, Powershell, 
Delphi, Go, I even know of one implemented as windows batch script. Only a 
limited version of them would be able to implement the window reliably. Also, 
the general idea for extcap utilities is, that they are universally usable 
across platforms, this dependency is a bit too much. 

So it is either between 2) or 3) and from my POV we should choose the option 
the promises to be more reliable, no matter about changing the extcap side of 
things. 

One thing though. Whatever the solution, we should try to provide a „don’t 
care“ mode. Otherwise most developers will have to die be into cross-Plattform 
development stuff, and as most external extcaps I know about are written by 
sysadmins or internal devs for very specific usecases, I fear that might turn 
people off from using the api in the first place. 

Cheers
Roland

> Am 21.08.2022 um 15:53 schrieb Jirka Novak :
> 
> Hi,
> 
>>> On Sat, Aug 6, 2022 at 1:09 PM Jirka Novak  wrote:
>>>Extcap API:
>>> i)  When extcap is started, dumpcap pass name of pipe to it and where it
>>> expects captured data.
>>> ii)  STDOUT/STDERR is used to report messages/errors of extcap to
>>> wireshark, but it is shown/evaluated at the end of capture which
>>> triggers e.g. #17827. STDIN is closed/not used.
>> STDOUT/STDERR is now (!7673 [1]) read during capture. STDOUT is
>> ignored, like it always was. STDERR is collected for later use.
> 
> It works, thank you.
> 
>>>Now I want to implement graceful shutdown. I mean that wireshark
>>> notify extcap it should end, cleanup and terminates. If extcap do not
>>> finish graceful shutdown in time (timer), it is killed as before.
> 
> I checked latest changes in master and I made additional research... I see 
> multiple options how to implement graceful shutdown and I propose we should 
> agree on common direction or at least discuss options.
> 
> Lets split the issue in two parts - *nix like systems and Windows/Win32 API.
> 
> For *nix like systems changes from !7673 works fine. SIGTERM is send 30 
> seconds before SIGKILL is sent. So extcap has 30 seconds for graceful 
> shutdown. If the shutdown is faster than 30 seconds, it makes no issue to 
> wireshark (no 30 seconds UI hang or so).
> If extcap do not require graceful shutdown or do not support it, SIGTERM is 
> not handled and it will kill extcap immediately.
> 
> In !5489 I made extcap/extcap-base.[ch] library calls which allows any C 
> based extcap to use it. But I plan to extract it to different MR...
> 
> For Windows/Win32 we still have no solution. There are two MRs -
> !2063 and !5489.
> 1) !2063 tries to use Win32 WM_CLOSE signal.
> 2) !5489 tries to use named pipe to pass information from wireshark to extcap 
> (same way as wireshark controls dumpcap nowadays).
> 3) I'm non Win32 specialist, but it looks there is another option - Windows 
> Event Objects (see 
> https://docs.microsoft.com/en-us/previous-versions/ms811896(v=msdn.10)?redirectedfrom=MSDN#ucmgch09_topic3)
> 
> My thoughts...
> 
> I think that *nix part is solved, just extcap side library is missing. We 
> must focus on Windows part.
> 
> My goal is to prepare library calls (at least for C) which will hide details 
> for developer and there will be just callback and/or global flag that extcap 
> should finish its work. Extcap author can use it if graceful shutdown is 
> required.
> 
> 1) Looks limiting to me, because my understanding is that it requires that 
> extcap must create hidden window to be able to receive WM_xxx signals.
> I'm afraid it can be limiting/additional complexity for extcaps. I can't 
> evaluate whether it has any other consequences for extcap code.
> 
> 2) It works, but it requires change how command line is parsed, because name 
> of named pipe must be passed to extcap. !5489 implements it as new pipe even 
> there are control pipes which are already processed by API. Patch can be 
> modified in that area.
> Library for C is proposed and it automates cli parsing.
> 
> 3) It makes sense to me even I didn't tried it yet. My understanding of 
> documentation is that 3) is more preferred in Win32 world.
> I see important that name of event must be agreed between wireshark and 
> extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every 
> extcap including ones called from different wireshark application. I think it 
> should not work this way.
> Name of Event can be new parameter for extcap, but it requires cmd line 
> change.
> We can try to derive name of Event from filename/pipe to which extcap writes 
> output. It is different value for every wireshark/extcap combination. It 

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

[Roland Knall]

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 places and we shouldn’t force a 
change everywhere because of it. 

Can also see, that that would be neat with some opposition. So in general, 
although I appreciate having new files apply to style guides, I would keep the 
existing ones as is

Cheers,
Roland

> Am 01.03.2022 um 19:23 schrieb João Valverde :
> 
> On 01/03/22 17:45, David Perry wrote:
>> Hi all,
>> 
>> Bottom line up front: how much do people care about the formatting of 
>> Wireshark's source code?
> I would like to have indentation harmonized (and enforced consistently) 
> across the entire C code base. Preferably 4-space.
> 
> Don't care so much about other style issues. I don't think that needs to be 
> enforced.
> 
>> Background: I'm looking into [#17253][1]. It's chiefly about removing editor 
>> modelines from the footer of each source file in favour of just using 
>> `.editorconfig` files. But by extension it's also about removing the 
>> exceptions from `.editorconfig` files and making the formatting rules 
>> consistent across files.
>> 
>> I took a manual pass at harmonizing the formatting of the C files in the 
>> root of the repo and that was painful, so I researched automatic approaches 
>> for the rest of our code. [Clang-Format][2] seems to be a popular approach 
>> for this sort of thing.
>> 
>> Automatic code formatters in general, and clang-format in particular, are 
>> rigid and somewhat naïve in how they do things. This is in contrast to the 
>> flexible formatting practices we use. That's not a huge deal if we just want 
>> to reformat once to harmonize our indentation levels and whatnot, and then 
>> return to manually formatting based on the new standard.
>> 
>> On the other hand, a comment on !6298 suggested that automatic reformatting 
>> could be integrated as a pre-commit hook and/or a CI step. That... also 
>> isn't a huge deal, I guess. We'd have consistency across files at the price 
>> of slightly less formatting freedom. (And of having another developer 
>> prerequisite to install, if we did it as a pre-commit hook.)
>> 
>> But it's a decision that should be made by the dev community as a whole. So 
>> what do you folks think? Is consistent formatting important to you? Would 
>> you like to see it enforced with an automatic formatter?
>> 
>> (My proposed `.clang-format` file is in [!6298][3] and aims to capture the 
>> most common practices used across the codebase. Please use that MR for 
>> discussions about specific formatting details. This email is for the general 
>> discussion of whether/how to apply and enforce formatting.)
>> 
>> Thanks for your time,
>> 
>> David Perry
>> he/him
>> 
>> [1]: https://gitlab.com/wireshark/wireshark/-/issues/17253
>> [2]: https://releases.llvm.org/13.0.1/tools/clang/docs/ClangFormat.html
>> [3]: https://gitlab.com/wireshark/wireshark/-/merge_requests/6298
>> ___ 
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

Which was used in the past, but that function has other issues (opening the 
users documents if the trace file path contains spaces)

I am looking into it. Empty StringList seems to solve it, but had not been able 
to test it properly yet

Cheers

> Am 11.02.2022 um 11:35 schrieb Graham Bloice :
> 
> 
> From the online Qt docs:
> bool QProcess::startDetached(const QString )
> 
> This function is obsolete. It is provided to keep old source code working. We 
> strongly advise against using it in new code.
> 
> Hence the MSVC warning, C4996 for a function that's marked as deprecated.  
> According to the Qt docs you should be using the more extensive overload:
> bool QProcess::startDetached(const QString , const QStringList 
> , const QString  = QString(), qint64 *pid = 
> nullptr)
> 
> and you'll have to provide the arguments parameter, even 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
>> 
>>  
>> 
>> From: Roland Knall  
>> Sent: den 11 februari 2022 11:12
>> To: Developer support list for Wireshark 
>> Cc: Anders Broman 
>> Subject: 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 
>> :
>> 
>> Hi,
>> 
>> Just built and got the following warning:
>> 
>>  
>> 
>>  ..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning C4996: 
>> 'QProcess::startDetached': Use QProcess::startDetached(const QString 
>> , const QStringList ) instead 
>> [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>> 
>>..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning C4996: success = 
>> QProcess::startDetached(command); 
>> [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>> 
>>..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning C4996:
>>  ^ [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>> 
>>  
>> 
>> 1 Warning(s)
>> 
>>  
>> 
>> Regards
>> 
>> Anders
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> 
> -- 
> Graham Bloice
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 QProcess::startDetached(const QString
> , const QStringList ) instead
> [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>
>..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning C4996: success
> = QProcess::startDetached(command);
> [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>
>..\ui\qt\utils\qt_ui_utils.cpp(208,25): warning
> C4996: ^
> [C:\Development\wsbuild64\ui\qt\qtui.vcxproj]
>
>
>
> 1 Warning(s)
>
>
>
> Regards
>
> Anders
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 this properly.
> Chuck, feeling up to it? ;)
>
> Thanks,
> Jaap
>
>
> On 1 Feb 2022, at 12:18, Erik Hjelmvik  wrote:
>
> Thank you Guy and Chuck!
>
> Adding a Pipe interface with the path "TCP@127.0.0.1:57012" worked, and
> so did running "wireshark -k -i TCP@127.0.0.1:57012"! I've now verified
> that this feature can be used to read PCAP from a TCP socket in both
> Windows and Linux. This is exactly what I was hoping for! Replacing
> 127.0.0.1 with localhost didn't work for some reason though. I just get an
> error message saying that "TCP@localhost:57012" is not a valid socket
> specification.
>
> I was delighted to see that tshark also reads the pcap stream nicely when
> I run it like this:
> tshark -i TCP@127.0.0.1:57012
>
> I've also verified that I can read the PCAP stream from a remote IP
> instead of just 127.0.0.1.
>
> Thank you for your great work!
>
> Den tis 1 feb. 2022 kl 04:28 skrev chuck c :
>
>> https://wiki.wireshark.org/CaptureSetup/Pipes.md#tcp-socket
>>
>> "A TCP stream is treated as like data from other pipes and the same
>> restrictions apply.
>> On each new connection the TCP server must send the header blocks as
>> specified by libpcap or pcapng before any packet captures.
>> TCP@ pipes may also be added in the GUI's Menu Capture/Options…, Manage
>> Interfaces…, Pipes Tab, but pipe settings are not saved by Wireshark."
>>
>> On Mon, Jan 31, 2022 at 6:19 PM Guy Harris  wrote:
>>
>>> On Jan 31, 2022, at 4:56 AM, Erik Hjelmvik 
>>> wrote:
>>>
>>> > Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP
>>> stream over a TCP socket.
>>> >
>>> > Currently, the best solution to read PCAP-over-IP in Wireshark is by
>>> using netcat to read the PCAP stream and forward it to Wireshark's STDIN
>>> like this:
>>> > nc localhost | wireshark -k -i -
>>>
>>> So this means "stream a pcap file to Wireshark and have it read it as a
>>> live capture".
>>>
>>> Wireshark - well, dumpcap, which does the capturing - has supported
>>> capturing from a pipe for a while.
>>>
>>> Support for capturing from a TCP socket was added at some point; the man
>>> page doesn't document it all that well:
>>>
>>>−i|−−interface  |rpcap://:/>>interface>|TCP@:|−
>>>
>>>Set the name of the network interface or pipe to use for live
>>>packet capture.
>>>
>>>Network interface names should match one of the names listed
>>> in
>>>"dumpcap −D" (described above); a number, as reported by
>>> "dumpcap
>>>−D", can also be used. If you’re using UNIX, "netstat −i",
>>>  ied,
>>>"ifconfig −a" or "ip link" might also work to list interface
>>> names,
>>>although not all versions of UNIX support the −a option to
>>>ifconfig.
>>>
>>>If no interface is specified, Dumpcap searches the list of
>>>interfaces, choosing the first non−loopback interface if
>>> there are
>>>any non−loopback interfaces, and choosing the first loopback
>>>interface if there are no non−loopback interfaces. If there
>>> are no
>>>interfaces at all, Dumpcap reports an error and doesn’t start
>>> theg
>>>capture.
>>>
>>>Pipe names should be either the name of a FIFO (named pipe)
>>> or "−"
>>>to read data from the standard input. On Windows systems,
>>> pipe
>>>names must be of the form "\\pipe\.*pipename*". Data read from
>>>pipes must be in standard pcapng or pcap format. Pcapng data
>>> must
>>>have the same endianness as the capturing host.
>>>
>>> It mentions "TCP@:" in the line describing the interface,
>>> but doesn't say what it means.
>>>
>>> So try
>>>
>>> wireshark -k -i TCP@localhost:57012
>>>
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: 

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

[Roland Knall]

That usecase is exactly what extcap was invented for. In your case, there
could be a small python or c application on the hosts side, which handles
the pipe management. Extcap is - in its essence - just a neat user
interface for configuring such pipe scenarios. So in your case, you could
provide your users with an extcap python, which can be locally installed
and handles the situation of capturing from the remote interface.

Sadly, that will require code to be written, out-of-the-box solutions
beyond sshdump/udpdump do not exist

Am Mo., 31. Jan. 2022 um 21:56 Uhr schrieb Erik Hjelmvik <
erik.hjelm...@gmail.com>:

> Thanks for the feedback Roland!
>
> sshdump is indeed a neat way to capture packets from a remote machine. But
> I'm afraid that extcap solution isn't quite what I'm looking for either. I
> should have explained more in detail what I'm trying to achieve, so that
> you folks would't have to guess. I primarily use PCAP-over-IP to
> read decrypted TLS packets from PolarProxy, for example as in these two
> examples:
> * Ingesting packets from PolarProxy to Arkime:
> https://netresec.com/?b=20C3247
> * Live extraction of TLS encrypted data in Windows:
> https://netresec.com/?b=221d46b
>
> One option would be to implement an additional packet export feature to
> PolarProxy, which transmits decrypted packets over ERSPAN or wrapping the
> packets in UDP, so that they can be parsed with udpdump. However, I'm a bit
> reluctant to adding new features unless there is a real need for them. What
> I'd like to achieve in the end is for Wireshark/tshark to be able to parse
> decrypted traffic from PolarProxy in near-real time. Any suggestions or
> ideas that you might have on how we can make PolarProxy+Wireshark work
> better together are welcome!
>
> PS: I actually did a live TLS decryption demo at the SEC-T conference in
> 2019, which was recorded and posted here:
> https://www.youtube.com/watch?v=lVS0DHjgpKc
>
> In this demo I simply pushed the decrypted PCAP stream from PolarProxy 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 jan. 2022 kl 20:39 skrev Roland Knall :
>
>> 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 simple capture device on the host pc.
>>
>> Roland
>>
>> Am Mo., 31. Jan. 2022 um 19:53 Uhr schrieb Erik Hjelmvik <
>> erik.hjelm...@gmail.com>:
>>
>>> Hi Dario,
>>>
>>> Udpdump looks interesting, but I'm afraid it doesn't quite fulfill my
>>> requirements. Wrapping captured packets inside of UDP packets or IP packets
>>> (as in ERSPAN) to allow remote sniffing is an attractive solution, but it
>>> comes with several drawbacks. Some of these drawbacks include difficulties
>>> in handling captured packets that exceed the MTU between sniffer and
>>> collector, how to preserve timestamps from the original capture source etc.
>>> Transmitting packets over a TCP connection has a few drawbacks as well, but
>>> it's a method that has served me very well over the years.
>>>
>>> As of now, I'd say that the primary drawback of using PCAP-over-IP
>>> (which really should be called  "PCAP-over-TCP") is that Wireshark/tshark
>>> can't read this data natively without having to use netcat as a shim
>>> between the TCP socket and Wireshar/tshark. I was hoping that there was an
>>> extcap solution for this, but I'm guessing I might be out of luck there :(
>>>
>>> /erik
>>>
>>> Den mån 31 jan. 2022 kl 14:02 skrev Dario Lombardo :
>>>
>>>> You can have a look at udpdump, which doesn't use TCP but UDP, but it
>>>> may fit your purpose.
>>>>
>>>> On Mon, Jan 31, 2022 at 1:57 PM Erik Hjelmvik 
>>>> wrote:
>>>>
>>>>> Hello folks,
>>>>>
>>>>> Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP
>>>>> stream over a TCP socket.
>>>>>
>>>>> Currently, the best solution to read PCAP-over-IP in Wireshark is by
>>>>> using netcat to read the PCAP stream and forward it to Wireshark's STDIN
>>>>> like this:
>>>>> nc localhost 57012 | wiresha

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

[Roland Knall]

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 simple capture device on the host pc.

Roland

Am Mo., 31. Jan. 2022 um 19:53 Uhr schrieb Erik Hjelmvik <
erik.hjelm...@gmail.com>:

> Hi Dario,
>
> Udpdump looks interesting, but I'm afraid it doesn't quite fulfill my
> requirements. Wrapping captured packets inside of UDP packets or IP packets
> (as in ERSPAN) to allow remote sniffing is an attractive solution, but it
> comes with several drawbacks. Some of these drawbacks include difficulties
> in handling captured packets that exceed the MTU between sniffer and
> collector, how to preserve timestamps from the original capture source etc.
> Transmitting packets over a TCP connection has a few drawbacks as well, but
> it's a method that has served me very well over the years.
>
> As of now, I'd say that the primary drawback of using PCAP-over-IP (which
> really should be called  "PCAP-over-TCP") is that Wireshark/tshark can't
> read this data natively without having to use netcat as a shim between the
> TCP socket and Wireshar/tshark. I was hoping that there was an extcap
> solution for this, but I'm guessing I might be out of luck there :(
>
> /erik
>
> Den mån 31 jan. 2022 kl 14:02 skrev Dario Lombardo :
>
>> You can have a look at udpdump, which doesn't use TCP but UDP, but it may
>> fit your purpose.
>>
>> On Mon, Jan 31, 2022 at 1:57 PM Erik Hjelmvik 
>> wrote:
>>
>>> Hello folks,
>>>
>>> Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP
>>> stream over a TCP socket.
>>>
>>> Currently, the best solution to read PCAP-over-IP in Wireshark is by
>>> using netcat to read the PCAP stream and forward it to Wireshark's STDIN
>>> like this:
>>> nc localhost 57012 | wireshark -k -i -
>>>
>>> But it would be much nicer if this data could be read directly without
>>> having to use netcat. Maybe as an extcap interface?
>>>
>>> Best regards,
>>> Erik
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>>
>> --
>>
>> Naima is online.
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

To be fair, there are two things to consider here. The status quo and the 
future direction. The second one should not be to develop those libraries 
independently. I totally agree with you that this should not be our scope. 

The status quo though is a different one. I do feel that we should bring the 
project into a direction, where it no longer needs to be considered, but this 
should be done carefully like you did in the past. We could break harder if we 
come up to the next major release. 

We could start a talk, if the next version in the summer should be such a 
release and if it would be opportun to change some bigger things that bother 
us. E.g. default settings or default layouts for example. And with such a 
discussion I would also argue that we could have a discussion about the 
expected contents of our packages

Cheers
Roland

> Am 22.01.2022 um 14:05 schrieb João Valverde :
> 
> Regarding questions I would like to know if is Wireshark is developed, 
> including each of the three existing libraries, for other projects to add as 
> dependencies to their software stack. It is possible I need to adjust my 
> understanding and expectations accordingly, and I will do so.
> 
> External plugins developed independently are not really relevant to this 
> discussion. Plugins are not independent projects in a technical sense, they 
> depend on Wireshark as a whole and not only any particular Wireshark library.
> 
> If we wanted to release system shared libraries, in the style of libpcap like 
> Balint intends, I think it would be important to split them out of the main 
> repo, with their own build system, lifecycle, clearly defined purpose, 
> versioning, API/ABI policy, release cadence, etc. It would also be important 
> to restructure the source tree, at a minimum to add an include folder for 
> each library.
> 
> This would be how to develop, maintain and release a library properly, in my 
> opinion. That's why I said in the Gitlab issue a shared library should be 
> implemented bottom up and not the other way around, like it was done here.
> 
>> On 20/01/22 20:34, Gerald Combs wrote:
>> If I understand the discussion in issue 17822 and here, we're looking at the 
>> following questions (feel free to correct me where needed):
>> 
>> Q: Should we commit to a stable ABI between minor releases?
>> 
>> I think everyone agrees that we should, or at least that it's a worthwhile 
>> goal.
>> 
>> Q: Should *wsutil* be part of that stable ABI?
>> 
>> Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat it 
>> as such. It would be helpful to know what non-Wireshark packages depend on 
>> wsutil in those distributions and elsewhere.
>> 
>> Q: What's the best way to ensure stability?
>> 
>> That's a tricky one. We did so in the past using abi-compliance-checker, 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:
>>> 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 >>> <mailto:rkn...@gmail.com>>:
>>> 
>>> 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 3.4 until either 3.6 is fixed or the utility (which probably will 
>>> be done in this case).
>>> 
>>> I also think it is the right thinking to allow libraries and more 
>>> specifically ABI breaks between releases. But those should never occur in a 
>>> maintenance release, which is what happened here if I got the gist of it. 
>>> If the break would be between 3.4.x and 3.6.0 it would be fine by me. But 
>>> breaking between 3.6.0 and 3.6.1 should not happen. I consider this an 
>>> issue that must be fixed - but the change should most certainly happen with 
>>> a version beyond 3.6.
>>> 
>>> And just additionally my 2 cents. Please always consider that although 
>>> the download rates of Wireshark are mind-blowing and wonderful, the 
>>> adopti

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

[Roland Knall]

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
https://gitlab.com/wireshark/wireshark/-/merge_requests/5318 version
changes where backported in 3.6, which are only meant to be in 3.7 and
beyond (hence the reference in libwireshark0.symbols). Regardless of what
some may think of the ensuing discussion, as a general rule we do not
introduce library changes within release branches. For that reason alone
(and only for that reason) I would say that the change needs to be reversed.

Now for the validity of the overall change, I do think it is valid and
makes absolute sense. I also think that external programs should not expect
huge stability for our APIs as they may change anytime between major
releases. If it is within our scope and reason to avoid such changes or
dependencies we should try to do so. I also do think that ABI compatibility
should not be set in stone.

kind regards
Roland

Am Fr., 21. Jan. 2022 um 11:17 Uhr schrieb João Valverde :

>
>
> On 21/01/22 09:44, Bálint Réczey wrote:
> > Hi João,
> >
> > João Valverde  ezt írta (időpont: 2022. jan. 21., P, 1:14):
> >>
> >>
> >> On 20/01/22 12:41, Bálint Réczey wrote:
> >>> Hi All,
> >>>
> >>> João shared his opinion about the project's commitment to maintain
> >>> stable shared library ABI within stable branches:
> >>> https://gitlab.com/wireshark/wireshark/-/issues/17822
> >>>
> >>> I believe the current practice is reasonable and beneficial enough for
> >>> many parties to warrant the work, but I could be wrong.
> >>>
> >> I agree the current practice is reasonable and beneficial, and it is
> >> currently documented in README.Developer[1], chapter 7.3, to the best of
> >> my understanding and ability.
> > OK, great to hear that from you. I got the impression from the gitlab
> > comments that you had a different view.
> >
> >> Do you have changes you'd like to propose? I'll gladly go over those.
> > I'm happy with the the project's commitment to ABI stability and agree
> > with Gerald's proposal of trying to revive the abi-complicance-checker
> > test to help him in the final release checks. I may find time to
> > restore the changes after this discussion is settled.
> >
> > Since you are asking, I'd very much welcome less hostility from your
> > side than what I observed in [2] when I reported the ABI breakage.
> >
> > What triggered my email was that after I reported the ABI breakage you
> > made in the stable branch you refused to own and fix it [3] and even
> > after Gerald kindly stepped in with the fix [4] you kept arguing ([5]
> > [6] ...) and this made me tired and wondering if you really represent
> > the project's opinion as you seemed to believe.
>
> I don't mind the email. We do disagree on many things and what I said on
> the Gitlab issue is exactly what I meant. My lack of patience with you
> is entirely justified.
>
> >
> >> What I won't do, however, is maintain your package for you.
> > I maintain the package in Debian for the users and not particularly
> > for myself since I'm not using Wireshark in my profession as I used to
> > do.
> > In general I'm happy to accept help, but I think I've never asked for
> > your help specifically for that package and I note that I should not
> > ask in  the future either.
> >
> > The Debian packaging in the upstream repository, i.e. [7] serves a
> > different set of users, those who want to be closer to the latest
> > development of Wireshark and the packaging scripts are kept a bit
> > simpler. I intentionally don't make too many changes there to let the
> > Wireshark project members set the direction and the changes there go
> > through the regular local review process. I believe the packaging in
> > itself is useful and the .symbols files help noticing ABI changes.
> >
>
> I strongly believe the upstream Debian package to be a detriment to the
> project, and not in the interest of users either. I will share my
> experience as a user. I  had to build the Wireshark Debian package to
> fix something or other. I looked up online the incantation to use and it
> seemed to work ok. After it was done building it spewed a bunch of files
> all over my filesystem. Many different packages. I tried installing them
> one by one and didn't succeed. I tried all at once and didn't succeed
> either. I had to guess the order necessary to get it to install.
> Afterward there was some apt conflict with the Wireshark package in the
> official repos. I tried uninstalling the packages I had manually
> installed and broke the package manager with some dependency issue.
> After half an hour trying to fix it I gave up. The end.
>
> There is no good reason for this package to exist upstream in its
> current state, nor does Debian recommend that practice in general, AFAIK.
> 

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

[Roland Knall]

To be quite honest, I asked the developers myself. In this case they are a
group of students who implemented that utility and did not know better.
Personally I would much rather have new developments added to the main
repository than be implemented as standalone. And as Guy rightfully
guessed, the main reason for them doing it this way was to basically
provide a different UI for the dissection engine with a little bit
different output info. Hope that answers your question as well Joao. Not
saying it was correct doing it like this, just that it happened. Sadly,
this utility is used by quite a few people and will not get an update
anytime soon. The version I know of is maintained behind closed doors and
they are currently changing the sourcecode to adapt for the ABI change.

Just to clarify, I do not think that people should be using those
libraries. But it is a know issue that they do. 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 implemented by utilizing heavily a wireshark installation
> including libwireshark and libwsutil
>
> So why, *other than "because it uses Wireshark libraries intended to
> provide directly useful services such as reading capture files or
> dissecting packets and that use libwsutil"*, would some program outside of
> Wireshark use wsutil?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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
including libwireshark and libwsutil

Am Do., 20. Jan. 2022 um 21:52 Uhr schrieb Guy Harris :

> On Jan 20, 2022, at 12:34 PM, Gerald Combs  wrote:
>
> > Q: Should *wsutil* be part of that stable ABI?
> >
> > Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat
> it as such. It would be helpful to know what non-Wireshark packages depend
> on wsutil in those distributions and elsewhere.
>
> ...and, if there are any, to know *why*.
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 :

> 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 3.4 until either 3.6 is fixed or the utility (which probably will
> be done in this case).
>
> I also think it is the right thinking to allow libraries and more
> specifically ABI breaks between releases. But those should never occur in a
> maintenance release, which is what happened here if I got the gist of it.
> If the break would be between 3.4.x and 3.6.0 it would be fine by me. But
> breaking between 3.6.0 and 3.6.1 should not happen. I consider this an
> issue that must be fixed - but the change should most certainly happen with
> a version beyond 3.6.
>
> And just additionally my 2 cents. Please always consider that although the
> download rates of Wireshark are mind-blowing and wonderful, the adoption
> within companies might be even greater with special build versions. There
> exists many reasons for those versions, be it not enough resources
> available to bring changes to mainline or having code and adaptations which
> are for whatever (legal mostly) reasons not able to be publicly available.
> Changes like these i would see as a risk to those practices, and one of the
> reasons Wireshark has such a good standing within the community are our
> policies for long-time stability and maintainability.
>
> Just my own thoughts on this.
> cheers
> Roland
>
> Am Do., 20. Jan. 2022 um 13:42 Uhr schrieb Bálint Réczey <
> bal...@balintreczey.hu>:
>
>> Hi All,
>>
>> João shared his opinion about the project's commitment to maintain
>> stable shared library ABI within stable branches:
>> https://gitlab.com/wireshark/wireshark/-/issues/17822
>>
>> I believe the current practice is reasonable and beneficial enough for
>> many parties to warrant the work, but I could be wrong.
>>
>> Comments are welcome.
>>
>> Cheers,
>> Balint
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 3.4
until either 3.6 is fixed or the utility (which probably will be done in
this case).

I also think it is the right thinking to allow libraries and more
specifically ABI breaks between releases. But those should never occur in a
maintenance release, which is what happened here if I got the gist of it.
If the break would be between 3.4.x and 3.6.0 it would be fine by me. But
breaking between 3.6.0 and 3.6.1 should not happen. I consider this an
issue that must be fixed - but the change should most certainly happen with
a version beyond 3.6.

And just additionally my 2 cents. Please always consider that although the
download rates of Wireshark are mind-blowing and wonderful, the adoption
within companies might be even greater with special build versions. There
exists many reasons for those versions, be it not enough resources
available to bring changes to mainline or having code and adaptations which
are for whatever (legal mostly) reasons not able to be publicly available.
Changes like these i would see as a risk to those practices, and one of the
reasons Wireshark has such a good standing within the community are our
policies for long-time stability and maintainability.

Just my own thoughts on this.
cheers
Roland

Am Do., 20. Jan. 2022 um 13:42 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:

> Hi All,
>
> João shared his opinion about the project's commitment to maintain
> stable shared library ABI within stable branches:
> https://gitlab.com/wireshark/wireshark/-/issues/17822
>
> I believe the current practice is reasonable and beneficial enough for
> many parties to warrant the work, but I could be wrong.
>
> Comments are welcome.
>
> Cheers,
> Balint
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Visual Studio 2022

[Roland Knall]

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 2022"
> >
> https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
>
> "These Build Tools allow you to build Visual Studio projects from a
> command-line interface."
>
> Does that mean
>
> this is Visual Studio without the "Visual", i.e. it's all the
> command-line tools, but without the IDE
>
> or
>
> if you just install Visual Studio, you don't get the command-line
> tools - you also have to install this?
>
> The former sounds like "Command Line Tools for Xcode {version}" on macOS
> or "don't install any IDE" on the free-software UN*Xes (I don't know
> whether Oracle Studio offers that).
>
> The latter seems less likely, as I think most IDEs either run the
> compiler/linker/other tools directly or run some builder program (make,
> msbuild, etc.) that runs the compiler/linker/other tools, but I guess if
> the core of the compiler/linker are in libraries that the command-line
> tools link with and that an IDE program could link with as well (say hello,
> LLVM), it would be possible.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Visual Studio 2022

[Roland Knall]

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,
>> Yes sounds like a good idea. Have been contemplating testing it too.
> 
> I just installed the "Build Tools for Visual Studio 2022"
>  
> https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
> 
> But was disappointed it does not include a newer compiler.
> My 'cl.exe' (part of the "VS 2019") is still at version
> 19.29.30139.
> 
> So what's the point of using VS 2022 really?
> 
> -- 
> --gv
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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?
>
>
> https://github.com/nmap/npcap/commit/865c3d1811a0fb6c6369e863dde23a6fff09ddf8
>
>   Npcap is a Windows packet sniffing driver and library and is copyright
> - (c) 2013-2021 by Insecure.Com LLC ("The Nmap Project").  All rights
> + (c) 2013-2021 by Nmap Software LLC ("The Nmap Project").  All rights
>   reserved.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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.

Also, please test on Windows, as it behaves a little different from
Linux/mac in the case of pipes/standard pipes

Change is fine by me

regards
Roland

Am Mi., 1. Dez. 2021 um 14:36 Uhr schrieb Dario Lombardo :

> I'm ok with this change. I can give you direct support for the extcaps I
> wrote (sshdump/ciscodump, udpdump, randpktdump), and do my best with the
> others.
>
> On Wed, Dec 1, 2021 at 2:18 PM Jirka Novak  wrote:
>
>> Hi,
>>
>>   I noticed issue below and I propose a solution for it. Can I ask for
>> comments?
>>
>>   Every extcap tool has --debug and --debug-file options, but when they
>> are used, it do "nothing". File is created, but it is empty.
>>   Later I found that it must be used with --log-level=debug to really
>> log messages.
>>   The issue is that when you increase --log-level, it logs to console
>> (STDERR). So when extcap is started from Wireshark, it mixes log output
>> with packet data and wireshark gets confused and I found no way how to
>> make it operational.
>>   In other words you can't use debug of extcap from Wireshark.
>>
>>   In code I found that the reason is that wsutils/wscode.c writes every
>> message to STDERR. If application registers additional file, it is
>> copied to it too, but output to STDERR is made in every case.
>>   Applications can replace default writer to STDERR, but no extcap do it.
>>
>>   My proposal is to modify extcap/extcap-base.c:
>> 1) When --debug is used, set log level to debug so you don't have to add
>> --log-level
>> 2) If --log-file used, register custom log writer with
>> ws_log_init_with_writer() which will discard all messages so just write
>> to file will be made.
>> 3) Update log init in every extcap
>>
>>   Change is quite simple, but involves all extcaps. I already tested it
>> and it works. I'm just not sure every extcap.
>>   I'm ready to prepare patch.
>>
>> Best regards,
>>
>> Jirka
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Extcap Rust library

[Roland Knall]

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 Tomáš Kukosa :

> Hi,
>
> I have released small library to help writing extcap plugins in Rust
> See https://crates.io/crates/extcap
>
> The shortest example is shown here https://docs.rs/extcap/0.3.0/extcap/
> Few more real examples how to use it are also available in the repository.
>
> Best regards,
>   Tomas
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Parameters for extcap

[Roland Knall]

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, which was later superseded by using
the identity file, which can be stored normally.

As for empty values, we have no possibility to detect, if the empty value
you entered is the default one, or if it is a new set value. Therefore
empty was implemented as "return default value". One could argue, that
default values should only be used, if you reset the complete
configuration, but than you could not reset an individual configuration.

regards
Roland


Am Di., 30. Nov. 2021 um 00:54 Uhr schrieb Jirka Novak :

> Hi,
>
>   Wireshark is able to run external captures (extcap). Extcap tools can
> provide configuration description which Wireshark shows as dialog and
> stores in advanced properties.
>   I'm observing two strange things I understood as bug.
>
> 1) If the tools provides as type of setting 'password', it is not stored
> permanently. It is correct.
> The issue is, that password is not remembered over runtime. So if I run
> extcap twice in row, second run has empty password :-(
> I think it is related to #14221, but I think that it should remember
> password till application is closed.
>
> 2) If the tool provides default value for a setting, it is stored in
> preference. If I change the value, it is stored too. It is correct.
> The issue is, that if I clear the value to do not pass the value to
> extcap (it is not required), the empty value is not stored so next run
> default value is again used.
>
> Both issues are very annoying.
>
> My plan is to change it:
> - remember password during runtime
> - store empty values
>
> My worry is about storing empty values to preferences. I'm afraid that
> the framework uses empty value to remove settings from preference.
>
> Can I ask for comments and advices before I will proceed?
>
> Best regards,
>
> Jirka Novak
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 a little differently than capture interfaces, as such
it was meant as a management system for piped input, where you have either
a finite number of packets to send to wireshark or you have total control
over what to send. When you have sent all the information you wanted to
send, you simply exit the program. If Wireshark closes the pipe before, we
"should" cleanly exit due to the fact that dumpcap closes the control
stream and terminates the program execution, as we are running in a
child-thread. We have seen in the past, that this might not always happen
100%

kind regards
Roland

Am Sa., 27. Nov. 2021 um 22:51 Uhr schrieb Jirka Novak :

> Hi Roland,
>
> > 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 the pipe gets closed, end the extcap from the
> > extcap side.
>
> can you point me to place where pipes are controlled on extcap side? I
> see common framework there, but I'm not sure where the place is exactly...
>
> Thank you in advance,
>
> Jirka
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 the pipe gets closed, end the extcap from the
extcap side.

cheers
Roland

Am Sa., 27. Nov. 2021 um 22:29 Uhr schrieb Jirka Novak :

> Hi,
>
>   I'm working on ciscodump extcap.
>   The the application creates settings on Cisco device and when it ends,
> it clears settings.
>   The issue is that when capture is stopped during capture, the
> application is stopped and settings stays on Cisco device.
>
>   I added signal handling to ciscodump so when it is stopped from CLI,
> it cleanups as expected. I'm capturing TERM and INT signals. But it
> looks that when it is run from wireshark, application is terminated and
> signal is not thrown.
>   Can I ask someone to help me/explain how extcaps are stopped to adapt
> to it?
>
>   I know how unix signals works, I'm just missing information how
> wireshark terminates extcaps.
>
> Best regards,
>
> Jirka
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 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
> not locked in in the byteview.
>
> Bugfix inbound, and I don't think it needs to be configurable, as it
> actually solves the underlying issue
>
> cheers
> Roland
>
> Am Sa., 11. Sept. 2021 um 15:45 Uhr schrieb John Thacker <
> johnthac...@gmail.com>:
>
>> On Sat, Sep 11, 2021 at 7:23 AM Jaap Keuter 
>> wrote:
>>
>>> 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 where
>>> this particular bytes are from follows the mouse pointer. But I'm working
>>> the other way around, by first selecting a field in the packet details,
>>> then dive into the packet bytes, where I would like the selected field
>>> highlighting to remain, so I can navigate around while keeping my bearings
>>> in the packet.
>>>
>>> But I recon this will upset people. So putting it behind a preference
>>> would a the way to go. The the question becomes where to put that? Anyone a
>>> good idea?
>>>
>>
>> I would appreciate that, I have wished for that behavior myself. While
>> one option is just giving it a name so that people can only access it
>> through Preferences->Advanced, I think the most natural place is in
>> Appearance->Layout. There's already a section for Packet List settings
>> there, that includes a preference for "Enable mouse-over colorization." (
>> https://gitlab.com/wireshark/wireshark/-/blob/master/epan/prefs.c#L3377-L3380)
>> Perhaps add a "Packet Bytes settings" group and then the new preference.
>>
>> Cheers,
>> John Thacker
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[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 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
not locked in in the byteview.

Bugfix inbound, and I don't think it needs to be configurable, as it
actually solves the underlying issue

cheers
Roland

Am Sa., 11. Sept. 2021 um 15:45 Uhr schrieb John Thacker <
johnthac...@gmail.com>:

> On Sat, Sep 11, 2021 at 7:23 AM Jaap Keuter  wrote:
>
>> 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 where
>> this particular bytes are from follows the mouse pointer. But I'm working
>> the other way around, by first selecting a field in the packet details,
>> then dive into the packet bytes, where I would like the selected field
>> highlighting to remain, so I can navigate around while keeping my bearings
>> in the packet.
>>
>> But I recon this will upset people. So putting it behind a preference
>> would a the way to go. The the question becomes where to put that? Anyone a
>> good idea?
>>
>
> I would appreciate that, I have wished for that behavior myself. While one
> option is just giving it a name so that people can only access it through
> Preferences->Advanced, I think the most natural place is in
> Appearance->Layout. There's already a section for Packet List settings
> there, that includes a preference for "Enable mouse-over colorization." (
> https://gitlab.com/wireshark/wireshark/-/blob/master/epan/prefs.c#L3377-L3380)
> Perhaps add a "Packet Bytes settings" group and then the new preference.
>
> Cheers,
> John Thacker
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 builders available to everyone.
But if you submit your changes, we can trigger it for you.

Btw, as a Mac & Linux user myself, I keep a virtualbox around just for that
purpose. To be able to build Wireshark. It is not required, but certainly
helps. Also, building Wireshark on your local Linux machine with a clang
compiler instead of gcc, will also identify most issues with the Microsoft
VS compilers (as was my experience in the past)

kind regards
Roland

Am Mo., 13. Sept. 2021 um 11:17 Uhr schrieb Ivan Nardi :

> Hi
>
> If I am not wrong, the "Windows Build" job is triggered only after a
> maintainer picks up the MR and assigns it to the "Wireshark GitLab
> Utility".
> Is there any way I can trigger it myself?
>
> Some background.
> I don't have a Windows machine to build Wireshark myself.
> My last MR (https://gitlab.com/wireshark/wireshark/-/merge_requests/3628)
> triggers a warning only in the Windows build.
> I **think** to have a fix for it. I could push it, wait for a
> maintainer to pick it up again and cross my fingers...
> But if I could trigger the Windows test myself it should be less a
> bother to anyone.
> Can I do that somehow?
>
> I hope I made myself clear
> Thanks
>
> Ivan
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] remote interfaces issues

[Roland Knall]

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
> 
> https://gitlab.com/wireshark/wireshark/-/merge_requests/3986
> 
> 
> there are several bugs with the management of the remote interfaces and i 
> would like
> the fix some others if you merge this fix
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 abstract
> network descriptions for automotive buses and dissects the messages on the
> bus accordingly. But as every bus has a different set of message
> definitions,
>
> So is there a single LINKTYPE_ value for all those buses, or do they all
> have different LINKTYPE_ values?
>
> If so, what are the LINKTYPE_ values?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

You misunderstood. pt must contain the bytes you want to be inside the
subset. It seems, that you collect different bytes for this array as you
select for your hf_item selection which is then highlighted in the
packet-view

kind regard
Roland

Am Mi., 26. Mai 2021 um 14:39 Uhr schrieb Antonello Tartamo <
antonellotart...@gmail.com>:

> Hello pt is an array (uint8_t pt[16];).
> pt is an array generated after processing a part of the packet.
> As I've created a new tvb the offset is 0 and the length is 16.
>
> Hope I've answered your questions.
>
>
>
> Il giorno 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 you using the same
>> length and start offset as for the hf item?
>>
>> regards
>> Roland
>>
>> Am Mi., 26. Mai 2021 um 08:46 Uhr schrieb Antonello Tartamo <
>> antonellotart...@gmail.com>:
>>
>>> Hello everyone,
>>> I'm trying to add a custom item which is not strictly related to the
>>> packet but it is coming from a processing of a part of the packet.
>>> I've used the following instructions:
>>>
>>> new_tvb = tvb_new_child_real_data(tvb, pt, (guint)16,
>>> 16);
>>> add_new_data_source(pinfo, new_tvb, "processed");
>>>
>>> ti = proto_tree_add_item(data_tree,
>>> hf_mp_control_processed, new_tvb, 0, 16, ENC_NA);
>>> PROTO_ITEM_SET_GENERATED(ti);
>>>
>>> hf_mp_control_processed is a set of bytes:
>>> { & hf_mp_control_processed ,
>>>   { "mp control processed", "mp.control.processed",
>>> FT_BYTES, BASE_NONE, 0x0, 0x0,
>>> NULL, HFILL }
>>> }
>>>
>>> The problem is that when I click on this new item into the Packet
>>> Details I see the correct byte values, while in the Packet Bytes view these
>>> ones are totally wrong.
>>>
>>> Attached image:
>>> [image: image.png]
>>> For example the first byte is 0x48 but 0x68 is shown in the Packet Bytes
>>> view.
>>>
>>> Is there a different way to perform this operation ?
>>>
>>> Thanks in advance
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 2021 um 08:46 Uhr schrieb Antonello Tartamo <
antonellotart...@gmail.com>:

> Hello everyone,
> I'm trying to add a custom item which is not strictly related to the
> packet but it is coming from a processing of a part of the packet.
> I've used the following instructions:
>
> new_tvb = tvb_new_child_real_data(tvb, pt, (guint)16, 16);
> add_new_data_source(pinfo, new_tvb, "processed");
>
> ti = proto_tree_add_item(data_tree,
> hf_mp_control_processed, new_tvb, 0, 16, ENC_NA);
> PROTO_ITEM_SET_GENERATED(ti);
>
> hf_mp_control_processed is a set of bytes:
> { & hf_mp_control_processed ,
>   { "mp control processed", "mp.control.processed",
> FT_BYTES, BASE_NONE, 0x0, 0x0,
> NULL, HFILL }
> }
>
> The problem is that when I click on this new item into the Packet Details
> I see the correct byte values, while in the Packet Bytes view these ones
> are totally wrong.
>
> Attached image:
> [image: image.png]
> For example the first byte is 0x48 but 0x68 is shown in the Packet Bytes
> view.
>
> Is there a different way to perform this operation ?
>
> Thanks in advance
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 lots of 'TCP Window fulls' detected from the server end.
>
> I tried with ethernet plugged directly  into my home router, but the
> outcome was the same.  Also disabled company VPN.
>
> Martin
>
> On Wed, May 19, 2021 at 2:21 PM Jim Young  wrote:
>
>> Hello Martin,
>>
>> On Wed, May 19, 2021 at 7:09 AM Martin Mathieson via Wireshark-dev
>>  wrote:
>> > ... when I try to clone it starts to go through the stages (i.e.
>> counting/compressing/ receiving objects/resolving objects) I am told
>> 'Connection to gitlab.com closed by remote host' ...
>> >
>> > Any ideas?
>>
>> Have you made a pcap? ;-)
>>
>> Seriously it might give you a clue as to what side may be responsible
>> for the issue.
>>
>> Several years ago (~April thru June 2017) I was having intermittent
>> problems simply doing a `git pull`. At times I would have to retry the
>> `git pull` a dozen times or more before it would complete
>> successfully. A client side packet capture showed that my machine was
>> receiving TCP RSTs purportedly generated by the git server. These TCP
>> RSTs had an IP TTL value one higher than the other TCP packets from
>> the `git pull` conversation. The IP TTL value in the RST packets
>> implied some middle box was responsible for synthesizing the TCP RSTs.
>> Interestingly there were lots of TCP RSTs, but most of them were
>> "benign". The benign RSTs did not cause the TCP session to stop
>> prematurely because the TCP sequence number in the RST packets were
>> apparently "too old" (had already been acknowledged) and were
>> ultimately ignored by the TCP stack. But occasionally these TCP RSTs
>> would actually cause the TCP connection to fail and the git client
>> would ultimately time out. I managed to contact the git server admin
>> ;) and we coordinated a packet trace on the server side. We determined
>> that a middle box would generate the TCP RSTs when the git client's
>> TCP packets arrived out-of-order. A config change was made on the
>> middle box to its tcp connection tracking which ultimately resolved
>> the intermittent `git pull` issues.
>>
>> Best regards,
>>
>> Jim Y.
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 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 disabled, see CMakeOptions.txt for a
>> list, but Qt Multimedia Lib cannot be disabled easily.
>>
>> If you look at cmakeconfig.h.in:
>> <https://gitlab.com/wireshark/wireshark/-/blob/master/cmakeconfig.h.in#L320>
>>
>> /* Define to the version of this package. */
>> #cmakedefine PACKAGE_VERSION
>>
>> /* Define if we have QtMultimedia */
>> #define QT_MULTIMEDIA_LIB 1
>>
>> /* Define if we have QtMacExtras */
>> #cmakedefine QT_MACEXTRAS_LIB 1
>>
>> You will see that QT_MULTIMEDIA_LIB is always defined.
>>
>> If you *both* change that line to
>>
>> #cmakedefine QT_MULTIMEDIA_LIB 1
>>
>> *and*
>>
>> comment out Qt5Multimedia from CMakeLists.txt
>> <https://gitlab.com/wireshark/wireshark/-/blob/master/CMakeLists.txt#L1179>
>>
>> and then rerun cmake (possibly after removing config.h and build.ninja or
>> your Makefile from the build directory),
>> then you can build without QT_MULTIMEDIA_LIB being set. On the current
>> master, when doing so, I get the following build error:
>>
>> In file included from
>> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/rtp_stream_dialog.h:16,
>>  from
>> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/main_window.h:78,
>>  from
>> ui/qt/qtui_autogen/EWIEGA46WW/moc_main_window.cpp:10,
>>  from ui/qt/qtui_autogen/mocs_compilation.cpp:65:
>> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/rtp_player_dialog.h:27:10:
>> fatal error: QAudioDeviceInfo: No such file or directory
>>27 | #include 
>>   |  ^~
>>
>> Because QAudioDeviceInfo is part of Qt Multimedia but not properly
>> protected by that #ifdef, which is exactly what you're trying to test.
>>
>> John Thacker
>>
>>
>> On Mon, Apr 26, 2021, 5:03 AM Jirka Novak  wrote:
>>
>>> Hi,
>>>
>>>   I would like to test whether #ifdef QT_MULTIMEDIA_LIB are correct in
>>> source code so I need to disable it during cmake detection. Is there
>>> something like there was --nofeature in autoconfigure?
>>>
>>> Best regards,
>>>
>>> Jirka
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 disabled, see CMakeOptions.txt for a list,
> but Qt Multimedia Lib cannot be disabled easily.
>
> If you look at cmakeconfig.h.in:
> 
>
> /* Define to the version of this package. */
> #cmakedefine PACKAGE_VERSION
>
> /* Define if we have QtMultimedia */
> #define QT_MULTIMEDIA_LIB 1
>
> /* Define if we have QtMacExtras */
> #cmakedefine QT_MACEXTRAS_LIB 1
>
> You will see that QT_MULTIMEDIA_LIB is always defined.
>
> If you *both* change that line to
>
> #cmakedefine QT_MULTIMEDIA_LIB 1
>
> *and*
>
> comment out Qt5Multimedia from CMakeLists.txt
> 
>
> and then rerun cmake (possibly after removing config.h and build.ninja or
> your Makefile from the build directory),
> then you can build without QT_MULTIMEDIA_LIB being set. On the current
> master, when doing so, I get the following build error:
>
> In file included from
> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/rtp_stream_dialog.h:16,
>  from
> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/main_window.h:78,
>  from ui/qt/qtui_autogen/EWIEGA46WW/moc_main_window.cpp:10,
>  from ui/qt/qtui_autogen/mocs_compilation.cpp:65:
> ui/qt/qtui_autogen/EWIEGA46WW/../../../../../wireshark/ui/qt/rtp_player_dialog.h:27:10:
> fatal error: QAudioDeviceInfo: No such file or directory
>27 | #include 
>   |  ^~
>
> Because QAudioDeviceInfo is part of Qt Multimedia but not properly
> protected by that #ifdef, which is exactly what you're trying to test.
>
> John Thacker
>
>
> On Mon, Apr 26, 2021, 5:03 AM Jirka Novak  wrote:
>
>> Hi,
>>
>>   I would like to test whether #ifdef QT_MULTIMEDIA_LIB are correct in
>> source code so I need to disable it during cmake detection. Is there
>> something like there was --nofeature in autoconfigure?
>>
>> Best regards,
>>
>> Jirka
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status label for issues

[Roland Knall]

It wasn't clear to me, that your list was the original list + new entries.

I have especially an issue with the new ws-status labels and their
transitions. Judging from a company, where we have about 50 developers
whose daily bread it is to transition properly in Jira, I cannot see an
open-source project with no additional tooling to properly transition
between e.g. unconfirmed => confirmed => in-progress.

That is my main concern.

Am Di., 27. Apr. 2021 um 08:44 Uhr schrieb Uli Heilmeier :

> Diff between current and proposal list:
>
> - incident
> - question
> - cli::tshark
> + ui::tshark
> - ui::gtk
> - version::0.x
> - version::1.0
> - version::1.10
> - version::1.12
> - version::1.2
> - version::1.4
> - version::1.6
> - version::1.8
> - version::2.0
> - version::2.2
> - version::2.4
> - version::2.6
> - version::3.0
> + version::outdated
> + ws-status::unconfirmed
> + ws-status::confirmed
> + ws-status::waiting-for-response
> + ws-status::in-progress
> + ws-status::invalid
> + ws-status::wontfix
> + ws-status::fixed
> + ws-status::duplicate
>
> I have no strong feelings 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 not convinced that they can be used properly and consistently
> at this point
> >
> > I would clean up the proposal list first, then from there figure out
> which items we need on the list
> >
> > cheers
> > Roladn
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status label for issues

[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 not convinced that
they can be used properly and consistently at this point

I would clean up the proposal list first, then from there figure out which
items we need 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.
> >
>
> I've created
> https://gitlab.com/wireshark/wireshark/-/wikis/Discussion-Issues-Labels
> to discuss labels for issues.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status label for issues

[Roland Knall]

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 we create a wiki page for that discussion first, and if we can
figure that out create the labels.

Also, I would limit the number of labels to as few as possible

kind regards
Roland

Am Sa., 24. Apr. 2021 um 13:33 Uhr schrieb Jirka Novak :

> Hi Uli,
>
> > For issues (especially bugs) I really miss the status field which was
> available with Bugzilla.
> >
> > Therefore I would like to create these scoped labels [1]:
> > ...
> >
> > Any objections? Comments are very welcome.
>
>   I agree with you. I'm missing this information about created issues too.
>   I propose one more kind of label/labels. It is more about interaction
> with reporter of the issue - "waiting for response". There are many
> issues opened for years where last message is request for sample or more
> information. I think that if such issue is opened for years with no
> reaction, it is useless and should be closed.
>
> Best regards,
>
> Jirka
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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.
> 
> How  is release selection made? Is it a cut-off date or manual choice?
> 
> 
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> Phone: +972-3-6897318 
> Fax:  +972-3-6897230
> 
> 
> 
> 
> From:Gerald Combs 
> To:wireshark-annou...@wireshark.org, Community support list for 
> Wireshark , Developer support list for 
> Wireshark 
> Date:04/21/2021 09:49 PM
> Subject:[EXTERNAL] [Wireshark-dev] Wireshark 3.4.5 is now available
> Sent by:"Wireshark-dev" 
> 
> 
> 
> I'm proud to announce the release of Wireshark 3.4.5.
> 
> 
>  What is Wireshark?
> 
>   Wireshark is the world’s most popular network protocol analyzer. It is
>   used for troubleshooting, analysis, development and education.
> 
>  What’s New
> .
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 
Roland

> Am 21.03.2021 um 15:53 schrieb Tomasz Moń :
> 
> On Sun, Mar 21, 2021 at 1:21 PM Martin Mathieson via Wireshark-dev
>  wrote:
>> Can an extcap program write to a wiretap-supported file format other than 
>> pcap or pcapng?  A quick test (hack to file preamble and frames in 
>> extcap_example.py) suggests not..
>> Has it to do with synchronising whole frames being read at the wireshark end 
>> of the pipe?
> 
> Currently extcap is inherently bound to pcap. Currently extcaps
> mention their DLT that determines link layer header type (as defined
> at [1]) when they are being called with --extcap-dlts argument. When
> you capture from extcap source, it is dumpcap that reads the pcap
> stream that is written to the pipe by extcap.
> 
> To make extcap support different file types would would need to:
>  * extend extcap interface with a method to let Wireshark know that
> the extcap in question does not output pcap data
>  * make dumpcap capable of at least passing the data from the pipe to 
> Wireshark
> 
> [1] https://www.tcpdump.org/linktypes.html
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

I was talking about live capture and how to generate statistic plugins for 
them. USER_DLTs will certainly work in that regard. 

regards 

> Am 27.01.2021 um 14:06 schrieb Björn 
> :
> 
> 
> Hello Roland,
> 
> thank you for your answer, but this will not work for me, because i need to 
> dissect 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 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 dissector to analyze custom protocol traffic. However, to 
>>> further increase the usability, we need to add protocol analysis specific 
>>> GUI elements. For now, we are not aware of a way to add a first level 
>>> plugin which can be called through an encapsulation type from a pcap file. 
>>> One other point is that we are not able to load a compiled plugin to 
>>> wireshark, if we don’t build it from source. We can’t link against 
>>> wireshark and cmake will not load the project if we install wireshark from 
>>> the APT packages.
>>> 
>>> Are implementations available to add an encapsulation type via a plugin?
>>> Could anybody point us to examples of similar attempts?
>>> Is there already some work in progress to provide such a plugin mechanism 
>>> for extending the encapsulation types?
>>> We noticed that distributed packets, e.g. in Ubuntu 18.04 do not allow for 
>>> C plugins to be loaded. Do you know if this is common practice?
>>> Our goal is creating an open source tool to analyze communication within 
>>> SoCs, e.g. SoC FPGAs by providing both insight into protocol structure as 
>>> well as bit and timing accurate analysis at the same time with 
>>> cross-references.
>>> You may think about this like an analyzer for video data transport 
>>> protocols, which provides the ability to cross-reference actual pixels 
>>> within the frames to the protocol entities that has contained them by 
>>> showing the picture and enables clicking through the pixels / areas of the 
>>> frames and the frames within the timeline of the video. When you click on 
>>> an images pixel/area, the respective protocol unit containing the pixel is 
>>> highlighted and vice versa. This allows for much better interpretation than 
>>> going through the payload view or the image separately.
>>> 
>>> We already built a proof of concept, but we feel that this approach to 
>>> basically create a fork of the wireshark GUI is neither maintainable and 
>>> efficient nor something the community is looking for.
>>> We are seeking for any comment/reply or proposals to advance and/or 
>>> continue this idea!
>>> 
>>> Björn Petersen 
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>> 
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 dissector to analyze custom protocol traffic. However, to 
> further increase the usability, we need to add protocol analysis specific GUI 
> elements. For now, we are not aware of a way to add a first level plugin 
> which can be called through an encapsulation type from a pcap file. One other 
> point is that we are not able to load a compiled plugin to wireshark, if we 
> don’t build it from source. We can’t link against wireshark and cmake will 
> not load the project if we install wireshark from the APT packages.
> 
> Are implementations available to add an encapsulation type via a plugin?
> Could anybody point us to examples of similar attempts?
> Is there already some work in progress to provide such a plugin mechanism for 
> extending the encapsulation types?
> We noticed that distributed packets, e.g. in Ubuntu 18.04 do not allow for C 
> plugins to be loaded. Do you know if this is common practice?
> Our goal is creating an open source tool to analyze communication within 
> SoCs, e.g. SoC FPGAs by providing both insight into protocol structure as 
> well as bit and timing accurate analysis at the same time with 
> cross-references.
> You may think about this like an analyzer for video data transport protocols, 
> which provides the ability to cross-reference actual pixels within the frames 
> to the protocol entities that has contained them by showing the picture and 
> enables clicking through the pixels / areas of the frames and the frames 
> within the timeline of the video. When you click on an images pixel/area, the 
> respective protocol unit containing the pixel is highlighted and vice versa. 
> This allows for much better interpretation than going through the payload 
> view or the image separately.
> 
> We already built a proof of concept, but we feel that this approach to 
> basically create a fork of the wireshark GUI is neither maintainable and 
> efficient nor something the community is looking for.
> We are seeking for any comment/reply or proposals to advance and/or continue 
> this idea!
> 
> Björn Petersen 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] QT installation

[Roland Knall]

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 personal email address to use the opensource license.

Alternatively you can download the Git repo and build Qt from source. For
that you do not need to register for a license at all.

Sadly, Qt has decided to use that route, nothing we can do about it I am
afraid.

kind regards
Roland

Am Do., 3. Dez. 2020 um 09:22 Uhr schrieb Lucio Di-Giovannantonio via
Wireshark-dev :

> I'm trying to install QT open source, but it is a mess, it seems
> impossible to find the open source installer. When I found it, I receive
> the following error:
>
>
>
> "Your company has commercial QT licenses. Please contact QT customer
> success to see if you are eligible to download QT open source".
>
>
>
> Unfortunately I cannot enter the linked web page to check my license.
> Someone can help me to install QT open source?
>
>
>
> Kind Regards
>
> Lucio Di Giovannantonio
>
> Senior Software Developer
>
>
>
> Keysight Technologies Italy srl – unico socio
>
> Via Policarpo Petrocchi 4 - 20127 Milano (MI) - Italy
>
>
>
> Tel: +39 02 923 98108, Telnet: 239 8108
>
> Web. www.keysight.com
>
>
>
>
>
> *[image: Prisma_eMailSignature]* 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 summary, if you run M1s run Rosetta2 atm. Binaries will require a few
months to be stable. If you want to develop though, that can be done
easily, just be aware, that development environment wise you will run into
issues. VSCode does not work yet 100%, Qt you must compile yourself,
QtCreator does not work at all for me so far, ...

I can give you pointers in the next Dev Den Meeting if you want

Cheers
Roland

chuck c  schrieb am Sa. 28. Nov. 2020 um 16:42:

> This question was about getting a pre-compiled binary:
>
> https://ask.wireshark.org/question/20092/which-version-should-i-download-on-new-mac-pro-with-new-m1-chip/
>
> but the bigger question is how does the transition to M1 affect developers?
>
> Is it possible to get a new M1 machine and build for both processor
> architectures?
> Does it matter for most code changes?
>
> I think Roland mentioned on the developers den he had been working on
> compiling on the new chip.
> Are there enough gotchas that are worth a Wiki page/update to dev
> guide/open issue to track?
>
> thanks
> chuckc
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] About i18n Translation

[Roland Knall]

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 debian/po only used in debian platform or all 
> platforms (like windows)? 
> (If these *.po are used in all platforms, I think they can also be used to 
> add new strings for title and description preference in 
> epan/dissectors/packet-xxx.c)
> 
> 2. Do the projects in https://www.transifex.com/wireshark/wireshark/ still 
> work like  "12.2.4.5. Internationalization and Translation" of 
> https://www.wireshark.org/docs/wsdg_html_chunked/ChUIQt.html#_source_code_overview
>  says, **each week** translations are automatically synchronized with the 
> source code?
> 
> Regards,
> Huang Qiangxiong
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 chuck c :

> Looking to build a Mac dev environment without paying the Apple hardware
> tax.
>
> Are there technical, moral, legal issues where this is a bad idea?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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:
> 
> https://linuxreviews.org/The_Qt_5.15_Disaster_On_Multi-Monitor_Setups
> 
> What it describes is similar to what I have seen from time to time
> with Wireshark (3.2.1 and earlier versions) where if Wireshark is on
> my second monitor menu items will appear on the first monitor (and
> other craziness can occur as well.)
> 
> Are these related at all? Do we plan to skip Qt 5.15?
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GitLab migration update

[Roland Knall]

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 Tue, Aug 25, 2020 at 12:56 PM Peter Wu  wrote:
>
>>
>> It looks like you have to delete the old stale fork relationship first,
>> otherwise you will end up with a 409 Conflict error ("Project already
>> forked").
>>
>> To automate fixing the fork status without requiring creation of an
>> access token, I wrote a small script that can be executed from your web
>> browser. See https://gitlab.com/wireshark/wireshark/-/issues/16806
>>
>>
> My wireshark repo on gitlab is not a fork of the main one (I've created it
> much earlier). Do you think the fork status can be forced on it as well?
> Just out of curiosity, I've already re-forked.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

> 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 
 read-only. SSH access is still enabled for now in order to make it easier 
 to migrate changes. I'll shut it off in the next couple of weeks.
>>> 
>>> Does "it" mean "Gerrit" or "SSH access to Gerrit"?
>> 
>> SSH access. I don't have a definite shutdown date for Gerrit, but it won't 
>> be for a while.
> 
> There's some potentially useful historical information there, when trying to 
> research why a change was made.
> 
> Is there a way to convert the Gerrit URLs in the issue database to 
> corresponding commits in the repository?

Two possibilities are here, none of which are automatic: 1. You can extract the 
change Id from the gerrit url and search within gerrit, or 2. the link to the 
gerrit change is part of the commit message, so searching git-log should yield 
results
> 
>>> Where is the link to the issues database from 
>>> https://gitlab.com/wireshark/wireshark?  GitHub has one on the top-level 
>>> page for GitHub repositories.
>> 
>> There should be an "Issues" link in the left sidebar. The direct link is 
>> https://gitlab.com/wireshark/wireshark/issues.
> 
> It's there, but the GitLab folks are not the best icon designers on the 
> planet.  The icon looks like a coffee cup, or a side view of a mailbox with 
> the door opened up, or whatever.  (And what does a rocket have to do with 
> continuous integration?)
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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-
>>> From: Wireshark-dev  On Behalf
>>> Of Guy Harris
>>> Sent: Tuesday, August 11, 2020 11:52 PM
>>> To: Developer support list for Wireshark 
>>> Cc: Community support list for Wireshark 
>>> Subject: Re: [Wireshark-dev] The Wireshark wiki has a new home
>>> 
 On Aug 11, 2020, at 5:18 PM, Gerald Combs  wrote:
>>> 
 As part of our larger GitLab migration effort I've migrated the Wireshark
>>> wiki to its new home at
 
 https://gitlab.com/wireshark/wireshark/-/wikis/home
 
 There's still a fair amount of post-migration work to do (for instance the
>>> "HowToEdit" is specific to our old wiki), but the new wiki should be faster 
>>> and
>>> easier to edit, particularly if you're familiar with Markdown.
>>> 
>>> So how do we edit a Wiki page?  I'm logged into my gitlab.com account, but I
>>> don't see, for example, an "Edit" button.
>> 
>> Same.  *Maybe* this is because Gerald is the only member of the project so 
>> far?
>> https://gitlab.com/wireshark/wireshark/-/project_members
> 
> Well, this stinks. I managed to overlook the fact that wiki editing requires 
> Developer permissions, which means that editing the wiki requires the same 
> rights as accepting merge requests and creating new branches:
> 
> https://gitlab.com/help/user/permissions
> 
> This is fine for core developers, but not so great for other people that 
> currently have editor permissions. Other people have the same problem, but I 
> don't see any indication that this will be fixed any time soon:
> 
> https://gitlab.com/gitlab-org/gitlab/-/issues/25177
> https://gitlab.com/gitlab-org/gitlab/-/issues/27294
> https://gitlab.com/gitlab-org/gitlab/-/issues/15504
> 
> 
> We have a few options in the mean time:
> 
> * Switch back to MoinMoin / wiki.wireshark.org and let it continue to bit-rot.
> 
> * Switch back to MoinMoin, find some other wiki software, and migrate to it.
> 
> * Create a separate, public wiki-only gitlab.com/wireshark/wireshark-wiki 
> project, and grant Developer permissions to anyone that wants to contribute.
> 
> * Create a separate, possibly-private wiki-only 
> gitlab.com/wireshark/wireshark-wiki-backend project, grant Developer 
> permissions to anyone that wants to contribute, and mirror it to the main 
> project wiki.
> 
> * Some other variation of the previous two items?
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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., 30. Juli 2020 um 08:59 Uhr schrieb Tomasz Moń :

> On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter  wrote:
> > 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 interpretation, as seen in network protocols.
> >
> > Your suggestion is that the interpretation can also be:
> >
> >  15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
> > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> > |  |  |  |  |  |  | 1| 0| 6| 5| 4| 3| 2|  |  |  |
> > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> This is not what I wanted to write. Assuming you meant two octets, and
> the bitmask on the 16-bit value is 0x1FC0 then the alternative
> interpretation would be:
>   15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
>  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>  |  |  |  |  |  |  | 4| 3| 2| 1| 0| 6| 5|  |  |  |
>  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> > Here the first interpretation is a simple matter of mask and shift, the
> second interpretation is somewhat more involved. Since the first
> interpretation is common in network protocols (and efficient to handle) the
> code was made with that in mind.
>
> Is the complexity the only reason? I prefer the complex things to be
> in the common code and not in individual dissectors.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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
hardly get more out of the packetlist then the frame number. An alternative
route would be to link your plugin against the wireshark application
itself, and cast QCoreApplication::instance() to WiresharkApplication. From
there you would be able to attach your code onto MainWindow's signals. But
again, more than a frame-number would not be possible, due to the same
memory constraints mentioned above. The packet-info itself is, once again,
part of the wrong execution context, therefore on most operating systems
access would lead to an access violation error.

The reason tap's work is that they were designed to be working like
that from the beginning. They also provide a specific object, not
packet_info. I tried to implement something similar then what you are
trying now in the past when I wrote the plugin interface. In the end I gave
up due to too many headaches involved.

cheers
Roland

Am So., 19. Juli 2020 um 10:49 Uhr schrieb Tomáš Kukosa :

> Hi,
>
> the plugin can introduce own menu item to menu bar or toolbar.
>
> When the menu callback is invoked is it possible to access selected
> packet anyhow?
>
> What I would like to achieve is to call external program with parameters
> based on selected packet.
>
> Thanks for any hint,
>
> Tomas
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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., 18. Juni 2020 um 06:27 Uhr schrieb chuck c :

> I would like to test installs with and without this change:
> https://code.wireshark.org/review/#/c/19179/
>
> Is there a way to figure out which binary this was first released in?
>
>
> thanks
> chuck
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] macOS build broken

[Roland Knall]

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 to be caused by the usage 
> of the _Nonnull, _Nullable, or _Null_unspecified type specifiers in the 
> 6lowpan dissector.
> 
> My compiler is:
> 
> > gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
> Apple clang version 11.0.0 (clang-1100.0.33.17)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> This is the error: 
> 
> In file included from 
> /Users/lojakab/src/wireshark-lisp/wireshark/epan/dissectors/packet-6lowpan.c:19:
> In file included from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/stdio.h:64:
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:93:16:
>  error: pointer is missing a nullability type specifier
>   (_Nonnull, _Nullable, or _Null_unspecified) 
> [-Werror,-Wnullability-completeness]
> unsigned char   *_base;
> ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:93:16:
>  note: insert '_Nullable' if the pointer may be null
> unsigned char   *_base;
> ^
>   _Nullable
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:93:16:
>  note: insert '_Nonnull' if the pointer should never be null
> unsigned char   *_base;
> ^
>   _Nonnull
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:32:
>  error: pointer is missing a nullability type specifier
>   (_Nonnull, _Nullable, or _Null_unspecified) 
> [-Werror,-Wnullability-completeness]
> int (* _Nullable _read) (void *, char *, int);
>   ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:32:
>  note: insert '_Nullable' if the pointer may be null
> int (* _Nullable _read) (void *, char *, int);
>   ^
>_Nullable
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:32:
>  note: insert '_Nonnull' if the pointer should never be null
> int (* _Nullable _read) (void *, char *, int);
>   ^
>_Nonnull
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:40:
>  error: pointer is missing a nullability type specifier
>   (_Nonnull, _Nullable, or _Null_unspecified) 
> [-Werror,-Wnullability-completeness]
> int (* _Nullable _read) (void *, char *, int);
>   ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:40:
>  note: insert '_Nullable' if the pointer may be null
> int (* _Nullable _read) (void *, char *, int);
>   ^
>_Nullable
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:138:40:
>  note: insert '_Nonnull' if the pointer should never be null
> int (* _Nullable _read) (void *, char *, int);
>   ^
>_Nonnull
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:139:35:
>  error: pointer is missing a nullability type specifier
>   (_Nonnull, _Nullable, or _Null_unspecified) 
> [-Werror,-Wnullability-completeness]
> fpos_t  (* _Nullable _seek) (void *, fpos_t, int);
>   ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:139:35:
>  note: insert '_Nullable' if the pointer may be null
> fpos_t  (* _Nullable _seek) (void *, fpos_t, int);
>   ^
>_Nullable
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:139:35:
>  note: insert '_Nonnull' if the pointer should never be null
> fpos_t  (* _Nullable _seek) (void *, fpos_t, int);
>   ^
>_Nonnull
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:140:32:
>  error: pointer is missing a nullability type specifier
>   (_Nonnull, _Nullable, or 

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

[Roland Knall]

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 it would read "Proto &&
HTTP" or "Proto && TCP", to create a folder "Proto" with the children
"HTTP" and "TCP".

Now the question is, if && is the correct delimiter. What do you think?
Would // for instance make more sense?

Please let me know

cheers, Roland
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Regenerating moc files

[Roland Knall]

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 regenerate Qt moc files?
> If I change something in the cmake defines, the target qtui_autogen doesn't 
> actually regenerate the moc files, giving me a compilation error. Otherwise 
> if I manually remove the moc dir ui/qt/qtui_autogen/ and recompile, goes ok.
> Thanks.
> Dario.
> 
> -- 
> Naima is online.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt availability changes

[Roland Knall]

> 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-company-is-stopping-qt-lts.html 
>> 
>> Long story short - we may have to host our own version at some point.
> 
> I think this is a more even and balanced take on the subject (from a KDE 
> developer also):
> 
> https://valdyas.org/fading/software/about-qt-offering-changes-2020/
> 
> 

I disagree. He reaches an even darker and more bleak conclusion of Qt loosing 
market share and attractiveness. 


>> 
>> Am Di., 28. Jan. 2020 um 12:44 Uhr schrieb Roland Knall :
>>> 
>>> 
>>> 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 rely on 
>>> 3rd-party packages or compile ourselves. This is a change from the current 
>>> situation where we use the official LTS versions.
>>>  
>>>> The main problem I see is it basically forces us to use the latest Qt
>>>> version which makes supporting older Linux distributions somewhat
>>>> harder. Based on the Qt version history [1], it looks like non-LTS
>>>> versions are supported for 1 year. Typical Linux distributions have a
>>>> longer lifetime.
>>>> 
>>> 
>>> This is not different from now. We still would support a minimum version, 
>>> although shipping with a later one. 
>>> 
>>>  
>>>>  [1]: https://en.wikipedia.org/wiki/Qt_version_history#Qt_5
>>>> 
>>>> The Qt project is still committed to providing security updates, so that
>>>> should not change the situation for Linux distribution maintainers.
>>>> Debian for example typically does not update the Qt version even though
>>>> there may be dozens of usability bug fixes.
>>>> 
>>> 
>>> It changes considerably, as the LTS versions (and code-branches) will no 
>>> longer be available. As said above, we would have to maintain our own 
>>> version of Qt if needed
>>>  
>>>> The LTS branch is not just 'no longer easily accessible', it will simply
>>>> be unavailable for non-commercial users. The Qt company wants OSS
>>>> developers like us to use the latest version and report back issues and
>>>> such. Which I already did in the past, including patches...
>>> 
>>> Which results in us having an issue with packaging.
>>> 
>> 
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt availability changes

[Roland Knall]

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 :

>
>
> 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 rely on
> 3rd-party packages or compile ourselves. This is a change from the current
> situation where we use the official LTS versions.
>
>
>> The main problem I see is it basically forces us to use the latest Qt
>> version which makes supporting older Linux distributions somewhat
>> harder. Based on the Qt version history [1], it looks like non-LTS
>> versions are supported for 1 year. Typical Linux distributions have a
>> longer lifetime.
>>
>>
> This is not different from now. We still would support a minimum version,
> although shipping with a later one.
>
>
>
>>  [1]: https://en.wikipedia.org/wiki/Qt_version_history#Qt_5
>>
>> The Qt project is still committed to providing security updates, so that
>> should not change the situation for Linux distribution maintainers.
>> Debian for example typically does not update the Qt version even though
>> there may be dozens of usability bug fixes.
>>
>>
> It changes considerably, as the LTS versions (and code-branches) will no
> longer be available. As said above, we would have to maintain our own
> version of Qt if needed
>
>
>> The LTS branch is not just 'no longer easily accessible', it will simply
>> be unavailable for non-commercial users. The Qt company wants OSS
>> developers like us to use the latest version and report back issues and
>> such. Which I already did in the past, including patches...
>>
>
> Which results in us having an issue with packaging.
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt availability changes

[Roland Knall]

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 rely on
3rd-party packages or compile ourselves. This is a change from the current
situation where we use the official LTS versions.


> The main problem I see is it basically forces us to use the latest Qt
> version which makes supporting older Linux distributions somewhat
> harder. Based on the Qt version history [1], it looks like non-LTS
> versions are supported for 1 year. Typical Linux distributions have a
> longer lifetime.
>
>
This is not different from now. We still would support a minimum version,
although shipping with a later one.



>  [1]: https://en.wikipedia.org/wiki/Qt_version_history#Qt_5
>
> The Qt project is still committed to providing security updates, so that
> should not change the situation for Linux distribution maintainers.
> Debian for example typically does not update the Qt version even though
> there may be dozens of usability bug fixes.
>
>
It changes considerably, as the LTS versions (and code-branches) will no
longer be available. As said above, we would have to maintain our own
version of Qt if needed


> The LTS branch is not just 'no longer easily accessible', it will simply
> be unavailable for non-commercial users. The Qt company wants OSS
> developers like us to use the latest version and report back issues and
> such. Which I already did in the past, including patches...
>

Which results in us having an issue with packaging.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt availability changes

[Roland Knall]

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, but I imagine we can keep the impact for our
user-base to a minimum.

>From an installation point of view, basically you have two options:
a. Go with the official installer and register for an account, or
b. use brew/port on Mac and chocolatey/vcpkg on Windows.

b. does not require registration, as chocolatey/vpckg/brew/ports build
themselves and they do not force the registration policy. They also tag
releases, which means that we could tag to a specific release for each
platform. After reading a lot of messages on the mailing list, it seems
that the main difference for LTS releases will be that additional to
security fixes, adaptions of changes (aka compiler changes for instance)
will no longer be available in older versions. I assume we will have the
option to build a version of Qt ourselves which we could than add to the
installation bundle. That option can be used from -dev or always the latest
tagged release version. For Windows/Mac users it will not make much
difference, as most Qt-based OSS projects don't focus on using a
system-wide Qt version anyway and are fine with using a
package-distributable version. It might present us with headaches in regard
of supporting Wireshark on older Mac/Windows versions though, and makes our
job a little harder. It also introduces a wider range of possible bug-hunts.

On the - user wants to develop a dissector - route, yes I agree, this makes
our lives harder. Just developing a small dissector quickly will not be as
easy as it might seem today (it isn't today as easy as it should be also,
but this is a different issue). On the other hand, a lot of users struggle
with today's approach as well. For the rest we can map out the
chocolatey/vpckg/brew/ports route. Or switch to Lua dissectors, where we
might need to find a way to package and distribute them properly.

Finally, I would not call it a day yet. Qt has become a very strategic
project for a lot of people. I could imagine, that the outcry over this
decision will be as big as the one 2015 over the first attempt to close
down the installer. I could imagine, that they will backpedal the ideas a
little bit in the near future, although I will not betting on it. Let's
hope they at least give the LTS route another thinking and come up with a
different solution. For the reasons mentioned above, I could live without
the binary releases, having no longer an easily accessible LTS branch does
hurt though.

Overall, I hope the impact will be - if anything - as small as possible and
affect us as the core's more than our users.

cheers
Roland

Am Mo., 27. Jan. 2020 um 21:37 Uhr schrieb Graham Bloice <
graham.blo...@trihedral.com>:

>
>
> On Mon, 27 Jan 2020 at 20:06, Gerald Combs  wrote:
>
>> The Qt Company recently announced upcoming changes in the distribution of
>> their official binaries:
>>
>> https://www.qt.io/blog/qt-offering-changes-2020
>>
>> https://lists.qt-project.org/pipermail/development/2020-January/thread.html#38316
>>
>> Two of the changes adversely affect how we develop and build Wireshark,
>> primarily on Windows and macOS. First, downloading official releases from
>> qt.io will require logging in with a Qt account. How much of an issue is
>> this for people developing Wireshark on those platforms? Is it enough to
>> warrant switching to a different, unofficial source for Qt binaries? I'm
>> not really thrilled about the prospect of Qt salespeople pestering someone
>> who just wants to build a Wireshark dissector.
>>
>> Second, LTS releases will no longer be open source starting with Qt 5.15.
>> We currently ship the latest LTS version of Qt with our Windows and macOS
>> packages. I'm not sure how we're going to handle this in the future.
>>
>
> Uggh.  Really unhelpful.  I fail to see how requiring Open source
> projects to follow effectively the HEAD of the CURRENT release is going to
> make things better.
>
> As folks noted in the thread you linked to, how will CI systems handle
> this?
>
> --
> Graham Bloice
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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, send this to extcap, which recreates a frame 
to be displayed using pcap as a format. 

See the documentation of extcap in the developer documents 

Regards
Roland

> Am 26.01.2020 um 09:46 schrieb Erwin Rol :
> 
> Hey all,
> 
> I was wondering if there is a remote capture "protocol" that works on
> Mac, Windows, and Linux? 
> 
> The idea I have is to use a small (and cheap) microcontroller like a
> STM32F407 that can capture a fieldbus (RS485 based, etc.) and relay
> that in realtime (realtime as in not storing it locally) to a PC
> running Wireshark.
> 
> I could simply pack it in some UDP protocol and write a dissector for
> that, but than I would loose my timing information, because it will be
> the timing of wenn the UDP packet has been received and not the time of
> when the fieldbus packet was received. 
> 
> Is there already anything out there that supports transporting capture
> data (including timing) over Ethernet that works on all 3 major
> platforms (rcap seems windows only, ssh seems linux only, and both are
> to heavy to implement on a microcontroller).
> 
> Any info and ideas are welcome.
> 
> TIA,
> 
> Erwin
> 
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Support Opus in WireShark

[Roland Knall]

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 schrieb Jiří Novák :

> Dear Ryan,
>
> > Using C++ default parameter because I want to use Opus FEC.  When a RTP
> > packet lost, I need to use the next packet’s data to recovery the lost
> > data. But the decoder module only have data ,can’t get the neighbor
> > packet’s information. So I modified  the rtp_audio_stream.cpp to play
> > audio and rtp_analysis_dialog.cpp to save the audio.
>
> I understand requirement for additional parameter, I don't understand
> why C++, but it is not important.
>
> I'm afraid you will touch one issue - nowadays Wireshark initiates codec
> "system wide". Therefore same codec handle receives "pieces" of payload
> to decode with no relations to other "pieces". If you have one RTP flow,
> it is OK, but for multiple flows it happens that codec receiving pieces
> of multiple flows interleaved.
> It makes no troubles till now because all currently supported codes are
> stateless - there is no relation between sequence of payloads. For Opus
> it will make troubles by my opinion - Opus is stateful codec and you
> must pass payload pieces to it in order and just for one stream. Once
> you will interleave it, it will decode garbage probably.
>
> BTW your need to add FEC flag to function call shows that codec handle
> is not aware of stream. If it will be aware of it, FEC flag should be
> part of codec state and you don't need to add parameter for it.
>
> Some time ago I got idea to change codec staff to be RTP stream aware,
> but as there was no strong need, I postponed it. It looks that there is
> right time for it now. I will be happy to cooperate on it.
>
> Best regards,
>
> Jirka Novak
>
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 well, which have to be adapted, as well as the before
mentioned macOS-brew script.

Am So., 29. Dez. 2019 um 21:15 Uhr schrieb João Valverde <
joao.valve...@tecnico.ulisboa.pt>:

>
>
> On 29/12/19 13:46, Jiří Novák wrote:
> > Hi,
> >
> >> For Ubuntu there is tools/debian-setup.sh that installs optional
> >> packages (as this).
> >> I suggest you to test your change at least on this platform since it's
> >> the most common.
> > OK. I will try.
> >
> >> Did you make your change compilable without that library? You need some
> >> preprocessor ifdefs for that.
> > I'm familiar with optional compilation with configure tools, but I'm
> > lost in CMake... On the other hand I tested it and it is possible to
> > compile it without library - CMake detects it is not there and do not
> > compile the code. Therefore it looks I wrote it correctly.
> >
> > BTW I have no idea where to get iLBC library for Windows and Mac. The
> > library is open source therefore we can try to compile it, but I don't
> > know how to incorporate this step/procedure to build of wireshark.
> >
> > Redhat like systems use version 1.1.1 from 2012 but many other platforms
> > use latest 2.0.2 from 2014.
> >
> >> If you push your change as WIP you can add me as reviewer: I have a
> >> bunch of builders for many platforms. I can help you at least to compile
> >> it on as many as possible.
> > OK, thank you for offer. I'm waiting for accepting a few changes it
> > depends on and then I will push it.
> >
>
> I think it would be helpful to push it anyway (your call). It will speed
> up the review of the pending patches and make it easier for us to help.
>
> Marking it [WIP] or [DONOTCOMMIT] is a good idea in case it doesn't show
> a merge conflict (so it doesn't get merged ahead of the dependencies).
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Extcap binaries on OSX

[Roland Knall]

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
> Windows: run\RelWithDebInfo\extcap
> OSX: ?
>
> Any help?
> Thanks.
> Dario.
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark for Mac 10.14.5

[Roland Knall]

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. When I try to download from supported version of 
>> Wireshark it gets me .png? Can you please help me in I installing Wireshark 
>> on my Mac?
> 
> Either
> 
>1) use Safari, not Chrome
> 
> or
> 
>2) make sure you have no "take a screenshot" Chrome extensions installed.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 setuid dumpcap root or setgid wireshark
> (existing group for the distribution version of wireshark I also have
> installed), but those didn't seem to work. Is there something else I need
> to be able to run it without sudo?
>
> Thanks!
>
> On Fri, 29 Nov 2019 at 14:28, Dario Lombardo  wrote:
>
>> Have a look at cmake's output. It will say something about libpcap
>> (whether is found or not). If it's found, you can compile dumpcap with
>> ninja/make dumpcap, just to be sure it's compiled. However a straight
>> compilation command should do its job.
>>
>> On Fri, Nov 29, 2019 at 3:04 PM Tom Bentley 
>> wrote:
>>
>>> Hi,
>>>
>>> I downloaded and built wireshark 3.1.1 from the website. When I
>>> run/wireshark the gui appears, but there in the "Capture" pane it says "No
>>> interfaces found". Furthermore (maybe related, maybe not) I had expected
>>> `dumpcap` to be in the run directory, but it's missing). So I'm wondering
>>> how I managed to mess up the build and what I need to do to fix it.
>>>
>>> Many thanks,
>>>
>>> Tom
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>
>>
>>
>> --
>>
>> Naima is online.
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

@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 because M$ now requires
> anniversary edition to install dotnet. They say:
>
> "
>
> https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements
> THis is kind of also mentioned in the package description
>
> Supported Windows Client versions: Windows 10 version 1903, Windows 10
> version 1809, Windows 10 version 1803, Windows 10 version 1709, Windows 10
> version 1703, Windows 10 version 1607, Windows 8.1, Windows 7 SP1
>
> 1607 being the anniversary edition
> "
>
> I'm trying to make my system up2date and then install dotnet. if I
> succeed, I'll drop a line in the documentation about installing on an
> updated windows version, or a more detailed description of the issue.
>
> On Tue, Nov 26, 2019 at 3:20 PM Graham Bloice 
> wrote:
>
>>
>> On Tue, 26 Nov 2019 at 11:55, Dario Lombardo  wrote:
>>
>>> Hi
>>> I'm following the win32/64 guide from the very beginning on a fresh
>>> win10 VM. I'm basically at the top, but I hit an error. In chap 2.2.2 I'm
>>> issuing the choco command to install visualstudio. The installation fails
>>> because dotnetfx fails. I've found this error message:
>>>
>>> The .NET Framework 4.8 is not supported on this operating system.
>>>
>>> The documentation doesn't say anything about incompatibilities with
>>> .NET. How can I fix it (I guess installing .NET by myself?)?
>>> Should we document something since this is a generalized problem, or
>>> it's just mine?
>>> --
>>>
>>> Naima is online.
>>>
>>> It seems that MS no longer install the .Net framework by default, it's
>> an additional option.  See the MS page on this issue here:
>> https://docs.microsoft.com/en-us/dotnet/framework/install/on-windows-10
>>
>> The choco package "dotnetfx"  will install this:
>> https://chocolatey.org/packages/dotnetfx
>>
>> Arguably it should be a dependency for the VS choco packages, and it is
>> listed for the VS 2019 community package.  Not sure what's gone wrong for
>> you here.
>>
>> --
>> Graham Bloice
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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, where is the best
> place to request something like this?
> > Doesn't seem worthy of a new entry in Bugzilla.
>
> In my opinion the best place would be the review system (currently
> Gerrit). That is, update the NEWS,
> commit and push the update for review.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 Visual Studio Commandprompt? I recently tried
>> it and it works fine.
>>
>>
>>
> This also works for me, without the need for a canoe though.
>
> You can check if the command prompt has been set up correctly by
> attempting to execute the compiler (cl.exe), for VS 2019 you should see
> something similar to:
>
> Microsoft (R) C/C++ Optimizing Compiler Version 19.23.28106.4 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> usage: cl [ option... ] filename... [ /link linkoption... ]
>
> --
> Graham Bloice
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 have VS2019 Community and can run up the UI with no problems.
> 
> However, when I try to run cmake I get the following error. Does
> anyone know the solution?
> 
> 
> C:\Development\wsbuild64>cmake -G "Visual Studio 16 2019" -A x64
> C:\Users\Richard.Sharpe.A00187\source\repos\wireshark
> CMake Error at CMakeLists.txt:29 (project):
>  Generator
> 
>Visual Studio 16 2019
> 
>  could not find any instance of Visual Studio.
> 
> 
> 
> -- Configuring incomplete, errors occurred!
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Roland Knall]

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 <
realrichardsha...@gmail.com>:

> Hi folks,
>
> With 3.1.0, I see the message displayed in yellow any time I try Right
> Click on a field, then Apply as Filter->Selected.
>
> Is that functionality broken in 3.1.0?
>
> The version is: Version 3.1.0 (v3.1.0-0-g414ca80b2168)
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Warnings from Qt

[Roland Knall]

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
>> 16:21:36.994 Main Warn CaptureEvent [ 2 ]:  2
>> 16:21:37.042 Main Warn CaptureEvent [ 2 ]:  4
>> 16:21:39.416 Main Warn CaptureEvent [ 2 ]:  8
>> 16:21:39.418 Main Warn CaptureEvent [ 2 ]:  16
>>
>> this started after  https://code.wireshark.org/review/#/c/34937/
>>
>
> Now that we have qDebug() activated by default, I guess we should comment
> its use in capture_file.cpp :)
>
>
>> //Joakim
>>
>> On Wed, 30 Oct 2019 at 18:32, Gerald Combs  wrote:
>>
>>> On 10/29/19 9:00 AM, Anders Broman via Wireshark-dev wrote:
>>> > Hi,
>>> >
>>> > Recently I’m getting:
>>> >
>>> > 16:14:09.906 Main Warn DirectWrite: CreateFontFaceFromHDC() failed
>>> > (Indicates an error in an input file such as a font file.) for
>>> > QFontDef(Family="Fixedsys", pointsize=9.75, pixelsize=15, styleHint=5,
>>> > weight=50, stretch=100, hintingPreference=0) LOGFONT("Fixedsys",
>>> lfWidth=0,
>>> > lfHeight=-15) dpi=96
>>>
>>> I can duplicate the issue here by changing the main window font
>>> preference to Fixedsys. It looks like it might be due to
>>> https://bugreports.qt.io/browse/QTBUG-57180. A fix was backported to
>>> the 5.12 branch recently, so it should hopefully be in 5.12.6:
>>> https://codereview.qt-project.org/c/qt/qtbase/+/277322.
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Migrate to GitLab?

[Roland Knall]

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 :

> 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 developed on an older commit then the current master has) and just
> cherry-picks the change. It has two basic advantages: 1. It prevents
> "merge-branch" commit messages and therefore keeps the master history
> clean, but also 2. it prevents the developer from rebasing on master before
> merging the change.
>
> Different to cherry-pick, merge branch strategy will also try to merge the
> commit together with the master branch. But in the scenario described
> above, it can lead to scenarios where the two branches are out of sync, and
> now git* will create a merge-commit to move them on the same track again.
> There are two major issues with that strategy: 1. it pollutes history. It
> will end up creating a bunch of those merge requests, as long as the
> developers don't take rebase seriously and 2. it increases the risk that a
> merge will overwrite newer changes, an absolut no-no. It usually is
> deployed either in small projects or together with a very complete CI/CD
> integration with nearly 100% automatic functionality testing. In bigger
> projects it is a very bad idea in my opinion.
>
> Now fast-forward is the strictest of it all, although a little bit similar
> to cherry-picking. It is used to absolutely ensure, that the commit history
> is clean. It basically means, that your merge request will have to happen
> on the very top of the commit history of the branch you want to merge into.
> This means, that the developer has to ensure that the patchset can be
> merged, no automatic resolving takes place. It is more cumbersome to work
> with, especially in projects where a lot of people commit. To my
> recollection the collisions have to be resolved only for the files touching
> the merge request, making it a little bit less strict, but still it
> requires additional effort on the side of the developer. (see
> https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
> for gitlab's explanation, at the bottom they have a very good overview of
> what it entails).
>
> Personally I have ever worked with fast-forward and cherry-pick. The first
> is an absolut must if code traceability has to be ensured (e.g. for machine
> safety applications), the latter for projects which want a very clean main
> history (e.g. for release notes) and also avoid extra checks for feature
> branch merges (due to the nature of overwriting existing changes on chance
> with merge-only strategies).
>
> Therefore I am very strongly opposed on merge commits and would prefer
> fast-forward. If we go with merge commits we would need other features and
> workflows to ensure, that no overwrite can take place or it is detected
> properly if it happens.
>
> regards
> Roland
>
> Am Sa., 12. Okt. 2019 um 12:09 Uhr schrieb Graham Bloice <
> graham.blo...@trihedral.com>:
>
>> As one who has never used GitLab, I'm uncertain about the changes.
>> To educate me can anyone point to an instance of a merge commit in
>> another project?
>>
>> If I understand them correctly (which might not be true) then I'm a -2
>> for merge commits.  I really do NOT want to see master commit history
>> polluted with the details of the sausage making, just the effective change.
>>
>> To clarify discussion on this I would like to see detailed workflows of
>> both approaches (ff only and merge commits), i.e. intial change creation,
>> amendment, approval and merge to master, along with any tooling (e.g.
>> similar to git-review) that makes the process easier.
>>
>> When we have the workflows laid out then we then have a basis for
>> discussion as to which fits the project needs better.
>>
>>
>> On Sat, 12 Oct 2019 at 02:28, João Valverde <
>> joao.valve...@tecnico.ulisboa.pt> wrote:
>>
>>>
>>> On 11/10/19 22:54, Gerald Combs wrote:
>>>
>>> The reactions to migrating so far have been pretty favorable, so I've 
>>> started documenting the process at 
>>> https://gitlab.com/wireshark/gitlab-migration/wikis/home. There are still a 
>>> lot of things to figure ou

Re: [Wireshark-dev] Migrate to GitLab?

[Roland Knall]

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 developed on an older commit then the current master has) and just
cherry-picks the change. It has two basic advantages: 1. It prevents
"merge-branch" commit messages and therefore keeps the master history
clean, but also 2. it prevents the developer from rebasing on master before
merging the change.

Different to cherry-pick, merge branch strategy will also try to merge the
commit together with the master branch. But in the scenario described
above, it can lead to scenarios where the two branches are out of sync, and
now git* will create a merge-commit to move them on the same track again.
There are two major issues with that strategy: 1. it pollutes history. It
will end up creating a bunch of those merge requests, as long as the
developers don't take rebase seriously and 2. it increases the risk that a
merge will overwrite newer changes, an absolut no-no. It usually is
deployed either in small projects or together with a very complete CI/CD
integration with nearly 100% automatic functionality testing. In bigger
projects it is a very bad idea in my opinion.

Now fast-forward is the strictest of it all, although a little bit similar
to cherry-picking. It is used to absolutely ensure, that the commit history
is clean. It basically means, that your merge request will have to happen
on the very top of the commit history of the branch you want to merge into.
This means, that the developer has to ensure that the patchset can be
merged, no automatic resolving takes place. It is more cumbersome to work
with, especially in projects where a lot of people commit. To my
recollection the collisions have to be resolved only for the files touching
the merge request, making it a little bit less strict, but still it
requires additional effort on the side of the developer. (see
https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html
for gitlab's explanation, at the bottom they have a very good overview of
what it entails).

Personally I have ever worked with fast-forward and cherry-pick. The first
is an absolut must if code traceability has to be ensured (e.g. for machine
safety applications), the latter for projects which want a very clean main
history (e.g. for release notes) and also avoid extra checks for feature
branch merges (due to the nature of overwriting existing changes on chance
with merge-only strategies).

Therefore I am very strongly opposed on merge commits and would prefer
fast-forward. If we go with merge commits we would need other features and
workflows to ensure, that no overwrite can take place or it is detected
properly if it happens.

regards
Roland

Am Sa., 12. Okt. 2019 um 12:09 Uhr schrieb Graham Bloice <
graham.blo...@trihedral.com>:

> As one who has never used GitLab, I'm uncertain about the changes.
> To educate me can anyone point to an instance of a merge commit in another
> project?
>
> If I understand them correctly (which might not be true) then I'm a -2 for
> merge commits.  I really do NOT want to see master commit history polluted
> with the details of the sausage making, just the effective change.
>
> To clarify discussion on this I would like to see detailed workflows of
> both approaches (ff only and merge commits), i.e. intial change creation,
> amendment, approval and merge to master, along with any tooling (e.g.
> similar to git-review) that makes the process easier.
>
> When we have the workflows laid out then we then have a basis for
> discussion as to which fits the project needs better.
>
>
> On Sat, 12 Oct 2019 at 02:28, João Valverde <
> joao.valve...@tecnico.ulisboa.pt> wrote:
>
>>
>> On 11/10/19 22:54, Gerald Combs wrote:
>>
>> The reactions to migrating so far have been pretty favorable, so I've 
>> started documenting the process at 
>> https://gitlab.com/wireshark/gitlab-migration/wikis/home. There are still a 
>> lot of things to figure out, but I'm hoping that we can start preparation 
>> and testing some time in November and cut over the repository in mid January 
>> (the 14th will be the 6th anniversary of the Subersion-to-Gerrit cutover).
>>
>> Awesome. Also +1 for merge commits from me. Sadly I haven't really seen
>> anyone else advocating for this.
>>
>> I agree it's nicer to look at a linear history but the workflow is better
>> with merges.
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
>
> --
> Graham Bloice
> Software Developer
> Trihedral UK 

Re: [Wireshark-dev] Migrate to GitLab?

[Roland Knall]

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 "git pull" will pick up
> changes from the master branch (and then I do enough rebases to preserve
> the "the master or wireshark-x.y.z branch is The Official Source,
> everything else in the universe, including my repositories, is secondary"
> model I use)?
>
>
basically, you create a merge request, based on the branch in your forked
repository, and every commit to that branch gets added to the merge
request. I am not sure, if you can use "git commit --amend", never tried
it. I usually have a working branch, and the merge request receives updates
commits. The final integration into the master is then a "merged" commit of
all commits in the merge-request. But maybe Dario has a different idea.

But as I said, we would most likely have to create one or two documents
explaining an example workflow
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Migrate to GitLab?

[Roland Knall]

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 lies the issue. There are two methods to achieve 1&2 - either you
create a branch in your local checkout of the wireshark repository and push
from there - which will push you towards the merge request link, or you
create a clone of the main repository and work in there, and then create
merge requests from there. Second approach may let you avoid branches, but
it will require more overhead as it will lead you to handle main repo
updates yourself.


That being said, I am still a fan of the move to Gitlab, but the workflow
has to be worked out properly before really enabling it.

cheers
Roland

Am Di., 8. Okt. 2019 um 00:34 Uhr schrieb Guy Harris :

> On Oct 7, 2019, at 3:22 PM, Gerald Combs  wrote:
>
> > For new contributors, getting up and running with GitLab should be
> easier. GitLab doesn't require pushing to a special remote reference and
> doesn't require a special Change ID in the commit message. It should also
> be more familiar. For better or worse, the world seems to be standardizing
> on Git{Hub,Lab} and their respective workflows and tooling.
> >
> > For existing contributors and core developers, the review process would
> change a fair amount. The current [-2 .. +2] approval system would either
> change or go away depending on the flavor of GitLab we use[2][3]. It also
> looks like you can't edit a commit message in the web UI before merging[4].
>
> 1) Can you push (or whatever) a proposed commit to GitLab and then do a
> git commit --amend, changing either code or commit message, and then push
> and have that amend the commit-on-GitLab, without polluting the history?
>
> 2) Will this cause merge commits, such as the crap that GitHub dumps in
> there by default:
>
>
> https://github.com/the-tcpdump-group/libpcap/commit/b43fdf882a3bd71391535362b3bf560ec54e77ef
>
> to pollute the history?
>
> 3) Will I be forced to use branches in my local repository or can I do all
> my work in the default branch?
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe