Re: [Wireshark-dev] Patch submission via e-mail/mailing list

[Jaap Keuter]

Hi Bruno,

Indeed GitLab is currently the preferred way of working, so this is going in 
the right direction.

Good luck,
Jaap

> On 4 Jun 2024, at 17:29, Bruno Mauricio  
> wrote:
> 
> Alexis started pointing out some typos there, so I fixed them promptly.
> 
> Noone said anything but I guess it's better to finish up via gitlab.
> 
> Thank you very much for your support guys :)
> 
> Best regards,
> 
> Bruno Mauricio
> 
> On 6/4/24 4:14 PM, chuck c wrote:
>> https://gitlab.com/wireshark/wireshark/-/merge_requests/15850
>> 
>> Looks like there is work being done via the standard process?
>> 
>> On Tue, Jun 4, 2024 at 8:28 AM Bruno Mauricio via Wireshark-dev 
>> mailto:wireshark-dev@wireshark.org>> wrote:
>>> Hello again,
>>> 
>>> Just as I sent my previous e-mail, I got a confirmation from gitlab 
>>> about false flagging my account, which got reinstated and my Merge 
>>> Request reappeared.
>>> 
>>> Should we proceed via e-mails and I close the MR, or via the normal 
>>> procedure?
>>> 
>>> Apologies for the noise/spam,
>>> 
>>> Bruno Mauricio
>>> 
>>> 
>>> On 6/4/24 2:22 PM, Bruno Mauricio via Wireshark-dev wrote:
>>> > Thank you very much for your reply,
>>> >
>>> >
>>> > I have attached the patch for Zigbee NCP dissector update in wireshark.
>>> >
>>> > I also attached a pcap which contains the added packets.
>>> >
>>> > Running wireshark (without the patch) shows a bunch of "Unknown Call 
>>> > ID" for packets which are now present with the patch.
>>> >
>>> > In case there is any issue please feel free to contact me directly, if 
>>> > you prefer not to spam this mailing list with those messages.
>>> >
>>> >
>>> > Best regards,
>>> >
>>> > Bruno Mauricio
>>> >
>>> >
>>> > On 6/4/24 2:03 PM, Jaap Keuter wrote:
>>> >> Hi,
>>> >>
>>> >> First of all, sorry that GitLab gives you grief. Please do follow up 
>>> >> on the ticket, they usually seem to be open to address such issues 
>>> >> AFIACT.
>>> >>
>>> >> As for the patch, this used to be the channel through which these 
>>> >> were collected, before GitLab^WGerrit^WBugzilla.
>>> >> So please go ahead and attach one here, and we’ll see what we can do.
>>> >>
>>> >> Thanks,
>>> >> Jaap
>>> >>
>>> >>
>>> >>> On 4 Jun 2024, at 12:48, Bruno Mauricio via Wireshark-dev 
>>> >>> mailto:wireshark-dev@wireshark.org>> 
>>> >>> wrote:
>>> >>>
>>> >>> Hello,
>>> >>>
>>> >>>
>>> >>> I created a Gitlab account just to send a patch for wireshark but it 
>>> >>> was banned a few minutes after I created the Merge Request.
>>> >>>
>>> >>> I tried creating a different account using gmail (and not this work 
>>> >>> e-mail, thought that might be the issue) but as soon as I input my 
>>> >>> phone number, it got banned as well. My number must have been 
>>> >>> flagged for some reason.
>>> >>>
>>> >>> I already opened a ticket but assume it will be some time until I 
>>> >>> get an answer back.
>>> >>>
>>> >>> In the meantime, what would be the better approach to submitting a 
>>> >>> patch without a gitlab account?
>>> >>>
>>> >>> Is this mailing list, or perhaps the Wireshark-commits mailing list 
>>> >>> appropriate for uploading a patch for review?
>>> >>>
>>> >>> Or should I sent it directly to a maintainer and if so to which 
>>> >>> e-mail address?
>>> >>>
>>> >>>
>>> >>> Thank you for your attention.
>>> >>>
>>> >>> Best regards,
>>> >>>
>>> >>> Bruno Mauricio
>>> >
>>> > ___
>>> > Sent via:Wireshark-dev mailing list >> > <mailto:wireshark-dev@wireshark.org>>
>>> > Archives:https://www.wireshark.org/lists/wireshark-dev
>>> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>> >   mailto:wireshark-dev-requ...@wireshark.org 
>>> > <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
>>> ___
>>> Sent via:Wireshark-dev mailing list >> <mailto:wireshark-dev@wireshark.org>>
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org 
>>> <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
>> 
>> 
>> ___
>> Sent via:Wireshark-dev mailing list  
>> <mailto:wireshark-dev@wireshark.org>
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives: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] Patch submission via e-mail/mailing list

[Jaap Keuter]

Hi,

First of all, sorry that GitLab gives you grief. Please do follow up on the 
ticket, they usually seem to be open to address such issues AFIACT.

As for the patch, this used to be the channel through which these were 
collected, before GitLab^WGerrit^WBugzilla.
So please go ahead and attach one here, and we’ll see what we can do.

Thanks,
Jaap


> On 4 Jun 2024, at 12:48, Bruno Mauricio via Wireshark-dev 
>  wrote:
> 
> Hello,
> 
> 
> I created a Gitlab account just to send a patch for wireshark but it was 
> banned a few minutes after I created the Merge Request.
> 
> I tried creating a different account using gmail (and not this work e-mail, 
> thought that might be the issue) but as soon as I input my phone number, it 
> got banned as well. My number must have been flagged for some reason.
> 
> I already opened a ticket but assume it will be some time until I get an 
> answer back.
> 
> In the meantime, what would be the better approach to submitting a patch 
> without a gitlab account?
> 
> Is this mailing list, or perhaps the Wireshark-commits mailing list 
> appropriate for uploading a patch for review?
> 
> Or should I sent it directly to a maintainer and if so to which e-mail 
> address?
> 
> 
> Thank you for your attention.
> 
> Best regards,
> 
> Bruno Mauricio

___
Sent via:Wireshark-dev mailing list 
Archives: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 Developer's Guide feedback

[Jaap Keuter]

Hi,

Thank you. I've created MR 15081 
 to address most 
of these concerns. I leave to update to the text the someone more in tune with 
the Lua API, I'm not sure what the best way to document this polymorphic beast is.


Thanks,
Jaap


On 3/29/24 7:23 PM, Krefta, Oliver O. - US via Wireshark-dev wrote:

Hi,

I've been using the Wireshark Developer's Guide ( 
https://www.wireshark.org/docs/wsdg_html/ 
  ) as a reference for developing a 
dissector using the Lua API. In doing so, I noticed a few potential errors in 
the documentation and wanted to give feedback.


Section 11.6.2.5
My understanding is that tvb:reported_length_remaining() takes an optional 
parameter specifying an offset. My own testing seems to confirm this. However 
the function is documented as taking no parameters.


Section 11.7
This section seems to have some formatting issues. Several of the documented 
API functions are children of the "Example" subsection 11.7.2 when they should 
be contained in the "TreeItem" subsection 11.7.1.
Additionally, the documentation for treeitem:add() and similar functions have 
mismatched brackets in the sentence:


This function has a complicated form: 'treeitem:add([protofield,]
[tvbrange,] value], label)', such that ...

(In fact that whole paragraph is a bit confusing to understand).


Hopefully you find this useful in improving the documentation.

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

[Wireshark-dev] Tracking branches, GitHub and Launchpad

[Jaap Keuter]

Hi,

A few observations which probably needs attention.

1. The GitHub mirror is picking up all our cherry-pick branches, which now run 
in the hundreds.
IMHO, these should not be mirrored in the first place.
How can we clean this up?

2. Launchpad upstream repo mirrors of GitHub. 
IMHO, it should mirror from GitLab.

3. The Launchpad mirror has all these cherrypick branches also.
IMHO, these should not be mirrored in the first place.
How can we clean this up?

Regards,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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 handles SCTP association indexing wrong under some circumstances -- multi-homing is wrongly reported where there is none

[Jaap Keuter]

Hi,

With what Wireshark version in this? And a (synthetic) sample capture would go 
a long way investigating this.

Thanks,
Jaap


> On 6 Dec 2023, at 12:08, Ariel Burbaickij  wrote:
> 
> Hello all,
> 
> we have a special setup here: SS7 E1 is converted to SCTP traffic with the 
> following basic schema (I cannot share capture itself, just in case):
> -- there are no INITs, HEARTBEATs/ACK, SACKs, just DATA chunks sent in both 
> directions as containers then for the traffic on higher layers .
> --each linkset, of which there are many, is represented like this:
>   1.1.1.1 <-> 2.2.2.2
>   3.3.3.3 <-> 4.4.4.4
>   5.5.5.5 <-> 6.6.6.6
>   etc.
> so, that one and the same IP address is never re-used for several 
> associations and <-> means bidirectional traffic. All associations use the 
> same port 2904 on both sides.
> 
> 
> vtags used per direction are last two bytes of the source IP in the least 
> significant bytes of vtag field, so for the second association it is:
> 
> 0x0303 from 3.3.3.3 to 4.4.4.4
> and
> 0x0404 from 4.4.4.4 to 3.3.3.3
> etc. 
> 
> and TSNs are verified to be accurate too.
> 
> Now, upon selecting the packet from, say  3.3.3.3 to 4.4.4.4 and "Analyse 
> this Association", we get multi-homed association reported with always larger 
> vtag reported as part of association, so as a matter of example:
> 
> Endpoint 1 is 1.1.1.1 and 3.3.3.3 (vtag 0x0303)
> Endpoint 2 is  2.2.2.2 and 4.4.4.4 (vtag 0x0404)
> 
> so, why does analysis fail here, where it should not ?
> 
> Kind Regards
> Ariel Burbaickij
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Wireshark-dev] The If_fcslen option unit mismatch

[Jaap Keuter]

Hi,

There’s a recent issue raised on a mismatch between the pcapng spec and 
Wireshark interpretation of it. The issue revolves around the unit used for the 
If_fcslen option in the pcapng file format.
The Wireshark issue is here: 
https://gitlab.com/wireshark/wireshark/-/issues/19174
Apparently this was already identified in 2019, by Guy in the pcapng 
specification.
The pcapng issue is here: 
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/issues/60
However, this was never resolved, as in, a conclusion was never reached.
How should we progress with this, now that it has become a noticed problem? 
Guy, do you have additional insights since the initial report from 2019?

Thanks,
Jaap
___
Sent via:Wireshark-dev mailing list 
Archives: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] Remove GPL (v3 or later) (with Bison parser exception) from our allowed license list?

[Jaap Keuter]

Hi,

It sounds like a reasonable choice to drop a (niche) unused licence.

Thanks,
Jaap


> On 8 Oct 2023, at 23:49, Gerald Combs  wrote:
> 
> Hi all,
> 
> We currently have "GPL (v3 or later) (with Bison parser exception)" in the 
> list of allowed licenses in checklicenses.py. Presumably that was because we 
> shipped Bison-generated code at one time. However, our last .y file was 
> removed in 2020 in f21cd2e23f and I can't find any code in our repository or 
> in our dependencies that uses this particular license. Does anyone object to 
> removing it from our allow list?

___
Sent via:Wireshark-dev mailing list 
Archives: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] 4.2.0 release schedule

[Jaap Keuter]

Hi,

This starts to resemble the Linux kernel merge window challenges. There's always 
a tradeoff between ease of development vs. churn. Things do need to settle down

before a branch can be made, that's what we're here for.

Personally I'm in the process of finalizing a new dissector (for iperf3) and 
extending another (RTP headers in SAToP). That's my target for 4.2. Not an issue 
to double submit, just a bit more hassle.


Jaap

On 9/16/23 01:02, João Valverde wrote:
I would like that. We can be liberal backporting changes to the 4.1 release, but 
some care should be taken to avoid very big or risky changes. Then for the 4.2 
release candidates, ideally only bugfixes would be backported.


On 9/15/23 22:51, Gerald Combs wrote:
I have no objections to creating the 4.2 branch earlier. As you point out, it 
mostly comes down to how much backporting we want to do. The release numbers 
are a reflection of the fact that "run tools/make-version.py -v ..." is in the 
new release branch checklist.


On 9/15/23 12:06 PM, João Valverde wrote:
Should 4.1 be developed on the release-4.2 branch already? Obviously it would 
require some backporting work from developers, but also provide some 
stability. Right now the 4.1 release is just a snapshot of master, so really 
4.1.x micro versions are meaningless.


There are some changes that might be too experimental to push on master right 
now, given that a stable release is right around the corner.


By creating the release-4.2 branch earlier, I think that problem could be 
avoided, and maybe also lead to a better 4.2 release.


Thoughts?

On 8/17/23 22:04, Gerald Combs wrote:

Hi all,

I'd like to start preparing for the creation of the release-4.2 branch and 
the 4.2.0 release. I've come up with the following tentative schedule, which 
will give us a couple of release candidates before SharkFest EU and a final 
release in November, after SharkFest:


Aug 24 : Release 4.1.0
Aug ?? : Release 4.1.1
Sep ?? : Release 4.1.2
Oct  2 : Create the release-4.2 branch
Oct  4 : Release 4.2.0rc1
Oct 18 : Release 4.2.0rc2
Oct 30 - Nov 3 : SharkFest EU. See you in Brussels!
Nov  8 : Release 4.2.0

If you need to delay any of the above, particularly the release-4.2 branch, 
please let me know.


New features and improvements in 4.2.0 will include:

- Packet list sorting performance improvements.

- "_ws.col." display filters.

- More display filter improvements, including raw byte matching (@field.name 
== 12:ab:23:cd).


- Some name resolution files (such as "manuf" and "services") are now 
compiled in, which reduces startup time.


- A built-in MAC address / OUI dialog.

- A Windows Arm64 installer.

Note that the release-3.6 branch is an LTS branch, so in accordance with 
https://wiki.wireshark.org/Development/LifeCycle we'll have three active 
release branches until May 2024.



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

[Wireshark-dev] SCTP statistics

[Jaap Keuter]

Hi,

Who knows what the current status of the SCTP statistics is? I’ve tried a few 
files, but couldn’t make sense of it. It looked like information was missing or 
not filled at all. 

Thanks,
Jaap

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

Re: [Wireshark-dev] About the DNS resolver

[Jaap Keuter]

Hi,

So, for 5.0, there would be a compile time option to choose c-ares or unbound, 
or are we considering a clean break?
If we keep both, which one would be considered default? I can imagine unbound 
when build support is present, otherwise c-ares?

Thanks,
Jaap


> On 21 Aug 2023, at 22:47, Gerald Combs  wrote:
> 
> Sounds fine to me. We had overlapping support for c-ares and ADNS for a 
> while, so this isn't new territory. Can you open an issue and set the 
> milestone to "Wireshark 5.x" so this doesn't get lost?
> 
> On 8/20/23 12:08 PM, Jaap Keuter wrote:
>> Hi,
>> So we’ve been using the c-ares name resolver for a while now and it’s 
>> serving its purpose.
>> However, this is not the only one out there. DNS technologies have evolved 
>> somewhat and c-ares does not provide for them.
>> Would it make sense to start looking into using libunbound[1] as a 
>> replacement for c-ares to bring these technologies in reach.
>> From a cursory look it seems that the current structure can be retained 
>> while shoehorning in unbound.
>> Thoughts? It could be something we could try to achieve for 5.0.
>> [1] https://nlnetlabs.nl/projects/unbound/about/
>> Jaap

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

[Wireshark-dev] About the DNS resolver

[Jaap Keuter]

Hi,

So we’ve been using the c-ares name resolver for a while now and it’s serving 
its purpose.
However, this is not the only one out there. DNS technologies have evolved 
somewhat and c-ares does not provide for them.
Would it make sense to start looking into using libunbound[1] as a replacement 
for c-ares to bring these technologies in reach.
From a cursory look it seems that the current structure can be retained while 
shoehorning in unbound.
Thoughts? It could be something we could try to achieve for 5.0.

[1] https://nlnetlabs.nl/projects/unbound/about/

Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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] add a BASE_DEFAULT_VALS

[Jaap Keuter]

Hi,

Use range_string rather than value_string.

Jaap

> On 14 Aug 2023, at 17:22, John Dill  wrote:
> 
> I've recently been doing a lot of enums that have multiple illegal values, 
> and the illegal value shouldn't be displayed as "Unknown" as it's hard coded 
> in proto.c (in 3.6.x).

___
Sent via:Wireshark-dev mailing list 
Archives: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] Help regarding CI failure in gitlab

[Jaap Keuter]

Hi,

Preliminary review comments you could address before making an MR:

- Recreate the files using the dissector boilerplate doc/packet-PROTOABBREV.c
- Get rid of the header file
- The PCAP doesn’t go into a commit, it has to got into either a protocol page 
on the wiki, or in Sample Captures on the wiki. You ca do that yourself.
- Change commit message header to “ PLDM: Adding dissector for Base 
Specification”, according to 
https://wiki.wireshark.org/Development/SubmittingPatches#writing-a-good-commit-message
 

- Get consistent value_string indentation
- Module static variables do not work, in the face of multiple conversation 
dissections and/or with packet random access.
- We do have BCD support for fields, see if that works.
- dissect_base() needs to be static
- dissector_add_uint("wtap_encap", 147, base_handle); looks suspicious, where’s 
147 coming from.
- No g_print() in the code

Hope it helps.


> On 27 Jul 2023, at 21:51, Riya Dixit  wrote:
> 
> Hi community,
> I am new to Wireshark development. I am trying to upstream my dissector. The 
> code works fine but why is the CI failing for all packages ( window×64, macos 
> arm and Intel). It is only passing for Windows MinGw. How do I debug this?
> This is the link to my CI -
> https://gitlab.com/riyadixitagra/wireshark-pldm/-/pipelines/913244896 
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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 ERROR While Running Cmake

[Jaap Keuter]

Hi,

It looks to me like you’re missing some required development packages. Not sure 
what environment you have, but you could refer to the setup scripts in the 
tools directory, e.g., arch-setup.sh

Regards

> On 30 May 2023, at 13:38, Anshula Singla  wrote:
> 
>  
>  
> Hi ,
>  
> Regarding I am facing multiple issue while building wireshark code  . while 
> running cmake facing issue snapped in snippet .
> Please find below snippet 
> 
>  
>  
> Please provide some fix for this issue .
>  
>  
>  
> Regards
> Anshula
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives: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] Wiki: Backporting A Change To A Release Branch

[Jaap Keuter]

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

Re: [Wireshark-dev] First 4 bytes in SNMP application data

[Jaap Keuter]

Hi,

What you’re looking at is the SNMP encoding according to the Basic Encoding 
Rules[2] (BER). These octets define the BER structure.

For example a 64 octet SNMPv3 message starts as such:

SNMPv3Message ::= SEQUENCE {

30 3E 

msgVersion INTEGER ( 0 .. 2147483647 ),

02 01 03

Where 30 defines a sequence, 3E the length, 02 an integer, 01 length of one and 
03 the version number.


[1] https://datatracker.ietf.org/doc/html/rfc3412#section-6 

[2] 
https://www.oss.com/asn1/resources/asn1-made-simple/asn1-quick-reference/basic-encoding-rules.html
 


Regards,
Jaap

> On 3 Mar 2022, at 06:33, Chandra Japan  wrote:
> 
> Hi Wireshark Team,
> 
> Please let me know 
> 
> what does first 4 bytes in SNMP Data indicate
> 
> because I could see from 5th byte I see version and other things
> 
> Regards
> Chandramohan
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Editor config and code formatting

[Jaap Keuter]

Hi,

As consistent formatting not always translates into readable formatting 
(although in many/most cases it does) I’m not in favour of forced automatic 
formatting.
And that is where great freedom comes with great responsibility. I’m already 
pleased if we can have a consistent style _per file_

I’ve created a mockup once, of a script calling uncrustify while adapting its 
configuration according to the modelines in the file. It works well, but 
readability sometimes suffers.

My €0.02



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

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

Re: [Wireshark-dev] On building better statistics

[Jaap Keuter]

> On 15 Feb 2022, at 13:20, João Valverde  wrote:
> 
> And also, it's not really correct to include IP inside ICMP as IP bytes, but 
> that's another issue entirely.

Looking at the Protocol Hierarchy statistics, only the ‘top level’ protocols 
are counted. So, an IP header in a ICMP packet don’t get added.

You can see that with IPv6, there you can choose to have the IPv6 extension 
headers under the root tree rather than under the IPv6 packet. If you put them 
under the root, they’ll show up in the Protocol Hierarchy statistics, otherwise 
not.

Regards,
Jaap

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

[Wireshark-dev] On building better statistics

[Jaap Keuter]

This discussion was brought on by issue 17877 titled “Non-visible photo items 
cannot change length after construction”. In there it is correctly stated that 
calls to set proto_item length (either proto_item_set_len() or 
proto_item_set_end()) are not effective when proto_items are not visible. When 
looking at these functions it can be seen that these are part of the group of 
functions which are optimised for faking proto_items when not visible. 

Without going into the faking details (see the macro 
TRY_TO_FAKE_THIS_ITEM_OR_FREE in epan/proto.c for that) it comes down to just 
short cutting the proto_item creation process by returning the tree intended to 
attach the newly to be constructed proto_item to. In effect these all return 
the root node of the dissection tree. 

A special case exception is put in place for proto_items of type FT_PROTOCOL. 
EPAN can be setup so that proto_items of this type in fact are allowed to be 
created, even if they otherwise would have been faked. This feature is used for 
protocol level statistics. The protocol level statistics ’tally the numbers’ by 
running the dissection, with a hidden tree, but with the special case exception 
set. This results in a very compact dissection tree, consisting of the root 
node and the proto_items of type FT_PROTOCOL. The length of these items is then 
used to determine the numbers to add to the various protocol layers in the 
statistics tree.

This is where the ambiguity comes in. Some protocols claim just there share of 
the octets in the frame (discussing Ethernet packet dissection here, to keep it 
simple). Others create their proto_item until the end of the TVB handed to them 
(usually to the end of the frame), and adjust the length after dissection of 
their fields have taken place and the variable number of bytes in the protocol 
layer has been determined. However, the functions to set these lengths don’t 
work when faking items is in effect.

As a result these protocols take up way more of the frame in the statistics 
than they in fact do. Overall more the 100% of the frame is allotted to the 
protocols contained in them. The User's Guide goes into this fact with the 
explanation that these protocol 'contain’ their payload, so that is why the 
payload is added to the protocol. That is one interpretation, but not really 
consistent because fixed size dissectors, which create their proto_items of 
type FT_PROTOCOL with fixed size, do not exhibit this behaviour. 

The simplest step to take would be to allow the functions proto_item_set_len() 
and proto_item_set_end() to operate on proto_items of type FT_PROTOCOL if the 
afore mentioned special case exception was in effect. However, since faking of 
other types of proto_items is still in effect, all these other proto_items are 
now using the proto_items of type FT_PROTOCOL as proto_item, rather than the 
root node. This means that code setting the length of a field, is now also no 
longer blocked, and in fact setting the length of the proto_item of type 
FT_PROTOCOL rather than his own (which is faked).

A simple experiment with the file (code_mac_tagged.pcap) attached to issue 
17877 makes this clear. Changing proto_items_set_len() to allow proto_items 
with type FT_PROTOCOL to set their length if the special case exception is set, 
shows a protocol hierarchy statistics page with all protocols matching their 
length in the dissection details pane. Except for COSE, the dissection details 
say 309 while the statistics say 246. This last length is the length set for 
the final part of the PDU, which ends up becoming the length of the protocol in 
the protocol hierarchy statistics. 

The question now becomes how to proceed with this. Faking proto_items makes 
legitimate calls to set the length of proto_items of type FT_PROTOCOL 
indistinguishable from those calls meant for fields within those protocols. 
Another approach of faking proto_items by always returning the root node 
instead of the tree creates it’s own set of side effects. Now all 
’non-protocol’ proto_items are processed for statistics too, and exposing 
things like expert info in the statistics also. This defeats the purpose of 
faking proto_items in the first place.

A ‘quick and dirty’ solution is to run dissection with a visible tree. This 
gives the desired results, but at the cost of doing a lot more dissection work 
than strictly necessary, voiding the whole purpose of the special case 
exception in not faking proto_items with type FT_PROTOCOL.

I’m not seeing a simple way out of this. Do we want to modify the statistics in 
this way is the fist question to answer. They will be different than in 3.6, 
3.4 and earlier. This could be the right time to do it though. Then the 
question becomes how to achieve this without taking a significant performance 
hit by sidestepping the faking of proto_items.

Thanks,
Jaap

(not rereading this draft, it’s way too late for that. Sorry for any mistyping 
or confusing statements)

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

[Jaap Keuter]

Hi,

Cool that this works as intended / expected.
All that is left now, as Guy indicated, is to document this properly.
Chuck, feeling up to it? ;)

Thanks,
Jaap


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

Re: [Wireshark-dev] Reassembly of split fragments

[Jaap Keuter]

Hi,

Few remarks. The mix-27010 dissector is made to dissect frames of type 
WTAP_ENCAP_MUX27010, or PCAP link layer header type, as defined at 
https://tcpdump.org/linktypes/LINKTYPE_MUX27010.html 
 There it states what the 
layout in the PCAP packets ought to be. All your variations do not fall into 
that category, so shouldn't use this PCAP link layer header type, IMHO. 
Opinions on this vary.
Instead you could use one of the USER link layer type (assuming that this is 
for private use only) in your capture, create a dissector for that link layer 
header type, and handle the defragmentation in there. Once you get that going, 
your complete mux27010 PDUs can then be handed to the (unmodified) mux27010 
dissector, which handles the rest. 
As for your defragmentation code, all information should be there in the calls 
to fragment_add and process_reassembled_data for them to determine what the PDU 
boundaries are. This was you get to be handed single mux27010 PDUs, ready for 
the mux27010 dissector. The ‘rest of the data’ stays in the reassembly table 
and comes out once enough data has been added to it.
Hope it helps


> On 26 Jan 2022, at 10:43, Lars Poeschel  wrote:
> 
> Hello wireshark devs,
> 
> I am currently struggling with reassembly of fragments of the mux27010
> protocol.
> There is a dissector for the mux27010 protocol in wireshark
> (packet-mux27010.c) but it does not work with fragments. The mux27010
> works on top of a serial line (uart) so there is no ethernet, no IP, no
> TCP involved so far. I capture the serial line traffic in pcap format,
> but it has no understanding of the mux27010 protocol, so there can be
> any possible combination of mux PDU and pcap capture unit in there,

___
Sent via:Wireshark-dev mailing list 
Archives: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] Issues with cross-compiling

[Jaap Keuter]

Hi,

Maybe buildroot can give some inspiration:

https://git.buildroot.net/buildroot/tree/package/wireshark

Thanks,
Jaap

> On 17 Jan 2022, at 03:01, Glen Huang  wrote:
> 
> Hi,
> 
> I’m trying to create an OpenWrt package for Wireshark.
> 
> I think I’m pretty close. However, I got stuck at lemon, which if I’m not 
> wrong, should be compiled by my build machine’s compiler. From the source 
> code, I found out it supports the LEMON_C_COMPILER variable, which I assigned 
> with the build machine’s compiler, but after compiling, CMAKE used the target 
> platform’s linking flags for linking, which apparently failed. I’m not very 
> familiar with CMAKE, so would appreciate some help.
> 
> Cross-compiling has cropped up here a few times in the past decades, but the 
> ones I managed to find are all pertaining to Wireshark’s autotools era, so 
> they’re not particularly helpful, at least for my limited knowledge in this 
> area.
> 
> Here is the OpenWrt package’s Makefile I have come up with so far:
> 
> include $(TOPDIR)/rules.mk
> 
> PKG_NAME:=wireshark
> PKG_VERSION:=3.6.1
> PKG_RELEASE:=1
> 
> PKG_SOURCE_URL:=https://www.wireshark.org/download/src/
> PKG_SOURCE:=wireshark-$(PKG_VERSION).tar.xz
> PKG_HASH:=0434eda8fb6bf88e2b42a67eb5d1de254a67d505bec3bb51fee9d7cad7925a38
> 
> PKG_BUILD_PARALLEL:=1
> CMAKE_INSTALL:=1
> 
> include $(INCLUDE_DIR)/package.mk
> include $(INCLUDE_DIR)/cmake.mk
> 
> define Package/wireshark
>  SECTION:=net
>  CATEGORY:=Network
>  TITLE:=Network protocol analyzer
>  URL:=https://www.wireshark.org/
>  DEPENDS:=+libpcap +glib2 +libgcrypt +libcares
> endef
> 
> define Package/wireshark/description
>Network protocol analyzer
> endef
> 
> CMAKE_OPTIONS += \
>-DCMAKE_CROSSCOMPILING=1 \
>-DHAVE_C99_VSNPRINTF=TRUE \
>-DLEMON_C_COMPILER=$(CMAKE_HOST_C_COMPILER) \
>-DBUILD_wireshark=OFF \
>-DBUILD_androiddump=OFF \
>-DBUILD_ciscodump=OFF \
>-DBUILD_idl2wrs=OFF
> 
> define Package/wireshark/install
># figure out later
> endef
> 
> $(eval $(call BuildPackage,wireshark))
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] MPLS Echo Packet containing FEC stack change Sub-TLV in DDMAP TLV is not decoded by wireshark or https://hpd.gasmi.net/

[Jaap Keuter]

Hi,

Thanks for the illustrative capture files. There's nothing better then to have 
that, so that we can look straight at the problem.
I've used them to open an issue here: 
https://gitlab.com/wireshark/wireshark/-/issues/17868 which I can use to 
resolve the problem.

Thanks,
Jaap



> Op 10-01-2022 17:13 schreef max payne.. :
> 
> 
> Hi Jaap,
> 
> Thanks for your response.
> Please find the attached wireshark capture for "multiple FEC stack change 
> TLV" and "FEC stack change with Target FEC TLV" not decoded properly.
> Also the bytes sent in mail below are complete encapsulation with all headers 
> and those bytes can be directly copied to online hex-decoder for a quick look.
> 
> 
> On Fri, Jan 7, 2022 at 12:31 PM Jaap Keuter  mailto:jaap.keu...@xs4all.nl > wrote:
> 
> > Hi,
> > 
> > The immediate response by Alexis was to open an issue on the Wireshark 
> > issue tracker.
> > My response would be to attach a small sample capture file with the 
> > packets, instead of some bytes or screenshot to the email.
> > 
> > Can you do either of those?
> > 
> > Jaap
> > 
> > 
> > 
> > > On 6 Jan 2022, at 06:31, max payne..  > > mailto:pankaj.knit...@gmail.com > wrote:
> > > 
> > > Hi Team,
> > > 
> > > I have not got the resolution for the issue below.
> > > 
> > > This was the link provided to me.
> > > https://www.wireshark.org/mailman/confirm/wireshark-dev/d4b89dd02f824a954e2e3ffa37151bf0f7ebacbc
> > > 
> > > On Fri, Dec 3, 2021 at 12:27 AM max payne..  > > mailto:pankaj.knit...@gmail.com > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > This is to inform you that we are supporting FEC Stack Change Sub-TLV 
> > > > in DDMAP TLV. I have Hex Dump, which is correct as per my understanding 
> > > > but it is not getting decoded on Wireshark or Online Decoder.
> > > > 
> > > > Please let me know if the latest Wireshark  "Version 3.6.0 
> > > > (v3.6.0-0-g3a34e44d02c9)" supports the following (RFC 8029  3.4.1.3 
> > > > https://datatracker.ietf.org/doc/html/rfc8029#section-3.4.1.3 . FEC 
> > > > Stack Change Sub-TLV) :-
> > > > 1) Multiple FEC stack change sub-TLV in DDMap TLV, whereas single FEC 
> > > > stack change TLV is decoded properly. Please find the HEX dump below.
> > > > 2) FEC stack change sub-TLV along with FEC stack sub-TLV in DDMap TLV 
> > > > is not decoded properly. Please find the HEX dump below.
> > > > 
> > > > I am having following HEX Dump, which is not getting decoded properly 
> > > > on wireshark or online decoder "https://hpd.gasmi.net/;
> > > > 
> > > > 
> > > > Two  FEC stack Sub-TLV in DDMAP TLV not decoded properly on wireshark 
> > > > or on https://hpd.gasmi.net/
> > > > Ethernet:   18 92 a4 55 71 04 00 23 8a fb c2 04 81 00 00 d4
> > > > 08 00
> > > > 
> > > > IP: 45 00
> > > > IP Len: 00 68
> > > > 71 a5 00 00 ff 11 29 a4 07 07
> > > > 07 07 09 09 09 09
> > > > 
> > > > UDP: 0d af 0d af
> > > > UPD Len: 00 54
> > > > a8 b1
> > > > 
> > > > ECHO: 00 01
> > > > 00 00 02 02 08 02 00 00 00 16 00 00 00 03 e4 ae
> > > > 50 eb 6f c5 47 9d e4 ae 50 eb 70 2a dc 4c
> > > > 
> > > > DDMAP: 00 14 00 28
> > > > 05 dc 01 02 d2 01 01 01 d2 01 01 01 00 00
> > > > SUB-Len: 00 18
> > > >  
> > > > Stack-chg Type: 00 03 00 08
> > > > Value : 02 01 00 00
> > > > 06 06 06 06
> > > > 
> > > > Stack-chg Type: 00 03 00 08
> > > > Value : 02 01 00 00
> > > > 07 07 07 07
> > > > 
> > > > FEC stack change sub-TLV with FEC sub-TLV (IGP IPV4 Prefix Segment TLV) 
> > > > not decoded properly on wireshark or on https://hpd.gasmi.net/.
> > > > 
> > > > Ethernet:   18 92 a4 55 71 04 00 23 8a fb c2 04 81 00 00 d4
> > > > 08 00
> > > > 
> > > > IP: 45 00
> > > > IP Len: 00 68
> > > > 71 a5 00 00 ff 11 29 a4 07 07
> > > > 07 07 09 09 09 09
> > > > 
> > > > UDP: 0d af 0d af
> > > > UPD Len: 00 54
> > > > a8 b1
> > > > 
> > > > ECHO: 00 01
> > > > 00 00 02 02 08 02 00 00 00 16 00 00 00 03 e4 ae
> > > > 50 eb 6f c5 47 9d e4 ae 50 eb 70 2a dc 4c
&

Re: [Wireshark-dev] MPLS Echo Packet containing FEC stack change Sub-TLV in DDMAP TLV is not decoded by wireshark or https://hpd.gasmi.net/

[Jaap Keuter]

Hi,

The immediate response by Alexis was to open an issue on the Wireshark issue 
tracker.
My response would be to attach a small sample capture file with the packets, 
instead of some bytes or screenshot to the email.

Can you do either of those?

Jaap


> On 6 Jan 2022, at 06:31, max payne..  wrote:
> 
> Hi Team,
> 
> I have not got the resolution for the issue below.
> 
> This was the link provided to me.
> https://www.wireshark.org/mailman/confirm/wireshark-dev/d4b89dd02f824a954e2e3ffa37151bf0f7ebacbc
>  
> 
> 
> On Fri, Dec 3, 2021 at 12:27 AM max payne..  > wrote:
> Hi,
> 
> This is to inform you that we are supporting FEC Stack Change Sub-TLV in 
> DDMAP TLV. I have Hex Dump, which is correct as per my understanding but it 
> is not getting decoded on Wireshark or Online Decoder.
> 
> Please let me know if the latest Wireshark  "Version 3.6.0 
> (v3.6.0-0-g3a34e44d02c9)" supports the following (RFC 8029  3.4.1.3 
> . FEC Stack 
> Change Sub-TLV) :-
> 1) Multiple FEC stack change sub-TLV in DDMap TLV, whereas single FEC stack 
> change TLV is decoded properly. Please find the HEX dump below.
> 2) FEC stack change sub-TLV along with FEC stack sub-TLV in DDMap TLV is not 
> decoded properly. Please find the HEX dump below.
> 
> I am having following HEX Dump, which is not getting decoded properly on 
> wireshark or online decoder "https://hpd.gasmi.net/ "
> 
> 
> Two  FEC stack Sub-TLV in DDMAP TLV not decoded properly on wireshark or on 
> https://hpd.gasmi.net/ 
> Ethernet:   18 92 a4 55 71 04 00 23 8a fb c2 04 81 00 00 d4
> 08 00 
> 
> IP: 45 00 
> IP Len: 00 68
> 71 a5 00 00 ff 11 29 a4 07 07
> 07 07 09 09 09 09 
> 
> UDP: 0d af 0d af 
> UPD Len: 00 54
> a8 b1 
> 
> ECHO: 00 01
> 00 00 02 02 08 02 00 00 00 16 00 00 00 03 e4 ae
> 50 eb 6f c5 47 9d e4 ae 50 eb 70 2a dc 4c 
> 
> DDMAP: 00 14 00 28 
> 05 dc 01 02 d2 01 01 01 d2 01 01 01 00 00
> SUB-Len: 00 18 
>   
> Stack-chg Type: 00 03 00 08 
> Value : 02 01 00 00 
> 06 06 06 06
> 
> Stack-chg Type: 00 03 00 08
> Value : 02 01 00 00 
> 07 07 07 07
> 
> FEC stack change sub-TLV with FEC sub-TLV (IGP IPV4 Prefix Segment TLV) not 
> decoded properly on wireshark or on https://hpd.gasmi.net/ 
> .
> 
> Ethernet:   18 92 a4 55 71 04 00 23 8a fb c2 04 81 00 00 d4
> 08 00 
> 
> IP: 45 00 
> IP Len: 00 68
> 71 a5 00 00 ff 11 29 a4 07 07
> 07 07 09 09 09 09 
> 
> UDP: 0d af 0d af 
> UPD Len: 00 54
> a8 b1 
> 
> ECHO: 00 01
> 00 00 02 02 08 02 00 00 00 16 00 00 00 03 e4 ae
> 50 eb 6f c5 47 9d e4 ae 50 eb 70 2a dc 4c 
> 
> DDMAP: 00 14 00 28
> 05 dc 01 02 d2 01 01 01 d2 01 01 01 00 00
> SUB-Len: 00 18 
>   
> Stack-chg Type: 00 03 00 08 
> Value : 02 01 0c 00 
> 06 06 06 06
> 
> FEC TLV Type: 00 0e 00 08
> Value : 01 01 01 01 
>  20 00 00 00
> 
> Whereas multiple Label-Stack sub-TLV in DDMap TLV is getting properly decoded 
> on https://hpd.gasmi.net/ 
> Ethernet: 18 92 a4 55 71 04 00 23 8a fb c2 04 81 00 00 d4
> 08 00 
> 
> IP: 45 00 
> IP Len: 00 60
> 71 a5 00 00 ff 11 29 a4 07 07
> 07 07 09 09 09 09 
> 
> UDP: 0d af 0d af 
> UPD Len: 00 4C
> a8 b1
> 
> MPLS Echo: 00 01
> 00 00 02 02 08 02 00 00 00 16 00 00 00 03 e4 ae
> 50 eb 6f c5 47 9d e4 ae 50 eb 70 2a dc 4c 
> 
> DDMAP: 00 14 00 20 
> 05 dc 01 02 d2 01 01 01 d2 01 01 01 00 00
> SUB-Len: 00 10 
> 
> Label-S: 00 02 00 04 
> 00 00 30 06
> 
> Label-S: 00 02 00 04 
> 00 00 30 06
> 
> -- 
> Pankaj Verma
> 
> 
> -- 
> Pankaj Verma
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Need help figuring out a large gap in trace | Windows 11

[Jaap Keuter]

Hi,

Not sure what’s going on here, but there’s one thing I would like to point out. 
For long term capture I would *strongly* recommend using dumpcap instead.
Reason behind this is that Tshark invokes the dissection engine for the 
captured packets, which in this case is not what’s needed, but still takes up 
processing and (lot’s of) memory. 
Instead you can invoke the capture engine used by Tshark directly. Dumpcap 
mostly uses the same command line parameters. Have a look at the manual page.
Several years ago I had dumpcap running for months without issue.

Regards,
Jaap

> On 22 Dec 2021, at 03:29, Adithya Krishna  wrote:
> 
> Hi there!
> 
> I am a new user of Wireshark and recently started logging packet traces on my 
> Windows 11 computer using the tshark command prompt option. I am using a 
> ring-buffer with a duration filter, and the tracing has been mostly fine. 
> Below is the exact CLI prompt being used

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

[Wireshark-dev] ISO-8601 date support

[Jaap Keuter]

Hi Jörg,

With commit a0173cd7 you’ve added ISO-8601 date support to text2pcap.
The “Import from Hex dump...” feature of Wireshark is supposed to be equally 
capable.
Would you be able to add this capability there as well?

Thanks,
Jaap
 
___
Sent via:Wireshark-dev mailing list 
Archives: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] Is there some reasonable way to split up epan/dissectors/packet-ieee80211.c into smaller files?

[Jaap Keuter]

Hi Richard,

Indeed it’s a rather monolithic block. Quick look at the code, here are some 
suggestions .

- Extract the dissection of the fixed management fields.
All these add_ff_... functions count up to a lot. Not sure how they are 
dependant on other parts of the dissector, but these at least one external 
dependancy. Could change about 10% LOC.

- Extract the dissection of tags.
These are now modeled as PINOs. Not sure how they are dependant on other parts 
of the dissector. Not sure how much that would change.

- Unwrap lines
Lame suggestion, but quite a few lines are wrapped somewhat conservatively. 
Unwrapping them to 132 columns might save some LOC as well.


I can offer help with the last one, the others require a little more insight in 
this code.

Thanks,
Jaap


> On 3 Dec 2021, at 00:12, Richard Sharpe  wrote:
> 
> Hi folks,
> 
> The IEEE802.11 dissector is becoming unwieldy.
> 
> It is currently around 50,000+ lines of code!
> 
> I am adding additional lines of code for the Wi-Fi 7 spec. I dread to
> think what will happen when they embark on Wi-Fi 8!
> 
> Is there some way we can split this behemoth into a set of separate files?
> 
> -- 
> 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

Re: [Wireshark-dev] Gitlab missing feature compared to Github

[Jaap Keuter]

Hi,

What about just entering the commit in the GitLab search box? There you get the 
commit, parent commit, the merge request, the pipeline, etc. all just one click 
away.
Basically the same thing.

Thanks,
Jaap


> On 30 Oct 2021, at 11:02, Joerg Mayer  wrote:
> 
> Hello,
> 
> there is one very valuable feature of github that was lost in the transition 
> to giblab:
> The commit message does no longer reference the merge request, making it way 
> harder to
> look at the discussion leading to a merge.
> Can this feature please be readded?
> 
> Thanks!
>   Jörg
> -- 
> Joerg Mayer   
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.

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

Re: [Wireshark-dev] 3.6.0 release schedule

[Jaap Keuter]

Hi João,

Thanks for the feedback.It’s been a while since someone seriously looked at 
this so it’s much appreciated. It also makes you kind of the resident expert on 
the thing ;).  So, in your judgement, are there things that really should be 
done to make things, I would say, consistent at least? 

Thanks,
Jaap


> On 7 Oct 2021, at 11:49, João Valverde via Wireshark-dev 
>  wrote:
> 
> 
> On 10/6/21 19:42, Jaap Keuter wrote:
>> Hi,
>> 
>> Are those wmem / pinfo->pool changes completed? Would be nice if that was 
>> consistent before branching. Is dfilter stabilised already?
> 
> I don't really have a roadmap, I'm just taking a fresh look at the code for 
> general improvements, bug fixing, learning and just maybe come up with some 
> kind of formal specification.
> 
>>  These are the things that come to mind.
>> 
>> Thanks,
>> Jaap
>> 
>>> On 30 Sep 2021, at 23:29, Gerald Combs  wrote:
>>> 
>>> Hi all,
>>> 
>>> I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm 
>>> wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1 
>>> instead. Unless anyone needs to delay the 3.6 branch I plan on doing the 
>>> following:
>>> 
>>> Oct  6 : Release 3.4.9 & 3.2.17
>>> Oct  7 : Create the release-3.6 branch
>>> Oct  8 : Release 3.6.0rc1
>>> Oct 20 : Release 3.6.0 and wind down the 3.2 branch
>>> Nov 17 : Release 3.6.1 & 3.4.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  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> <mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 3.6.0 release schedule

[Jaap Keuter]

Hi Evan,

Thanks for the insight. So the first item should be done then, the last one 
will unfortunately not be ready in time. So be it I guess.

Thanks,
Jaap


> On 6 Oct 2021, at 20:51, Evan Huus  wrote:
> 
> On Wed., Oct. 6, 2021, 14:43 Jaap Keuter,  <mailto:jaap.keu...@xs4all.nl>> wrote:
> Hi,
> 
> Are those wmem / pinfo->pool changes completed? Would be nice if that was 
> consistent before branching.
> 
> I have three things left on my list:
> - a few last changes in to_str macros - small and easy
> - figure out what to do with valuestrings - hard and undefined
> - convert remaining dissectors - trivial but large
> 
> The last two aren't worth waiting for as they will both require some 
> investment. The first one I'll try to get to soon, but should be 
> self-explanatory based on my recent merges if somebody else wants to grab it 
> today.
> 
> Evan
> 
> Is dfilter stabilised already? These are the things that come to mind.
> 
> Thanks,
> Jaap
> 
> > On 30 Sep 2021, at 23:29, Gerald Combs  > <mailto:ger...@wireshark.org>> wrote:
> > 
> > Hi all,
> > 
> > I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm 
> > wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1 
> > instead. Unless anyone needs to delay the 3.6 branch I plan on doing the 
> > following:
> > 
> > Oct  6 : Release 3.4.9 & 3.2.17
> > Oct  7 : Create the release-3.6 branch
> > Oct  8 : Release 3.6.0rc1
> > Oct 20 : Release 3.6.0 and wind down the 3.2 branch
> > Nov 17 : Release 3.6.1 & 3.4.10
> 
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>  mailto:wireshark-dev-requ...@wireshark.org 
> <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> <mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 3.6.0 release schedule

[Jaap Keuter]

Hi,

Are those wmem / pinfo->pool changes completed? Would be nice if that was 
consistent before branching. Is dfilter stabilised already? These are the 
things that come to mind.

Thanks,
Jaap

> On 30 Sep 2021, at 23:29, Gerald Combs  wrote:
> 
> Hi all,
> 
> I have the 3.5.1 release scheduled for next Thursday, October 7, but I'm 
> wondering if we shouldn't create the 3.6 branch and release 3.6.0rc1 instead. 
> Unless anyone needs to delay the 3.6 branch I plan on doing the following:
> 
> Oct  6 : Release 3.4.9 & 3.2.17
> Oct  7 : Create the release-3.6 branch
> Oct  8 : Release 3.6.0rc1
> Oct 20 : Release 3.6.0 and wind down the 3.2 branch
> Nov 17 : Release 3.6.1 & 3.4.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

[Wireshark-dev] On MR 4428

[Jaap Keuter]

Hi,

Looking at MR 4428 https://gitlab.com/wireshark/wireshark/-/merge_requests/4428 
(cherry picked from commit 96cfaf67) it introduces a new symbol in the wiretap 
11 library (wtap_uses_lua_filehandler). The debian symbols file contains the 
addition of "wtap_uses_lua_filehandler@Base 3.5.1", which refers to a later 
version (3.5.1) than this release is of (3.4.x). I could see this being a 
problem somewhere. Maybe we need to reconsider inclusion of the MR in 
release-3.4

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

[Wireshark-dev] Does this apply to 3.2 too?

[Jaap Keuter]

Hi,

When building release-3.2 I'm greeted by a stream of warnings from CMake first, 
like these:


-- Configuring done 

CMake Warning (dev) in CMakeLists.txt:  

Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. 
  
Run "cmake --help-policy CMP0071" for policy details.  Use the cmake_policy 
  
command to set the policy and suppress this warning.
  

For compatibility, CMake is excluding the GENERATED source file(s): 
  

"/master-3.2/build/tshark-tap-register.c"   


from processing by AUTOMOC and AUTOUIC.



It seems that MR 3140 
https://gitlab.com/wireshark/wireshark/-/merge_requests/3140 was introduced for 
to quell that stream in release-3.4. What could be the reason this is not 
applicable to master-3.2 too? Minimum supported Qt version, or CMake version 
which cannot handle this? I'm not familiar enough with these subjects to know 
what constraints there are, so don't want to mess things up with a MR just yet.

Thanks,
Jaap___
Sent via:Wireshark-dev mailing list 
Archives: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] Sample of IAX2 with RTP

[Jaap Keuter]

Hi,

Be very careful to not change any calculation made in accordance to RFC 3550.
People depend on these algorithms as well as the naming used.

Regards,
Jaap

> Op 04-10-2021 21:08 schreef Jirka Novak :
> 
>  
> Hi,
> 
>   there is observed misbehaving in RTP jitter mean calculation
> (https://gitlab.com/wireshark/wireshark/-/issues/17600). I'm going to
> fix it.
>   There is very similar code in IAX2 analysis and it looks there is same
> issue too. I plan to fix it too, but I have no IAX2 sample with RTP to
> verify it.
>   Can I ask someone to publish short sample?
> 
>   I expect that sample will show forward and reverse stream in
> Telephony->IAX2 Stream Analysis.
>   Please, send it as response to this email or attach it to mentioned issue.
> 
>   If it will be permitted, I will publish it in sample library of Wireshark.
> 
>   Best regards,
> 
>   Jirka Novak
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] pod2adoc and the man pages

[Jaap Keuter]

Hi, 

In reference to https://gitlab.com/wireshark/wireshark/-/merge_requests/4294

What is supposed to happen to the man pages themselves? Will they now be 
generated from the AsciiDoc files? I think I’m missing the point to this change.

Thanks,
Jaap

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

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

[Jaap Keuter]

Great, I’ll have a look when time permits... ;)

> On 13 Sep 2021, at 17:03, Roland Knall  wrote:
> 
> See https://gitlab.com/wireshark/wireshark/-/merge_requests/4178 
> <https://gitlab.com/wireshark/wireshark/-/merge_requests/4178> for the 
> functionality change
> 
> Am Mo., 13. Sept. 2021 um 11:37 Uhr schrieb Roland Knall  <mailto:rkn...@gmail.com>>:
> Looks to me that we actually have an inconsistency in behavior. If you click 
> on a byte, the underlying field gets selected in the byteview as well as 
> packetdetail pane and stays selected, until you click someplace else. If you 
> do the same the other way around, it does not work, as the selection is not 
> locked in in the byteview.
> 
> Bugfix inbound, and I don't think it needs to be configurable, as it actually 
> solves the underlying issue
> 
> cheers 
> Roland
> 
> Am Sa., 11. Sept. 2021 um 15:45 Uhr schrieb John Thacker 
> mailto:johnthac...@gmail.com>>:
> On Sat, Sep 11, 2021 at 7:23 AM Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> wrote:
> Hi all, 
> 
> Often when working with captured data from some development setup I wonder 
> around the packet bytes with the mouse pointer to try and follow where in the 
> code under development certain parts of a packet contents is being created. 
> What happens now is that the highlighting of the field where this particular 
> bytes are from follows the mouse pointer. But I'm working the other way 
> around, by first selecting a field in the packet details, then dive into the 
> packet bytes, where I would like the selected field highlighting to remain, 
> so I can navigate around while keeping my bearings in the packet. 
> 
> But I recon this will upset people. So putting it behind a preference would a 
> the way to go. The the question becomes where to put that? Anyone a good 
> idea? 
> 
> I would appreciate that, I have wished for that behavior myself. While one 
> option is just giving it a name so that people can only access it through 
> Preferences->Advanced, I think the most natural place is in 
> Appearance->Layout. There's already a section for Packet List settings there, 
> that includes a preference for "Enable mouse-over colorization." 
> (https://gitlab.com/wireshark/wireshark/-/blob/master/epan/prefs.c#L3377-L3380
>  
> <https://gitlab.com/wireshark/wireshark/-/blob/master/epan/prefs.c#L3377-L3380>)
>  Perhaps add a "Packet Bytes settings" group and then the new preference.
> 
> Cheers,
> John Thacker
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>  mailto:wireshark-dev-requ...@wireshark.org 
> <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Wireshark-dev] Byte view mouse hover behaviour

[Jaap Keuter]

Hi all,

Often when working with captured data from some development setup I wonder 
around the packet bytes with the mouse pointer to try and follow where in the 
code under development certain parts of a packet contents is being created. 
What happens now is that the highlighting of the field where this particular 
bytes are from follows the mouse pointer. But I'm working the other way around, 
by first selecting a field in the packet details, then dive into the packet 
bytes, where I would like the selected field highlighting to remain, so I can 
navigate around while keeping my bearings in the packet.

A very simple solution is this:

diff --git a/ui/qt/byte_view_tab.cpp b/ui/qt/byte_view_tab.cpp
index efb2cb1add..70ee2a4c5e 100644
--- a/ui/qt/byte_view_tab.cpp
+++ b/ui/qt/byte_view_tab.cpp
@@ -112,7 +112,7 @@ void ByteViewTab::addTab(const char *name, tvbuff_t *tvb) {

connect(wsApp, SIGNAL(zoomMonospaceFont(QFont)), byte_view_text, 
SLOT(setMonospaceFont(QFont)));

- connect(byte_view_text, SIGNAL(byteHovered(int)), this, 
SLOT(byteViewTextHovered(int)));
+ //connect(byte_view_text, SIGNAL(byteHovered(int)), this, 
SLOT(byteViewTextHovered(int)));
connect(byte_view_text, SIGNAL(byteSelected(int)), this, 
SLOT(byteViewTextMarked(int)));
connect(byte_view_text, SIGNAL(byteViewSettingsChanged()), this, 
SIGNAL(byteViewSettingsChanged()));
connect(this, SIGNAL(byteViewSettingsChanged()), byte_view_text, 
SLOT(updateByteViewSettings()));

But I recon this will upset people. So putting it behind a preference would a 
the way to go. The the question becomes where to put that? Anyone a good idea?

Thanks,
Jaap
___
Sent via:Wireshark-dev mailing list 
Archives: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".

[Jaap Keuter]

HI,

Very well, that’s one possible cause out of the way. 
Luckily Pascal found something else, so hopefully that’s solved..

Thanks,
Jaap


> On 10 Aug 2021, at 17:41, Mora, Jorge via Wireshark-dev 
>  wrote:
> 
> Hello Jaap,
>  
> I just looked around and I found this:
> $ ll /usr/share/cmake/Modules/CheckFunctionExists.c*
> -rw-r--r--. 1 root root  421 Jun 14  2018 
> /usr/share/cmake/Modules/CheckFunctionExists.c
> -rw-r--r--. 1 root root 3796 Jun 14  2018 
> /usr/share/cmake/Modules/CheckFunctionExists.cmake
>  
> # rpm -qa | grep cmake
> cmake-rpm-macros-3.11.4-7.el8.noarch
> cmake-3.11.4-7.el8.x86_64
> cmake-filesystem-3.11.4-7.el8.x86_64
> cmake-data-3.11.4-7.el8.noarch
>  
> Thanks,
>  
> --Jorge
>  
> From: Wireshark-dev  <mailto:wireshark-dev-boun...@wireshark.org>> on behalf of Jaap Keuter 
> mailto:jaap.keu...@xs4all.nl>>
> Reply-To: Developer support list for Wireshark  <mailto:wireshark-dev@wireshark.org>>
> Date: Tuesday, August 10, 2021 at 9:26 AM
> To: Developer support list for Wireshark  <mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unknown CMake command "check_function_exists".
>  
> NetApp Security WARNING: This is an external email. Do not click links or 
> open attachments unless you recognize the sender and know the content is 
> safe. 
> 
> 
> 
> Hi, 
>  
> The module CheckFunctionExists [1] has been around from at least cmake 3.0, 
> so that’s not new. The first question then would be if, besides cmake, the 
> cmake modules are installed as well?
>  
> [1] https://cmake.org/cmake/help/v3.11/module/CheckFunctionExists.html 
> <https://cmake.org/cmake/help/v3.11/module/CheckFunctionExists.html>
>  
> Thanks,
> Jaap
>  
> 
> 
>> On 10 Aug 2021, at 16:57, Mora, Jorge via Wireshark-dev 
>> mailto:wireshark-dev@wireshark.org>> wrote:
>>  
>> 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 mailto:johnthac...@gmail.com>>
>> 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".
>>  
>>  
>> --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

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

[Jaap Keuter]

Hi,

The module CheckFunctionExists [1] has been around from at least cmake 3.0, so 
that’s not new. The first question then would be if, besides cmake, the cmake 
modules are installed as well?

[1] https://cmake.org/cmake/help/v3.11/module/CheckFunctionExists.html

Thanks,
Jaap


> On 10 Aug 2021, at 16:57, Mora, Jorge via Wireshark-dev 
>  wrote:
> 
> 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 mailto:johnthac...@gmail.com>>
> 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".
>  
>  
> --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] IRC channel

[Jaap Keuter]

Hi Jason,

Please be aware that the Freenode IRC channel #wireshark is a resource not 
controlled by the Wireshark organisation. 

Thanks,
Jaap

> On 10 Jun 2021, at 18:55, Jason Cohen  wrote:
> 
> Curious if there is (or I missed) an announcement about the IRC channel on 
> freenode.  Obviously there is a lot of activity / drama going on there and 
> I've been seeing some rather ugly spam messages in the channel on freenode.

___
Sent via:Wireshark-dev mailing list 
Archives: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] Proposal: New set of help pages for VoIP dialogs

[Jaap Keuter]

Hi,

You could instead think about adding to the user guide, where this stuff should 
be in the first place.

Thanks,
Jaap

> On 29 Mar 2021, at 08:36, Jirka Novak  wrote:
> 
> Hi,
> 
>  I'm working on VoIP dialogs for several weeks. RTP Player was
> significantly changed, there are more available actions in other VoIP
> dialogs too and I plan to update wiki pages for it.
>  What I found is that e.g. RTP Player changes are so big that it is
> difficult to describe current behaving and new behaving on one page.
>  My proposal is to create "version 2" wiki pages for that dialogs.
> Version 1 will up to 3.4, version 2 will be from 3.5.
> 
>  Does this idea fits into Wireshark's wiki concept?
> 
>  If so, the question is how to connect new pages to global list of
> pages in wiki to make it clear?
>  Any comment welcomed.
> 
>   Best regards,
> 
>   Jirka Novak

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

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

[Jaap Keuter]

It’s not a matter of *what* the program is reading, but *where* it's reading in 
the buffer. This makes it usable for *all* programs reading this file format, 
not just Wireshark. Prefixing it with zero padding (even a nibble) would 
achieve that.
I’m done.


> On 16 Feb 2021, at 10:05, Timmy Brolin  wrote:
> 
> Hi,
>  
> Would anyone mind if I submit a merge request which makes Wireshark capable 
> of dissecting all valid Ethernet mPackets according to IEEE 802.3br?
> It is a reasonably small change. But I don’t want to put in the effort if the 
> merge request would be blocked.
>  
>  
> Jaap:
> Note that Figure 99-4 has absolutely no information about how to dissect the 
> CRC, SMD, FRAG_COUNT and PREAMBLE.
>  
> Wireshark
> Dissects the CRC according to section 99.3.6 and figure 99-6
> Dissects the SMD according to section 99.3.3 and figure 99-6
> Dissects the FRAG_COUNT according to section 99.3.4 and figure 99-6
> 
> But it does NOT dissect the PREAMBLE according to figure 99-6
>  
> Are you not reading a little too much into a single line of text on the 
> tcpdump webpage?
> If figure 99-4 is the only specification for ‘type 274 - 
> LINKTYPE_ETHERNET_MPACKET’, do you think dissection of the CRC, SMD and 
> FRAG_COUNT according to sections 99.3.3, 99.3.4, 99.3.6 and figure 99-6 
> should be removed from Wireshark?
>  
> The intention is obviously that pcapng type “LINKTYPE_ETHERNET_MPACKET” 
> should be able to hold any and all valid Ethernet mPackets according to IEEE 
> 802.3br.
> 
> Regards,
> Timmy Brolin
> 
>  
>  
> From: Wireshark-dev  On Behalf Of Jaap 
> Keuter
> Sent: den 15 februari 2021 21:12
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] pcapng decoding error when preamble is shortened
>  
> Hi,
>  
> A not uncommon, but unfortunate misconception is that of Wireshark being a 
> capture device, or receiver as you put it. In short Wireshark doesn’t 
> capture, it is a program reading files, containing packets conforming to 
> specifications as laid out in the Link Layer Header Types on the tcpdump 
> website, among others. To accommodate users it does provide interfaces to 
> capture filters, most famous to BPF via libpcap, and as of recent to Npcap, 
> as well as extcaps. These programs are invoked to interface between the Link 
> Layer (L2) and the wiretap interface build into Wireshark to read capture 
> file formats. In that respect Wireshark sits on top of the Data Link Layer of 
> whatever medium is underneath.
>  
> In the context of Ethernet, Wireshark indeed expects the capture filter to 
> provide well-formed packets, starting at the first octet after the SFD and 
> optionally with an FCS. The fact wether or not to accept a frame with an 
> invalid FCS is up to the network driver combined with the hardware (MAC/PHY). 
> In normal cases the driver/hardware does filter out incorrect frames, either 
> for their destination MAC not matching, invalid FCS, but also short frames 
> (<64 octets), too long frames (jabber), or otherwise corrupted frames. To 
> allow for wider packet sniffing capabilities some of these checks can be 
> configured being off, the promiscuous mode. This holds true for destination 
> MAC and FCS and maybe others.
>  
> Regardless of mode (promiscuous or normal) the capture filter is still 
> expected to deliver the packet beginning with the first octet of the 
> destination MAC address. Whether or not the FCS is to be part of the captured 
> packet is a bit of a contentious subject, but there’s no ambiguity about 
> where the captured packet should begin. That is at the first octet after the 
> SFD. The MAC is reponsible to hunt for this frame synchronisation, the 
> capture filter is sending the correctly aligned packet to the capture engine.
>  
> Where the format for Ethernet (Link Layer Header Type 1) is somewhat loosely 
> defined as "IEEE 802.3 Ethernet”, in case of Link Layer Header Type 274 this 
> is made very explicit:
> "mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the 
> preamble and always ending with a CRC field.” Notwithstanding the text and/or 
> figures in the rest of this IEEE standard, this figure is the format to which 
> packets need to adhere in order to be valid packets of Link Layer Header Type 
> 274. To accommodate an even lower level of IEEE 802.3br packet reception an 
> additional Link Layer Header Type would need to be defined, with additional 
> specification of the packets’ physical reception characteristics. The number 
> of received preamble symbols would be one of them, the IPG length could be 
> another, and maybe even other data for TSN purposes. This would then be an 
> evolved alternative to the cu

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

[Jaap Keuter]

Hi,

A not uncommon, but unfortunate misconception is that of Wireshark being a 
capture device, or receiver as you put it. In short Wireshark doesn’t capture, 
it is a program reading files, containing packets conforming to specifications 
as laid out in the Link Layer Header Types on the tcpdump website, among 
others. To accommodate users it does provide interfaces to capture filters, 
most famous to BPF via libpcap, and as of recent to Npcap, as well as extcaps. 
These programs are invoked to interface between the Link Layer (L2) and the 
wiretap interface build into Wireshark to read capture file formats. In that 
respect Wireshark sits on top of the Data Link Layer of whatever medium is 
underneath.

In the context of Ethernet, Wireshark indeed expects the capture filter to 
provide well-formed packets, starting at the first octet after the SFD and 
optionally with an FCS. The fact wether or not to accept a frame with an 
invalid FCS is up to the network driver combined with the hardware (MAC/PHY). 
In normal cases the driver/hardware does filter out incorrect frames, either 
for their destination MAC not matching, invalid FCS, but also short frames (<64 
octets), too long frames (jabber), or otherwise corrupted frames. To allow for 
wider packet sniffing capabilities some of these checks can be configured being 
off, the promiscuous mode. This holds true for destination MAC and FCS and 
maybe others.

Regardless of mode (promiscuous or normal) the capture filter is still expected 
to deliver the packet beginning with the first octet of the destination MAC 
address. Whether or not the FCS is to be part of the captured packet is a bit 
of a contentious subject, but there’s no ambiguity about where the captured 
packet should begin. That is at the first octet after the SFD. The MAC is 
reponsible to hunt for this frame synchronisation, the capture filter is 
sending the correctly aligned packet to the capture engine.

Where the format for Ethernet (Link Layer Header Type 1) is somewhat loosely 
defined as "IEEE 802.3 Ethernet”, in case of Link Layer Header Type 274 this is 
made very explicit:
"mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the preamble 
and always ending with a CRC field.” Notwithstanding the text and/or figures in 
the rest of this IEEE standard, this figure is the format to which packets need 
to adhere in order to be valid packets of Link Layer Header Type 274. To 
accommodate an even lower level of IEEE 802.3br packet reception an additional 
Link Layer Header Type would need to be defined, with additional specification 
of the packets’ physical reception characteristics. The number of received 
preamble symbols would be one of them, the IPG length could be another, and 
maybe even other data for TSN purposes. This would then be an evolved 
alternative to the currently defined Link Layer Header Type for capture filters 
that requires this. Or a Link Layer Header Type with a pseudo header containing 
these physical reception characteristics of the packet, followed by the mPacket 
data as per Figure 99-4. This would then be alike Link Layer Header Type 127, 
"Radiotap link-layer information followed by an 802.11 header.”, where the 
existing IEEE 802.11 dissector is being reused, while providing extra reception 
information from the Radiotap header.

Regards,
Jaap



> On 14 Feb 2021, at 00:57, Timmy Brolin  wrote:
> 
> Yes, the capture device is indeed capturing data completely accurately.
> 
> You are referring to the transmission section of IEEE 802.3br-2016.
> If you look at the receive section on page 51, you will find that receivers 
> are required to accept any length preamble. Hence, Wireshark is not compliant 
> with the IEEE 802.3br-2016 specification.
> 
> It is just like the specification requires the FCS to always be transmitted 
> correct, but receivers are required to also expect and handle an incorrect 
> FCS without breaking down.
> Wireshark does not require capture devices to repair any faulty FCS, does it?
> 
> Preamble reduction is quite common practice. In this particular case I have a 
> SGMII RJ45 SFP on the network which randomly chops off one byte of the 
> preamble on some packets. This is common and accepted behavior for various 
> pieces of network equipment. 
> 
> The entire point of using a mPacket capture device is to be able to correctly 
> monitor and debug everything from the lowest to the highest level aspects of 
> Ethernet.
> All specification-compliant packets on the wire should decode properly in 
> Wireshark, and Wireshark should not lie to the user about how the packet 
> looks on the wire.
> 
> Regards,
> Timmy Brolin
>  
> From: Wireshark-dev  <mailto:wireshark-dev-boun...@wireshark.org>> On Behalf Of Jaap Keuter
> Sent: den 13 februari 2021 10:43
> To: Developer support list for Wireshark  <

Re: [Wireshark-dev] pcapng decoding error when preamble is shortened

[Jaap Keuter]

Hi,The capture file (View | Reload as File Format/Capture) contains an Interface Descriptor Block which states Link Type 274.According to https://www.tcpdump.org/linktypes.html the Packet Data in the capture file must adhere to "mPackets, as specified by IEEE 802.3br Figure 99-4, starting with the preamble and always ending with a CRC field.” According to IEEE 802.3br-2016 the mPacket has either * 7 octets preamble (0x55), 1 octet SMD followed by the mData and 4 octets CRC.* 6 octets preamble (0x55), 1 octet SMD, 1 octet fragment count followed by the mData and 4 octets CRC.The first packet in the capture has 7 preamble octets and an SMD-E making it an Express Packet.The second packet in the capture has 6 preamble octets, an SMD-E and a frag_count field of 0x01. That format does not align with the mPacket specification. The SMD has to be of a different type and the frag_count field has to be properly encoded.In the second packet, when counting out from the SMD, the first and second sextet look like Ethernet MAC addresses (from the same device sending the first packet to the LLDP multicast address) with the LLDP ether type. So the intended mData seems to be a valid Ethernet packet. What is wrong though is that the capture device is creating a capture file, declaring to write Link Type 274 packet blocks, which are as defined in IEEE802.3br figure 99-4, but fails to adhere to that format in all circumstances. It assumes that writing short(-er) preambles is okay, but this violates the Link Type specification.I can think of two reasons why this is done. 1) the capture device wants to record as accurately as possible what its receiver is able to detect on the wire. While that means that it may miss symbols due to its slicer still getting in sync, it shows what it can. 2) the capture devices misaligns the received symbols into the receive buffer, thereby distorting the intended receive frame.From what you write it seems that reason 1) is applicable. Unfortunately the chosen Link Type is not suitable for this. The Link Type 274 is not intended for mPackets where the reader is to hunt for frame synchronisation. That task is left to the receiver before writing IEEE802.3br compliant mPackets in the file. Currently there is no defined Link Type for that, nor a dissector capable of this.What you could do is to contact the supplier of the capture device and discuss the options, or write a program to correct these capture files before loading them in Wireshark.Regards,JaapOn 9 Feb 2021, at 11:21, Timmy Brolin  wrote:Hi, It seems Wireshark fails to decode captured packets with shortened preamble? Normally Ethernet packets have a preamble and SFD like this:55D5But during transmission over Ethernet, sometimes the preamble arrives slightly shorter at the receiving end. Some bytes, or even half a byte(!), at the start of the preamble can go missing for various technical reasons.This is considered normal, and all Ethernet MACs are required to properly decode packets with shortened preamble, as well as packets where the preamble is a non-integer number of bytes.But it seems Wireshark does not?  Decoding failure when preamble is shortened:Normal preamble, decoding successful:  I have attached a pcapng file with these two packets. Timmy BrolinM.SC. Computer Systems EngineeringHMS Industrial Networks ABStationsgatan 37, Box 4126300 04 Halmstad, SwedenEmail: t...@hms.seDirect: +46 35 17 29 32HALMSTAD | BARCELONA | BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DUBAI | HEDEL | IGUALADA |KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE | TOKYO | WETZLARwww.hms-networks.com 

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

Re: [Wireshark-dev] Missing Wiki page on Gitlab

[Jaap Keuter]

> On 3 Feb 2021, at 15:54, Graham Bloice  wrote:
> 
> No idea if it got transferred and has subsequently been deleted or failed to 
> transfer but the old wiki page on ExpertInfo 
> (https://wiki.wireshark.org/Development/ExpertInfo 
> ) doesn't seem to be 
> present in the Gitlab version.
> 
> -- 
> Graham Bloice
> 

I’ve removed it since a) the info was outdated, and b) the correct info was 
added to the developer guide.

Thanks,
Jaap


___
Sent via:Wireshark-dev mailing list 
Archives: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.3 on macOS crash

[Jaap Keuter]

> On 30 Jan 2021, at 15:37, Jaap Keuter  wrote:
> 
> Just downloaded the update of current stable. Launching it however is not so 
> fine. Probably something left over in the settings which causes it to crash.
> 
> 
> 
> Going down the rabbit hole...

Okay, not too deep: #17193 
<https://gitlab.com/wireshark/wireshark/-/issues/17193>

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

[Wireshark-dev] Wireshark 3.4.3 on macOS crash

[Jaap Keuter]

Just downloaded the update of current stable. Launching it however is not so 
fine. Probably something left over in the settings which causes it to crash.

Process:   Wireshark [46889]
Path:  /Applications/Wireshark.app/Contents/MacOS/Wireshark
Identifier:org.wireshark.Wireshark
Version:   3.4.3 (3.4.3)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible:   Wireshark [46889]
User ID:   502

Date/Time: 2021-01-30 15:33:21.025 +0100
OS Version:Mac OS X 10.15.7 (19H114)
Report Version:12
Anonymous UUID:8C235D6C-D2DD-D6D8-A1F8-31F508F8FB4B

Sleep/Wake UUID:   C2BCA0DC-9C1C-4C40-B9A8-2DA421D8FCDD

Time Awake Since Boot: 89 seconds
Time Since Wake:   4000 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_ARITHMETIC (SIGFPE)
Exception Codes:   EXC_I386_DIV (divide by zero)
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Floating point exception: 8
Termination Reason:Namespace SIGNAL, Code 0x8
Terminating Process:   exc handler [46889]

Application Specific Information:
Wireshark 3.4.3 (v3.4.3-0-g6ae6cd335aa9)
 
Compiled (64-bit) with Qt 5.12.6, with libpcap, without POSIX capabilities, with
GLib 2.58.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.15 and PKCS #11 support, with Gcrypt 1.8.7, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with
automatic updates using Sparkle, with SpeexDSP (using system library), with
Minizip.
 
Running on Mac OS X 10.15.7, build 19H114 (Darwin 19.6.0), with Intel(R)
Core(TM) i7-3720QM CPU @ 2.60GHz (with SSE4.2), with 8192 MB of physical memory,
with locale C, with libpcap version 1.9.1, with GnuTLS 3.6.15, with Gcrypt
1.8.7, with brotli 1.0.9, with zlib 1.2.11, binary plugins supported (0 loaded).
 
Built using clang 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16).
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgmp.10.dylib 0x0001110ed9e7 __gmpn_tdiv_qr + 
1543 (tdiv_qr.c:263)
1   libgmp.10.dylib 0x0001110bb3f8 __gmpz_tdiv_r + 376 
(tdiv_r.c:91)
2   libgmp.10.dylib 0x0001110af9c8 __gmpz_fdiv_r + 136 
(fdiv_r.c:55)
3   libgnutls.30.dylib  0x00010fbe2b19 wrap_nettle_mpi_addm 
+ 41 (mpi.c:248)
4   libgnutls.30.dylib  0x00010fb5d575 
_gnutls_pkcs12_string_to_key + 1765 (pkcs12_encr.c:202)
5   libgnutls.30.dylib  0x00010fb656e9 
_gnutls_pkcs_raw_decrypt_data + 697 (pkcs7-crypt.c:1197)
6   libgnutls.30.dylib  0x00010fb6ecc8 pkcs8_key_decode + 
664 (privkey_pkcs8.c:959)
7   libgnutls.30.dylib  0x00010fb6d59c 
gnutls_x509_privkey_import_pkcs8 + 236 (privkey_pkcs8.c:1589)
8   libwsutil.12.dylib  0x00010f22c8f1 rsa_load_pkcs12 + 
1057 (rsa.c:307)
9   libwireshark.14.dylib   0x0001084d4d19 
ssldecrypt_uat_fld_password_chk_cb + 73 (packet-tls-utils.c:6188)
10  libwireshark.14.dylib   0x000108b723be uat_load_lex + 3278
11  libwireshark.14.dylib   0x000108b73651 uat_load + 225 
(uat_load.l:419)
12  libwireshark.14.dylib   0x000108b61ef7 uat_load_all + 87 
(uat.c:532)
13  libwireshark.14.dylib   0x000108b1cc5a read_prefs + 26 
(prefs.c:4343)
14  libwireshark.14.dylib   0x000108b00fb0 epan_load_settings + 
16 (epan.c:318)
15  org.wireshark.Wireshark 0x0001070a8759 main + 2105
16  libdyld.dylib   0x7fff684fecc9 start + 1


Going down the rabbit hole...



___
Sent via:Wireshark-dev mailing list 
Archives: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] Revive the happy-shark repository?

[Jaap Keuter]

Hi,

As for the options proposed by Dario,
1) git submodules basically pins a specific commit of an external repository 
into your repository. It also requires additional git commands to checkout and 
move the ‘pin’ forward when anything is added to the external repo which is 
desired in the git repo. In my experience it is useful to include specific 
(release-)tags from external libraries, which develop on their own pace, not s 
much for development in parallel which is our use case.
2) git lfs could be interesting, but also makes it more complex for users, 
needing to install additional git features. In my experience something to be 
used strategically, I was a bit underwhelmed when finding 128 byte capture 
files stored with git lfs.

Although I’ve little experience with happy-shark, in theory I would like to see 
a (especially a TCP) test suite independent of Wireshark version, which is 
could probably best served by happy-shark.

Thanks,
Jaap


> On 22 Jan 2021, at 21:15, Dario Lombardo  wrote:
> 
> Talking about your options:
> 1) my concern here is that we would have 2 repos, with parallel lifecycles, 
> that are not enforced to stay aligned. A change in a dissector would benefit 
> from a test case, but such a testcase in happy-shark would be proposed after 
> the code merge in the main repo. That would slow down the process, wouldn't 
> it?
> 2) this is the current situation. Ideal in the sense that a change carries 
> the code and the testcase. Suboptimal because as soon as the testcases grow, 
> the repo gets too heavy, as you said.
> 
> If the concern is not to make the repo too heavy we may investigate other 
> options as well.
> 1) use git submodules
> 2) use git lfs
> Option 2 sounds promising: "Git Large File Storage (LFS) replaces large files 
> such as audio samples, videos, datasets, and graphics with text pointers 
> inside Git". We do have a dataset. Moreover gitlab.com  
> supports LFS.
> Unfortunately I don't have direct experience with either submodules and lfs, 
> hence I cannot provide more than just raw ideas.
> 
> On Fri, Jan 22, 2021 at 6:25 PM Gerald Combs  > wrote:
> Hi all,
> 
> Years ago we added a repository for dissector regression tests at 
> https://github.com/wireshark/happy-shark 
> . Unfortunately it hasn't received 
> much attention, and instead we've been adding dissector tests in the main 
> repository. Should we
> 
> - Import happy-shark into GitLab and move our current dissector tests there?
> 
> - Retire happy-shark and do all of our testing in the main repository?
> 
> - Something else?
> 
> I'm leaning toward the first option for the simple reason that it will 
> minimize the number of files we accrue in test/captures.
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives: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] Wireshark dissector does not match spec for IEEE P802.1AS-Rev/D8.0

[Jaap Keuter]

> On 20 Jan 2021, at 11:46, Ari Timonen  wrote:
> 
> The specification IEEE P802.1AS-Rev/D8.0 page 155 has the correct TLV flags.


Hi,

Looking in IEEE Std 802.1AS-2011, at table 10-14 it lists

Bit

Name

1

computeNeighborRateRatio

2

computeNeighborPropDelay


What draft are you referencing? Is that an update to the 2011 standard?

Thanks,
Jaap



___
Sent via:Wireshark-dev mailing list 
Archives: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] Setcap in ubuntu 20.04

[Jaap Keuter]

Hi,

Yes, I’ve seen this some time ago, and Gerald bumped into it also.

What I do as a workaround, is to add a symlink in the build directory: 
libwsutil.so.0 -> run/libwsutil.so.0

Thanks,
Jaap


> On 6 Jan 2021, at 22:19, João Valverde via Wireshark-dev 
>  wrote:
> 
> 
> 
> On 06/01/21 20:32, Dario Lombardo wrote:
>> Another user on SO suggested a fix
>> 
>> https://stackoverflow.com/questions/58255970/wireshark-dumpcap-with-setcap-set-to-no-root-capture-failes-to-start-in-ubuntu-1
>>  
>> 
>> 
>> However I'm pretty sure I've run wireshark from the build dir before with 
>> setcap.
> 
> 
> The change in behaviour might be because of the upgrade of glibc (system 
> libc).
> 
> Anyway see ld.so(8) "Secure-execution mode". And [1] and [2].
> 
> [1] https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH_USE_ORIGIN.html 
> .
> [2] 
> https://gitlab.com/wireshark/wireshark/-/commit/f3f97e976ba67140cac53471a1f84f77badf1ec6
>  
> 
> 
> 
>> 
>> On Wed, Jan 6, 2021 at 9:20 PM Dario Lombardo > > wrote:
>> Hi
>> I got a new laptop and I took the chance to upgrade my OS. Now I have Ubuntu 
>> 20.04. Today I had an unexpected behavior. After compilation, I issued the 
>> setcap command, but then I got:
>> 
>> $ sudo setcap cap_net_raw,cap_net_admin=eip run/dumpcap
>> $ ./run/dumpcap -D
>> ./run/dumpcap: error while loading shared libraries: libwsutil.so.0: cannot 
>> open shared object file: No such file or directory
>> 
>> Removing the capabilities gave my dumpcap back.
>> 
>> $ sudo setcap -r run/dumpcap
>> $ ./run/dumpcap -D
>> 1. wlp59s0
>> 2. nlmon0
>> 3. lo (Loopback)
>> [...]
>> 
>> Another user from ask, hit the same problem, like 1 year ago, on ubuntu 18: 
>> https://ask.wireshark.org/question/12115/wireshark-dumpcap-with-setcap-set-to-no-root-capture-failes-to-start-in-ubuntu-1810/
>>  
>> 
>> I'm still trying to figure out if I made other configurations before, but I 
>> can't recall anything useful.
>> Any ideas?
>> Thanks.
>> Dario.
>> -- 
>> Naima is on the broom.
>> 
>> 
>> -- 
>> 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] Software requirements specification

[Jaap Keuter]

On 30-12-2020 10:37, Anna Gkika Zosan wrote:

Greetings,

My name is Anna and I am relatively new to open source programming. I’m really 
interested in writing a SRS about Wireshark. Is there already one or having one 
is something that could be used?


Thank you in advance



Hello,

Welcome to the world of FOSS. As you may have picked up already FOSS projects 
can be _very_ different in nature. Some are rather formal, with requirement, 
architecture and design documentation, while others are just a loose knit group 
of individuals working toward some (imaginary) ultimate goal. If you want to get 
a grasp of what the Wireshark project is, have a look at the SharkFest'19 
keynote by the project leader Gerald Combs, and friends: 
https://youtu.be/lAc6DCxdF2o
As you may notice from this, the project is not that formal, while it tries to 
deploy robust software engineering techniques (always room for improvement). 
Also there's no explicit requirements stated, other than an objective (see if 
you can find it). In time the program has organically grown to achieve that 
objective to an ever increasing extend. Still basic requirements could be 
distilled from the current design.
This is not something you usually see, so is this some study assignment to 
create an SRS?


Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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 : 9.6. How to produce protocol stats

[Jaap Keuter]

Hi,

Thanks for having a look and reporting back. This could have been done as a 
merge request, this works as well. I’ve created one on your behalf, see WSDG: 
update protocol stats section to match current API 


Further comments are inline.

Thanks,
Jaap

> On 20 Dec 2020, at 10:32, wsgd  wrote:
> 
> Hello all,
> 
> 
> Questions/remarks about 
> https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectStats.html
> 
> 
> 1) An include is missing :
> Solution :
> Add #include 
> 

Done

> 
> 2) msgtypevalues does not exist
> Solution :
> Replace "msgtypevalues" by "packettypenames"
>  to be conform with previous § 9.2.3. Improving the dissection information 
> (https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html)
> 

Done

> 
> 3) st_node_packets = stats_tree_create_node(st, st_str_packets, 0, TRUE); 
> does not compile
> Solution :
> Replace it by :
> st_node_packets = stats_tree_create_node(st, st_str_packets, 0, 
> STAT_DT_INT, TRUE);
> 

Done

> 
> 4) foo_stats_tree_packet has bad prototype
> Solution :
> foo_stats_tree_packet should return tap_packet_status / TAP_PACKET_REDRAW 
> (instead of int / 1)
> 
> 

Done

> 
> About register_foo_stat_trees
> 
> 5) WS_DLL_PUBLIC_DEF void plugin_register_tap_listener(void) does not compile 
> :
> 1>T:\wireshark\dev\build_sources_3.4--win64\wireshark\plugins\epan\foo\packet-foo.c(192,1):
>  error C2491: 'plugin_register_tap_listener' : définition de fonction 
> dllimport non autorisée
> 1>Génération du projet "foo.vcxproj" terminée -- ÉCHEC.
> "Solution" :
> Use __declspec(dllexport) instead of WS_DLL_PUBLIC_DEF
> 

Nope, this is what ws_symbol_export.h is in place for, to have a cross platform 
abstraction of dynamically linked identifiers. The build system has to take 
care of this, the Windows one is especially finicky about the details.

> 
> 6) __declspec(dllexport) void plugin_register_tap_listener(void) is never 
> called
> Solution ? :
> - remove it
> - call directly register_foo_stat_trees(); from proto_reg_handoff_foo
> 
> It is the good way to do ?
> 

Again, this is what the build system is taking care of, to create cross 
platform abstractions of the dynamic link linking.

> 
> Thanks,
> Olivier
> 

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

[Wireshark-dev] ZLIB on macOS build discrepancy?

[Jaap Keuter]

Hi,

Not that it bothers me too much but I noticed (another) library mismatch in 
3.4.2 

tools/macos_setup.sh sports ZLIB_VERSION=1.2.11, while About Wireshark (3.4.2) 
states “with zlib 1.2.8,”.

Looking at my currently installed 3.4.0, it says "with zlib 1.2.11,” so it 
seemed to have rolled back somehow?

Thanks,
Jaap


___
Sent via:Wireshark-dev mailing list 
Archives: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] Regarding Wireshark plugin project

[Jaap Keuter]

Hi Martin,

FYI: the OBD-II dissector was already included in Wireshark 3.4
Hope someone can help you out.

Thanks,
Jaap

> On 11 Dec 2020, at 08:49, Martin Falch  wrote:
> 
> Hi Wireshark Developers,
> 
> I tried sending a mail some time ago for a paid project on a Wireshark 
> plugin, but I don't think it came through. I was recommended to try and send 
> it again.
> 
> The project is described below and I'd be interested in hearing from any 
> developers that think this could be a good fit for their skills: 
> 
> https://docs.google.com/document/d/15zzjpKIn-gwIC0F_U15IoK4JPtfc0ZZoV-NSkVzk6ew/edit
>  
> 
> 
> best,
> Martin
> 
> Martin Falch
> CSS Electronics 
> 
> 
> Den 16. november 2020 kl. 16.28.02 +01.00, skrev Martin Falch 
> :
>> Hi Wireshark team,
>> 
>> As per this thread, we're looking for a developer to help out on a small 
>> freelance project to update a Wireshark plugin. The project is described 
>> here 
>> .
>>  If you are interested, please let me know.
>> 
>> best,
>> Martin
>> 
>> Martin Falch
>> CSS Electronics 
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] clang-tools on Windows source code

[Jaap Keuter]

> On 11 Dec 2020, at 22:36, Gerald Combs  wrote:
> 
> validate-clang-check.sh doesn't exist in master-3.2. It started out as 
> validate-clang-check.py, but was migrated to a shell script in master in 
> August in b586f2578. We should probably cherry-pick that to 3.2 and add 
> "#ifdef _WIN32" guards to file_dlg_win32.c to match console_win32.c.

Hi Gerald,

Thanks for having a look. And let's see what the pipelines do now :)

Thanks,
Jaap

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

[Wireshark-dev] clang-tools on Windows source code

[Jaap Keuter]

Hi,

When changing Win32 code the jobs run for master and release-3.4 borked on this:

4882$ sh -c '[ ! -e ../tools/validate-clang-check.sh ] || 
../tools/validate-clang-check.sh'
4883/builds/wireshark/wireshark/build/../ui/win32/file_dlg_win32.c:13:10: fatal 
error: 'tchar.h' file not found
4884#include 
4885 ^
48861 error generated.
4887Error while processing 
/builds/wireshark/wireshark/build/../ui/win32/file_dlg_win32.c.
4888/builds/wireshark/wireshark/build/../ui/win32/file_dlg_win32.c:13:10: fatal 
error: 'tchar.h' file not found
4889#include 
4890 ^
48911 error generated.
4892Error while processing 
/builds/wireshark/wireshark/build/../ui/win32/file_dlg_win32.c.

(see pipeline https://gitlab.com/wireshark/wireshark/-/pipelines/228408750)

Curiously enough the job for master-3.2 succeeded?

5176Built using clang Ubuntu Clang 10.0.1 .
5177$ sh -c '[ ! -e ../tools/validate-clang-check.sh ] || 
../tools/validate-clang-check.sh'
5178$ ninja checkAPI
5179[1/34] Running checkAPI_caputils-todo

(see pipeline https://gitlab.com/wireshark/wireshark/-/pipelines/228409358)

What’s the difference here? Both seem to be using the same script and 
clang-tools.

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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 does this not blow up?

[Jaap Keuter]

Not sure why there would be a difference, file_dlg_win32.c is the same between 
master and release-3.4.
OTOH, format_handle_wm_initdialog() is only called from export_file_hook_proc() 
on WM_INITDIALOG, but win32_export_file() has already setup print_args to 
print_dissections_as_displayed, so I can’t see a user following this code path. 
Still going to fix the code though.

Thanks,
Jaap

> On 11 Dec 2020, at 00:15, chuck c  wrote:
> 
> It does "blow up" with 3.5.0rc0. Not sure why it works with 3.4.1.
> 
> 
> On Thu, Dec 10, 2020 at 4:06 PM Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> wrote:
> Hi,
> 
> In "ui/win32/file_dlg_win32.c"
> 
> static void
> format_handle_wm_initdialog(HWND dlg_hwnd, print_args_t *args) {
> HWND cur_ctrl;
> ...
> switch (args->print_dissections) {
> case print_dissections_none:
> case print_dissections_collapsed:
> SendMessage(cur_ctrl, CB_SETCURSEL, 0, 0);
> break;
> case print_dissections_as_displayed:
> SendMessage(cur_ctrl, CB_SETCURSEL, 1, 0);
> break;
> case print_dissections_expanded:
> SendMessage(cur_ctrl, CB_SETCURSEL, 2, 0);
> >> No break statement??
> default:
> g_assert_not_reached();
> }
> 
> 

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

[Wireshark-dev] How does this not blow up?

[Jaap Keuter]

Hi,

In "ui/win32/file_dlg_win32.c"

static void
format_handle_wm_initdialog(HWND dlg_hwnd, print_args_t *args) {
HWND cur_ctrl;
...
switch (args->print_dissections) {
case print_dissections_none:
case print_dissections_collapsed:
SendMessage(cur_ctrl, CB_SETCURSEL, 0, 0);
break;
case print_dissections_as_displayed:
SendMessage(cur_ctrl, CB_SETCURSEL, 1, 0);
break;
case print_dissections_expanded:
SendMessage(cur_ctrl, CB_SETCURSEL, 2, 0);
>> No break statement??
default:
g_assert_not_reached();
}


___
Sent via:Wireshark-dev mailing list 
Archives: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] Problem with ENC_BCD_DIGITS_0_9 odd/even

[Jaap Keuter]

Hi,

Indeed a nasty one. You need sub-octet length indication here, which doesn’t 
exist. But since it’s limited to nibbles, a single flag is all that’s really 
needed.
Anything above the ENC_CHARENCODING_MASK would be fine. 

This would be the minimalist implementation of this:
proto_tree_add_item(subtree, hf_bcd_thing, tvb, offset, -1, ENC_KEYPAD_BC_TBCD 
| (odd ? ENC_BCD_ODD : 0));

Jaap

> On 9 Dec 2020, at 16:43, Anders Broman via Wireshark-dev 
>  wrote:
> 
> Hi,
> There is a problem with the BCD encoded numbers as they may be padded and 
> unfortunately with Zero.
>  
> “Encoding scheme: BCD. Note: Filler H’0 (last digit) is used in case of the 
> odd number of digits.” 
>  
> In order to present this properly
> It would be good to be able to pass an odd/even indicator, what would be the 
> preferred bits to use?
> #define ENC_BCD_ODD   0x1000
> #define ENC_BCD_EVEN  0x2000
>  
> If(odd){
>proto_tree_add_item(subtree, hf_cs1plus_gen_digits, parameter_tvb, 
> poffset, -1, ENC_KEYPAD_BC_TBCD| ENC_BCD_ODD );
> else
>proto_tree_add_item(subtree, hf_cs1plus_gen_digits, parameter_tvb, 
> poffset, -1, ENC_KEYPAD_BC_TBCD| ENC_BCD_EVEN);
>  
> Or some other solution?
>  
> Best regards
> Anders
>  
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives: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] G729

[Jaap Keuter]

Hi Balint,

Thank you for paying attention to this.

Regards,
Jaap

> On 8 Dec 2020, at 23:00, Bálint Réczey  wrote:
> 
> Hi Jaap,
> 
> Thanks for the heads up!:
> https://salsa.debian.org/debian/wireshark/-/commit/4f3b519334121ee8115f255d21c22f305e233cc2
> 
> Cheers,
> Balint
> 
> Jaap Keuter  ezt írta (időpont: 2020. dec. 7., H, 
> 12:04):
>> 
>> FYI, it seems to have finally happened, bcg729 has landed in Debian testing.
>> 
>> ---8<---
>> From: Debian FTP Masters 
>> To: 785480-cl...@bugs.debian.org
>> Subject: Bug#785480: fixed in bcg729 1.1.1-1
>> Date: Sun, 06 Dec 2020 13:00:08 +
>> Source: bcg729
>> Source-Version: 1.1.1-1
>> Done: Victor Seva 
>> 
>> We believe that the bug you reported is fixed in the latest version of
>> bcg729, which is due to be installed in the Debian FTP archive.
>> ---8<---
>> 
>> This opens the path to having G.729 capability in regular Debian and 
>> derivatives builds.
>> 
>> Jaap
>> 
>> On 6 Aug 2017, at 10:47, Jaap Keuter  wrote:
>> 
>> Hi  Dario,
>> 
>> I’ve already posted a note to Debian Bug 785480 ITP: bcg729 -- ITU G.729 
>> Annex A compatible audio codec 
>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785480) to make them 
>> aware of the recent Wireshark developments in this matter. Have a look there 
>> what’s going on with this packaging.
>> 
>> Thanks,
>> Jaap
>> 
>> 
>> 
>> On 5 Aug 2017, at 18:32, Dario Lombardo  wrote:
>> 
>> I've noticed that cmake shows me
>> 
>> -- The following OPTIONAL packages have not been found:
>> 
>> * BCG729 , G.729 decoder , 
>> <https://www.linphone.org/technical-corner/bcg729/overview>
>>   Support for G.729 codec in RTP player
>> 
>> Does anyone know which package in ubuntu/debian contains 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
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] G729

[Jaap Keuter]

FYI, it seems to have finally happened, bcg729 has landed in Debian testing.

---8<---
From: Debian FTP Masters 
To: 785480-cl...@bugs.debian.org
Subject: Bug#785480: fixed in bcg729 1.1.1-1
Date: Sun, 06 Dec 2020 13:00:08 +
Source: bcg729
Source-Version: 1.1.1-1
Done: Victor Seva 

We believe that the bug you reported is fixed in the latest version of
bcg729, which is due to be installed in the Debian FTP archive.
---8<---

This opens the path to having G.729 capability in regular Debian and 
derivatives builds.

Jaap

> On 6 Aug 2017, at 10:47, Jaap Keuter  wrote:
> 
> Hi  Dario,
> 
> I’ve already posted a note to Debian Bug 785480 ITP: bcg729 -- ITU G.729 
> Annex A compatible audio codec 
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785480 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785480>) to make them 
> aware of the recent Wireshark developments in this matter. Have a look there 
> what’s going on with this packaging.
> 
> Thanks,
> Jaap
> 
> 
> 
>> On 5 Aug 2017, at 18:32, Dario Lombardo > <mailto:dario.lombardo...@gmail.com>> wrote:
>> 
>> I've noticed that cmake shows me
>> 
>> -- The following OPTIONAL packages have not been found:
>> 
>>  * BCG729 , G.729 decoder , 
>> <https://www.linphone.org/technical-corner/bcg729/overview 
>> <https://www.linphone.org/technical-corner/bcg729/overview>>
>>Support for G.729 codec in RTP player
>> 
>> Does anyone know which package in ubuntu/debian contains 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

[Wireshark-dev] PAD file updates desired

[Jaap Keuter]

Hi,

Looking at the PAD file published for Wireshark 3.4.0 it seems it needs some 
tweaks.

- The Program_OS_Support item still lists Win7 x32 and Win7 x64, while support
is supposed to be ended.

- The Application_Screenshot_URL links to an image that shows the GTK+
interface, which can no longer be considered representative of the current GUI.

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

[Wireshark-dev] Automatic updates fail

[Jaap Keuter]

Hi Gerald,

Good morning.

The submission of automatic updates seems to fail, see 
https://gitlab.com/wireshark/wireshark/-/merge_requests/994

Thanks,
Jaap
___
Sent via:Wireshark-dev mailing list 
Archives: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] Tshark closing unexpectedly due to failure reading from file

[Jaap Keuter]

Hi,

From the issue report I saw that you’re using some development version “TShark 
(Wireshark) 3.1.0 (v3.1.0rc0-268-g09a04829)”. Can’t say it makes a difference 
in this case, but this is not recommended. If you could update to the latest 
3.2, or 3.4 release that would at least give us some stable footing.

Thanks,
Jaap

> On 16 Nov 2020, at 21:45, Alastair Scott  wrote:
> 
> 
> I've posted an in-depth description of the issue with logs and pcap's 
> attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013 
> 
> 
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] Marking GitLab issues as duplicates

[Jaap Keuter]

"Clear as mud” ;)

Thanks for sharing

> On 6 Nov 2020, at 02:57, Guy Harris  wrote:
> 
> If you type a / at the beginning of a comment, it pops up a menu of "quick 
> actions".
> 
> One of those actions is /dup{licate}.  If you type
> 
>   /duplicate #N
> 
> and save that comment, GitLab will mark the issue in which you make the 
> comment as a duplicate of issue #N.
> 
> This is extraordinarily well documented, in a place that's easy to find, just 
> as many other GitLab features are documented in a place easy to find./sarcasm.
> 
> I found it, after some Web searching, and following various GitLab issue 
> links for issues on GitLab itself, from
> 
>   https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10391
> 
> and
> 
>   https://docs.gitlab.com/ee/user/project/quick_actions.html
> 
> The first of those was the first one I found; annoyingly, the first thing 
> that a Google search for
> 
>   slash command gitlab
> 
> turned up was
> 
>   https://docs.gitlab.com/ee/integration/slash_commands.html
> 
> which has nothing to do with GitLab issues; the merge request called 
> /duplicate a "slash command", which led me to waste time with that search.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[Wireshark-dev] Tweak bug template to get _all_ version info

[Jaap Keuter]

Hi,

Again it’s seems difficult to get people to add _all_ version informalities 
when filing a bug report. Only the version string is copied then.

We’ve introduced a “Copy to clipboard’ button on the About Wireshark dialog for 
this. Can the template be adjusted to direct users to use that button and past 
the copied information?

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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] MATE not extracting fields as requested

[Jaap Keuter]

Hi Harald,

I've created issue 16961[1] on your behalf.

Thanks,
Jaap

[1] https://gitlab.com/wireshark/wireshark/-/issues/16961

On 24-10-2020 18:43, Harald Welte wrote:
> Hi Jaap,
> 
> thanks for your insight into the matter.  As you confirm there is an actual 
> bug, I will raise
> it in gitlab, together with extracts of your findings here.

___
Sent via:Wireshark-dev mailing list 
Archives: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] MATE not extracting fields as requested

[Jaap Keuter]

Hi,

Looking at the proto item modification functions there were a series of changes 
involving the (very tricky) optimisation considerations. Bug 10329 was the 
reason the latest optimisation was put in place.
Not wanting to mess with that there’s another way to address this. Adding the 
protocol tree root item is done with zero length and later extended, as 
described below. The better approach is to add the item with length -1, meaning 
until the end of the buffer. Then the protocol item does cover the fields MATE 
wants to extract. This has two possible issues though, first one is that it 
probably doesn’t cover reassembly well, another is that repeated protocols may 
cause problems extracting the desired value.

Looking for protocol items added with zero length this list comes up after a 
casual search:
gsm_um, netmon, cisco-erspan, isdn, wtp, atn-cm, hci-h1, slowprotocls, 
ieee80211-radio, pcomtcp, pktc, atalk, mgcp(!), epon, hci_h4, f5ethtrailer, 
aruba-erm, cisco-sm, pflog, clip, aruba-adp, mtp3.

These would potentially fall victim to the same problem.

Thanks,
Jaap


> On 23 Oct 2020, at 13:12, Jaap Keuter  wrote:
> 
> Hi,
> 
> Quick test shows that this is indeed the interaction between setting lengths 
> after prototree item creation and post dissectors. In fact _all_ proto item 
> modification functions need to be reviewed in this light.
> 
> Thanks,
> Jaap
> 
> 
>> On 23 Oct 2020, at 12:33, Jaap Keuter  wrote:
>> 
>> Hi,
>> 
>> Okay this is indeed weird. The MATE engine picks up the protocol but 
>> determines that the protocol fields are in a zero length part of the packet. 
>> It sees the fields, but these all fall outside of the zero length part of 
>> the packet (obviously). There is something specific about how the MGCP part 
>> of the packet dissection is set and that is that the protocol is added zero 
>> length to the protocol tree, and afterwards adjusted once its true length is 
>> found out. I can’t see why that makes a difference to MATE (being a post 
>> dissector, so running once all protocol dissection is done, so the MGCP 
>> protocol length is properly set), but we’ll have to see if this is somehow..
>> 
>> (Note to self: having the field length set _after_ adding field to tree, 
>> using proto_item_set_len() is subject to TRY_TO_FAKE_THIS_REPR_VOID. If that 
>> blocks length setting (because at first run tree=NULL) then all post 
>> dissectors, using this length are screwed).
>> 
>> Thanks,
>> Jaap
>> 
>>> On 17 Oct 2020, at 17:22, Harald Welte  wrote:
>>> 
>>> Dear wireshark developers,
>>> 
>>> the other problem I have with MATE is that for some protocols/dissectors
>>> I don't seem to be able to extract wireshark fields into MATE attributes.
>>> 
>>> Like in the last e-mail, I'm again working with the following MATE config
>>> https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
>>> 
>>> This time, I'm looking at MGCP traces.  The MATE config states:
>>> 
>>> ---
>>> Pdu mgcp_pdu Proto mgcp Transport udp/ip {
>>> Extract ip_addr From ip.addr;
>>> Extract port From udp.port;
>>> 
>>> Extract mgcp_rsp_code From mgcp.rsp.rspcode;
>>> Extract mgcp_verb From mgcp.req.verb;
>>> Extract mgcp_endpoint From mgcp.req.endpoint;
>>> Extract mgcp_conn_id From mgcp.param.connectionid;
>>> Extract mgcp_spec_endp_id From mgcp.param.specificendpointid;
>>> };
>>> ---
>>> 
>>> For some strnge reason, none of the mgcp.* fields are ever passed into MATE
>>> attributes.
>>> 
>>> Attached is again a pcap file for your reference.  In none of those
>>> packets, MATE extracts the named fields as attributes.  I've checked the
>>> field names several times, and they are correct.  Why are they not added
>>> to 'mgcp_pdu Attributes'?
>>> 
>>> Like the previous topic, I'm not reporting this as a bug as of yet, as
>>> I'm not sure it is a bug or I'm stimply not able to use MATE as
>>> expected.
>>> 
>>> Thanks in advance.
>>> 
>>> Regards,
>>> Harald
>>> 
>>> -- 
>>> - Harald Weltehttp://laforge.gnumonks.org/
>>> 
>>> "Privacy in residential applications is a desirable marketing option."
>>>(ETSI EN 300 175-7 Ch. A6)


mgcp.pcap
Description: application/vnd.tcpdump.pcap
>> 
>>> 
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives: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] MATE not extracting fields as requested

[Jaap Keuter]

Hi,

Quick test shows that this is indeed the interaction between setting lengths 
after prototree item creation and post dissectors. In fact _all_ proto item 
modification functions need to be reviewed in this light.

Thanks,
Jaap


> On 23 Oct 2020, at 12:33, Jaap Keuter  wrote:
> 
> Hi,
> 
> Okay this is indeed weird. The MATE engine picks up the protocol but 
> determines that the protocol fields are in a zero length part of the packet. 
> It sees the fields, but these all fall outside of the zero length part of the 
> packet (obviously). There is something specific about how the MGCP part of 
> the packet dissection is set and that is that the protocol is added zero 
> length to the protocol tree, and afterwards adjusted once its true length is 
> found out. I can’t see why that makes a difference to MATE (being a post 
> dissector, so running once all protocol dissection is done, so the MGCP 
> protocol length is properly set), but we’ll have to see if this is somehow..
> 
> (Note to self: having the field length set _after_ adding field to tree, 
> using proto_item_set_len() is subject to TRY_TO_FAKE_THIS_REPR_VOID. If that 
> blocks length setting (because at first run tree=NULL) then all post 
> dissectors, using this length are screwed).
> 
> Thanks,
> Jaap
> 
>> On 17 Oct 2020, at 17:22, Harald Welte  wrote:
>> 
>> Dear wireshark developers,
>> 
>> the other problem I have with MATE is that for some protocols/dissectors
>> I don't seem to be able to extract wireshark fields into MATE attributes.
>> 
>> Like in the last e-mail, I'm again working with the following MATE config
>> https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
>> 
>> This time, I'm looking at MGCP traces.  The MATE config states:
>> 
>> ---
>> Pdu mgcp_pdu Proto mgcp Transport udp/ip {
>> Extract ip_addr From ip.addr;
>> Extract port From udp.port;
>> 
>> Extract mgcp_rsp_code From mgcp.rsp.rspcode;
>> Extract mgcp_verb From mgcp.req.verb;
>> Extract mgcp_endpoint From mgcp.req.endpoint;
>> Extract mgcp_conn_id From mgcp.param.connectionid;
>> Extract mgcp_spec_endp_id From mgcp.param.specificendpointid;
>> };
>> ---
>> 
>> For some strnge reason, none of the mgcp.* fields are ever passed into MATE
>> attributes.
>> 
>> Attached is again a pcap file for your reference.  In none of those
>> packets, MATE extracts the named fields as attributes.  I've checked the
>> field names several times, and they are correct.  Why are they not added
>> to 'mgcp_pdu Attributes'?
>> 
>> Like the previous topic, I'm not reporting this as a bug as of yet, as
>> I'm not sure it is a bug or I'm stimply not able to use MATE as
>> expected.
>> 
>> Thanks in advance.
>> 
>> Regards,
>>  Harald
>> 
>> -- 
>> - Harald Weltehttp://laforge.gnumonks.org/
>> 
>> "Privacy in residential applications is a desirable marketing option."
>> (ETSI EN 300 175-7 Ch. A6)


mgcp.pcap
Description: application/vnd.tcpdump.pcap
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives: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] MATE not extracting fields as requested

[Jaap Keuter]

Hi,

Okay this is indeed weird. The MATE engine picks up the protocol but determines 
that the protocol fields are in a zero length part of the packet. It sees the 
fields, but these all fall outside of the zero length part of the packet 
(obviously). There is something specific about how the MGCP part of the packet 
dissection is set and that is that the protocol is added zero length to the 
protocol tree, and afterwards adjusted once its true length is found out. I 
can’t see why that makes a difference to MATE (being a post dissector, so 
running once all protocol dissection is done, so the MGCP protocol length is 
properly set), but we’ll have to see if this is somehow..

(Note to self: having the field length set _after_ adding field to tree, using 
proto_item_set_len() is subject to TRY_TO_FAKE_THIS_REPR_VOID. If that blocks 
length setting (because at first run tree=NULL) then all post dissectors, using 
this length are screwed).

Thanks,
Jaap

> On 17 Oct 2020, at 17:22, Harald Welte  wrote:
> 
> Dear wireshark developers,
> 
> the other problem I have with MATE is that for some protocols/dissectors
> I don't seem to be able to extract wireshark fields into MATE attributes.
> 
> Like in the last e-mail, I'm again working with the following MATE config
> https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
> 
> This time, I'm looking at MGCP traces.  The MATE config states:
> 
> ---
> Pdu mgcp_pdu Proto mgcp Transport udp/ip {
> Extract ip_addr From ip.addr;
> Extract port From udp.port;
> 
> Extract mgcp_rsp_code From mgcp.rsp.rspcode;
> Extract mgcp_verb From mgcp.req.verb;
> Extract mgcp_endpoint From mgcp.req.endpoint;
> Extract mgcp_conn_id From mgcp.param.connectionid;
> Extract mgcp_spec_endp_id From mgcp.param.specificendpointid;
> };
> ---
> 
> For some strnge reason, none of the mgcp.* fields are ever passed into MATE
> attributes.
> 
> Attached is again a pcap file for your reference.  In none of those
> packets, MATE extracts the named fields as attributes.  I've checked the
> field names several times, and they are correct.  Why are they not added
> to 'mgcp_pdu Attributes'?
> 
> Like the previous topic, I'm not reporting this as a bug as of yet, as
> I'm not sure it is a bug or I'm stimply not able to use MATE as
> expected.
> 
> Thanks in advance.
> 
> Regards,
>   Harald
> 
> -- 
> - Harald Weltehttp://laforge.gnumonks.org/
> 
> "Privacy in residential applications is a desirable marketing option."
>  (ETSI EN 300 175-7 Ch. A6)


mgcp.pcap
Description: application/vnd.tcpdump.pcap
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] MATE, ip_addr and same source/est IP / loopback traffic

[Jaap Keuter]

Hi,

This is a tough one. Our resident MATE developer hasn’t been active for a while 
now, and so far no one has really picked it up. I did a quick test (after 
getting debugging working again) and found that the protocol fields are added 
to an ‘Address-Value-Pair-List’ (AVPL) on basis of uniqueness. I can see why 
that is, but I also see that this gives problems like this. It goes for the IP 
address, as in this case, but also for the port numbers. I wonder if it would 
be possible to box this in per packet instead of per field. It would require 
more study to see how to go about this.

I was briefly thinking about a workaround using ip.src and ip.dst instead of 
ip.addr, but then you end up with again a localhost specific Gop definition, 
e.g., Gop tcp_ses On tcp_pdu Match (srcaddr, dstaddr, port, port). That makes 
it unidirectional when you have different host addresses, so that probably 
won’t work either. Not sure where the solution is for this problem.

Regards,
Jaap


> On 17 Oct 2020, at 17:09, Harald Welte  wrote:
> 
> Dear wireshark developers,
> 
> I'm a big fan of MATE, but I've run into a couple of problems that I've been
> unable to resolve.  This mail is aabout the first problem:
> 
> It is customary to use 'Extract ip_addr From ip.adddr' in 'Pdu' definitions
> in order to extract the source and destination IP addresses.  This can then
> later be used in 'Gop' definitions like
> 
>   Gop rsl_lchan On rsl_pdu Match (ip_addr, ip_addr, port, port, ...)
> 
> In my experience, this works great for traffic that has different source and
> destination IP addresses.  In this situation, MATE extracts the two IP 
> addresses,
> and the Pdu contains two related attributes.   That in turn allows two ip_addr
> keys to be used like in the above-mentioned Gop example.
> 
> However, if the source IP address and destination IP address are identical
> (such as most commonly seen by two local applications talking over loopback
> with 127.0.0.1 on both ends), MATE is only adding a *single* ip_addr attribute
> to the Pdu.
> 
> That in turn seems to be causing the 'Gop' definition no longer matching,
> as it requires two ip_addr attributes :(  I can of course modify the Gop 
> definition
> to only uses ip_addr once, e.g. modify the above example to
> 
>   Gop rsl_lchan On rsl_pdu Match (ip_addr, port, port, ...)
> 
> And suddenly things will work.  But then they _only_ work for loopback 
> traffic,
> and not for other traffic with different source/dest IP addresses anymore.
> 
> I tried to add two Gop definitions, but then MATE also doesn't allow that,
> apparently there can only be one Gop definition for each PDU, not multiple 
> (alternative)
> ones.
> 
> So my question is: How am I support to write the Pdu + Gop rule in a way to
> work for both cases?
> 
> For a complete example, see the rsl_pdu and rsl_lchan definitions in
> https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
> For tose MATE rules, you can find two pcap files attached; also two 
> screenshots
> from the working vs. non-working case.
> 
> [please ignore the wrong ip header checksum in the localhost example, i 
> binary-patched
> the loopback address in there to make sure the IP address is really the only 
> difference
> in those files]
> 
> 
> Thanks in advance,
>   Harald
> 
> p.s.: My tests were don with wireshark Version 3.3.0 
> (v3.3.0rc0-1701-g4bea0e7c2ebf),
> but I've been seeing this problem in all my builds for at least 7 months now.
> 
> -- 
> - Harald Weltehttp://laforge.gnumonks.org/
> 
> "Privacy in residential applications is a desirable marketing option."
>  (ETSI EN 300 175-7 Ch. A6)


rsl-nolocalhost.pcap
Description: application/vnd.tcpdump.pcap


rsl-localhost.pcap
Description: application/vnd.tcpdump.pcap
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Trouble uploading Wireshark enhancement

[Jaap Keuter]

> On 23 Oct 2020, at 04:21, Fulko Hew  wrote:
> 
> I've enhanced a Lua based dissector, and have also rewritten it
> in 'C' so that it can be included in the next release of Wireshark.
> 
> Now I'm trying to submit it.  My last submission was back in 2007,
> and things have changed a little since then.
> 
> I believe? the latest doc on how to submit changes are in:
> 
> https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches#a-super-short-overview-of-git
>  
> 
> 
> After being a developer for 45 years, I never had to use git until now, so 
> I'll
> admit I don't know anything about git, and I'm trying to follow those 
> instructions.
> 
> I got to the point of 'commit' and then 'git push downstream +HEAD'
> and I get the error:
> 
> fatal: 'downstream' does not appear to be a git repository
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> What am I doing wrong?
> 
> 


Hi,

Indeed _a lot_ has changed over time, and we’re still shaking a little from the 
latest transition to GitLab. As a result the guidance and documentation is not 
yet settled. One of the things we as a group need to finalise is how we imagine 
the repository setup for developers to be. This is because in this case (i.e., 
with sites like GitLab and GitHub) you work with a ‘repository triangle’. This 
means you have the repo of the project (Wireshark), the 'fork' of the project 
on the web service's site, and your clone of the repo. Your clone of the repo 
can either be from the project repo, or from your forks repo. Either way, the 
repo you cloned from is referred to as ‘origin’. If you clone from the project 
repo you have no relation to your fork, in the web service. That is were you 
can add a remote for your clone, and this is imagined to be ‘downstream’. This 
is ‘somewhat’ described in the section ‘Migrating form Gerrit’ but that is also 
not completely suitable. As said the documentation is not yet settled. Anyway, 
depending on where you cloned from (project repo, or your clone), you can add a 
remote (downstream or upstream respectively) and use the name pointing to your 
clone to push to. 

Hope it makes sense,
Jaap

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

[Wireshark-dev] Working with the wiki clone

[Jaap Keuter]

Hi,

So, the GitLab Wiki has a ‘clone repository’ option and I thought to try it 
out. It simply lists what needs to be done, i.e. installing the gollum gem, 
cloning the Wiki repo and launching gollum from the directory when the clone 
is. 

Helas, no Wiki, just a 'Create page' for Home. After some back and forth, 
trying different things it struck me that gollum _insists_ on having a Home.md 
file as starting point. Our wiki repository has a home.md file, not Home.md. 
Renaming the file in my clone made everything work. I’m not sure how this all 
fits into the GitLab infrastructure, but ‘Home’ seems the prevailing name. 
Maybe we should adjust.

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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] So how are fixes cherry-picked to release branches?

[Jaap Keuter]

+1

Still working out the nooks and crannies of the review procedure itself, so 
this would be welcome.

> On 2 Sep 2020, at 10:02, Guy Harris  wrote:
> 
> Searching for "cherry" on the Wiki finds these pages:
> 
>   https://gitlab.com/wireshark/wireshark/-/wikis/Development/Backporting
> 
>   https://gitlab.com/wireshark/wireshark/-/wikis/Development/Workflow
> 
>   
> https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches/Git-Review
> 
> all of which contain the name "Gerrit".
> 
> We should probably update those to reflect whatever the new procedure is.

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

Re: [Wireshark-dev] Gitlab wiki search

[Jaap Keuter]

Indeed it’s a bit coarse. It seems improvements are planned, see 
https://docs.gitlab.com/ee/user/project/wiki/#customizing-sidebar 
, not sure 
what that will bring.

> On 22 Aug 2020, at 13:43, Graham Bloice  wrote:
> 
> Maybe I've missed something obvious, but there doesn't seem to be any way to 
> search the GitLab Wireshark wiki.  I can get a 45 page tabinated list of all 
> pages  with no hint of where in the alphabet page nnn might be and that's not 
> friendly.
> 
> I'm trying to find the "Submitting Patches" page which is a sub page of 
> Development.  Eventually I found Development on page 7 of the list and the 
> actual page I wanted on page 8 of the list.
> 
> I've now figured out that the GitLab search defaults to showing me things 
> from users, which had 0 results for "submitting patches" and I have to click 
> the "bubble" for Wikis to see the 12 results all of which show diffs of the 
> markdown but does actually have the page I want.
> 
> IMHO not really a wiki.
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] GSoD approved technical writer - community bonding phase

[Jaap Keuter]

> On 17 Aug 2020, at 16:07, Moshe Kaplan  wrote:
> 
> 1. The Wireshark manuals are written with docbook. The text is in the 
> wsug_src directory here: 
> https://gitlab.com/wireshark/wireshark/-/tree/master/docbook 
>  . Information 
> on submitting patches is available here: 
> https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches 
> 
Correction, the manual as written in AsciiDoc, using the AsciiDoctor toolchain: 
https://asciidoctor.org 

The development process is entering a state of flux, due to the pending move 
from Gerrit to GitLab. Thing will change in the coming time. There’s changes in 
the descriptions incoming, but it may be a bit turbulent at times.

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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] Filtering on a field when there is more than one such field in a Wi-Fi packet

[Jaap Keuter]

Hi Richard,

The display filter engine has no concept of individual instances of a field, 
either it’s there in a packet or not and its value is used in the expression. 
Where it is in the packet and in what relation to other fields in a display 
filter expression is of no concern of the display filter engine. It is a 
question that comes up once in a while, so its not unheard of, but no one has 
dared to venture into redoing the whole display filter engine design to make 
this possible. It would at least require an overhaul of the syntax, and I’m not 
even sure it is possible with the current dissection engine design.

Thanks,
Jaap

> On 13 Aug 2020, at 22:12, Richard Sharpe  wrote:
> 
> Hi folks,
> 
> I faced an interesting problem recently.
> 
> I was typing to find a particular tagged item with a tag length
> greater than a specific size.
> 
> This presented a problem because many Wi-Fi packets have tagged fields
> and a search filter like wlan.tag.number == X and wlan.tag.length >=
> some-value is prone to false positives if any tagged field in the
> frame has that number and any other tagged field in the frame has a
> length ge the value.
> 
> How can I limit the length comparison to the tag found in the first 
> comparison?
> 
> Do we even have that concept?
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] Protocol to tie Bugzilla entry to Gerrit change

[Jaap Keuter]

> On 13 Aug 2020, at 09:37, Guy Harris  wrote:
> 
> On Aug 13, 2020, at 12:24 AM, Jaap Keuter  wrote:
> 
>> For now(*) this is done as per 
>> https://wiki.wireshark.org/Development/SubmittingPatches#Writing_a_Good_Commit_Message
> 
> He's talking about comments in Gerrit, such as "this change broke XXX"; he's 
> not talking about commit messages in Git.

I’m sorry, but then this question is too convoluted for me, as non-native 
English speaker.

___
Sent via:Wireshark-dev mailing list 
Archives: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] Protocol to tie Bugzilla entry to Gerrit change

[Jaap Keuter]

Hi,

For now(*) this is done as per 
https://wiki.wireshark.org/Development/SubmittingPatches#Writing_a_Good_Commit_Message
 


(*) there’s a Big Move coming to a GitLab instance, this will Change 
Everything(tm).

Thanks,
Jaap

> On 12 Aug 2020, at 20:05, chuck c  wrote:
> 
> What is protocol to tie a bug entry 
> (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16771 
> )
> to a Gerrit change (https://code.wireshark.org/review/#/c/31973/ 
> )?
> 
> If only done in Bugzilla, will it languish out there till someone takes an 
> interest?
> 
> Or add a comment in Gerrit which I assume sends a note to some or all of the 
> people under Owner, Uploader, Reviews,   ?
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] Some apparent type bugs

[Jaap Keuter]

Hi,

Okay, I’ve pushed a change (38004 ) 
for the first ones.

Thanks,
Jaap

> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>  wrote:
> 
> I won't have time to look into these properly for a few days - if anyone else 
> does please feel free to check/fix them.
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] Some apparent type bugs

[Jaap Keuter]

Hi,

Don’t know, just noticed the UINT part and thought about returning 'a value' 
should be possible.
Will have to look into this more closely to see if and what makes sense.

Thanks,
Jaap


> On 31 Jul 2020, at 14:05, John Thacker  wrote:
> 
> 
> On Fri, Jul 31, 2020 at 7:51 AM Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> wrote:
> Hi,
> 
> Shouldn’t these be supported? After all, they have a UINT.
> 
>> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>> mailto:wireshark-dev@wireshark.org>> wrote:
>> 
>> Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at 
>> ./tools/../epan/dissectors/packet-ppp.c 2377 with type FT_UINT_BYTES
>> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
>> 'FT_UINT8'} )
>> 
>> Error: proto_tree_add_item_ret_uint (.., hf_slsk_directory_name , ...) 
>> called at ./tools/../epan/dissectors/packet-slsk.c 1051 with type 
>> FT_UINT_STRING
>> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
>> 'FT_UINT8'} )
> 
> 
> There's a UINT passed in that's the fixed length of the length field, there's 
> the total length (which is the value in the length field of
> the variable bytes plus the passed in fixed UINT) returned by 
> proto_tree_add_item_ret_length(), and then there's the value of the
> variable length field only.
> 
> Is the proposed change to have proto_tree_add_item_ret_uint() return the 
> value contained in the variable length field
> instead of the total length? Is that ever necessary? Shouldn't in most cases 
> just _ret_length() be used instead?
> 
> 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

Re: [Wireshark-dev] Some apparent type bugs

[Jaap Keuter]

Hi,

This one you probably have to look into yourself, because that’s not from the 
published code base, AFAIKT.

Thanks,
Jaap

> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>  wrote:
> 
> I won't have time to look into these properly for a few days - if anyone else 
> does please feel free to check/fix them.
> 
> Error: proto_tree_add_item_ret_uint (.., hf_ecpri_address , ...) called at 
> ./tools/../epan/dissectors/packet-ecpri.c 304 with type FT_UINT48
> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
> 'FT_UINT8'} )

___
Sent via:Wireshark-dev mailing list 
Archives: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] Some apparent type bugs

[Jaap Keuter]

Hi,

This is the script tripped up by inserted comments I’m afraid.

Thanks,
Jaap

> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>  wrote:
> 
> Error: proto_tree_add_item_ret_uint64 (.., hf_epl_od_uint , ...) called at 
> ./tools/../epan/dissectors/packet-epl.c 2744 with type 
> (allowed types are {'FT_UINT48', 'FT_UINT56', 'FT_UINT64', 'FT_UINT40'} )

___
Sent via:Wireshark-dev mailing list 
Archives: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] Some apparent type bugs

[Jaap Keuter]

Hi,

Shouldn’t these be supported? After all, they have a UINT.

> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>  wrote:
> 
> Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at 
> ./tools/../epan/dissectors/packet-ppp.c 2377 with type FT_UINT_BYTES
> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
> 'FT_UINT8'} )
> 
> Error: proto_tree_add_item_ret_uint (.., hf_slsk_directory_name , ...) called 
> at ./tools/../epan/dissectors/packet-slsk.c 1051 with type FT_UINT_STRING
> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
> 'FT_UINT8'} )

Thanks,
Jaap

___
Sent via:Wireshark-dev mailing list 
Archives: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] Some apparent type bugs

[Jaap Keuter]

Hi Anders,

This code in packet-pfcp.c, line 7482 looks wrong to me

/* Octet 5 to 20   NF Instance ID */
proto_tree_add_item_ret_uint(tree, hf_pfcp_nf_instance_id, tvb, offset, 1, 
ENC_BIG_ENDIAN, _length);

Isn’t this supposed to be

/* Octet 5 to 20   NF Instance ID */
proto_tree_add_item(tree, hf_pfcp_nf_instance_id, tvb, offset, id_length, 
ENC_BIG_ENDIAN);
offset += id_length;

Thanks,
Jaap

> On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev 
>  wrote:
> 
> Error: proto_tree_add_item_ret_uint (.., hf_pfcp_nf_instance_id , ...) called 
> at ./tools/../epan/dissectors/packet-pfcp.c 7482 with type FT_GUID
> (allowed types are {'FT_CHAR', 'FT_UINT32', 'FT_UINT24', 'FT_UINT16', 
> 'FT_UINT8'} )

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

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

[Jaap Keuter]

Hi,

I can see both points of view. However, I think we can retain the code as is 
for ENC_NA (== ENC_BIG_ENDIAN) and add code to handle the ENC_LITTLE_ENDIAN 
case to it. This should not break any existing code, the choice ENC_NA = 
ENC_BIG_ENDIAN was made in that light.
I think it's not in there now because we never encountered a protocol like 
this, AFAIK.

Thanks,
Jaap

> On 30 Jul 2020, at 09:26, Tomasz Moń  wrote:
> 
> On Thu, Jul 30, 2020 at 9:18 AM Roland Knall  wrote:
>> 
>> Putting the complexity in the common code will increase the complexity for a 
>> lot of other stuff which relies on this functionality. Also you run the risk 
>> of increasing dissection time for more protocols, then if you handle it 
>> specifically.
>> 
>> That would be my reasoning against it
> 
> Having the function take quite important parameter (encoding) and not
> using it at all is pretty bad. When someone tries to use
> tvb_get_bits() with ENC_LITTLE_ENDIAN the issue becomes apparent.

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

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

[Jaap Keuter]

:)

> On 30 Jul 2020, at 09:19, Tomasz Moń  wrote:
> 
> On Thu, Jul 30, 2020 at 8:58 AM Tomasz Moń  <mailto:deso...@gmail.com>> wrote:
>> 
>> On Thu, Jul 30, 2020 at 8:30 AM Jaap Keuter  wrote:
>>> Let’s put a hypothetical here, a 7 bit value spanning 2 octets:
>>> 
>>> 15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>> |  |  |  |  |  |  | 6| 5| 4| 3| 2| 1| 0|  |  |  |
>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>> 
>>> This would be the typical interpretation, as seen in network protocols.
>>> 
>>> Your suggestion is that the interpretation can also be:
>>> 
>>> 15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>>> |  |  |  |  |  |  | 1| 0| 6| 5| 4| 3| 2|  |  |  |
>>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> 
>> This is not what I wanted to write. Assuming you meant two octets, and
>> the bitmask on the 16-bit value is 0x1FC0 then the alternative
>> interpretation would be:
>>  15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>> |  |  |  |  |  |  | 4| 3| 2| 1| 0| 6| 5|  |  |  |
>> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> 
> Sorry, I should have displayed that in a fixed font earlier! It is
> perfectly clear then (the bitmask in your example is 0x03F8, and not
> 0x1FC0 as I was led to believe due to trying to figure it out on font
> not suited for the task)

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

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

[Jaap Keuter]

Hi,

Let’s put a hypothetical here, a 7 bit value spanning 2 octets:

 15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  | 6| 5| 4| 3| 2| 1| 0|  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

This would be the typical interpretation, as seen in network protocols.

Your suggestion is that the interpretation can also be:

 15 14 13 12 11 10  9  8| 7  6  5  4  3  2  1  0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  |  |  |  |  |  | 1| 0| 6| 5| 4| 3| 2|  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Here the first interpretation is a simple matter of mask and shift, the second 
interpretation is somewhat more involved. Since the first interpretation is 
common in network protocols (and efficient to handle) the code was made with 
that in mind. 

Thanks,
Jaap


> On 30 Jul 2020, at 08:06, Tomasz Moń  wrote:
> 
> Hello,
> 
> The tvb_get_bits() function family contains following comment:
>/* note that encoding has no meaning here, as the tvb is
> considered to contain an octet array */
> 
> I don't understand the reason. What am I missing?
> 
> The actual octets in tvb contain the bits ordered as expected, so the
> MSB/LSB-first problem within the octet itself does not apply (and I
> think this is what the comment refers to). However, when the bit field
> (e.g. 11 bits) spans across multiple octets, then the endianness does
> matter (i.e. which of the two octets contains the more significant
> part of the 11-bit value). Simply assuming Big Endian at the
> cross-octet boundary prevents USB HID dissection from using
> tvb_get_bits() directly because USB uses Little Endian.
> 
> Best Regards,
> Tomasz Moń

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

Re: [Wireshark-dev] Code Coverage Measurement of Wireshark - Outdated Instruction

[Jaap Keuter]

Sounds to me as something that could be made into a build option, but that’s 
just ’shooting from the hip’, I haven’t looked at the CMake files yet.

> On 28 Jul 2020, at 11:11, Peimann, Jannis 
>  wrote:
> 
> Okay, I was able to find a workaround.
>  
> I changed the following inside the main CMakeLists.txt inside my Wireshark 
> 3.2.4 root directory and rebuild Wireshark:
>  
> Line 500 (add code coverage compiler flags; changed extension from *.c.gcno 
> to *.gcno):
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fprofile-arcs -ftest-coverage")
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fprofile-arcs -ftest-coverage")
> set(CMAKE_C_OUTPUT_EXTENSION_REPLACE 1)
> set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE 1)
>  
> Line 750 (Added -lgcov for GCOV and LCOV integration):
> set(WIRESHARK_LD_FLAGS
># See also CheckCLinkerFlag.cmake
>-Wl,--as-needed
># -flto
># -fwhopr
># -fwhole-program
>-lgcov 
> )
>  
>  
> *.gcda and *.gcno file location in Ubuntu:
> /*/build-ninja/plugins/epan/dissector_name/CMakeFiles/dissector_name.dir/
>  
>  
> Evaluation commands:
> local@vxu-1804: ~/*/build-ninja
> lcov -c -d . -o coverage.lcov
> mkdir lcov-output
>  
> genhtml -o lcov-output/ coverage.lcov
> or with source error ignoration:
> genhtml –ignore-errors source -o lcov-output/ coverage.lcov
>  
>  
> Maybe this helps someone else.
>  
> Is this a good way, or is there a better/preferred way to do it?
>  
>  
> Von: Wireshark-dev  Im Auftrag von 
> Peimann, Jannis
> Gesendet: Montag, 27. Juli 2020 13:07
> An: wireshark-dev@wireshark.org
> Betreff: [Wireshark-dev] Code Coverage Measurement of Wireshark - Outdated 
> Instruction
>  
> Hello together,
>  
> I created a small Dissector that I want to test now.
> Therefore I tried the Code Coverage Measurement from the Wireshark Wiki Page 
> but ran into some issues.
>  
> At first I have seen, that this page was updated the last time in 2008. 
> (wiki.wireshark.org/Development/CodeCoverage)
> These steps are not valid anymore:
>  
> ~/wireshark$ ./autogen.sh
> ~/wireshark$ ./configure CFLAGS=--coverage [options]
>  
> Starting with Wireshark 3.0.0, autotools is no longer supported, only cmake. 
> – According to this thread: Missing autogen.sh in 3.0.0 (Ask Wireshark Thread)
>  
> Could someone please update that Wiki entry or/and explain to me how I can 
> achieve this with CMake?
> Unfortunately I am not able to create *.gcno files with CMake.
> I guess some commands are different and I maybe have to change some CMake 
> Configuration Files.
>  
> For your interest, I use Ubuntu.
> GCC Version is 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
>  
> I tried this already but no *.gcno files were created:
> make clean && make CFLAGS=--coverage LDFLAGS=--coverage
>  
>  
> Thanks in advance for your help.
>  
>  
> Best regards,
>  
> Jannis Peimann
> 

___
Sent via:Wireshark-dev mailing list 
Archives: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] GurumNetworks RTPS Vendor ID Request

[Jaap Keuter]

Hi,

All changes have been implemented:
https://code.wireshark.org/review/#/c/37915/ 
<https://code.wireshark.org/review/#/c/37915/> 
https://code.wireshark.org/review/#/c/37929/ 
<https://code.wireshark.org/review/#/c/37929/> 
https://code.wireshark.org/review/#/c/37930/ 
<https://code.wireshark.org/review/#/c/37930/> 

If you want to try it you can download an automatic build here: 
https://www.wireshark.org/download/automated/ 
<https://www.wireshark.org/download/automated/>

Regards,
Jaap

> On 27 Jul 2020, at 06:31, 김다은  wrote:
> 
> Hi, 
> 
> If you have any updates on the vendor lists, please let me know. 
> Thank you so much.
> 
> Best,
> Daeun Kim
>  
> 2020년 7월 21일 (화) 오전 9:11, 김다은 님이 작성:
> Hi, 
> 
> Thank you so much for kind reply and updating the vendor list.
> 
> Sincerely,
> Daeun Kim
> 
> 2020년 7월 21일 (화) 오전 4:25, Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>>님이 작성:
> Hi,
> 
> This request triggered me to have a look at this vendor list as a whole. It 
> seems the currently coded list is outdated.
> Therefore I’ve taken the opportunity to update the complete list, thereby 
> adding GurumNetworks as well.
> 
> Thanks,
> Jaap
> 
>> On 20 Jul 2020, at 05:57, 김다은 mailto:da...@gurum.cc>> wrote:
>> 
>> Good evening.
>> I am Daeun Kim from GurumNetworks. 
>> Since our RTPS Vendor ID hasn't been applied to Wireshark yet, I want to 
>> make a request. However, I am not sure this is the right place where I 
>> request it. If it is not the right place to make a request, please send me 
>> the right email address to ask. 
>> Thank you.
>> 
>> Sincerely,
>> Daeun Kim
> 
> ___
> Sent via:Wireshark-dev mailing list  <mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>  mailto:wireshark-dev-requ...@wireshark.org 
> <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives: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] Using FTDI device ids from Linux kernel

[Jaap Keuter]

Hi,

Do you have any idea how volatile this data is, how quickly it’s changing?
There are already some data sets which are picked up weekly from external 
sources (e.g., IEEE manuf, PEN). This could be handled the same way if as 
volatile as these.

Thanks,
Jaap


> On 26 Jul 2020, at 11:01, Tomasz Moń  wrote:
> 
> Hello,
> 
> The Linux kernel FTDI SIO driver contains quite a comprehensive USB
> VID/PID database. The values are defined in
> linux/drivers/usb/serial/ftdi_sio_ids.h and are combined together in
> id_table_combined in linux/drivers/usb/serial/ftdi_sio.c. The protocol
> these devices use is being dissected by FTDI FT dissector.
> 
> FTDI FT dissector has its own short list of VID/PID pairs. How could
> we expand the list with the IDs from Linux kernel (I guess manually is
> one option, but that just sounds bad)?
> 
> Best Regards,
> Tomasz Moń

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

Re: [Wireshark-dev] proto_item_get_display_repr ignoring time zone

[Jaap Keuter]

That smells like a bug to me.

> On 23 Jul 2020, at 18:33, Thomas Wiens  wrote:
> 
> Hi,
> 
> I've noticed that when I add a timestamp in UTC time zone
> (ABSOLUTE_TIME_UTC) to the tree with proto_tree_add_time() it's displayd
> in UTC as expected. But when I get the string from this proto_item with
> proto_item_get_display_repr() then I get local time instead.
> 
> I've digged a little bit into this and found in ftype-time.c:
> 
> absolute_val_to_repr(fvalue_t *fv, ftrepr_t rtype, int field_display
> _U_, char *buf, unsigned int size)
> 
> that field_display is not used (which would contain ABSOLUTE_TIME_UCT).
> Instead it's set to ABSOLUTE_TIME_LOCAL, same in absolute_val_repr_len().
> 
> Is there a good reason for this or a bug?
> 
> --
> Cheers,
> 
> Thomas Wiens

___
Sent via:Wireshark-dev mailing list 
Archives: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] GurumNetworks RTPS Vendor ID Request

[Jaap Keuter]

Hi,

This request triggered me to have a look at this vendor list as a whole. It 
seems the currently coded list is outdated.
Therefore I’ve taken the opportunity to update the complete list, thereby 
adding GurumNetworks as well.

Thanks,
Jaap

> On 20 Jul 2020, at 05:57, 김다은  wrote:
> 
> Good evening.
> I am Daeun Kim from GurumNetworks. 
> Since our RTPS Vendor ID hasn't been applied to Wireshark yet, I want to make 
> a request. However, I am not sure this is the right place where I request it. 
> If it is not the right place to make a request, please send me the right 
> email address to ask. 
> Thank you.
> 
> Sincerely,
> Daeun Kim

___
Sent via:Wireshark-dev mailing list 
Archives: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] Issues in synphasor dissector

[Jaap Keuter]

Hi John,

Thanks for chipping in. There’s one blocking issue with these ideas though, 
they can’t be back ported to stable release(s).
Still these could be interesting additions to the dissection engine API, so you 
could either start a separate thread on this list with a well worked out 
proposal, or work through en enhancement bug.

Thanks,
Jaap

> On 7 Jul 2020, at 01:30, John Thacker  wrote:
> 
> 
> Well, there are two other options:
> 1) Adding the ability to do BASE_CUSTOM for FT_FLOAT and FT_DOUBLE 
> 2) Declaring as FT_[U]INT32 with BASE_CUSTOM, and do the type punning in the 
> custom function, as done in
> tvb_get_nttohieee_float() in tvbuff.c for when FT_FLOAT is used anyway. For 
> bonus points, implement (or export
> and make no longer static) get_ieee_float() in the same that exists for VAXen 
> and other non IEEE754 floating point
> machines where simple type punning won't work.
> 
> John Thacker
> 
> 
> 
> On Mon, Jul 6, 2020 at 5:51 PM Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> wrote:
> Hi,
> 
> So, you want to keep this function call:
> 
> proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, 
> ENC_BIG_ENDIAN);
> 
> with this header field definition:
> 
> { _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT,
> BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL, HFILL }}
> 
> but have it output "Unspecified Location" in case the value is +/- infinity.
> 
> Unfortunately the use of BASE_CUSTOM is not available for FT_FLOAT, so I see 
> no other way than this:
> 
> if (isinf(pmu_lat)) {
> proto_tree_add_float_format_value(wgs84_tree, hf_conf_pmu_lat_unknown, 
> tvb, offset, 4, INFINITY, unspecified_location);
> } else {
> proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, 
> ENC_BIG_ENDIAN);
> }
> 
> and these header field definitions:
> 
> { _conf_pmu_lat_unknown, { "PMU Latitude", "synphasor.conf.pmu_latitude", 
> FT_FLOAT,
> BASE_NONE, NULL, 0x0, NULL, HFILL }}
> { _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT,
> BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL, HFILL }}
> 
> Now at least the field abbrev "synphasor.conf.pmu_latitude" has a constant 
> type FT_FLOAT.
> 
> I hope I got this right.
> Jaap
> 
> 
> On 7/6/20 10:12 PM, Елисеев Дмитрий Алексеевич wrote:
>> Hello, Jaap Keuter!
>> I made some fast cheks and need some help.
>> I need some function like:
>> proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, 
>> ENC_BIG_ENDIAN);
>> { _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", 
>> FT_FLOAT,
>>   BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL, 
>> HFILL }}
>> 
>> witch replace Infinity with text: "Unspecified Location"
>> 
>> С уважением, 
>> 
>> Дмитрий Елисеев
>> инженер
>> сектора испытаний систем управления и автоматики
>> АО «НТЦ ЕЭС»
>> т:   29-29-499 доб. 214
>> a:   ул. Курчатова, д. 1, лит.А , Санкт-Петербург, Россия, 194223
>> e:   elis...@ntcees.ru <mailto:elis...@ntcees.ru>
>> 
>> 
>> От: Jaap Keuter  <mailto:jaap.keu...@xs4all.nl> 
>> Кому: Dmitriy Eliseev  <mailto:elisee...@ntcees.ru>, 
>> Developer support list for Wireshark  
>> <mailto:wireshark-dev@wireshark.org> 
>> Отправлено: 06.07.2020 19:10 
>> Тема: Issues in synphasor dissector 
>> 
>> Hi Dmitriy, 
>> 
>> There are still some issues with the synphasor dissector. There are a number 
>> of fields with the same field abbreviation, but incompatible type. 
>> These are lines from the 'conflict check' run by the buildbot: 
>> 
>> 'synphasor.conf.chnam_len' exists multiple times with NOT compatible types: 
>> FT_STRING and FT_UINT8 
>> 'synphasor.conf.phasor_flags' exists multiple times with NOT compatible 
>> types: FT_UINT16 and FT_BOOLEAN 
>> 'synphasor.conf.pmu_latitude' exists multiple times with NOT compatible 
>> types: FT_STRING and FT_FLOAT 
>> 'synphasor.conf.pmu_longitude' exists multiple times with NOT compatible 
>> types: FT_STRING and FT_FLOAT 
>> 'synphasor.conf.pmu_elevation' exists multiple times with NOT compatible 
>> types: FT_STRING and FT_FLOAT 
>> 
>> https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio
>>  
>> <https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio>

Re: [Wireshark-dev] Issues in synphasor dissector

[Jaap Keuter]

Hi,

So, you want to keep this function call:

proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, 
ENC_BIG_ENDIAN);/
/

with this header field definition:

{ _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT,
    BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL, HFILL }}

but have it output "/Unspecified Location/" in case the value is +/- infinity.

Unfortunately the use of BASE_CUSTOM is not available for FT_FLOAT, so I see no
other way than this:

if (isinf(pmu_lat)) {
    proto_tree_add_float_format_value(wgs84_tree, hf_conf_pmu_lat_unknown, tvb,
offset,4, INFINITY, unspecified_location);
} else {
    proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4,
ENC_BIG_ENDIAN);
}

and these header field definitions:

{ _conf_pmu_lat_unknown, { "PMU Latitude", "synphasor.conf.pmu_latitude",
FT_FLOAT,
    BASE_NONE, NULL, 0x0, NULL, HFILL }}
{ _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT,
    BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL, HFILL }}

Now at least the field abbrev "synphasor.conf.pmu_latitude" has a constant type
FT_FLOAT.

I hope I got this right.
Jaap


On 7/6/20 10:12 PM, Елисеев Дмитрий Алексеевич wrote:
> Hello, Jaap Keuter!
> I made some fast cheks and need some help.
> I need some function like:
> /proto_tree_add_item(wgs84_tree, hf_conf_pmu_lat, tvb, offset, 4, 
> ENC_BIG_ENDIAN);
> { _conf_pmu_lat, { "PMU Latitude", "synphasor.conf.pmu_latitude", FT_FLOAT,
> /
> /          BASE_NONE | BASE_UNIT_STRING, _degree_degrees, 0x0, NULL,
> HFILL }}/
> /
> /
> witch replace Infinity with text: "/Unspecified Location/"
>
> С уважением, 
>
> Дмитрий Елисеев
> /инженер/
> сектора испытаний систем управления и автоматики
> АО «НТЦ ЕЭС»
> т:    29-29-499 доб. 214
> a:ул. Курчатова, д. 1, лит.А , Санкт-Петербург, Россия, 194223
> e:elis...@ntcees.ru <mailto:elis...@ntcees.ru>
>
>
>
>
> *От: * Jaap Keuter 
> *Кому: * Dmitriy Eliseev , Developer support list for
> Wireshark 
> *Отправлено: * 06.07.2020 19:10
> *Тема: * Issues in synphasor dissector
>
> Hi Dmitriy,
>
> There are still some issues with the synphasor dissector. There are a
> number of fields with the same field abbreviation, but incompatible type.
> These are lines from the 'conflict check' run by the buildbot:
>
> 'synphasor.conf.chnam_len' exists multiple times with NOT compatible
> types: FT_STRING and FT_UINT8
> 'synphasor.conf.phasor_flags' exists multiple times with NOT compatible
> types: FT_UINT16 and FT_BOOLEAN
> 'synphasor.conf.pmu_latitude' exists multiple times with NOT compatible
> types: FT_STRING and FT_FLOAT
> 'synphasor.conf.pmu_longitude' exists multiple times with NOT compatible
> types: FT_STRING and FT_FLOAT
> 'synphasor.conf.pmu_elevation' exists multiple times with NOT compatible
> types: FT_STRING and FT_FLOAT
>
> 
> https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio
>
>
> You seem to be knowledgeable about this protocol and dissector. Would you
> be able to address these reported issues?
>
> Thanks,
> Jaap
>

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

[Wireshark-dev] Issues in synphasor dissector

[Jaap Keuter]

Hi Dmitriy,

There are still some issues with the synphasor dissector. There are a number of 
fields with the same field abbreviation, but incompatible type.
These are lines from the 'conflict check' run by the buildbot:

'synphasor.conf.chnam_len' exists multiple times with NOT compatible types: 
FT_STRING and FT_UINT8
'synphasor.conf.phasor_flags' exists multiple times with NOT compatible types: 
FT_UINT16 and FT_BOOLEAN
'synphasor.conf.pmu_latitude' exists multiple times with NOT compatible types: 
FT_STRING and FT_FLOAT
'synphasor.conf.pmu_longitude' exists multiple times with NOT compatible types: 
FT_STRING and FT_FLOAT
'synphasor.conf.pmu_elevation' exists multiple times with NOT compatible types: 
FT_STRING and FT_FLOAT

https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/12010/steps/conflict%20check/logs/stdio

You seem to be knowledgeable about this protocol and dissector. Would you be 
able to address these reported issues?

Thanks,
Jaap

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

[Wireshark-dev] WLAN bug?

[Jaap Keuter]

Hi Richard,

Have you seen these entries from conflict check:

** (process:12824): WARNING **: 08:16:29.502: Field 'Status code' 
(wlan.fixed.status_code) has a conflicting entry in its value_string: 125 is at 
indices 125 (Requested TCLAS processing has been terminated by the AP due to 
conflict with higher layer QoS policies) and 126 (Request denied because source 
address of request is inconsistent with local MAC address policy)


** (process:12824): WARNING **: 08:16:29.502: Field 'Status Code' 
(wlan.ric_data.status_code) has a conflicting entry in its value_string: 125 is 
at indices 125 (Requested TCLAS processing has been terminated by the AP due to 
conflict with higher layer QoS policies) and 126 (Request denied because source 
address of request is inconsistent with local MAC address policy)

Do you know how to address this?

Thanks,
Jaap

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

[Wireshark-dev] Nordic_ble bug?

[Jaap Keuter]

Hi Stig,

Have you seen this entry from conflict check:

** (process:12824): WARNING **: 08:16:29.526: Field 'MIC' 
(nordic_ble.mic_not_relevant) has identical true and false strings ("Only 
relevant when encrypted", "Only relevant when encrypted”)

Do you know how to address this?

Thanks,
Jaap

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

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

[Jaap Keuter]

Hi,

Okay, we should at least try to ‘pick the low hanging fruit’ of this. I’ve 
started with these already: 37694 <https://code.wireshark.org/review/37694>, 
37692 <https://code.wireshark.org/review/37692> and 37697 
<https://code.wireshark.org/review/37697> 
It would be great if at least the obvious cases 
<https://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20Petri%20Dish%20x64/builds/11982/steps/conflict%20check/logs/stdio>
 can be addressed.


Thanks,
Jaap


> On 5 Jul 2020, at 11:57, Alexis La Goutte  wrote:
> 
> Yes it is true ! But I don’t how to set orange with buildbot on this case, 
> some others step (clang analyzer check, pre commit...) need this.
> 
> And also if it is orange, it is not specific to this change..
> Le dim. 5 juil. 2020 à 11:16, Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> a écrit :
> Hi Alexis,
> 
> "issues are not yet fixed” sounds a bit weird for a reason for marking this 
> stage okay (green). That would be the same as... ignoring all the compilation 
> warnings.
> I’m not expecting it to be marked as error (red), but as warning (orange), 
> calling attention to it. Because I wonder how many are aware of these 
> reported issues.
> 
> Thanks,
> Jaap
> 
> 
>> On 5 Jul 2020, at 11:03, Alexis La Goutte > <mailto:alexis.lagou...@gmail.com>> wrote:
>> 
>> Hi Jaap,
>> 
>> It is beacuse all issue are not yet fixed (some coming from generated 
>> code... or missing spec info to known what the correct fix).
>> 
>> Personally, when review code after Petri dish, I try to look different 
>> output log, because I know don’t fail it is juste warning.
>> 
>> Le dim. 5 juil. 2020 à 08:53, Jaap Keuter > <mailto:jaap.keu...@xs4all.nl>> a écrit :
>> Hi,
>> 
>> Due to some recent issues with DHCPv6 the buildbot began flagging the 
>> 'conflict check' stage as failed. This drew my attention to the fact that 
>> there is a long list of warnings in there about wrong use of protocol 
>> fields, but once the DHCPv6 issues were fixed the build happily went back to 
>> green for the ‘conflict check’. Why is is not orange with the warning output?
>> 
>> This is the output of a recent build:
>> 
>> 'HI2Operations.latitude' exists multiple times with NOT compatible types: 
>> FT_UINT32 and FT_STRING
>> 'HI2Operations.longitude' exists multiple times with NOT compatible types: 
>> FT_INT32 and FT_STRING
>> 'HI2Operations.mcc' exists multiple times with NOT compatible types: 
>> FT_BYTES and FT_UINT32
>> 'HI2Operations.mnc' exists multiple times with NOT compatible types: 
>> FT_BYTES and FT_UINT32
>> 'HI2Operations.lai' exists multiple times with NOT compatible types: 
>> FT_BYTES and FT_UINT32
>> 'acse.result' exists multiple times with NOT compatible types: FT_INT32 and 
>> FT_UINT32
>> 'ain.notificationIndicator' exists multiple times with NOT compatible types: 
>> FT_BYTES and FT_BOOLEAN
>> 'ain.invoke' exists multiple times with NOT compatible types: FT_INT32 and 
>> FT_UINT32
>> 'ansi_683.reserved' exists multiple times with NOT compatible types: 
>> FT_UINT16 and FT_BOOLEAN
>> 'ansi_tcap.private' exists multiple times with NOT compatible types: 
>> FT_UINT32 and FT_INT32
> 
> 

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

Re: [Wireshark-dev] Why is conflict check on the buildbot green?

[Jaap Keuter]

Hi Alexis,

"issues are not yet fixed” sounds a bit weird for a reason for marking this 
stage okay (green). That would be the same as... ignoring all the compilation 
warnings.
I’m not expecting it to be marked as error (red), but as warning (orange), 
calling attention to it. Because I wonder how many are aware of these reported 
issues.

Thanks,
Jaap


> On 5 Jul 2020, at 11:03, Alexis La Goutte  wrote:
> 
> Hi Jaap,
> 
> It is beacuse all issue are not yet fixed (some coming from generated code... 
> or missing spec info to known what the correct fix).
> 
> Personally, when review code after Petri dish, I try to look different output 
> log, because I know don’t fail it is juste warning.
> 
> Le dim. 5 juil. 2020 à 08:53, Jaap Keuter  <mailto:jaap.keu...@xs4all.nl>> a écrit :
> Hi,
> 
> Due to some recent issues with DHCPv6 the buildbot began flagging the 
> 'conflict check' stage as failed. This drew my attention to the fact that 
> there is a long list of warnings in there about wrong use of protocol fields, 
> but once the DHCPv6 issues were fixed the build happily went back to green 
> for the ‘conflict check’. Why is is not orange with the warning output?
> 
> This is the output of a recent build:
> 
> 'HI2Operations.latitude' exists multiple times with NOT compatible types: 
> FT_UINT32 and FT_STRING
> 'HI2Operations.longitude' exists multiple times with NOT compatible types: 
> FT_INT32 and FT_STRING
> 'HI2Operations.mcc' exists multiple times with NOT compatible types: FT_BYTES 
> and FT_UINT32
> 'HI2Operations.mnc' exists multiple times with NOT compatible types: FT_BYTES 
> and FT_UINT32
> 'HI2Operations.lai' exists multiple times with NOT compatible types: FT_BYTES 
> and FT_UINT32
> 'acse.result' exists multiple times with NOT compatible types: FT_INT32 and 
> FT_UINT32
> 'ain.notificationIndicator' exists multiple times with NOT compatible types: 
> FT_BYTES and FT_BOOLEAN
> 'ain.invoke' exists multiple times with NOT compatible types: FT_INT32 and 
> FT_UINT32
> 'ansi_683.reserved' exists multiple times with NOT compatible types: 
> FT_UINT16 and FT_BOOLEAN
> 'ansi_tcap.private' exists multiple times with NOT compatible types: 
> FT_UINT32 and FT_INT32


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