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

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

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

ow the package 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 : >>

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

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? And

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

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

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

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 fr

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

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 packag

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

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

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

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

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

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

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

e is also nothing legally preventing someone from rebuilding     Wireshark with a modified source code to ignore the plugin license check     and forget the whole issue, in the same conditions as above, as long as     they don't distribute the proprietary plugin. The GPL violati

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

1Jeff Morriss skrev: 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 "se

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

Wireshark with a modified source code to ignore the plugin license check and forget the whole issue, in the same conditions as above, as long as they don't distribute the proprietary plugin. The GPL violation only happens if you distribute your plugin using an incompatible li

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

he 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 04/12/23 14:52, João Valverde wrote: > > > On 04/12/23 14:32, Anders Broman wrote:

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

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 to f

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

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

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

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

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

chnical 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):

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

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

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

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

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

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

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

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

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

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 ava

[Wireshark-dev] Changes to the plugin registration API

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 M

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

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

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

d Am Mi., 22. Nov. 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 fi

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

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 s

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

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

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

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, a

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

FIX, build 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 Va

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

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

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

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 f

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

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 the

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

gards 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 recen

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

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

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

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,

Re: [Wireshark-dev] 4.2.0 release schedule

.2. Not an issue to double submit, just a bit 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 b

Re: [Wireshark-dev] 4.2.0 release schedule

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: Sho

Re: [Wireshark-dev] 4.2.0 release schedule

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 migh

Re: [Wireshark-dev] 4.2.0 release schedule

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

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

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 04/05/2

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

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

Re: [Wireshark-dev] format_text_wsp() not working?

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 "\\n"

Re: [Wireshark-dev] display filter scanner.l possible weirdness

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 for

Re: [Wireshark-dev] display filter scanner.l possible weirdness

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

Re: [Wireshark-dev] display filter scanner.l possible weirdness

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: - - ([.][-+[:

Re: [Wireshark-dev] Filter expressions for recursive structures

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 s

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

er modelines 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 inde

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

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

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

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 oth

Re: [Wireshark-dev] On building better statistics

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 c

Re: [Wireshark-dev] On building better statistics

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.

Re: [Wireshark-dev] On building better statistics

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 bu

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

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 pl

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

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

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

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

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

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ã

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

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:

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

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 st

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

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.

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

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 man

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

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

Re: [Wireshark-dev] Issues with cross-compiling

ld: (.text+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 feedba

Re: [Wireshark-dev] Issues with cross-compiling

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 le

Re: [Wireshark-dev] wslog, windows, pytest, and heap corruption

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

Re: [Wireshark-dev] wslog, windows, pytest, and heap corruption

level), get_localtime(tstamp.tv_sec, &cookie), tstamp.tv_nsec, domain, level, file, line, func, user_format, user_ap); +   */ } A few weeks ago I worked with João Valverde o

Re: [Wireshark-dev] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

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", &sh

Re: [Wireshark-dev] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

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",     &show_soc_flags);     prefs_register_bool_preference(

Re: [Wireshark-dev] Errors building 3.7 plugins.

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 plugi

Re: [Wireshark-dev] Errors building 3.7 plugins.

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

Re: [Wireshark-dev] Errors building 3.7 plugins.

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 bringi

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

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 pr

Re: [Wireshark-dev] a bug or a feature

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 r

Re: [Wireshark-dev] Warning message when starting wireshark "color_filters.c:658 -- read_filters_file(): Could not compile "Checksum Errors" in colorfilters "

I will check. Sorry I missed this. On 08/10/21 11:56, Anders Broman via Wireshark-dev wrote: Hi, Top of trunk I get ** (wireshark:13228) 12:52:43.789284 [Epan WARNING] C:\Development\wireshark\epan\color_filters.c:658 -- read_filters_file(): Could not compile "Checksum Errors" in colorfilter

Re: [Wireshark-dev] Display filter field variables

gt; https://gitlab.com/wireshark/wireshark/-/commit/9865b6346f6442bc8326cde55e5f012250748131 <https://gitlab.com/wireshark/wireshark/-/commit/9865b6346f6442bc8326cde55e5f012250748131> On Fri, Oct 8, 2021 at 10:10 AM João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org&

[Wireshark-dev] Display filter field variables

Hi, The GUI display filter has an interesting but little-known (?) feature to replace field values for the selected frame with the syntax ${}, which I only learned about in bug #15504, and confused me at first. This all happens before the expression is compiled and is different from display f

Re: [Wireshark-dev] 3.6.0 release schedule

time well IMO. Thanks, Jaap On 7 Oct 2021, at 11:49, João Valverde via Wireshark-dev wrote: On 10/6/21 19:42, Jaap Keuter wrote: Hi, Are those wmem / pinfo->pool changes completed? Would be nice if that was consistent before branching. Is dfilter stabilised already? I don'

Re: [Wireshark-dev] On MR 4428

On 10/6/21 11:58, Jaap Keuter wrote: Hi, Looking at MR 4428 (cherry picked from commit 96cfaf67 ) it introduces a new symbol in the wiretap 11 library (wtap_uses_lua_filehandler). The debian symbols file contains the addition

Re: [Wireshark-dev] 3.6.0 release schedule

On 10/6/21 19:42, Jaap Keuter wrote: Hi, Are those wmem / pinfo->pool changes completed? Would be nice if that was consistent before branching. Is dfilter stabilised already? I don't really have a roadmap, I'm just taking a fresh look at the code for general improvements, bug fixing, learni

Re: [Wireshark-dev] New Warnings on Windows builds? Related to defilter changes?

It's related for sure, I will investigate, thanks. On 05/10/21 07:15, Anders Broman via Wireshark-dev wrote: Hi, Recently these warnings started to show up C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(49,1): warning C4005

Re: [Wireshark-dev] Unable to compile latest master

On 04/10/21 14:29, Ivan Nardi wrote: Hi I am not able to compile the latest master, even if I start from scratch (on ubuntu 20.04). Everything was fine until 1-2 weeks ago. ivan@ivan-Latitude-E6540:~/svnrepos/wireshark(master)$ mkdir wireshark-master-asan ivan@ivan-Latitude-E6540:~/svnrepos/wi

Re: [Wireshark-dev] Filtering USB HID fields

On 29/09/21 07:22, Tomasz Moń wrote: Hello, USB HID Usage Tables 1.22 specifies plenty of usages. Usages include for example, keyboard keys, LEDs, buttons, VR controls, etc. Usages are grouped into pages. There are plenty of usages, e.g. button page alone is 65536 items (0x means no button

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 31/07/21 01:56, Marco Davids (SIDN) wrote: Op 30-07-21 om 21:10 schreef João Valverde via Wireshark-dev: Also, I have not find any aggregate statistics just yet. But nevertheless still happy with this nice feature. The statistics for SLAAC/OUI don't exist. What I was trying to s

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 18:35, Marco Davids (SIDN) wrote: Op 30-07-21 om 17:29 schreef João Valverde: Address:    2001:db8::be05:43ff:fefb:281f translates into:    bc:05:43:fb:28:1f is:    'AVM GmbH' There is already an IPv6 "SA MAC" field in Wireshark that does wh

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 15:44, Marco Davids (SIDN) wrote: Hi João, Op 30-07-21 om 16:20 schreef João Valverde via Wireshark-dev: Address:    2001:db8::be05:43ff:fefb:281f translates into:    bc:05:43:fb:28:1f is:    'AVM GmbH' There is already an IPv6 "SA MAC" field in

Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

On 30/07/21 12:28, Marco Davids (SIDN) via Wireshark-dev wrote: Hello, I have an idea for a new feature in Wireshark and would like to hear your take on it: In Wireshark, under the 'Ethernet II'-section (when the 'name resolution' preference is set appropriately) the MAC addresses are 're

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 19:48, Evan Huus wrote: On Mon, Jul 12, 2021 at 14:42 João Valverde via Wireshark-dev mailto:wireshark-dev@wireshark.org>> wrote: On 12/07/21 19:13, Evan Huus wrote: > On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev > mailto:w

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 19:13, Evan Huus wrote: On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev wrote: On 12/07/21 16:52, Evan Huus wrote: I've been thinking recently about starting the process of getting rid of the "global" wmem scope methods (wmem_packet_scope, wmem_

Re: [Wireshark-dev] Replacing wmem_packet_scope() with pinfo->pool?

On 12/07/21 16:52, Evan Huus wrote: I've been thinking recently about starting the process of getting rid of the "global" wmem scope methods (wmem_packet_scope, wmem_file_scope, etc) in favour of passing them around in arguments (or in pinfo, or something). This would let us drop a bunch of in-

Re: [Wireshark-dev] Incorrect checksum calculation for UDP packet with ipv6 extension header

Hi, The final destination address for the packet is 505:505:505:505:505:505:505:505. Why would you think it is not? When the kernel is routing the packet (at 4ea1::::11) it does not look at the UDP checksum to accept/reject it. Regards, João On 7/8/21 7:56 PM, Hupfer, Michael via

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

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

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

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

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

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 parameter

Re: [Wireshark-dev] Unit testing dissector code

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 (be

Re: [Wireshark-dev] Unit testing dissector code

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 suppor

Re: [Wireshark-dev] Unit testing dissector code

Hi Martin, This is promising. I think dissecting a TVB and walking the proto_tree to assert the result is probably the way to go about implementing a dissector test suite (instead of reading a pcap with tshark and grepping the output). But regarding your PoC having to give extern linkage to

Re: [Wireshark-dev] Calling a dissector: Type for data parameter

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 wit

Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef

gitlab.com/constg2021/wireshark On 31/03/21 21:00, Gerald Combs wrote: Hi Constantine, You receivied the failure notice because: - You pushed a commit to gitlab.com/constg2021/wireshark. Was this for a merge request for wireshark/wireshark? From GitLab's perspective it dosen't matter. constg

Re: [Wireshark-dev] File rename impacts Gitlab history

On 26/02/21 16:48, chuck c wrote: https://gitlab.com/wireshark/wireshark/-/commit/50dbe4df7fd7a5e4e1a27fd5046981486d350994 Rename packet-ssl* to packet-tls* Looking through history of https://gitlab.com

Re: [Wireshark-dev] Dissector functions and variables that could be static

Hi Martin, As you said some functions may only be used by third party plugins so indiscriminately removing every exported but not used function would be a bad policy. Even if they're not actually being used right now, who knows, they may be part of some public API for plugins, so for use as n

Re: [Wireshark-dev] Setcap in ubuntu 20.04

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

  1   2   3   4   >