[Wireshark-dev] Is this a known problem?
Hi folks, I installed 4.2.2 on a Windows Server 2012 system and got the following error: "The procedure entry point SystemParametersInfoForDpi could not be located in the dynamic link library ..." [image: image.png] Is there a work-around? -- 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
[Wireshark-dev] Resurrecting a discussion on being able to filter within embedded structures
Hi folks, Some time ago (back in August or September) I raised the subject of being able to filter within specific substructures in a particular protocol. This has come up in a couple of places now in ieee802.11 where they allow Informational Elements (IEs) (which are TLVs) to appear in other IEs, and also allow multiple instances of the first level of IEs. Specifically this came up in the context of handling the Multi-Link IE in 802.11be (Draft). I proposed an approach that used the concept of contexts where a filter expression could be of the form "sta_profile_1:wlan.tcprep.trsmt_pow[==28]" for either searching for frames within "sta_profile_1" (whatever that is) that contain the rest of the filter string or that actually match the value. There was some discussion on this but in the spirit of trying something instead of arguing about it interminably, and because the user needed it, I went ahead and implemented something in 3.4.8 (which they have currently standardized on.) This gave me a lot of understanding of the code in that area and had the upside that it worked. However, it also has some deficiencies: 1. There was no registration of those contexts so user couldn't easily find out about them, 2. It required adding special code to the dissectors that wanted to support this approach, 3. It only allows one level of contexts while it is conceivable that there will be situations in the future where there would be a need to say something like "find me packets where field "syz" within field "abc" within field "def" has value "qrs". That being the case I thought I would raise the issue again and propose something slightly different. The first thing to do is to make it more general by removing the need for these special contexts and I figured the easiest way to do that was to actually extend the existing filtering system and extend the syntax a little. Eg: "wlan.eht.multi_link.sta_profile==1:wlan.tcprep.trsmt_pow[==28]" The square brackets are not part of the syntax and just allow me to express two filters in one string. The benefit of doing this is that there should be no need to add special code and everything is registered. Of course the lexical scanner code will have to be changed to accept such filter strings but the added flexibility will be worth it, IMO. It will also lend itself well to allowing multiple levels of context without adding lots of extra code in dissectors. One issue with this approach is that you cannot use calls like proto_tree_add_subtree[_format] to add the substructures because you do not provide a filter string associated with the subtree you are adding so dissectors will have to use a combination of proto_tree_add_item and proto_item_add_subtree. I have manufactured capture files that have such cases so I can explore these concepts. However, there are likely to be many cases where dissector authors have used proto_tree_add_subtree et al, which means that such filtering will not always be possible. -- 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] How do I indicate that a commit or MR fixes an issue?
On Tue, Oct 18, 2022 at 10:54 AM chuck c wrote: > > https://wiki.wireshark.org/Development/SubmittingPatches#writing-a-good-commit-message > > As mentioned above, you can use "#" to reference issues. > "Closes #1234" is special – it will close issue 1234 when the change is > merged, while other references such as "see #4512" will simply link to the > issue. Thanks. Looks like I chose the wrong way :-( > On Tue, Oct 18, 2022 at 12:46 PM Richard Sharpe > wrote: >> >> Hi folks. >> >> What do I put in a commit message to indicate that it fixes an issue? >> >> -- >> Regards, >> Richard Sharpe >> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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
[Wireshark-dev] How do I indicate that a commit or MR fixes an issue?
Hi folks. What do I put in a commit message to indicate that it fixes an issue? -- 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] Max size of a field seems to be 240 for a dissector
On Tue, Oct 18, 2022 at 9:39 AM Pascal Quantin wrote: > > Hi Richard, > > Le mar. 18 oct. 2022 à 18:30, Richard Sharpe a > écrit : >> >> Hi folks, >> >> How do I squeeze more than 240 chars into a string field? > > You can't currently. As seen in epan/proto.h, you have the ITEM_LABEL_LENGTH > define set to 240 and that exists since ages. > >> >> I am trying to fix an issue with the beamforming matrices for 802.11ax >> and 802.11be and maybe 802.11ac. > > I guess you refer to https://gitlab.com/wireshark/wireshark/-/issues/18504 Yes. >> >> When I try to assemble all of a single SCIDX, I get this: >> >> S [truncated]: SCIDX: -122, phi11:57, phi21:34, phi31:59, phi41:8, >> phi51:52, phi61:18, phi71:14, psi21:10, psi31:8, psi41:1, psi51:5, >> psi61:5, psi71:3, psi81:4, phi22:33, phi32:22, phi42:22, phi52:10, >> phi62:41, phi72:59, psi32:8, psi42:3, >> -- >> >> Why is there an arbitrary limit? Is it because I am working with 3.4.8? > > No, it has been like this for 23 years according to Git blame. > Maybe it's time to display this matrix differently (with several lines?) > instead of appending all those infos in a single line? I tried that but the user finds it hard to work with. I have found a way to make the user happy, but of the spec changes to increase the number of angles needed we will run into the same problem. -- 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
[Wireshark-dev] Max size of a field seems to be 240 for a dissector
Hi folks, How do I squeeze more than 240 chars into a string field? I am trying to fix an issue with the beamforming matrices for 802.11ax and 802.11be and maybe 802.11ac. When I try to assemble all of a single SCIDX, I get this: S [truncated]: SCIDX: -122, phi11:57, phi21:34, phi31:59, phi41:8, phi51:52, phi61:18, phi71:14, psi21:10, psi31:8, psi41:1, psi51:5, psi61:5, psi71:3, psi81:4, phi22:33, phi32:22, phi42:22, phi52:10, phi62:41, phi72:59, psi32:8, psi42:3, -- Why is there an arbitrary limit? Is it because I am working with 3.4.8? -- 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
[Wireshark-dev] The font size used for the menu etc does not seem to change when I change the main window font size
Hi folks, I have noticed that I can increase the font size in the Main Window via preferences or I can click on the + button in the ribbon below the menu. However, nothing seems to increase the font size of the items in the menu or the headings of the columns. How can I do that? -- 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] proto_item_append_text info not being picked up when extracting fields via tshark
On Wed, Oct 12, 2022 at 11:10 AM Richard Sharpe
wrote:
>
> Hi folks,
>
> As a result of a recent issue and MR I suggested the use of tshark to
> extract some info but it does not work.
>
> I suggested this:
> --
> ./run/tshark -r ~/SNR* -Y "frame.number == 1" -Tfields -e
> "wlan.he.action.he_mimo_control.scidx"
> -500,-496,-492,-488,-484,-480,-476,-472,-468,-464,-460,-456,-452,-448,-444,-440,-436,-432,-428,-424,-420,-416,-412,-408,-404,-400,-396,-392,-388,-384,-380,-376,-372,-368,-364,-360,-356,-352,-348,-344,-340,-336,-332,-328,-324,-320,-316,-312,-308,-304,-300,-296,-292,-288,-284,-280,-276,-272,-268,-264,-260,-256,-252,-248,-244,-240,-236,-232,-228,-224,-220,-216,-212,-208,-204,-200,-196,-192,-188,-184,-180,-176,-172,-168,-164,-160,-156,-152,-148,-144,-140,-136,-132,-128,-124,-120,-116,-112,-108,-104,-100,-96,-92,-88,-84,-80,-76,-72,-68,-64,-60,-56,-52,-48,-44,-40,-36,-32,-28,-24,-20,-16,-12,-8,-4,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,180,184,188,192,196,200,204,208,212,216,220,224,228,232,236,240,244,248,252,256,260,264,268,272,276,280,284,288,292,296,300,304,308,312,316,320,324,328,332,336,340,344,348,352,356,360,364,368,372,376,380,384,388,392,396,400,404,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500
>
>
> However, if you look at what Wireshark displays for this frame, you
> will see much more info:
> (attached)
>
> What tshark is extracting is the scidx numbers but not the phi and psi
> values following it.
>
> Has anyone seen this issue before? I guess I will look into it soon
> but was interested to know if anyone has seen it.
I forgot to mention that this is the code that is inserting the phi
and psi values:
---
for (ci = 1; ci <= nc; ci++) {
for (ri = ci; ri < nr; ri++) {
int angle = he_get_bits(tvb, bit_offset, phi_bits);
proto_item_append_text(pi, ", phi%d%d:%d", ri, ci, angle);
bit_offset += phi_bits;
}
for (ri = ci + 1; ri <= nr; ri++) {
int angle = he_get_bits(tvb, bit_offset, psi_bits);
proto_item_append_text(pi, ", psi%d%d:%d", ri, ci, angle);
bit_offset += psi_bits;
}
}
--
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
[Wireshark-dev] proto_item_append_text info not being picked up when extracting fields via tshark
Hi folks, As a result of a recent issue and MR I suggested the use of tshark to extract some info but it does not work. I suggested this: -- ./run/tshark -r ~/SNR* -Y "frame.number == 1" -Tfields -e "wlan.he.action.he_mimo_control.scidx" -500,-496,-492,-488,-484,-480,-476,-472,-468,-464,-460,-456,-452,-448,-444,-440,-436,-432,-428,-424,-420,-416,-412,-408,-404,-400,-396,-392,-388,-384,-380,-376,-372,-368,-364,-360,-356,-352,-348,-344,-340,-336,-332,-328,-324,-320,-316,-312,-308,-304,-300,-296,-292,-288,-284,-280,-276,-272,-268,-264,-260,-256,-252,-248,-244,-240,-236,-232,-228,-224,-220,-216,-212,-208,-204,-200,-196,-192,-188,-184,-180,-176,-172,-168,-164,-160,-156,-152,-148,-144,-140,-136,-132,-128,-124,-120,-116,-112,-108,-104,-100,-96,-92,-88,-84,-80,-76,-72,-68,-64,-60,-56,-52,-48,-44,-40,-36,-32,-28,-24,-20,-16,-12,-8,-4,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,180,184,188,192,196,200,204,208,212,216,220,224,228,232,236,240,244,248,252,256,260,264,268,272,276,280,284,288,292,296,300,304,308,312,316,320,324,328,332,336,340,344,348,352,356,360,364,368,372,376,380,384,388,392,396,400,404,408,412,416,420,424,428,432,436,440,444,448,452,456,460,464,468,472,476,480,484,488,492,496,500 However, if you look at what Wireshark displays for this frame, you will see much more info: (attached) What tshark is extracting is the scidx numbers but not the phi and psi values following it. Has anyone seen this issue before? I guess I will look into it soon but was interested to know if anyone has seen it. -- 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] display filter scanner.l possible weirdness
On Tue, Aug 23, 2022 at 6:56 AM João Valverde wrote:
>
> On 8/23/22 14:29, Richard Sharpe wrote:
> > On Tue, Aug 23, 2022 at 2:30 AM João Valverde wrote:
> >> On 8/22/22 14:42, Richard Sharpe wrote:
> >>> Hi folks,
> >>>
> >>> In trying to introduce my contexts approach for display filters to
> >>> handle embedded/recursive structures in 802.11 Information Elements
> >>> (TLVs) I came across this in epan/dfilter/scanner.l:
> >>>
> >>> -
> >>> - ([.][-+[:alnum:]_:]+)+[.]{0,2} |
> >>> -[-+[:alnum:]_:]+([.][-+[:alnum:]_:]+)*[.]{0,2} {
> >>> + ([.][-+[:alnum:]_]+)+[.]{0,2} |
> >>> +[-+[:alnum:]_]+([.][-+[:alnum:]_]+)*[.]{0,2} {
> >>> --
> >>>
> >>> Basically, the original scanner allowed solons (:) in field names. I
> >>> had to change that since I needed to parse out colons separately in
> >>> the grammar. It almost looks like someone made a mistake and assumed
> >>> they needed ':]' in contexts where that was not necessary.
> >>>
> >>> I do not believe anyone uses colons in filter strings and did not
> >>> think it was possible.
> >>>
> >>> Does anyone think this will be a problem?
> >> It is a problem because that regex also has to match things other than
> >> fields. Bytes, MAC addresses, IPv6 addresses, those use colons.
> > Hmmm, I had not noticed that so I will have to find another way to do
> > what I want to do.
> >
> >> Is there a reason why you are not developing this on the master branch?
> >> That is odd.
> > I am doing it in a private branch but why does that matter?
>
> I know it is a private branch, but that branch is based on version 3.6.
> That matters if you plan to contribute your code to the project.
>
> >> And I urge you to come up with a design first that can garner some
> >> support. Maybe you could explain what "protocol contexts" are. I fail to
> >> see what makes contexts recursive.
> > In ieee802.11 now (or soon) there will be IEs that are contained in
> > other IEs. With IE defragmentation there can be quite a lot of them.
> >
> > Some people want to be able to say: Find me all the packets that have
> > IE xyz but only when it is within IE abc.
> >
> > Making that possible the simple way (by having different filter
> > strings for each possible context) is an enormous amount of work and
> > would bloat the code inordinately.
> >
> > An alternative is to have those small number of places where it is
> > possible to have IEs inside IEs (and it will only be newer IEs
> > introduced in 802.11be) to add a context string that can be used to do
> > that filtering.
> >
>
> I get that but you can't expect to add new syntax for display filters
> that only works with an 802.11 IE. A language extension needs to be more
> generic than that. It needs to solve recursion for all dissectors, or at
> least be widely useful.
Hmmm, this seems to be a different objection to your earlier
objection. In any event the same approach can be used for any
protocol. The dissector would add the context as needed.
I will write some more about this later.
--
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] display filter scanner.l possible weirdness
On Tue, Aug 23, 2022 at 2:30 AM João Valverde wrote:
>
> On 8/22/22 14:42, Richard Sharpe wrote:
> > Hi folks,
> >
> > In trying to introduce my contexts approach for display filters to
> > handle embedded/recursive structures in 802.11 Information Elements
> > (TLVs) I came across this in epan/dfilter/scanner.l:
> >
> > -
> > - ([.][-+[:alnum:]_:]+)+[.]{0,2} |
> > -[-+[:alnum:]_:]+([.][-+[:alnum:]_:]+)*[.]{0,2} {
> > + ([.][-+[:alnum:]_]+)+[.]{0,2} |
> > +[-+[:alnum:]_]+([.][-+[:alnum:]_]+)*[.]{0,2} {
> > --
> >
> > Basically, the original scanner allowed solons (:) in field names. I
> > had to change that since I needed to parse out colons separately in
> > the grammar. It almost looks like someone made a mistake and assumed
> > they needed ':]' in contexts where that was not necessary.
> >
> > I do not believe anyone uses colons in filter strings and did not
> > think it was possible.
> >
> > Does anyone think this will be a problem?
>
> It is a problem because that regex also has to match things other than
> fields. Bytes, MAC addresses, IPv6 addresses, those use colons.
Hmmm, I had not noticed that so I will have to find another way to do
what I want to do.
> Is there a reason why you are not developing this on the master branch?
> That is odd.
I am doing it in a private branch but why does that matter?
> And I urge you to come up with a design first that can garner some
> support. Maybe you could explain what "protocol contexts" are. I fail to
> see what makes contexts recursive.
In ieee802.11 now (or soon) there will be IEs that are contained in
other IEs. With IE defragmentation there can be quite a lot of them.
Some people want to be able to say: Find me all the packets that have
IE xyz but only when it is within IE abc.
Making that possible the simple way (by having different filter
strings for each possible context) is an enormous amount of work and
would bloat the code inordinately.
An alternative is to have those small number of places where it is
possible to have IEs inside IEs (and it will only be newer IEs
introduced in 802.11be) to add a context string that can be used to do
that filtering.
--
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
[Wireshark-dev] Is there some way in gitlab that I can be automatically informed when merge requests are created for ieee80211?
Hi folks, Is there some way that gitlab can inform me of merge requests for the 802.11 dissector? -- 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
[Wireshark-dev] display filter scanner.l possible weirdness
Hi folks,
In trying to introduce my contexts approach for display filters to
handle embedded/recursive structures in 802.11 Information Elements
(TLVs) I came across this in epan/dfilter/scanner.l:
-
- ([.][-+[:alnum:]_:]+)+[.]{0,2} |
-[-+[:alnum:]_:]+([.][-+[:alnum:]_:]+)*[.]{0,2} {
+ ([.][-+[:alnum:]_]+)+[.]{0,2} |
+[-+[:alnum:]_]+([.][-+[:alnum:]_]+)*[.]{0,2} {
--
Basically, the original scanner allowed solons (:) in field names. I
had to change that since I needed to parse out colons separately in
the grammar. It almost looks like someone made a mistake and assumed
they needed ':]' in contexts where that was not necessary.
I do not believe anyone uses colons in filter strings and did not
think it was possible.
Does anyone think this will be a problem?
Also, are there automated tests for the dfilter stuff? I have been
using dftest to test my changes but it would be good to see if I have
disturbed anything.
--
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] Filter expressions for recursive structures
On Wed, Aug 17, 2022 at 6:31 AM Richard Sharpe wrote: > > On Sun, Jul 31, 2022 at 3:36 AM João Valverde wrote: > > > > Maybe we could add wildcards? > > > > |diameter.*.Result-Code > > > > The star represents "any nesting level", not "any number of characters". > > I.e: it's not a text match, it matches levels on the protocol tree. > > > > It's not trivial at all to implement though. I think it would have to > > use a loop in DFVM code. > > It looks like I am going to have to revisit this. > > I did think of using wild cards, however, I now think it is going to > be easier to do something like: > > 1. In the code indicate that the filter expression supplied by the HF > should have a string prepended. In the use case I am thinking of it > would be something like "sta_profile_" without the angle brackets. > There will be well known points in the code where this should be done. > This makes it easy to understand how to derive the filter expressions. > 2. Carry around with the field in the tree the prefix that applies. > 3. Modify the DFVM code to use the prepended string. OK, it turns out this approach will not work either, or at least the simple version. I was thinking of setting up the names like "sta_profile_1.wlan.eht.multi_link..." but since sta_profile_1 would not be part of the filter expression for any header field and making it so would wildly increase the total number of header fields and require touching lots of code, I looked at an alternative. The alternative I am looking at ATM is: 'sta_profile_1:wlan.eht.multi_link...' and have made some progress on the dfilter grammar etc to support this. A problem is that if there is further recursion in these things I might have to add support for something like 'sta_profile_1::wlan.eht.multi_link...' The context info would be added by the appropriate dissector(s). -- 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] Filter expressions for recursive structures
On Sun, Jul 31, 2022 at 3:36 AM João Valverde wrote: > > Maybe we could add wildcards? > > |diameter.*.Result-Code > > The star represents "any nesting level", not "any number of characters". > I.e: it's not a text match, it matches levels on the protocol tree. > > It's not trivial at all to implement though. I think it would have to > use a loop in DFVM code. It looks like I am going to have to revisit this. I did think of using wild cards, however, I now think it is going to be easier to do something like: 1. In the code indicate that the filter expression supplied by the HF should have a string prepended. In the use case I am thinking of it would be something like "sta_profile_" without the angle brackets. There will be well known points in the code where this should be done. This makes it easy to understand how to derive the filter expressions. 2. Carry around with the field in the tree the prefix that applies. 3. Modify the DFVM code to use the prepended string. > On 30/07/22 13:28, John Thacker wrote: > > To pile on more, there's the same enhancement request for Diameter > > (also generated) that's ten years old: > > > > https://gitlab.com/wireshark/wireshark/-/issues/6816 > > > > On Sat, Jul 30, 2022, 3:12 AM Roland Knall wrote: > > > > Just to pile on, a very similar issue exists with OPC UA, more > > because the dissector is generated and the generator is not > > respecting naming schemes but they face the same issue. > > > > Kind regards > > Roland > > > > > Am 29.07.2022 um 18:28 schrieb Richard Sharpe > > : > > > > > > Hi folks, > > > > > > The wonderful people working on 802.11 have started using > > recursive structures. > > > > > > That is, they are embedding Info Elements (IEs) within Info Elements > > > and there can be multiple IEs of the same type within an IE within a > > > Beacon or Probe etc frame. > > > > > > Now some people are asking to be able to refer to a specific > > embedded > > > IE within an IE. > > > > > > That would seem to present problems because there is no way to > > > concatenate filter expressions. > > > > > > About the best I can think of is pass some context to IE dissectors > > > via the pinfo field and to insert that into field values via a > > > proto_item_append_text ... > > > > > > Are there any other thoughts about how to deal with this issue? > > > > > > -- > > > Regards, > > > Richard Sharpe > > > (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) > > > > > > > ___ > > > Sent via:Wireshark-dev mailing list > > > > > Archives: https://www.wireshark.org/lists/wireshark-dev > > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > > > > > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives: https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > > > > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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] Syncthing protocol dissector
On Mon, Feb 28, 2022 at 11:53 AM Tmore1 wrote: > > Hi, > > Thank you. I understand that only C dissectors are distributed with > Wireshark - in my message, I asked whether the project would be > interested in my reimplementing it in C. Yes. If needed I can help you shepherd the changes into the repository. > The Syncthing protocols are a mixture of protobufs and ordinary fields. > I assumed that the way to write such a dissector is by writing a > protocol specific dissector, and then calling the protobuf dissector > with a subset of the tvb. That's what I did in Lua, and that's what I > suppose I would do in C. Is this the right approach? That sounds correct to me. > On Mon, 28 Feb 2022 10:20:01 +0100 > Alexis La Goutte wrote: > > > Hi Thomas, > > > > We don't accept LUA dissector on source code > > > > But there is now a protobuff dissector on Wireshark and i think it will not > > be complicated to add this protocol. > > > > Cheers > > > > > > On Sun, Feb 27, 2022 at 5:39 AM Tmore1 wrote: > > > > > Hello, > > > > > > Several years ago, there was some discussion on this list about a > > > Syncthing protocol dissector: > > > > > > https://www.wireshark.org/lists/wireshark-dev/201811/msg00017.html > > > > > > AFAICT, there still doesn't seem to be one. I'm new to Wireshark > > > internals (and pretty new to Wireshark externals, as well ;)), but I > > > thought I'd try my hand at writing one. I starting by writing a Lua > > > dissector for one of the Syncthing protocols: > > > > > > https://github.com/tmo1/wireshark-syncthing-dissector > > > > > > and it seems to work. If I'm not too daunted by trying to reimplement > > > it in C, would this be something of interest to the project? > > > > > > Thomas > > > ___ > > > Sent via:Wireshark-dev mailing list > > > Archives:https://www.wireshark.org/lists/wireshark-dev > > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > > > mailto:wireshark-dev-requ...@wireshark.org > > > ?subject=unsubscribe > > > > > > -- > Tmore1 > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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] Passing information to a sub dissector
On Thu, Feb 17, 2022 at 8:54 AM Jérôme HAMM wrote: > > Hi > > What is the return value of the main dissector function (the one that gets > registered with register_dissector) supposed to be? I don't know :-) > What is supposed to be in its void* data parameter? (I checked the doc but > didn't find an answer) I believe that this is supposed to be an agreement between the caller and the dissectors behind the dissector table, if that is what you are referring to. Have a look at the IEEE802.11 dissector for some example. Hmmm, on second thoughts, it is so damn large that you might struggle to find any useful info. Have a look at add_tag_relay_capabilities in that dissector. The caller sets up the data structure how it wants to and the called function has to know that. > Is there a standard way to pass data to a sub-dissector (for example, two > sftp streams could be opened in the same ssh session, how do I tell the > subdissector with which "conversation" it should work)? Conversation info should probably be in the pinfo, but if not, pass in enough info to find the conversation. -- 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
[Wireshark-dev] How do I figure out why the test failed?
Hi folks, On my latest MR, I got this during the Windows build: --- 31/38 Test #32: suite_nameres .. Passed 5.46 sec 3380 Start 34: suite_release 338132/38 Test #34: suite_release ..***Failed 0.65 sec --- How do I figure out where it failed? -- 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
[Wireshark-dev] How do I create a merge request for changes to get into the next 3.6.x release
Hi folks, I have submitted merge requests to fix some problems with the S1G radiotap changes and would like to ensure they get into the next 3.6.x release because there are now chipsets and adapters shipping with S1G (Halow) support. So, what sort of merge requests do I need to create? -- 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
[Wireshark-dev] My latest Merge Request pipeline failed in a weird way in the Windows build
Hi folks, This pipeline failed: https://gitlab.com/wireshark/wireshark/-/pipelines/429686197 The failure is: $ cmake -G "Visual Studio 16 2019" -A x64 -DENABLE_LTO=off .. 57-- Selecting Windows SDK version to target Windows 10.0.17763. 58-- The C compiler identification is unknown 59-- The CXX compiler identification is unknown 60CMake Error at CMakeLists.txt:43 (project): 61 No CMAKE_C_COMPILER could be found. 62CMake Error at CMakeLists.txt:43 (project): 63 No CMAKE_CXX_COMPILER could be found. 64-- Configuring incomplete, errors occurred! What is going on? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Exporting FTP objects
On Tue, Dec 14, 2021 at 10:18 AM Moshe Kaplan wrote: > > I considered using such a data structure, but the challenge there is that > there's no guarantee of a 'file transfer complete' that could be used to > trigger reassembly and adding to the export objects list. AFAIK, it's also > not possible to have a function to run after all packets were dissected to > generate the export object list entries then. I am very unfamiliar with the tap infrastructure but perhaps you could introduce an EOM event through the tap so you could detect the data connection going down and do reassembly there. -- 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] Exporting FTP objects
On Tue, Dec 14, 2021 at 9:34 AM Moshe Kaplan wrote: > > Good afternoon, > > I've been working on MR 1611 for exporting FTP objects. One of the > complexities is that because the transmitted FTP files are spread across > multiple "packets", they need to be reassembled by the export objects 'tap' > into a single block of contiguous memory, so they can be exported. In the > MR's current implementation, this is done by appending the data from each > ftp-data packet as it is received. > > Martin Mathieson commented here: > "I would still like to hear more opinions on whether we should export data > that isn't re-ordered/reassembled. I've unfortunately missed the past couple > of developer dens. Maybe ask on the dev list about whether it would be > confuse people, and if it would, whether there are ideas on how to do it?" > > Does anyone have any suggestions as to how to best deal with the problem of > reordered packets? I suspect you are going to have to maintain a data structure that allows you to reassemble them, but you probably knew that. How about a data structure (perhaps a hash indexed by starting sequence number) with the ending seq number or length and pointer to the data and a more-data flag or something. Then, when you have all the data you can index into the hash table by starting sequence number starting at 1. -- 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] Is there some reasonable way to split up epan/dissectors/packet-ieee80211.c into smaller files?
On Thu, Dec 2, 2021 at 11:12 PM Alexis La Goutte wrote: > > Hi Richard, > > yes, ieee802.11 dissector is big... > do you have some idea how to split ? Here is a thought, but it does not handle everything. Each new version of the Wi-Fi spec (which is now around 4000+ pages in size) introduces new IEs and new this and new that. Currently, IEs are handled via a dissector table but extended IEs are not handled via a dissector table and Categories are not handled via a dissector table. If more of these sort of things were handled via dissector tables, then we could separate the Wi-Fi 6 and Wi-Fi 7 and Wi-Fi 99 additions into separate files, for the most part. Perhaps we would need a mechanism for Wi-Fi X+1 to override some parts of Wi-Fi X as well, but I have no idea how to handle that for the moment. -- 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
[Wireshark-dev] Is there some reasonable way to split up epan/dissectors/packet-ieee80211.c into smaller files?
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] make rpm-package does not build custom dissectors ...
On Fri, Oct 29, 2021 at 7:56 AM Richard Sharpe wrote: > > Hi folks, > > In one project I have a bunch of custom dissectors in a 3.5.0 build. > > They are all defined in epan/dissectors/CMakeListsCustom.txt. > > When I run cmake it tells me it found the custom stuff. > > Then when I run make it builds them (it logs each custom dissector being > build.) > > However, when I run make rpm-package the custom dissectors are not > built and there are not .o files in the build directory for the custom > dissectors. > > Where should I look to figure out what is going wrong? OK, a moment's peripatetic thought informed me of the problem. Since I am not adding the files I generated to git and the packaging process is using git to extract the files for building, they didn't make it into the build. -- 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
[Wireshark-dev] make rpm-package does not build custom dissectors ...
Hi folks, In one project I have a bunch of custom dissectors in a 3.5.0 build. They are all defined in epan/dissectors/CMakeListsCustom.txt. When I run cmake it tells me it found the custom stuff. Then when I run make it builds them (it logs each custom dissector being build.) However, when I run make rpm-package the custom dissectors are not built and there are not .o files in the build directory for the custom dissectors. Where should I look to figure out what is going wrong? -- 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] I have added another file to wireshark but keep getting unresolved references
On Sun, Oct 24, 2021 at 7:07 AM Anders Broman via Wireshark-dev wrote: > > Hi, > Did you try to delete the build dir and re-run CMake? I did, but it turned out to be a stupid mistake. The function in question had a forward declaration earlier on in the code that declared it static :-( > Regards > Anders > > -Original Message- > From: Wireshark-dev On Behalf Of > Richard Sharpe > Sent: den 24 oktober 2021 15:17 > To: Developer support list for Wireshark > Subject: [Wireshark-dev] I have added another file to wireshark but keep > getting unresolved references > > Hi folks, > > I have added another file to Wireshark but when I build I keep getting this: > > -- > [ 79%] Linking C executable run/sharkd > /usr/bin/ld: run/libwireshark.so.14.0.8: undefined reference to > `dissect_neighbor_report' > collect2: error: ld returned 1 exit status > make[2]: *** [CMakeFiles/sharkd.dir/build.make:160: run/sharkd] Error 1 > make[1]: *** [CMakeFiles/Makefile2:3630: CMakeFiles/sharkd.dir/all] Error 2 > make: *** [Makefile:160: all] Error 2 > > > The function is not static and the file has a handoff section and I have > added the file to the files list in epan/dissectors/CMakeLists.txt. > > What else should I do? > > -- > Regards, > Richard Sharpe > (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) > ___ > Sent via:Wireshark-dev mailing list > Archives: > https://protect2.fireeye.com/v1/url?k=7fa4649d-203f5d98-7fa42406-86959e472243-36d92ad18a6c6eb6=1=2ced34b0-e6b9-4385-b2f5-2a58860d3081=https%3A%2F%2Fwww.wireshark.org%2Flists%2Fwireshark-dev > Unsubscribe: > https://protect2.fireeye.com/v1/url?k=fa656564-a5fe5c61-fa6525ff-86959e472243-00731add9e780d9f=1=2ced34b0-e6b9-4385-b2f5-2a58860d3081=https%3A%2F%2Fwww.wireshark.org%2Fmailman%2Foptions%2Fwireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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
[Wireshark-dev] I have added another file to wireshark but keep getting unresolved references
Hi folks, I have added another file to Wireshark but when I build I keep getting this: -- [ 79%] Linking C executable run/sharkd /usr/bin/ld: run/libwireshark.so.14.0.8: undefined reference to `dissect_neighbor_report' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/sharkd.dir/build.make:160: run/sharkd] Error 1 make[1]: *** [CMakeFiles/Makefile2:3630: CMakeFiles/sharkd.dir/all] Error 2 make: *** [Makefile:160: all] Error 2 The function is not static and the file has a handoff section and I have added the file to the files list in epan/dissectors/CMakeLists.txt. What else should I do? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Can an 'Apply as Column' column contain multiple columns?
On Tue, Aug 31, 2021 at 7:52 AM chuck c wrote: > > http://www.packettrain.net/2017/07/05/wireshark-hints-multi-column/ Well, sh*t, seems there is nothing new under the sun. > On Tue, Aug 31, 2021 at 9:49 AM Richard Sharpe > wrote: >> >> Hi folks, >> >> Often times I am analyzing captures that contain multiple protocols of >> interest and I want to see the response times of several protocols, eg >> SMB2, NFS and CTDB. >> >> Currently, I have to Apply as Column the time field in responses for >> each such protocol, which takes up a lot of screen real estate. >> >> It would be better (IMO) if I could say: >> >> Add a column that contains smb2.time or rpc.time or ctdb.time >> >> Or maybe even Add a column that contains '*.time'. >> >> That would mean one column contains the info I want for many protocols. >> >> Is that possible? How much work would it be. >> >> -- >> Regards, >> Richard Sharpe >> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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
[Wireshark-dev] Can an 'Apply as Column' column contain multiple columns?
Hi folks, Often times I am analyzing captures that contain multiple protocols of interest and I want to see the response times of several protocols, eg SMB2, NFS and CTDB. Currently, I have to Apply as Column the time field in responses for each such protocol, which takes up a lot of screen real estate. It would be better (IMO) if I could say: Add a column that contains smb2.time or rpc.time or ctdb.time Or maybe even Add a column that contains '*.time'. That would mean one column contains the info I want for many protocols. Is that possible? How much work would it be. -- 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] Getting captured interface name inside plugin
On Sun, Jun 6, 2021 at 5:42 PM Jan Mall wrote: > > The ultimate goal is an automotive dissector, which takes abstract > network descriptions for automotive buses and dissects the messages on > the bus accordingly. But as every bus has a different set of message > definitions, I somehow need to find out on which bus (physical > interface) I receive the traffic in order to perform dissection > according to the message definitions for this bus. Of course the user > could just change the network description in the plugins preferences > every time he switches the interfaces, but I thought maybe there's a > smoother solution. Are the messages partitioned such that they are different on each interface, or is it the case that Message 1 can appear on interface types A and B but with different formats? > On 07.06.21 02:24, Guy Harris wrote: > > On Jun 6, 2021, at 5:13 PM, Jan Mall wrote: > > > >> I'm currently developing a plugin/dissector (C API), which should have a > >> different dissection behavior depending on the interface Wireshark is > >> currently listening on. > > Why? > > > > What is the *ultimate* goal of this? > > ___ > > Sent via:Wireshark-dev mailing list > > Archives: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 -- 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] Can the OSS-FUZZ tool be modified to generate a pcap test file?
On Thu, May 27, 2021 at 10:16 AM Moshe Kaplan wrote: > > I believe Peter Wu created a script a while back to do that and published it > here: https://github.com/Lekensteyn/wireshark-fuzztools Thanks for that. -- 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
[Wireshark-dev] Can the OSS-FUZZ tool be modified to generate a pcap test file?
Hi folks, It seems like the OSS-FUZZ tool is very useful in finding certain types of problems, but it would be even more useful if it could generate a pcap file of the packets it used to find a problem. Does anyone know how hard it would be to modify to do that? -- 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] Ethernet dissector
On Sun, May 23, 2021 at 5:06 AM Antonello Tartamo
wrote:
>
> Hello everyone,
> I'm trying to create an ethernet dissector for a custom protocol working on
> L2.
>
> In proto_reg_handoff_myproto() function I've called:
> heur_dissector_add("eth", dissect_myproto, "MyProtocol", "mp", proto_mp,
> HEURISTIC_ENABLE);
> eth_handle = find_dissector("eth_withoutfcs");
>
> then in the dissect_myproto function when I call:
> tvbuff_t* next_tvb = tvb_new_subset_remaining(tvb, 0);
> int new_off = call_dissector(eth_handle, tvb, pinfo, tree);
> return new_off;
>
> I get the following two errors on the terminal:
> ** (wireshark:11483): WARNING **: 07:31:59.826: Dissector bug, protocol
> Ethernet, in packet 12: /home/osboxes/Devel/wireshark/epan/packet.c:2794:
> failed assertion "saved_layers_len < 500"
>
> ** (wireshark:11483): WARNING **: 07:31:59.826: Dissector bug, protocol
> Ethernet, in packet 12: /home/osboxes/Devel/wireshark/epan/packet.c:775:
> failed assertion "saved_layers_len < 500"
>
> I'm running the development wireshark with ./run/wireshark.
>
> I think the error is due to the fact the both the heuristic dissector and the
> "find_dissector" are ethernet based.
> Is there another way to reuse the ethernet dissector and avoid manually
> adding to the tree the src/dst mac addresses and the ethertype ?
If you are using a fixed ethertype, then the ieee1905 dissector
(packet-ieee1905.c) does this:
void
proto_reg_handoff_ieee1905(void)
{
static dissector_handle_t ieee1905_handle;
ieee1905_handle = create_dissector_handle(dissect_ieee1905,
proto_ieee1905);
dissector_add_uint("ethertype", ETHERTYPE_IEEE_1905, ieee1905_handle);
eapol_handle = find_dissector("eapol");
}
You can ignore the eapol_handle stuff unless you also plan to use
EAPOL (ieee801.X) in your protocol.
--
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
[Wireshark-dev] Should we be dynamically allocating the hash buf below?
Hi folks,
I notice that in the ieee1905 dissector there is now the following
code for calculating fragment hashes.
static guint
ieee1905_fragment_hash(gconstpointer k)
{
guint hash_val;
const ieee1905_fragment_key *key = (const ieee1905_fragment_key *)k;
if (!key || !key->src.data || !key->dst.data) {
return 0;
}
const guint8 src_len = key->src.len;
const guint8 dst_len = key->dst.len;
const guint8 hash_buf_len = src_len + dst_len + sizeof(guint8) +
sizeof(guint32);
guint8* hash_buf = (guint8*)wmem_alloc(wmem_packet_scope(), hash_buf_len);
memcpy(hash_buf, key->src.data, src_len);
memcpy(_buf[src_len], key->dst.data, dst_len);
hash_buf[src_len + dst_len] = key->frag_id;
memcpy(_buf[src_len + dst_len + sizeof(guint8)], >vlan_id,
sizeof(guint32));
hash_val = wmem_strong_hash((const guint8 *)hash_buf, hash_buf_len);
return hash_val;
}
My question is: Should we be using wmem_alloc for the hash_buf because
it seems like we never use it after the hash is calculated so why
leave it around and why allocate it instead of using a buffer on the
stack.
We also never free it, although it will be freed when the packet goes
away, I guess.
--
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
[Wireshark-dev] packet-rpc.c failing find rpc_call info when the capture file is large enough
Hi folks, I have run across an interesting issue. I took a capture using -C and -W to get some 30 or more capture files with 30M each. I then merged several of them towords the end to give me a 95MB capture file. When I look at it I can see each response found and matched to the previous request. However, when I merged more of them to give me an approximately 700MB capture file, the responses to quote a few are not dissected and show up RPC continuations. Using some debugging I have tracked it down to the following statement not finding the correct conversation, it seems: conversation = find_conversation_for_reply(pinfo); Here is the logging I have added in the case that it works: xid = 0xd4e94d56 frame=146941 # This is for the request Checking if we have a conv=0x7fbf96ae60c0 for XID=0xd4e94d56 frame=146941 Did we have an rpc_conv_info 0x7fbf96ae8750 for 0xd4e94d56 frame 146941 Did we find the call (nil) for 0xd4e94d56 for frame 146941 Storing 0x7fbf92184470 for 0xd4e94d56 for frame 146941 The XID=0xd4e94d56 for frame=146951 # This is for the reply Found a conversation=0x7fbf96ae60c0 for XID=d4e94d56 frame=146951 Found rpc_conv_info=0x7fbf96ae8750 for XID=d4e94d56 frame=146951 Found rpc_call=0x7fbf92184470 for XID=d4e94d56 frame=146951 xid = 0xd4e94d56 frame=146951 - Notice that we found the same conversation in the case of both the request and the response. (I am logging when I see a specific XID.) Here is what I see in the case of the larger merged capture file: -- xid = 0xd4e94d56 frame=524451 # This is for the request Checking if we have a conv=0x7f20b1022ce0 for XID=0xd4e94d56 frame=524451 Did we have an rpc_conv_info 0x7f20b1025500 for 0xd4e94d56 frame 524451 Did we find the call (nil) for 0xd4e94d56 for frame 524451 Storing 0x7f20ac71a4a0 for 0xd4e94d56 for frame 524451 The XID=0xd4e94d56 for frame=524461 # This is for the reply Found a conversation=0x7f20bf051460 for XID=d4e94d56 frame=524461 Found rpc_conv_info=0x7f20bf052ce0 for XID=d4e94d56 frame=524461 Notice there that in the second case it seems we found a different conversation for the reply ... I am trying to figure out why we did not find the correct conversation with the large capture file. If anyone has ideas I would be interested in hearing from you. -- 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] Who introduced these failures?
On Wed, Apr 21, 2021 at 10:47 AM Pascal Quantin wrote: > > Hi Richard, > > Le mer. 21 avr. 2021 à 19:43, Richard Sharpe a > écrit : >> >> My latest MR failed with these errors: >> >> - >> C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): >> error C2220: workload = 100.0 * >> CSR_GET_WORKLOAD(tvb_get_ntohs(message_tvb, 284)); >> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] >> 857C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): >> error C2220: ^ >> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] >> 858 packet-cp2179.c >> 859C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): >> warning C4244: '=': conversion from 'double' to 'float', possible loss >> of data >> [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] >> --- >> >> They are not in packet-ieee80211.c where my changes were. > > > This seems related to > https://gitlab.com/wireshark/wireshark/-/merge_requests/2178 where no Windows > build was run by the CI, and thus the error was left unnoticed prior to the > merge. See the thread initiated by Anders earlier today. Ahhh, thanks. -- 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
[Wireshark-dev] Who introduced these failures?
My latest MR failed with these errors: - C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): error C2220: workload = 100.0 * CSR_GET_WORKLOAD(tvb_get_ntohs(message_tvb, 284)); [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] 857C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): error C2220: ^ [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] 858 packet-cp2179.c 859C:\builds\wireshark\wireshark\epan\dissectors\packet-componentstatus.c(172,71): warning C4244: '=': conversion from 'double' to 'float', possible loss of data [C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj] --- They are not in packet-ieee80211.c where my changes were. -- 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] Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files
On Sun, Apr 18, 2021 at 9:30 PM Guy Harris wrote: > > On Apr 18, 2021, at 2:33 PM, Richard Sharpe > wrote: > > > I am thinking of writing a wtap module to read ComView WLAN Analyzer > > and Decoder NCFS format files. > > > > They are a little like PCAP files with a radiotap header, > > ...and a bit more like CommView NCF files, which we already support. > > > One way to handle it would be to convert their info to a standard > > radiotap header but it looks kind of complicated to handle that. > > > > Another approach might be to use a new or different WTAP type and > > write a separate dissector for those headers. > > The way to do it, currently, is the same way it's done for NCF - fill in the > pseudo-header in the wiretap module, and use > WTAP_ENCAP_IEEE_802_11_WITH_RADIO for Wi-Fi packets. (There's no per-file > encapsulation type for NCF or NCFX, so we use WTAP_ENCAP_PER_PACKET.) > > > Any thoughts? > > Somebody from Tamosoft mentioned NCFX files to me a while ago, suggesting > adding Wireshark support, and I worked on it; I've done a merge request for > what I have now: > > https://gitlab.com/wireshark/wireshark/-/merge_requests/2762 > > Currently, there may be some bits of information that the pseudo-header can't > handle; if so, it should be extended to handle them. > > The "number of streams" is NSS (N sub SS) minus 1 for HT, VHT, and HE PHYs - > 0 means 1 stream. > > We may want to change the 802.11 pseudo-header to have data rates in units of > 100 Kb/s rather than 500 Kb/s, to handle NCFX and possibly other files. (We > might also want to add support for "scaled integer" fields, which display not > as the raw value but as the value multiplied by/divided by a scaling factor, > if avoiding inaccuracies due to scaling values not being representable > exactly as floating-point binary numbers (.5 can, .1 can't). I think the problem will be that the radiotap HE and other headers support much more info than what you have suggested. Will we also add things like GI, LFT symbol size, # LTF symbols, Pre FEC padding, etc, to the pseudo-header? In addition, radiotap now supports TLVs (since they ran out of bits in the features word). However, that is possibly easier to handle, since an unknown TLV can simply be displayed as raw bytes. -- 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
[Wireshark-dev] Clearly, someone thought no one should be using CommView after 2038
Hi folks, I just came across this validation check in the commview wiretap code: if (... cv_hdr.year < 1970 || cv_hdr.year >= 2038 || ...) -- 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
[Wireshark-dev] Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files
Hi folks, I am thinking of writing a wtap module to read ComView WLAN Analyzer and Decoder NCFS format files. They are a little like PCAP files with a radiotap header, but their format is quite different from the radiotap format. It contains much of the same info but it is in a different format. The spec is here: https://www.tamos.com/htmlhelp/commwifi/logformat.htm The main things of interest are the 802.11ax info. One way to handle it would be to convert their info to a standard radiotap header but it looks kind of complicated to handle that. Another approach might be to use a new or different WTAP type and write a separate dissector for those headers. Any thoughts? -- 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] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet
On Thu, Apr 15, 2021 at 1:23 PM Guy Harris wrote: > > On Apr 15, 2021, at 2:03 AM, Graham Bloice > wrote: > > > Wireshark is a complicated project to build. You can follow the tested > > way, as shown in the Developers Guide, which is essentially what our > > Continuous Integration (CI) systems use and most other developers, or you > > can forge your own path on less travelled routes strewn with rocks, rusty > > nails and broken glass that you mostly have to deal with on your own. > > > > Unless you have some inescapable need to do things in a different way, it's > > easier and more productive to follow the herd. > > Building in a subdirectory with a name other than "build" isn't exactly a > "[route] strewn with rocks, rusty nails and broken glass". *That* should > Just Work (at least if the name is all ASCII printable characters and > contains no spaces); if it doesn't, that's a sign that the build process > isn't robust enough. Indeed, I routinely build in directories like wireshark-build or wireshark--build and I have never seen a problem. cmake is not that silly. -- 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
[Wireshark-dev] Wireshark not dissecting ONC RPC on a different port in build 3.4.4 and an older build but OK on Master?
Hi folks, I am seeing a weird problem. I grabbed a capture today from a CentOS 7.6-based system that contains some SMB2 traffic and some NFS traffic (on a non-standard port). Wireshark 3.4.4 on Windows will not dissect the RPC packets and thus the NFS packets. However, it will dissect a similar capture I took on a different build of the CentOS 7.6-based system. Our internal build of Wireshark also seems to have problems with that capture, but it is based on 2.6 or so. However, the latest master build has no problems with the capture and dissects the RPC and thus the NFS fine, at least on a Fedora 31 system. Has anyone seen this before? I am currently building 3.4.4 on Fedora to see if the problem is across more than one build of 3.4.4, -- 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
[Wireshark-dev] Hitting a weird error in a MR pipeline
Hi folks, In my latest MR pipeline: https://gitlab.com/wireshark/wireshark/-/pipelines/285790755 I see these errors in the Windows build portion: --- C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22): error C2220: the following warning is treated as an error [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj] 2718 packet-rtse.c 2719C:\builds\wireshark\wireshark\ui\qt\rtp_player_dialog.cpp(671,22): warning C4101: 'error': unreferenced local variable [C:\builds\wireshark\wireshark\build\ui\qt\qtui.vcxproj] --- However, my change did not touch those files ... what is going on? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Support for searching in FT_BYTES or longer bit fields
Hi folks, In one of the fields in 802.11az D3.0 there is a bit field that can be up to 512 bits long, and has padding defined to round it out to the nearest byte. This creates some problems with respect to how to insert it so that users can search on the field. No one wants to have to enter all 512 bits in order to search. I can think of several ways to handle this field: 1. Insert each block of 64 bits or less as a bit field. The last block might be less than 64 bits. Each block might be called availability_block_n and users would search within each block with something like wlan.ftm.ista.availability_block_2 == 0x1ff37 or whatever. 2. Insert the whole lot as an FT_BYTES field but then it seems like the user will have to enter the whole value, up to 32 bytes if it is that long. 3. ??? Is there a better way? -- 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
[Wireshark-dev] Is there a way to easily go to the next packet that satisfies a filter string without filtering the packets
Hi folks, I use Wireshark a great deal in my job because I am always looking at captures when trying to figure out bugs in our code. I often have captures with a lot of different types of packets and need to find a particular set of packets of mixed type, eg SMB2 followed by the NFS packets caused by the SMB2 request or SMB2 followed by the Kerberos packets caused etc. What I would like to be abe to do is to set up a filter string for a specific type of SMB2 request, say, based on source and dest IP and maybe type (ie, a CREATE, or whatever) and then go to the first such packet in the capture and then examine the subsequent packets to see if they satisfy my criteria. If they don't then I would like to go the next packet that satisfies my filter string and examine them, and so on until I find what I am looking for. I will usually also have filtered already on two types of frames (or a few types) like SMB2 || NFS. Currently, the only way I can think to do this is to filter on SMB2, select the first one I am interested in, unfilter (or refilter), examine the packets, and if they are not what I am interested in, refilter on SMB2 and select the next packet, and so on. The workflow is quite painful. Is there a simpler way to do this? If not, could we add a button for Next packet satisfying filter? -- 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] Problems with passing g_free to g_slist_foreach?
On Tue, Mar 16, 2021 at 9:23 PM Richard Sharpe wrote: > > Hi folks, > > I have been seeing some compiler errors on CentOS 8 like the following: > > --- > /home/rsharpe/src/wireshark/epan/packet.c:142:25: error: > cast between incompatible function types from ‘void (*)(void *)’ to > ‘void (*)(void *, void *)’ [-Werror=cast-function-type] > g_slist_foreach(*list, (GFunc)g_free, NULL); > ^ > cc1: all warnings being treated as errors > make[2]: *** [epan/CMakeFiles/epan.dir/build.make:687: > epan/CMakeFiles/epan.dir/packet.c.o] Error 1 > -- > > The warning is correct because a GFunc takes two arguments, while > g_free takes only one argument. > > How do I avoid the warning/error? > > Also, should we fix these things up? OK, I see that in the latest sources all these seem to have been fixed up using the same techniques I used on the 2.6.2-based source I was working with :-) -- 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
[Wireshark-dev] Problems with passing g_free to g_slist_foreach?
Hi folks, I have been seeing some compiler errors on CentOS 8 like the following: --- /home/rsharpe/src/wireshark/epan/packet.c:142:25: error: cast between incompatible function types from ‘void (*)(void *)’ to ‘void (*)(void *, void *)’ [-Werror=cast-function-type] g_slist_foreach(*list, (GFunc)g_free, NULL); ^ cc1: all warnings being treated as errors make[2]: *** [epan/CMakeFiles/epan.dir/build.make:687: epan/CMakeFiles/epan.dir/packet.c.o] Error 1 -- The warning is correct because a GFunc takes two arguments, while g_free takes only one argument. How do I avoid the warning/error? Also, should we fix these things up? -- 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] Is gitlab having problems?
On Sun, Mar 14, 2021 at 4:43 PM Richard Sharpe wrote: > > Hi folks, > > I am trying to sign into the gitlab UI and it just sits there saying > it is checking my browser and telling me it may take up to 5 seconds > but never gets there. Seems to be a browser issue. I tried a different browser and it worked but the original browser refused to work. -- 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
[Wireshark-dev] Is gitlab having problems?
Hi folks, I am trying to sign into the gitlab UI and it just sits there saying it is checking my browser and telling me it may take up to 5 seconds but never gets there. -- 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] 90GB pcap file get last frame time stamp
On Fri, Feb 26, 2021 at 9:10 AM Raj sekar wrote: > > Hi Everyone! > > Need a help. Is there any library or method to get large pcap file's( offline > ) last timestamp. > > I know capinfos can get this. But i want faster than capinfos. > > Any suggestion? Because each captured frame can be a different length, normally you would have to skip all the preceding frames to get the timestamp of the last record. However, a heuristic approach might be to read the header to get the capture-length, and then read that much from the end of the file and look for an appropriate record header ... On the other hand, I am unaware of any code that does that. -- 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] warning: unused parameter
On Sun, Feb 7, 2021 at 10:59 AM Paul Offord wrote: > > I submitted some code to GitLab for merging and I got a couple of warnings > from the pipeline that builds in the Ubuntu environment: > > ../sharkd_daemon.c:361:17: warning: unused parameter 'argc' > [-Wunused-parameter] > sharkd_loop(int argc, char* argv[]) > ^ > ../sharkd_daemon.c:361:29: warning: unused parameter 'argv' > [-Wunused-parameter] > sharkd_loop(int argc, char* argv[]) > ^ > It's true that argc and argv are not used in a *NIX build but are used in a > Windows build. > > What's the correct way to handle this? Should I: > > Ignore the warnings? > Add conditional compile statements for the sharkd_loop function declaration > and all calls to it? > Add something to the *NIX version of the code to use the parameters? Do you really need the parameter? If so, does adding _U_ after it not fix the problem? -- 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] Do we see false positives on the prechecks in merge-request runners
On Mon, Feb 1, 2021 at 7:22 AM Pascal Quantin wrote: > > Hi Richard, > > Le lun. 1 févr. 2021 à 16:09, Richard Sharpe a > écrit : >> >> Hi folks, >> >> In one of the builds for my merge request around Robust AV Streaming, >> I got this: >> >> https://gitlab.com/wireshark/wireshark/-/jobs/998246552 >> >> It is complaining that an ENC_BIG_ENDIAN should be ENC_NA, but in >> looking at the code, it already is ENC_NA and I have not changed that >> for a while (but perhaps the original code was wrong.) > > > This is not a false positive: your MR > https://gitlab.com/wireshark/wireshark/-/merge_requests/1885 is adding those > two new fields hf_ieee80211_tclas4_ipv6_src and hf_ieee80211_tclas4_ipv6_dst > and they use ENC_BIG_ENDIAN instead of ENC_NA. Whoa. When I do a git show I see that the patch shows ENC_BIG_ENDIAN. However, when I look at the code, even after I have added and done a git commit --amend, it shows ENC_NA. -- 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
[Wireshark-dev] Do we see false positives on the prechecks in merge-request runners
Hi folks, In one of the builds for my merge request around Robust AV Streaming, I got this: https://gitlab.com/wireshark/wireshark/-/jobs/998246552 It is complaining that an ENC_BIG_ENDIAN should be ENC_NA, but in looking at the code, it already is ENC_NA and I have not changed that for a while (but perhaps the original code was wrong.) -- 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] [Outreachy] Internship blog 2020 post #3
On Thu, Jan 7, 2021 at 8:13 AM Joey Salazar via Wireshark-dev wrote: > > Hi all, > > A new blog entry talking a bit about both Git and Wireshark here [1]. > > Check it out! Due to Xmas holidays last week, the next post will be there > next week (as opposed to the 2-week break in between posts as usual). Hi Joey, Is there any code we can look at? -- 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] Branch name issues ...
On Sat, Jan 2, 2021 at 11:07 PM Pascal Quantin wrote: > > Hi Richard, > > Le dim. 3 janv. 2021 à 01:01, Richard Sharpe a > écrit : >> >> Hi folks, >> >> I just tried to push some changes to my upstream repo prior to >> creating a merge request for the PV1/S1G changes I have accumulated. >> >> However, I hit this problem: >> >> remote: GitLab: Branch name does not follow the pattern >> '^(master|release-3.4|master-3.2|master-3.0|cherry-pick-.*)$' >> >> My branch is called ieee80211-PV1 ... >> >> Is this something I can change in my fork or do I have to use >> something like cherry-pick-.xxx? > > > Are you sure you are not trying to push to the gitlab.com/wireshark/wireshark > (upstream) repository and not to your fork (downstream)? D'oh. Must have been confused by all the fixing I did to get it to build. That was the problem. -- 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
[Wireshark-dev] Branch name issues ...
Hi folks, I just tried to push some changes to my upstream repo prior to creating a merge request for the PV1/S1G changes I have accumulated. However, I hit this problem: remote: GitLab: Branch name does not follow the pattern '^(master|release-3.4|master-3.2|master-3.0|cherry-pick-.*)$' My branch is called ieee80211-PV1 ... Is this something I can change in my fork or do I have to use something like cherry-pick-.xxx? -- 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
[Wireshark-dev] The ultimate networking hacker's device!
Hi folks, I came across this: https://www.crowdsupply.com/traverse-technologies/ten64/updates/10g-options-and-performance -- 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] Handling malformed packet exceptions from within ASN.1 dissectors
On Mon, Nov 2, 2020 at 11:57 PM Anders Broman via Wireshark-dev wrote: > > Hi, > I think a TRY CATCH block is the thing to use. Grep for CTACH and I think you > will find a bunch of examples. Yeah, I found them. But then I found that the ASN.1 dissectors already handle the situation and my problem was elsewhere :-) -- 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
[Wireshark-dev] Handling malformed packet exceptions from within ASN.1 dissectors
Hi folks, I am using some of the existing ASN.1 dissectors from within the ieee802.11 dissector, and in some cases the frame is malformed in the ASN.1 portion. However, since it is within an IE where I know the length of the element, I would like to regain control and add an Expert Info and then keep dissecting. How can I handle this? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Possible regression in Version 3.3.1 (v3.3.1-0-gd64aca7966e2)
On Sun, Oct 18, 2020 at 6:32 PM chuck c wrote:
>
> { _smb2_time,
> { "Time from request", "smb2.time", FT_RELATIVE_TIME, BASE_NONE,
> NULL, 0, "Time between Request and Response for SMB2 cmds", HFILL }
> },
>
> [Time from request: 0.008027000 seconds]
>
> Works for me on Windows 10.
> Maybe it's capture specific. Can you recreate with one of the sample captures
> from the wiki?
> https://gitlab.com/wireshark/wireshark/-/wikis/SMB2
Yeah, it worked for me as well on Windows 10 and 3.2.1. The funny
thing is that we were both looking at the same capture, I think, when
he hit the problem.
--
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] Possible regression in Version 3.3.1 (v3.3.1-0-gd64aca7966e2)
On Sun, Oct 18, 2020 at 1:33 PM Sake Blok | SYN-bit wrote: > > RIchard, > > I just tried “Applying as column” in Wireshark 3.3.1 on my Mac and it works > as expected. May the problem is only exposed with certain fields? What was > the field your co-working was trying to apply as a column? It was the SMB2 Time from request field in responses. -- 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] Do Lua Postdissectors still work with the most recent versions of Wireshark
On Fri, Oct 16, 2020 at 5:08 PM chuck c wrote: > > This was a Friday project a couple weeks ago: > https://gitlab.com/wireshark/wireshark/-/wikis/Lua/Examples/filtcols Great. Thanks. Maybe I can use this approach to do what I want. Are there any problems with Lua and Wireshark on Mac OS X? -- 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
[Wireshark-dev] Possible regression in Version 3.3.1 (v3.3.1-0-gd64aca7966e2)
Hi folks, I got a report from a coworker that 'Apply as column' was not working correctly. I showed the person how to right-click on a field in the details pane and then select Apply as column. However, what happened in their case was they got a column with no values in it. When we went to Edit->Preferences->Appearance->Columns the column had been defined but the type was not Custom and the Fields and Field Occurrence values had not been filled in. When he manually made them the same as what I have, it all worked. I just tried deleting that definition on my 3.2.1 installation and then re-adding it all worked correctly. My colleague is using a Mac. Not sure if this is relevant. -- 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
[Wireshark-dev] Do Lua Postdissectors still work with the most recent versions of Wireshark
Hi folks, I was looking around for a quick way to add some stuff to an existing protocol that we have extended in one way, and thought Lua might help. I found Lua postdissectors and it looks like they will help me do what I want. Are they still supported as of Wireshark 3.2.x? -- 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] Introduction - An Outreachy 2020 Applicant
On Fri, Oct 9, 2020 at 12:14 PM Amanda Shafack wrote: > > Good day. > > I'm Amanda Shafack, an Outreachy 2020 applicant who wishes to > contribute to the "Add Git protocol support to Wireshark" project. > > I have some experience coding in C and I hope to enhance > my skill set by contributing to this project. > > In addition, I'm fascinated by network protocols and it's really > exciting to get my hands around these concepts in a real-world > project. > > I'm currently going through the project description and contribution > guidelines. Welcome. There are many helpful people on the list. It would be useful if you can point us to a protocol description document but that can wait until help is needed. It may be that all the online resources are sufficient, but if not, do not hesitate to use this list to ask questions. -- 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] Introduction - An Outreachy 2020 Applicant
On Fri, Oct 9, 2020 at 8:18 AM Jonathan Nieder wrote: > > Jonathan Nieder wrote: > > > +wireshark-dev@wireshark.org > > Hi Amanda, > > > > Amanda Shafack wrote: > > > >> I am Amanda Shafack, an Outreachy 2020 applicant who wishes to > >> contribute to the "Add Git protocol support to Wireshark" project. Perhaps Amanda could resend her introduction on the wireshark-dev mailing list because this is the list for development type questions and will get better responses for developer-type questions. -- 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] Joint project with Git for outreachy
On Mon, Sep 21, 2020 at 8:01 AM Emily Shaffer via Wireshark-dev wrote: > > On Sat, Sep 19, 2020 at 03:36:23PM -0700, Junio C Hamano wrote: > > > > "brian m. carlson" writes: > > > > > On 2020-09-19 at 09:12:53, ronnie sahlberg wrote: > > >> Hi Jonathan, > > >> Hi Emily > > >> > > >> Emily, you want to contribute to wireshark? That is awesome. I think I > > >> speak for everyone to send a HUGE welcome > > >> your way and hope your experience working on and with wireshark be > > >> excellent! > > > > > > I think there's been a misunderstanding. I think the proposal was to > > > have Emily and Jonathan, who are both significant contributors to Git, > > > doing the mentoring from the Git side, along with someone from the > > > Wireshark side. I don't think we know yet if anyone will be interested > > > in working on it, but it seems from the response to be a proposal that > > > has interest in both projects. > > > > > > Feel free to correct me if I've misunderstood. > > > > That matches my understanding. > > Right - brian and Junio are correct, I'm hoping to co-mentor with > Jonathan. Ronnie, I'm really pleased to see this warm welcome, which > makes me optimistic about the kind of experience an intern would have on > this project. It would be really great if we could get a volunteer to > serve as point-of-contact if the mentee is not sure about something > they want to send to the Wireshark list, and possibly to come to an > introductory real-time chat (video/voice/IM) to provide a little > overview and nudge in the right direction. I am in the Bay Area so I can serve as the point of contact for some geographies, while Ronnie is in Australasia so he might make a better point of contact for those geographies. There is quite a bit of information in the Wireshark sources in the doc directory, including several README.* files. There is also a sample dissector in doc/packet-PROTOABBREV.c However, it can all be a bit daunting for a beginner so I am willing to help get things started. I should also point out that there are many people on the wireshark-developer mailing list who will be more than happy to help. -- 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] Joint project with Git for outreachy
On Sat, Sep 19, 2020 at 8:21 AM Jonathan Nieder wrote: > > Hi wiresharkers, > > Outreachy <https://www.outreachy.org/> is a program similar to the > Google Summer of Code, providing internships to work on open source > projects. > > Emily (cc-ed) and I would be interested in mentoring an outreachy > intern on adding support for the Git protocol to wireshark. We think > this would be helpful for documenting the spec better, for making > debugging easier for future Git developers, and for helping people > working on systems involving Git (e.g. CI systems) to understand the > behavior of the systems they oversee. We think that a co-mentor > within wireshark would be helpful for making sure an intern is set up > for success (helping them find pointers, making sure their approach is > on the right track, etc). > > This would be a project under the Git umbrella > <https://www.outreachy.org/communities/cfp/git/>. > > What do you think? Does this sound interesting to you? Replying again to all this time. We welcome any one who wants to write a dissector or help out in any area of Wireshark, as Ronnie said. I am more than happy to offer advice and ideas and look at code to get new Wireshark developers going. -- 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] Joint project with Git for outreachy
On Sat, Sep 19, 2020 at 2:13 AM ronnie sahlberg wrote: > > Hi Jonathan, > Hi Emily > > Emily, you want to contribute to wireshark? That is awesome. I think I > speak for everyone to send a HUGE welcome > your way and hope your experience working on and with wireshark be excellent! > > I think a git dissector would be really awesome. > We do have a packet-git.c already in wireshark, but looking at it it > is very barebones (understatement of the year:-) > but getting a real full blown git protocol implementation would be > totally awesome. > > I am more than happy to provide feedback and advice for Emily. We do > have pretty good development documentation so it should be pretty easy > to get started and get a development environment up and running. I agree. More than happy to help someone get up to speed with writing dissectors, and I am sure many other developers are as well. -- 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
[Wireshark-dev] The QT-5.15 disaster and an issue with multi-monitor setups, Windows and Wireshark
Hi folks, I just came across this article: https://linuxreviews.org/The_Qt_5.15_Disaster_On_Multi-Monitor_Setups What it describes is similar to what I have seen from time to time with Wireshark (3.2.1 and earlier versions) where if Wireshark is on my second monitor menu items will appear on the first monitor (and other craziness can occur as well.) Are these related at all? Do we plan to skip Qt 5.15? -- 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
[Wireshark-dev] Have we already switched over to gitlab?
Hi folks, Has the switchover occurred? -- 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] Filtering on a field when there is more than one such field in a Wi-Fi packet
On Thu, Aug 13, 2020 at 11:14 PM Jaap Keuter wrote: > > 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. I'm thinking of a gross hack like: wlan.tag.number == and found.wlan.tag.length >= Perhaps found would have to be somewhat more verbose to avoid matching against some obscure protocol, or perhaps it should be: wlan.tag.number == and found:wlan.tag.length >= -- 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
[Wireshark-dev] Filtering on a field when there is more than one such field in a Wi-Fi packet
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? -- 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] Code of Conduct for our community
On Wed, Aug 5, 2020 at 8:49 AM Uli Heilmeier wrote: > > All, > > As discussed in the last Remote Developer Den meeting I see a Code of Conduct > (CoC) as helpful for our community. Why? Nothing is broken at the moment, so nothing needs fixing, AFAICT. I would suggest the following alternative approach that the Samba team seems to have adopted: https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely As far as I can recall, there have been no instances of the behavior the Contributor Covenant seems to protect against, so what is the point here? Is someone saying that Wireshark is bad because of harassment on the lists? > I propose that we adopt the "Contributor Covenant" version 2 [1] for our > community. > This is a well established CoC with a good scope (including code review, > mailing lists, ask.wireshark.org, Sharkfest). > > The instance to handel reports should be a team consisting of 3 or 5 well > accepted community members (not only core > devs). The email address to reach them should be an alias or so > (repo...@wireshark.org). > We should have a wiki page where the team members are listed (similar to > node.js [2]). > > [3] gives a nice overview of CoC and is a good starting point to read. [4] is > a scientific paper discussing some aspects > of different CoC. > > So, what's your opinion? Any concerns? Any suggestions? > > Cheers > Uli > > [1] https://www.contributor-covenant.org/version/2/0/code_of_conduct.html > [2] https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md > [3] https://opensource.guide/code-of-conduct/ > [4] https://www.win.tue.nl/~aserebre/SANER2017.pdf > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- 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] Capturing 10GbE on a Linux laptop?
On Wed, Aug 5, 2020 at 8:56 AM Jasper Bongertz wrote: > > Hi Richard, > > I know there are some USB-C 10G network adapters (and the ProfiShark 10G, of > course), but I haven't tested any of them. I have tested one or two of them. They run warm to hot but seem to work. In my tests I used NVMe and at that time only had 1TB spare on the laptop I was using (on a second NVMe card), but it was fast enough for about 500-600MB/s. Now you can get 4TB NVMe or even 8TB NVMe (although you would pay $849 for 4TB.) However, you need Thunderbolt 3 and it seems that very few Linux laptops have that. System 76 has one or two (the Adder WS, for example.) The Librem laptops do not. Lenovo has one on it P51 and two on the P53. I used a NetGear GS110EMX to generate the traffic (with multiple devices plugged into it and mirroring all traffic to the 10GBe port(s).) > Writing that much data to disk is > something I do with small portable servers (about the size of a small shoe > box) > with a FPGA based capture card. NVMe can handle it ... -- 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
[Wireshark-dev] Capturing 10GbE on a Linux laptop?
Hi folks, Last year using my Cubro EX2+ I managed to capture around 600MB/s on my Lenovo P51 laptop. My P51 has a Thunderbolt 3 interface and has two 1TB NVMe storage devices that are capable of 2+GBps write speeds. I was aggregating multiple 1GbE interfaces into one of the 10GbE interfaces and then using a 10GbE to Thunderbolt 3 adapter. I had two Windows laptops and two OSX 10 laptops driving the load and interestingly the Apple laptops were generating more load than the Windows laptops via SMB2. My question is: Is there a Linux laptop out there that can handle that load. I have looked at System 76 and Librem but it does not seem they are capable of handling the load. -- 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] WLAN bug?
On Sun, Jul 5, 2020 at 5:29 AM Richard Sharpe wrote: > > On Sun, Jul 5, 2020 at 5:30 AM Jaap Keuter wrote: > > > > 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? > > Probably. The entries for 124 and 125 are duplicated at the end of the table. I have checked the standard and 124 and 125 are the correct entries. I am preparing a fix. -- 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] WLAN bug?
On Sun, Jul 5, 2020 at 5:30 AM Jaap Keuter wrote: > > 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? Probably. -- 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
[Wireshark-dev] Seems I can no longer submit changes for review
Hi folks, I tried to submit a change for review but got: remote: Unauthorized fatal: Authentication failed for 'https://code.wireshark.org/review/wireshark/' What is going on? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark and Kerberos keytabs?
Hi folks, I am trying to look inside kerberos blobs, so I followed the instructions at: https://wiki.samba.org/index.php/Keytab_Extraction and ran this command to extract the keytab for the user involved: ktpass.exe /out my.keytab /pass /princ @ /ptype KRB5_NT_PRINCIPAL /crypto all However, the enc part is not being busted out for me. Does anyone know how to do this? -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Gaining access to ff_pa_action_codes_ext from other protocols
On Thu, Jun 4, 2020 at 3:09 AM Peter Wu wrote: > > On Wed, Jun 03, 2020 at 11:17:01AM -0700, Richard Sharpe wrote: > > Hi folks, > > > > Some protocols define status values etc in terms of 802.11. > > > > I am trying to get the latest changes for IEEE1905 into Wireshark and > > have an issue where one or more dissector functions needs access to > > ff_pa_action_codes_ext. > > > > What is the best way to handle this? > > > > 1. Make it non static and allow the linker to deal with it? > > This is common. If it is just within the libwireshark (epan/) library, > you do not even need WS_DLL_PUBLIC or similar. Either declare it through > a header, or use 'extern value_string_ext ff_pa_action_codes_ext;' in > both the user and provider. OK, so it seems this is an acceptable solution then. I was just checking. -- 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
[Wireshark-dev] Gaining access to ff_pa_action_codes_ext from other protocols
Hi folks, Some protocols define status values etc in terms of 802.11. I am trying to get the latest changes for IEEE1905 into Wireshark and have an issue where one or more dissector functions needs access to ff_pa_action_codes_ext. What is the best way to handle this? 1. Make it non static and allow the linker to deal with it? 2. Provide a function that retrieves a pointer to it? 3. Some other mechanism? -- 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] asn2wrs.py no longer seems to generate the same code ...
On Sat, May 16, 2020 at 8:51 AM Pascal Quantin wrote: > > Hi Richard, > > Le sam. 16 mai 2020 à 17:34, Richard Sharpe a > écrit : >> >> On Sat, May 16, 2020 at 6:00 AM João Valverde >> wrote: >> > >> > Hi Richard, >> > >> > On 15/05/20 23:46, Richard Sharpe wrote: >> > > On Fri, May 15, 2020 at 3:33 PM Peter Wu wrote: >> > >> The "asn1" target rebuilds all asn1 dissectors. >> > >> Alternatively to rebuild a specific one, use a target such as >> > >> "generate_dissector-pkcs1". >> > > Sure, but there seems to be multiple issues. >> > > >> > > 1. The 'documented' command placed in the generated source does not >> > > generate the same source: >> > > 2. make asn1 modifies the source directory, but it seems to me that it >> > > should not do that because that breaks one of the out-of-tree >> > > guarantees that cmake gives you. >> > >> > Normally that would be true for a generated source file, but in this >> > case a choice was made to commit the generated ASN.1 source code to VCS >> > (for efficiency reasons I presume). Therefore the asn1 target is a >> > special one designed only to update the ASN.1 source tree and commit the >> > result. >> >> Shouldn't the developer make that decision? > > > That was a decision taken by the developers years ago, so I'm not sure I get > your point. The idea is to reduce the build time as those dissectors are not > updated that often and generating them takes some time. I understand that. However, if I make a change to one of the ASN files, as I just did, shouldn't it be my decision as to whether or not I want the modified .c file put in the source tree? -- 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] asn2wrs.py no longer seems to generate the same code ...
On Sat, May 16, 2020 at 6:00 AM João Valverde wrote: > > Hi Richard, > > On 15/05/20 23:46, Richard Sharpe wrote: > > On Fri, May 15, 2020 at 3:33 PM Peter Wu wrote: > >> The "asn1" target rebuilds all asn1 dissectors. > >> Alternatively to rebuild a specific one, use a target such as > >> "generate_dissector-pkcs1". > > Sure, but there seems to be multiple issues. > > > > 1. The 'documented' command placed in the generated source does not > > generate the same source: > > 2. make asn1 modifies the source directory, but it seems to me that it > > should not do that because that breaks one of the out-of-tree > > guarantees that cmake gives you. > > Normally that would be true for a generated source file, but in this > case a choice was made to commit the generated ASN.1 source code to VCS > (for efficiency reasons I presume). Therefore the asn1 target is a > special one designed only to update the ASN.1 source tree and commit the > result. Shouldn't the developer make that decision? -- 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] asn2wrs.py no longer seems to generate the same code ...
On Fri, May 15, 2020 at 3:33 PM Peter Wu wrote: > > The "asn1" target rebuilds all asn1 dissectors. > Alternatively to rebuild a specific one, use a target such as > "generate_dissector-pkcs1". Sure, but there seems to be multiple issues. 1. The 'documented' command placed in the generated source does not generate the same source: 2. make asn1 modifies the source directory, but it seems to me that it should not do that because that breaks one of the out-of-tree guarantees that cmake gives you. > Example: > > mkdir build > cd build > cmake .. > cmake --build . --target generate_dissector-pkcs1 > > Or if you use ninja: > > mkdir build > cd build > cmake -GNinja .. > ninja generate_dissector-pkcs1 -- 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] asn2wrs.py no longer seems to generate the same code ...
On Fri, May 15, 2020 at 2:29 PM Richard Sharpe wrote: > > On Fri, May 15, 2020 at 2:30 PM Peter Wu wrote: > > > > Hi Richard, > > > > On Fri, May 08, 2020 at 08:54:58AM -0700, Richard Sharpe wrote: > > [..] > > > It doesn't look like it was manually modified. The last person who > > > touched that file was Peter Wu, it seems, so maybe he can shed some > > > light on it. > > > > How did you invoke asn2wrs.py? If I run the asn1 ninja/make target on my > > system to regenerate dissectors based on the ASN.1 inputs, there are no > > further changes. > > I ran the command recorder in the header of the .c file. > > What is this ninja/make thing you refer to? To be more specific, I needed a callable function to dissect an ECDSA_Sig_Value, so I figured I could modify the .cnf file and run the command documented in the current packet-pkcs1.c file: /* asn2wrs.py -b -p pkcs1 -c ./pkcs1.cnf -s ./packet-pkcs1-template -D . -O ../.. PKIXAlgs-2009.asn */ However, that did not produce something that worked. It even generated different code for an unmodified .cnf file. However, just now I ran, from the build directory 'make asn1' after I modified pkcs1.cnf, and lo and behold, it modified my source directory. That was unexpected, because I thought the whole idea of cmake was that the source code would not be touched. Anyway, the code it generated does look correct (but was different to what was generated when I ran the 'documented' command) so I wonder what actual command it used. -- 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] asn2wrs.py no longer seems to generate the same code ...
On Fri, May 15, 2020 at 2:30 PM Peter Wu wrote: > > Hi Richard, > > On Fri, May 08, 2020 at 08:54:58AM -0700, Richard Sharpe wrote: > [..] > > It doesn't look like it was manually modified. The last person who > > touched that file was Peter Wu, it seems, so maybe he can shed some > > light on it. > > How did you invoke asn2wrs.py? If I run the asn1 ninja/make target on my > system to regenerate dissectors based on the ASN.1 inputs, there are no > further changes. I ran the command recorder in the header of the .c file. What is this ninja/make thing you refer to? -- 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] Cannot Decrypt Fast BSS Transition (802.11r) Packets
On Fri, May 15, 2020 at 10:27 AM Mikael Kanstrup wrote: > > Hi, > > Fast BSS Transitioning decryption is unfortunately not supported by Wireshark. > > Wireshark uses passphrase/PSK/PMK together with 4-way handshake to derive PTK > and GTK. FT key hierarchy and key derivation is not handled by the decryption > engine so PTK remains unknown which makes decryption fail. And unfortunately > directly entering PTK for decryption is not supported either. It could be but it would take some work :-) -- 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] Cannot Decrypt Fast BSS Transition (802.11r) Packets
On Wed, May 13, 2020 at 9:01 PM Mohit Khattar via Wireshark-dev wrote: > > Hi, > > We (myself and Jeff Hansen, CC'd) have been having trouble decrypting data > packets on a monitor-mode capture involving packets between an ath9k client > and a Fast BSS Transition-capable wireless network with WPA-EAP encryption. > We have tried using the PMK and the PTK from the AP, with no success. > We also tried decrypting data packets on a WPA-PSK wireless network using the > passphrase, and were unsuccessful if Fast BSS Transition was enabled on the > network. > > On wireless networks without fast-transition, we have been able to decrypt > both WPA-EAP (using PMK) monitor mode pcaps, as well as WPA-PSK pcaps (using > passphrase). > > I am using Version 3.2.3 (v3.2.3-0-gf39b50865a13), which is the newest > (stable) version currently available. > > Is decryption of fast BSS transition data packets supported by Wireshark? If > so, could you please suggest what we can do to investigate what is going on? It is not currently supported. The WFA uses an external tool to decrypt those packets. -- 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
[Wireshark-dev] Does a filter expression allow searching with a string of bytes as decimal numbers?
Hi folks, Suppose you have a field in packet that has been inserted as a byte string, say: some-proto.some-field = 0x21 0x32 0x81 Can I search on "some-proto.some-field == 33:50:129" or does the filter expression parser think those numbers between the colons are HEX digits? -- 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] asn2wrs.py no longer seems to generate the same code ...
On Fri, May 8, 2020 at 8:43 AM Pascal Quantin wrote:
>
> Hi Richard,
It doesn't look like it was manually modified. The last person who
touched that file was Peter Wu, it seems, so maybe he can shed some
light on it.
> Le ven. 8 mai 2020 à 17:08, Richard Sharpe a
> écrit :
>>
>> Hi folks,
>>
>> While figuring out how to get a dissection function for
>> ECDSA_Sig_Value, I noticed that asn2wrs.py no longer generates the
>> same code it once did.
>>
>> I re-ran asn2wrs.py against epan/dissectors/asn1/pkcs1/pkcs1.cnf
>> (unmodified) and then compared the current output to what is checked
>> in. This is what I get:
>>
>> ---
>> @@ -131,7 +131,7 @@
>>
>> static int
>> dissect_pkcs1_DigestAlgorithmIdentifier(gboolean implicit_tag _U_,
>> tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree
>> *tree _U_, int hf_index _U_) {
>> - offset = dissect_x509af_AlgorithmIdentifier(implicit_tag, tvb,
>> offset, actx, tree, hf_index);
>> + offset = dissect_AuthenticationFramework_AlgorithmIdentifier(implicit_tag,
>> tvb, offset, actx, tree, hf_index);
>>
>>return offset;
>> }
>> @@ -148,7 +148,7 @@
>>
>>
>> static const ber_sequence_t DigestInfo_sequence[] = {
>> - { _pkcs1_digestAlgorithm, BER_CLASS_UNI, BER_UNI_TAG_SEQUENCE,
>> BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
>> + { _pkcs1_digestAlgorithm, -1/*imported*/, -1/*imported*/,
>> BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
>>{ _pkcs1_digest, BER_CLASS_UNI, BER_UNI_TAG_OCTETSTRING,
>> BER_FLAGS_NOOWNTAG, dissect_pkcs1_Digest },
>>{ NULL, 0, 0, 0, NULL }
>> };
>> ...
>> ---
>>
>> This seems like a problem ...
>>
>> Perhaps I should file a bugzilla bug.
>
>
> Didi you check the file history to see whether it was manually modified? It
> might not be a asn2wrs.py problem.
>
> Best regards,
> Pascal.
> ___________
> Sent via:Wireshark-dev mailing list
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
--
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
[Wireshark-dev] asn2wrs.py no longer seems to generate the same code ...
Hi folks,
While figuring out how to get a dissection function for
ECDSA_Sig_Value, I noticed that asn2wrs.py no longer generates the
same code it once did.
I re-ran asn2wrs.py against epan/dissectors/asn1/pkcs1/pkcs1.cnf
(unmodified) and then compared the current output to what is checked
in. This is what I get:
---
@@ -131,7 +131,7 @@
static int
dissect_pkcs1_DigestAlgorithmIdentifier(gboolean implicit_tag _U_,
tvbuff_t *tvb _U_, int offset _U_, asn1_ctx_t *actx _U_, proto_tree
*tree _U_, int hf_index _U_) {
- offset = dissect_x509af_AlgorithmIdentifier(implicit_tag, tvb,
offset, actx, tree, hf_index);
+ offset = dissect_AuthenticationFramework_AlgorithmIdentifier(implicit_tag,
tvb, offset, actx, tree, hf_index);
return offset;
}
@@ -148,7 +148,7 @@
static const ber_sequence_t DigestInfo_sequence[] = {
- { _pkcs1_digestAlgorithm, BER_CLASS_UNI, BER_UNI_TAG_SEQUENCE,
BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
+ { _pkcs1_digestAlgorithm, -1/*imported*/, -1/*imported*/,
BER_FLAGS_NOOWNTAG, dissect_pkcs1_DigestAlgorithmIdentifier },
{ _pkcs1_digest, BER_CLASS_UNI, BER_UNI_TAG_OCTETSTRING,
BER_FLAGS_NOOWNTAG, dissect_pkcs1_Digest },
{ NULL, 0, 0, 0, NULL }
};
...
---
This seems like a problem ...
Perhaps I should file a bugzilla bug.
--
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] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?
On Thu, May 7, 2020 at 8:04 AM Pascal Quantin wrote:
>
> Hi Richard,
>
> Le jeu. 7 mai 2020 à 17:01, Richard Sharpe a
> écrit :
>>
>> Hi folks,
>>
>> I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in
>> epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as:
>>
>> -
>>ECDSA-Sig-Value ::= SEQUENCE {
>> r INTEGER,
>> s INTEGER
>>}
>> -
>>
>> I tried the obvious by adding it as an export to the pkcs1.cnf file by
>> adding it to the .EXPORTS section but perhaps I forgot to remove it
>> from the .NO_EMIT section ...
>
>
> Do you need a dissector registered by name, or a function to call?
Just a function to call.
After sending this message I tried removing it from the .NO_EMIT
section and adding it to the .EXPORTS section and wonder of wonders, I
got a callable function that does what I need :-)
--
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
[Wireshark-dev] How do I expose ECDSA-Sig-Value as a dissect function in pkcs1?
Hi folks,
I need a dissector for an EDCSA-Sig-Value, and it is nicely defined in
epan/dissectors/asn1/pkcs1/PKIXAlgs-2009.asn as:
-
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-
I tried the obvious by adding it as an export to the pkcs1.cnf file by
adding it to the .EXPORTS section but perhaps I forgot to remove it
from the .NO_EMIT section ...
Is that all I need to do (and then re-run the command to generate the
new packet-pcks1.c file?)
--
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
[Wireshark-dev] Has anything changed with respect to contributing changes to Wireshark after github?
Hi folks, I think I saw an email about things moving to github or gitlab and wondered if they meant any changes to my workflow around submitting changes? If so, is there a link I can use to see what they are? -- 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] "Custom" link-layer types for pcap and pcapng
On Thu, Mar 26, 2020 at 7:44 PM Guy Harris wrote: > > Here's the proposal for "custom" link-layer types I threatened^Wpromised in > my earlier email. > > A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, with > libpcap offering a DLT_CUSTOM. > > A custom link-layer type has a 32-bit IANA-registered Private Enterprise > Number (PEN): > > https://en.wikipedia.org/wiki/Private_Enterprise_Number > > https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers > > as is used for custom pcapng blocks and options. > > We could either 1) also say it should have a 32-bit per-vendor link-layer > type number or 2) say that if the vendor plans to use it for more than one > type of link-layer header, they have to arrange that the link-layer header > should begin with information necessary to determine what the *rest* of the > link-layer header is. > > 2) is more along the lines of the way custom block and options work. However: > > every non-custom block includes a block type, and every non-custom > option has an option type, but not every *block* in a capture file has a > link-layer header type - a pcap header has a link-layer type that applies to > all packets in the file and a pcapng IDB has a link-layer type that applies > to all packets on that interface; > > knowing the link-layer type up front makes it easier to generate BPF > filter code for an interface, if we support these types for live capture (or > if the vendor's private capture mechanism supports it); > > so I'm inclined to go with 1). > > In that model: > > in pcap files, if the lower 16 bits of the 32-bit link-layer type > value is 0x, the two "Reserved" fields (which were formerly a > rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone > offset and time stamp resolution) MUST contain the PEN and vendor-specific > link-layer type; > > in pcapng file, if the link-layer type in an IDB is 0x, the IDB > *MUST* contain a new option, containing the PEN and vendor-specific > link-layer type. > > Given that it's for *two* capture file formats, these lists are probably > better places for discussion than having two pull requests and discussing > them in comments there. Sounds good to me. -- 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
[Wireshark-dev] I have some captures from Jouni's hwsim for 802.11 with Anti-Clogging tokens
Hi folks, How do I get these into the collection? -- 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] Request for a Wireshark Update to support TEAP traffic analysis.
On Fri, Feb 7, 2020 at 7:33 AM Nikhil Jadhav wrote: > Hello Developers, > > > > I am working on Cisco ISE and I find the Wireshark tool very beneficial to > analyze different packets. So Cheers to all your hard work!!! > > I am using Windows 10 (Insider Preview Build with TEAP support) endpoint > with the latest version of Wireshark running (Version 3.2.1 > (v3.2.1-0-gbf38a67724d0)). > > Currently there is a new TEAP protocol (Tunneled EAP protocol - RFC 7170) > , and we tried to analyze the TEAP traffic on Wireshark but Wireshark shows > the Code-Type in EAP as ‘Unknown’ instead of ‘TEAP’ even though it > identifies the code as 55. Also, could you please let me know if there be > way to analyze the TEAP traffic by adding certificate to Wireshark. > > > > Kindly please have a look at the attached Wireshark screenshots of TEAP > Traffic and PEAP traffic so as to have a better comparison and > understanding of the issue. > > > Here's your chance to become one of the famous wireshark developers. 1. Get the source. 2. Inside epan/dissectors/packet-eap.c there is an array of value_string structs called eap_type_vals. 3. Add the new entry or entries to that table. 4. Rebuild. Probably on Linux because building on Windows is hard. 5. Feed the capture into the new build. 6. Feel a burst of joy at making your first change to Wireshark. 7. Add any new attributes or whatever is needed to properly dissect the whole new types. 8. Submit a code review. -- 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] PIM: Support for dissection of PIM Flooding Mechanisme (PFM)
On Wed, Dec 25, 2019 at 12:52 PM Anders Reggestad wrote: > > Hi, > > I have as part of a study of the RFC8364, written a dissection of the PFM > message from https://tools.ietf.org/html/rfc8364 as part of the Protocol > Independed Multicast (PIM) dissection. Not sure if this is of interest to > include into the source base or not? If someone would find it useful then you should submit it. https://code.wireshark.org/review -- 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
