[Wireshark-dev] zlib-ng, test suites failing

[Anders Broman]

Hi,
MR https://gitlab.com/wireshark/wireshark/-/merge_requests/15869 is failing
in the test suites and I'm having a hard time figuring out why. Running
tshark --version in the RelWithdebinfo or Debug dirs works for me locally.
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

Re: [Wireshark-dev] Finding zlib-ng on MacOS?

[Anders Broman]

Den tors 6 juni 2024 kl 01:41 skrev Guy Harris :

> On Jun 5, 2024, at 11:07 AM, Anders Broman  wrote:
>
> > Th MR https://gitlab.com/wireshark/wireshark/-/merge_requests/15869
> > is failing to build. I'm guessing the FindZLIBNG.cmake is not finding
> the library(?)
>
> Nope:
>
> -- Checking for one of the modules 'zlib'
> -- Found ZLIB: /Applications/
> Xcode-14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/lib/libz.tbd
> -- Looking for inflate
> -- Looking for inflate - found
> -- Looking for inflatePrime
> -- Looking for inflatePrime - found
> -- Checking for one of the modules 'zlib-ng'
> -- Found ZLIBNG: /opt/homebrew/Cellar/zlib-ng/2.1.6/lib/libz-ng.dylib
> -- Looking for zng_gzopen
> -- Looking for zng_gzopen - found
>
> It's finding both zlib (as shipped with the system) *and* zlib-ng (as
> installed by Homebrew).
>
> What appears to be happening is that it's including both the zlib and
> zlib-ng headers, and getting a collision because they're defining the same
> typedef and redefining the same structure:
>
> In file included from
> /Users/gitlab/builds/wireshark/wireshark/wsutil/version_info.c:36:
> /opt/homebrew/include/zlib-ng.h:1079:20: error: typedef redefinition with
> different types ('uint32_t (*)(void *, const uint8_t **)' (aka 'unsigned
> int (*)(void *, const unsigned char **)') vs 'unsigned int (*)(void *,
> unsigned char **)')
> typedef uint32_t (*in_func) (void *, const uint8_t * *);
> ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/zlib.h:1102:20:
> note: previous definition is here
> typedef unsigned (*in_func) OF((void FAR *,
> ^
> In file included from
> /Users/gitlab/builds/wireshark/wireshark/wsutil/version_info.c:36:
> /opt/homebrew/include/zlib-ng.h:1792:8: error: redefinition of 'gzFile_s'
> struct gzFile_s {
> ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/zlib.h:1839:8:
> note: previous definition is here
> struct gzFile_s {
> ^
> 2 errors generated.
>
> Is there some particular reason why we search for zlib *and* zlib-ng,
> rather than, for example, searching for zlib-ng and, if we don't find it,
> searching for zlib, with some -D option to tell it not to look for zlib-ng?
>

The only reason for not going for zlib-ng only if it's available was
starting out with a partial implementation and being able to build during
development. Now it builds with zlib-ng only
but there is some problem with the updated dependency libraries on Windows
still.
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

[Wireshark-dev] Finding zlib-ng on MacOS?

[Anders Broman]

Hi,
Th MR https://gitlab.com/wireshark/wireshark/-/merge_requests/15869
is failing to build. I'm guessing the FindZLIBNG.cmake is not finding the
library(?)
could someone with a Mac help out?
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

Re: [Wireshark-dev] CI not running for vcpkg commit?

[Anders Broman]

I did try to start it manually but it complained about no runners available
for the label.

Den ons 29 maj 2024 21:33Alexis La Goutte  skrev:

> Hi Anders,
>
> is it not by Desgin ?
>
> You need to manual start the job ?
>
> On Wed, May 29, 2024 at 2:34 PM Anders Broman 
> wrote:
>
>> Hi,
>> It looks like there is a problem with th CI job at:
>>
>> https://gitlab.com/wireshark/wireshark-vcpkg-scripts/-/jobs/6968885748
>>
>> Any ideas?
>> 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
>
___
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] CI not running for vcpkg commit?

[Anders Broman]

Hi,
It looks like there is a problem with th CI job at:

https://gitlab.com/wireshark/wireshark-vcpkg-scripts/-/jobs/6968885748

Any ideas?
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

[Wireshark-dev] Use zlib-ng? or cloudflare version?

[Anders Broman]

Hi,
Can we add zlib-ng to our windows vcpkg? It is available.
Ref https://github.com/zlib-ng/zlib-ng/blob/develop/README.md

It would be interesting to benchmark it.
Best regards
Anders

P.S in this article https://blog.cloudflare.com/cloudflare-fights-cancer

"..

   - Using an improved hash function - we use the iSCSI CRC32
    function as the hash function in
   our zlib. This specific function is implemented as a hardware instruction
   on Intel processors. It has very fast performance and better collision
   properties..."

Could that be of use in some of our hashtables?
___
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] MacOS Intel builds failing

[Anders Broman]

Hi,
The builds has been failing for a while:
https://gitlab.com/wireshark/wireshark/-/pipelines/1251569220

Found @rpath/libbcg729.0.dylib in /usr/local/lib
Found @rpath/libsnappy.1.dylib in /usr/local/lib
Found @rpath/libssh.4.dylib in /usr/local/lib
ERROR: Cannot resolve rpath "@rpath/Sparkle.framework/Versions/B/Sparkle"
ERROR:  using QList("/usr/local/Sparkle-2.2.2",
"/usr/local/Qt-6.5.3/lib",
"/Users/tuexen/builds/etFJV6Z4P/0/wireshark/wireshark/build/run")
ERROR: Cannot resolve rpath "@rpath/libsnappy.1.dylib"
ERROR:  using QList("/usr/local/Sparkle-2.2.2",
"/usr/local/Qt-6.5.3/lib",
"/Users/tuexen/builds/etFJV6Z4P/0/wireshark/wireshark/build/run")
Log:


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

Re: [Wireshark-dev] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

[Anders Broman]

Hi,
Yes you can contact me privately for further discussions if you want.
Best regards
Anders

Den tis 2 apr. 2024 kl 23:57 skrev R Massink :

> Hi Anders,
>
> That is awesome! I must admit I was not familiar enough with the .asn and
> asn2wrs decoder to see how much I could do there. Therefore most of my code
> was outside of that part, but your approach is much cleaner.
>
> If it's ok, I'd like to discuss directly how I can help to get more of the
> mapping integrated and to collaborate to get a more mature version of what
> I produced that might be eligible for merging as well.
>
> Thanks again
>
> Best regards,
>
> Robin
>
> On Tue, Apr 2, 2024 at 11:28 PM Anders Broman 
> wrote:
>
>> Hi,
>> I took a stab at integrating some of it into the MMS dissector
>> https://gitlab.com/wireshark/wireshark/-/merge_requests/15113. As far as
>> I understand it,this will only decode "proper IEC 61850" fields.
>>
>> Best regards
>> Anders
>>
>> Den sön 24 mars 2024 kl 19:41 skrev R Massink :
>>
>>> Hello,
>>>
>>> I've created an initial version of an IEC-61850 dissector for wireshark.
>>> It is available here: https://github.com/robidev/iec61850-dissector.
>>> IEC-61850 is a mapping on top of MMS that uses a subset of MMS PDU's for
>>> its purpose; substation communication.
>>>
>>> While an MMS dissector, which IEC-61850 maps onto already exists, this
>>> MMS dissector lacks a lot of IEC-61850  specific context. For example, an
>>> unconfirmed-PDU in MMS, may in IEC-61850 be a Report, CommandTermination or
>>> Addcause. Each of these messages in turn may contain fields with specific
>>> meaning in the context of the protocol-mapping(e.g. first entry shall be
>>> ReportID, second field defines included optional fields that in turn define
>>> the field-names of subsequent entries). This type of information is quite
>>> hard to decode from the pure MMS packet, and therefore I created this
>>> dissector to assist with the IEC-61850 context-specific encoding.
>>>
>>> However, I am wondering if I did the integration right. As I need
>>> additional information during the MMS parsing to properly identify the
>>> correct IEC-61850 field, I have copied the MMS parser code, and included
>>> extra hooks to provide this information in a private structure during the
>>> BER decoding. Then during the actual mapping routines, I try to identify if
>>> it is a valid IEC-61850 packet, and if so, I add an additional IEC-61850
>>> layer below the MMS entry in the dissector tree and replace the INFO column
>>> with IEC-61850 related information (e.g. an MMS 'read' request/response is,
>>> based on context a GetDataValue, or GetRCBValue, or ..). When the packet is
>>> not recognised as a known IEC-61850 service, the original (wireshark
>>> native) MMS dissector is called via call_dissector(), and no further
>>> processing happens. Also a setting(via prefs_register_bool_preference) is
>>> provided to stop any attempt to decode IEC-61850, and hand off the packet
>>> to the MMS dissector early if desired.
>>>
>>> Does anyone have suggestions on how this integration may be handled more
>>> elegantly?(i.e. not first calling my MMS function, before handing it back
>>> to the original one?) As I now replace the MMS dissector, and hand
>>> processing back if I conclude the packet was not IEC-61850. I had a look at
>>> heuristics, PINO's and the decode-as functionality. But these did not match
>>> for various technical reasons. The heuristic function is not an option, as
>>> the hook for the dissector is via
>>> register_ber_oid_dissector("1.0.9506.2.3",), and it seems to me "decode
>>> as" does not allow to replace the MMS dissector. PINO seem to solve a
>>> different issue(as far as I understood).
>>>
>>> Or would my current solution be an acceptable approach to allow for a
>>> pull request in the future for merging this into the main wireshark branch?
>>> (assuming other conditions are met)
>>>
>>> Best regards,
>>>
>>> Robin
>>>
>>> ___
>>> 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] Advice on how to integra IEC-61850 protocol mapping onto the existing MMS dissector

[Anders Broman]

Hi,
I took a stab at integrating some of it into the MMS dissector
https://gitlab.com/wireshark/wireshark/-/merge_requests/15113. As far as I
understand it,this will only decode "proper IEC 61850" fields.

Best regards
Anders

Den sön 24 mars 2024 kl 19:41 skrev R Massink :

> Hello,
>
> I've created an initial version of an IEC-61850 dissector for wireshark.
> It is available here: https://github.com/robidev/iec61850-dissector.
> IEC-61850 is a mapping on top of MMS that uses a subset of MMS PDU's for
> its purpose; substation communication.
>
> While an MMS dissector, which IEC-61850 maps onto already exists, this MMS
> dissector lacks a lot of IEC-61850  specific context. For example, an
> unconfirmed-PDU in MMS, may in IEC-61850 be a Report, CommandTermination or
> Addcause. Each of these messages in turn may contain fields with specific
> meaning in the context of the protocol-mapping(e.g. first entry shall be
> ReportID, second field defines included optional fields that in turn define
> the field-names of subsequent entries). This type of information is quite
> hard to decode from the pure MMS packet, and therefore I created this
> dissector to assist with the IEC-61850 context-specific encoding.
>
> However, I am wondering if I did the integration right. As I need
> additional information during the MMS parsing to properly identify the
> correct IEC-61850 field, I have copied the MMS parser code, and included
> extra hooks to provide this information in a private structure during the
> BER decoding. Then during the actual mapping routines, I try to identify if
> it is a valid IEC-61850 packet, and if so, I add an additional IEC-61850
> layer below the MMS entry in the dissector tree and replace the INFO column
> with IEC-61850 related information (e.g. an MMS 'read' request/response is,
> based on context a GetDataValue, or GetRCBValue, or ..). When the packet is
> not recognised as a known IEC-61850 service, the original (wireshark
> native) MMS dissector is called via call_dissector(), and no further
> processing happens. Also a setting(via prefs_register_bool_preference) is
> provided to stop any attempt to decode IEC-61850, and hand off the packet
> to the MMS dissector early if desired.
>
> Does anyone have suggestions on how this integration may be handled more
> elegantly?(i.e. not first calling my MMS function, before handing it back
> to the original one?) As I now replace the MMS dissector, and hand
> processing back if I conclude the packet was not IEC-61850. I had a look at
> heuristics, PINO's and the decode-as functionality. But these did not match
> for various technical reasons. The heuristic function is not an option, as
> the hook for the dissector is via
> register_ber_oid_dissector("1.0.9506.2.3",), and it seems to me "decode
> as" does not allow to replace the MMS dissector. PINO seem to solve a
> different issue(as far as I understood).
>
> Or would my current solution be an acceptable approach to allow for a pull
> request in the future for merging this into the main wireshark branch?
> (assuming other conditions are met)
>
> Best regards,
>
> Robin
> ___
> 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] Running test_tls13_rfc8446 manually

[Anders Broman]

Hi,
I'm trying to figure out why the pipline for
https://gitlab.com/wireshark/wireshark/-/merge_requests/14615 fails but
can't get the syntax right:
C:\development\build\run\RelWithDebInfo\tshark.exe -r
C:\development\wireshark\test\captures\tls13-rfc8446.pcap
-otls.keylog_file:{C:\development\wireshark\test\keystls13-rfc8446-noearly.keys}
-Y http -Tfields -e frame.number -e http.request.uri -e http.file_data
sort of works but not sure the decryption works
C:\development\build\run\RelWithDebInfo\tshark.exe -r
C:\development\wireshark\test\captures\tls13-rfc8446.pcap
-otls.keylog_file:{C:\development\wireshark\test\keystls13-rfc8446-noearly.keys}
-Y http -Tfields -e frame.number -e http.request.uri -e http.file_data -E
separator=|
fails for some reason.

Running out of time today :-)

Best regards
Andeers
___
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

[Anders Broman]

Den tors 21 dec. 2023 12:03João Valverde  skrev:

>
> 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 maintain wireshark across servers.
> > This is a feature I vote for us to keep regardless of any opinion on
> > how Debian build their packages. Maybe a Debian mailing list is a
> > better place to discuss their build system?
>
> I don't know what that has anything to do with what I said below but
> that is totally fine. I'm not against a Debian package. I'm against
> mirroring Debian in this project. I note you already asked me twice how
> the package could be made better, I answered both times (IMO) and you
> never replied back.
>
> And what I'm saying is that I find it convenient to have the script and
> that I would like us to keep them. As for how to improve the scripts I did
> not intend to work on them myself. Sorry if you felt I should have
> acknowledged in any way.
>

Best regards
Anders

>
>
> > 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 :
> > >>
> > >> 
> > >>
> > >>> 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 what such way is that?! I don't even know why libvirt keeps
> > coming
> > up in this discussion. They wrote a dissector plugin. That's
> > great. Good
> > for them. I don't upstream many of my plugins into Wireshark either.
> > This is something so banal that I am honestly confused why libvirt
> > keeps
> > coming up as a big boogaloo in this discussion.
> >
> > I ask again in all sincerity, because I could be misunderstanding,
> > what
> > is the difficulty created by the libvirt plugin and what does that
> > have
> > to do with Debian packaging?
> >
> >
> > >>
> >
>  

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

[Anders Broman]

Hi,
To me it is a useful feature to be able to easily build .deb packages and
make repos to easily update and maintain wireshark across servers. This is
a feature I vote for us to keep regardless of any opinion on how Debian
build their packages. Maybe a Debian mailing list is a better place to
discuss their build system?
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 :
> >>
> >> 
> >>
> >>> 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 what such way is that?! I don't even know why libvirt keeps coming
> up in this discussion. They wrote a dissector plugin. That's great. Good
> for them. I don't upstream many of my plugins into Wireshark either.
> This is something so banal that I am honestly confused why libvirt keeps
> coming up as a big boogaloo in this discussion.
>
> I ask again in all sincerity, because I could be misunderstanding, what
> is the difficulty created by the libvirt plugin and what does that have
> to do with Debian 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
>
___
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] Changes to the plugin registration API

[Anders Broman]

Not answering the statement
"Not the right thing to do"

Den mån 4 dec. 2023 17:44João Valverde  skrev:

>
>
> On 04/12/23 16:30, Anders Broman wrote:
> >
> https://www.google.com/search?q=company+internal+use+of+gpl+code=company+internal+use+of+gpl+code_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigAdIBCTIxMDcwajFqN6gCALACAA=ms-android-samsung-ss=chrome-mobile=UTF-8_dse_attribution=1
> > <
> https://www.google.com/search?q=company+internal+use+of+gpl+code=company+internal+use+of+gpl+code_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigAdIBCTIxMDcwajFqN6gCALACAA=ms-android-samsung-ss=chrome-mobile=UTF-8_dse_attribution=1>
>
> >
> >
> > For me it is no problem circumventing your code. I'm just questioning
> > if it is the right thing for the project to do.
>
> I said "legally" preventing. Obviously technically anyone can circumvent
> it.
>
> > That's it from me.
> > Regards
> > Anders
> >
> > Den mån 4 dec. 2023 17:24João Valverde  skrev:
> >
> >
> >
> > On 04/12/23 15:55, Martin Mathieson via Wireshark-dev wrote:
> > > I have been doing internal Wireshark releases for years wherever
> > I've
> > > been working (as far as I know, they have never been sent
> > outside of
> > > the company).  I have *never* used the plugin mechanism. I
> > package up
> > > the entire program, even if only one file has been changed.  My
> > > current company has acquired and merged with several other
> > companies
> > > and development groups - as far as I can tell, they all have a
> > local
> > > Wireshark person who does the same.  If people are working
> > > closely with me, we sometimes even just keep dissectors as part
> > of the
> > > test code for the project that uses them, and team members build it
> > > themselves.
> > >
> > > Am I allowed to do this?
> >
> > In a strict legal sense I don't think you can use a GPL-incompatible
> > license for your changes, but it doesn't really matter as long as you
> > don't distribute it. Otherwise what does it matter which license
> > it uses
> > or if it doesn't have a license at all? There is no one to license it
> > to. You are the only one using it and the GPL grants you the right to
> > modify the software. You can grant yourself only a GPL-license for
> > your
> > modifications and no one else if it gives you peace of mind. :-)
> >
> > AFAIK there 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 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,
> > > >> 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
> > > >> forbid that? In that case why should companies provide
> > code to
> > > >> Wireshark rather than just fork and build internally.
> > > >
> > > > I understand the argument and why that is a point of
> > contention,
> > > but
> > > > that does not change the terms of the GPL which must be
> abided
> > > by even
> > > > if this commit was never merged in the first place.
> > > >
> > > > I don't think it is a question of whether we want to
> > forbid it,
> > > it is
> > > > whether we can allow it. I believe the answer to that is a
> > clear
> > > no if
> > > > we want to respect the terms of the GPLv2 (and I'm fine with
> > > that). I
> > > &

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

[Anders Broman]

https://www.google.com/search?q=company+internal+use+of+gpl+code=company+internal+use+of+gpl+code_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigAdIBCTIxMDcwajFqN6gCALACAA=ms-android-samsung-ss=chrome-mobile=UTF-8_dse_attribution=1

For me it is no problem circumventing your code. I'm just questioning if it
is the right thing for the project to do.
That's it from me.
Regards
Anders

Den mån 4 dec. 2023 17:24João Valverde  skrev:

>
>
> On 04/12/23 15:55, Martin Mathieson via Wireshark-dev wrote:
> > I have been doing internal Wireshark releases for years wherever I've
> > been working (as far as I know, they have never been sent outside of
> > the company).  I have *never* used the plugin mechanism. I package up
> > the entire program, even if only one file has been changed.  My
> > current company has acquired and merged with several other companies
> > and development groups - as far as I can tell, they all have a local
> > Wireshark person who does the same.  If people are working
> > closely with me, we sometimes even just keep dissectors as part of the
> > test code for the project that uses them, and team members build it
> > themselves.
> >
> > Am I allowed to do this?
>
> In a strict legal sense I don't think you can use a GPL-incompatible
> license for your changes, but it doesn't really matter as long as you
> don't distribute it. Otherwise what does it matter which license it uses
> or if it doesn't have a license at all? There is no one to license it
> to. You are the only one using it and the GPL grants you the right to
> modify the software. You can grant yourself only a GPL-license for your
> modifications and no one else if it gives you peace of mind. :-)
>
> AFAIK there 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 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,
> > >> 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
> > >> forbid that? In that case why should companies provide code to
> > >> Wireshark rather than just fork and build internally.
> > >
> > > I understand the argument and why that is a point of contention,
> > but
> > > that does not change the terms of the GPL which must be abided
> > by even
> > > if this commit was never merged in the first place.
> > >
> > > I don't think it is a question of whether we want to forbid it,
> > it is
> > > whether we can allow it. I believe the answer to that is a clear
> > no if
> > > we want to respect the terms of the GPLv2 (and I'm fine with
> > that). I
> > > am not a license lawyer so this is just my understanding of the
> > > legalities involved.
> > >
> > ...nor any other kind of lawyer. :-)
> >
> > > There are many reasons why companies may choose to contribute or
> > not.
> > > Other companies may choose not to contribute to projects not
> > using the
> > > GPL. And individual developers may or may not want to
> > contribute. Etc.
> > > We can also debate that but it might veer off-topic.
> > >
> > >> Best regards
> > >
> > >> A ders
> > >>
> > >> Den mån 4 dec. 2023 15:22João Valverde  skrev:
> > >>
> > >>
> > >>
> > >> On 04/12/23 13:42, Anders Broman wrote:
> > >> > Hi,
> > >> > Maybe you are missing the point that someone may wish to
> > develop
> > >> an in
> > >> > house plug-in not meant for distribution which in my
> > >> understanding is
> > >> > permissible under GPL.
> > >>
> > >> My understanding is that this is permitted under the GPL if
> > using a
> &g

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

[Anders Broman]

Hi,
My understanding of the GPL is that for company internal additions to GPL
SW there is no obligation to GPL those changes nor distribute any SW copy.

Regardless I question why we should make it harder for people to do private
plug-ins. Isn't the mission statement take it easier to understand what's
going on in your network. Surely it applies to companies too. Why should we
play lawyers? Sue the ones breaking the license.
 Best regards
Anders

Den mån 4 dec. 2023 17:11Jeff 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 "secret" code for proprietary
>> > protocols under patents or IPL. Do we really want to forbid that? In
>> > that case why should companies provide code to Wireshark rather than
>> > just fork and build internally.
>>
>> I understand the argument and why that is a point of contention, but
>> that does not change the terms of the GPL which must be abided by even
>> if this commit was never merged in the first place.
>>
>> I don't think it is a question of whether we want to forbid it, it is
>> whether we can allow it. I believe the answer to that is a clear no if
>> we want to respect the terms of the GPLv2 (and I'm fine with that). I am
>> not a license lawyer so this is just my understanding of the legalities
>> involved.
>>
>
> I agree: I think the GPL is pretty clear here and AFAIK we don't grant an
> exception.
>
> That being said, when I used to create custom/proprietary dissectors
> (that, frankly, were only of interest to people working for my employer),
> those dissectors were (intentionally) GPL.  Any co-employee (to whom I gave
> the binary) was free to have the source code (and also free to do what they
> want with it).  Since there was genuinely no concern about them sharing
> said source code (no real risk if they did, but also no reason for them to
> do it), no additional restrictions were put in place.
>
> If, OTOH, there were significant secrets or proprietary information in
> those dissectors, one could *imagine* that those co-employees/users might
> have had an additional *condition of employment* (or similar, as long as
> it does not affect the source license!) that they do not share this
> proprietary code.  I believe this is similar to how Red Hat is getting away
> with restricting access to RHEL source code: the software license says you
> can do what you want with it, but if you share it then Red Hat is free to
> revoke your support contract (or whatever).
>
> ___
> 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] Changes to the plugin registration API

[Anders Broman]

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 forbid that? In that case why
should companies provide code to Wireshark rather than just fork and build
internally.
Best regards
A ders

Den mån 4 dec. 2023 15:22João Valverde  skrev:

>
>
> On 04/12/23 13:42, Anders Broman wrote:
> > Hi,
> > Maybe you are missing the point that someone may wish to develop an in
> > house plug-in not meant for distribution which in my understanding is
> > permissible under GPL.
>
> My understanding is that this 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
> > > 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 topi

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

[Anders Broman]

Hi,
Maybe you are missing the point that someone may wish to develop an in
house plug-in not meant for distribution which in my understanding is
permissible under GPL.

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

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

[Anders Broman]

Hi,
Does this mean that we are no longer allowing private closed source
plug-ins not distributed outside of companies?

If so isn't that a rather big change of policy?

Best regards
Anders

Den mån 4 dec. 2023 00:26João Valverde  skrev:

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

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

[Anders Broman]

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 point that some found it useful to be able to
build Deb packages and it might be more fruitful to discuss how that could
be made easier? I think today the script tells you what symbols are missing
perhaps it could just update the list, as an example.
Best regards
Anders

Den ons 22 nov. 2023 12:36João Valverde  skrev:

> 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

[Anders Broman]

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

[Wireshark-dev] Enable all protocols -> restore default.

[Anders Broman]

Hi,
I just found "Spirent Test Center Signature" at the end of a packet
pointing to bytes near the end
of the packet. Debugging I found that it is a post dissector defaulted to
"disabled" I had not enabled it so here's what I think has happened.
Recently I was disabling some protocols testing a bug report. When
finishing I "restored" by enabling all protocols. Seemingly that enables
protocols
that were previously disabled by default which was somewhat unexpected. I
think we would need a factory reset button or similar.
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

[Wireshark-dev] HTTP3 for Windows

[Anders Broman]

Hi,
I'm trying to compile the HTTP3 dissector from
https://gitlab.com/wireshark/wireshark/-/merge_requests/9330 but it will
require the NGHTTP3 package from https://vcpkg.io/en/packages could someone
add it to the packages repo please? While at it it might be good to update
the NGHTTP2 package to 1.55.2.

I downloaded the MR as a patch and applied that and fixed build warnings on
Windows the macos setup .sh patch did not apply cleanly.
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

Re: [Wireshark-dev] View file internals?

[Anders Broman]

Yes, thanks.
Anders

Den tors 10 aug. 2023 15:41Maynard, Chris via Wireshark-dev <
wireshark-dev@wireshark.org> skrev:

> I think you’re looking for View -> Reload as File Format/Capture
> (Ctrl+Shift+F).
>
> - Chris
>
>
>
> *From:* Wireshark-dev  *On Behalf Of
> *Anders Broman
> *Sent:* Thursday, August 10, 2023 8:27 AM
> *To:* Developer support list for Wireshark 
> *Subject:* [Wireshark-dev] View file internals?
>
>
>
> Hi,
>
> How do you open a file to view the internals? I have forgotten how...
>
> Best regards
>
> Anders
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This message is the property of International Game
> Technology PLC and/or its subsidiaries and may contain proprietary,
> confidential or trade secret information. This message is intended solely
> for the use of the addressee. If you are not the intended recipient and
> have received this message in error, please delete this message from your
> system. Any unauthorized reading, distribution, copying, or other use of
> this message or its attachments is strictly prohibited.
> ___
> 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] View file internals?

[Anders Broman]

Hi,
How do you open a file to view the internals? I have forgotten how...
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

[Wireshark-dev] Pending LUA MRs

[Anders Broman via Wireshark-dev]

Hi,
Can some one familiar with LUA please look at the LUA MRs I have tried to put 
labels on LUA related MRs. Non core developers can assist by leaving comments.
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

[Wireshark-dev] LUA MRs

[Anders Broman]

Hi,

Can someone familiar with LUA please look at the LUA MRs I have tried to
put labels on LUA related MRs. Non core developers can assist by leaving
comments.

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

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

[Anders Broman]

Hi,
Good catch, thanks.
Best regards
Anders

Den tis 15 nov. 2022 kl 15:57 skrev João Valverde :

> 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".
> The second call to format_text_wsp() never sees a newline and does nothing.
>
> On 11/15/22 08:41, Anders Broman wrote:
> > Hi,
> > I encountered strange problem with
> >
> > https://gitlab.com/wireshark/wireshark/-/merge_requests/8848
> > packet 2 of the included trace causes a call to
> > col_add_fstr(pinfo->cinfo, COL_INFO, "Reply: %s",
> > format_text_wsp(pinfo->pool, rawstr, realsize - offset));
> > But it seems like the /n is not replaced with space using the
> > debugger. It seems like the call to
> > format_text_internal() does not propagate "TRUE" ???
> > char *
> > format_text_wsp(wmem_allocator_t* allocator, const char *string,
> > size_t len)
> > {
> > return format_text_internal(allocator, string, len, TRUE);
> > }
> > Any ideas?
> >
> > 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
>
___
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] format_text_wsp() not working?

[Anders Broman]

Hi,
I encountered strange problem with

https://gitlab.com/wireshark/wireshark/-/merge_requests/8848
packet 2 of the included trace causes a call to
col_add_fstr(pinfo->cinfo, COL_INFO, "Reply: %s",
format_text_wsp(pinfo->pool, rawstr, realsize - offset));
But it seems like the /n is not replaced with space using the debugger. It
seems like the call to
format_text_internal() does not propagate "TRUE" ???
char *
format_text_wsp(wmem_allocator_t* allocator, const char *string, size_t len)
{
return format_text_internal(allocator, string, len, TRUE);
}
Any ideas?

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

[Wireshark-dev] Strange font size on Windows.

[Anders Broman]

Hi,
Not sure if it is related but after using Wireshark on the laptops display
I get a strange large
font in the panes when back on my two high resolution monitors. If I look
in the preferences is says font Consolas 22. if I try to change that it
rescans the whole packet list - super annoying as I have a very large file
loaded - and then doesn't change the font. Anyone else seeing this?
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

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

[Anders Broman]

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

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

[Anders Broman]

Thanks for the MR Roland.
Best regards
Anders

Den fre 30 sep. 2022 16:41Jeff Morriss  skrev:

>
> On Fri, Sep 30, 2022 at 5:50 AM Dario Lombardo  wrote:
>
>> 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.
>>
>
> FWIW, their policy makes a lot of sense to me.  As a user of an EL, I want
> stability first and foremost but I also want security updates (keep in mind
> that here "stability" doesn't mean "it doesn't crash," it means "it behaves
> the same").  I can't imagine any Linux vendor could keep up with questions
> like "what will break (or what behavior will change) if we bump our
>  version from  to ?" for every one of the thousands of
> packages they include.  But they can take security patches and apply them
> to the older package source code.  Some won't apply directly which creates
> more work but the vast majority of the time it's a massive time saver.
>
> At some level we (as individuals) need to trust/offload the security work
> to the EL (or any other OS) vendor, mainly because we don't have the
> resources go track all the CVE stuff.  Those with more resources
> (companies) can simply pay for a product that (automatically?) takes in all
> the CVE inputs and tells you if your OS (EL or otherwise) has any
> open/unpatched vulnerabilities.  Those products know that CVE X is patched
> in EL8 package P patch level 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

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

[Anders Broman]

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 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)?
>>>>&g

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

[Anders Broman]

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

[Anders Broman]

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

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

[Anders Broman]

Hi,
Thanks guys, I actually found an RPM for 1.14.0
https://cbs.centos.org/koji/buildinfo?buildID=36063 but I might go for 1.13
in the next build.
Best regards
Anders

Den ons 28 sep. 2022 kl 18:48 skrev 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

[Wireshark-dev] CARES to old for CentOS8?

[Anders Broman]

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

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

Re: [Wireshark-dev] Create tshark rpm

[Anders Broman]

Hi,
Thanks Chuck for the reference, this did the tric:
--- a/packaging/rpm/wireshark.spec.in
+++ b/packaging/rpm/wireshark.spec.in
@@ -65,7 +65,11 @@ Source:
https://www.wireshark.org/download/src/OneWireshark-%{package_version}.
 URL:   https://www.wireshark.org/
 Packager:  Gerald Combs 

+%if 0%{?rhel} && ( 0%{?rhel} <= 7 )
+BuildRequires: cmake3 >= 3.10
+%else
 BuildRequires: cmake >= 3.10
+%endif
 BuildRequires: python3
 %if %{with toolchain_clang}
 BuildRequires: clang
@@ -281,7 +285,12 @@ development of Wireshark scripts and plugins.
 # Fedora's new RPATH hardening means we need to enable $ORIGIN if the
 # prefix is anything other than /usr:
 # https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild
+%if 0%{?rhel} && ( 0%{?rhel} <= 7 )
+cmake3 \
+  -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \
+%else
 %cmake \
+%endif
 %if 0%{?fedora} && ( "%{_prefix}" != "/usr" )
   -DENABLE_RPATH_ORIGIN=ON \
 %endif

@jeff.morriss...@gmail.com  i got cmake3 from
epel I believe
yum-config-manager --enable base epel extras updates
yum install cmake3
Built from source:
c-ares-1.14.0
libgcrypt-1.10.1
ibgpg-error-1.27

Best regards
Anders

Den fre 19 aug. 2022 kl 17:49 skrev chuck c :

> Similar error message:
> https://gitlab.com/wireshark/wireshark/-/issues/17354
>
> Changes to rhel7 cmake requirements:
>
> https://gitlab.com/wireshark/wireshark/-/commit/0676ddfb4f37af4c805c0e5c2112e131669e6375
>
> On Fri, Aug 19, 2022 at 10:26 AM Anders Broman 
> wrote:
>
>> Hi,
>> Yes that did the trick now stuck on
>> Create a rpm from the current git commit.
>> error: Failed build dependencies:
>> cmake >= 3.10 is needed by
>> wireshark-4.1.0rc0.5120_gc67cdc0514d9_Ericsson-1.x86_64
>> make[3]: *** [CMakeFiles/wireshark_rpm] Error 1
>> make[2]: *** [CMakeFiles/wireshark_rpm.dir/all] Error 2
>> make[1]: *** [CMakeFiles/wireshark_rpm.dir/rule] Error 2
>> make: *** [wireshark_rpm] Error 2
>> [root@wireshark-build-server-inst-site1 build]# cmake --version
>> cmake3 version 3.17.5
>>
>> Used alternatives as suggested here:
>>
>> https://stackoverflow.com/questions/48831131/cmake-on-linux-centos-7-how-to-force-the-system-to-use-cmake3
>>
>> Regards
>> Anders
>>
>>
>> Den fre 19 aug. 2022 kl 17:07 skrev chuck c :
>>
>>> https://www.wireshark.org/docs/wsdg_html/#ChSrcRpm
>>>
>>> Should the target be wireshark_rpm?
>>>
>>> On Fri, Aug 19, 2022 at 9:23 AM Anders Broman 
>>> wrote:
>>>
>>>> Hi,
>>>> I'm trying to build a tshark RPM on Centos7 after manually building
>>>> some required packages
>>>> l(ibcryp c-ares) the build works
>>>> cmake3 -G "Unix Makefiles" ../source -DBUILD_wireshark=OFF
>>>> make (successful)
>>>> make rpm-package
>>>> make: *** No rule to make target `rpm-package'.  Stop.
>>>>
>>>> Shouldn't it be possible to do a tshark rpm only?
>>>> 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
>>>
>>
>> ___
>> 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] Create tshark rpm

[Anders Broman]

Hi,
Yes that did the trick now stuck on
Create a rpm from the current git commit.
error: Failed build dependencies:
cmake >= 3.10 is needed by
wireshark-4.1.0rc0.5120_gc67cdc0514d9_Ericsson-1.x86_64
make[3]: *** [CMakeFiles/wireshark_rpm] Error 1
make[2]: *** [CMakeFiles/wireshark_rpm.dir/all] Error 2
make[1]: *** [CMakeFiles/wireshark_rpm.dir/rule] Error 2
make: *** [wireshark_rpm] Error 2
[root@wireshark-build-server-inst-site1 build]# cmake --version
cmake3 version 3.17.5

Used alternatives as suggested here:
https://stackoverflow.com/questions/48831131/cmake-on-linux-centos-7-how-to-force-the-system-to-use-cmake3

Regards
Anders


Den fre 19 aug. 2022 kl 17:07 skrev chuck c :

> https://www.wireshark.org/docs/wsdg_html/#ChSrcRpm
>
> Should the target be wireshark_rpm?
>
> On Fri, Aug 19, 2022 at 9:23 AM Anders Broman 
> wrote:
>
>> Hi,
>> I'm trying to build a tshark RPM on Centos7 after manually building some
>> required packages
>> l(ibcryp c-ares) the build works
>> cmake3 -G "Unix Makefiles" ../source -DBUILD_wireshark=OFF
>> make (successful)
>> make rpm-package
>> make: *** No rule to make target `rpm-package'.  Stop.
>>
>> Shouldn't it be possible to do a tshark rpm only?
>> 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
>
___
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] Create tshark rpm

[Anders Broman]

Hi,
I'm trying to build a tshark RPM on Centos7 after manually building some
required packages
l(ibcryp c-ares) the build works
cmake3 -G "Unix Makefiles" ../source -DBUILD_wireshark=OFF
make (successful)
make rpm-package
make: *** No rule to make target `rpm-package'.  Stop.

Shouldn't it be possible to do a tshark rpm only?
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

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

[Anders Broman via Wireshark-dev]

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 
mailto: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 mailto:wireshark-dev@wireshark.org> >
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org 
<mailto:wireshark-dev-requ...@wireshark.org> ?subject=unsubscribe



smime.p7s
Description: S/MIME cryptographic signature
___
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] MSVC gives warnings "qt_ui_utils.cpp(208, 25): warning C4996: 'QProcess::startDetached'"

[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



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Anders Broman]

Hi,
Yes sounds like a good idea. Have been contemplating testing it too.
Regards

Den fre 14 jan. 2022 21:50Gerald Combs  skrev:

> Would it make sense to migrate the master GitLab builds to Visual Studio
> 2022? I was able to build Wireshark with it on my Windows development VM
> and didn't run into any obvious problems.
> ___
> 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] Including sharkd in the installation downloads

[Anders Broman via Wireshark-dev]

Hi,

I guess it is just a matter of doing a section for sharkd in the Wireshark.nsi 
file similar to tshark?



:

  !insertmacro MUI_DESCRIPTION_TEXT ${SecTShark} "Text based network protocol 
analyzer."

:

Section "TShark" SecTShark

;---

SetOutPath $INSTDIR

File "${STAGING_DIR}\tshark.exe"

File "${STAGING_DIR}\tshark.html"

SectionEnd



Regards

Anders



From: Wireshark-dev  On Behalf Of Paul 
Offord
Sent: den 5 januari 2022 23:55
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Including sharkd in the installation downloads



Hi,



There is a tremendous push for automation at work, and I'm sure other 
enterprises have the same aspirations.  Sharkd provides all the power of 
Wireshark dissection and filtering in a way that can easily be driven by an 
automation script.



It's quite difficult to get permission to instal Wireshark, and there is zero 
chance of us being allowed to build a copy from source.  I'm sure similar 
restrictions apply to many in large organisations.



Is it possible to include sharkd in the installers?



Best regards...Paul




-- 

Paul Offord



smime.p7s
Description: S/MIME cryptographic signature
___
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] Failed build on SLED 15

[Anders Broman via Wireshark-dev]

Hi,

We get 

glib-compat.h:31:7: note: include '' or provide a declaration of
'memcpy'

when building on SLED 15.

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] TCP reassembly fails when ethernet tunnled over TCP

[Anders Broman]

Hi,
How about having an array of "address information" where each level put's
it's address info and then a "current IP layer" index variable
which the "tunnel protocol" can set when calling the tunneled protocol(s)
and re-set when returning. In that way the TCP protocol would
get the correct IP for the layer it operates on.
With this structure we would also have MAC addresses etc accessible from
higher layers if needed.
Regards
Anders

Den fre 12 nov. 2021 kl 14:11 skrev John Thacker :

> Yes, this is a long standing problem:
>
> https://gitlab.com/wireshark/wireshark/-/issues/2345
> and
> https://gitlab.com/wireshark/wireshark/-/issues/9782
>
> among others, are examples of the same generic problem.
>
> The entire packet_info [dl_|net_]{src, dst} structure doesn't work very
> well for tunnelled packets, especially those containing the same protocol
> in the outer layers as well inside the tunnel. The endpoints API is
> supposed to help, but the TCP dissector doesn't use it, and it would still
> have to be changed for multiple protocols of the same type, see Michael
> Mann's comment on #2345.
>
> John
>
>
> On Fri, Nov 12, 2021 at 7:57 AM Anders Broman via Wireshark-dev <
> wireshark-dev@wireshark.org> wrote:
>
>> Hi,
>>
>> We have a proprietary protocol sending usually small frames mixed with
>> larger tunneled ethernet frames over TCP. If we then have a TCP segment
>> where the ethernet frame
>>
>> Spans 2 segments reassembly fails presumably because pinfo does not have
>> the IP address of the TCP segment. I think we would need a way to create a
>> new pinfo structure
>>
>> For the tunneled frame? How to do that or some other way to solve the
>> problem? In our case we only have ethernet and a vlan tag then our protocol
>> again so
>>
>> We “fixed” that by dissecting those bytes in the internal dissector. But
>> I think it may be a generic problem for tunneling that may deserve a proper
>> fix.
>>
>> tcp_dissect_pdus() is used
>>
>> 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
>
___
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] TCP reassembly fails when ethernet tunnled over TCP

[Anders Broman via Wireshark-dev]

Hi,

We have a proprietary protocol sending usually small frames mixed with
larger tunneled ethernet frames over TCP. If we then have a TCP segment
where the ethernet frame

Spans 2 segments reassembly fails presumably because pinfo does not have the
IP address of the TCP segment. I think we would need a way to create a new
pinfo structure

For the tunneled frame? How to do that or some other way to solve the
problem? In our case we only have ethernet and a vlan tag then our protocol
again so

We "fixed" that by dissecting those bytes in the internal dissector. But I
think it may be a generic problem for tunneling that may deserve a proper
fix.

tcp_dissect_pdus() is used

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] I have added another file to wireshark but keep getting unresolved references

[Anders Broman via Wireshark-dev]

Hi,
Did you try to delete the build dir and re-run CMake?
Regards
Anders

-Original Message-
From: Wireshark-dev  On Behalf Of Richard 
Sharpe
Sent: den 24 oktober 2021 15:17
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] I have added another file to wireshark but keep 
getting unresolved references

Hi folks,

I have added another file to Wireshark but when I build I keep getting this:

--
[ 79%] Linking C executable run/sharkd
/usr/bin/ld: run/libwireshark.so.14.0.8: undefined reference to 
`dissect_neighbor_report'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/sharkd.dir/build.make:160: run/sharkd] Error 1
make[1]: *** [CMakeFiles/Makefile2:3630: CMakeFiles/sharkd.dir/all] Error 2
make: *** [Makefile:160: all] Error 2


The function is not static and the file has a handoff section and I have added 
the file to the files list in epan/dissectors/CMakeLists.txt.

What else should I do?

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
___
Sent via:Wireshark-dev mailing list 
Archives:
https://protect2.fireeye.com/v1/url?k=7fa4649d-203f5d98-7fa42406-86959e472243-36d92ad18a6c6eb6=1=2ced34b0-e6b9-4385-b2f5-2a58860d3081=https%3A%2F%2Fwww.wireshark.org%2Flists%2Fwireshark-dev
Unsubscribe: 
https://protect2.fireeye.com/v1/url?k=fa656564-a5fe5c61-fa6525ff-86959e472243-00731add9e780d9f=1=2ced34b0-e6b9-4385-b2f5-2a58860d3081=https%3A%2F%2Fwww.wireshark.org%2Fmailman%2Foptions%2Fwireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


smime.p7s
Description: S/MIME cryptographic signature
___
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] Debianbuild fails on Ubuntu 18.04

[Anders Broman via Wireshark-dev]

Hi,
Thanks a lot Balint!
I will try it out as soon as I can.
Regards
Anders

-Original Message-
From: Bálint Réczey  
Sent: den 21 oktober 2021 10:48
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] Debianbuild fails on Ubuntu 18.04

Hi Anders,

Anders Broman via Wireshark-dev  ezt írta
(időpont: 2021. okt. 20., Sze, 11:24):
>
> Hi,
>
> I can no longer create a debian package on Ubuntu 18.04...

The build fails due to a debhelper bug.
I've submitted the workaround at
https://gitlab.com/wireshark/wireshark/-/merge_requests/4755 .

Cheers,
Balint


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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Debianbuild fails on Ubuntu 18.04

[Anders Broman via Wireshark-dev]

Hi,

I can no longer create a debian package on Ubuntu 18.04...

 

Best regards

Anders


# check all necessary headers are included
cc -c debian/headers-check.c -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-O2 -fdebug-prefix-map=/home/ericsson/wireshark=. -fstack-protector-strong 
-Wformat -Werror=format-security -Idebian/libwireshark-dev/usr/include 
-Idebian/libwireshark-dev/usr/include/wireshark 
-Idebian/libwiretap-dev/usr/include/wireshark 
-Idebian/libwsutil-dev/usr/include/wireshark -o /dev/null
make[1]: Leaving directory '/home/ericsson/wireshark'
   dh_installdocs -O--buildsystem=cmake
   dh_installchangelogs -O--buildsystem=cmake
   dh_installman -O--buildsystem=cmake
   dh_installdebconf -O--buildsystem=cmake
   dh_python3 -O--buildsystem=cmake
E: dh_python3 dh_python3:176: no package to act on (python3-foo or one with 
${python3:Depends} in Depends)
   dh_installinit -O--buildsystem=cmake
   dh_installsystemduser -O--buildsystem=cmake
   dh_lintian -O--buildsystem=cmake
   dh_icons -O--buildsystem=cmake
   dh_perl -O--buildsystem=cmake
   dh_link -O--buildsystem=cmake
   dh_strip_nondeterminism -O--buildsystem=cmake
   dh_compress -O--buildsystem=cmake
   debian/rules override_dh_fixperms
make[1]: Entering directory '/home/ericsson/wireshark'
dh_fixperms
chmod 644 debian/wireshark-dev/usr/share/pyshared/make-plugin-reg.py \
debian/wireshark-dev/usr/share/pyshared/wireshark_be.py \
debian/wireshark-dev/usr/share/pyshared/wireshark_gen.py
make[1]: Leaving directory '/home/ericsson/wireshark'
   dh_missing -O--buildsystem=cmake
dh_missing: usr/bin/sharkd exists in debian/tmp but is not installed to anywhere
dh_missing: usr/bin/idl2wrs exists in debian/tmp but is not installed to 
anywhere
dh_missing: usr/include/wireshark/file.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/ws_symbol_export.h exists in debian/tmp but 
is not installed to anywhere
dh_missing: usr/include/wireshark/globals.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/ws_diag_control.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/cli_main.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/cfile.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/ws_compiler_tests.h exists in debian/tmp but 
is not installed to anywhere
dh_missing: usr/include/wireshark/ws_attributes.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/ws_log_defs.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/ws_version.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/wiretap/secrets-types.h exists in debian/tmp 
but is not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/wtap_opttypes.h exists in debian/tmp 
but is not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/wtap.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/pcap-encap.h exists in debian/tmp but 
is not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/file_wrappers.h exists in debian/tmp 
but is not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/merge.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/pcapng_module.h exists in debian/tmp 
but is not installed to anywhere
dh_missing: usr/include/wireshark/wiretap/wtap_modules.h exists in debian/tmp 
but is not installed to anywhere
dh_missing: usr/include/wireshark/epan/diam_dict.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/epan/conversation_debug.h exists in 
debian/tmp but is not installed to anywhere
dh_missing: usr/include/wireshark/epan/maxmind_db.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/epan/frame_data.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/epan/x264_prt_id.h exists in debian/tmp but 
is not installed to anywhere
dh_missing: usr/include/wireshark/epan/guid-utils.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/epan/packet.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/epan/dvb_chartbl.h exists in debian/tmp but 
is not installed to anywhere
dh_missing: usr/include/wireshark/epan/ax25_pids.h exists in debian/tmp but is 
not installed to anywhere
dh_missing: usr/include/wireshark/epan/t35.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/epan/expert.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: usr/include/wireshark/epan/print.h exists in debian/tmp but is not 
installed to anywhere
dh_missing: 

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

[Anders Broman via Wireshark-dev]

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 colorfilters file
"C:\Development\wsbuild-gpl\run\RelWithDebInfo\colorfilters".

"Bad" cannot be converted to Unsigned integer, 1 byte.

** (wireshark:13228) 12:52:44.177545 [Main MESSAGE] -- Wireshark is up and
ready to go, elapsed time 6,160s

 

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] New Warnings on Windows builds? Related to defilter changes?

[Anders Broman via Wireshark-dev]

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: 'INT8_MIN': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(49,1):
warning C4005: #define INT8_MIN (-127i8 - 1)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(49,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(50,1):
warning C4005: 'INT16_MIN': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(50,1):
warning C4005: #define INT16_MIN(-32767i16 - 1)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(50,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(51,1):
warning C4005: 'INT32_MIN': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(51,1):
warning C4005: #define INT32_MIN(-2147483647i32 - 1)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(51,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(53,1):
warning C4005: 'INT8_MAX': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(53,1):
warning C4005: #define INT8_MAX 127i8
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(53,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(54,1):
warning C4005: 'INT16_MAX': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(54,1):
warning C4005: #define INT16_MAX32767i16
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(54,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(55,1):
warning C4005: 'INT32_MAX': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(55,1):
warning C4005: #define INT32_MAX2147483647i32
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(55,1):
warning C4005: ^ (compiling source file
C:\Development\wsbuild-gpl\epan\dfilter\scanner.c)
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

 C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(57,1):
warning C4005: 'UINT8_MAX': macro redefinition
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\stdint.h(57,1):
warning C4005: #define UINT8_MAX0xffui8
[C:\Development\wsbuild-gpl\epan\dfilter\dfilter.vcxproj]

   C:\Program Files (x86)\Microsoft Visual

[Wireshark-dev] Compilation on Windows taking a very long time?

[Anders Broman via Wireshark-dev]

Hi,

Is it just me or is compilation time on Windows much longer now?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Edit resolved name stopped working?

[Anders Broman]

Hi,
I think it was exported pdu with ips as tags. That would explain it I
suppose.
Will check Monday.
Regards
Anderd

Den fre 10 sep. 2021 13:24Anders Broman via Wireshark-dev <
wireshark-dev@wireshark.org> skrev:

> Hi,
>
> Has ”Edit resolved name” stopped working or what needs to be set in order
> for it to work?
>
> In a trace with no resolved IPs the menu “Edit resolved names” is greyed
> out.
>
> 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

[Wireshark-dev] Edit resolved name stopped working?

[Anders Broman via Wireshark-dev]

Hi,

Has "Edit resolved name" stopped working or what needs to be set in order
for it to work?

In a trace with no resolved IPs the menu "Edit resolved names" is greyed
out.

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Wireshark does not build on Ubunty 18.04 with LZ4 (to old version?)

[Anders Broman via Wireshark-dev]

Hi,

Build fails complaining on  

wiretap/file_wrappers.c:199:5 error: unknown type name 'LZ4F_dctx'

 

As far as I understand in the older package it uses LZ4F_dctx_s

Should we require a higher version of the LZ4 library?

 

 

Do we need something like this:
(https://github.com/facebook/hhvm/blob/master/CMake/FindLZ4.cmake)


# fb-mysql requires LZ4F_resetDecompressionContext() which was added in
v1.8.0


if (LZ4_LIBRARY)


  include(CheckCSourceRuns)


  set(CMAKE_REQUIRED_INCLUDES ${LZ4_INCLUDE_DIR})


  set(CMAKE_REQUIRED_LIBRARIES ${LZ4_LIBRARY})


  check_c_source_runs("


#include 


int main() {


  int good = (LZ4_VERSION_MAJOR > 1) ||


((LZ4_VERSION_MAJOR == 1) && (LZ4_VERSION_MINOR >= 8));


return !good;


}" LZ4_GOOD_VERSION)


  set(CMAKE_REQUIRED_INCLUDES)


  set(CMAKE_REQUIRED_LIBRARIES)


endif()

 

Best regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Anders Broman via Wireshark-dev]

Hi,

I think you should go for 2. Wouldn’t this type of construct from the goose 
protocol work?

 

GSEMngtRequests ::= CHOICE {

   getGoReference[1] IMPLICIT 
GetReferenceRequestPdu,

   getGOOSEElementNumber [2] IMPLICIT 
GetElementRequestPdu,

   getGsReference [3] IMPLICIT 
GetReferenceRequestPdu,

   getGSSEDataOffset   [4] IMPLICIT 
GetElementRequestPdu,

   ...

}

e.g.

MyNewProtocolMessages ::= CHOICE{

   myMeasge1 [1] IMPLICIT MyMessage1,

   :

Repeated as many times as needed, MyMessage1 could have sub messages or 
whatever…

I assume the encoder will be using an ASN1 encoder to serialize the data.

Regards

Anders

 

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] ASN.1-based dissector decoding by port number vs 
switch/case using 1st octet

 

Hello everyone in the Wireshare-dev community,

 

The primary question in this email (but I think it requires some explanation 
below): How does one write an ASN.1-based dissector such that the generated 
code (per "make asn1") does indeed decode the first octet as the message type 
using C-style switch/case construct? 

 

In May I sat in (online) at an online Wireshark Developer Den meeting. I asked 
about encoding schemes like that in IEEE 1451.0 where the first octet is used 
to decode the message. I got a response indicating it was natural to use a 
switch/case statement in C programming to decode the messages (all of them, 
with one switch/case statement). [I gather that one switch/case statement for 
decoding all messages of a protocol implies one enumeration table for encoding 
them in the first octet.]


But I did not understand that until today. Nor did I know how to modify the 
ASN.1-based dissector “foo” to make it work with a switch/case statement. It 
had build errors from the change to cmake; I renamed it “myfoo” in my 
repository and fixed the build errors (I have been slow to make a MR, merge 
request, for it). I made the decision to base decoding entirely on port number 
and make one dissector per message per port number. Yuck, but that’s what I 
did. The current approach would add over 100 new folders to asn1 folder in 
(./epan/dissectors/asn1).  Is that acceptable? To add over 100 new folders in 
asn1 for a new protocol? [I am helping design a new protocol]. 

 

I am consider two options:

 

1. Explore the possibility of using a port-range since tcpdump and tshark 
support portrange filtering. To me that implies the possibility that people 
could indeed be implementing protocols with one dissector per message per port 
(and conceivably are using a lot ports for a single protocol in some cases). 
This new protocol allows for hundreds of unique messages. It seems, however, a 
port range of several hundred ports for one protocol is impractical and 
wasteful of port numbers. But ignoring that objection for the moment I press 
on, and ask how I might I put several hundred dissectors into a single 
source-tree under the asn1 folder (in ./epan/dissectors/asn1)? Again, assuming 
it's okay to use up several hundred UDP ports for a single protocol: What 
success might have during build step "make asn1" that it will generate 
dissectors from a source-tree of dissectors in one folder in the asn1 folder? 
For example, I am thinking I will put a group of dissectors in ./asn1/netsvc/ 
and another group in ./asn1/xdrsvc, and so on. Is anyone doing this? Is this 
supported in the current build process?

 

2. Give up on #1 above, and do something sane like use the first octet to 
encode the message type rather than waste hundreds of ports on a 
single-port-per-message-per-dissector approach describe in #1 above. This 
brings me back to the response I got in the Wireshark Developer Den in May: Use 
a C switch/case statement to decode the messages. Okay, I want to that do that. 
But I don't know how to do that for ASN.1-based dissectors. If I can learn how 
to do that then I would revise the "foo" dissector (simple ASN.1-based 
dissector) to be exactly that, get it working, and make my MR (merge-request 
for that and final give something back to this community that has been so 
helpful to me).

 

I like option #2 above, because it uses a single UDP for the entire protocol 
(again, this is a new protocol being developed as an IEEE standard). We could 
still end up using a few ports perhaps (one port per group of messages). For 
example, IEEE 1451.0 Network Services would get one UDP port, IEEE 1451.0 
Transducer Services would get another port, and so on. Then the protocol would 
need only a handful of port numbers at the most. Either way the issue remains: 
How does one even begin to write an ASN.1-based dissector such that the 
generated code (per "make asn1") 

Re: [Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE

[Anders Broman via Wireshark-dev]

-Original Message-
From: Wireshark-dev  On Behalf Of Isaac 
Boukris
Sent: den 16 juni 2021 12:52
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] ASN1: How to display an octet-string as UTF16 LE

Hello,

I'd like to add the following asn1 struct to the credssp dissector (following 
MR 3020):
TSRemoteGuardPackageCred ::= SEQUENCE {
packageName [0] OCTET STRING,
credBuffer  [1] OCTET STRING
}

It gets displayed like this:
logonCred
packageName: 4b00650072006200650072006f007300
credBuffer:
0a00020073041805200093046182046f…

Now, the package name is a UTF16 LE string (Kerberos), and I wonder if there is 
an easy way to make it display it as a string instead of HEX
- thoughts?

Thanks!

Hi,
If it's always an UTF16 string you will have to do .cnf magic and add something 
like
proto_tree_add_item(tree, hf_krb_pac_upn_upn_name, tvb, upn_offset, upn_len, 
ENC_UTF_16|ENC_LITTLE_ENDIAN);

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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Calling a dissector: Type for data parameter

[Anders Broman]

Hi,
Yes the method is fragile. At the time of development I think it was
proposed to pass a struct containing a string and the void pointer where
the string could be used as a identifier. But that was voted down.
Regards
Anders

Den lör 29 maj 2021 09:26Guy Harris  skrev:

> On May 29, 2021, at 12:12 AM, Anders Broman  wrote:
>
> > Shouldn't the caller be calling with the right data type or NULL? So a
> bug in the MQTT disector?
>
> How can the MQTT dissector determine what the right data type *is* -
> especially given that the dissectors aren't wired in, there's a UAT
> preference that lets the user configure it.
>
> This is where the current mechanism for passing data between dissectors
> goes crashing to the ground.
>
> MQTT passes a topic string, which is just a string, to the dissectors it
> calls.
>
> JSON expects to be passed a pointer to an http_message_info_t.
>
> JSON registers its non-heuristic dissector by name, and allows it to be
> used with Decode As... for UDP ports.
>
> It might *look* safe if you check the UDP dissector and the dissectors
> that use "media_type" and "grpc_message_type", but the "registers its
> non-heuristic dissector by name" mean there are no guarantees, given that
> another dissector that passes a pointer to something *other* than an
> http_message_info_t to dissectors that are specified by name in a UAT.
> ___
> 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] Calling a dissector: Type for data parameter

[Anders Broman]

Hi,
Shouldn't the caller be calling with the right data type or NULL? So a bug
in the MQTT disector?
Regards
Anders


Den lör 29 maj 2021 09:07Uli Heilmeier  skrev:

> With MR 2706 [1] the MQTT dissector calls now subdissectors with
> call_dissector_with_data() [2]. Previously this was call_dissector().
>
> With this change the JSON dissector crashes WS with a memory access
> segfault (while using MQTT decode topic as option).
> This is because for JSON we expect http_message_info_t for data pointer
> [3]. MQTT hands over a pointer to a char array (topic_str) for data.
>
> How do we handle data type for the data parameter pointer? Would it make
> sense to compare at least the size of data with the size of
> http_message_info_t?
>
> I don’t know any way to check the data type of a pointer address location.
>
> Cheers
> Uli
>
> [1]: https://gitlab.com/wireshark/wireshark/-/merge_requests/2706/
> [2]:
> https://gitlab.com/wireshark/wireshark/-/merge_requests/2706//diffs#07171e000b3caaabee32ab5dc04a5d28efbaaae3_755_755
> [3]:
> https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-json.c#L221
> ___
> 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] MR 2984 stuck?

[Anders Broman via Wireshark-dev]

Hi,

Could someone have a look at

https://gitlab.com/wireshark/wireshark/-/merge_requests/2984

It seems like the pipelines are stuck?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] MR that commes up as "OK to Merge" fails pipline

[Anders Broman via Wireshark-dev]

Hi,

This MR  
https://gitlab.com/wireshark/wireshark/-/merge_requests/2178 passed check
but failed merge at the firsts attempt - the author then amended

It passed check and came up with a green merge button. It then fails
pipeline. What should it have been done instead?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] still unclear how to build a new ASN.1-based dissector

[Anders Broman via Wireshark-dev]

Hi,

Perhaps a misconception here, the generated files are part of the source tree 
currently so when you change any of the files in the

../asn1/foo directory you need to run make foo and check in the generated .c 
and optionally .h file.

 

So on the very first round add the directory and files in the /foo directory DO 
NOT change cmake for the generated files yet

Run cmake to have the cmake files generated needed to generate asn1 dissectors.

Run make foo

You should now have generated .c and possibly .h files in your src dir

Check them in and update the cmake files to include the f´generated .c .h files

Run make to have them built

 

Best regards

Anders

 

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 19 april 2021 05:06
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] still unclear how to build a new ASN.1-based 
dissector

 

CORRECTION:  I omitted the troublesome steps (underlined) when describing the 
problem:

git clone https://   wireshark

cd wireshark

git checkout wireshark-3.4.4

cd wireshark/epan/dissectors

cp ~/myfoo.tgz . #copy dissector code into wireshark clone

tar xvf myfoo.tgz #extract the dissector code (details in previous email)

cd ../../..

mkdir build

cd build

cmake ../wireshark #this step worked previously but not on a fresh wireshark 
clone now

make asn1 #with relevant entries in two CMakeListsCustom files

make

 

On Sun, Apr 18, 2021 at 8:15 PM Vincent Randal mailto:vtran...@gmail.com> > wrote:

Hello Wireshark-dev community,

 

Apparently, I still don't have the correct sequence of steps necessary for 
first time generation of "packet-myfoo.c" and "packet-myfoo.h" for a new 
ASN.1-based dissector called myfoo. Details follow.

 

I would like to understand (much better than I do) how to add an ASN.1-based 
dissector to epan/dissectors/asn1 in a fresh clone of wireshark. I got a lot of 
help from a lot of people last week (for which I am grateful) but I must still 
be missing a step here:

git clone https://   wireshark

cd wireshark

git checkout wireshark-3.4.4

cd ..

mkdir build

cd build

cmake ../wireshark #this step worked previously but not on a fresh wireshark 
clone now

make asn1 #with relevant entries in two CMakeListsCustom files

make

 

When I add my dissector folder "myfoo" to epan/dissectors/asn1 here's the 
relevant error messages from cmake (with some highlighting by me):

-- Configuring done
CMake Error at epan/dissectors/CMakeLists.txt:2004 (add_library):
  Cannot find source file:

/home/vtrandal/ws1/wireshark/epan/dissectors/packet-myfoo.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

CMake Error at epan/dissectors/CMakeLists.txt:2004 (add_library):
  No SOURCES given to target: dissectors

[end of cmake error messages]

 

The point of the above cmake error messages is that the "packet-myfoo.c" and 
"packet-myfoo.h" files have not yet been generated (and I don't know how to 
generate them). I do not know how I got past the cmake step before, but I was 
lucky (and unlucky now). The ASN.1-based dissector code is in the attached .tgz 
file which I extract in epan/dissectors as follows:

tar xvf myfoo.tgz

./CMakeListsCustom.txt <== contains entry for myfoo
./asn1/CMakeListsCustom.txt <== contains entry for myfoo
./asn1/myfoo/
./asn1/myfoo/myfoo.asn
./asn1/myfoo/myfoo.cnf
./asn1/myfoo/CMakeLists.txt
./asn1/myfoo/packet-myfoo-template.h
./asn1/myfoo/packet-myfoo-template.c

 

I apologize in advance for being thick-headed about the process of adding a new 
ASN.1-based dissector to epan/dissectors/asn1 in Wireshark. With help from a 
lot of people I got it to compile previously (again for which I am grateful). 
But I cannot repeat that success starting with a fresh clone of wireshark 
regardless of the branch. Somehow I still don't have the correct sequence of 
steps necessary to generate "packet-myfoo.c" and "packet-myfoo.h" the first 
time. With my dissector code in epan/dissectors the cmake step fails and I 
cannot make  anything. 

 

Vincent

 

NOTE: The attached dissector code is based on the simple ASN.1-based dissector 
example online. 
https://www.wireshark.org/docs/wsdg_html_chunked/SimpleASN1BasedDissector.html

 



smime.p7s
Description: S/MIME cryptographic signature
___
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 build the simple ASN.1 UDP-based dissector example (foo)

[Anders Broman via Wireshark-dev]

Hi,

I don’t think they are generated what will be generated are the files needed to 
DO the generation.

On windows the next step is to run

msbuild /m /p:Configuration=RelWithDebInfo  
epan\dissectors\asn1\h248\generate_dissector-h248.vcxproj

which will the generate the .c and .h files

Regards

Anders

 

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 13 april 2021 16:40
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector 
example (foo)

 

Correct insofar as there are no generated files associated with asn1/foo 
directory. Namely, packet-foo.c and packet-foo.h did not get generated. But 
maybe that's not definitive proof that asn1/foo dissector did not get built. 
How else can I confirm the dissector was or was not built? Open Wireshark and 
attempt to apply "foo" as a display filter? It's not there.

 

On Tue, Apr 13, 2021 at 8:10 AM Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

Hi,

So you are saying that if you create foo dir like

epan/dissectors/asn1/foo/

Rename and update the custom cmake file to

set(CUSTOM_ASN1_SRC_DIR

   foo

)

And place your source file and cmake.txt in the foo dir then rerun the cmake 
process

Nothing happens?

Try to delete the build dir  before rerunning cmake again?

I’m not sure on linux if the generate cmake file ends up under the build dir or 
in the source dir.

 

Regards

Anders

From: Wireshark-dev mailto:wireshark-dev-boun...@wireshark.org> > On Behalf Of Vincent Randal
Sent: den 13 april 2021 15:32
To: Developer support list for Wireshark mailto:wireshark-dev@wireshark.org> >
Subject: Re: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector 
example (foo)

 

I tried renaming ./epan/dissectors/asn1/CMakeListsCustom.txt.example to 
CMakeListsCustom.txt with an entry as follows:

# Add a list of your custom asn1 dissectors here
set(CUSTOM_ASN1_SRC_DIR
   foo
)

 

Again, the build did not update any targets even with that change. But this is 
progress because that underscores the Step by Step instructions need to be 
updated to something that works. Any more ideas?

 

On Tue, Apr 13, 2021 at 7:12 AM John Thacker mailto:johnthac...@gmail.com> > wrote:

On Tue, Apr 13, 2021, 8:32 AM Vincent Randal mailto:vtran...@gmail.com> > wrote:

Hello everyone,

 

I need help building the simple ASN.1 UDP-based dissector example (foo); 
specifically, I need help building the generate_dissector-*proto* target (Step 
#6 below). I'm certainly missing something here.

 

 

(c) I created directory "foo" by extracting the attachment (foo.tgz) in 
epan/dissectors/asn1/

(d) There is a CMakeListsCustom.txt.example file in epan/dissectors/asn1 which 
already contains an entry for "foo". 

(e) Since I don't know what to do in Step #6, I build Wireshare (using cmake), 
but no build targets get updated.

 

If the solution to this problem belongs in the Wireshark documentation, I would 
be glad to help update the documentation. Namely, I don't understand the usage 
of the 5 (five) CMakeListsCustom.txt.example files inWireshark source code.

 

The CMakeListsCustom.txt.example files are just that, examples. You need to 
copy or rename them to CMakeListsCustom.txt (without the .example) for them to 
have any effect (and edit them appropriately to add the dissector name to the 
list, not commented out.)

 

CMake is configured to look for the files by that name.

 

John Thacker

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

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



smime.p7s
Description: S/MIME cryptographic signature
___
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 build the simple ASN.1 UDP-based dissector example (foo)

[Anders Broman via Wireshark-dev]

Hi,

So you are saying that if you create foo dir like

epan/dissectors/asn1/foo/

Rename and update the custom cmake file to

set(CUSTOM_ASN1_SRC_DIR

   foo

)

And place your source file and cmake.txt in the foo dir then rerun the cmake 
process

Nothing happens?

Try to delete the build dir  before rerunning cmake again?

I’m not sure on linux if the generate cmake file ends up under the build dir or 
in the source dir.

 

Regards

Anders

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 13 april 2021 15:32
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector 
example (foo)

 

I tried renaming ./epan/dissectors/asn1/CMakeListsCustom.txt.example to 
CMakeListsCustom.txt with an entry as follows:

# Add a list of your custom asn1 dissectors here
set(CUSTOM_ASN1_SRC_DIR
   foo
)

 

Again, the build did not update any targets even with that change. But this is 
progress because that underscores the Step by Step instructions need to be 
updated to something that works. Any more ideas?

 

On Tue, Apr 13, 2021 at 7:12 AM John Thacker mailto:johnthac...@gmail.com> > wrote:

On Tue, Apr 13, 2021, 8:32 AM Vincent Randal mailto:vtran...@gmail.com> > wrote:

Hello everyone,

 

I need help building the simple ASN.1 UDP-based dissector example (foo); 
specifically, I need help building the generate_dissector-*proto* target (Step 
#6 below). I'm certainly missing something here.

 

 

(c) I created directory "foo" by extracting the attachment (foo.tgz) in 
epan/dissectors/asn1/

(d) There is a CMakeListsCustom.txt.example file in epan/dissectors/asn1 which 
already contains an entry for "foo". 

(e) Since I don't know what to do in Step #6, I build Wireshare (using cmake), 
but no build targets get updated.

 

If the solution to this problem belongs in the Wireshark documentation, I would 
be glad to help update the documentation. Namely, I don't understand the usage 
of the 5 (five) CMakeListsCustom.txt.example files inWireshark source code.

 

The CMakeListsCustom.txt.example files are just that, examples. You need to 
copy or rename them to CMakeListsCustom.txt (without the .example) for them to 
have any effect (and edit them appropriately to add the dissector name to the 
list, not commented out.)

 

CMake is configured to look for the files by that name.

 

John Thacker

___
Sent via:Wireshark-dev mailing list mailto:wireshark-dev@wireshark.org> >
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



smime.p7s
Description: S/MIME cryptographic signature
___
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 build the simple ASN.1 UDP-based dissector example (foo)

[Anders Broman via Wireshark-dev]

Hi,

On what OS are you doing this?

Regards

Anders

 

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 13 april 2021 14:32
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector 
example (foo)

 

Hello everyone,

 

I need help building the simple ASN.1 UDP-based dissector example (foo); 
specifically, I need help building the generate_dissector-*proto* target (Step 
#6 below). I'm certainly missing something here.

 

I'm following the Step by Step instructions (shown below) to create the simple 
ASN1 UDP-based dissector 

  mentioned in 14.2. ASN.1 Dissector Requirements 

  and I'm stuck on step #6. In this case *proto* = "foo" (the simple ASN1 
UDP-based dissector, attached to this email as foo.tgz).


14.7. Step By Step Instructions [Creating ASN.1 Dissectors]


1.  Create a directory for your protocol in the epan/dissectors/asn1 
directory and put your ASN.1 file there. 
2.  Copy CMakeLists.txt from another ASN.1 dissector and edit it to suit 
your needs. 
3.  Create a .cnf file either by copying an existing one and editing it or 
using the empty example above. 
4.  Create template files either by copying suitable existing ones and 
editing them or use the examples above, putting your protocol name in the 
appropriate places. 
5.  Add your dissector to epan/dissectors/asn1/CMakeLists.txt 
6.  Test generating your dissector by building the 
generate_dissector-*proto* target. <== how? using cmake?
7.  Depending on the outcome you may have to edit your .cnf file, ASN.1 
file etc… 
8.  Build Wireshark. <== with cmake

NOTES:

(a) The above Step by Step instructions come from here:

https://www.wireshark.org/docs/wsdg_html_chunked/ASN1StepByStepInstructions.html

(b) Prior to attempting any dissector development I built and installed 
wireshark-3.4.4 successfully (using cmake).

(c) I created directory "foo" by extracting the attachment (foo.tgz) in 
epan/dissectors/asn1/

(d) There is a CMakeListsCustom.txt.example file in epan/dissectors/asn1 which 
already contains an entry for "foo". 

(e) Since I don't know what to do in Step #6, I build Wireshare (using cmake), 
but no build targets get updated.

 

If the solution to this problem belongs in the Wireshark documentation, I would 
be glad to help update the documentation. Namely, I don't understand the usage 
of the 5 (five) CMakeListsCustom.txt.example files inWireshark source code.

 

Sincerely,

Vincent Randal



smime.p7s
Description: S/MIME cryptographic signature
___
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] general inquiry on building dissectors for wireshark-3.4.4

[Anders Broman via Wireshark-dev]

Hi,

If the protocol is truly described by asn1 documents there are plenty of 
examples in epan/dissectors/asn1/

Basically you need the asn1 description a template and a .cnf file. Are you 
building on Windows or Linux?

I’m not familiar with building the asn1 based dissectors on Linux. Are you 
going to submit the dissector back to the community

Or is it a private one? If it’s a public one we could guide you in an MR.

Best regards

Anders

 

 

From: Wireshark-dev  On Behalf Of Graham 
Bloice
Sent: den 7 april 2021 19:46
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] general inquiry on building dissectors for 
wireshark-3.4.4

 

 

 

On Wed, 7 Apr 2021 at 17:28, Vincent Randal mailto:vtran...@gmail.com> > wrote:

Hello,

 

Where can I find a complete "text based" dissector example that builds with the 
current Wireshark cmake build method used in wireshark-3.4.4? Does that 
question even make sense? I fear most people reading my question won't 
understand what I'm after.

 

I've watched numerous YouTube videos by Graham Bloice and Richard Sharpe that 
describe 3 primary methods for Wireshark dissector development:

1. Text based

2. Scripting Language based

3. C based

 

In the meantime I have built wireshark-2.6.20 using the older ./autogen.sh, 
configure, make build method. This gives me hope I might have some success with 
at least 1 (one) text-based dissector example that uses that build method:

https://wiki.wireshark.org/ASN1_plugin

 

 

The text based dissector in my presentation was specifically WSGD which 
provides its own runtime via a plugin DLL.  It's a bit of a grey area if an 
ASN.1 dissector is text based, as the description is fed into the dissector 
generator asn2wrs.py and out pops a C-based dissector.

 

If I were an expert with cmake (which might be easier than I think) I would 
probably update the text-based examples to build using cmake. But I don't know 
how to do that (yet).

 

Adding a dissector with CMake is easier (I think)  as it mostly handles 
platform and compiler differences.  As such the page you link to (which is the 
old wiki, not our new shiny GitLab one, 
https://gitlab.com/wireshark/wireshark/-/wikis/ASN1_plugin) is woefully out of 
date as it doesn't describe how to do that with CMake.

 

Unfortunately I've never dealt with an asn1 based dissector, either built-in or 
as a plugin so can't offer advice on that.

 

 

Vincent Randal

Longmont, CO

 

-- 

Graham Bloice



smime.p7s
Description: S/MIME cryptographic signature
___
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] Pipeline stuck?

[Anders Broman via Wireshark-dev]

Hi,

In  
https://gitlab.com/wireshark/wireshark/-/merge_requests/1934

The pipeline seems stuck, how to reset?

 

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Dissector functions and variables that could be static

[Anders Broman via Wireshark-dev]

Hi,

Did some googling out of curiosity and found 
https://jelmer.uk/klaus/wireshark/blob/e738b556d72d4db5d7df85969c15117dedd0d063/epan/dissectors/packet-xml.c

Search for “xml_get_attrib" So it seems it was part of packet-xml.c at some 
point so perhaps safe to remove…

/Anders

 

From: Wireshark-dev  On Behalf Of Martin 
Mathieson via Wireshark-dev
Sent: den 27 januari 2021 13:27
To: Developer support list for Wireshark 
Cc: Martin Mathieson 
Subject: Re: [Wireshark-dev] Dissector functions and variables that could be 
static

 

Hi João,

 

I agree that every function / variable needs to be looked at carefully, but 
more so if they have WS_DLL_PUBLIC in a header file.

 

I will reinstate the XML functions in my change.  Hopefully, in other places I 
will find clear comments saying that they are provided for calling from private 
code or plugins, etc.

 

The few occasions I've added to debian/libwireshark0.symbols have been to 
unbreak the pipeline when linking between dissectors and GUI code.  My pdcp 
key-setting functions don't even appear there, but I don't build Windows 
plugins.

 

Martin

 

On Wed, Jan 27, 2021 at 11:48 AM João Valverde via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

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 needed. The considerate 
way to remove them would be to have a deprecation period.

Unfortunately debian symbols doesn't help here. It does not say anything 
interesting not already said by the static/exported C keywords,  because 
functions that may be internal, for example exported from epan to the wireshark 
GUI application (not intended to be part of a public API), must also be 
included in debian symbols.

So really IMO the analysis must be done case by case for each function. And of 
course the risk of breaking someone elses plugin is always there, however 
small, so I think it needs to proceed with some caution.



On 27/01/21 11:06, Martin Mathieson via Wireshark-dev wrote:

My most recent MR 
(https://gitlab.com/wireshark/wireshark/-/merge_requests/1829), has come across 
some symbols that don't appear to be in used by our repo.

 

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below

  
4934dpkg-gensymbols: warning: debian/libwireshark0/DEBIAN/symbols doesn't match 
completely debian/libwireshark0.symbols

  4935--- 
debian/libwireshark0.symbols (libwireshark0_3.5.0_amd64)

  4936+++ 
dpkg-gensymbolsUhOwDI 2021-01-27 10:38:17.0 +

  4937@@ -2124,7 
+2124,7 @@

  4938 
wsp_vals_pdu_type_ext@Base 1.9.1

  4939 
wsp_vals_status_ext@Base 1.9.1

  4940 
xml_escape@Base 1.9.1

  4941- 
xml_get_attrib@Base 1.9.1

  4942- 
xml_get_cdata@Base 1.9.1

  4943- 
xml_get_tag@Base 1.9.1

  4944+#MISSING: 
3.5.0# xml_get_attrib@Base 1.9.1

  4945+#MISSING: 
3.5.0# xml_get_cdata@Base 1.9.1

  4946+#MISSING: 
3.5.0# xml_get_tag@Base 1.9.1

  4947 
zbee_zcl_init_cluster@Base 2.5.2

 

It may be possible that someone has a private dissector that uses these xml 
accessor functions to try to pick out some interesting fields.

 

I am guessing that I should have my script read debian/libwireshark0.symbols to 
realise that these functions need to be non-static, even if there it can't find 
any actual references?

 

Martin 

 

 

 

On Tue, Jan 26, 2021 at 7:59 PM Martin Mathieson 
mailto:martin.r.mathie...@googlemail.com> > 
wrote:

I have done a bit more on this - I started picking off the ones at the end of 
the (alphabetical) list - 2nd one is 
https://gitlab.com/wireshark/wireshark/-/merge_requests/1817. Please feel free 
if anyone feels motivated to tackle some of the earlier ones.  The script is 
much tidier now, and also checks for references from the ui folder (this 
removed around 20 from the list), will take another pass through it before 
creating an MR with it. 

 

Sometimes 

[Wireshark-dev] Problem with ENC_BCD_DIGITS_0_9 odd/even

[Anders Broman via Wireshark-dev]

Hi,

There is a problem with the BCD encoded numbers as they may be padded and
unfortunately with Zero.

 

"Encoding scheme: BCD. Note: Filler H'0 (last digit) is used in case of the
odd number of digits." 

 

In order to present this properly

It would be good to be able to pass an odd/even indicator, what would be the
preferred bits to use?

#define ENC_BCD_ODD   0x1000

#define ENC_BCD_EVEN  0x2000

 

If(odd){

   proto_tree_add_item(subtree, hf_cs1plus_gen_digits, parameter_tvb,
poffset, -1, ENC_KEYPAD_BC_TBCD| ENC_BCD_ODD );

else

   proto_tree_add_item(subtree, hf_cs1plus_gen_digits, parameter_tvb,
poffset, -1, ENC_KEYPAD_BC_TBCD| ENC_BCD_EVEN);

 

Or some other solution?

 

Best regards

Anders

 



smime.p7s
Description: S/MIME cryptographic signature
___
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] Recent console warning from Qt?

[Anders Broman via Wireshark-dev]

-Original Message-
From: Wireshark-dev  On Behalf Of 
Maynard, Christopher via Wireshark-dev
Sent: den 8 december 2020 16:20
To: 'Developer support list for Wireshark' 
Cc: Maynard, Christopher 
Subject: Re: [Wireshark-dev] Recent console warning from Qt?

> From: Wireshark-dev  On Behalf Of
> Anders Broman via Wireshark-dev
> Sent: Tuesday, December 8, 2020 3:55 AM
> To: wireshark-dev@wireshark.org
> Cc: Anders Broman 
> Subject: [Wireshark-dev] Recent console warning from Qt?
>
> Hi,
> Has anyone else seen this Main Warn QWinTaskbarButton: qIID_ITaskbarList4 
> was not initialized: 0x, ?
> Regards
> Anders
>

I'm not seeing that.  Here's my Wireshark information for reference:

3.5.0 (v3.5.0rc0-316-gc876b34ed103)

Compiled (64-bit) with Qt 5.15.2, with libpcap, with GLib 2.52.3, with zlib 
1.2.11, with SMI 0.4.8, with c-ares 1.17.0, with Lua 5.2.4, with GnuTLS 3.6.3 
and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB 
resolver, with nghttp2 1.42.0, with brotli, with LZ4, with Zstandard, with 
Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic updates using 
WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled resampler).

Running on 64-bit Windows 10 (2004), build 19041, with Intel(R) Xeon(R) CPU 
E3-1505M v5 @ 2.80GHz (with SSE4.2), with 16231 MB of physical memory, with 
locale English_United States.utf8, with light display mode, without HiDPI, 
with Npcap version 1.00, based on libpcap version 1.9.1, with GnuTLS 3.6.3, 
with Gcrypt 1.8.3, with brotli 1.0.9, with AirPcap 4.1.0 build 1622, binary 
plugins supported (21 loaded).

Built using Microsoft Visual Studio 2019 (VC++ 14.28, build 29333).


I have
Wireshark 3.5.0 (v3.5.0rc0-317-g9722eaf93456)

Copyright 1998-2020 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later 
<https://www.gnu.org/licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.15.1, with libpcap, with GLib 2.52.3, with zlib
1.2.11, with SMI 0.4.8, with c-ares 1.17.0, with Lua 5.2.4, with GnuTLS 3.6.3
and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB
resolver, with nghttp2 1.42.0, with brotli, with LZ4, with Zstandard, with
Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic updates using
WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled resampler).

Running on 64-bit Windows 10 (1809), build 17763, with Intel(R) Core(TM)
i7-8650U CPU @ 1.90GHz (with SSE4.2), with 32611 MB of physical memory, with
locale Swedish_Sweden.utf8, with Npcap version 0.9996, based on libpcap 
version
1.9.1, with GnuTLS 3.6.3, with Gcrypt 1.8.3, with brotli 1.0.9, with AirPcap
4.1.0 build 1622, binary plugins supported (0 loaded).

Built using Microsoft Visual Studio 2019 (VC++ 14.28, build 29334).

Perhaps it is fixed in Qt 5.15.2...
Regards
Anders








CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information. This message is intended solely for 
the use of the addressee. If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Recent console warning from Qt?

[Anders Broman via Wireshark-dev]

Hi,

Has anyone else seen this Main Warn QWinTaskbarButton: qIID_ITaskbarList4
was not initialized: 0x, ?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Long time to merge?

[Anders Broman via Wireshark-dev]

Hi,

What is the most efficient way to merge MRs with git-lab? Approve one
request and wait until it's merged or stage a couple?

I set up a bunch this morning and it is still not complete I think.

What buttons to press in what order? When to assign to git-lab utility?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Qt warning on Windows build.

[Anders Broman via Wireshark-dev]

Hi,

Currently there is one Warnimg produced for the Windows build

C:\Development\ewireshark\trunk\ui\qt\widgets\byte_view_text.cpp(187,38):
warning C4996: 'QFont::ForceIntegerMetrics': was declared deprecated
[C:\Development\wsbuild64\ui\qt\qtui.vcxproj]

 

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Handling malformed packet exceptions from within ASN.1 dissectors

[Anders Broman via Wireshark-dev]

Hi,
I think a TRY CATCH block is the thing to use. Grep for CTACH and I think you 
will find a bunch of examples.
Regards
Anders

-Original Message-
From: Wireshark-dev  On Behalf Of Richard 
Sharpe
Sent: den 3 november 2020 00:26
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Handling malformed packet exceptions from within ASN.1 
dissectors

Hi folks,

I am using some of the existing ASN.1 dissectors from within the
ieee802.11 dissector, and in some cases the frame is malformed in the
ASN.1 portion.

However, since it is within an IE where I know the length of the element, I 
would like to regain control and add an Expert Info and then keep dissecting.

How can I handle this?

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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Create dissctor groups to easily dissable unneded protocols.

[Anders Broman via Wireshark-dev]

 

 

From: Wireshark-dev  On Behalf Of chuck c
Sent: den 21 oktober 2020 17:52
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Create dissctor groups to easily dissable unneded 
protocols.

 

>The Frame protocol (and a dozen others) can not be disabled:

> /* You can't disable dissection of "Frame", as that would be
>  tantamount to not doing any dissection whatsoever. */
>proto_set_cant_toggle(proto_frame);

> 

>Would there be a group that lists these?

 

I think it could be done – not sure what the use case would be, other than 
creating a list.

/Anders

 

On Wed, Oct 21, 2020 at 9:34 AM Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

Hi,

In the developers den we discussed the possibility of disabling unneeded 
protocols and I brought up the idea of protocol groups. If there is interest in 
this feature

I would need help with the GUI part – volunteers? As a PoC I was thinking of 
something along these lines.

Turn all protocols of – enable the group “basic” which would then be the basic 
protocols you would need in most cases like

Ethernet -VLAN-IP4/IPv6-TCP UDP SCTP ICMP ICMP6 ARP more? We don’t need a 
comprehensive list here and now these might do for the PoC.

Once the basic group is there we might start to look at large groups of 
specialized protocols most people would want to turn off like

USB Bluetooth ZigeBee, telco(?) might be candidates. 

 

This would be the API to register in a group, only allowed group names(we make 
list) to be accepted at registry time, possibly

Have a register group name routine? But the poc may not have to be more 
complicated than this.

--- a/epan/proto.c

+++ b/epan/proto.c

@@ -343,21 +343,22 @@ static header_field_info hfi_text_only =

{ "Text item",  "text", FT_NONE, BASE_NONE, NULL, 0x0, NULL, HFILL };

int hf_text_only = -1;

 

-/* Structure for information about a protocol */

+/** Structure for information about a protocol */

struct _protocol {

-   const char *name;   /* long description */

-   const char *short_name; /* short description */

-   const char *filter_name;/* name of this protocol in filters */

-   GPtrArray  *fields; /* fields for this protocol */

-   int proto_id;   /* field ID for this protocol */

-   gbooleanis_enabled; /* TRUE if protocol is enabled */

-   gbooleanenabled_by_default; /* TRUE if protocol is enabled by 
default */

-   gbooleancan_toggle; /* TRUE if is_enabled can be changed */

-   int parent_proto_id;/* Used to identify "pino"s (Protocol 
In Name Only).

+   const char *name;   /**< long description */

+   const char *short_name; /**< short description */

+   const char *filter_name;/**< name of this protocol in filters */

+   const char* group_name; /**< name of the "group" this protocol 
belongs to */

+   GPtrArray  *fields; /**< fields for this protocol */

+   int proto_id;   /**< field ID for this protocol */

+   gbooleanis_enabled; /**< TRUE if protocol is enabled */

+   gbooleanenabled_by_default; /**< TRUE if protocol is enabled by 
default */

+   gbooleancan_toggle; /**< TRUE if is_enabled can be changed 
*/

+   int parent_proto_id;/**< Used to identify "pino"s (Protocol 
In Name Only).

For dissectors that need a protocol 
name so they

can be added to a dissector table, but 
use the

parent_proto_id for things like 
enable/disable */

-   GList  *heur_list;  /* Heuristic dissectors associated with 
this protocol */

+   GList  *heur_list;  /**< Heuristic dissectors associated 
with this protocol */

};

 

/* List of all protocols */

@@ -7208,8 +7209,14 @@ check_valid_filter_name_or_fail(const char *filter_name)

}

 

int

-proto_register_protocol(const char *name, const char *short_name,

-   const char *filter_name)

+proto_register_protocol(const char* name, const char* short_name, const char* 
filter_name)

+{

+   return proto_register_protocol_and_group(name, short_name, filter_name, 
NULL);

+}

+

+int

+proto_register_protocol_and_group(const char *name, const char *short_name,

+   const char *filter_name, const char* group_name)

{

protocol_t *protocol;

header_field_info *hfinfo;

@@ -7248,6 +7255,7 @@ proto_register_protocol(const char *name, const char 
*short_name,

   protocol->name = name;

protocol->short_name = short_name;

protocol->filter_name = filter_name;

+   protocol-

[Wireshark-dev] Create dissctor groups to easily dissable unneded protocols.

[Anders Broman via Wireshark-dev]

Hi,

In the developers den we discussed the possibility of disabling unneeded
protocols and I brought up the idea of protocol groups. If there is interest
in this feature

I would need help with the GUI part - volunteers? As a PoC I was thinking of
something along these lines.

Turn all protocols of - enable the group "basic" which would then be the
basic protocols you would need in most cases like

Ethernet -VLAN-IP4/IPv6-TCP UDP SCTP ICMP ICMP6 ARP more? We don't need a
comprehensive list here and now these might do for the PoC.

Once the basic group is there we might start to look at large groups of
specialized protocols most people would want to turn off like

USB Bluetooth ZigeBee, telco(?) might be candidates. 

 

This would be the API to register in a group, only allowed group names(we
make list) to be accepted at registry time, possibly

Have a register group name routine? But the poc may not have to be more
complicated than this.

--- a/epan/proto.c

+++ b/epan/proto.c

@@ -343,21 +343,22 @@ static header_field_info hfi_text_only =

{ "Text item",  "text", FT_NONE, BASE_NONE, NULL, 0x0, NULL, HFILL
};

int hf_text_only = -1;

 

-/* Structure for information about a protocol */

+/** Structure for information about a protocol */

struct _protocol {

-   const char *name;   /* long description */

-   const char *short_name; /* short description */

-   const char *filter_name;/* name of this protocol in filters
*/

-   GPtrArray  *fields; /* fields for this protocol */

-   int proto_id;   /* field ID for this protocol */

-   gbooleanis_enabled; /* TRUE if protocol is enabled */

-   gbooleanenabled_by_default; /* TRUE if protocol is enabled by
default */

-   gbooleancan_toggle; /* TRUE if is_enabled can be changed
*/

-   int parent_proto_id;/* Used to identify "pino"s
(Protocol In Name Only).

+   const char *name;   /**< long description */

+   const char *short_name; /**< short description */

+   const char *filter_name;/**< name of this protocol in
filters */

+   const char* group_name; /**< name of the "group" this
protocol belongs to */

+   GPtrArray  *fields; /**< fields for this protocol */

+   int proto_id;   /**< field ID for this protocol */

+   gbooleanis_enabled; /**< TRUE if protocol is enabled */

+   gbooleanenabled_by_default; /**< TRUE if protocol is enabled by
default */

+   gbooleancan_toggle; /**< TRUE if is_enabled can be
changed */

+   int parent_proto_id;/**< Used to identify "pino"s
(Protocol In Name Only).

For dissectors that need a protocol
name so they

can be added to a dissector table,
but use the

parent_proto_id for things like
enable/disable */

-   GList  *heur_list;  /* Heuristic dissectors associated
with this protocol */

+   GList  *heur_list;  /**< Heuristic dissectors associated
with this protocol */

};

 

/* List of all protocols */

@@ -7208,8 +7209,14 @@ check_valid_filter_name_or_fail(const char
*filter_name)

}

 

int

-proto_register_protocol(const char *name, const char *short_name,

-   const char *filter_name)

+proto_register_protocol(const char* name, const char* short_name, const
char* filter_name)

+{

+   return proto_register_protocol_and_group(name, short_name,
filter_name, NULL);

+}

+

+int

+proto_register_protocol_and_group(const char *name, const char *short_name,

+   const char *filter_name, const char* group_name)

{

protocol_t *protocol;

header_field_info *hfinfo;

@@ -7248,6 +7255,7 @@ proto_register_protocol(const char *name, const char
*short_name,

   protocol->name = name;

protocol->short_name = short_name;

protocol->filter_name = filter_name;

+   protocol->group_name = group_name;

protocol->fields = NULL; /* Delegate until actually needed */

protocol->is_enabled = TRUE; /* protocol is enabled by default */

protocol->enabled_by_default = TRUE; /* see previous comment */

diff --git a/epan/proto.h b/epan/proto.h

index 679cb6989c..fa63c9d9de 100644

--- a/epan/proto.h

+++ b/epan/proto.h

@@ -2371,6 +2371,14 @@ proto_item_fill_label(field_info *fi, gchar
*label_str);

WS_DLL_PUBLIC int

proto_register_protocol(const char *name, const char *short_name, const char
*filter_name);

 

+/** Register a new protocol with group association.

+ @param name the full name of the new protocol

+ @param short_name abbreviated name of the new protocol

+ @param filter_name protocol name used for a display filter string

+ @param group_name the group the protocol belongs to. Grops are 

Re: [Wireshark-dev] nas_eps value type change request

[Anders Broman via Wireshark-dev]

Hi,

The proper way to request features or report bugs is through 
https://bugs.wireshark.org/bugzilla/ or start a discussion on the mailing 
lists. If I look in the 3GPP specifications

TS 23.003 Chapter 2.4

…”The TMSI consists of 4 octets. It can be coded using a full hexadecimal 
representation.”… so displaying it as decimal may be misleading?

In packet-s1ap.c we have 

M-TMSI TYPE = FT_UINT32 DISPLAY = BASE_DEC_HEX

Which will change the representation to be both decimal AND hexadecimal we 
could do that for NAS-EPS too I suppose.

 

“I’m trying to create a MATE file that will add IMSI to all packets in all 
common 3gpp core protocols.

My goal is to filter all messages related to a specific IMSI from a 
multi-subscriber and multi-protocol cap file.”

 

This would be a valuable feature I think and perhaps should be done by code 
rather than mate, perhaps you can share your mate files?

Regards

Anders

 

From: Dudi D  
Sent: den 5 oktober 2020 08:10
To: Anders Broman 
Subject: nas_eps value type change request

 

Hi Andres,

 

Sorry for this direct request, My name is Dudi and I’m a Packet Core Engineer.

I’m using WS a lot, i’m trying to create a MATE file that will add IMSI to all 
packets in all common 3gpp core protocols.

My goal is to filter all messages related to a specific IMSI from a 
multi-subscriber and multi-protocol cap file.

 

M-TMSI (under GUTI) value is in hex on nas_eps and dec in s1ap dissector.

nas_eps.emm.m_tmsi

s1ap.m_TMSI

 

So, because of this type difference, when using MATE, I cannot correlate 
between Attach/TAU to Service requests and Paging.

Is it possible to change  in packet-nas_epc also to decimal like MME group ID 
and MMe Code ?

Do you think it's correct to use decimal here ?

https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-nas_eps.c#L6949
 
<https://protect2.fireeye.com/v1/url?k=99410b7f-c7e1ebe1-99414be4-86ee86bd5107-f4db730c5d1ad937=1=3082eef2-751c-4d1f-8929-c0d6b4c3bf59=https%3A%2F%2Fgithub.com%2Fwireshark%2Fwireshark%2Fblob%2Fmaster%2Fepan%2Fdissectors%2Fpacket-nas_eps.c%23L6949>
 

 

 

BR,

Dudi Davidesko



smime.p7s
Description: S/MIME cryptographic signature
___
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] Reassembling IPP info through USB

[Anders Broman via Wireshark-dev]

-Original Message-
From: Wireshark-dev  On Behalf Of Guy 
Harris
Sent: den 9 juli 2020 04:00
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Reassembling IPP info through USB

On Jul 8, 2020, at 6:06 PM, Jamie Hare  wrote:

> I am attempting to create a dissector for IPP over USB and am running into 
> some issues with the reassembly. I first thought that I could just use a 
> reassembly table but with the way the dissectors are run multiple times is 
> it necessary to create a PDU/tap combo like TCP or UDP?

Taps are not used for reassembly of PDUs that cover multiple TCP segments or 
multiple UDP datagrams, so taps are not necessary for reassembly of 
IPP-over-USB.

You *do* need to make sure that, in the first pass over the packets, the 
results of the reassembly are saved, just as happens with reassembly with 
other packets, so that, when packets are looked at, in a possibly random 
order, after the first pass, it can be determined where the packet in question 
resides within the reassembled IPP message.

pinfo->fd->visited can be used to track if it's the first pas or not. If you 
search for it in the code you can find how it is used with reassembly in 
many(all) cases.
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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Build boot stuck?

[Anders Broman via Wireshark-dev]

Hi,

The latest build seems to take a long time.

/Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Intermittent Builder Windows Petri Dish x64 failed (failed ctest) failures seriously annoying.

[Anders Broman via Wireshark-dev]

Hi,

We have intermittent false petri dish failures. Can someone with insight
into the tests have a look?

Best regards

Anders

Example Builder Windows Petri Dish x64 failed (failed ctest) -

http://buildbot.wireshark.org/petri-dish/builders/Windows%20Petri%20Dish%20x
64/builds/11913



smime.p7s
Description: S/MIME cryptographic signature
___
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] Include LUA dissectors in installers?

[Anders Broman via Wireshark-dev]

Hi,

Does anyone have modified CMakefiles to include LUA dissectors in nsis and
RPMs? 

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Dissecting http2 traffic

[Anders Broman via Wireshark-dev]

Hi,
Yes it's related to that bug. And if memory serves the trace would illustrate 
the problem.
I don't see how the compression/decompression could recover as in showing the 
missing header element. I'm not sure I understand what your objection is. Is it 
in how to present the non decodable element? Alternative solutions welcome.  I 
have pushed the suggested code upstream but no feedback yet. I think it would 
be of service to the telco community to have an interim solution in Wireshark 
until we get something from upstream. If that's not acceptable I will use my 
own branch.
Best regards
Anders

Skickat från Outlook Mobile<https://aka.ms/blhgte>


From: Peter Wu 
Sent: Friday, May 15, 2020 10:40:03 PM
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] Dissecting http2 traffic

On Fri, May 15, 2020 at 06:50:18AM +, Anders Broman via Wireshark-dev wrote:
> Hi,
>
> I think there is a demand to dissect http2 traffic where all packets in a
> session is not captured. This is currently not possible.
>
> As the http2 protocol creates dynamic data for compression/decompression and
> if the packet adding a new index to the index table is not
>
> Present then that header element can not be decoded in the packet(s) where
> it occurs. Also the nghttp2 library stops processing the
>
> Header and is left in an error state(I think).
>
>
>
> I have modified the nghttp2 code to handle unknown indexes
> https://protect2.fireeye.com/v1/url?k=d2592c57-8cf9ccc9-d2596ccc-86ee86bd5107-f102bcce985b9905=1=3d077b47-0100-4f28-aa79-f193cfe770be=https%3A%2F%2Fgithub.com%2Fnghttp2%2Fnghttp2%2Fpull%2F1467
>  and modified Wireshark to use
> it
>
> https://code.wireshark.org/review/#/c/37203/ as this pull request is not yet
> accepted and of course no nghttp2 release including it exists, there is
>
> a problem to get this functionality. Could we roll our own windows version
> of nghttp2 as a start? I have built a modified library for my tests.

I'd suggest to work with upstream nghttp2 to get the patches reviewed
first. The suggested approach of generating a dummy ":Failed deflate"
header seems wrong to me.

Depending on the lost data, it might not be possible to completely
recover. What kind of errors would you like to recover from? Do you have
an example trace? Is it related to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16496?

Kind regards,
Peter

> Suggestions on how to proceed? For 5G who is a heavy user of http2 I think
> the ability to decode payloads are essential and this is a first step to fix
> that.
>
> 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

[Wireshark-dev] Dissecting http2 traffic

[Anders Broman via Wireshark-dev]

Hi,

I think there is a demand to dissect http2 traffic where all packets in a
session is not captured. This is currently not possible.

As the http2 protocol creates dynamic data for compression/decompression and
if the packet adding a new index to the index table is not

Present then that header element can not be decoded in the packet(s) where
it occurs. Also the nghttp2 library stops processing the

Header and is left in an error state(I think).

 

I have modified the nghttp2 code to handle unknown indexes

https://github.com/nghttp2/nghttp2/pull/1467 and modified Wireshark to use
it

 
https://code.wireshark.org/review/#/c/37203/ as this pull request is not yet
accepted and of course no nghttp2 release including it exists, there is

a problem to get this functionality. Could we roll our own windows version
of nghttp2 as a start? I have built a modified library for my tests.

 

Suggestions on how to proceed? For 5G who is a heavy user of http2 I think
the ability to decode payloads are essential and this is a first step to fix
that.

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] HTTP2 headers not dissected

[Anders Broman via Wireshark-dev]

Him
Opened https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16496
/Anders

-Original Message-
From: Peter Wu  
Sent: den 16 april 2020 00:36
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] HTTP2 headers not dissected

Hi Anders,

On Wed, Apr 15, 2020 at 03:11:01PM +, Anders Broman via Wireshark-dev
wrote:
> It seems like at least in some cases when there is multiple HTTP2 
> streams the header fields are not decoded but if
> 
> Packets belonging to that stream is put in a separate trace file 
> decoding works.

Can you file a bug with an example capture file for the first problematic
case?
--
Kind regards,
Peter Wu
https://lekensteyn.nl


smime.p7s
Description: S/MIME cryptographic signature
___
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] HTTP2 headers not dissected

[Anders Broman via Wireshark-dev]

Hi,

It seems like at least in some cases when there is multiple HTTP2 streams
the header fields are not decoded but if

Packets belonging to that stream is put in a separate trace file decoding
works.

Best regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] HTTP2 decryption test fails

[Anders Broman via Wireshark-dev]

Hi,

https://code.wireshark.org/review/#/c/36851/

seems to make the test fail. Not sure what the problem might be. Can someone
take a look?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Dissectors with the same abbreviation

[Anders Broman]

Den fre 20 mars 2020 16:19Pascal Quantin  skrev:

> Hi Tomasz,
>
> Le ven. 20 mars 2020 à 16:10, Tomasz Moń  a écrit :
>
>> Hello,
>>
>> In Wireshark there is Precision Time Protocol (IEEE1588) dissector
>> suing the abbreviation "ptp". There is also, currently without built
>> in dissector, Picture Transfer Protocol (ISO 15740:2008) that is
>> commonly referred to as PTP. MTP (Media Transfer Protocol) is
>> extension to Picture Transfer Protocol.
>>
>
> This is unfortunate, but can happen given the amount of protocols
> supported by Wireshark.
>
>
>> What abbreviation should Picture Transfer Protocol dissector use?
>>
>
> iso_ptp maybe?
>

Pic-tp?


> Cheers,
> Pascal.
> ___
> 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] Build without LUA fails

[Anders Broman via Wireshark-dev]

 

 

From: Pascal Quantin  
Sent: den 17 mars 2020 10:13
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] Build without LUA fails

 

Hi Anders,

 

Le mar. 17 mars 2020 à 10:02, Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > a écrit :

Hi,

Someone at work is trying to build without LUA and getting, from cmake:

 

:

- The following OPTIONAL packages have not been found:

 

* LIBSSH (required version >= 0.6), Library for implementing SSH clients, 
<https://www.libssh.org/ 
<https://protect2.fireeye.com/v1/url?k=26994e1c-7a136cc8-26990e87-0cc47ad93e6a-bf41698e2320f659=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fwww.libssh.org%2F>
 >

   extcap remote SSH interfaces (sshdump, ciscodump)

* Systemd, System and Service Manager (libraries), 
<https://freedesktop.org/wiki/Software/systemd/ 
<https://protect2.fireeye.com/v1/url?k=fe7da14b-a2f7839f-fe7de1d0-0cc47ad93e6a-59860c2d4f2e2152=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Ffreedesktop.org%2Fwiki%2FSoftware%2Fsystemd%2F>
 >

  Support for systemd journal extcap interface (sdjournal)

* MaxMindDB, C library for the MaxMind DB file format, 
<https://github.com/maxmind/libmaxminddb 
<https://protect2.fireeye.com/v1/url?k=a2f64434-fe7c66e0-a2f604af-0cc47ad93e6a-c422963fef79097e=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fgithub.com%2Fmaxmind%2Flibmaxminddb>
 >

   Support for GeoIP lookup

* SMI

* Minizip, C library for supporting zip/unzip functionality, 
<https://www.winimage.com/zLibDll/minizip.html 
<https://protect2.fireeye.com/v1/url?k=ecbe0ffc-b0342d28-ecbe4f67-0cc47ad93e6a-458ff04972920839=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fwww.winimage.com%2FzLibDll%2Fminizip.html>
 >

   Support for profiles import/export

* BROTLI

* LZ4, LZ4 is lossless compression algorithm used in some protocol (CQL...), 
<http://www.lz4.org 
<https://protect2.fireeye.com/v1/url?k=31a16480-6d2b4654-31a1241b-0cc47ad93e6a-60ca5d75f4a68dec=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=http%3A%2F%2Fwww.lz4.org%2F>
 >

   LZ4 decompression in CQL and Kafka dissectors

* SNAPPY, A fast compressor/decompressor from Google, 
<https://google.github.io/snappy/ 
<https://protect2.fireeye.com/v1/url?k=ffbdd3e3-a337f137-ffbd9378-0cc47ad93e6a-aa1c45afdd0254a1=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fgoogle.github.io%2Fsnappy%2F>
 >

   Snappy decompression in CQL and Kafka dissectors

* ZSTD (required version >= 1.0.0), A compressor/decompressor from Facebook 
providing better compression than Snappy at a cost of speed, 
<https://facebook.github.io/zstd/ 
<https://protect2.fireeye.com/v1/url?k=8e4a792c-d2c05bf8-8e4a39b7-0cc47ad93e6a-3c554c55bddcd6e3=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Ffacebook.github.io%2Fzstd%2F>
 >

   Zstd decompression in Kafka dissector

* LUA (required version >= 5.1)

* SBC, Bluetooth low-complexity, subband codec (SBC) decoder, 
<https://git.kernel.org/pub/scm/bluetooth/sbc.git>

   Support for playing SBC codec in RTP player

* SPANDSP, a library of many DSP functions for telephony, 
<https://www.soft-switch.org 
<https://protect2.fireeye.com/v1/url?k=66abf21d-3a21d0c9-66abb286-0cc47ad93e6a-fc567e190f1951a3=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fwww.soft-switch.org%2F>
 >

   Support for G.722 and G.726 codecs in RTP player

* BCG729, G.729 decoder, 
<https://www.linphone.org/technical-corner/bcg729/overview 
<https://protect2.fireeye.com/v1/url?k=466d134f-1ae7319b-466d53d4-0cc47ad93e6a-37ddcbaedcd602d7=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fwww.linphone.org%2Ftechnical-corner%2Fbcg729%2Foverview>
 >

   Support for G.729 codec in RTP player

* ILBC, iLBC decoder, <https://github.com/TimothyGu/libilbc 
<https://protect2.fireeye.com/v1/url?k=4c718298-10fba04c-4c71c203-0cc47ad93e6a-652a8dc4a478f089=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fgithub.com%2FTimothyGu%2Flibilbc>
 >

   Support for iLBC codec in RTP player

* SpeexDSP, SpeexDSP is a patent-free, Open Source/Free Software DSP library, 
<https://www.speex.org/ 
<https://protect2.fireeye.com/v1/url?k=d62dbae1-8aa79835-d62dfa7a-0cc47ad93e6a-70e92ec7f8e18c17=1=d79c2d7b-43e8-40b7-8bf9-9570ae22d886=https%3A%2F%2Fwww.speex.org%2F>
 >

   RTP audio resampling

* Asciidoctor (required version >= 1.5):

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake 
files:

LUA_INCLUDE_DIR

   used as include directory in directory ..Wireshark /epan

:

 

Any ideas?

 

Just a blind attmpt. Would th epatch below change something?

 

diff --git a/cmake/modules/FindLUA.cmake b/cmake/modules/FindLUA.cmake
index 2e5e8d476b..ea65b0f89e 100644
--- a/cmake/modules/FindLUA.cmake
+++ b/cma

[Wireshark-dev] Build without LUA fails

[Anders Broman via Wireshark-dev]

Hi,

Someone at work is trying to build without LUA and getting, from cmake:

 

:

- The following OPTIONAL packages have not been found:

 

* LIBSSH (required version >= 0.6), Library for implementing SSH clients,


   extcap remote SSH interfaces (sshdump, ciscodump)

* Systemd, System and Service Manager (libraries),


  Support for systemd journal extcap interface (sdjournal)

* MaxMindDB, C library for the MaxMind DB file format,


   Support for GeoIP lookup

* SMI

* Minizip, C library for supporting zip/unzip functionality,


   Support for profiles import/export

* BROTLI

* LZ4, LZ4 is lossless compression algorithm used in some protocol (CQL...),


   LZ4 decompression in CQL and Kafka dissectors

* SNAPPY, A fast compressor/decompressor from Google,


   Snappy decompression in CQL and Kafka dissectors

* ZSTD (required version >= 1.0.0), A compressor/decompressor from Facebook
providing better compression than Snappy at a cost of speed,


   Zstd decompression in Kafka dissector

* LUA (required version >= 5.1)

* SBC, Bluetooth low-complexity, subband codec (SBC) decoder,


   Support for playing SBC codec in RTP player

* SPANDSP, a library of many DSP functions for telephony,


   Support for G.722 and G.726 codecs in RTP player

* BCG729, G.729 decoder,


   Support for G.729 codec in RTP player

* ILBC, iLBC decoder, 

   Support for iLBC codec in RTP player

* SpeexDSP, SpeexDSP is a patent-free, Open Source/Free Software DSP
library, 

   RTP audio resampling

* Asciidoctor (required version >= 1.5):

CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake
files:

LUA_INCLUDE_DIR

   used as include directory in directory ..Wireshark /epan

:

 

Any ideas?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Wireshark wiki on portable aps

[Anders Broman via Wireshark-dev]

Hi,

This page may need some love  Is it built with cmake?

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Mixing Exported_pdu with Lua

[Anders Broman]

Hi,
And I think the OP wants to use the protocol name tag to call the LUA
dissector e.g the dissector needs to be registered by name.
Regards
Anders

Den tis 18 feb. 2020 22:29Pascal Quantin  skrev:

> Hi Chris,
>
> Le mar. 18 févr. 2020 à 22:18, Maynard, Chris via Wireshark-dev <
> wireshark-dev@wireshark.org> a écrit :
>
>> I’m not quite sure what is meant by EXPORTED_PDU here.  Maybe you could
>> share some Lua code and provide a little more detail and context?
>>
>
> For the exported PDU format description, see
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/exported_pdu.h;h=e5226c6e070caedccc3828ff9fa7b14a56b1;hb=refs/heads/master
>
> Pascal.
>
>> - Chris
>>
>> (I don’t consider myself a Lua expert by any means, but I’ve written a
>> number of Lua dissectors, so I guess that qualifies me as one of the
>> “lua_guys”.)
>>
>>
>>
>> *From:* Wireshark-dev  *On Behalf
>> Of *Anders Broman via Wireshark-dev
>> *Sent:* Tuesday, February 18, 2020 11:18 AM
>> *To:* Developer support list for Wireshark 
>> *Cc:* Anders Broman 
>> *Subject:* Re: [Wireshark-dev] Mixing Exported_pdu with Lua
>>
>>
>>
>> Hi,
>>
>> I do not do LUA code but did you do Proto.new(name, desc)
>> <https://wiki.wireshark.org/LuaAPI/Proto#Proto.new.28name.2C_desc.29> and
>> then use that name to call the dissector?
>>
>> @lua guys: Does that register the LUA dissector by name? or do you do it
>> some other way?
>>
>> Regards
>>
>> Anders
>>
>>
>>
>> *From:* Wireshark-dev  *On Behalf
>> Of *Juanjo Martin Carrascosa
>> *Sent:* den 17 februari 2020 16:40
>> *To:* Developer support list for Wireshark 
>> *Subject:* [Wireshark-dev] Mixing Exported_pdu with Lua
>>
>>
>>
>> Hi devs,
>>
>>
>>
>> Is it possible to register a Lua dissector so it is called by
>> EXPORTED_PDU? I don't manage to "register" the Lua dissector properly.
>>
>>
>>
>> My goal is to create a dissector in Lua that is called by EXPORTED_PDU
>> and later calls another C dissector from Wireshark. Once I get this working
>> and this protocol is stable enough, I may write a C file for it.
>>
>>
>>
>> Any help would be appreciated!
>>
>>
>>
>> Regards,
>>
>> Juanjo Martin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This message is the property of International
>> Game Technology PLC and/or its subsidiaries and may contain proprietary,
>> confidential or trade secret information. This message is intended solely
>> for the use of the addressee. If you are not the intended recipient and
>> have received this message in error, please delete this message from your
>> system. Any unauthorized reading, distribution, copying, or other use of
>> this message or its attachments is strictly prohibited.
>>
>> ___
>> 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] Mixing Exported_pdu with Lua

[Anders Broman via Wireshark-dev]

Hi,

I do not do LUA code but did you do 
 
Proto.new(name, desc) and then use that name to call the dissector?

@lua guys: Does that register the LUA dissector by name? or do you do it some 
other way?

Regards

Anders



From: Wireshark-dev  On Behalf Of Juanjo 
Martin Carrascosa
Sent: den 17 februari 2020 16:40
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] Mixing Exported_pdu with Lua



Hi devs,



Is it possible to register a Lua dissector so it is called by EXPORTED_PDU? I 
don't manage to "register" the Lua dissector properly.



My goal is to create a dissector in Lua that is called by EXPORTED_PDU and 
later calls another C dissector from Wireshark. Once I get this working and 
this protocol is stable enough, I may write a C file for it.



Any help would be appreciated!



Regards,

Juanjo Martin



smime.p7s
Description: S/MIME cryptographic signature
___
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] Unable to detect custom protocol dissector

[Anders Broman via Wireshark-dev]

Hi,

I don’t write Lua code but try

  
Dissector.get(name) 

 

Using gnw as name

Regards

Anders

 

From: Wireshark-dev  On Behalf Of sandip 
gangakhedkar
Sent: den 13 februari 2020 23:11
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unable to detect custom protocol dissector

 

Hi Chris,

 

I confirm that I see the same issue with your Lua script. However, I am able to 
dissect the GeoNetworking header normally in another pcap trace that does not 
contain my proprietary header that encapsulates my GeoNetworking PDU. So I 
think the Native Wireshark gnw Dissector is working just fine. 

 

However, when I add the custom Dissector for my proprietary header and then 
chain the gnw Dissector to it, I am able to see my proprietary headers, but 
fail to see the GeoNetworking header dissected. 

 

@Anders: I did not notice anything particular in the way the gnw Dissector is 
registered:

 

 



expert_module_t* expert_geonw;


module_t *geonw_module;


 


proto_geonw = proto_register_protocol("GeoNetworking", "GNW", "gnw");


 


 


geonw_handle = register_dissector("gnw", dissect_geonw, proto_geonw);


 


proto_register_field_array(proto_geonw, hf_geonw, array_length(hf_geonw));


proto_register_subtree_array(ett, array_length(ett));


 


expert_geonw = expert_register_protocol(proto_geonw);


expert_register_field_array(expert_geonw, ei, array_length(ei));



 

Am I missing something here?

 

Thanks again for your help.

 

 

 

 

On Thu, Feb 13, 2020 at 10:50 PM Maynard, Chris via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

I’m not sure what you’re trying to do, but there’s already a Wireshark built-in 
dissector for GeoNetworking[1]. 

 

If you’re trying to replace it for some reason, then you may either need to 
disable that one or remove it completely.  And if you’re trying to implement in 
Lua, then you’ll need to register it as a heuristic dissector using 
register_heuristic[2].  However, it seems that there might be a bug with 
respect to this function[3], as the following simple Lua script seems to 
indicate:

 

local p_gnw = Proto("gnwHdr", "GeoNetworkingHdr")

 

function p_gnw.dissector(tvbuf, pinfo, tree)

 

local ethertype = tvbuf(12, 2):uint()

if ethertype == 35143 then

pinfo.cols.protocol:set("GNW")

return true

else

return false

end

end

 

p_gnw.register_heuristic("eth", p_gnw.dissector)

 

 

When Wireshark is started with this gnw.lua script loaded, the following error 
message is encountered:

 

Lua: Error during loading:

path\to\gnw.lua:14:bad

argument #1 to ‘register_heuristic’ (userdata expected, got string)

stack traceback:

 [C]: in function ‘register_heuristic’

 path\to\gnw.lua:14:

in main chunk

 

- Chris

[1]: 
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-geonw.c;h=21290a3b179c8974483a2f762cbe512fbec67103;hb=HEAD

[2]: https://www.wireshark.org/docs/wsdg_html_chunked/lua_module_Proto.html 
(Section 11.6.5.3)

[3]: 
https://osqa-ask.wireshark.org/questions/54158/register-heuristic-function-for-multiple-heuristic-list-names-in-lua

 

 

From: Wireshark-dev mailto:wireshark-dev-boun...@wireshark.org> > On Behalf Of sandip gangakhedkar
Sent: Wednesday, February 12, 2020 4:46 PM
To: wireshark-dev@wireshark.org  
Subject: [Wireshark-dev] Unable to detect custom protocol dissector

 

Hi, 

 

I am using a Custom protocol dissector (Lua script) for the GeoNetworking 
header. I have build wireshark 3.2.1 from source on Ubuntu 18.04 and placed the 
Lua script in the Global plugins directory. However, the script fails when to 
find the Geonetworking protocol when I invoke it in the script:

 

  Dissector.get("gnw"):call(newTvb, pkt, root)

 

So I tried another approach:

 

  gnw_dissector = DissectorTable.get("ethertype"):get_dissector(35143)

 

The protocol gnw (GeoNetworking) corresponds to an EtherType of 35143 in my 
Wireshark protocols configuration. However, this also fails to find the "gnw" 
protocol.

 

How can I get wireshark to detect the GeoNetworking protocol from my custom Lua 
script?

 

Thanks in advance.

 

 

CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information. This message is intended solely for 
the use of the addressee. If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited. 

Re: [Wireshark-dev] Unable to detect custom protocol dissector

[Anders Broman via Wireshark-dev]

 

 

From: Wireshark-dev  On Behalf Of Graham 
Bloice
Sent: den 13 februari 2020 11:09
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unable to detect custom protocol dissector

 

Does your custom build of Wireshark include Lua?  What does the Help | About 
Wireshark | Wireshark info show?

 

On Wed, 12 Feb 2020 at 21:46, sandip gangakhedkar mailto:sandipfl...@gmail.com> > wrote:

Hi,

 

I am using a Custom protocol dissector (Lua script) for the GeoNetworking 
header. I have build wireshark 3.2.1 from source on Ubuntu 18.04 and placed the 
Lua script in the Global plugins directory. However, the script fails when to 
find the Geonetworking protocol when I invoke it in the script:

 

  Dissector.get("gnw"):call(newTvb, pkt, root)

 

So I tried another approach:

 

  gnw_dissector = DissectorTable.get("ethertype"):get_dissector(35143)

 

The protocol gnw (GeoNetworking) corresponds to an EtherType of 35143 in my 
Wireshark protocols configuration. However, this also fails to find the "gnw" 
protocol.

 

How can I get wireshark to detect the GeoNetworking protocol from my custom Lua 
script?

 

Thanks in advance.

 

 


The function DissectorTable.get("ethertype"):get_dissector(35143)

 

 
https://wiki.wireshark.org/LuaAPI/Dissector#dissectortable:get_dissector.28pattern.29

gets the handle of the built in GNW dissector as far as I can tell. Is that 
what you want? Why do you want to replace the existing dissector? (If that’s 
what you are trying to do).

 

Regards

Anders

 



smime.p7s
Description: S/MIME cryptographic signature
___
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] q on catching error in sub-dissectors.

[Anders Broman via Wireshark-dev]

-Original Message-
From: Wireshark-dev  On Behalf Of João 
Valverde
Sent: den 21 januari 2020 15:47
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] q on catching error in sub-dissectors.



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 values).
>
> The problem I'm hitting is that the first malformed inner packet fails all 
> the way out of my parent dissector, so it doesn't dissect any of the other 
> packets in the payload.
>
> Another problem I'm having is that the IP sub-dissector is overwriting my 
> source and destination addresses in the pinfo/tree (not sure which doesn't 
> really matter).
>
> Summary:
>
> - How can I "catch" errors in a subdissector so I can call other 
> sub-dissectors?

Use TRY/CATCH (in epan/exceptions.h).

> - How can I "block" sub-dissectors from overwriting my outer header 
> information?

I don't think you can. Maybe your IPTFS dissector can set it after the 
sub-dissectors run.

Not sure how you want it, there is col_set_fence()

>
> Thanks,
> Chris.
> ___
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
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] Bypassing the first layer

[Anders Broman via Wireshark-dev]

Hi,

Did not find it online, but some basics:

Put the following lines into a file

   00 0c 00 0c 67 73 6d 5f 61 5f 64 74 61 70 00 00  . gsm_a_dtap 67 73 
6d 5f 61 5f 64 74 61 70

0010   00 1e 00 04 00 00 00 01 00 00 00 00 08 15 03 

And run

text2pcap.exe -l 252 Manufacture_frames_exp_pdu.txt 
Manufactured_frames_exp_pdu.pcapng

 

   00 0c 00 0c 6e 61 73 2d 35 67 73 00 00 00 00 00   nas-5gs.

0010   00 1e 00 04 00 00 00 01 00 00 00 00 7e 00 3e 57   ..>A 
Message type last octet  0x57 Authentication response

0020   78 00 57 0a 01 25 46 00 00 55 71 53 01 d6 10 04   ó%F..UqS.Ö..

0030   8e 42 20 10 00 04 20 63 db 24 2f 04 4d aa 62 67   .B n.. cÛ$/.Mªbg

0040   52 22 04 78 78 00 33 78 00 30 00 5e 7b 78 40 04   R"."..0.nf.^{x@.

0050   75 9f 77 77 50 04 5a fa f6 6d b0 2b 03 3d ff ff   u.wwP.Zúöm°+.=ÿÿ

0060   2c 04 00 00 00 00 2d 06 00 00 00 00 00 00 c0 7c   ,.-...À|

0070   00 08 07 00 c0 7c 00 02 00 00 À|

text2pcap.exe -l 252 Manufacture_frames_exp_pdu.txt 
Manufactured_frames_exp_pdu.pcapng

 

 

 

From: Wireshark-dev  On Behalf Of Juanjo 
Martin Carrascosa
Sent: den 15 januari 2020 14:54
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Bypassing the first layer

 

This helps me too. There are some slides about export pdu.

 

But yes, any material is welcome. Thanks for the help team. This is fantastic.

 

On Wed, Jan 15, 2020 at 2:47 PM Dario Lombardo mailto:lom...@gmail.com> > wrote:

I don't think this is what Anders was talking about. This is about extcap, 
while I was referring to export_pdu.

If you or Anders can reference the right one, that would be great.

If you want to have a look at something using export_pdu creating a pcap file, 
have a loot at the udpdump.c code.

 

On Wed, Jan 15, 2020 at 2:37 PM Juanjo Martin Carrascosa mailto:jua...@rti.com> > wrote:

https://sharkfestus.wireshark.org/assets/presentations18/17.pptx

 

On Wed, Jan 15, 2020 at 2:36 PM Dario Lombardo mailto:lom...@gmail.com> > wrote:

Can you share the link, for future reference?

 

On Wed, Jan 15, 2020 at 2:15 PM Juanjo Martin Carrascosa mailto:jua...@rti.com> > wrote:

Found the presentation, this is fantastic.

 

Thanks!

 

On Wed, Jan 15, 2020 at 12:58 PM Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

Hi,

In the frame layer there is the “Encapsulation type” the way the pcap format 
works this indicates how the data following should be interpreted.

Linktype/encapsulation type is defined at  
<https://protect2.fireeye.com/v1/url?k=c347add8-9fcd786c-c347ed43-866a015dd3d5-d7661157f49a37ff=1=d82b7876-3625-4158-b8b6-c262c0dc56f8=https%3A%2F%2Fwww.tcpdump.org%2Flinktypes.html>
 https://www.tcpdump.org/linktypes.html so one thing you could do is to design 
your own DLT

Add whatever meta data you want and then add the RTPS data at some position in 
that structure. You can try this out by using the USER DLTs in Wireshark

Or if you do not want to request a DLT from tcpdump ( DO NOT USE ONE WITHOUT 
ALLOCATING IT) you could use the Exported PDU DLT defined by Wireshark

Epan/exported_pdu.h contains some information. If you would require new 
elements for meta information that could be discussed. Adding RTSP data in

An exported_pdu DLT frame should be simple as an initial test. I think there is 
a sharkfest presentation on how to add any protocol data in an exported pdu 
frame with text2pcap.

Regards

Anders

 

From: Wireshark-dev mailto:wireshark-dev-boun...@wireshark.org> > On Behalf Of Juanjo Martin 
Carrascosa
Sent: den 15 januari 2020 12:24
To: Developer support list for Wireshark mailto:wireshark-dev@wireshark.org> >
Subject: Re: [Wireshark-dev] Bypassing the first layer

 

Hi Dario,

 

Could you elaborate on this? I get the idea but my knowledge about the how is 
very basic.

 

How can this help me achieve what I need?

 

Thanks for the help.

Juanjo Martin

 

On Tue, Jan 14, 2020 at 4:48 PM Dario Lombardo mailto:lom...@gmail.com> > wrote:

You can use export_pdu. This is a layer with multiple attributes (see 
epan/exported_pdu.h), but the only really needed is the proto_name, that allows 
you to directly call a dissector by its name.

You will have frames with this stack: FRAME/EXPORT PDU/RTPS, that is properly 
dissected by wireshark.

 

On Tue, Jan 14, 2020 at 4:33 PM Juanjo Martin Carrascosa mailto:jua...@rti.com> > wrote:

Hi everyone,

 

RTPS is a protocol already supported by Wireshark. I have been helping maintain 
that protocol these past years. It sits on top of TCP and UDP, as well as some 
other transports that are not network ones (Shared Memory typically with a 
proprietary implementation).


 

We are currently working on implementing a new logging mechanism for our 
product, mainly to address the Shared Memory scenario but it can also be really 
useful when RTPS is used on top of network 

Re: [Wireshark-dev] Bypassing the first layer

[Anders Broman via Wireshark-dev]

Hi,

In the frame layer there is the “Encapsulation type” the way the pcap format 
works this indicates how the data following should be interpreted.

Linktype/encapsulation type is defined at  
 https://www.tcpdump.org/linktypes.html 
so one thing you could do is to design your own DLT

Add whatever meta data you want and then add the RTPS data at some position in 
that structure. You can try this out by using the USER DLTs in Wireshark

Or if you do not want to request a DLT from tcpdump ( DO NOT USE ONE WITHOUT 
ALLOCATING IT) you could use the Exported PDU DLT defined by Wireshark

Epan/exported_pdu.h contains some information. If you would require new 
elements for meta information that could be discussed. Adding RTSP data in

An exported_pdu DLT frame should be simple as an initial test. I think there is 
a sharkfest presentation on how to add any protocol data in an exported pdu 
frame with text2pcap.

Regards

Anders

 

From: Wireshark-dev  On Behalf Of Juanjo 
Martin Carrascosa
Sent: den 15 januari 2020 12:24
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Bypassing the first layer

 

Hi Dario,

 

Could you elaborate on this? I get the idea but my knowledge about the how is 
very basic.

 

How can this help me achieve what I need?

 

Thanks for the help.

Juanjo Martin

 

On Tue, Jan 14, 2020 at 4:48 PM Dario Lombardo mailto:lom...@gmail.com> > wrote:

You can use export_pdu. This is a layer with multiple attributes (see 
epan/exported_pdu.h), but the only really needed is the proto_name, that allows 
you to directly call a dissector by its name.

You will have frames with this stack: FRAME/EXPORT PDU/RTPS, that is properly 
dissected by wireshark.

 

On Tue, Jan 14, 2020 at 4:33 PM Juanjo Martin Carrascosa mailto:jua...@rti.com> > wrote:

Hi everyone,

 

RTPS is a protocol already supported by Wireshark. I have been helping maintain 
that protocol these past years. It sits on top of TCP and UDP, as well as some 
other transports that are not network ones (Shared Memory typically with a 
proprietary implementation).


 

We are currently working on implementing a new logging mechanism for our 
product, mainly to address the Shared Memory scenario but it can also be really 
useful when RTPS is used on top of network protocols. 

 

Problem: We can log the RTPS layer but we don't have some information in our 
middleware like the Frame or Ethernet information, so we need to make it up. 
This is ugly, so I am trying to avoid that:

 

How can I register a protocol so it is picked up instead of the Frame layer? 
This is, I want to create a new protocol that detects that the information we 
generate is for that protocol and the Frame protocol is not called, but the new 
protocol I am creating. This new protocol will then call the RTPS protocol to 
dissect the payload I want to display. We are planning to also add some 
information to this custom protocol, that's why I want it to be called first.

 

Note: I just came up with this solution, but if you have a different solution 
for this, please let me know.

 

Thanks,

Juanjo Martin

___
Sent via:Wireshark-dev mailing list mailto:wireshark-dev@wireshark.org> >
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 mailto:wireshark-dev@wireshark.org> >
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




 

-- 

 

Juanjo Martin

Principal Application Engineer

EMEA Services Lead @ Professional Services Group

Office: +34 958 27 88 62

jua...@rti.com  

www.rti.com 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
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] Brotli decompression

[Anders Broman via Wireshark-dev]

Hi,
On Windows it should be included, check About Wireshark
Regards
Anders

-Original Message-
From: Wireshark-dev  On Behalf Of Jasper 
Bongertz
Sent: den 19 december 2019 13:30
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Brotli decompression

Hello all,

  I found this in the release notes of Wireshark 3.2:   "Brotli decompression 
support in HTTP/HTTP2 (requires the brotli library)"

  Sounds great, but I can't seem to find any instructions how to add the 
"brotli
  library" to my Wireshark installation. I guess I need some DLL, but all I
  could find are the Github pages with the source code. Does anyone have a 
good
  instruction set for Wireshark on Windows to enable Brotli?

  I did a "Follow HTTP2 stream" and got unreadable stuff (decrypted first with
  SSLKEYLOG file), so I guess Brotli is  what I need to see the actual page 
contents...

Thanks & cheers,
Jasper


___
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


smime.p7s
Description: S/MIME cryptographic signature
___
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-bugs] [Bug 16265] Some Windows packages need updating

[Anders Broman]

Den mån 9 dec. 2019 19:42  skrev:

> *Comment # 5
>  on bug 16265
>  from
> Christopher Maynard  *
>
> (In reply to Pascal Quantin from comment #2 
> )> If you are 
> aware of security issues with the packages we bundle, please let
> > us know and we will see what we can do. Otherwise we generally do not update
> > the libraries in the stable version.
>
> Here's what I've found:
> ===
> The Gtk+ 2-24 release notes can be found 
> here:https://gitlab.gnome.org/GNOME/gtk/blob/gtk-2-24/NEWS.  There is 1 CVE 
> listed,
> although there are numerous bug fixes including for crashes.
>
> The Glib release notes can be found 
> here:https://gitlab.gnome.org/GNOME/glib/blob/master/NEWS.  There are 4 CVE's
> listed, 1 of which is fixed in the 2.61.2 release, which is after the 2.52
> release.  Obviously, there have been numerous bug fixes including for crashes
> as well.
>
> The latest Kerberos for Windows (https://web.mit.edu/kerberos/dist/) version 
> is
> 4.1 based on MIT krb5 1.13, whereas 3.2.2 was based on 1.6.3.  Historical
> releases can be found here: https://web.mit.edu/kerberos/dist/historic.html.
> It isn't quite as easy to review the changes for this project, but there are
> CVE's listed for this project too.  (NOTE: I only looked at the CHANGES for
> 1.13.0, but I count a total of 39 releases after 1.6.3 up to and including
> 1.13.0.)
>
> The libxml2 changelog is 
> here:https://gitlab.gnome.org/GNOME/libxml2/blob/master/ChangeLog.  I believe
> version 2.9.10 was released a month ago; it's unclear to me if there were any
> CVE's fixed in this release.
>
> The Lua Binaries can be found 
> at:http://luabinaries.sourceforge.net/download.html.  There's 1 release newer 
> than
> 5.2.4, namely 5.3.5.  I didn't look for security vulnerabilities.
>
> The latest available release of nasm is 2.14.02 (with 2.14.03 in rc2 status),
> but that's 30 releases since 2.09.08: https://nasm.us/doc/nasmdocc.html.  I
> don't see any CVE's mentioned, but there are numerous bug fixes, including for
> 4  mentioned crashes post-2.09.08.
>
> It would appear that there have been no updates to Portaudio since v19, so
> Wireshark 2.6 likely has the latest version: 
> http://portaudio.com/download.html
>
> And finally, it would also appear that zlib 1.2.11 is the latest version
> available as well: http://www.zlib.net/
> ===
>
> It isn't for me to judge the severity of these bugs and the impact (or
> non-impact) to Wireshark, but to try to bring it to the attention of the
> Wireshark community to decide what to do, if anything, regarding upgrading
> these packages (or not).
>
> (In reply to Pascal Quantin from comment #4 
> )> When 
> upgrading third party packages, you take the risk of introducing new
> > bug (and yes it happened to us with Npcap for example). So it should be
> > handled on a case by case basis IMHO, and not done systematically.
> > Any help is welcome to mantain the packages up to date of course.
>
> True, but by not upgrading, you end up deploying packages with known bugs and
> vulnerabilities.
>
> But upgrading to our latest package is probably better :-)

> --
> You are receiving this mail because:
>
>- You are watching all bug changes.
>
> ___
> Sent via:Wireshark-bugs mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-bugs
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
>  mailto:wireshark-bugs-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] Accessing Mystery Case Studies under Wire Shark

[Anders Broman via Wireshark-dev]

Hi, 

No idea what you are talking about.

/Regards

Anders

 

From: Wireshark-dev  On Behalf Of St
John, John Arthur
Sent: den 7 november 2019 01:12
To: wireshark-dev@wireshark.org
Cc: St John, John Arthur 
Subject: [Wireshark-dev] Accessing Mystery Case Studies under Wire Shark

 

Good Day Wire shark,

 

My name is Professor John St John, I'm a a teacher st DeVry University and 

currently teaching a Network Class, where this week my students are

required to watch of the mystery cases and when they try to click on one it
takes

them to a page where they need to make a purchase. 

 

Trying to find the best possible route for my students to watch the cases

and complete they assignment.  

 

Thank You for your time and consideration. Have a wonderful day.

 

John St John

DeVry University Professor

jstj...@devry.edu  

6192274755

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
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