Re: [Wireshark-dev] Tracking branches, GitHub and Launchpad

[Pascal Quantin]

17 déc. 2023 23:29:59 Guy Harris :

> On Dec 17, 2023, at 10:08 AM, Jaap Keuter  wrote:
> 
>> 1. The GitHub mirror is picking up all our cherry-pick branches, which now 
>> run in the hundreds.
> 
> 1.5. Are cherry-pick branches deleted once the changes on those branches are 
> merged into the version branch and, if not, why not?  Do they serve some 
> purpose such as recording history that is, in some fashion, of interest?  The 
> changes themselves are in the version branch and, by default, the commit 
> message includes the signature of the commit from which it was cherry-picked.

They are deleted most of the time (when the option is checked in GitLab UI, 
which is the default value). Once in a while I delete a few stale merge 
branches that stay open because the corresponding merge requests were closed or 
because the delete option was not selected, to keep our branches number under 
control.
___
Sent via:Wireshark-dev mailing list 
Archives: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

[Pascal Quantin]

Le mer. 22 nov. 2023 à 14:25, João Valverde  a écrit :

>
> On 22/11/23 13:12, Pascal Quantin wrote:
>
> Hi Joao,
>
> Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :
>
>> You are free to participate in the discussion or not. But I really don't
>> care to wait for the new committee that is pretty much exactly the same as
>> the old committee, as far as I can tell.
>>
>> Anyway silence is another Wireshark project classic. At least you tried
>> to bring something to the debate, so thank you for that, at least.
>>
>
> It seems like the discussion is shifting away from the initial goal. I
> don't think aggression/criticism/sarcasm brings anything to the debate, so
> I would prefer to keep a constructive exchange between whoever feels
> involved in the subject. I personally have never used the Debian scripts,
> but I did not consider updating the symbols list as being a really time
> consuming task (and I did it numerous times in the past), so I do not have
> an opinion on whether the current status quo is good or bad.
> Balint's initial email was to collect some feedback regarding whether the
> scripts are being used or not. Anders provided the first feedback, let's
> see if others do (with the hope that they are monitoring this list...).
>
>
> I'm not being aggressive, I'm being candid. And also expressing some
> pretty valid (IMO) criticisms.
>
And let the discussion shift, what about it? I think it's all relevant to
> the issue of Debian packaging.
>

Well that's all about communication. I personally find the emails you are
sending today as being more and more aggressive. Maybe that's just me, or
maybe this is the language / cultural differences, but I think it was worth
notifying you as you might not be aware of how others can react to what you
are writing.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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

[Pascal Quantin]

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :

> You are free to participate in the discussion or not. But I really don't
> care to wait for the new committee that is pretty much exactly the same as
> the old committee, as far as I can tell.
>
> Anyway silence is another Wireshark project classic. At least you tried to
> bring something to the debate, so thank you for that, at least.
>

It seems like the discussion is shifting away from the initial goal. I
don't think aggression/criticism/sarcasm brings anything to the debate, so
I would prefer to keep a constructive exchange between whoever feels
involved in the subject. I personally have never used the Debian scripts,
but I did not consider updating the symbols list as being a really time
consuming task (and I did it numerous times in the past), so I do not have
an opinion on whether the current status quo is good or bad.
Balint's initial email was to collect some feedback regarding whether the
scripts are being used or not. Anders provided the first feedback, let's
see if others do (with the hope that they are monitoring this list...).

Best regards,
Pascal.


> On 22/11/23 11:45, Roland Knall wrote:
>
> Hi
>
> I would recommend that we bring this topic before the technical steering
> committee. As of right now, that committee needs to be formed in
> January and this topic is exactly why we are going to have the committee in
> the first place. The process is in the final steps and should be finished
> by the end of the year anyway.
>
> I do not think that further discussing this issue is actually beneficial
> for the long term resolution of this situation. Both sides have valid
> arguments and good pointers and I would suggest as soon as the committee
> has taken up the topic we collectively create a single mission statement as
> suggested by Joao above. Until then, personally I will refrain from
> discussing this further, as I have said everything there is to say from
> my perspective.
>
> Do you agree Gerald?
>
> kind regards
> Roland
>
>
>
> Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :
>
>> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
>> Since you've got the experience and actually use it?
>>
>> There are loads of lintian warnings waiting to be fixed, or there were
>> until recently. Maybe you'd like to start there, and be more active staying
>> on top of the all-important symbol lists. Just a thought.
>>
>> On 21/11/23 15:00, Anders Broman wrote:
>>
>> Hi,
>> I found it useful to be able to do Debian packages easily to provide
>> internal installation packages and even ppa for Ubuntu.
>> So I have been using the Debian build system.
>> Best regards
>> Anders
>>
>> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>>
>>> As mentioned on the ticket - just putting it here as well - I am against
>>> dropping packaging/debian. But I am for having it underneath packaging, and
>>> not in the main directory, which is what the original change was about. I
>>> respect Joao's opinion as well as yours Balint. In this case here I think,
>>> we can provide assistance for future implementors and as a starting point,
>>> by keeping the directory underneath packaging/debian.
>>>
>>> just my thoughts
>>> Roland
>>>
>>>
>>> Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
>>> bal...@balintreczey.hu>:
>>>
 Hi All,

 João shared his opinion about the project's commitment to maintain the
 packaging/debian/ in the project's repository:


 https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

 I believe the current practice is reasonable and beneficial enough for
 many parties to warrant the work, but I could be wrong.

 Probably the most important question is if there is anyone relying on
 the packaging scripts there. If you are, please speak up otherwise the
 directory may be dropped.

 Comments are welcome.

 Cheers,
 Balint

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

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

Re: [Wireshark-dev] Examples where field doesn't have enough bits of value_string values

[Pascal Quantin]

Hi Martin,

Le jeu. 21 sept. 2023 à 22:20, Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> After https://gitlab.com/wireshark/wireshark/-/merge_requests/12195, I'm
> finding the warnings below.  I think these are valid, based upon editing a
> mask value and watching how the value was masked/shifted before being
> looked up in the value_string.
>
> I understand the RoHC example, where a newer version of the protocol
> supports the new values in a wider field, but the old one still uses the
> updated value_string, despite some of the values being impossible to match.
>
> A common mistake seems to be to add to the value_string the byte values in
> the frame, rather than the masked + shifted value of the field as
> calculated in the item before looking up the value_string.
>
> I can hopefully try to look at these as time permits, but if you are
> familiar with any of the protocols below, I'd appreciate any fixes/feedback
> you can give!
>
> Best regards,
> Martin
>
>
>
> Warning: epan/dissectors/packet-amp.c hf_ari_struct filter= amp.struct
> VALS(amp_ari_struct_type) has max value 19 (0x13) which doesn't fit into 4
> bits ( mask is 0xf )
>
> Warning: epan/dissectors/packet-ansi_map.c hf_ansi_map_pagingFrameClass
> filter= ansi_map.pagingFrameClass VALS(ansi_map_PagingFrameClass_vals) has
> max value 8 (0x8) which doesn't fit into 2 bits ( mask is 0x3 )
>
> Warning: epan/dissectors/packet-bittorrent.c hf_bittorrent_msg_type
> filter= bittorrent.msg.type VALS(bittorrent_messages) has max value 261
> (0x105) which doesn't fit into 8 bits ( mask is 0x0 )
>
> Warning: epan/dissectors/packet-btatt.c hf_btatt_opcode_method filter=
> btatt.opcode.method VALS(opcode_vals) has max value 210 (0xd2) which
> doesn't fit into 6 bits ( mask is 0x3f )
>
> Warning: epan/dissectors/packet-bthci_cmd.c
> hf_btcommon_eir_ad_oob_flags_address_type filter=
> btcommon.eir_ad.entry.oob_flags.oob_address_type
> VALS(bthci_cmd_address_types_vals) has max value 3 (0x3) which doesn't fit
> into 1 bits ( mask is 0x8 )
>
> Warning: epan/dissectors/packet-bthci_evt.c
> hf_bthci_evt_ext_advts_event_type_data_status filter=
> bthci_evt.le_ext_advts_event_type.data_status
> VALS(ext_adv_data_status_vals) has max value 255 (0xff) which doesn't fit
> into 2 bits ( mask is 0x60 )
>
> Warning: epan/dissectors/packet-btmesh.c
> hf_btmesh_sensor_status_mpid_format_a_property_id filter=
> btmesh.model.sensor_status.mpid.format_a.property_id
> VALS(btmesh_properties_vals) has max value 65535 (0x) which doesn't fit
> into 11 bits ( mask is 0xffe0 )
>
> Warning: epan/dissectors/packet-btrfcomm.c hf_frame_type filter=
> btrfcomm.frame_type VALS(vs_frame_type) has max value 239 (0xef) which
> doesn't fit into 7 bits ( mask is 0xef )
>
> Warning: epan/dissectors/packet-canopen.c
> hf_canopen_sdo_cmd_ccs6_subcommand filter= canopen.sdo.cs
> VALS(sdo_client_subcommand_meaning) has max value 3 (0x3) which doesn't fit
> into 1 bits ( mask is 0x1 )
>
> Warning: epan/dissectors/packet-canopen.c
> hf_canopen_sdo_cmd_scs6_subcommand filter= canopen.sdo.ss
> VALS(sdo_server_subcommand_meaning) has max value 2 (0x2) which doesn't fit
> into 1 bits ( mask is 0x1 )
>
> Warning: epan/dissectors/packet-cbor.c hf_cbor_type_tag5 filter=
> cbor.type.tag VALS(tag32_vals) has max value 55799 (0xd9f7) which doesn't
> fit into 5 bits ( mask is 0x1f )
>
> Warning: epan/dissectors/packet-cimd.c
> hf_cimd_dcs_coding_group_indicatorC0 filter= cimd.dcs.cg
> VALS(cimd_dcs_coding_groups) has max value 15 (0xf) which doesn't fit into
> 2 bits ( mask is 0xc0 )
>
> Warning: epan/dissectors/packet-cimd.c
> hf_cimd_dcs_character_set_indicator04 filter= cimd.dcs.chs
> VALS(cimd_dcs_character_set) has max value 3 (0x3) which doesn't fit into 1
> bits ( mask is 0x4 )
>
> Warning: epan/dissectors/packet-dec-dnart.c hf_dec_rt_services filter=
> dec_dna.nsp.services VALS(rt_services_vals) has max value 12 (0xc) which
> doesn't fit into 2 bits ( mask is 0xc )
>
> Warning: epan/dissectors/packet-devicenet.c hf_devicenet_fragment_type
> filter= devicenet.fragment_type
> VALS(devicenet_fragmented_message_type_vals) has max value 192 (0xc0) which
> doesn't fit into 2 bits ( mask is 0xc0 )
>
> Warning: epan/dissectors/packet-dpnss.c hf_dpnss_sic_oct2_data_type
> filter= dpnss.sic_oct2_data_type VALS(dpnss_sic_oct2_data_type_vals) has
> max value 7 (0x7) which doesn't fit into 2 bits ( mask is 0x3 )
>
> Warning: epan/dissectors/packet-ehs.c hf_ehs_ph_data_mode filter=
> ehs.data_mode VALS(ehs_primary_header_data_mode) has max value 16 (0x10)
> which doesn't fit into 4 bits ( mask is 0xf )
>
> Warning: epan/dissectors/packet-gmr1_rr.c hf_rr_msg_type filter=
> gmr1.rr.msg_type VALS(gmr1_msg_rr_strings) has max value 318 (0x13e) which
> doesn't fit into 8 bits ( mask is 0x0 )
>
> Warning: epan/dissectors/packet-gsm_a_bssmap.c hf_gsm_a_bssmap_dlci_cc
> filter= gsm_a.bssmap.dlci.cc VALS(bssap_cc_values) has max value 192
> (0xc0) which doesn't fit into 2 bits ( mask is 

Re: [Wireshark-dev] Wireshark warning for F1AP protocol: something unknown here [10.9 Unconstrained]

[Pascal Quantin]

Hi,

Le jeu. 24 août 2023 à 17:39, SAURABH SARAF  a
écrit :

> While decoding Ue Assistance information in F1ap Ue context modification
> request, warning "something unknown here [10.9 Unconstrained]" is seen.
> Dump for the same RRC container is getting decoded properly in x2ap rrc
> transfer message.
>

This is not a Wireshark bug but a CU bug as explained in
https://gitlab.com/wireshark/wireshark/-/issues/19301

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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] rewrite of asterix dissector

[Pascal Quantin]

Hi Zoran,

Le ven. 18 août 2023 à 17:36, Zoran Bošnjak  a écrit :

> Dear wireshark developers,
> I am rewriting asterix dissector. There are some open problems on asterix,
> which are almost impossible to resolve in the current setting.
>
> The idea is to split the code between pure generated code (with all
> asterix items and other asterix related definitions), but which does not
> depend on wireshark internals at all, something like this:
>
> https://gitlab.com/zoranbosnjak/wireshark/-/blob/8db96a7226ed6c7efc60aca6313adbb6957ac35a/epan/dissectors/asterix-specs.h
>
> ... and the packet-asterix.c file which does what is necessary to dissect
> asterix. It includes the asterix-specs.h file. Something like this:
>
> https://gitlab.com/zoranbosnjak/wireshark/-/blob/8db96a7226ed6c7efc60aca6313adbb6957ac35a/epan/dissectors/packet-asterix.c
>
> The reason for a pure asterix-specs.h file is that it reduces the
> maintenance, since the same code could be used in any asterix related C
> project. It is also much shorter since the same definitions are defined
> only once. I could even check it alone with "gcc -Wall asterix-specs.h".
> And the packet-asterix.c becomes cleaner and shorter too.
>
> I have made some progress with this approach (see the 'asterix' branch in
> the repository above), but I am now facing the problem with 'hf' array in
>
> proto_register_field_array (proto_asterix, hf, array_length (hf));
>
> ...which is currently specified in the source code (statically known at
> compile time for each item).
>
> What would be the best way to populate this (hf) array at the
> initialization time or even during dissecting?
> The number of all distinct items is known at compile time, so the
> necessary memory could be prepared without any dynamic allocation, for
> example
>
> static int hf_generated_items[TOTAL_ITEM_COUNT];
> for (int i=0; i
> Are there any examples on other generated dissectors, where hf array is
> initialized at runtime?
>

See packet-diameter.c and its use of the proto_register_prefix() function
for example.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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] Are we fully moved over to C++ compilers?

[Pascal Quantin]

Hi Gilbert,

17 mai 2023 23:41:21 Gilbert Ramirez :

> What's the state of our toolchain requirements for wireshark and all the 
> programs within it?
> The CMakeLists.txt indicates we need C++ 11, but also has variables for 
> C_ONLY_FLAGS
>
> Some .c/.h files have "#ifdef __cplusplus" and others don't.
>
> Basically, if I'm working on a new feature in common code for tshark and 
> wireshark, can I rely on C++ and the STL, or must I restrain myself to C and 
> glib?

You should stick to C (C++ being used for Qt code). Lately we allowed the use 
of stdint.h types if I'm not mistaken, but 99.9% of the code still uses glib 
types and functions.

Best regards,
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

Re: [Wireshark-dev] URL correction for section 8.1 of Wireshark Developer’s Guide

[Pascal Quantin]

Hi Denis,

Le ven. 25 nov. 2022 à 00:39, Denis Ovsienko  a écrit :

> Hello.
>
> On this page [1] please replace the old URL [2] with the new URL [3].
>

Thanks for the notification, done in
https://gitlab.com/wireshark/wireshark/-/merge_requests/8930

Best regards,
Pascal.


> Thank you!
>
> 1: https://www.wireshark.org/docs/wsdg_html_chunked/ChapterCapture.html
>
> 2:
>
> https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.capture-module
>
> 3: https://www.tcpdump.org/libpcap-module-HOWTO.html
>
> --
> Denis Ovsienko
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Destination Embedded IPv4 address in IPv6 not correct in "Paacket Details" for 4.0.1

[Pascal Quantin]

Hi Joel,

Le dim. 6 nov. 2022 à 16:39, Joel Moxey  a écrit :

> Hi!
>
> PFA example PCAP as requested.
>

Thanks for the pcap, the inbound fix can be found here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/8793

Best regards,
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

Re: [Wireshark-dev] Destination Embedded IPv4 address in IPv6 not correct in "Packet Details" for 4.0.1

[Pascal Quantin]

Hi Joel,

Could you please share a pcap exhibiting your issue?

Thanks and best regards,
Pascal.

3 nov. 2022 23:31:04 Joel Moxey :

> *In 4.0.1:*
> 
> No.     Time               Delta time     Source                Src port 
> Destination           Dst port Protocol Length RAT Type   TEID/GRE Key 
> Sequence Number Layer 2 Tunneling Protocol Info
>       5 18:42:33.216141    0.000130       2605:4580:0:a::1      2000     
> 64:ff9b::330:1        80       TCP      74                                    
>                                     2000 → 80 [SYN] Seq=1597636906 Win=32768 
> Len=0
> 
> Frame 5: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
> Ethernet II, Src: IntelCor_be:7c:f8 (3c:fd:fe:be:7c:f8), Dst: 
> Fortinet_06:27:80 (e0:23:ff:06:27:80)
> Internet Protocol Version 6, Src: 2605:4580:0:a::1, Dst: 64:ff9b::330:1
>     0110  = Version: 6
>             = Traffic Class: 0x00 (DSCP: CS0, 
> ECN: Not-ECT)
>           = Flow Label: 0x0
>     Payload Length: 20
>     Next Header: TCP (6)
>     Hop Limit: 64
>     Source Address: 2605:4580:0:a::1
>     Destination Address: 64:ff9b::330:1
>     [Embedded IPv4 Prefix: 0064ff9b]
> *    [Destination Embedded IPv4: 0.0.0.10]
>     [Embedded IPv4: 0.0.0.10]*
> Transmission Control Protocol, Src Port: 2000, Dst Port: 80, Seq: 1597636906, 
> Len: 0
> 
> *In 3.6.9:*
> 
> No.     Time               Delta time     Source                Src port 
> Destination           Dst port Protocol Length RAT Type   TEID/GRE Key 
> Sequence Number Layer 2 Tunneling Protocol Info
>       5 18:42:33.216141    0.000130       2605:4580:0:a::1      2000     
> 64:ff9b::330:1        80       TCP      74                                    
>                                     2000 → 80 [SYN] Seq=1597636906 Win=32768 
> Len=0
> 
> Frame 5: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
> Ethernet II, Src: IntelCor_be:7c:f8 (3c:fd:fe:be:7c:f8), Dst: 
> Fortinet_06:27:80 (e0:23:ff:06:27:80)
> Internet Protocol Version 6, Src: 2605:4580:0:a::1, Dst: 64:ff9b::330:1
>     0110  = Version: 6
>             = Traffic Class: 0x00 (DSCP: CS0, 
> ECN: Not-ECT)
>           = Flow Label: 0x0
>     Payload Length: 20
>     Next Header: TCP (6)
>     Hop Limit: 64
>     Source Address: 2605:4580:0:a::1
>     Destination Address: 64:ff9b::330:1
>    *[Destination Embedded IPv4: 3.48.0.1]*
> Transmission Control Protocol, Src Port: 2000, Dst Port: 80, Seq: 1597636906, 
> Len: 0
___
Sent via:Wireshark-dev mailing list 
Archives: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] Max size of a field seems to be 240 for a dissector

[Pascal Quantin]

Hi Richard,

Le mar. 18 oct. 2022 à 18:30, Richard Sharpe 
a écrit :

> Hi folks,
>
> How do I squeeze more than 240 chars into a string field?
>

You can't currently.  As seen in epan/proto.h, you have the
ITEM_LABEL_LENGTH define set to 240 and that exists since ages.


> I am trying to fix an issue with the beamforming matrices for 802.11ax
> and 802.11be and maybe 802.11ac.
>

I guess you refer to https://gitlab.com/wireshark/wireshark/-/issues/18504


> When I try to assemble all of a single SCIDX, I get this:
> 
> S [truncated]: SCIDX: -122, phi11:57, phi21:34, phi31:59, phi41:8,
> phi51:52, phi61:18, phi71:14, psi21:10, psi31:8, psi41:1, psi51:5,
> psi61:5, psi71:3, psi81:4, phi22:33, phi32:22, phi42:22, phi52:10,
> phi62:41, phi72:59, psi32:8, psi42:3,
> --
>
> Why is there an arbitrary limit? Is it because I am working with 3.4.8?
>

No, it has been like this for 23 years according to Git blame.
Maybe it's time to display this matrix differently (with several lines?)
instead of appending all those infos in a single line?

Best regards,
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

Re: [Wireshark-dev] Wiki: Backporting A Change To A Release Branch

[Pascal Quantin]

Hi Chuck,

it works fine here:

~/wireshark/git$ git remote -v
downstream  g...@gitlab.com:pquantin/wireshark.git (fetch)
downstream  g...@gitlab.com:pquantin/wireshark.git (push)
upstreamg...@gitlab.com:wireshark/wireshark.git (fetch)
upstreamg...@gitlab.com:wireshark/wireshark.git (push)
~/wireshark/git$ git checkout -b test upstream/release-4.0
Branch 'test' set up to track remote branch 'release-4.0' from 'upstream'.
Switched to a new branch 'test'

Le lun. 26 sept. 2022 à 22:00, chuck c  a écrit :

> wireshark$ git remote -v
> downstream  g...@gitlab.com:chuckcraft/wireshark.git (fetch)
> downstream  g...@gitlab.com:chuckcraft/wireshark.git (push)
> upstreamg...@gitlab.com:wireshark/wireshark.git (fetch)
> upstreamg...@gitlab.com:wireshark/wireshark.git (push)
>
> wireshark$ git branch -r -l | grep -i upstream
>   upstream/master
>
> wireshark$ git checkout -b github_4_0_qt6 upstream/release-4.0
> fatal: 'upstream/release-4.0' is not a commit and a branch
> 'github_4_0_qt6' cannot be created from it
>
> (link to the wiki page the original email referenced:
> https://wiki.wireshark.org/Development/SubmittingPatches#backporting-a-change-to-a-release-branch
> )
>
> On Mon, Sep 26, 2022 at 2:43 PM Jaap Keuter  wrote:
>
>> Hi,
>>
>> Yes, the text is still relevant, in case you’re looking to back port a
>> change from master to release-X.Y.
>>
>> What you’re seem to be looking at is making a change in release-4.0 only.
>> So, checkout release-4.0 first. Then create a branch from that and put
>> your change on there and push that.
>>
>> Regards,
>> Jaap
>>
>>
>> On 26 Sep 2022, at 00:52, chuck c  wrote:
>>
>> Is this section of the Wiki still accurate?
>>
>> (substituting  "release-4.0" for "master-X.Y"
>>
>> "Create and checkout a new branch with a name related to the type of
>> change (e.g. the bug number you're fixing or the dissector you're working
>> on):
>>   git checkout -b my-branch-name upstream/master-X.Y
>> where "master-X.Y" is the release branch to which to backport the change.
>>
>> This creates a branch named "my-branch-name" based on the master-X.Y
>> branch in the official repository."
>>
>> Or how best to make a change to:
>>
>> https://gitlab.com/wireshark/wireshark/-/blob/release-4.0/.github/workflows/windows.yml
>> that doesn't apply to master.
>>
>> thanks
>> chuckc
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>> 
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Issue with the NR-RRC Di-sector

[Pascal Quantin]

Hi,

Le jeu. 28 oct. 2021 à 17:45, Chilla Sunil Kumar-Trainee <
csku...@parallelwireless.com> a écrit :

> Hi,
>
> I had an issue with RRC messages.
>
>1. In F1Setup Request message , it is not Showing the complete message
>information. SIB1 Information is missing and showing that  *[Expert
>Info (Warning/Undecoded): something unknown here [too long
>integer(per_normally_small_nonnegative_whole_number)]]*
>*[something unknown here [too long
>integer(per_normally_small_nonnegative_whole_number)]]*
>*[Severity level: Warning]*
>*[Group: Undecoded].* Please find this in the attached snapshot – F1
>setup issue.png
>
> We cannot provide any support with a screenshot only. It could be that
your SIB1 message is not properly encoded of a bug in Wireshark.

>
>1.
>2. I am not able to see some RRC messages like *NAS Security mode
>Command Complete* and *AS Security mode Command.* Please find the
>attached snapshot - RRC.png
>
> If you use ciphering, this is expected as Wirehark does not include the
(potentially patented) code to perform deciphering (that would be UE
specific also due to the different ciphering key).

>
>1.
>2. Not able to find the message transmission in between gNB_DU and UE
>(Over the Air messages) - Please find this in the attached snapshot –need
>rrc.png
>
> See the response above.

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

Re: [Wireshark-dev] How to manage conn hashtable? recv TH_FIN, TH_RST packet will remove conn from hashtable and free conn memory?

[Pascal Quantin]

Hi,

Le mer. 22 sept. 2021 à 17:42, ygm via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> How to manage conn hashtable? recv TH_FIN, TH_RST packet will remove conn
> from hashtable and free conn memory:
>   conversation_hashtable_no_addr2_or_port2;
>   conversation_hashtable_no_addr2;
>   conversation_hashtable_no_port2;
>   conversation_hashtable_exact;
>

Thanks for bringing the discussion to the -dev list rather than on GitLab
issues tracker.
As said in the previous issue you opened, please provide more context and a
more precise question as currently it is way too vague to understand what
you want to know exactly.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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 does not build on Ubunty 18.04 with LZ4 (to old version?)

[Pascal Quantin]

Hi Anders,

Le mar. 7 sept. 2021 à 14:33, Anders Broman via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

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

Rather than requiring a higher version of LZ4 (that is also used by CQL and
Kafka dissectors), I guess we could check the LZ4 version found in
file_wrappers.c. What do you think ?

Cheers,
Pascal.


>
>
>
> 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
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] close issues

[Pascal Quantin]

Hi John,

4 sept. 2021 15:52:10 John Thacker :

> BACnet issues
> https://gitlab.com/wireshark/wireshark/-/issues/17142
> https://gitlab.com/wireshark/wireshark/-/issues/17398
>
> were both fixed by merge
> https://gitlab.com/wireshark/wireshark/-/merge_requests/3019
>
> (Merge 3019 tried to automatically close 17142, but the commit message was 
> slightly off in how Gitlab automatically parses it, and it only viewed it as 
> "related to.")
>
> Can someone with the proper permissions close them?

Thanks for the notification, I closed them.

Best regards,
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

Re: [Wireshark-dev] Wireshark 3.4.8 build from source tarball fails generating build files

[Pascal Quantin]

Hi Michael,

27 août 2021 19:54:17 Michael Lum :

> Thank you Graham.
>  
> I have successfully generated the build files and built Wireshark now.
> The change that made the difference was as Gerald pointed out, #5 in your 
> list.
>  
> My Wireshark build script has evolved over the years, thus the old stuff.
> I will make the changes you have suggested.
>  
> I also missed the part about Windows 7 not being supported past 3.2, I 
> believe.
> I'm assuming #4 is because I am building on Windows 7.

FYI I'm still able to build on Win7 x64 using an up to date MSVC 2019.

>  
> My only problem is now getting everything packaged with NSIS.
> I'll create a separate email for that.
>  
> Thank you again for your timely assistance.
>  
> Michael Lum
>  
> 
> *From:* Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] *On Behalf 
> Of *Graham Bloice
> *Sent:* August-27-21 12:43 AM
> *To:* Developer support list for Wireshark
> *Subject:* Re: [Wireshark-dev] Wireshark 3.4.8 build from source tarball 
> fails generating build files
>
> You don't appear to be following the current Developers Guide steps for 
> building Wireshark.  While it's not the only approach that will work, it is 
> known to work.
>
> A couple of things jump out to me:
1. > Cygwin.  Building wireshark does not need Cygwin, and in the past it has 
caused issues. If at all possible don't have Cygwin present in your Wireshark 
build env.
2. > From 1.,  WIRESHARK_CYGWIN_INSTALL_PATH is no longer used or does anything.
3. > No need to set WIRESHARK_TARGET_PLATFORM, that's set by the CMake scripts.
4. > Your Visual Studio environment seems odd, e.g. " -- Selecting Windows SDK 
version 8.1 to target Windows 6.1.7601. ".  normally VS2019 will have the 
Windows 10 SDK installed.
5. > As noted by Gerald WIRESHARK_BASE_DIR should NOT be the same as the build 
dir.  The WSDG steps set this to the parent of the source and build dirs, e.g.
> C:\Development
>     Wireshark (source dir)
>     wsbuild64 (build dir)
>     wireshark-win64-libs-xxx
>
>
> On Thu, 26 Aug 2021 at 21:43, Michael Lum  
> wrote:
> Hi,
>  
> I'm using the source tarball from the download page, extracted into 
> c:\wireshark-3.4.8
>  
> I've got multiple Wireshark builds and multiple VS installations.
> The last Wireshark build I did was 3.0.1.
>  
> I was following the Developer's Guide for the most part.
> I am not using Git, Asciidoctor, Xsltproc or DocBook.
> I installed strawberryperl.
>  
> I have nuked the ws348-64 directory and retried a couple of times and
> always get the same results. (That's good ;))
>  
> These are my build settings:
>  
>   set WIRESHARK_BASE_DIR=C:\ws348-64
>   set WIRESHARK_VERSION_EXTRA=-StarSolutions-1
>   set CYGWIN=nodosfilewarning
>   set WIRESHARK_TARGET_PLATFORM=win64
>   set QT5_BASE_DIR=C:\Qt\5.15.2\5.15.2\msvc2019_64
>   set WIRESHARK_CYGWIN_INSTALL_PATH=c:/cygwin64
> Running this with administrator rights:
>  
> x64 Native Tools Command Prompt for VS 2019
>  
> The command I ran:
>  
> "WIRESHARK_CYGWIN_INSTALL_PATH=c:/cygwin64"
> cmake -G "Visual Studio 16 2019" -A x64 c:\wireshark-3.4.8\
> -- Selecting Windows SDK version 8.1 to target Windows 6.1.7601.
> -- Generating build using CMake 3.21.2
> -- LTO/IPO is enabled
> -- Building for win64 using Visual Studio 16 2019
> Working in C:\ws348-64\wireshark-win64-libs-3.4
> Tag 2021-05-29-3.4 found. Skipping.
> -- CMake build type: RelWithDebInfo
> -- V: 3.4.8-StarSolutions-1, MaV: 3, MiV: 4, PL: 8, EV: -StarSolutions-1.
> -- Linker flags: /LARGEADDRESSAWARE /MANIFEST:NO /INCREMENTAL:NO /RELEASE 
> /guard:cf
> -- Could NOT find Git (missing: GIT_EXECUTABLE)
> Java HotSpot(TM) Client VM warning: TieredCompilation is disabled in this 
> release.
> -- Could NOT find DOXYGEN (missing: DOXYGEN_EXECUTABLE)
> -- Could NOT find SpeexDSP (missing: SPEEXDSP_LIBRARY SPEEXDSP_INCLUDE_DIR) 
> (found version "")
> Java HotSpot(TM) Client VM warning: TieredCompilation is disabled in this 
> release.
> -- C-Flags:  /MP /Zo /utf-8 /guard:cf /w34295 /w34100 /w34189 /wd4200 /DWIN32 
> /D_WINDOWS /W3 /MD /Zi /O2 /Ob1 /DNDEBUG
> -- CXX-Flags:  /MP /Zo /utf-8 /guard:cf /w34295 /w34100 /w34189 /wd4200 
> /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /Zi /O2 /Ob
> 1 /DNDEBUG
> -- Warnings as errors disabled
> -- The following OPTIONAL packages have been found:
> ...
>  
> I get the following errors when generating the build files:
>  
> ...
> -- Using VCINSTALLDIR: C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Community\VC
> -- Using C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Community\VC\Redist\MSVC\14.29.30133\vcredist_x64.exe for the 
> NSIS installer.
> -- Configuring done
> CMake Error in epan/CMakeLists.txt:
>   Target "epan" INTERFACE_INCLUDE_DIRECTORIES property contains path:
>  
>     
> "C:/ws348-64/wireshark-win64-libs-3.4/vcpkg-export-20190318-win64ws/installed/x64-windows/include"
>  
>   which is prefixed in the build directory.
>  
>
> CMake Error 

Re: [Wireshark-dev] ISO 7816 vs GSM SIM dissector

[Pascal Quantin]

Hi Stig,

Le mer. 18 août 2021 à 13:51, Stig Bjørlykke  a écrit :

> Hi,
>
> Does anyone know the difference between the ISO 7816 dissector and the GSM
> SIM dissector?
>
> For me it looks like they are handling the same PDUs, but both are
> incomplete in different ways.
>

You are correct. Both were done by different developers for different
purposes (Martin added the generic ISO 7816 dissector after Harald added
the GSM SIM one). SIM or USIM application is just one of the many
applications that can run on a smartcard. Note that the 3GPP specs override
the ISO specs, so the decoding of the elementary files could differ as far
as I can remember (it has been a few years since I last played with those
things).

Best regards,
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

Re: [Wireshark-dev] Unknown CMake command "check_function_exists".

[Pascal Quantin]

Hi Jorge,

Le mar. 10 août 2021 à 16:57, Mora, Jorge via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> Hello,
>
>
>
> I just got the latest tree but cmake fails:
>
>
>
> $ uname -a
>
> Linux netapp83.linux.fake 4.18.0-240.el8.x86_64 #1 SMP Wed Sep 23 05:13:10
> EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
>
>
>
> $ git log
>
> commit 3c5168c874c7a9cf60ae3eaa44fb982352f2628d (HEAD -> master,
> upstream/master, upstream/HEAD)
>
> Author: John Thacker 
>
> Date:   Mon Aug 9 20:30:02 2021 -0400
>
>
>
> editcap doc: Fix description of split output file names
>
>
>
> The editcap documentation still refers to the pre 1.2.1 behavior
>
> of determining output file names when splitting based on either
>
> packet counts or time intervals. (See commit a8eb860103) Update
>
> it to reflect the current behavior.
>
>
>
> $ cmake ../wireshark
>
> -- Generating build using CMake 3.11.4
>
> -- LTO/IPO is not enabled
>
> -- CMake build type: RelWithDebInfo
>
> -- V: 3.5.0, MaV: 3, MiV: 5, PL: 0, EV: .
>
> -- Linker flags:  -Wl,--as-needed
>
> -- Could NOT find LIBSSH (missing: LIBSSH_LIBRARIES LIBSSH_INCLUDE_DIRS
> LIBSSH_VERSION) (Required is at least version "0.6")
>
> -- Checking for one of the modules 'libpcap'
>
> -- Could NOT find PCAP (missing: PCAP_LIBRARY PCAP_INCLUDE_DIR)
>
> -- Could NOT find Systemd (missing: SYSTEMD_LIBRARY SYSTEMD_INCLUDE_DIR)
> (found version "")
>
> -- Could NOT find MaxMindDB (missing: MAXMINDDB_LIBRARY
> MAXMINDDB_INCLUDE_DIR)
>
> -- Could NOT find SMI (missing: SMI_LIBRARY SMI_INCLUDE_DIR)
>
> CMake Error at cmake/modules/FindKERBEROS.cmake:95 (check_function_exists):
>
>   Unknown CMake command "check_function_exists".
>
> Call Stack (most recent call first):
>
>   CMakeLists.txt:1096 (find_package)
>
>   CMakeLists.txt:1214 (ws_find_package)
>
>
>
>
>
> -- Configuring incomplete, errors occurred!
>
> See also "/home/mora/wireshark-build/CMakeFiles/CMakeOutput.log".
>
> See also "/home/mora/wireshark-build/CMakeFiles/CMakeError.log".
>

The following patch should probably solve your issue. I'm gonna push it
soon.

diff --git a/cmake/modules/FindKERBEROS.cmake
b/cmake/modules/FindKERBEROS.cmake
index 38cd55a3ab..8a3c2c7625 100644
--- a/cmake/modules/FindKERBEROS.cmake
+++ b/cmake/modules/FindKERBEROS.cmake
@@ -84,6 +84,7 @@ endif()
 # Try to detect the installed Kerberos vendor, assume MIT if it was not
Heimdal.
 if(KERBEROS_FOUND)
   include(CheckSymbolExists)
+  include(CheckFunctionExists)
   set(CMAKE_REQUIRED_INCLUDES ${KERBEROS_INCLUDE_DIRS})
   set(CMAKE_REQUIRED_LIBRARIES ${KERBEROS_LIBRARIES})
   #see also HAVE_HEIMDAL_KERBEROS in cmakeconfig.h.in

Best regards,
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

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

[Pascal Quantin]

Hi Moshe,

Le mer. 21 juil. 2021 à 17:56, Moshe Kaplan  a
écrit :

> Coverity is complaining that some of the allocations made with pinfo ->
> pool are leaking. Is it possible that the pinfo->pool based allocations are
> not always cleaned up?
>
> As an example, CoverityID 1487512 complains about packet-tcp.c's calls to
> port_with_resolution_to_str leaking:
> https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-tcp.c#L6500
> .
>

Most likely Coverity's analysis capabilities cannot properly handle a
custom memory allocator like the one we use, where the garbage collector is
performed out of scope of the current functions.
Looking at CID 1487512, this really seems to be the case: Coverity cannot
know that the dynamically allocated buffers that are not stored in any
local/global variable can be freed later on in epan_dissect_cleanup(). So
at first glance it seems like a false positive (like many other ones as far
as I know, maybe there is a way to provide directives to avoid those false
reports). The problem is that using a NULL scope will fallback to
g_malloc'ed memory that will leak, and this might be too subtle for a
simple directive.

Best regards,
Pascal.


> Moshe
>
>
>
> On Wed, Jul 21, 2021 at 11:31 AM Evan Huus  wrote:
>
>> FYI this migration has now begun. Going forward, please use pinfo->pool
>> instead of wmem_packet_scope() in new code when possible. And if anybody
>> has some time, there are lots of existing dissectors left to convert. I
>> expect most of them to be pretty straightforward, just adding pinfo to a
>> few more method signatures as needed.
>>
>> Thanks,
>> Evan
>>
>> On Mon, Jul 12, 2021 at 11:52 Evan Huus  wrote:
>>
>>> I've been thinking recently about starting the process of getting rid
>>> of the "global" wmem scope methods (wmem_packet_scope,
>>> wmem_file_scope, etc) in favour of passing them around in arguments
>>> (or in pinfo, or something). This would let us drop a bunch of
>>> in-scope/out-of-scope tracking and assertion, as well as make the code
>>> more amenable to future refactors like (potentially) concurrency.
>>>
>>> At a first glance, we already have pinfo->pool which maintains the
>>> lifetime of the packet_info object. As far as I can reason, this is
>>> almost/effectively the same as the existing wmem_packet_scope - it
>>> gets cleaned up later in the dissection flow, but there's still only
>>> ever one which gets reused for each packet.
>>>
>>> Is this correct? If so, does it make sense to start replacing
>>> `wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
>>> in scope?
>>>
>>> Thanks,
>>> Evan
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives: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] Can the legacy HAVE_LIBGCRYPT_AEAD check be removed?

[Pascal Quantin]

Hi Matthias,

Le lun. 12 juil. 2021 à 21:22, Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> a écrit :

> Hi all,
>
> in wsgcrypt.h the libgcrypt version is checked to ensure that it supports
> AEAD ciphers:
>
> #if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
> /* Whether to provide support for authentication in addition to
> decryption. */
> #define HAVE_LIBGCRYPT_AEAD
> #endif
>
> (see [1])
>
> Given the fact that libgcrypt 1.6.0 was released in 2013-12-16 (see [2]),
> I was wondering whether after such a long time it would be acceptable to
> simplify
> all the conditional code depending on HAVE_LIBGCRYPT_AEAD by making
> GCRYPT_VERSION_NUMBER >= 0x010600 a requirement and removing  the
> #else code parts.
>
> The reason why I am asking is because the packet-isakmp dissector has some
> conditional code to emulate AES-GCM using AES-CTR in the absence
> of HAVE_LIBGCRYPT_AEAD which I'd like to remove. I did some git history
> research and noticed that there were some recent commits in 2020 related
> to fixing compilation without HAVE_LIBGCRYPT_AEAD  (see [3]). However, I'm
> not sure whether this was done deliberately to support libgcrypt < 1.6.0
> or just out of habit because nobody considered the option of removing the
> legacy check.
>

If some changes were done to fix the compilation, it means that some people
still use a libgcrypt version older than 1.6.0. And as seen in our
CMakeLists.txt file,
the minimum version required for now is 1.5.0.

Best regards,
Pascal.


> Regards,
> Matthias
>
>
> [1]
> https://gitlab.com/wireshark/wireshark/-/blob/06ed6930dc602b5b3b1a79a176272c1846840f8f/wsutil/wsgcrypt.h#L32-35
> [2]
> https://github.com/gpg/libgcrypt/blob/ccfa9f2c1427b40483984198c3df41f8057f69f8/NEWS#L673
>
>
> [3] output of:
>
> for f in $(git grep -l HAVE_LIBGCRYPT_AEAD); do \
> git annotate $f | grep HAVE_LIBGCRYPT_AEAD; \
> done | awk '{print $1}' | sort | uniq | xargs git show --oneline
> --pretty=reference  --no-patch  | grep -w fix
>
> 03af5553eb (ssl-utils: fix compilation if not HAVE_LIBGCRYPT_AEAD.,
> 2018-03-15)
> 151ee60555 (http3: fix build without support for AEAD cipher suites.,
> 2020-08-10)
> 8c99f4de8d (QUIC: fix compilation without HAVE_LIBGCRYPT_AEAD, 2020-11-19)
> 90c3e7dead (QUIC: fix build error without LIBGCRYPT_AEAD, 2020-07-13)
> e7642e162f (TLS: fix build error without LIBGCRYPT_AEAD, 2020-07-13)
> e846d238d7 (QUIC: fix compile  without LIBGCRYPT_AEAD,
> 2020-08-10)___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Replacing wmem_packet_scope() with pinfo->pool?

[Pascal Quantin]

Hi Evan,

Le lun. 12 juil. 2021 à 17:52, Evan Huus  a écrit :

> I've been thinking recently about starting the process of getting rid
> of the "global" wmem scope methods (wmem_packet_scope,
> wmem_file_scope, etc) in favour of passing them around in arguments
> (or in pinfo, or something). This would let us drop a bunch of
> in-scope/out-of-scope tracking and assertion, as well as make the code
> more amenable to future refactors like (potentially) concurrency.
>
> At a first glance, we already have pinfo->pool which maintains the
> lifetime of the packet_info object. As far as I can reason, this is
> almost/effectively the same as the existing wmem_packet_scope - it
> gets cleaned up later in the dissection flow, but there's still only
> ever one which gets reused for each packet.
>

That's also my understanding.


>
> Is this correct? If so, does it make sense to start replacing
> `wmem_packet_scope()` calls with `pinfo->pool` when pinfo is already
> in scope?
>

I had the same idea in the past, mostly because of subtle bugs where
Wireshark was using already freed packet memory because of the difference
between packet and pool scopes (that is documented in README.wmem but still
error prone). Keeping only the later would definitely simplify things (at
the cost of another massive rename like what we did when moving from
ephemeral/seasonal memory to wmem scopes).

Best regards,
Pascal.

PS: nice seeing you active again
___
Sent via:Wireshark-dev mailing list 
Archives: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] Decoding error SS7 SMS-MO (ok) vs SMPP Deliver SM (malformed)

[Pascal Quantin]

Hi Andreas,

Le mer. 7 juil. 2021 à 16:20, Andreas Fink  a écrit :

> Hello,
>
> I run into a decoding error in SMPP
>
> I have a GSM SMS payload which comes in as SMS-MO into a SMSC.
>
> the GSM-SMS TPDU SMS-submit -> TP-UserData section contains the bytes:
> 0271141201897d3623d52eaea27bb6dad9e9c37cfa
>
> Wireshark decodes this correctly as having a UDH header of 0x71 which is a
> (U)SIM Tooling Security Header and some raw binary data.
>
>
>
> This same Payload is now packed by the SMSC into a SMPP Deliver SM.
> The bytes are exactly the same. but now Wireshark can't decode it anymore
>
>
>
> So I presume the SMPP branch doesn't know the same User Data Headers as
> the SS7 branch of Wireshark.
>

It's even worse: your first screenshot is decoded by the gsm_sms dissector
(that decodes a TPDU, including the TP-UD)), while the SMPP dissector is
calling another gsm_sms_ud dissector (taht decodes the TP-UD only).
It seems like the latter is not really maintained while the former is more
actively maintained and has better decoding capabilities.

Even worse, it does not skip over a unknown UDH header but assumes
> everything is wrong.
>

As said, it seems to be abandoned code so that's not surprising.


>
> I think this needs fixing.
> I can probably find it in the right spot in the source but I don't have a
> wireshark build environment set up as I used it mainly on a Mac (which has
> quite some complex dependencies). So if someone has an easy way to fix
> this, it would be greatly apprechiated.
>

I do not see an "easy fix" and no one will ever try to fix that with a
screenshot only. Better fill a bug on
https://gitlab.com/wireshark/wireshark/-/issues with a pcap attached.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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] warning LNK4291: module may contain '__except' but was not compiled with /guard:ehcont

[Pascal Quantin]

Hi Chris,

2 juil. 2021 17:36:21 Maynard, Christopher via Wireshark-dev 
:

> I’m not sure if these warnings have been seen by anyone yet, but I just 
> noticed them after updating sources today and compiling.
>  
> From: _https://gitlab.com/wireshark/wireshark/-/jobs/1395187730#L534_
> libmaxminddb.lib(maxminddb.c.obj) : warning LNK4291: module may contain 
> '__except' (Structured Exception Handling) but was not compiled with 
> /guard:ehcont; generating conservative metadata 
> [C:\builds\wireshark\wireshark\build\mmdbresolve.vcxproj]
> _535[https://gitlab.com/wireshark/wireshark/-/jobs/1395187730]_libmaxminddb.lib(data-pool.c.obj)
>  : warning LNK4291: module may contain '__except' (Structured Exception 
> Handling) but was not compiled with /guard:ehcont; generating conservative 
> metadata [C:\builds\wireshark\wireshark\build\mmdbresolve.vcxproj]
>  
> From: _https://gitlab.com/wireshark/wireshark/-/jobs/1395187730#L3000_
> minizip.lib(unzip.c.obj) : warning LNK4291: module may contain '__except' 
> (Structured Exception Handling) but was not compiled with /guard:ehcont; 
> generating conservative metadata 
> [C:\builds\wireshark\wireshark\build\wireshark.vcxproj]
> _3001[https://gitlab.com/wireshark/wireshark/-/jobs/1395187730]_minizip.lib(zip.c.obj)
>  : warning LNK4291: module may contain '__except' (Structured Exception 
> Handling) but was not compiled with /guard:ehcont; generating conservative 
> metadata [C:\builds\wireshark\wireshark\build\wireshark.vcxproj]
> _3002[https://gitlab.com/wireshark/wireshark/-/jobs/1395187730]_qtmain.lib(qtmain_win.obj)
>  : warning LNK4291: module may contain '__except' (Structured Exception 
> Handling) but was not compiled with /guard:ehcont; generating conservative 
> metadata [C:\builds\wireshark\wireshark\build\wireshark.vcxproj]

See https://gitlab.com/wireshark/wireshark/-/merge_requests/3329#note_616965519

Best regards,
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

Re: [Wireshark-dev] please close issue 12800

[Pascal Quantin]

Hi Eugene,

4 juin 2021 18:41:53 Eugène Adell :

> Hello,
>
> anyone with sufficient rights please close :
>
> https://gitlab.com/wireshark/wireshark/-/issues/12800

Done.

Best regards,
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

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

[Pascal Quantin]

Hi Antonello

Le jeu. 27 mai 2021 à 08:54, Antonello Tartamo 
a écrit :

> pt contains 16 bytes I have filled up.
> I'm telling proto_tree_add_item to read these bytes from offset 0 with
> length 16.
> The field is properly shown (correct bytes) in the Packet Details tree but
> when I select it in the Packet Bytes view the bytes selected are not the
> same shown in the Packet Details view.
>

I think the real thing to look at (and that you did not share) is the
lifetime of the pt buffer. Do you ensure that the memory pointed by this
address is still valid when Wireshark tries to display its content in the
packet bytes buffer? WIthout seeing this full code part we cannot really
help you, but you should ensure that pt is valid during the whole pinfo
structure lifetime (by allocating it in the pinfo->pool memory pool for
example, see doc/README.wmem file for more details).

Hope this helps,
Pascal.


>
> Il giorno mer 26 mag 2021 alle ore 15:24 Roland Knall 
> ha scritto:
>
>> You misunderstood. pt must contain the bytes you want to be inside the
>> subset. It seems, that you collect different bytes for this array as you
>> select for your hf_item selection which is then highlighted in the
>> packet-view
>>
>> kind regard
>> Roland
>>
>> Am Mi., 26. Mai 2021 um 14:39 Uhr schrieb Antonello Tartamo <
>> antonellotart...@gmail.com>:
>>
>>> Hello pt is an array (uint8_t pt[16];).
>>> pt is an array generated after processing a part of the packet.
>>> As I've created a new tvb the offset is 0 and the length is 16.
>>>
>>> Hope I've answered your questions.
>>>
>>>
>>>
>>> Il giorno mer 26 mag 2021 alle ore 14:32 Roland Knall 
>>> ha scritto:
>>>
 The data displayed in the subitem is the one from pt, your data
 variable which you used to create the new tvb. The hf_item seems to point
 to a different data structure. How is pt being generated? Are you using the
 same length and start offset as for the hf item?

 regards
 Roland

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

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

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

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

Re: [Wireshark-dev] Close bugs

[Pascal Quantin]

Hi _John,_

26 mai 2021 06:58:14 John Thacker :

> Can someone with the proper permission please close #13238 
> (https://gitlab.com/wireshark/wireshark/-/issues/13238)?
> It was fixed by commit 81f184bc00b938807cfdee72dc6f8d49412e26c6 three years 
> ago, but didn't get closed (and no one really owns it after the Bugzilla 
> migration.)
>
> Also please close #6365 
> (https://gitlab.com/wireshark/wireshark/-/issues/6365), which was addressed 
> with the "Export PDUs to File" functionality and API.

Done.

Best regards,
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

Re: [Wireshark-dev] Status label for issues

[Pascal Quantin]

Hi Graham,

23 avr. 2021 16:39:16 Graham Bloice :

> How will issues that aren't bugs be handled, e.g. enhancement requests?

We already have an enhancement label.

@Uli, LGTM.

Cheers,
Pascal.

>
> On Fri, 23 Apr 2021 at 13:30, Uli Heilmeier  wrote:
>> Hi everyone,
>>
>> For issues (especially bugs) I really miss the status field which was 
>> available with Bugzilla.
>>
>> Therefore I would like to create these scoped labels [1]:
>>
>> ws-status::unconfirmed => This bug has recently been added to the issue 
>> tracker. Nobody has confirmed that this bug is
>> valid.
>> ws-status::confirmed => This bug is valid.
>> ws-status::in-progress => This bug is not yet resolved, but is assigned to 
>> the proper person who is working on the bug.
>> ws-status::invalid => The problem described is not a bug or not our bug.
>> ws-status::wontfix => The problem described is a bug which will never be 
>> fixed.
>> ws-status::fixed => A fix for this bug is checked into master branch.
>> ws-status::duplicate => The problem is a duplicate of an existing issue.
>>
>> Scoped labels are mutually exclusive.
>>
>> Setting the label requires manual interaction. So yes, this label won't 
>> reflect the real state when the issue is closed
>> automatically (for example when a MR referencing this issue is merged or 
>> when the issue is marked as an duplicate).
>>
>> Furthermore a normal user is not allowed to set labels at the moment. Having 
>> the label in the issue template won't add
>> the label when opening an issue.
>>
>> Maybe we need another bot (like triage-ops [2]) to set labels automatically.
>> Does anyone have experience with triage-ops bot (or any other bot managing 
>> issues) and Gitlab and can share some insides?
>>
>> Any objections? Comments are very welcome.
>>
>> Cheers
>> Uli
>>
>> [1]: 
>> https://docs.gitlab.com/ee/user/project/labels.html#workflows-with-scoped-labels
>> [2]: https://gitlab.com/gitlab-org/quality/triage-ops
>> ___
>> Sent via:    Wireshark-dev mailing list 
>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>              mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
> --
> Graham Bloice
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives: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] MR that commes up as "OK to Merge" fails pipline

[Pascal Quantin]

Le mer. 21 avr. 2021 à 20:12, Gerald Combs  a écrit :

> On 4/21/21 6:38 AM, Pascal Quantin wrote:
> > Hi Anders,
> >
> > Le mer. 21 avr. 2021 à 15:34, Anders Broman via Wireshark-dev <
> wireshark-dev@wireshark.org <mailto:wireshark-dev@wireshark.org>> a
> écrit :
> >
> > Hi,
> >
> > This MR https://gitlab.com/wireshark/wireshark/-/merge_requests/2178
> <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?
> >
> >
> > For some reason the MRs do not seem to run the Windows builder, unless
> Wireshark  Gitlab Utility rebases the change. This is not the first time I
> see this.
> > Gerald, is this some configuration setting that needs to be changed? Or
> only the Wireshark group can run the Windows builder?
>
> GitLab's shared Windows runners don't let you specify a custom Docker
> image[1], and the image that they supply[2] is missing many of our
> prerequsities[3]. As a result I set up a "specific"[4] Windows runner for
> wireshark/wireshark, but as you point out this doesn't run for many of our
> detached merge requests. I haven't found anything definitive in GitLab's
> docs, but it looks like specific runners don't run detached merge requests
> unless it's initiated by a user with sufficient permissions.
>
> We might be able to work around this by finding a way to quickly install
> our prerequisites on GitLab's standard image. IIRC the slowest ones are Qt,
> Strawberry Perl, and Python.
>

Alternatively, would we have a way to ensure that Wireshark Gitlab Utility
always run one CI job before allowing the merge?


> [1]
> https://docs.gitlab.com/ee/user/gitlab_com/index.html#limitations-and-known-issues
> [2]
> https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md
> [3]
> https://gitlab.com/wireshark/wireshark-containers/-/blob/master/dev/windows/Dockerfile
> [4]https://docs.gitlab.com/ee/ci/runners/#specific-runners
>
___
Sent via:Wireshark-dev mailing list 
Archives: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] Who introduced these failures?

[Pascal Quantin]

Hi Richard,

Le mer. 21 avr. 2021 à 19:43, Richard Sharpe 
a écrit :

> My latest MR failed with these errors:
>
> -
>
> C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71):
> error C2220: workload = 100.0 *
> CSR_GET_WORKLOAD(tvb_get_ntohs(message_tvb, 284));
> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj]
>
> 857C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71):
> error C2220: ^
> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj]
> 858 packet-cp2179.c
>
> 859C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71):
> warning C4244: '=': conversion from 'double' to 'float', possible loss
> of data
> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj]
> ---
>
> They are not in packet-ieee80211.c where my changes were.
>

This seems related to
https://gitlab.com/wireshark/wireshark/-/merge_requests/2178 where no
Windows build was run by the CI, and thus the error was left unnoticed
prior to the merge. See the thread initiated by Anders earlier today.

Best regards,
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

Re: [Wireshark-dev] MR that commes up as "OK to Merge" fails pipline

[Pascal Quantin]

Hi Anders,

Le mer. 21 avr. 2021 à 15:34, Anders Broman via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

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

For some reason the MRs do not seem to run the Windows builder, unless
Wireshark  Gitlab Utility rebases the change. This is not the first time I
see this.
Gerald, is this some configuration setting that needs to be changed? Or
only the Wireshark group can run the Windows builder?

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

Re: [Wireshark-dev] ASN.1-based dissector development for Wireshark

[Pascal Quantin]

Hi Vincent,

the truncated ASCII bytes pane seems like a Qt UI bug not related to the
dissector code itself. It seems like you are suffering from
https://gitlab.com/wireshark/wireshark/-/issues/17087 that got fixed in
https://gitlab.com/wireshark/wireshark/-/merge_requests/1902 but not
backported in release-3.4 branch (which is probably a mistake). Could you
apply it locally and confirm it fixes the issue for you?

Indeed the simple ASN.1 based dissector code sample is outdated. Could you
should replace:

static void
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
proto_item  *foo_item = NULL;
proto_tree  *foo_tree = NULL;
int offset = 0;

/* make entry in the Protocol column on summary display */
if (check_col(pinfo->cinfo, COL_PROTOCOL))
col_set_str(pinfo->cinfo, COL_PROTOCOL, PNAME);

/* create the foo protocol tree */
if (tree) {
foo_item = proto_tree_add_item(tree, proto_foo, tvb, 0, -1, FALSE);
foo_tree = proto_item_add_subtree(foo_item, ett_foo);

dissect_FOO_MESSAGE_PDU(tvb, pinfo, foo_tree);
}
}

by

static int
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
{
proto_item  *foo_item;
proto_tree  *foo_tree;

/* make entry in the Protocol column on summary display */
col_set_str(pinfo->cinfo, COL_PROTOCOL, PNAME);

/* create the foo protocol tree */
foo_item = proto_tree_add_item(tree, proto_foo, tvb, 0, -1, FALSE);
foo_tree = proto_item_add_subtree(foo_item, ett_foo);

return dissect_FOO_MESSAGE_PDU(tvb, pinfo, foo_tree);
}
It should remove the call to the data dissector after the ASN.1 PDU
dissection (that happens because the FOO dissector does not indicate
to have consumed

Best regards,
Pascal.


Le jeu. 15 avr. 2021 à 23:59, Vincent Randal  a écrit :

> Hi Anders (and interested persons). Good idea. Thank you. I expanded
> Wireshark to fullscreen. And I've made two new screenshots to compare
> behavior of myfoo dissector with the icmp dissector. I realize now I might
> be comparing apples with oranges insofar as myfoo is UDP-based while icmp
> is TCP-based. Here goes.
>
> Screenshots relevant to this email are in myfoo.bug.tgz (attached)
> (myfoo.png) Screenshot for myfoo dissector. This dissector is essentially
> the simple ASN.1-based dissector example (foo) from the Wireshark
> documentation.
> (icmp.png) Screenshot for imcp dissector which I believe to be TCP-based
> and is one of many many dissectors that come with Wireshark.
>
> The two screenshots show only the left half of the fullscreen Wireshark UI
> window (the omitted right halves are blank). My focus is on how
> highlighting in the bottom window (raw data) responds to highlighting MYFOO
> Protocol [Internet Control Message Protocol (for icmp)] in the middle
> window (expanded tree). There's at least two things to notice: (1) For
> myfoo the 24 byte UDP-payload comprises the entire message; the messageId
> and flowId are incorrectly highlighted along with the two 10 octet strings
> that follow (in the messageData). Whereas for icmp the 48 data bytes are
> correctly preceded by 16 bytes of information (type, code, checksum, etc).
> (2) Both myfoo and icmp have a problem with the ASCII area to the right of
> the raw data in the bottom window. For myfoo the problem is more severe
> insofar as the ASCII area is only 8 characters wide. For icmp the ASCII
> area is a full 16 characters wide for part of the raw data.
>
> My conclusions regarding the above observations:
> (1) I've introduced a bug in the myfoo dissector when I made changes to
> packet-myfoo-template.c and packet-myfoo-template.h in an attempt to get
> them build. I can review those changes by diffing myfoo with foo from the
> simple ASN.1-based dissector example online. Specifically, the bug in myfoo
> is causing the messageId and flowId to be included in (highlighted along
> with) the two 10 octet strings that follow them. See the attached myfoo.asn
> file for details or refer to foo.asn from the example here:
> https://www.wireshark.org/docs/wsdg_html_chunked/SimpleASN1BasedDissector.html
> (2) It could be that as Wireshark loads my dissector the "ASCII area" in
> the bottom window is adversely affected for all dissectors as indicated in
> the screenshot for icmp. Maybe that's not possible. Otherwise, there's a
> problem with the width of the ASCII area not being a full 16 characters
> wide to correspond to the raw data on the left.
>
> I'm confident this write up is a review for many of you that work on
> dissectors in which case I'm hoping someone can comment on my conclusions
> and speculations. I would be pleasantly surprised if fixing myfoo bug also
> fixes the width of the ASCII area for icmp. I can actually test that theory
> by downloading and installing wireshark-3.4.4 from wireshark.org website.
>
> It's been 14 years since I looked at dissector code and 

Re: [Wireshark-dev] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet

[Pascal Quantin]

Hi Vincent,

Le jeu. 15 avr. 2021 à 10:52, Vincent Randal  a écrit :

> (1) There is no error message other than it fails immediately when
> beginning building "qtui" (at about 70% of the way into make for
> wireshark-3.4.4)
>

You should have an error message, please check above in the build log.
I just built Wireshark 3.4.4 (taken from the git tag, not the source
tarball in case it matters) without any issue with an out of tree build
(folder named build.wireshark) both with make and ninja, using CMake
3.16.3, Qt 5.12.8 and gcc/g++ 9.3.0 on Ubuntu 20.04.2.

(2) Good point. Wireshark uses dissectors to provide details of packets, as
> you point out. So then the dissector source code provides the details of
> the dissector.
>
> On Thu, Apr 15, 2021 at 2:26 AM Guy Harris  wrote:
>
>> On Apr 15, 2021, at 12:55 AM, Vincent Randal  wrote:
>>
>> > (1)  building Wireshark in build.wireshark fails
>> > The solution here is to use "build" as the name of the build directory
>> and then make succeeds. Otherwise, if the build directory has some other
>> name like build.wireshark then make fails at about 70% when building qtui.
>>
>> What's the error that it reports?  I can't reproduce that on my Mac with
>> the current tip of the main branch.
>>
>> > (2) how to get dissector details without packet
>> > I see there is "Decode as ..." in the Analzye menu of Wireshark. That
>> looks very useful. I think I can use that to get Wireshark to ... uh well
>> ... decode an already decoded packet as something else.
>> >
>> > But what about something that shows me what Wireshark thinks about a
>> dissector even without a packet? Is that possible? Can Wireshark show me
>> the details of a dissector without a packet to dissect?
>>
>> That depends on what you mean by "the details of the dissector".
>> Normally, what Wireshark shows is the details of a *packet*, which,
>> obviously, requires a packet; what would the details of a *dissector* be?
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives: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] Closing issue 15128

[Pascal Quantin]

Hi Uli,

14 avr. 2021 16:22:14 Uli Heilmeier :

> Hi List,
>
> Would someone who has the necessary rights please be so kind and close issue 
> 15128 [1]?
> I am missing the necessary permission.

Done

Best regards,
Pascal.

>
> Cheers
> Uli
>
>
> [1] https://gitlab.com/wireshark/wireshark/-/issues/15128
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    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] Hitting a weird error in a MR pipeline

[Pascal Quantin]

Le mar. 13 avr. 2021 à 18:49, Pascal Quantin  a
écrit :

> This is because of
> https://gitlab.com/wireshark/wireshark/-/merge_requests/2689
> that was merged despite a Windows failure. need to fix it.
>

Fix attempt here, to be reviewed by Jirka:
https://gitlab.com/wireshark/wireshark/-/merge_requests/2691


> Pascal.
>
> 13 avr. 2021 18:42:29 Richard Sharpe :
>
> > Hi folks,
> >
> > In my latest MR pipeline:
> > https://gitlab.com/wireshark/wireshark/-/pipelines/285790755
> >
> > I see these errors in the Windows build portion:
> > ---
> > C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22):
> > error C2220: the following warning is treated as an error
> > [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj]
> > 2718 packet-rtse.c
> > 2719C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22):
> > warning C4101: 'error': unreferenced local variable
> > [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj]
> > ---
> >
> > However, my change did not touch those files ... what is going on?
> >
> > --
> > Regards,
> > Richard Sharpe
> > (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives: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] Hitting a weird error in a MR pipeline

[Pascal Quantin]

This is because of https://gitlab.com/wireshark/wireshark/-/merge_requests/2689
that was merged despite a Windows failure. need to fix it.

Pascal.

13 avr. 2021 18:42:29 Richard Sharpe :

> Hi folks,
> 
> In my latest MR pipeline:
> https://gitlab.com/wireshark/wireshark/-/pipelines/285790755
> 
> I see these errors in the Windows build portion:
> ---
> C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22):
> error C2220: the following warning is treated as an error
> [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj]
> 2718 packet-rtse.c
> 2719C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22):
> warning C4101: 'error': unreferenced local variable
> [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj]
> ---
> 
> However, my change did not touch those files ... what is going on?
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector example (foo)

[Pascal Quantin]

13 avr. 2021 17:36:20 John Thacker :

> Depending on your build system, the other ASN.1 dissectors can be regenerated 
> with either
>
> ninja asn1
>   Or
> make asn1
>
> without starting the full build process.

Those commands will regenerate all the ASN.1 dissectors. The command I gave 
allows to regenerate a single dissector (which is much faster), something I do 
each time I update the 3GPP dissectors I maintain (using Linux and not Windows).

>
> I do it all the time, last did it a week ago when developing on Linux and 
> just did it two minutes ago before writing this email to check the command. 
> That is for the built in ones not a new custom one, but I have added a custom 
> dissector before and it works perfectly fine on Linux.
>
>
> On Tue, Apr 13, 2021, 11:23 AM Vincent Randal  wrote:
>> Before or After running cmake (in Linux) there are no files containing 
>> "generate_dissector" in the filename in asn1/foo. And they do not exist 
>> anywhere in the source tree.
>>
>> How did the other asn1 dissectors get generated in Linux? When was the last 
>> time anyone generated or updated a dissector in epan/dissectors/asn1 using 
>> Linux? Maybe this step has been broken for a while in Linux (assuming it 
>> works in Windows).
>>
>> On Tue, Apr 13, 2021 at 9:03 AM Pascal Quantin  wrote:
>>> Hi Vicent,
>>>
>>> Le mar. 13 avr. 2021 à 16:53, Vincent Randal  a écrit :
>>>> I should give that a try. What version of Windows and tools are you using? 
>>>> I’m beat. I need to do something that works soon.
>>>
>>> No need to install Windows; it works the same way on Linux. Go to your 
>>> build folder and run:
>>> ninja epan/dissectors/asn1/foo/generate_dissector-foo
>>> Assuming you are using ninja, otherwise replace it by make.
>>> The target should have been created iby running CMake after the addition of 
>>> the CMakeListsCustom.txt file.
>>>
>>> Best regards.
>>>
>>>>
>>>> On Tue, Apr 13, 2021 at 8:47 AM Anders Broman via Wireshark-dev 
>>>>  wrote:
>>>>>
>>>>> 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 
>>>>>  wrote:
>>>>>
>>>>>> …
>>>>> ___
>>>>> Sent via:    Wireshark-dev mailing list 
>>>>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>>>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>>>              
>>>>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>> ___
>>>> Sent via:    Wireshark-dev mailing list 
>>>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>>              mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>> _

Re: [Wireshark-dev] How to build the simple ASN.1 UDP-based dissector example (foo)

[Pascal Quantin]

Hi Vicent,

Le mar. 13 avr. 2021 à 16:53, Vincent Randal  a écrit :

> I should give that a try. What version of Windows and tools are you using?
> I’m beat. I need to do something that works soon.
>

No need to install Windows; it works the same way on Linux. Go to your
build folder and run:
ninja epan/dissectors/asn1/foo/generate_dissector-foo
Assuming you are using ninja, otherwise replace it by make.
The target should have been created iby running CMake after the addition of
the CMakeListsCustom.txt file.

Best regards.


> On Tue, Apr 13, 2021 at 8:47 AM Anders Broman via Wireshark-dev <
> wireshark-dev@wireshark.org> wrote:
>
>> 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 <
>> 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  *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 
>> wrote:
>>
>> On Tue, Apr 13, 2021, 8:32 AM Vincent Randal  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 
>> Archives: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
>>  

Re: [Wireshark-dev] Dissector lifecycle and per-file data

[Pascal Quantin]

Hi Vincent,

Le lun. 29 mars 2021 à 18:24, Vincent Mallet  a écrit :

> I am hoping this is the right place to ask this question but if not please
> redirect me.
>

That's the right place :)


> I am working on a custom C dissector and need to keep some data around for
> the lifetime of the current file. At the moment I allocate my structures
> using various wmem_ functions with a wmem_file_scope() scope and keep them
> in conversations with conversation_get_proto_data() and
> conversation_add_proto_data(). It works great for conversation-related data
> but is not ideal for file-related data.
>

The wmem file scope is definitely the right memory pool.


> Is there a way for a dissector to know a new file is being worked on and
> it’s time to reinitialize data structures? Or is there an equivalent to
> conversation_get_proto_data() but for a file?
>

Did you look at the register_cleanup_routine() found in epan/packet.h? It
seems to be what you are looking for. To quote the comments:
/**
 * Allows protocols to register "cleanup" routines which are called
 * after closing a capture file (or when preferences are changed, in
 * that case these routines are called before the init routines are
 * executed). It can be used to release resources that are allocated in
 * register_init_routine.
 */
You can find multiple dissectors using it in our code base that should give
you plenty of examples.

Best regards,
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

Re: [Wireshark-dev] Improvments for NVMeOF dissector

[Pascal Quantin]

Hi Constantine,

Le lun. 29 mars 2021 à 17:36, Constantine Gavrilov  a
écrit :

> I have waited for another week and nothing happens.


Unfortunately those kinds of things happen sometimes. As said previously we
are all doing this in our spare time, and maybe the previous exchanges did
not motivate other people (just speculating here, at least this is how I
could have reacted, sorry to say that).


>
> This merge request (!2405) was created more than two weeks ago, and the
> people who have looked into it either lost interest or do not have time.


So I took the time to look at it and provided some comments in the merge
request. Once those small nits are clarified I guess we can merge the MR.


>
> I appreciate that everyone is so busy, but the same claim goes for
> contributors as well as developers.


No one said the opposite.


>
> I am more busy than most people, and I have found time to contribute. I
> equally expect that someone finds time to look into this work. This is a
> reasonable expectation as long as the projects states that contributions
> are welcome. If every developer is so busy and there is no formal process
> to assign the contribution for review, or a measure of how many
> contributions were evaluated by people holding core developer status, while
> there is also a taste of coldness in communication -- "do not bother us, we
> are busy and  owe you  nothing", why shall I bother?
>

I wonder how you can assume that you are busier than us without having any
clue on our own tasks, and being aggressive rarely helps (again this is my
personal point of view, not any project statement).


> I feel I have wasted my time. I have already explained that I have nothing
>  to gain from this. It was an act of gratitude to the project. But I do not
> want to feel that I have to push it down the project throat. As I have said
> there are many changes to improve NVMEoF dissector, and if there is no
> interest nor cooperation, I can easily continue in my local tree and it
> will serve my work just fine. This also means that these changes will never
> see public access.


No one said that and I'm sorry if you feel this way.


>
> The same goes for MR 2522 and 2324. Regarding the last one, I simply fail
> to grasp what is the problem there. Typically, build problems are solved
> within minutes (like a recent problem building on MAC). Since the change is
> so trivial, and beta builds of Fedora with gcc-11 are out, while the
> release is imminent, I do not understand why it has not been merged.
> Perhaps the problem is that I have provided the patch and should have just
> opened the bug report like people did reporting the MAC build issue?
>
So, I want to know what to do. Shall I close the merge requests and leave
> busy people alone with their busy affairs or perhaps we can work in the
> spirit of cooperation?
>

It's a shame if you close the MR, but we cannot prevent you from doing it.
I guess the first positive step would  be to sound less aggressive (maybe
that's not the intent, but this is how I read your messages, so maybe
others do also).

Hope we can move smoothly in the future and that you can accept that things
can take time sometimes.

Best regards,
Pascal.


> Until this point, I have contributed above 3k lines of code, where 800
> lines are in the tree, and 2.2K lines are stuck in the review.  If this is
> not a significant contribution, I do not know what is. I understand
> responsibility and would not whine about lack of time (despite being very
> busy) if I had core developer access. Your call, core developers. Can we
> collaborate, or you are so busy that collaboration is not possible?
>
>
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> 
>
>
>
> From:Constantine Gavrilov/Israel/IBM
> To:Developer support list for Wireshark <
> wireshark-dev@wireshark.org>
> Date:03/21/2021 05:37 PM
> Subject:Re: [EXTERNAL] Re: [Wireshark-dev] Improvments for NVMeOF
> dissector
> --
>
>
> Pascal, thank you.
>
> > You should accommodate the project, and not the other way around.
>
> I have never assumed otherwise, just tried to reach out...
>
> I will wait until the end of the week and see what happens...
>
>
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> 
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> 

Re: [Wireshark-dev] Improvments for NVMeOF dissector

[Pascal Quantin]

21 mars 2021 14:25:53 Constantine Gavrilov :

> Pascal, thank you again.
>
> Two days is not the end of the world. Initial review has taken one week, and 
> that was a bit long for me, but it is not the end of the world either. Anders 
> comment was a good answer, because he said that he could not do it, and he 
> did exactly what I asked -- he has let me know.
>
> It is more a problem of setting the expectations. Perhaps, I do not 
> understand how the process works. But after investing many hours and before 
> continuing to do so, I need to know one thing -- that my work is  getting 
> noticed and will be eventually considered. It is even OK that it is 
> eventually rejected.
>
> As I have said, there is no assignment process, not for the contributor. Even 
> if someone comments on the MR, it is not changing status, and I cannot expect 
> the same person to continue the review. I simply do not know what to expect.
>
> Is opening a merge request sufficient guarantee that someone will look into 
> this? Shall I request on the list? Perhaps there are certain core developers 
> who are more invested in RDMA/NVMEoF whom I shall ask?

Yes that's how it works, and how it has been for all the merge requests you 
have opened so far. This is not because this one takes a bit longer to be 
reviewed than the previous ones that it means it is being ignored or rejected.

>
> The uniqueness of the situation here is that I would like to make  
> significant contributions, and I can move fast. I am not saying people shall 
> accommodate me, I am just saying that I want and I need to move fast.  Having 
> a private tree that is far "ahead" of development tree is a burden for me 
> because of changes and review fixes. So, I would like to ask again "How can 
> make it better, if I have a lot of code to contribute in a particular area -- 
> NVMEoF?". Is core developer access out of the question?

You should accommodate the project, and not the other way around. Do not get me 
wrong: this is not a question of the quality of your contributions, but simply 
the way it works.
You can eventually be granted a core developer access when other core developer 
consider that you have provided enough quality patches and have proven to be 
involved long enough in the project to do not disappear immediately.

Best regards.

>
>
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> Phone: +972-3-6897318
> Fax:      +972-3-6897230
> 
>
>
>
> From:        Pascal Quantin 
> To:        Developer support list for Wireshark 
> Date:        03/21/2021 02:55 PM
> Subject:        [EXTERNAL] Re: [Wireshark-dev] Improvments for NVMeOF 
> dissector
> Sent by:        "Wireshark-dev" 
> 
>
>
>
> Hi Constantine, 21 mars 2021 13:40:22 Constantine Gavrilov 
> : > Pascal, thank you for your answer. > > What would be a 
> reasonable time to wait? A week, two weeks, a month? Long review times a 
> problem by themselves,
> Hi Constantine,
>
> 21 mars 2021 13:40:22 Constantine Gavrilov :
>
>> Pascal, thank you for your answer.
>>
>> What would be a reasonable time to wait? A week, two weeks, a month? Long 
>> review times a problem by themselves, since I cannot move ahead. But it is 
>> not even a problem of waiting as much, as it is a problem of communication 
>> loss. Dropping a line " will review it within 3 weeks" or "cannot handle it, 
>> too busy" "or will review later" is far less problematic then ignoring the 
>> question "can you review it, please?"
>
> Come on, it has been two days, including the weekend. I hardly see where 
> there is a communication issue here, simply people that do not spend all 
> their time behind their computer screen. To be honest I would have better 
> understood your push if it had been a full week without any feedback, but not 
> after one day (long review time? That's really what you are thinking?).  I 
> see some other open source projects where the submitted patches do not get 
> any attention during weeks. We could definitely do better, but I do not think 
> we are the worst.
>
>>
>>
>> I have nothing personal to gain from this. It is true that I am using 
>> wireshark for my work on NVMEoF, but if I cannot interest the community with 
>> this work, I can fork the tree locally and continue without submitting the 
>> changes. Doing this for community was an act of contibution and a hard work, 
>> but I will not impose if

Re: [Wireshark-dev] Improvments for NVMeOF dissector

[Pascal Quantin]

Hi Constantine,

21 mars 2021 13:40:22 Constantine Gavrilov :

> Pascal, thank you for your answer.
>
> What would be a reasonable time to wait? A week, two weeks, a month? Long 
> review times a problem by themselves, since I cannot move ahead. But it is 
> not even a problem of waiting as much, as it is a problem of communication 
> loss. Dropping a line " will review it within 3 weeks" or "cannot handle it, 
> too busy" "or will review later" is far less problematic then ignoring the 
> question "can you review it, please?"

Come on, it has been two days, including the weekend. I hardly see where there 
is a communication issue here, simply people that do not spend all their time 
behind their computer screen. To be honest I would have better understood your 
push if it had been a full week without any feedback, but not after one day 
(long review time? That's really what you are thinking?).  I see some other 
open source projects where the submitted patches do not get any attention 
during weeks. We could definitely do better, but I do not think we are the 
worst.

>
>
> I have nothing personal to gain from this. It is true that I am using 
> wireshark for my work on NVMEoF, but if I cannot interest the community with 
> this work, I can fork the tree locally and continue without submitting the 
> changes. Doing this for community was an act of contibution and a hard work, 
> but I will not impose if there is no cooperation. As I have said, I do not 
> think recognition. If there is an interest and someone will come up to 
> reveiew the changes, than I continue to contibute. If the attitude is "do not 
> bother us", why should I care?

We appreciate your contribution, and if you think this is not the case please 
give some examples. I'm just reminding you (as Anders did already) that we are 
volonteersand not paid for the time we spend on the project, and that we also 
have a professional and personal life that have their own constraints, and 
priority over the Wireshark project. Having a few days delay is not the end of 
the world, fortunately.

Best regards,
Pascal.

>
>
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> Phone: +972-3-6897318
> Fax:      +972-3-6897230
> 
>
>
>
> From:        Pascal Quantin 
> To:        Developer support list for Wireshark 
> Date:        03/21/2021 12:02 PM
> Subject:        [EXTERNAL] Re: [Wireshark-dev] Improvments for NVMeOF 
> dissector
> Sent by:        "Wireshark-dev" 
> 
>
>
>
> Hi Constantine, If I read the review history correctly, you were asked to 
> perform some changes that you did 2 days ago. This is not abnormal not to get 
> any feedback in such a short period, and that does not mean the receiver lost 
> interest but
> Hi Constantine,
>
> If I read the review history correctly, you were asked to perform some 
> changes that you did 2 days ago. This is not abnormal not to get any feedback 
> in such a short period, and that does not mean the receiver lost interest but 
> simply that he is busy.
> So my suggestion is to be a bit more patient as reviewers usually do their 
> best according to the time they can give to the project. Being too pushy can 
> give the exact opposite of what you would like. Just my two cents.
>
> Best regards,
> Pascal.
>
> 21 mars 2021 10:47:02 Constantine Gavrilov :
>
> Sometime ago, I started to work on NVMEoF dissector. I have already 
> contributed the number of fixes and improvements and they have already been 
> merged.
>
> My goal is to have a full dissection for connection establishment, management 
> and IO flow, and I would like to move on quickly.
>
> The goal is to contribute back to the community. I am not seeking recognition 
> -- I have plenty of that in my place of work. The goal is to help and express 
> my gratitude to the project.
>
> After initial changes merged, I am stuck at getting my current merge request 
> (_#17282[/wireshark/wireshark/-/issues/17282]_)reviewed. I understand that 
> this is a volunteer project and all people are busy. But I do have a problem 
> with broken line of communication. My personal opinion is that if a core 
> developer "picks up" the merge request and has review comments, they shall 
> follow up on the requested changes that a contributor has provided. If they 
> loose focus or interest, they shall inform the contributor, instead of just 
> "disappearing".  As a contributor,  I can control any form of merge request 
> as

Re: [Wireshark-dev] Improvments for NVMeOF dissector

[Pascal Quantin]

Hi Constantine,

If I read the review history correctly, you were asked to perform some changes 
that you did 2 days ago. This is not abnormal not to get any feedback in such a 
short period, and that does not mean the receiver lost interest but simply that 
he is busy.
So my suggestion is to be a bit more patient as reviewers usually do their best 
according to the time they can give to the project. Being too pushy can give 
the exact opposite of what you would like. Just my two cents.

Best regards,
Pascal.

21 mars 2021 10:47:02 Constantine Gavrilov :

> Sometime ago, I started to work on NVMEoF dissector. I have already 
> contributed the number of fixes and improvements and they have already been 
> merged.
> 
> My goal is to have a full dissection for connection establishment, management 
> and IO flow, and I would like to move on quickly.
> 
> The goal is to contribute back to the community. I am not seeking recognition 
> -- I have plenty of that in my place of work. The goal is to help and express 
> my gratitude to the project.
> 
> After initial changes merged, I am stuck at getting my current merge request 
> (_#17282[/wireshark/wireshark/-/issues/17282]_)reviewed. I understand that 
> this is a volunteer project and all people are busy. But I do have a problem 
> with broken line of communication. My personal opinion is that if a core 
> developer "picks up" the merge request and has review comments, they shall 
> follow up on the requested changes that a contributor has provided. If they 
> loose focus or interest, they shall inform the contributor, instead of just 
> "disappearing".  As a contributor,  I can control any form of merge request 
> assignment or have control over who will look at the merge request.
> 
> The fact that people are busy goes both ways -- for contributors as well as 
> core developers. I am looking into improving my contribution experience for 
> NVMEoF. Perhaps there is a core developer who is willing to look at the 
> changes and has sufficient interest and available time to work with me on 
> reviewing NVMEoF dissector changes? As it stands now, I feel blocked from 
> contributing (just because the speed of the review and people dropping off). 
> I am busy and will eventually have hard choices to make...
> 
> Perhaps I can get approval to join core developers?
> 
> 
> --
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> 
> ___
> Sent via:    Wireshark-dev mailing list 
> Archives:    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] Issue cleanup (admin privs needed)

[Pascal Quantin]

Hi Chuck,

Le ven. 12 mars 2021 à 19:07, chuck c  a écrit :

> https://gitlab.com/wireshark/wireshark/-/issues/16587
> Typing after Display Filter Macro crashes gui
>
> https://gitlab.com/wireshark/wireshark/-/issues/16778
> Display Filter Macros Crash Wireshark
>

Done.

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

Re: [Wireshark-dev] Submitting Replacement Code

[Pascal Quantin]

Hi Paul,

Le mer. 10 févr. 2021 à 18:37, Paul Offord  a
écrit :

> Hi,
>
> I need some GitLab guidance.  The procedure for submitting code is:
>
>- Commit code changes to the local copy of my personal Wireshark repo
>- Push the changes to my upstream personal repo
>- Press the "Create merge request" button
>
> Let's imagine that my code fails in the pipeline tests (mine often does
> :-( ).  Should I close the original merge request or does my later push of
> revised code simply reactivate the original Merge request?
>

As explained in
https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches,
you can amend your change and do a 'git push downstream +HEAD' to force an
update of your branch. This will automatically update the associated MR.

Best regards,
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

Re: [Wireshark-dev] Procedure to solve/close issues in Gitlab

[Pascal Quantin]

Hi Jirka,

Le mar. 9 févr. 2021 à 12:51, Jirka Novak  a écrit :

> Hi,
>
>   what is proposed procedure to solve and close issues in Gitlab?
>
>   During conversion to gitlab all bugzilla issues were created as
> issues. I reviewed many voice related issues, made solutions (e.g.
> patches) for them and updated issues, but they are still open even it
> makes no sense anymore.
>

When you have a MR fixing a given bug, please add a fixes #XXX comment in
you commit message so that GitLab can close the issue automatically. It
will avoid the need to manually close them afterwards.

  Can I or someone else close them?
>

I do not know if you have the rights to close an issue in  GitLab, but if
not leave a comment and we will close them for you.

Best regards,
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

Re: [Wireshark-dev] What mean "Error: Found prohibited APIs in ..." error during build?

[Pascal Quantin]

Hi Jirka,

Le mar. 9 févr. 2021 à 09:13, Jirka Novak  a écrit :

> Hi,
>
> >>  I commited patch and pipeline failed because:
> >>
> >> ...
> >> FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt
> >> ...
> >> Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp:
> open
> >> Error: Found prohibited APIs in utils/rtp_audio_routing_filter.cpp: open
> >>
> >>  but message gives me no hint what to change.
> >
> > Change calls to open() to call ws_open(), instead, so that, on Windows,
> they can handle UTF-8 pathnames (by turning them into UTF-16 pathnames and
> passing them to routines that take UTF-16 pathnames, rather than using
> various code page encodings for strings).
> >
> > Also use ws_close() instead of close().  (The ws_ calls, on Windows,
> also call the Visual Studio C library routines that implement UN*X-style
> APIs, with an underscore preceding the UN*X API name.)
>
> Thank you for explanation and I understand the reasons, but I don't
> think it is possible in this case. Classes extending QIODevice where
> open/close are parent methods I must call/override.
> It looks that it is false positive check. Is there any way how to add
> exception to check in this case?
>

THere is already some code in checkAPIs.pl file to identify false positives:

# Match function calls, but ignore false positives from:
# C++ method definition: int MyClass::open(...)
# Method invocation: myClass->open(...);
# Function declaration: int open(...);
# Method invocation: QString().sprintf(...)
while (${$fileContentsRef} =~ m/ \W (?|\w\ ) (? 0) {
push @{$foundAPIsRef}, $api;
$groupHashRef->{function_counts}->{$api} += 1;
}

This probably needs to be improved for your use case.

Best regards,
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

Re: [Wireshark-dev] Do we see false positives on the prechecks in merge-request runners

[Pascal Quantin]

Hi Richard,

Le lun. 1 févr. 2021 à 16:09, Richard Sharpe 
a écrit :

> Hi folks,
>
> In one of the builds for my merge request around Robust AV Streaming,
> I got this:
>
> https://gitlab.com/wireshark/wireshark/-/jobs/998246552
>
> It is complaining that an ENC_BIG_ENDIAN should be ENC_NA, but in
> looking at the code, it already is ENC_NA and I have not changed that
> for a while (but perhaps the original code was wrong.)
>

This is not a false positive: your MR
https://gitlab.com/wireshark/wireshark/-/merge_requests/1885 is adding
those two new fields hf_ieee80211_tclas4_ipv6_src and
hf_ieee80211_tclas4_ipv6_dst and they use ENC_BIG_ENDIAN instead of ENC_NA.

Best regards,
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

Re: [Wireshark-dev] [Outreachy] Multiple-line parsing of packets dissected over HTTP

[Pascal Quantin]

Hi Joey,

Le mer. 20 janv. 2021 à 20:15, Joey Salazar  a écrit :

> Hi Pascal,
>
> On Wednesday, January 20, 2021 4:23 AM, Pascal Quantin wrote:
>
> Hi Joey,
>
> Le mar. 19 janv. 2021 à 23:35, Joey Salazar  a
> écrit :
>
>> On Tuesday, January 19, 2021 4:20 PM, Pascal Quantin wrote:
>>
>> Le mar. 19 janv. 2021 à 23:09, Joey Salazar  a
>> écrit :
>>
>>> Hi Pascal,
>>> On Tuesday, January 19, 2021 11:19 AM, Pascal Quantin wrote:
>>>
>>> Hi Joey,
>>>
>>> Le mar. 19 janv. 2021 à 17:45, Joey Salazar via Wireshark-dev <
>>> wireshark-dev@wireshark.org> a écrit :
>>>
>>>> Hi all,
>>>>
>>>> In commit 33af2649 [1] we can keep dissecting the contents of the req,
>>>> adv, and res packets by setting
>>>>  while (plen > 0) { }
>>>> either in `dissect_git_pdu()` or in `dissect_one_pkt_line()`, but for
>>>> now in `dissect_git_pdu()` it'd be a bit messy, so wanted to ask for your
>>>> feedback for getting `dissect_one_pkt_line()` to work properly first.
>>>>
>>>> As you can see in pcap 169 [2], it correctly parses the length of the
>>>> first line as 0x0014 (20 bytes) until `0x0a`, then it's supposed to get the
>>>> length of the next line by the first 4 hex bytes in that line, but instead
>>>> of reading the length as 0x0018 (24 bytes) it's reading it as 0x0010 (16
>>>> bytes), and anyways, this particular line's length actually is 59 bytes.
>>>>
>>>> Suggestions on how to approach this?
>>>>
>>>
>>> So what is the code leading to this dissection? It does not seem to be
>>> gitlab.com/joeysal/wireshark/-/commit/33af2649927cb5660d4aeb64b9a9e9a58a1823aa
>>> as dissect_one_pkt_line() seem to read only one line
>>>
>>> Yes, the code on that commit is what gives the parsing of the screenshot.
>>>
>>
>> So what mechanism is used to call dissect_one_plt_line() a second time?
>> With only screenshots and no pcap / code to look at, we can hardly help.
>>
>> The code has already been provided. I confirm again that there hasn't
>> been other lines added other than what's in that commit.
>>
>> Does it mean that packet-http.c calls your dissector per line? Please
>> provide more info, or even better share the pcap if you want us to provide
>> some help.
>>
>> Please find attached the pcap I'm using with the patch from the commit.
>> As you can see, the way 167 and 255 are parsed is similar, but I'm
>> referring specifically to 169 for now ("To-do" in line 121 will be for the
>> cases where there's a  terminator packet like the end of the first-line
>> in 167) .
>>
>
> Unfortunately you did not share the associated TLS secret (or I missed it)
> that would allow me to decrypt the session and test your dissector. Could
> you send it?
>
> My big apologies, I haven't worked with TLS certificates in the past and
> completely missed to send the secret. Apologies for taking your time.
> Please let me know if I'm missing anything else.
>

The use of a debugger clearly shows what the issue is:
- dissect_one_pkt_line() gets the length of the first line only with
get_packet_length(). So the while loop after should be useless as you will
consume the full line anyway as I stated previously
- dissect_one_pkt_line() is in fact intended to decode all lines, but you
are not updating plen after adding the hf_git_packet_data item to the tree
while incrementing offset. So you reuse the previous value of plen (that
has been decremented by 4 after putting the hf_git_packet_len item), thus
the value 0x0010 you get.
Your code should be instead something like this:

  total_len = tvb_reported_length(tvb);
  while (offset < total_len) {
if (!get_packet_length(tvb, offset, )) {
  /* XXX display expert info error? */
  return tvb_captured_length(tvb);
}
proto_tree_add_uint(git_tree, hf_git_packet_len, tvb, offset, 4, plen);
offset += 4;
plen -= 4;

proto_tree_add_item(git_tree, hf_git_packet_data, tvb, offset, plen,
ENC_NA);
offset += plen;
// To-do: add lines for parsing of terminator packet 
  }
  if (plen == 0) {
proto_tree_add_uint(git_tree, hf_git_packet_terminator, tvb, offset,
4, plen);
  }
  return tvb_captured_length(tvb);

Note that in packet 169 there seems to be an issue with the fourth line
that has a length of 1 only while you expect 4 at a minimum in your code.
It needs to be properly handled.

Hope this helps,
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

Re: [Wireshark-dev] Multiple-line parsing of packets dissected over HTTP

[Pascal Quantin]

Hi Joey,

Le mar. 19 janv. 2021 à 23:35, Joey Salazar  a écrit :

> On Tuesday, January 19, 2021 4:20 PM, Pascal Quantin wrote:
>
> Le mar. 19 janv. 2021 à 23:09, Joey Salazar  a
> écrit :
>
>> Hi Pascal,
>> On Tuesday, January 19, 2021 11:19 AM, Pascal Quantin wrote:
>>
>> Hi Joey,
>>
>> Le mar. 19 janv. 2021 à 17:45, Joey Salazar via Wireshark-dev <
>> wireshark-dev@wireshark.org> a écrit :
>>
>>> Hi all,
>>>
>>> In commit 33af2649 [1] we can keep dissecting the contents of the req,
>>> adv, and res packets by setting
>>>  while (plen > 0) { }
>>> either in `dissect_git_pdu()` or in `dissect_one_pkt_line()`, but for
>>> now in `dissect_git_pdu()` it'd be a bit messy, so wanted to ask for your
>>> feedback for getting `dissect_one_pkt_line()` to work properly first.
>>>
>>> As you can see in pcap 169 [2], it correctly parses the length of the
>>> first line as 0x0014 (20 bytes) until `0x0a`, then it's supposed to get the
>>> length of the next line by the first 4 hex bytes in that line, but instead
>>> of reading the length as 0x0018 (24 bytes) it's reading it as 0x0010 (16
>>> bytes), and anyways, this particular line's length actually is 59 bytes.
>>>
>>> Suggestions on how to approach this?
>>>
>>
>> So what is the code leading to this dissection? It does not seem to be
>> https://gitlab.com/joeysal/wireshark/-/commit/33af2649927cb5660d4aeb64b9a9e9a58a1823aa
>> as dissect_one_pkt_line() seem to read only one line
>>
>> Yes, the code on that commit is what gives the parsing of the screenshot.
>>
>
> So what mechanism is used to call dissect_one_plt_line() a second time?
> With only screenshots and no pcap / code to look at, we can hardly help.
>
> The code has already been provided. I confirm again that there hasn't been
> other lines added other than what's in that commit.
>
> Does it mean that packet-http.c calls your dissector per line? Please
> provide more info, or even better share the pcap if you want us to provide
> some help.
>
> Please find attached the pcap I'm using with the patch from the commit. As
> you can see, the way 167 and 255 are parsed is similar, but I'm referring
> specifically to 169 for now ("To-do" in line 121 will be for the cases
> where there's a  terminator packet like the end of the first-line in
> 167) .
>

Unfortunately you did not share the associated TLS secret (or I missed it)
that would allow me to decrypt the session and test your dissector. Could
you send it?

Best regards,
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

Re: [Wireshark-dev] Multiple-line parsing of packets dissected over HTTP

[Pascal Quantin]

Le mar. 19 janv. 2021 à 23:09, Joey Salazar  a écrit :

> Hi Pascal,
> On Tuesday, January 19, 2021 11:19 AM, Pascal Quantin wrote:
>
> Hi Joey,
>
> Le mar. 19 janv. 2021 à 17:45, Joey Salazar via Wireshark-dev <
> wireshark-dev@wireshark.org> a écrit :
>
>> Hi all,
>>
>> In commit 33af2649 [1] we can keep dissecting the contents of the req,
>> adv, and res packets by setting
>>  while (plen > 0) { }
>> either in `dissect_git_pdu()` or in `dissect_one_pkt_line()`, but for now
>> in `dissect_git_pdu()` it'd be a bit messy, so wanted to ask for your
>> feedback for getting `dissect_one_pkt_line()` to work properly first.
>>
>> As you can see in pcap 169 [2], it correctly parses the length of the
>> first line as 0x0014 (20 bytes) until `0x0a`, then it's supposed to get the
>> length of the next line by the first 4 hex bytes in that line, but instead
>> of reading the length as 0x0018 (24 bytes) it's reading it as 0x0010 (16
>> bytes), and anyways, this particular line's length actually is 59 bytes.
>>
>> Suggestions on how to approach this?
>>
>
> So what is the code leading to this dissection? It does not seem to be
> https://gitlab.com/joeysal/wireshark/-/commit/33af2649927cb5660d4aeb64b9a9e9a58a1823aa
> as dissect_one_pkt_line() seem to read only one line
>
> Yes, the code on that commit is what gives the parsing of the screenshot.
>

So what mechanism is used to call dissect_one_plt_line() a second time?
With only screenshots and no pcap / code to look at, we can hardly help.
Does it mean that packet-http.c calls your dissector per line? Please
provide more info, or even better share the pcap if you want us to provide
some help.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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] Multiple-line parsing of packets dissected over HTTP

[Pascal Quantin]

Hi Joey,

Le mar. 19 janv. 2021 à 17:45, Joey Salazar via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> Hi all,
>
> In commit 33af2649 [1] we can keep dissecting the contents of the req,
> adv, and res packets by setting
>  while (plen > 0) { }
> either in `dissect_git_pdu()` or in `dissect_one_pkt_line()`, but for now
> in `dissect_git_pdu()` it'd be a bit messy, so wanted to ask for your
> feedback for getting `dissect_one_pkt_line()` to work properly first.
>
> As you can see in pcap 169 [2], it correctly parses the length of the
> first line as 0x0014 (20 bytes) until `0x0a`, then it's supposed to get the
> length of the next line by the first 4 hex bytes in that line, but instead
> of reading the length as 0x0018 (24 bytes) it's reading it as 0x0010 (16
> bytes), and anyways, this particular line's length actually is 59 bytes.
>
> Suggestions on how to approach this?
>

So what is the code leading to this dissection? It does not seem to be
https://gitlab.com/joeysal/wireshark/-/commit/33af2649927cb5660d4aeb64b9a9e9a58a1823aa
as dissect_one_pkt_line() seem to read only one line (BTW using a while
loop in this commit is useless as you are incrementing offset by plen, and
the code you shared considers that plen includes the 4 bytes of the packet
length field while your screenshot does not assume that).

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives: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] Assigned reviewers

[Pascal Quantin]

Le mer. 6 janv. 2021 à 11:26, Dario Lombardo  a écrit :

>
>
> On Wed, Jan 6, 2021 at 9:38 AM Pascal Quantin 
> wrote:
>
>> Hi Jonathan,
>>
>> Le mer. 6 janv. 2021 à 05:39, Jonathan Nieder  a
>> écrit :
>>
>>> Hi wiresharks,
>>>
>>> Context:
>>> https://gitlab.com/wireshark/wireshark/-/merge_requests/1313#note_478706594
>>>
>>> In Gerrit times, a person could add someone as a reviewer to a change
>>> to request review, the reviewer could remove themselves if they were
>>> unavailable, and so on.  What is the equivalent in the GitLab world?
>>> More concretely:
>>>
>>> - when a change is ready to review, how do I say so?
>>>
>>
>> All opened threads are resolved and the submitter can add a comment to
>> ping us. A reviewer can be explicitly added in the right column of the
>> Gitlab GUI
>>
>
> Do you mean assignee? I guess so, but I'd like to clear it, since the
> reviewer and assignee were separate in Gerrit.
>

No I really meant reviewer as I was considering the assignee as the person
that will ultimately schedule the merge. You can have more than one
reviewer. But I'm open to any workflow we might define.


>
>>
>> - if a review seems to be stalled, what's the best place to poke?
>>>
>>
>> Writing a comment in the MR; we are almost all volunteers doing this on
>> our spare time so sometimes real life collides and a given change can get
>> out of the radar
>>
>> - if I would like to review a change, how should I signal interest?
>>>
>>
>> Everybody is free to put comments in a MR
>>
>> - what happens when a change has been approved and it is time to merge
>>>   it?  Where can I read about the bot that does that?
>>>
>>
>> One of the core developer approves the change and schedules it for merge
>>
>>
> The Core devels are able to rebase and merge a MR. However the race for
> merge with other MRs could make the merge harder. That's why we can assign
> the MR to the bot that automatically rebases the change until the merge
> actually happens. But it's not a must.
>

As only core developers can do this operation, that's what I meant when
saying "schedule for merge" but did not enter into the details. Thanks for
clarifying it.
___
Sent via:Wireshark-dev mailing list 
Archives: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] Assigned reviewers

[Pascal Quantin]

Hi Jonathan,

Le mer. 6 janv. 2021 à 05:39, Jonathan Nieder  a écrit :

> Hi wiresharks,
>
> Context:
> https://gitlab.com/wireshark/wireshark/-/merge_requests/1313#note_478706594
>
> In Gerrit times, a person could add someone as a reviewer to a change
> to request review, the reviewer could remove themselves if they were
> unavailable, and so on.  What is the equivalent in the GitLab world?
> More concretely:
>
> - when a change is ready to review, how do I say so?
>

All opened threads are resolved and the submitter can add a comment to ping
us. A reviewer can be explicitly added in the right column of the Gitlab GUI

- if a review seems to be stalled, what's the best place to poke?
>

Writing a comment in the MR; we are almost all volunteers doing this on our
spare time so sometimes real life collides and a given change can get out
of the radar

- if I would like to review a change, how should I signal interest?
>

Everybody is free to put comments in a MR

- what happens when a change has been approved and it is time to merge
>   it?  Where can I read about the bot that does that?
>

One of the core developer approves the change and schedules it for merge

Best regards,
Pascal.


> I checked docbook/wsdg_src/WSDG_chapter_sources.adoc[1] as a first
> guess of where to find these answers and didn't get a clear sense of
> things.  I'll be happy to contribute a summary of what I learn there.
>
> Thanks for your kind help in reviews while we've been guessing. :)
>
> Thanks,
> Jonathan
>
> [1] https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Branch name issues ...

[Pascal Quantin]

Hi Richard,

Le dim. 3 janv. 2021 à 01:01, Richard Sharpe 
a écrit :

> Hi folks,
>
> I just tried to push some changes to my upstream repo prior to
> creating a merge request for the PV1/S1G changes I have accumulated.
>
> However, I hit this problem:
>
> remote: GitLab: Branch name does not follow the pattern
> '^(master|release-3.4|master-3.2|master-3.0|cherry-pick-.*)$'
>
> My branch is called ieee80211-PV1 ...
>
> Is this something I can change in my fork or do I have to use
> something like cherry-pick-.xxx?
>

Are you sure you are not trying to push to the
gitlab.com/wireshark/wireshark (upstream) repository and not to your fork
(downstream)?

Best regards,
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

Re: [Wireshark-dev] tpdu_data missing in gtp packet

[Pascal Quantin]

Hi,

Le ven. 25 déc. 2020 à 06:02, Ranjeet kumar singh  a
écrit :

> it is present in 3.25 and missing in 3.4.2.
>
> Please see attached images. in one this field is present and in other
> it's missing.
>
> I have not made any setting changes. Just installed released wireshark
> and opened a captured file with gtp packet.
>

I cannot reproduce your issue: by setting the "Dissect T-PDU as None" GTP
preference, I do get the T-PDU data payload displayed with 3.4.2. If I let
the default value (TPDU Heuristic) it properly identifies the payload as IP.
So it could be related to your GTP-U PDU where the heuristic fails for
example. Please check the behavior if you sendure to set the preference to
None and share the packet if it still fails.

Best regards.


>
> Regards
> Ranjeet S
>
> On Thu, Dec 24, 2020 at 1:46 PM Dario Lombardo  wrote:
> >
> > Can you please tell a version in which is present and a version in which
> is not?
> >
> > On Thu, Dec 24, 2020 at 8:54 AM Ranjeet kumar singh <
> ranjeet...@gmail.com> wrote:
> >>
> >> Hi
> >>
> >> Gtp packets used to have a tpdu_data field.
> >>
> >> I don't see it in the latest wireshark.
> >>
> >> This is causing my lua plugins to break.
> >>
> >> Can someone please fix it.
> >>
> >> Regards
> >> Ranjeet S
> >>
> ___
> >> Sent via:Wireshark-dev mailing list 
> >> Archives:https://www.wireshark.org/lists/wireshark-dev
> >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> >
> >
> >
> > --
> >
> > Naima is online.
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] tpdu_data missing in gtp packet

[Pascal Quantin]

Le jeu. 24 déc. 2020 à 09:16, Dario Lombardo  a écrit :

> Can you please tell a version in which is present and a version in which
> is not?
>

And please clarify your GTP setting regarding the T-PDU dissection.


> On Thu, Dec 24, 2020 at 8:54 AM Ranjeet kumar singh 
> wrote:
>
>> Hi
>>
>> Gtp packets used to have a tpdu_data field.
>>
>> I don't see it in the latest wireshark.
>>
>> This is causing my lua plugins to break.
>>
>> Can someone please fix it.
>>
>> Regards
>> Ranjeet S
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] F1AP Messages are not getting dissected correctly.

[Pascal Quantin]

Dear Simran,

Le mer. 16 déc. 2020 à 17:38, Simran Kumawat 
a écrit :

> Hi Sir/Ma'am,
>
> This is Simran Kumawat, Project Associate at 5G-TestBed Project, IIT
> Hyderabad.
> I am working on the F1AP interface currently, I observed a few things as
> mentioned below.
> Wireshark is dissecting f1ap msgs like this -
> 1. Initiating Message --> Initiating Message
> 2. SuccessfulOutcome Message> Initiating Message
> 3. UnsuccessfulOutcome Message-> SuccessfulOutcome Message
> The information contained is also the same but the problem is  only at
> this moment. for example ,
> wireshark is dissecting F1SetupResponse > F1SetupRequest and
>
> F1SetupFailure> F1SetupResponse
> with the same content. There is no problem in the code because after
> decoding at receiver side, I am printing the info contained in the packet.
> I am attaching the wireshark capture for your reference and logs from
> sender and receiver side.
>
> I request you to please check with the issue mentioned above.
> In case of any query, please get back to me.
>

Wireshark decodes your pcap as:
F1 Application Protocol
F1AP-PDU: successfulOutcome (1)
successfulOutcome
procedureCode: id-F1Setup (1)
criticality: reject (0)
value
F1SetupResponse
protocolIEs: 2 items
Item 0: id-TransactionID
ProtocolIE-Field
id: id-TransactionID (78)
criticality: reject (0)
value
TransactionID: 20
Item 1: id-Cause
ProtocolIE-Field
id: id-Cause (0)
criticality: reject (0)
value
Cause: radioNetwork (0)
radioNetwork: unspecified (0)

Which matches the decoding obtained with other ASN.1 engines (like
https://asn1.io/asn1playground/ for example, as seen below):
F1AP-PDU ::= successfulOutcome : {
  procedureCode 1,
  criticality reject,
  value F1SetupResponse : {
protocolIEs {
  {
id 78,
criticality reject,
value TransactionID : 20
  },
  {
id 0,
criticality reject,
value OCTET STRING : '00'H
  }
}
  }
}

So the bug is on your side.

Best regards,
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

Re: [Wireshark-dev] Qt warning on Windows build.

[Pascal Quantin]

Hi Chris,

Le lun. 23 nov. 2020 à 20:38, Maynard, Christopher via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> > From: Wireshark-dev  On Behalf Of
> Anders Broman via Wireshark-dev
> > Sent: Thursday, November 19, 2020 3:50 AM
> > To: wireshark-dev@wireshark.org
> > Cc: Anders Broman 
> > Subject: [Wireshark-dev] Qt warning on Windows build.
> >
> > 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
> >
>
> And after upgrading to Qt 5.15.2, there are more warnings, and since at
> least 2 of them are treated as errors, the build now fails:
>
> Build FAILED.
>
>"D:\wireshark\builds\win64\master\Wireshark.sln" (default target)
> (1) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj"
> (default
>target) (44) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default
> target) (
>120) ->
>(ClCompile target) ->
>  D:\wireshark\src\master\ui\qt\widgets\byte_view_text.cpp(187,38):
> warn
>ing C4996: 'QFont::ForceIntegerMetrics': was declared deprecated
> [D:\wir
>eshark\builds\win64\master\ui\qt\qtui.vcxproj]
>
>
>"D:\wireshark\builds\win64\master\Wireshark.sln" (default target)
> (1) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj"
> (default
>target) (44) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default
> target) (
>120) ->
>  D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): warning
> C4996:
>'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead
> [D:\w
>ireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\packet_list.cpp(794,64): warning
> C4996:
>'Qt::MidButton': MidButton is deprecated. Use MiddleButton instead
> [D:\w
>ireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): warning
> C4996:
> 'QPrinter::pageRect': Use
> pageLayout().paintRectPixels(resolution()) in
>stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\print_dialog.cpp(174,55): warning
> C4996:
> 'QPrinter::pageRect': Use
> pageLayout().paintRectPixels(resolution()) in
>stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\print_dialog.cpp(176,21): warning
> C4996:
> 'QPrinter::pageRect': Use
> pageLayout().paintRectPixels(resolution()) in
>stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\print_dialog.cpp(236,24): warning
> C4996:
> 'QPrinter::pageRect': Use
> pageLayout().paintRectPixels(resolution()) in
>stead. [D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj]
>
>
>"D:\wireshark\builds\win64\master\Wireshark.sln" (default target)
> (1) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj.metaproj"
> (default
>target) (44) ->
>"D:\wireshark\builds\win64\master\ui\qt\qtui.vcxproj" (default
> target) (
>120) ->
>(ClCompile target) ->
>  D:\wireshark\src\master\ui\qt\packet_list.cpp(794,46): error
> C2220: th
>e following warning is treated as an error
> [D:\wireshark\builds\win64\ma
>ster\ui\qt\qtui.vcxproj]
>  D:\wireshark\src\master\ui\qt\print_dialog.cpp(139,32): error
> C2220: t
>he following warning is treated as an error
> [D:\wireshark\builds\win64\m
>aster\ui\qt\qtui.vcxproj]
>
> 7 Warning(s)
> 2 Error(s)
>

You can find a fix attempt here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/1011
It does not handle the warning raised by Anders though.

Best regards,
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

Re: [Wireshark-dev] Compile fails after fetch

[Pascal Quantin]

Hi Jorge,

Le jeu. 19 nov. 2020 à 18:08, Pascal Quantin  a
écrit :

> Hi Jorge,
>
> Le jeu. 19 nov. 2020 à 17:51, Mora, Jorge  a
> écrit :
>
>> Hello,
>>
>>
>>
>> After a git fetch, compile fails with the following:
>>
>> [ 50%] Building C object
>> epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
>>
>> /home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error:
>> ‘quic_are_ciphers_initialized’ defined but not used
>> [-Werror=unused-function]
>>
>> quic_are_ciphers_initialized(quic_ciphers *ciphers)
>>
>> ^
>>
>> cc1: all warnings being treated as errors
>>
>> make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o]
>> Error 1
>>
>> make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2
>>
>>
>>
>> $ git log
>>
>> commit 1d7bc367e943464f912a67ad436fabddb1a61a37
>>
>> Author: Anders Broman 
>>
>> Date:   Wed Nov 18 13:56:52 2020 +0100
>>
>>
>>
>> GSM A Common: Dissect polygon points
>>
>>
>>
>>
>>
>> Two weeks ago I did a git fetch and I was able to compile with no
>> problems.
>>
>
> See https://gitlab.com/wireshark/wireshark/-/merge_requests/974
>

You can pull master branch, the issue is now fixed. Thanks for reporting it.


> Best regards,
> Pascal.
>
>
>>
>>
>>
>> --Jorge
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives: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] Compile fails after fetch

[Pascal Quantin]

Hi Jorge,

Le jeu. 19 nov. 2020 à 17:51, Mora, Jorge  a écrit :

> Hello,
>
>
>
> After a git fetch, compile fails with the following:
>
> [ 50%] Building C object
> epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
>
> /home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error:
> ‘quic_are_ciphers_initialized’ defined but not used
> [-Werror=unused-function]
>
> quic_are_ciphers_initialized(quic_ciphers *ciphers)
>
> ^
>
> cc1: all warnings being treated as errors
>
> make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o]
> Error 1
>
> make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2
>
>
>
> $ git log
>
> commit 1d7bc367e943464f912a67ad436fabddb1a61a37
>
> Author: Anders Broman 
>
> Date:   Wed Nov 18 13:56:52 2020 +0100
>
>
>
> GSM A Common: Dissect polygon points
>
>
>
>
>
> Two weeks ago I did a git fetch and I was able to compile with no problems.
>

See https://gitlab.com/wireshark/wireshark/-/merge_requests/974

Best regards,
Pascal.


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

Re: [Wireshark-dev] How to ammend/correct a merged MR?

[Pascal Quantin]

Hi Chuck

Le ven. 30 oct. 2020 à 14:51, chuck c  a écrit :

> https://gitlab.com/wireshark/wireshark/-/merge_requests/180
>
> Do I make another commit again !180 or create a new commit and merge
> request?
>

As this MR is already merged, my understanding is that you must create a
new one (but I'm still in the learning curve like you :)).

Best regards,
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

Re: [Wireshark-dev] Random "#" in issues - cross references

[Pascal Quantin]

Le mer. 28 oct. 2020 à 17:17, Pascal Quantin  a
écrit :

> Hi Chuck,
>
> Le mer. 28 oct. 2020 à 17:00, chuck c  a écrit :
>
>> https://gitlab.com/wireshark/wireshark/-/issues/16844
>> "Compiled (64-bit) with Qt 5.14.2, with libpcap, with GLib 2.52.3, with
>> zlib
>> 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4, with GnuTLS
>> 3.6.3
>> and PKCS #11 (closed) support, ..."
>>
>> The #11 gets flagged as an issue and cross reference made.
>>
>> https://gitlab.com/wireshark/wireshark/-/issues/11
>>
>
> presumably putting the build description in``` quotes would have prevented
> this. We should update our bug template.
>

See https://gitlab.com/wireshark/wireshark/-/merge_requests/765


> Best regards,
> Pascal.
>
>
>>
>>
>> Austin Knutson @AustinKnutsonSprint mentioned in issue #16805 (closed) 2
>> months ago
>> Chuck Craft @chuckcraft mentioned in issue #16834 1 month ago
>> Allen Lee @BigFatCat mentioned in issue #16837 1 month ago
>> Chuck Craft @chuckcraft mentioned in issue #16844 (closed) 1 month ago
>> Georg Kneringer @EggisEgg mentioned in issue #16846 (closed) 1 month ago
>> lemur117 @lemur117 mentioned in issue #16859 1 month ago
>> John Thacker @johnthacker mentioned in issue #16872 1 month ago
>> Dmitry @dpl94 mentioned in issue #16881 (closed) 4 weeks ago
>> Ori Inbar @oriinbar mentioned in issue #16889 (closed) 3 weeks ago
>> Elvis Presley @phikus mentioned in issue #16904 (closed) 2 weeks ago
>> Haxthausen @Haxthausen mentioned in issue #16905 2 weeks ago
>> Guy Harris @guyharris mentioned in issue #16906 2 weeks ago
>> John Thacker @johnthacker mentioned in issue #16909 (closed) 1 week ago
>> Gerald Combs @geraldcombs mentioned in issue #16911 1 week ago
>> Tomáš Szaniszlo @tomaxuser mentioned in issue #16925 1 week ago
>> Jaap Keuter @JaapKeuter mentioned in issue #16940 1 week ago
>> Christopher Maynard @cjmaynard mentioned in issue #16957 14 hours ago
>> Jaap Keuter @JaapKeuter mentioned in issue #16961 (closed) 5 hours ago
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives: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] Random "#" in issues - cross references

[Pascal Quantin]

Hi Chuck,

Le mer. 28 oct. 2020 à 17:00, chuck c  a écrit :

> https://gitlab.com/wireshark/wireshark/-/issues/16844
> "Compiled (64-bit) with Qt 5.14.2, with libpcap, with GLib 2.52.3, with
> zlib
> 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4, with GnuTLS
> 3.6.3
> and PKCS #11 (closed) support, ..."
>
> The #11 gets flagged as an issue and cross reference made.
>
> https://gitlab.com/wireshark/wireshark/-/issues/11
>

presumably putting the build description in``` quotes would have prevented
this. We should update our bug template.

Best regards,
Pascal.


>
>
> Austin Knutson @AustinKnutsonSprint mentioned in issue #16805 (closed) 2
> months ago
> Chuck Craft @chuckcraft mentioned in issue #16834 1 month ago
> Allen Lee @BigFatCat mentioned in issue #16837 1 month ago
> Chuck Craft @chuckcraft mentioned in issue #16844 (closed) 1 month ago
> Georg Kneringer @EggisEgg mentioned in issue #16846 (closed) 1 month ago
> lemur117 @lemur117 mentioned in issue #16859 1 month ago
> John Thacker @johnthacker mentioned in issue #16872 1 month ago
> Dmitry @dpl94 mentioned in issue #16881 (closed) 4 weeks ago
> Ori Inbar @oriinbar mentioned in issue #16889 (closed) 3 weeks ago
> Elvis Presley @phikus mentioned in issue #16904 (closed) 2 weeks ago
> Haxthausen @Haxthausen mentioned in issue #16905 2 weeks ago
> Guy Harris @guyharris mentioned in issue #16906 2 weeks ago
> John Thacker @johnthacker mentioned in issue #16909 (closed) 1 week ago
> Gerald Combs @geraldcombs mentioned in issue #16911 1 week ago
> Tomáš Szaniszlo @tomaxuser mentioned in issue #16925 1 week ago
> Jaap Keuter @JaapKeuter mentioned in issue #16940 1 week ago
> Christopher Maynard @cjmaynard mentioned in issue #16957 14 hours ago
> Jaap Keuter @JaapKeuter mentioned in issue #16961 (closed) 5 hours ago
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Buildbot crash - what did I break?

[Pascal Quantin]

Hi Chuck

Le jeu. 22 oct. 2020 à 20:06, chuck c  a écrit :

> https://gitlab.com/wireshark/wireshark/-/issues/16939
> Buildbot crash output: fuzz-2020-10-20-17042.pcap
>
> Git commit
> commit 5b242d62b045e6c85a0119c5271d0b072707c79a
> Author: Chuck Craft 
> Date:   Tue Sep 8 21:59:02 2020 -0500
>
> WIN32 logging: connect stdio earlier in main()
>
>
> https://gitlab.com/wireshark/wireshark/-/commit/5b242d62b045e6c85a0119c5271d0b072707c79a
>
> But it seems it might be this commit instead?
>
> https://gitlab.com/wireshark/wireshark/-/commit/0ceb46e1c28d1094a56aefa0ebf7d7c0e00f8849
> proto: add support for FT_BYTES in proto_tree_add_bits
>

It's not you: you get the reference of the changeset that was fuzzed, which
is not necessarily the one that introduced the issue.

Best regards,
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

Re: [Wireshark-dev] Documentation for PDUs and TLS session keys

[Pascal Quantin]

Hi Alex,

Le mar. 29 sept. 2020 à 20:14, Alex Nik  a écrit :

> Hi, folks,
>
> I’m looking for the subject matter expert in Exporting PDUs to file and
> Exporting TLS session keys to write a proper documentation. Is there anyone
> who I can ask questions? I’m alexnik in the IRC. Could you contact me there
> please, or answer to this mail?
>

I have contributed to the PDU export functionality addition in Wireshark
even if I'm not the author. You can find some documentation in the
corresponding header file (
https://gitlab.com/wireshark/wireshark/-/blob/master/epan/exported_pdu.h)
even if it is more developer oriented than user oriented. The purpose is to
be able to save "upper level" PDUs without the need for lower level
protocols (for example to save a decrypted session without the need to
share the encryption keys).
Currently we have the following default PDU export levels:
- Logcat and Logcat text: for Android logs
- DLT User: to be able to export a protocol framed in a user data link type
table without the need to configure user DLT table again (see
https://gitlab.com/wireshark/wireshark/-/wikis/HowToDissectAnything)
- DVB-CI: for DVB protocol
- OSI layer 3: currently used to export protocols encapsulated in IPSec or
SCTP
- OSI layer 4: currently used to export protocols encapsulated in TCP or UDP
- OSI layer 7: currently used to export the following protocols: CredSSP
over TLS, Diameter, protocols encapsulated in TLS and DTLS, H.248, Megaco,
RELOAD framing, SIP, SMPP
The framework allows any dissector to add itself to this existing list or
define a new entry in the list. The choice of the protocols using this
functionality was mostly driven by user specific needs than anything else.

Hope this helps. Feel free to ask if you have more questions, I will try to
help.

Best regards,
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

Re: [Wireshark-dev] pfcp seid decode error

[Pascal Quantin]

Hi Ranjeet,

Le dim. 13 sept. 2020 à 05:54, Ranjeet kumar singh  a
écrit :

> Hi
>
> Seeing "IE wrongly encoded" error while decoding F-SEID in a pfcp
> session establishment response.
>
> Please see attached screenshot and pcap.
>
> Please let me know if it is a bug.
>

29.244 chapter 8.2.37 says "At least one of V4 and V6 shall be set to "1",
and both may be set to "1"", while here they are both set to 0. That's why
Wireshark displays the "IE wrongly encoded" error message.

Best regards,
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

Re: [Wireshark-dev] pfcp ctag decode bug

[Pascal Quantin]

Hi Ranjeet,

Le sam. 12 sept. 2020 à 18:45, Ranjeet kumar singh  a
écrit :

> PFA wireshark file.
>

Thanks. The current MR gives the following decoding:
C-TAG :
IE Type: C-TAG (134)
IE Length: 3
Flags: 0x04, VID
 0... = Spare: 0
 .1.. = VID: True
 ..0. = DEI: False
 ...0 = PCP: False
  1100 1000 = C-VID: 0x00c8
 0... = Drop eligible indicator (DEI): Ineligible
 .000 = Priority code point (PCP): Best Effort (default), Drop
Eligible (0)

Best regards,
Pascal.


> Regards
> Ranjeet S
>
> On Sat, Sep 12, 2020 at 9:31 PM Pascal Quantin 
> wrote:
> >
> > Hi Ranjeet,
> >
> > Le sam. 12 sept. 2020 à 17:58, Ranjeet kumar singh 
> a écrit :
> >>
> >> Hi Pascal
> >>
> >> Please find the attached image that shows the byte dump of the c-tag IE.
> >
> >
> > Please provide a full packet if you want the bug to be fixed. Thanks for
> your understanding.
> >
> >>
> >> Regards
> >> Ranjeet Singh
> >>
> >> On Sat, Sep 12, 2020 at 9:08 PM Pascal Quantin 
> wrote:
> >> >
> >> > Hi Ranjeet,
> >> >
> >> > Le sam. 12 sept. 2020 à 10:16, Pascal Quantin 
> a écrit :
> >> >>
> >> >> Le sam. 12 sept. 2020 à 04:40, Guy Harris  a
> écrit :
> >> >>>
> >> >>> On Sep 11, 2020, at 7:04 PM, Ranjeet kumar singh <
> ranjeet...@gmail.com> wrote:
> >> >>>
> >> >>> > I am seeing following error
> >> >>> >
> >> >>> > [Dissector bug, protocol PFCP:
> >> >>> >
> C:\buildbot\builders\wireshark-3.2-64\windows-2019-x64\build\epan\proto.c:11594:
> >> >>> > field pfcp.c_tag.dei_flag is not of type FT_CHAR or an FT_{U}INTn
> >> >>> > type]
> >> >>> >
> >> >>> > with a pfcp session establishment request.
> >> >>> >
> >> >>> > Can someone please confirm if it is a bug.
> >> >>>
> >> >>> Yes, Wireshark confirmed it, by saying "Dissector bug".  That's
> what the "bug" in "Dissector bug" means.
> >> >>>
> >> >>> The right place to report Wireshark bugs is
> >> >>>
> >> >>> https://gitlab.com/wireshark/wireshark/-/issues
> >> >>
> >> >>
> >> >> See https://gitlab.com/wireshark/wireshark/-/merge_requests/227
> >> >>
> >> >> I still have a doubt regarding the C-VID / S-VID encoding. See the
> MR comment for more details.
> >> >
> >> >
> >> > it would be great if you could share a pcap containing a packet with
> a C-TAG or S-TAG IE so as to verify the fix.
> >> >
> >> > Thanks,
> >> > 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
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives: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] pfcp ctag decode bug

[Pascal Quantin]

Hi Ranjeet,

Le sam. 12 sept. 2020 à 17:58, Ranjeet kumar singh  a
écrit :

> Hi Pascal
>
> Please find the attached image that shows the byte dump of the c-tag IE.
>

Please provide a full packet if you want the bug to be fixed. Thanks for
your understanding.


> Regards
> Ranjeet Singh
>
> On Sat, Sep 12, 2020 at 9:08 PM Pascal Quantin 
> wrote:
> >
> > Hi Ranjeet,
> >
> > Le sam. 12 sept. 2020 à 10:16, Pascal Quantin  a
> écrit :
> >>
> >> Le sam. 12 sept. 2020 à 04:40, Guy Harris  a écrit :
> >>>
> >>> On Sep 11, 2020, at 7:04 PM, Ranjeet kumar singh 
> wrote:
> >>>
> >>> > I am seeing following error
> >>> >
> >>> > [Dissector bug, protocol PFCP:
> >>> >
> C:\buildbot\builders\wireshark-3.2-64\windows-2019-x64\build\epan\proto.c:11594:
> >>> > field pfcp.c_tag.dei_flag is not of type FT_CHAR or an FT_{U}INTn
> >>> > type]
> >>> >
> >>> > with a pfcp session establishment request.
> >>> >
> >>> > Can someone please confirm if it is a bug.
> >>>
> >>> Yes, Wireshark confirmed it, by saying "Dissector bug".  That's what
> the "bug" in "Dissector bug" means.
> >>>
> >>> The right place to report Wireshark bugs is
> >>>
> >>> https://gitlab.com/wireshark/wireshark/-/issues
> >>
> >>
> >> See https://gitlab.com/wireshark/wireshark/-/merge_requests/227
> >>
> >> I still have a doubt regarding the C-VID / S-VID encoding. See the MR
> comment for more details.
> >
> >
> > it would be great if you could share a pcap containing a packet with a
> C-TAG or S-TAG IE so as to verify the fix.
> >
> > Thanks,
> > 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
___
Sent via:Wireshark-dev mailing list 
Archives: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] pfcp ctag decode bug

[Pascal Quantin]

Hi Ranjeet,

Le sam. 12 sept. 2020 à 10:16, Pascal Quantin  a
écrit :

> Le sam. 12 sept. 2020 à 04:40, Guy Harris  a écrit :
>
>> On Sep 11, 2020, at 7:04 PM, Ranjeet kumar singh 
>> wrote:
>>
>> > I am seeing following error
>> >
>> > [Dissector bug, protocol PFCP:
>> >
>> C:\buildbot\builders\wireshark-3.2-64\windows-2019-x64\build\epan\proto.c:11594:
>> > field pfcp.c_tag.dei_flag is not of type FT_CHAR or an FT_{U}INTn
>> > type]
>> >
>> > with a pfcp session establishment request.
>> >
>> > Can someone please confirm if it is a bug.
>>
>> Yes, Wireshark confirmed it, by saying "Dissector bug".  That's what the
>> "bug" in "Dissector bug" means.
>>
>> The right place to report Wireshark bugs is
>>
>> https://gitlab.com/wireshark/wireshark/-/issues
>
>
> See https://gitlab.com/wireshark/wireshark/-/merge_requests/227
>
> I still have a doubt regarding the C-VID / S-VID encoding. See the MR
> comment for more details.
>

it would be great if you could share a pcap containing a packet with a
C-TAG or S-TAG IE so as to verify the fix.

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

Re: [Wireshark-dev] pfcp ctag decode bug

[Pascal Quantin]

Le sam. 12 sept. 2020 à 04:40, Guy Harris  a écrit :

> On Sep 11, 2020, at 7:04 PM, Ranjeet kumar singh 
> wrote:
>
> > I am seeing following error
> >
> > [Dissector bug, protocol PFCP:
> >
> C:\buildbot\builders\wireshark-3.2-64\windows-2019-x64\build\epan\proto.c:11594:
> > field pfcp.c_tag.dei_flag is not of type FT_CHAR or an FT_{U}INTn
> > type]
> >
> > with a pfcp session establishment request.
> >
> > Can someone please confirm if it is a bug.
>
> Yes, Wireshark confirmed it, by saying "Dissector bug".  That's what the
> "bug" in "Dissector bug" means.
>
> The right place to report Wireshark bugs is
>
> https://gitlab.com/wireshark/wireshark/-/issues


See https://gitlab.com/wireshark/wireshark/-/merge_requests/227

I still have a doubt regarding the C-VID / S-VID encoding. See the MR
comment for more details.

Best regards,
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

Re: [Wireshark-dev] Cherry-picking, gitlab permissions

[Pascal Quantin]

Hi John,

Le mer. 26 août 2020 à 14:58, John Thacker  a écrit :

> The official Gitlab instructions (along with the still being transitioned
> developer's guide) mention the ability to cherry pick merges from the GUI:
>
> https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html#cherry-picking-a-merge-request
> https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html
>
> Those buttons don't appear for me. I do see this bug about the cherry-pick
> button not appearing for projects set to fast-forward merge only, like
> wireshark:
> https://gitlab.com/gitlab-org/gitlab/-/issues/5990
> but the workaround listed in that issue doesn't work for me either.
>

I do not see this button either, but when I select a commit and click on
the options button (upper right part of the commit window) I can select
cherry-pick. I don't know if you will see it in the Wireshark repository
with your current permission level but you should be able to perform the
cherry-pick in your own fork and then push a MR.

Best regards,
Pascal.


> I suspect that it may also have to do with permission levels. Is the
> current workaround to do it from the command line? Are there plans to have
> people who are not core developers request get and various intermediate
> levels of permission? The "Reporter" level of permission seems to include
> only things that previously people could get by registering for Bugzilla,
> and some other features that people used to be able to do seem at the
> "Developer" level (though that also includes some higher level permissions
> too.)
>
> John Thacker
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Version of Qt required?

[Pascal Quantin]

Hi John,

Le mar. 7 juil. 2020 à 19:09, John Thacker  a écrit :

> On Tue, Jul 7, 2020 at 10:48 AM Graham Bloice 
> wrote:
>
>>
>> The table of Qt versions shows which versions have been used in Wireshark
>> installers for Windows and macOS. Determining the versions available on
>> specific Linux distributions is a bit more of an artform but can be gleaned
>> from the tables further down.
>>
>
> Ah, I see, yes I misread the table and interpreted the bold versions as
> minimum requirements. I just took a look and  updated the RHEL/CentOS and
> SLES information. Looking at the rest of the tables, Debian Jesse just went
> end of support, so Ubuntu xenial (16.04LTS, end of support April 2021)
> being at 5.5.x is I think the oldest QT in a still officially supported
> distribution on that page. After that there's several at 5.6.x.
>
> I reckon that QT 5.9 is fine for every distro's most recent LTS release,
> and 5.6 is fine for every distro's N-1 LTS release. Personally I'd be fine
> with moving master to 5.9 (which also settles requiring C+11), but I could
> understand 5.6.
>

Can't this code be made conditional to the Qt version used for compiling?

Best regards,
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

Re: [Wireshark-dev] git clone does not include latest commits

[Pascal Quantin]

Hi Damian,

Le sam. 6 juin 2020 à 12:36, Damian Stevenson  a
écrit :

> I'm reading "Develop -> Get Involved" guide
> (https://www.wireshark.org/develop.html)
>
> But for some reason latest commits
> (https://code.wireshark.org/review/#/c/37385/) are not included into
> "git clone https://code.wireshark.org/review/wireshark;, which I want
> to compile and test.
>

The patch you are referring to is still under review and not merged yet. If
you want to test it you need to apply it by yourself.

Best regards,
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

Re: [Wireshark-dev] Question about displaying of Sequence Number of GTP v2

[Pascal Quantin]

Hi,

Le jeu. 4 juin 2020 à 17:11, Дмитрий Кондратьев  a
écrit :

> Good afternoon all.
> Recently I discovered that the parameter Sequence Number for GTP v2
> protocol is displayed in such way: "Sequence Number: 0x00ff (16777215)"
> But if you see specs then it is stated that Sequence Number is 24-bit
> field. From my perspective, it doesn't make sense to include two lead zeros.
> Am I missing something? Is it a small UI bug?
> Thank you in advance!
>

There are several sequence numbers in the GTPv2 specification.
The one specified in 3GPP 29.274 chapter 8.114 is 4 bytes long and this is
the one matching the gtpv2.sequence_number filter.
The one from the header is 3 bytes long and is using the gtpv2.seq filter.
It is wrongly displayed as a FT_UINT32 instead of FT_UINT24. I guess this
is the one you are looking at. THanks for the report, it is addressed in
https://code.wireshark.org/review/#/c/37379/

Best regards,
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

Re: [Wireshark-dev] asn2wrs.py no longer seems to generate the same code ...

[Pascal Quantin]

Le sam. 16 mai 2020 à 23:01, Richard Sharpe  a
écrit :

> On Sat, May 16, 2020 at 8:51 AM Pascal Quantin 
> wrote:
> >
> > Hi Richard,
> >
> > Le sam. 16 mai 2020 à 17:34, Richard Sharpe 
> a écrit :
> >>
> >> On Sat, May 16, 2020 at 6:00 AM João Valverde
> >>  wrote:
> >> >
> >> > Hi Richard,
> >> >
> >> > On 15/05/20 23:46, Richard Sharpe wrote:
> >> > > On Fri, May 15, 2020 at 3:33 PM Peter Wu 
> wrote:
> >> > >> The "asn1" target rebuilds all asn1 dissectors.
> >> > >> Alternatively to rebuild a specific one, use a target such as
> "generate_dissector-pkcs1".
> >> > > Sure, but there seems to be multiple issues.
> >> > >
> >> > > 1. The 'documented' command placed in the generated source does not
> >> > > generate the same source:
> >> > > 2. make asn1 modifies the source directory, but it seems to me that
> it
> >> > > should not do that because that breaks one of the out-of-tree
> >> > > guarantees that cmake gives you.
> >> >
> >> > Normally that would be true for a generated source file, but in this
> >> > case a choice was made to commit the generated ASN.1 source code to
> VCS
> >> > (for efficiency reasons I presume). Therefore the asn1 target is a
> >> > special one designed only to update the ASN.1 source tree and commit
> the
> >> > result.
> >>
> >> Shouldn't the developer make that decision?
> >
> >
> > That was a decision taken by the developers years ago, so I'm not sure I
> get your point. The idea is to reduce the build time as those dissectors
> are not updated that often and generating them takes some time.
>
> I understand that.
>
> However, if I make a change to one of the ASN files, as I just did,
> shouldn't it be my decision as to whether or not I want the modified
> .c file put in the source tree?
>

Well, should not you follow the existing agreement? Unless there was a
massive vote to change the existing behavior (and why would we?) it seems
normal to me to follow what was decided by the community. In any project
you have defined rules that you must follow, and that can be eventually
changed after an open discussion. Otherwise it becomes quickly a nightmare
unmanageable.

Best regards,
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

Re: [Wireshark-dev] asn2wrs.py no longer seems to generate the same code ...

[Pascal Quantin]

Hi Richard,

Le sam. 16 mai 2020 à 17:34, Richard Sharpe  a
écrit :

> On Sat, May 16, 2020 at 6:00 AM João Valverde
>  wrote:
> >
> > Hi Richard,
> >
> > On 15/05/20 23:46, Richard Sharpe wrote:
> > > On Fri, May 15, 2020 at 3:33 PM Peter Wu  wrote:
> > >> The "asn1" target rebuilds all asn1 dissectors.
> > >> Alternatively to rebuild a specific one, use a target such as
> "generate_dissector-pkcs1".
> > > Sure, but there seems to be multiple issues.
> > >
> > > 1. The 'documented' command placed in the generated source does not
> > > generate the same source:
> > > 2. make asn1 modifies the source directory, but it seems to me that it
> > > should not do that because that breaks one of the out-of-tree
> > > guarantees that cmake gives you.
> >
> > Normally that would be true for a generated source file, but in this
> > case a choice was made to commit the generated ASN.1 source code to VCS
> > (for efficiency reasons I presume). Therefore the asn1 target is a
> > special one designed only to update the ASN.1 source tree and commit the
> > result.
>
> Shouldn't the developer make that decision?
>

That was a decision taken by the developers years ago, so I'm not sure I
get your point. The idea is to reduce the build time as those dissectors
are not updated that often and generating them takes some time.

Best regards,
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

Re: [Wireshark-dev] asn2wrs.py no longer seems to generate the same code ...

[Pascal Quantin]

Hi Richard,

Le ven. 8 mai 2020 à 17:08, Richard Sharpe  a
écrit :

> Hi folks,
>
> While figuring out how to get a dissection function for
> ECDSA_Sig_Value, I noticed that asn2wrs.py no longer generates the
> same code it once did.
>
> I re-ran asn2wrs.py against epan/dissectors/asn1/pkcs1/pkcs1.cnf
> (unmodified) and then compared the current output to what is checked
> in. This is what I get:
>
> ---
> @@ -131,7 +131,7 @@
>
>  static int
>  dissect_pkcs1_DigestAlgorithmIdentifier(gboolean implicit_tag _U_,
> tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree
> *tree _U_, int hf_index _U_) {
> -  offset = dissect_x509af_AlgorithmIdentifier(implicit_tag, tvb,
> offset, actx, tree, hf_index);
> +  offset =
> dissect_AuthenticationFramework_AlgorithmIdentifier(implicit_tag,
> tvb, offset, actx, tree, hf_index);
>
>return offset;
>  }
> @@ -148,7 +148,7 @@
>
>
>  static const ber_sequence_t DigestInfo_sequence[] = {
> -  { _pkcs1_digestAlgorithm, BER_CLASS_UNI, BER_UNI_TAG_SEQUENCE,
> BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
> +  { _pkcs1_digestAlgorithm, -1/*imported*/, -1/*imported*/,
> BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
>{ _pkcs1_digest, BER_CLASS_UNI, BER_UNI_TAG_OCTETSTRING,
> BER_FLAGS_NOOWNTAG, dissect_pkcs1_Digest },
>{ NULL, 0, 0, 0, NULL }
>  };
> ...
> ---
>
> This seems like a problem ...
>
> Perhaps I should file a bugzilla bug.
>

Didi you check the file history to see whether it was manually modified? It
might not be a asn2wrs.py problem.

Best regards,
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

Re: [Wireshark-dev] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?

[Pascal Quantin]

Hi Richard,

Le jeu. 7 mai 2020 à 17:01, Richard Sharpe  a
écrit :

> Hi folks,
>
> I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in
> epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as:
>
> -
>ECDSA-Sig-Value ::= SEQUENCE {
> r  INTEGER,
> s  INTEGER
>}
> -
>
> I tried the obvious by adding it as an export to the pkcs1.cnf file by
> adding it to the .EXPORTS section but perhaps I forgot to remove it
> from the .NO_EMIT section ...
>

Do you need a dissector registered by name, or a function to call?

Best regards,
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

Re: [Wireshark-dev] Unable to cmake Wireshark on Red Hat 7 due to GLIB2 version error

[Pascal Quantin]

Hi Mark,

Le jeu. 30 avr. 2020 à 17:16, Brodie, Mark (Refinitiv) <
mark.bro...@refinitiv.com> a écrit :

> Hi there,
>
>
>
> My wireshark build attempt fails during cmake when it checks the version
> of GLIB2.
>
>
>
> -- Checking for one of the modules 'glib-2.0'
>
> CMake Error at
> /opt/cmake-3.17.2-Linux-x86_64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> (message):
>
>   Could NOT find GLIB2: Found unsuitable version "", but required is at
> least
>
>   "2.32.0" (found GLIB2_LIBRARY-NOTFOUND)
>
> Call Stack (most recent call first):
>
>
> /opt/cmake-3.17.2-Linux-x86_64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:443
> (_FPHSA_FAILURE_MESSAGE)
>
>   cmake/modules/FindGLIB2.cmake:106 (find_package_handle_standard_args)
>
>   CMakeLists.txt:1023 (find_package)
>
>
>
>
>
>
>
> GLIB2 is installed with version 2.56.1:
>
>
>
> sudo yum info glib2
>
> Loaded plugins: rhnplugin
>
> This system is receiving updates from RHN Classic or Red Hat Satellite.
>
> Installed Packages
>
> Name: glib2
>
> Arch: x86_64
>
> Version : 2.56.1
>
> Release : 5.el7
>
> Size: 12 M
>
> Repo: installed
>
> From repo   : fxspw-7-2002
>
> Summary : A library of handy utility functions
>
> URL : http://www.gtk.org
>
> License : LGPLv2+
>
> Description : GLib is the low-level core library that forms the basis for
> projects
>
> : such as GTK+ and GNOME. It provides data structure handling
> for C,
>
> : portability wrappers, and interfaces for such runtime
> functionality
>
> : as an event loop, threads, dynamic loading, and an object
> system.
>

You need the develpoment headers: install glib2-devel package.

Best regards,
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

Re: [Wireshark-dev] Issue Report - Latest Version

[Pascal Quantin]

Le mar. 28 avr. 2020 à 17:03, Graham Bloice  a
écrit :

>
>
> On Tue, 28 Apr 2020 at 15:45, Leonardo Ayek  wrote:
>
>>
>> Hi guys, just to let you know that I'm having a problem to use OpenVPN
>> GUI after I installed Wireshark (Latest Version)
>>
>>1. The version number of Wireshark and the dependent libraries linked
>>with it, such as Qt or GLib. You can obtain this from Wireshark’s about 
>> box
>>or the command *wireshark -v*. Wireshark Version 3.0.10
>>(v3.0.10-0-gaa0261e8ddf3)
>>2. Information about the platform you run Wireshark on (Windows,
>>Linux, etc. and 32-bit, 64-bit, etc.). Windows 7 Pro 64-bit
>>3. A detailed description of your problem. New Wireshark Version
>>(Wireshark-win64-3.2.3) is crashing OpenVPN (OpenVPN GUI v11.15.0.0)
>>4. If you get an error/warning message, copy the text of that message
>>(and also a few lines before and after it, if there are some) so others 
>> may
>>find the place where things go wrong. Please don’t give something like: “I
>>get a warning while doing x” as this won’t give a good idea where to 
>> look. After
>>I have installed / upgraded to the Wireshark latest version,  I can’t
>>connect to any VPN connections that I have on OpenVPN. If I remove or
>>downgrade Wireshark to the Wireshark-win64-3.0.10 version, I’m able to
>>connect again.
>>
>>
>>
>>
> This is almost certainly an issue with the 3rd party capture library used
> by Wireshark on Windows called npcap.
>
> You can:
>
>1. Uninstall npcap and then install the older (and unsupported)
>WinPcap that Wireshark is still able to use
>2. Work with the npcap support folks to report and hopefully fix the
>issue:  https://github.com/nmap/nmap/issues/
>
> And the issue you report seems quite similar to
https://github.com/nmap/nmap/issues/1980. They do have a few other related
open issues.

Best regards,
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

Re: [Wireshark-dev] Wiki EditorGroup request

[Pascal Quantin]

Hi Uli,

Le ven. 24 avr. 2020 à 13:39, Uli Heilmeier  a écrit :

> Hi,
>
> Can someone be so kind and add me (UliHeilmeier) to the EditorGroup at
> wiki.wireshark.org?


Done.

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

Re: [Wireshark-dev] Has anything changed with respect to contributing changes to Wireshark after github?

[Pascal Quantin]

Hi Richard,

Le mar. 14 avr. 2020 à 19:41, Richard Sharpe 
a écrit :

> Hi folks,
>
> I think I saw an email about things moving to github or gitlab and
> wondered if they meant any changes to my workflow around submitting
> changes?
>
> If so, is there a link I can use to see what they are?
>

Even if a move to gitlab is ongoing, so far nothing has changed so you must
still push to Gerrit.

Best regards,
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

Re: [Wireshark-dev] Wireshark col_append_sep_str function

[Pascal Quantin]

Hi Jannis,

Le ven. 3 avr. 2020 à 11:22, Peimann, Jannis <
jannis.peim...@continental-corporation.com> a écrit :

> Hi together,
>
>
>
> I want to add information to the Info column for every frame in Wireshark.
>
> This is working fine as long as I only have one PDU in my UDP package.
>
> If I  have more than one PDU, then it overwrites the old Info column
> string. It is not appending.
>
>
>
> *This is my function:*
>
> if (pdu_description != NULL)
>
> {
>
> col_append_sep_str(pinfo->cinfo, COL_INFO, ",",
> pdu_description);
>
> g_print("Debug Message: frame number [%d] [%s]\n", pinfo->fd->num,
> pdu_description);/*Debug Console Message */
>
> }
>
>
>
> This col_append_sep_str function is from column-utils.c
>
> For example the DEBUG Message is called twice, if I have two PDUs. This is
> working.
>
>
>
>
>
> *Right now I only have this:*
>
> PDU Protocol, Name2
>
> But it should be:
>
> PDU Protocol, Name1, Name2…
>
>
>
> I think there is a problem with losing the old frame information, because
> it is writing again PDU Protocol.
>
> Do you guys know what I’m missing?
>

Are you sure you are not calling col_clear(pinfo->cinfo, COL_INFO)
somewhere in your code?

Best regards,
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

Re: [Wireshark-dev] range_string checking

[Pascal Quantin]

Hi Martin,

Le jeu. 2 avr. 2020 à 23:08, Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> Hi,
>
> I have been adding checking to proto.c (that will be protected by #ifdef
> ENABLE_CHECK_FILTER) to see if range_string arrays passed
> into tmp_fld_check_assert() look sensible.
>

Nice.


> The checks I'm doing are:
> (1) it is a problem if the max is < min for any range_string
> (2) if an entry within an array is *completely* hidden by an earlier one,
> that is a problem (they are checked in the order they are given
> in try_rval_to_str_idx()
>
> It is common to have a 'catch-all' case for parts or all of the range,
> which is Ok if it comes after more specific entries.  I'm wondering if its
> worth complaining if *part* of an entry is hidden by an earlier one?
> Current output from master is as below.  I will try to fix them up where I
> can access the relevant specs, but wanted to check my understanding of how
> they work and how fussy we should be?  I will most likely update
> README.dissector to make sure it is clear how it is evaluated in order.
>

In my understanding having a part hidden by an earlier one should be an
error also.
I do have the GSM SMS and Diameter spec in hand so I will push a fix for
those ones.

BR,
Pascal.


> Best regards,
> Martin
>
> value_range_string error:  AVBTP Subtype (ieee1722.subtype) hidden by
> earlier entry (prev="Reserved for future protocols":  131 -> 237)
>  (this="ECC Signed Control Format":  236 -> 236)
> value_range_string error:  AVBTP Subtype (ieee1722.subtype) hidden by
> earlier entry (prev="Reserved for future protocols":  131 -> 237)
>  (this="ECC Encrypted Control Format":  237 -> 237)
> value_range_string error:  Quality of Service Delay class
> (diameter.3gpp.qos.delay_cls) entry for "Reserved" - max(0) is less than
> min(7)
> value_range_string error:  Application Id (eiss.app_id) entry for "Signed
> Application" - max(16383) is less than min(16384)
> value_range_string error:  Nature of address indicator
> (gsm_map.locationnumber.nai) hidden by earlier entry (prev="spare":  112 ->
> 126)  (this="reserved for national use":  112 -> 126)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)
>  (this="Telematic interworking not supported":  128 -> 128)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)  (this="Short
> message Type 0 not supported":  129 -> 129)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)  (this="Cannot
> replace short message":  130 -> 130)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)
>  (this="Reserved":  131 -> 142)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)
>  (this="Unspecified TP-PID error":  143 -> 143)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="TP-PID errors":  128 -> 143)
>  (this="Reserved":  131 -> 142)
> value_range_string error:  TP-Failure-Cause (TP-FCS) (gsm_sms.tp-fcs)
> hidden by earlier entry (prev="Reserved":  131 -> 142)  (this="Reserved":
>  131 -> 142)
> value_range_string error:  Message Type (hislip.messagetype) hidden by
> earlier entry (prev="FatalError":  2 -> 3)  (this="Error":  3 -> 3)
> value_range_string error:  Notify Message Type (isakmp.notify.msgtype)
> hidden by earlier entry (prev="RESERVED":  15 -> 16)  (this="RESERVED":  15
> -> 16)
> value_range_string error:  Type of delayed charging information
> (isup.japan.charge_delay_type) hidden by earlier entry (prev="Reserved for
> network specific use":  1 -> 252)  (this="Spare":  129 -> 250)
> value_range_string error:  Type (nan.ranging_setup.type) entry for
> "Response" - max(0) is less than min(1)
> value_range_string error:  Type (nan.ranging_setup.type) entry for
> "Termination" - max(0) is less than min(2)
> value_range_string error:  destination_offset (optommp.destination_offset)
> hidden by earlier entry (prev="Wiegand Serial Event Configuration -
> Read/Write":  4048945152 -> 4059434879)  (this="SNAP High-Density Digital -
> Read Only":  4051730432 -> 4051738622)
> value_range_string error:  destination_offset (optommp.destination_offset)
> hidden by earlier entry (prev="Wiegand Serial Event Configuration -
> Read/Write":  4048945152 -> 4059434879)  (this="SNAP High-Density Digital
> Read and Clear - Read/Write":  4051738624 -> 4051746814)
> value_range_string error:  destination_offset (optommp.destination_offset)
> hidden by earlier entry (prev="Wiegand Serial Event Configuration -
> Read/Write":  4048945152 -> 4059434879)  (this="SNAP High-Density Digital
> Write - Read/Write":  4051746816 -> 4051747838)
> value_range_string 

Re: [Wireshark-dev] Build without LUA fails

[Pascal Quantin]

Hi Dario,
Le ven. 27 mars 2020 à 18:10, Dario Lombardo  a écrit :

> On Thu, Mar 19, 2020 at 9:09 AM Pascal Quantin 
> wrote:
>
>>
>> Note that the previous patch was incomplete. Lines 103 and 108 must be
>> changed also. See https://code.wireshark.org/review/#/c/36494/
>>
>>
> Should have it fixed the compilation when lua is installed but disabled
> through ENABLE_LUA=0?
> I am in this configuration and the compilation fails.
>

No and the file I changed does not care about ENABLE_LUA that is handled in
CMakeLists.txt. I guess in this file, wherever you have if (LUA_FOUND) you
should replace it by if (LUA_FOUND AND ENABLE_LUA) and retest.

Best regards,
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

Re: [Wireshark-dev] Build failure (kerberos)

[Pascal Quantin]

Le lun. 23 mars 2020 à 09:17, Dario Lombardo  a écrit :

>
>
> On Sun, Mar 22, 2020 at 6:15 PM Dario Lombardo  wrote:
>
>> Ok, thanks.
>>
>> On Sun, Mar 22, 2020 at 9:48 AM Martin Mathieson <
>> martin.r.mathie...@googlemail.com> wrote:
>>
>>>
> ./asn1/kerberos/packet-kerberos-template.c: In function
> ‘dissect_krb5_PAC_CREDENTIAL_INFO’:
> ./asn1/kerberos/packet-kerberos-template.c:2187:2: error: implicit
> declaration of function ‘decrypt_krb5_data’
> [-Werror=implicit-function-declaration]
> ./asn1/kerberos/packet-kerberos-template.c:2187:11: error: assignment
> makes pointer from integer without a cast [-Werror]
> ./asn1/kerberos/packet-kerberos-template.c: At top level:
> ./asn1/kerberos/kerberos.cnf:360:1: error:
> ‘dissect_kerberos_PA_ENC_TS_ENC’ defined but not used
> [-Werror=unused-function]
>
>
>> I don't know which part of the asn1/cnf/template generates this function.
>> Can anyone guide me through the asn1 dissector generation process?
>>
>
> I've found how to remove the definition of the function conditionally.
> However the definition of
>
> static const ber_sequence_t PA_ENC_TS_ENC_sequence[]
>
> still remains unused, giving an error. Which part of the cnf generates
> this definition?
>

Hi Dario,

this is generated automatically unless you put PA-ENC-TS-ENC in the
OMIT_ASSIGNMENT section.
As asn2wrs.py does not support conditional generation AFAIK, better move it
in the template file (together with its dependencies) and add it to the
OMIT_ASSIGNMENT.

Best regards,
Pascal.

-- 
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
diff --git a/epan/dissectors/asn1/kerberos/kerberos.cnf b/epan/dissectors/asn1/kerberos/kerberos.cnf
index 4a7e623336..3dbfe7c1be 100644
--- a/epan/dissectors/asn1/kerberos/kerberos.cnf
+++ b/epan/dissectors/asn1/kerberos/kerberos.cnf
@@ -59,6 +59,7 @@ KrbFastResponse
 KrbFastFinished
 FastOptions
 KerberosFlags
+PA-ENC-TS-ENC
 
 #.NO_EMIT ONLY_VALS
 Applications
diff --git a/epan/dissectors/asn1/kerberos/packet-kerberos-template.c b/epan/dissectors/asn1/kerberos/packet-kerberos-template.c
index a53f1c3f62..0c3cfccacb 100644
--- a/epan/dissectors/asn1/kerberos/packet-kerberos-template.c
+++ b/epan/dissectors/asn1/kerberos/packet-kerberos-template.c
@@ -107,7 +107,6 @@ static dissector_handle_t kerberos_handle_udp;
 static int dissect_kerberos_Applications(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
 static int dissect_kerberos_AuthorizationData(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
 static int dissect_kerberos_PA_ENC_TIMESTAMP(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
-static int dissect_kerberos_PA_ENC_TS_ENC(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
 static int dissect_kerberos_PA_PAC_REQUEST(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
 static int dissect_kerberos_PA_S4U2Self(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
 static int dissect_kerberos_PA_S4U_X509_USER(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_);
@@ -271,7 +270,6 @@ kerberos_is_win2k_pkinit(asn1_ctx_t *actx)
 
 	return private_data->is_win2k_pkinit;
 }
-
 #ifdef HAVE_KERBEROS
 
 /* Decrypt Kerberos blobs */
@@ -302,6 +300,20 @@ read_keytab_file_from_preferences(void)
 
 	read_keytab_file(last_keytab);
 }
+
+static const ber_sequence_t PA_ENC_TS_ENC_sequence[] = {
+  { _kerberos_patimestamp, BER_CLASS_CON, 0, 0, dissect_kerberos_KerberosTime },
+  { _kerberos_pausec , BER_CLASS_CON, 1, BER_FLAGS_OPTIONAL, dissect_kerberos_Microseconds },
+  { NULL, 0, 0, 0, NULL }
+};
+
+static int
+dissect_kerberos_PA_ENC_TS_ENC(gboolean implicit_tag _U_, tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_) {
+  offset = dissect_ber_sequence(implicit_tag, actx, tree, tvb, offset,
+   PA_ENC_TS_ENC_sequence, hf_index, ett_kerberos_PA_ENC_TS_ENC);
+
+  return offset;
+}
 #endif /* HAVE_KERBEROS */
 
 #if defined(HAVE_HEIMDAL_KERBEROS) || defined(HAVE_MIT_KERBEROS)
@@ -2144,7 +2156,7 @@ dissect_krb5_PAC_LOGON_INFO(proto_tree *parent_tree, tvbuff_t *tvb, int offset,
 	return offset;
 }
 
-
+#ifdef HAVE_KERBEROS
 static int
 

Re: [Wireshark-dev] Dissectors with the same abbreviation

[Pascal Quantin]

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?

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

Re: [Wireshark-dev] Build without LUA fails

[Pascal Quantin]

Le jeu. 19 mars 2020 à 08:54, Anders Broman  a
écrit :

>
>
>
>
> *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 <
> 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>
> >
&g

Re: [Wireshark-dev] User's guide to French

[Pascal Quantin]

Hi Jérémie,

Le mar. 17 mars 2020 à 15:49, J?r?mie Denis  a
écrit :

> Hello,
>
>
>
> Have you this even guide in French?
>

Sorry, we do not.

Best regards,
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

Re: [Wireshark-dev] Build without LUA fails

[Pascal Quantin]

Hi Anders,

Le mar. 17 mars 2020 à 10:02, Anders Broman via Wireshark-dev <
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/>
>
>extcap remote SSH interfaces (sshdump, ciscodump)
>
> * Systemd, System and Service Manager (libraries), <
> https://freedesktop.org/wiki/Software/systemd/>
>
>   Support for systemd journal extcap interface (sdjournal)
>
> * MaxMindDB, C library for the MaxMind DB file format, <
> https://github.com/maxmind/libmaxminddb>
>
>Support for GeoIP lookup
>
> * SMI
>
> * Minizip, C library for supporting zip/unzip functionality, <
> https://www.winimage.com/zLibDll/minizip.html>
>
>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, <
> https://google.github.io/snappy/>
>
>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/>
>
>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>
>
>Support for G.722 and G.726 codecs in RTP player
>
> * BCG729, G.729 decoder, <
> https://www.linphone.org/technical-corner/bcg729/overview>
>
>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?
>

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/cmake/modules/FindLUA.cmake
@@ -84,7 +84,7 @@ find_package_handle_standard_args(LUA
   REQUIRED_VARS LUA_LIBRARY LUA_INCLUDE_DIR LUA_VERSION_NUM
   VERSION_VAR   LUA_VERSION_NUM)

-IF(LUA_LIBRARY)
+IF(LUA_FOUND)
   SET( LUA_LIBRARIES "${LUA_LIBRARY}")
   SET( LUA_INCLUDE_DIRS ${LUA_INCLUDE_DIR} )
   if (WIN32)

Best regards,
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

Re: [Wireshark-dev] [Wireshark-commits] wireshark-win64-libs rev 635: / /trunk/packages/: npcap-0.9987.exe npcap-0.9988.exe /trunk/: README.txt

[Pascal Quantin]

Hi Chris,

Le lun. 16 mars 2020 à 23:47, Maynard, Chris via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

> "Rather serious memory leak in Npcap 0.9988. Consider reverting to 0.9987
> until the next release. Thanks! "
> Ref: https://twitter.com/bonsaiviking/status/1239297302361247749


We saw the notice and so far considered that reverting was not necessary as
it is only in master branch, that hopefully the next release should be
available ASAP, and that anybody can do it manually (Wireshark will not
propose to install an older release that the one currently installed
anyway).
If there is a consensus to do the revert it can be done easily but still
the users would have to do the downgrade manually (unless we want to hack
the NSIS installer, which seems overkill to me given that only nightly
builds are impacted).

Best regards,
Pascal.


>
> -Original Message-
> From: Wireshark-commits  On
> Behalf Of pas...@wireshark.org
> Sent: Saturday, March 7, 2020 5:42 AM
> To: wireshark-comm...@wireshark.org
> Subject: [Wireshark-commits] wireshark-win64-libs rev 635: /
> /trunk/packages/: npcap-0.9987.exe npcap-0.9988.exe /trunk/: README.txt
>
> User: pascal
> Date: 2020/03/07 10:42 AM
>
> Log:
>  Upgrade Npcap to 0.9988
>
> Directory: /trunk/packages/
>   ChangesPathAction
>   +0 -0  npcap-0.9987.exeRemoved
>   +0 -0  npcap-0.9988.exeAdded
>
> Directory: /trunk/
>   ChangesPath  Action
>   +1 -1  README.txtModified
>
> ___
> Sent via:Wireshark-commits mailing list <
> wireshark-comm...@wireshark.org>
> Archives:https://www.wireshark.org/lists/wireshark-commits
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-commits
>  mailto:wireshark-commits-requ...@wireshark.org
> ?subject=unsubscribe
>
>
>
>
>
>
>
>
>
>
>
> 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

Re: [Wireshark-dev] Wireshark wiki on portable aps

[Pascal Quantin]

Hi Anders

Le lun. 16 mars 2020 à 13:57, Anders Broman via Wireshark-dev <
wireshark-dev@wireshark.org> a écrit :

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

According to
https://buildbot.wireshark.org/wireshark-master/builders/Windows%20Server%202019%20x86/builds/1155/steps/compile_7/logs/stdio
the target name is portableapps_package.vcxproj

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

Re: [Wireshark-dev] Cmake on windows

[Pascal Quantin]

Le ven. 6 mars 2020 à 14:02, Dario Lombardo  a écrit :

>
>
> On Fri, Mar 6, 2020 at 12:44 PM Pascal Quantin 
> wrote:
>
>>
>>
>> Le ven. 6 mars 2020 à 12:28, Dario Lombardo  a écrit :
>>
>>> I am sorry, I still don't understand, I beg your pardon.
>>> You said
>>>
>>> > your machine does not have the MSVC redistributable copied in the
>>> wireshark-libs folder (as explained in the developer guide) while it is
>>> required for the NSIS installer.
>>>
>>> But I cannot find any point in the developer guide where it is explained
>>> that the MSVC redistributable has to be copied somewhere, nor I know how to
>>> do it myself without a more detailed explanation.
>>>
>>
>> This is why I said it used to be more visible in the documentation .
>> We used to have to download vcredist_x86.exe or vcredist_x64.exe from
>> Microsoft website and copy it in the Wireshark-win32-libs or
>> Wireshark-win64-libs folder. It is no more required because the
>> redistributables are bundled in the MSVC 2019 community edition (for
>> example mine is located by CMake in C:/Program Files (x86)/Microsoft Visual
>> Studio/2019/Community/VC/Redist/MSVC/14.24.28127).
>>
>> I now realize that you have 2 errors: one about the VCINSTALLDIR (root
>> cause of your NSIS issue) and one about MERGE_MODULE_DIR (for WiX). Sorry
>> for not seeing this earlier.
>>
>> As found in our CMakeLists.txt file:
>>
>> # Try to find the Redist folder in VCINSTALLDIR which is set by
>> vcvarsall.bat.
>> # If it is not set, query it within the registry. VS2015 looks for the
>> "VC7" key
>> # in two locations (four if you count HKCU instead of HKLM). However,
>> VS2017
>> # does not use "VC7" (it sets a directory relative to
>> vsdevcmd_start.bat). As
>> # both versions do set "VS7", use that instead.
>> find_path(VCINSTALLDIR Redist PATHS
>> "$ENV{VCINSTALLDIR}"
>>
>> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\SxS\\VS7;${_msvs_version}]\\VC"
>>
>> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\VisualStudio\\SxS\\VS7;${_msvs_version}]\\VC"
>> NO_DEFAULT_PATH
>> )
>> file(TO_NATIVE_PATH "${VCINSTALLDIR}" VCINSTALLDIR_NATIVE)
>> message(STATUS "Using VCINSTALLDIR: ${VCINSTALLDIR_NATIVE}")
>>
>> That's what Gerald indicated in his message.
>>
>> When I open the MSVC 2019 command prompt, and type 'set VCINSTALLDIR', I
>> get as expected:
>> VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\
>>
>> What do you get?
>>
>>
> Unfortunately the builder doesn't print anything with that command
>
>
> https://github.com/crondaemon/wireshark/runs/490180639?check_suite_focus=true
>
> see the "set" step.
>

Si it seems like it is not running the MSVC 2019 command prompt that takes
care of setting the various environment variables.
___
Sent via:Wireshark-dev mailing list 
Archives: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] Cmake on windows

[Pascal Quantin]

Le ven. 6 mars 2020 à 12:28, Dario Lombardo  a écrit :

> I am sorry, I still don't understand, I beg your pardon.
> You said
>
> > your machine does not have the MSVC redistributable copied in the
> wireshark-libs folder (as explained in the developer guide) while it is
> required for the NSIS installer.
>
> But I cannot find any point in the developer guide where it is explained
> that the MSVC redistributable has to be copied somewhere, nor I know how to
> do it myself without a more detailed explanation.
>

This is why I said it used to be more visible in the documentation .
We used to have to download vcredist_x86.exe or vcredist_x64.exe from
Microsoft website and copy it in the Wireshark-win32-libs or
Wireshark-win64-libs folder. It is no more required because the
redistributables are bundled in the MSVC 2019 community edition (for
example mine is located by CMake in C:/Program Files (x86)/Microsoft Visual
Studio/2019/Community/VC/Redist/MSVC/14.24.28127).

I now realize that you have 2 errors: one about the VCINSTALLDIR (root
cause of your NSIS issue) and one about MERGE_MODULE_DIR (for WiX). Sorry
for not seeing this earlier.

As found in our CMakeLists.txt file:

# Try to find the Redist folder in VCINSTALLDIR which is set by
vcvarsall.bat.
# If it is not set, query it within the registry. VS2015 looks for the
"VC7" key
# in two locations (four if you count HKCU instead of HKLM). However, VS2017
# does not use "VC7" (it sets a directory relative to vsdevcmd_start.bat).
As
# both versions do set "VS7", use that instead.
find_path(VCINSTALLDIR Redist PATHS
"$ENV{VCINSTALLDIR}"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\SxS\\VS7;${_msvs_version}]\\VC"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\VisualStudio\\SxS\\VS7;${_msvs_version}]\\VC"
NO_DEFAULT_PATH
)
file(TO_NATIVE_PATH "${VCINSTALLDIR}" VCINSTALLDIR_NATIVE)
message(STATUS "Using VCINSTALLDIR: ${VCINSTALLDIR_NATIVE}")

That's what Gerald indicated in his message.

When I open the MSVC 2019 command prompt, and type 'set VCINSTALLDIR', I
get as expected:
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\

What do you get?


> On Fri, Mar 6, 2020 at 12:20 PM Pascal Quantin 
> wrote:
>
>> Hi Dario,
>>
>> Le ven. 6 mars 2020 à 12:16, Dario Lombardo  a écrit :
>>
>>> Hi Pascal
>>> I'm not sure I got the point. I try to explain what I understand. I have
>>> one single build, that may have multiple problems, some trivial, some not.
>>> The error I see in cmake could be ignored, while the one that counts is the
>>> fact I need the MSVC redistributable in the wireshark-lib folder.
>>> Am I correct?
>>>
>>
>> Yes if you do not have a step building the WiX installer (which seems to
>> be the case).
>>
>>
>>>
>>>>> Joao is correct: on one side you have a non fatal error in CMake that
>>>> only impacts the WiX installer, and in the other side your machine does not
>>>> have the MSVC redistributable copied in the wireshark-libs folder (as
>>>> explained in the developer guide) while it is required for the NSIS
>>>> installer.
>>>>
>>>> Can you link the devel guide where it's explained? I just found
>>>
>>>
>>> https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBinary.html#ChSrcNSIS
>>>
>>
>> https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
>>
>> In the past it used to be more visible if I remember correctly.
>>
>> BR,
>> 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
>
>
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Cmake on windows

[Pascal Quantin]

Hi Dario,

Le ven. 6 mars 2020 à 12:16, Dario Lombardo  a écrit :

> Hi Pascal
> I'm not sure I got the point. I try to explain what I understand. I have
> one single build, that may have multiple problems, some trivial, some not.
> The error I see in cmake could be ignored, while the one that counts is the
> fact I need the MSVC redistributable in the wireshark-lib folder.
> Am I correct?
>

Yes if you do not have a step building the WiX installer (which seems to be
the case).


>
>>> Joao is correct: on one side you have a non fatal error in CMake that
>> only impacts the WiX installer, and in the other side your machine does not
>> have the MSVC redistributable copied in the wireshark-libs folder (as
>> explained in the developer guide) while it is required for the NSIS
>> installer.
>>
>> Can you link the devel guide where it's explained? I just found
>
> https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBinary.html#ChSrcNSIS
>

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

In the past it used to be more visible if I remember correctly.

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

Re: [Wireshark-dev] Cmake on windows

[Pascal Quantin]

Hi Dario,

Le ven. 6 mars 2020 à 11:30, Dario Lombardo  a écrit :

> No, it's the same. Have a look at the cmake section and you will see the
> error messages below.
>

Joao is correct: on one side you have a non fatal error in CMake that only
impacts the WiX installer, and in the other side your machine does not have
the MSVC redistributable copied in the wireshark-libs folder (as explained
in the developer guide) while it is required for the NSIS installer.


> On Fri, Mar 6, 2020 at 10:54 AM João Valverde <
> joao.valve...@tecnico.ulisboa.pt> wrote:
>
>>
>>
>> On 06/03/20 08:23, Dario Lombardo wrote:
>>
>> Example of failing build
>>
>>
>> https://github.com/crondaemon/wireshark/runs/489648430?check_suite_focus=true
>>
>>
>> A quick look suggests this is a different build than you indicated
>> before, for an NSIS package, and the problem seems to be that the VC_REDIST
>> exe is missing.
>>
>>
>> On Fri, Mar 6, 2020 at 9:07 AM Dario Lombardo  wrote:
>>
>>> Are you saying "set v"? It doesn't print anything.
>>> The installation of VS is pre-made by the github builder itself, not by
>>> me, hence I don't have any control over the installation options. However I
>>> guess every component is in place, and maybe I just need to add the proper
>>> dir to the PATH. What do you think?
>>>
>>> On Thu, Mar 5, 2020 at 9:36 PM Gerald Combs 
>>> wrote:
>>>
 On 3/5/20 7:27 AM, Dario Lombardo wrote:
 > Hi,
 > I'm getting this output from a windows build
 >
 > -- Using VCINSTALLDIR: VCINSTALLDIR-NOTFOUND
 > -- Using MERGE_MODULE_DIR-NOTFOUND\Microsoft_VC142_CRT_x64.msm for
 the WiX installer
 > -- Configuring done
 > -- Generating done
 > -- Build files have been written to: D:/a/wireshark/wireshark/build
 >
 > What's going wrong? The rest of the output looks good.

 VCINSTALLDIR should have been set by Visual Studio, e.g. by
 vcvarsall.bat. What does `set v` show?

 ___
 Sent via:Wireshark-dev mailing list 
 Archives: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.
>>>
>>>
>>
>> --
>>
>> Naima is online.
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list  
>> 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
>> 
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
>
> --
>
> Naima is online.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Sime Diameter messages doesn't shown at new versions

[Pascal Quantin]

Hi Iman,

Le mar. 3 mars 2020 à 20:18, Iman Mohammadi <
iman.mohammadi.tele...@gmail.com> a écrit :

> Hi All,
>
> I have a problem for checking Diameter messages in wireshark at new
> versions,some Diameter messages just shown as TCP or SCTP packets as below
> in new versions,but at old versions it's normal and shown,there is any
> setting for it or it's a bug?(sorry for pictures)
>

Try unchecking the TCP option "do not call subdissectors for error packets".
And in the future please do not send 7MB pictures to the mailing list, this
is not a good idea at all. Either reduce their size or post a link.
Of course we prefer capture files (anonymized with TraceWrangler for
example) rather than pictures.

Best regards,
Pascal.


> Thanks in advanced
>
> Old Version: 1.12.1
>
>
>
>
> Best Regards
> Iman Mohammadi
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] how to add global per-capture state?

[Pascal Quantin]

Hi Aurélien,

Le lun. 24 févr. 2020 à 15:40, Aurélien Aptel  a écrit :

> Hi,
>
> I'm working on the SMB2 dissector (packet-smb2.c) and I'd like to have
> better support for multichannel where an authenticated session is shared
> across TCP sessions.
>
> So at the moment, we store a hashtable in the conversation. That table
> maps SessionId => Session Data
>
> When a new channel is opened for that session it will share the same ID
> but since it's a different TCP connection, it will be in a different
> conversation so we won't be able to lookup the existing Session Data.
>
> The solution would be to make the SessionID=>SessionData hashtable
> global per-capture instead of per-conversation.
>
> How is this usually done in a Wireshark dissector?
>
> I was thinking of having a global static hashtable in the dissector but
> then I would need to reset it when the capture is opened/closed...
>

You can have a look at the dissectors using
wmem_map_new_autoreset(wmem_epan_scope(), wmem_file_scope(), ...) which
defines a hash table that is automatically reset each time you open a new
file (or reload the current one).

Best regards,
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

Re: [Wireshark-dev] Feedback on Developer's Guide 3.3.0

[Pascal Quantin]

Hi David,

Le mer. 19 févr. 2020 à 17:47, Boyce, David  a
écrit :

> Hi,
>
>
>
> I notice that the developer’s guide does not appear to have any Wireshark
> C API Reference Manual equivalent to the Lua API Reference Manual of
> Chapter 11.  Given that 1.4.1 emphasises that ‘(almost) any dissector is
> written in plain old ANSI C’, this seems to be a strange omission.  Is
> there a good reason for this?
>

You have a lot of documentation in the doc/ folder of the Wireshark source
code. I guess the fact that it is located here and not in the developer's
guide is a mix of legacy and that, to build a C dissector, you need to have
Wireshark source code anyway (which is not the case for Lua).

Best regards,
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