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

2023-12-04 Thread Martin Mathieson via Wireshark-dev
I have been doing internal Wireshark releases for years wherever I've been working (as far as I know, they have never been sent outside of the company). I have *never* used the plugin mechanism. I package up the entire program, even if only one file has been changed. My current company has

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

2023-11-22 Thread Martin Mathieson via Wireshark-dev
Pretty sure I'm not adding anything useful here, but I was only vaguely aware of debian packaging support. If I'm sharing builds with colleagues, I use Windows packaging, or for Ubuntu we tend to set CMAKE_INSTALL_PREFIX, build the 'install' target and transfer it as a tarball. On Wed, Nov 22,

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

2023-09-22 Thread Martin Mathieson via Wireshark-dev
Thanks Pascal. On Fri, Sep 22, 2023 at 12:54 PM Pascal Quantin wrote: > Hi Martin, > > Le jeu. 21 sept. 2023 à 22:20, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> a écrit : > >> After https://gitlab.com/wireshark/wireshark/-/merge_req

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

2023-09-21 Thread Martin Mathieson via Wireshark-dev
After https://gitlab.com/wireshark/wireshark/-/merge_requests/12195, I'm finding the warnings below. I think these are valid, based upon editing a mask value and watching how the value was masked/shifted before being looked up in the value_string. I understand the RoHC example, where a newer

Re: [Wireshark-dev] Some items with apparently out-of-range value_string values?

2023-02-13 Thread Martin Mathieson via Wireshark-dev
er > > On Sun, Feb 12, 2023, 6:14 PM Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> Hi, >> >> I have added another check to CHECK_HF_FILTER in proto.c (extra checks >> that only get done in the 'CLANG + Code check

[Wireshark-dev] Some items with apparently out-of-range value_string values?

2023-02-12 Thread Martin Mathieson via Wireshark-dev
Hi, I have added another check to CHECK_HF_FILTER in proto.c (extra checks that only get done in the 'CLANG + Code checks' pipeline build) to check for values in an item's value_string that could not be represented in the item's type (e.g. a value of > 255 for FT_UINT8). I can eventually look

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-08 Thread Martin Mathieson via Wireshark-dev
bad as the filenames with a "+" in the names, but >>> would file-darwin.c be enough? >>> >>> On Sat, Feb 4, 2023 at 10:48 AM Martin Mathieson via Wireshark-dev < >>> wireshark-dev@wireshark.org> wrote: >>> >>>> Please see htt

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-04 Thread Martin Mathieson via Wireshark-dev
ent.c >> >> I guess it's not as bad as the filenames with a "+" in the names, but >> would file-darwin.c be enough? >> >> On Sat, Feb 4, 2023 at 10:48 AM Martin Mathieson via Wireshark-dev < >> wireshark-dev@wireshark.org> wrote: >> >>>

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-04 Thread Martin Mathieson via Wireshark-dev
Yes, if there are likely no other similar types. On Sat, 4 Feb 2023, 16:56 chuck c, wrote: > file-pcapng_darwin_process_event.c > > I guess it's not as bad as the filenames with a "+" in the names, but > would file-darwin.c be enough? > > On Sat, Feb 4, 2023 at 1

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-04 Thread Martin Mathieson via Wireshark-dev
Please see https://gitlab.com/wireshark/wireshark/-/merge_requests/9688 I have yet to port my (genuinely) local block type, but would like to see if this approach looks OK. More thought might be needed to stay safe while dealing with block types that don't have options. On Fri, Feb 3, 2023 at

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-03 Thread Martin Mathieson via Wireshark-dev
On Fri, Feb 3, 2023 at 7:25 AM Guy Harris wrote: > On Feb 1, 2023, at 12:58 AM, Joakim wrote: > > > if you manage to add a dissector table that would be great! I believe my > company too will implement non-standard blocks so it would be very > convenient to have it available. > > Note that

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-03 Thread Martin Mathieson via Wireshark-dev
On Fri, Feb 3, 2023 at 7:05 AM Guy Harris wrote: > On Jan 28, 2023, at 3:19 PM, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > > I have 5 non-standardised/local block types that are in-use within my > company, that are in the 'local' rang

Re: [Wireshark-dev] Dissecting pcapng local block types

2023-02-02 Thread Martin Mathieson via Wireshark-dev
On Wed, Feb 1, 2023 at 8:58 AM Joakim wrote: > Hi, > > if you manage to add a dissector table that would be great! I believe my > company too will implement non-standard blocks so it would be very > convenient to have it available. > > //Joakim > > On Sun, 29 Jan 2023 at

[Wireshark-dev] Dissecting pcapng local block types

2023-01-28 Thread Martin Mathieson via Wireshark-dev
I have 5 non-standardised/local block types that are in-use within my company, that are in the 'local' range 0x8000-0x. My first thought was to add a dissector table (pcapng.block-types ?) by 'Block Type Code' in file-pcapng.c, then have dissectors register by adding themselves to

Re: [Wireshark-dev] Build breakage on master?

2022-03-01 Thread Martin Mathieson via Wireshark-dev
Thanks for the responses. Somehow, epan/dissectors/packet-ncp.c did exist in the build folder, but was empty. After deleting it and rebuilding the correct file was generated. Martin On Tue, Mar 1, 2022 at 12:02 AM Guy Harris wrote: > > On Mon, Feb 28, 2022 at 10:58 AM Martin Mathies

[Wireshark-dev] Build breakage on master?

2022-02-28 Thread Martin Mathieson via Wireshark-dev
I am seeing this error on master. Don't have time to look into it just now, but I have just made a new VM for building Wireshark. Which object file is supposed to implement these? /usr/bin/ld: run/libwireshark.so.0.0.0: undefined reference to `nds_defrag' /usr/bin/ld:

Re: [Wireshark-dev] Build of packet-http2.c broken without HAVE_NGHTTP2

2021-11-28 Thread Martin Mathieson via Wireshark-dev
Thanks! On Sun, Nov 28, 2021 at 3:34 AM qiangxiong.huang via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Fixed in MR (https://gitlab.com/wireshark/wireshark/-/merge_requests/5243 > ). > > -- Original -- > *From:* "Developer support list for Wireshark" <

[Wireshark-dev] Build of packet-http2.c broken without HAVE_NGHTTP2

2021-11-27 Thread Martin Mathieson via Wireshark-dev
I have run out of time tonight, but it looks as though quite a lot more of this dissector needs to be inside #ifdef HAVE_NGHTTP2 [ 42%] Building C object epan/dissectors/CMakeFiles/dissectors.dir/packet-http2.c.o /home/martin/wireshark/epan/dissectors/packet-http2.c:1038:56: error: expected ‘)’

[Wireshark-dev] Does it make sense to have an FT_BOOLEAN field and > 1 bit set in mask?

2021-10-14 Thread Martin Mathieson via Wireshark-dev
I added this check to tools/check_typed_item_calls.py --mask I am hoping that someone will recognise a protocol they know and check out what is reported, and to be able to work out if this check makes sense to do. Quite a few of the current cases have to do with multi-bit reserved fields, where

Re: [Wireshark-dev] re-load IKEv2 / ESP UAT during wireshark gui runtime

2021-08-19 Thread Martin Mathieson via Wireshark-dev
I have nothing against a text keylog file approach, but FWIW with ESP UAT (or the run-time function I mentioned), you can configure the key in hex prefixed with 0x. Martin On Thu, Aug 19, 2021 at 6:37 PM Nicolás Alvarez wrote: > El jue, 19 de ago. de 2021 a la(s) 08:30, Harald Welte >

Re: [Wireshark-dev] re-load IKEv2 / ESP UAT during wireshark gui runtime

2021-08-19 Thread Martin Mathieson via Wireshark-dev
Hi Harald, I realise this may not be convenient for you, but what I have done a couple of times is to have a private dissector parse logging frames in the same capture that contain info about new SAs being created. With all of the relevant information in hand, the dissector then calls

Re: [Wireshark-dev] RTP-MIDI strange field masks?

2021-07-08 Thread Martin Mathieson via Wireshark-dev
Thanks, I clearly didn't read the line I quoted properly.. On Thu, 8 Jul 2021, 19:46 Tomasz Moń, wrote: > On Thursday, July 8, 2021, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me

[Wireshark-dev] RTP-MIDI strange field masks?

2021-07-08 Thread Martin Mathieson via Wireshark-dev
These mask fields (0x7f7f, 0x7f7f7f7f, etc) look wrong to me, but I am worried I might be missing something? Looking at an example in RFC 4695 (Song Position Pointer) I think this (on page 157) is saying that is it just a 2-byte field (and should therefore have a non-mask of 0x0)? | Song Position

Re: [Wireshark-dev] Struggling to setup Windows command-line build

2021-06-22 Thread Martin Mathieson via Wireshark-dev
t; > What was the solution? > > On Tue, Jun 22, 2021 at 4:26 AM Graham Bloice > wrote: > >> >> On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev < >> wireshark-dev@wireshark.org> wrote: >> >>> Hi, >>> >>> I am usin

[Wireshark-dev] Struggling to build NSIS installation

2021-06-22 Thread Martin Mathieson via Wireshark-dev
Does the Java warning sound important? Is there something I should do to try to increase the java heap size? This machine should have loads (c20GB) of memory available.. [image: image.png] Best regards, Martin ___ Sent

[Wireshark-dev] Struggling to setup Windows command-line build

2021-06-22 Thread Martin Mathieson via Wireshark-dev
Hi, I am using Visual Studio 2019 (not community version). My cmake step is succeeding, but when I try to build, it is pointing at an invalid solution configuration. [image: image.png] My cmake command is: [image: image.png] I don't know why it is trying to build with RelWithDebInfo | *x86*.

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

2021-05-27 Thread Martin Mathieson via Wireshark-dev
gt; https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/4849#note_587084318 > > On 5/19/21 6:53 AM, Martin Mathieson via Wireshark-dev wrote: > > I did take a capture. All I see is a FIN,ACK from the server, after > which it sent another couple of ACKs. > > There are lot

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

2021-05-19 Thread Martin Mathieson via Wireshark-dev
Thanks, this got me going. Martin On Wed, May 19, 2021 at 5:27 PM Roland Knall wrote: > You can try to just capture a single depth (--depth 1) and see if this > works > > regards > Roland > > Am Mi., 19. Mai 2021 um 15:54 Uhr schrieb Martin Mathieson via > Wiresha

Re: [Wireshark-dev] Having trouble cloning repo in a new VM

2021-05-19 Thread Martin Mathieson via Wireshark-dev
. Martin On Wed, May 19, 2021 at 2:21 PM Jim Young wrote: > Hello Martin, > > On Wed, May 19, 2021 at 7:09 AM Martin Mathieson via Wireshark-dev > wrote: > > ... when I try to clone it starts to go through the stages (i.e. > counting/compressing/ receiving objects/resolvi

[Wireshark-dev] Having trouble cloning repo in a new VM

2021-05-19 Thread Martin Mathieson via Wireshark-dev
I am trying to set up a Wireshark dev env on a new machine/Ubuntu VM. Have generated new keys and added them to my account. It appears to accept my credentials. However, when I try to clone it starts to go through the stages (i.e. counting/compressing/ receiving objects/resolving objects) I am

Re: [Wireshark-dev] Qt link errors (Q_INIT_RESOURCE)

2021-03-31 Thread Martin Mathieson via Wireshark-dev
f that fixes the problem then we might have to > enable CMAKE_AUTO* earlier or later depending on our CMake version. > > I also noticed that https://doc.qt.io/qt-5/qdir.html#Q_INIT_RESOURCE says > > "This macro cannot be used in a namespace. It should be called from > main()

[Wireshark-dev] Qt link errors (Q_INIT_RESOURCE)

2021-03-30 Thread Martin Mathieson via Wireshark-dev
I started getting this link error a day or 2 back: [ 98%] Linking CXX executable run/wireshark /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: ui/qt/CMakeFiles/qtui.dir/wireshark_application.cpp.o: in function `WiresharkApplication::WiresharkApplication(int&, char**)':

[Wireshark-dev] File formats that extcap programs can write

2021-03-21 Thread Martin Mathieson via Wireshark-dev
Hi Can an extcap program write to a wiretap-supported file format other than pcap or pcapng? A quick test (hack to file preamble and frames in extcap_example.py) suggests not.. Has it to do with synchronising whole frames being read at the wireshark end of the pipe? Regards, Martin

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

2021-01-27 Thread Martin Mathieson via Wireshark-dev
reshark/blob/e738b556d72d4db5d7df85969c15117dedd0d063/epan/dissectors/packet-xml.c > > Search for “xml_get_attrib" So it seems it was part of packet-xml.c at > some point so perhaps safe to remove… > > /Anders > > > > *From:* Wireshark-dev *On Behalf Of > *Martin Mathi

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

2021-01-27 Thread Martin Mathieson via Wireshark-dev
by case for each function. > And of course the risk of breaking someone elses plugin is always there, > however small, so I think it needs to proceed with some caution. > > > On 27/01/21 11:06, Martin Mathieson via Wireshark-dev wrote: > > My most recent MR ( > https://gi

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

2021-01-27 Thread Martin Mathieson via Wireshark-dev
My most recent MR ( https://gitlab.com/wireshark/wireshark/-/merge_requests/1829), has come across some symbols that don't appear to be in used by our repo. dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below 4934

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

2021-01-26 Thread Martin Mathieson via Wireshark-dev
I have done a bit more on this - I started picking off the ones at the end of the (alphabetical) list - 2nd one is https://gitlab.com/wireshark/wireshark/-/merge_requests/1817. Please feel free if anyone feels motivated to tackle some of the earlier ones. The script is much tidier now, and also

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

2021-01-24 Thread Martin Mathieson via Wireshark-dev
On Sun, Jan 24, 2021 at 8:27 PM Jirka Novak wrote: > Hi, > > I checked the code I know: > > > epan/dissectors/packet-rtp-events.c (01a0 D> > rtp_event_type_values_ext) is not referred to so could be static? (in> > header) > It is used in UI, outside of dissectors. Therefore it

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

2021-01-24 Thread Martin Mathieson via Wireshark-dev
at 11:57 PM Moshe Kaplan wrote: > Would it also be possible to build this script into a GitLab CI job, to > detect and prevent the issue from recurring? > > Moshe > > On Sat, Jan 23, 2021 at 11:45 AM Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wr

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

2021-01-23 Thread Martin Mathieson via Wireshark-dev
Hi, I wrote a script to check whether variables and functions in dissector modules that were not static were: - not called by any other dissector modules (including dissectors.c) - mentioned in the header file corresponding to that dissector Reasons to clean up these cases could include: - it

Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-17 Thread Martin Mathieson via Wireshark-dev
On Fri, Oct 16, 2020 at 11:14 PM Guy Harris wrote: > On Oct 16, 2020, at 2:54 PM, Martin Mathieson < > martin.r.mathie...@googlemail.com> wrote: > > > There might be some protocols where there was (say) a 7 byte integer > field, so the dissector writer had to round it up to the nearest supported

Re: [Wireshark-dev] proto_tree_add_item() calls where length doesn't match type of hf item

2020-10-16 Thread Martin Mathieson via Wireshark-dev
to in the very next line (i.e. which size does it match?), but that would be hard to reliably parse. On Fri, Oct 16, 2020 at 10:43 PM Guy Harris wrote: > On Oct 16, 2020, at 2:38 PM, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > > I made a quick

[Wireshark-dev] Build failure for me on master

2020-10-09 Thread Martin Mathieson via Wireshark-dev
Am I the only person seeing this over the past couple of days? /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: ui/qt/CMakeFiles/qtui.dir/extcap_argument.cpp.o: undefined reference to symbol '_ZTVN10__cxxabiv117__class_type_infoE@@CXXABI_1.3'

Re: [Wireshark-dev] Build error with packet-cipmotion.c ?

2020-08-30 Thread Martin Mathieson via Wireshark-dev
I created https://gitlab.com/wireshark/wireshark/-/merge_requests/65 for this. Martin On Sun, Aug 30, 2020 at 10:22 AM Dario Lombardo wrote: > I'm seeing the same thing on several builders. It definitely needs fixing. > > On Sat, Aug 29, 2020, 21:53 Martin Mathieson via Wire

[Wireshark-dev] Build error with packet-cipmotion.c ?

2020-08-29 Thread Martin Mathieson via Wireshark-dev
I am seeing this error with current master: /home/martin/wireshark_gl/epan/dissectors/packet-cipmotion.c: In function ‘dissect_cipmotion3’: /home/martin/wireshark_gl/epan/dissectors/packet-cipmotion.c:2173:4: error: missing initializer for field ‘TransportClass_trigger’ of ‘cip_conn_info_t’

Re: [Wireshark-dev] Some apparent type bugs

2020-07-31 Thread Martin Mathieson via Wireshark-dev
Oops. On Fri, Jul 31, 2020 at 1:05 PM Jaap Keuter wrote: > Hi, > > This one you probably have to look into yourself, because that’s not from > the published code base, AFAIKT. > > Thanks, > Jaap > > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev <

Re: [Wireshark-dev] Some apparent type bugs

2020-07-31 Thread Martin Mathieson via Wireshark-dev
’m afraid. > > Thanks, > Jaap > > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > Error: proto_tree_add_item_ret_uint64 (.., hf_epl_od_uint , ...) called at > ./tools/../epan/dissectors/packet-epl.c 2744 with

Re: [Wireshark-dev] Some apparent type bugs

2020-07-31 Thread Martin Mathieson via Wireshark-dev
aap Keuter wrote: > Hi, > > Shouldn’t these be supported? After all, they have a UINT. > > On 31 Jul 2020, at 11:28, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > Error: proto_tree_add_item_ret_uint (.., hf_lcp_opt_id , ...) called at &

[Wireshark-dev] Some apparent type bugs

2020-07-31 Thread Martin Mathieson via Wireshark-dev
Hi, I wrote a script to try to check the types of hf items passed to proto.h APIs where there is a subset of types that are allowed. i.e. Trying to stop errors such as: ** (process:8243): WARNING **: Dissector bug, protocol IDN, in packet 126: epan/proto.c:11693: field idn.gts_wavelength_prefix

[Wireshark-dev] Using tools/check_dissector_urls.py in Petri-dish ?

2020-07-09 Thread Martin Mathieson via Wireshark-dev
Hi, I find that a lack of protocol documentation often makes it hard to check details that would make fixing simple bugs or investigating apparent inconsistencies easier. I could give check_dissector_urls.py similar command-line options to cppcheck.sh (i.e. support '-l 1' to only consider the

Re: [Wireshark-dev] Build boot stuck?

2020-07-07 Thread Martin Mathieson via Wireshark-dev
shark.org/review/c/37773/. > > On 7/7/20 7:10 AM, Martin Mathieson via Wireshark-dev wrote: > > Alexis, > > > > Anders change https://code.wireshark.org/review/#/c/37770/ only affects > a header file. > > Is it now running cppcheck -l 1, which would scan the whole

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

2020-07-07 Thread Martin Mathieson via Wireshark-dev
m support release and there are some distributions > stuck on it. I can change my recent commit if we don't want to bump the > required version. > > John > > On Tue, Jul 7, 2020, 9:15 AM Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >>

Re: [Wireshark-dev] Build boot stuck?

2020-07-07 Thread Martin Mathieson via Wireshark-dev
Alexis, Anders change https://code.wireshark.org/review/#/c/37770/ only affects a header file. Is it now running cppcheck -l 1, which would scan the whole tree? Martin On Tue, Jul 7, 2020 at 3:05 PM Anders Broman via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Hi, > > The latest

[Wireshark-dev] Version of Qt required?

2020-07-07 Thread Martin Mathieson via Wireshark-dev
In a VM where I build Wireshark, I am getting this error on master: /home/martin/wireshark/ui/qt/follow_stream_dialog.cpp: In member function ‘void FollowStreamDialog::addCodecs(const QMap&)’: /home/martin/wireshark/ui/qt/follow_stream_dialog.cpp:164:47: error: ‘qAsConst’ was not declared in this

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

2020-07-06 Thread Martin Mathieson via Wireshark-dev
, at 9:09 AM, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > > > > I added https://code.wireshark.org/review/#/c/37711/ for the DVB-S2-BB > one. It is a range_string, where arguably a value_string would be clearer, > but the linked-to

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

2020-07-05 Thread Martin Mathieson via Wireshark-dev
I added https://code.wireshark.org/review/#/c/37711/ for the DVB-S2-BB one. It is a range_string, where arguably a value_string would be clearer, but the linked-to documentation is currently unavailable. Martin On Sun, Jul 5, 2020 at 11:41 AM Jaap Keuter wrote: > Hi, > > Okay, we should at

[Wireshark-dev] On buildbot, cppcheck stuck on 3-months old build

2020-05-27 Thread Martin Mathieson via Wireshark-dev
Looking at the last cppcheck build on master ( https://buildbot.wireshark.org/wireshark-master/builders/Clang%20Code%20Analysis/builds/5214/steps/cppcheck/logs/stdio), it was done on the weekend but using an old revision of master. Looking at build 5214 (dated 24th May), it tests revision

[Wireshark-dev] Deleting unused header file inclusions (revisited)

2020-05-18 Thread Martin Mathieson via Wireshark-dev
Hi, Do we want to prune unnecessary header file inclusions? In https://code.wireshark.org/review/#/c/37210/, I have updated tools/delete_includes.py and run it on epan/dissectors. There are some uncontroversial ones I think, e.g. including where it isn't needed (maybe someone added some

Re: [Wireshark-dev] range_string checking

2020-04-06 Thread Martin Mathieson via Wireshark-dev
t;> >> My plan is to fix the remaining handful of issues and check it in as >> it is, then I'll experiment with seeing if I can find any others. >> >> The only other automated check along these lines I tried recently was for >> enumerated preferences (i.e. looking

Re: [Wireshark-dev] range_string checking

2020-04-04 Thread Martin Mathieson via Wireshark-dev
recently was for > enumerated preferences (i.e. looking for duplicated IDs or strings), but it > sadly(?) didn't find anything... > > Martin > > On Sat, Apr 4, 2020 at 2:53 PM Jaap Keuter wrote: > >> >> >> On 2 Apr 2020, at 23:08, Martin Mathieson via Wiresh

Re: [Wireshark-dev] range_string checking

2020-04-04 Thread Martin Mathieson via Wireshark-dev
automated check along these lines I tried recently was for enumerated preferences (i.e. looking for duplicated IDs or strings), but it sadly(?) didn't find anything... Martin On Sat, Apr 4, 2020 at 2:53 PM Jaap Keuter wrote: > > > On 2 Apr 2020, at 23:08, Martin Mathieson via Wireshark-dev <

Re: [Wireshark-dev] range_string checking

2020-04-03 Thread Martin Mathieson via Wireshark-dev
and Diameter parts - I haven't looked at any of them in detail. Best regards, Martin On Fri, Apr 3, 2020 at 8:38 AM Pascal Quantin wrote: > Hi Martin, > > Le jeu. 2 avr. 2020 à 23:08, Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> a écrit : > >> H

[Wireshark-dev] range_string checking

2020-04-02 Thread Martin Mathieson via Wireshark-dev
Hi, I have been adding checking to proto.c (that will be protected by #ifdef ENABLE_CHECK_FILTER) to see if range_string arrays passed into tmp_fld_check_assert() look sensible. The checks I'm doing are: (1) it is a problem if the max is < min for any range_string (2) if an entry within an array

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

2020-03-23 Thread Martin Mathieson via Wireshark-dev
This works for me (when I cherry-pick all 3 of your changes). Martin On Mon, Mar 23, 2020 at 9:43 AM Dario Lombardo wrote: > Ok, this seems to work. I'm pushing the fix. > > On Mon, Mar 23, 2020 at 9:29 AM Pascal Quantin > wrote: > >> >> >> Le lun. 23 mars 2020 à 09:17, Dario Lombardo a écrit

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

2020-03-22 Thread Martin Mathieson via Wireshark-dev
issues with conditional compilation with kerberos. > However I cannot reproduce this exact problem. Which is your build > environment? > > On Sat, Mar 21, 2020 at 9:41 PM Martin Mathieson via Wireshark-dev < > wireshark-dev@wireshark.org> wrote: > >> I am seeing t

[Wireshark-dev] Build failure (kerberos)

2020-03-21 Thread Martin Mathieson via Wireshark-dev
I am seeing this: ./asn1/kerberos/packet-kerberos-template.c: In function ‘dissect_krb5_PAC_CREDENTIAL_INFO’: ./asn1/kerberos/packet-kerberos-template.c:2187:2: error: implicit declaration of function ‘decrypt_krb5_data’ [-Werror=implicit-function-declaration]

[Wireshark-dev] Error while building NSIS package

2019-05-14 Thread Martin Mathieson via Wireshark-dev
As the last step of building a Windows package, I ran msbuild /m /p:Configuration=RelWithDebInfo nsis_package.vcxproj and got the error below. There are lots of libs in C:\Development\wsbuild64\run\RelWithDebInfo, but no libglib-2.0-0.dll I can't see that anything obvious has changed in

Re: [Wireshark-dev] Anyone working on a Syncthing dissector?

2018-11-09 Thread Martin Mathieson via Wireshark-dev
Hi, I have a simple dissector (private) which just calls protoc --decode, reads the output from a pipe and shows the output using "data-text-lines". In my environment, I have quite a few protobuf protocols that change often. I basically have a table whose columns are: - .UDP port number -

[Wireshark-dev] asn2wry.py - showing protocol version ?

2018-10-17 Thread Martin Mathieson via Wireshark-dev
Hi, I would like to be able to show, for the generated dissectors, the version of the protocol. For 3GPP protocols, in theory they are backwards-compatible, but not at this point in the NR(5G) standards. So for the 3GPP .asn files, the first line might be e.g. -- 3GPP TS 38.331 V15.3.0

[Wireshark-dev] Master build broken for me (packet-http2.c)

2018-09-28 Thread Martin Mathieson via Wireshark-dev
I am getting this build error: home/martin/wireshark/epan/dissectors/packet-http2.c: In function ‘http2_get_stream_id’: /home/martin/wireshark/epan/dissectors/packet-http2.c:1124:21: error: ‘http2_session_t’ has no member named ‘current_stream_id’ return h2session->current_stream_id;

[Wireshark-dev] Build failure today

2018-04-20 Thread Martin Mathieson via Wireshark-dev
I'm getting the error below: Looking at the first one, my compiler doesn't seem to realise that compute_offset() will throw an exception rather than return a number without setting *offset_ptr But when I look at e.g. BoundsError (which may be returned without setting *offset_ptr), it is

Re: [Wireshark-dev] QCustomPlot 2.0.0

2018-02-10 Thread Martin Mathieson via Wireshark-dev
but in the long run seems to be the better method. > > Does not mean we should remove QCustomPlot right away or at all, but keep > it in the 2.x and go with Qt Charts in 3.0. As said, depends on the version > of Qt we choose for 3.0 > > cheers > Roland > > On Sat, Feb 10, 2

Re: [Wireshark-dev] QCustomPlot 2.0.0

2018-02-10 Thread Martin Mathieson via Wireshark-dev
rk out. Just a short >> request, if you add it, please check it Qt4.8 is still supported for it >> (requirement for 2.6) and if you add it, we should move it to a new >> directory. >> >> I’ll do the latter in a separate patch before I think. >> >> Regards >> Ro

[Wireshark-dev] QCustomPlot 2.0.0

2018-02-09 Thread Martin Mathieson via Wireshark-dev
Hi, This was released September last year, has anyone else played with it? Locally, I got all our uses of it compiling (but mostly not tested). The reason I tried it out was that for the LTE RLC Graph, I wanted to use the QCPAxisTickerFixed class, to force it to not subdivide the Sequence

[Wireshark-dev] Build issues with packet-ieee80211.c

2017-12-24 Thread Martin Mathieson via Wireshark-dev
Hi Richard, Please see https://code.wireshark.org/review/#/c/24977/ (merged), the error I saw was: packet-ieee80211.c:2326:27: error: ‘vht_max_mpdu_in_amsdu’ defined but not used [-Werror=unused-const-variable=] static const value_string vht_max_mpdu_in_amsdu[] = { Martin

Re: [Wireshark-dev] Windows 64-bit petri-dish build timing out?

2017-12-09 Thread Martin Mathieson via Wireshark-dev
Oops, should have just searched for 'error', was looking for something obvious near the bottom of the log. And rebased. Martin On Sat, Dec 9, 2017 at 2:44 PM, Jakub Zawadzki <darkjames...@darkjames.pl> wrote: > Hello Martin, > > W dniu 2017-12-09 14:52, Martin Mathieson vi

[Wireshark-dev] Windows 64-bit petri-dish build timing out?

2017-12-09 Thread Martin Mathieson via Wireshark-dev
There have been some failures recently, e.g. https://buildbot.wireshark.org/petri-dish/builders/Windows%20Petri%20Dish%20x64/builds/1123/steps/compile_1/logs/stdio That build took over 21 minutes, and near the start of the log you can see: in dir

[Wireshark-dev] Build broken (cfile-int.h missing)

2017-12-03 Thread Martin Mathieson via Wireshark-dev
I'm seeing this, I don't have cfile-int.h anywhere): [ 2%] Building C object ui/CMakeFiles/ui.dir/capture.c.o /home/martin/wireshark/ui/capture.c:25:23: fatal error: cfile-int.h: No such file or directory #include "cfile-int.h" ^ compilation terminated. Martin

Re: [Wireshark-dev] External processes in Snort dissector - code execution

2017-08-28 Thread Martin Mathieson via Wireshark-dev
Hi Peter, I had not really thought about someone doing this. I have at times had multiple versions of snort installed in the same VM and used the option to switch between them... Its not a solution really, but I had thought I ought to run the snort binary with -V and check that it got a