On 06/03/20 08:23, Dario Lombardo wrote:
Example of failing build
https://github.com/crondaemon/wireshark/runs/489648430?check_suite_focus=true
A quick look suggests this is a different build than you indicated
before, for an NSIS package, and the problem seems to be that the
VC_REDIST
On 06/03/20 13:55, Dario Lombardo wrote:
Si it seems like it is not running the MSVC 2019 command prompt
that takes care of setting the various environment variables.
Well... this is a point. I added the proper action and it made it a
bit further.
On 22/01/20 17:04, Christian Hopps wrote:
On Jan 22, 2020, at 11:21 AM, João Valverde
wrote:
On 22/01/20 01:11, Christian Hopps wrote:
João Valverde writes:
On 21/01/20 16:06, João Valverde wrote:
On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs
Assuming you are serious, talking like a normal person would go a long
way towards getting your point across.
FYI, the documentation source code is here:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=tree;f=docbook;h=e4ea2271d3ec1416a0a8472148fac98b69f098c1;hb=HEAD
It is a
On 27/01/20 20:05, 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
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
On 22/01/20 01:11, Christian Hopps wrote:
João Valverde writes:
On 21/01/20 16:06, João Valverde wrote:
On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs in a single IP frame with
SCTP for years. While there's room for improvement it's worked
pretty well
On 21/01/20 16:06, João Valverde wrote:
On 21/01/20 16:01, Jeff Morriss wrote:
We've been having fun with multiple PDUs in a single IP frame with
SCTP for years. While there's room for improvement it's worked
pretty well.
Maybe I didn't explain well, but that's completely different
On 21/01/20 14:33, Christian Hopps wrote:
So I've got a payload of packets in a single frame. I'm calling dissector_try_uint_new()
to dissect each payload (typically IPv4 packets). Some of these packets are considered
"malformed" by wireshark (e.g., created by scapy/trex with some bogus
By the way usually a tunnel encapsulates a single packet. I'm not aware
of any other protocol multiplexing at the IP level. I would assume
Wireshark requires some replumbing to handle that. Something like TFS
being treated as a framing layer. Just food for thought.
On 21/01/20 14:46, João
in a single frame. L4 multiplexing is nothing
new, I agree.
On Tue, Jan 21, 2020 at 9:58 AM João Valverde
<mailto:joao.valve...@tecnico.ulisboa.pt>> wrote:
By the way usually a tunnel encapsulates a single packet. I'm not
aware
of any other protocol multiplexing at the IP level
On 20/01/20 21:33, Christian Hopps wrote:
So with IPTFS (https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-00) I've got
basically a packet stream inside an IPsec/ESP datagram packet stream. I've built various
data structures to track out of order etc fragments as I get called for
On 29/12/19 21:16, João Valverde wrote:
On 29/12/19 20:46, Roland Knall wrote:
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
interested in adopting this library.
Am So., 29. Dez. 2019 um 21:15 Uhr schrieb João Valverde
<mailto: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 opt
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?
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?
Related: https://code.wireshark.org/review/#/c/36990/
On 30/04/20 12:10, Brodie, Mark (Refinitiv) wrote:
Hi there,
My wireshark build attempt fails during cmake when it checks the
version of GLIB2.
-- Checking for one of the modules 'glib-2.0'
CMake Error at
On 15/05/20 23:46, Richard Sharpe wrote:
On Fri, May 15, 2020 at 3:33 PM Peter Wu wrote:
The "asn1" target rebuilds all asn1 dissectors.
Alternatively to rebuild a specific one, use a target such as
"generate_dissector-pkcs1".
Sure, but there seems to be multiple issues.
1. The
Hi Richard,
On 15/05/20 23:46, Richard Sharpe wrote:
On Fri, May 15, 2020 at 3:33 PM Peter Wu wrote:
The "asn1" target rebuilds all asn1 dissectors.
Alternatively to rebuild a specific one, use a target such as
"generate_dissector-pkcs1".
Sure, but there seems to be multiple issues.
1. The
On 19/03/20 18:38, Guy Harris wrote:
On Mar 19, 2020, at 7:40 AM, Gisle Vanem wrote:
I'm surprised no one has come across this compile
error yet:
epan/dissectors/packet-f5ethtrailer.c(482): error C2143: syntax error: missing
';' before '.'
epan/dissectors/packet-f5ethtrailer.c(485): error
On 20/03/20 17:45, Guy Harris wrote:
On Mar 20, 2020, at 8:09 AM, João Valverde
wrote:
On 19/03/20 18:38, Guy Harris wrote:
This isn't unique to Windows. It dates back to old BSD, in which struct in_addr
contained a union of multiple different types for an IP address, with some types
On 30/12/21 23:46, John Thacker wrote:
On Thu, Dec 30, 2021 at 5:55 PM Gerald Combs wrote:
On 12/29/21 5:15 PM, John Thacker wrote:
> I was working on a MR for moving the text2pcap/text_import debug
over to the ws_log features and I ran into a seemingly bizarre
problem.
),
get_localtime(tstamp.tv_sec, ),
tstamp.tv_nsec,
domain, level, file, line, func,
user_format, user_ap);
+ */
}
A few weeks ago I worked with João Valverde on changes
This was added in commit 1089bdb7d4911a5508f86a0eea59418b424b265c.
Catches mistakes where the same variable is populated by multiple
preferences:
prefs_register_bool_preference(epl_module, "show_soc_flags",
"text1", "desc1",
_soc_flags);
On 22/12/21 11:46, Jirka Novak wrote:
Hi,
This was added in commit 1089bdb7d4911a5508f86a0eea59418b424b265c.
Catches mistakes where the same variable is populated by
multiple preferences:
prefs_register_bool_preference(epl_module, "show_soc_flags",
"text1", "desc1",
On 03/11/21 10:50, Zoran Bošnjak wrote:
Hello wireshark developers,
I would appreciate some clarification about "making preferences obsolete".
As this problem reports (which is also in accordance with README.dissector)
https://gitlab.com/wireshark/wireshark/-/issues/17697
... is to make each
This is almost certainly my fault when integrating extcap with wslog.
Thanks for looking into it.
I'm not sure disabling every message to stderr is a good idea. The
problem space is the same as with dumpcap and that already works seamlessly.
But for now muting stderr with extcap --debug is
Hi,
The problem is that ssize_t is not defined in your platform. More
specifically because we define it in config.h that definition is not
available to external plugins.
It's a Wireshark bug but the easiest fix is for you to define ssize_t
before including wsutil/regex.h.
Thanks for
ne ssize_t long int
ahead of the #include in some plugins.
Thanks,
Peter M.
Sent from my awesome iPhone
On Dec 13, 2021, at 10:57, João Valverde wrote:
Hi,
The problem is that ssize_t is not defined in your platform. More
specifically because we define it in config.h that definition is not
On 14/12/21 13:39, Gisle Vanem wrote:
João Valverde wrote:
you can (and probably should) include "config.h", just like other
Wireshark bundled plugins do.
Why does this project not use '-FI./config.h'?
The header works fine, the consideration is that external plugins can
Hi,
You would have a better chance of receiving helpful feedback on the
CMake side of things if you also described the actual error in detail.
On 17/01/22 02:01, Glen Huang wrote:
Hi,
I’m trying to create an OpenWrt package for Wireshark.
I think I’m pretty close. However, I got stuck at
+0x19): undefined reference to `__libc_csu_init'
collect2: error: ld returned 1 exit status
I don’t think musl should show up here, since my build machine is Debian.
On Jan 17, 2022, at 10:09 PM, João Valverde wrote:
Hi,
You would have a better chance of receiving helpful feedback on the CMake
On 14/02/22 15:34, João Valverde wrote:
Hi Jaap,
If I understand correctly I think the numbers are correct by design.
When viewing packet details the analysis is almost always on the
protocol header. In this case that's what the size represents and
that's what I would expect.
I don't
On 15/02/22 20:01, Jaap Keuter wrote:
On 15 Feb 2022, at 13:20, João Valverde wrote:
And also, it's not really correct to include IP inside ICMP as IP
bytes, but that's another issue entirely.
Looking at the Protocol Hierarchy statistics, only the ‘top level’
protocols are counted. So
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
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
in
that case is wider editor support. The fact that the setting is hidden
away is actually a (minor) disadvantage if we still need to manage each
individual file.
On 02/03/22 12:36, João Valverde wrote:
The policy that exists for new files is a mere recommendation to use 4
space indentation
Hi Jaap,
If I understand correctly I think the numbers are correct by design.
When viewing packet details the analysis is almost always on the
protocol header. In this case that's what the size represents and that's
what I would expect.
I don't typically use Protocol Hierarchy statistics
On 20/01/22 15:28, Roland Knall wrote:
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
On 20/01/22 21:24, Bálint Réczey wrote:
Hi Guy,
Guy Harris ezt írta (időpont: 2022. jan. 20., Cs, 21:52):
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.
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
On 20/01/22 21:39, Roland Knall wrote:
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
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,
>>>
>>>
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
On 21/01/22 09:44, Bálint Réczey wrote:
João Valverde ezt írta (időpont: 2022. jan. 21., P, 1:29):
On 20/01/22 21:24, Bálint Réczey wrote:
Hi Guy,
Guy Harris ezt írta (időpont: 2022. jan. 20., Cs, 21:52):
On Jan 20, 2022, at 12:34 PM, Gerald Combs wrote:
Q: Should *wsutil* be part
On 21/01/22 11:14, Bálint Réczey wrote:
João Valverde ezt írta (időpont: 2022. jan. 21., P, 11:17):
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
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
Should 4.1 be developed on the release-4.2 branch already? Obviously it
would require some backporting work from developers, but also provide
some stability. Right now the 4.1 release is just a snapshot of master,
so really 4.1.x micro versions are meaningless.
There are some changes that
the 4.2 branch earlier. As you point
out, it mostly comes down to how much backporting we want to do. The
release numbers are a reflection of the fact that "run
tools/make-version.py -v ..." is in the new release branch checklist.
On 9/15/23 12:06 PM, João Valverde wrote:
more hassle.
Jaap
On 9/16/23 01:02, João Valverde wrote:
I would like that. We can be liberal backporting changes to the 4.1
release, but some care should be taken to avoid very big or risky
changes. Then for the 4.2 release candidates, ideally only bugfixes
would be backported.
On 9/15/23 22
On 8/24/23 13:16, Peter Wu via Wireshark-dev wrote:
Hi,
In the last weeks I started using Wireshark more and noticed some
crashes. I hope to be able to look into it over the next two weeks, and
also address some QUIC issues. Not sure if I will be able to review the
HTTP/3 changes in time.
Do
On 8/23/22 15:12, Richard Sharpe wrote:
On Tue, Aug 23, 2022 at 6:56 AM João Valverde wrote:
On 8/23/22 14:29, Richard Sharpe wrote:
On Tue, Aug 23, 2022 at 2:30 AM João Valverde wrote:
On 8/22/22 14:42, Richard Sharpe wrote:
Hi folks,
In trying to introduce my contexts approach
On 8/23/22 14:29, Richard Sharpe wrote:
On Tue, Aug 23, 2022 at 2:30 AM João Valverde wrote:
On 8/22/22 14:42, Richard Sharpe wrote:
Hi folks,
In trying to introduce my contexts approach for display filters to
handle embedded/recursive structures in 802.11 Information Elements
(TLVs) I
On 8/22/22 14:42, Richard Sharpe wrote:
Hi folks,
In trying to introduce my contexts approach for display filters to
handle embedded/recursive structures in 802.11 Information Elements
(TLVs) I came across this in epan/dfilter/scanner.l:
-
-
On 7/30/22 18:35, Richard Sharpe wrote:
On Fri, Jul 29, 2022 at 9:20 AM Richard Sharpe
wrote:
Hi folks,
The wonderful people working on 802.11 have started using recursive structures.
That is, they are embedding Info Elements (IEs) within Info Elements
and there can be multiple IEs of the
On 12/24/22 00:17, jayrturne...@gmail.com 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
This is not going to work as intended:
rawstr = tvb_format_text(pinfo->pool, tvb, offset, realsize - offset);
col_add_fstr(pinfo->cinfo, COL_INFO, "Reply: %s",
format_text_wsp(pinfo->pool, rawstr, realsize - offset));
The first call to tvb_format_text() already replaced "\n" with
Having the build directory under the source tree is still considered an
out-of-source build and is generally convenient and customary.
Having the support libraries path under the source tree is bad practice
however and the root cause for your errors, as already mentioned by others.
On
On 21/12/23 12:43, Bálint Réczey wrote:
Hi João,
On 2023. Dec 21., Thu at 12:02, João Valverde wrote:
On 20/12/23 23:20, Anders Broman wrote:
> Hi,
> To me it is a useful feature to be able to easily build .deb
packages
> and make repos to easily update and
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
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
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 package
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
On 20/12/23 22:35, Roland Knall wrote:
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
could be made better, I answered both times (IMO) and you
never replied back.
Just my 2 cents
Anders
Den ons 20 dec. 2023 23:49João Valverde skrev:
On 20/12/23 22:35, Roland Knall wrote:
>
>> Am 20.12.2023 um 22:43 schrieb João Valverde :
>>
>>
. 2023 um 12:36 Uhr schrieb João Valverde <mailto:j...@v6e.pt>>:
__
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
On 04/12/23 23:48, João Valverde wrote:
On 04/12/23 22:57, Gerald Combs wrote:
On 12/4/23 12:43 PM, João Valverde wrote:
https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
Gerald: "As far as I know the GPL doesn't plac
the 'install' target and transfer it as a
tarball.
You can use CPack for that now. Something like "cpack -G TZST
". Works really well in my opinion.
On Wed, Nov 22, 2023 at 1:12 PM Pascal Quantin
wrote:
Hi Joao,
Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :
s above,
as long as
they don't distribute the proprietary plugin. The GPL
violation only
happens if you distribute your plugin using an incompatible
license.
> Martin
>
>
>
> On Mon, Dec 4,
On 04/12/23 22:57, Gerald Combs wrote:
On 12/4/23 12:43 PM, João Valverde wrote:
On 04/12/23 18:45, Gerald Combs wrote:
The FAQ entry below makes it clear that developing an internal
version of Wireshark is permitted, and that "within an organization"
counts as "internal.&qu
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
Hi,
The GPL never allowed for that, as far as I know. See:
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
In this case Wireshark is a library for plug-ins.
What you can do is not distribute the (private-use) plug-in, and
therefore you do not have a requirement to make the source
On 04/12/23 10:09, Bálint Réczey wrote:
On 2023. Dec 4., Mon at 10:02, João Valverde wrote:
Hi,
The GPL never allowed for that, as far as I know. See:
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
In this case Wireshark is a library for plug-ins.
What you
long as
they don't distribute the proprietary plugin. The GPL violation only
happens if you distribute your plugin using an incompatible license.
> Martin
>
>
>
> On Mon, Dec 4, 2023 at 2:54 PM João Valverde wrote:
:
On Mon, Dec 4, 2023 at 9:53 AM João Valverde wrote:
On 04/12/23 14:32, Anders Broman wrote:
> Hi,
> Company plug-ins may have restrictive license as the purpose
is to
> only use them internally no public usage "secret" code for
violation only
happens if you distribute your plugin using an incompatible license.
Martin
On Mon, Dec 4, 2023 at 2:54 PM João Valverde wrote:
On 04/12/23 14:52, João Valverde wrote:
>
>
> On 04/12/23 14:32, Anders Broman wrote:
>> Hi,
>> Comp
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
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
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
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
ch 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 comitte
> >
> > 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 star
On 04/12/23 14:52, João Valverde wrote:
On 04/12/23 14:32, Anders Broman wrote:
Hi,
Company plug-ins may have restrictive license as the purpose is to
only use them internally no public usage "secret" code for
proprietary protocols under patents or IPL. Do we really want
al 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):
&g
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
On 22/11/23 13:12, Pascal Quantin wrote:
Hi Joao,
Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :
You are free to participate in the discussion or not. But I really
don't care to wait for the new committee that is pretty much
exactly the same as the old committee, as far
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
Really important work there... nothing gets me out of bed like
suppressing someone else's future potential needs using crappy tools and
methodologies.
This isn't a criticism of Debian. Use the Debian system if you like it,
don't use it if you don't.
It is a criticism of Debian in Wireshark,
So you want to discuss how to make it easier? We can do that. How do you
feel about the CPack Debian Generator?
On 22/11/23 12:38, Anders Broman wrote:
Hi,
I think that if you look at the commit history I have made my fair
share of updating the list in the past.
I was just trying to make
On 22/11/23 13:29, Pascal Quantin wrote:
Le mer. 22 nov. 2023 à 14:25, João Valverde a écrit :
On 22/11/23 13:12, Pascal Quantin wrote:
Hi Joao,
Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :
You are free to participate in the discussion or not. But I
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
On 22/11/23 14:39, João Valverde wrote:
On 22/11/23 13:12, Pascal Quantin wrote:
Hi Joao,
Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :
You are free to participate in the discussion or not. But I
really don't care to wait for the new committee that is pretty
much
On 22/11/23 13:12, Pascal Quantin wrote:
Hi Joao,
Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :
You are free to participate in the discussion or not. But I really
don't care to wait for the new committee that is pretty much
exactly the same as the old committee, as far
On 06/01/21 20:32, Dario Lombardo wrote:
Another user on SO suggested a fix
https://stackoverflow.com/questions/58255970/wireshark-dumpcap-with-setcap-set-to-no-root-capture-failes-to-start-in-ubuntu-1
On 14/06/21 22:01, Martin Nyhus wrote:
On 05/06/2021 02:33, João Valverde wrote:
But regarding your PoC having to give extern linkage to the internal
dissector code is a big drawback IMO, even if it isn't visible in a DLL
(because we use default hidden visibility when the compiler supports
On 16/06/21 15:36, David Perry wrote:
Sorry to drag up an old topic, but I've been thinking about this:
Message: 5
Date: Sat, 29 May 2021 09:32:29 +0200
From: Anders Broman
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Calling a dissector: Type for data
On 22/06/21 03:35, John Thacker wrote:
On Mon, Jun 21, 2021 at 9:28 PM João Valverde via Wireshark-dev
mailto:wireshark-dev@wireshark.org>> wrote:
On 22/06/21 01:26, John Thacker wrote:
> On Mon, Jun 21, 2021 at 2:21 PM João Valverde via Wireshark-dev
> mail
On 22/06/21 01:26, John Thacker wrote:
On Mon, Jun 21, 2021 at 2:21 PM João Valverde via Wireshark-dev
mailto:wireshark-dev@wireshark.org>> wrote:
On 16/06/21 15:36, David Perry wrote:
> Sorry to drag up an old topic, but I've been thinking about this:
>
&
On 15/06/21 05:02, João Valverde via Wireshark-dev wrote:
On 14/06/21 22:01, Martin Nyhus wrote:
On 05/06/2021 02:33, João Valverde wrote:
But regarding your PoC having to give extern linkage to the internal
dissector code is a big drawback IMO, even if it isn't visible in a DLL
(because
It would be nice to fix this in a way that could be used from Lua, to
make Lua dissectors first-class citizens and allow them to talk to C
dissectors (and vice-versa).
On 30/05/21 11:36, Graham Bloice wrote:
When I made that change to MQTT I failed to notice that it called
other dissectors
201 - 300 of 321 matches
Mail list logo
