Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread João Valverde
On 18/09/18 01:07, Maynard, Chris wrote: Thanks for the tips Richard, but after some additional testing and some head-scratching, I discovered the source of the problem was something in my profile, because if I switched to a pristine profile, then master ran fine. Through

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Anders Broman
Hi, I think that the problem is that one of these fields has changed name, but debugging the registration phase is hard on Windows as the console is not open...GRR * The following are the field ids for the protocol values used by TRANSUM. Make sure they line up with ehf_of_interest order */

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Anders Broman
Hi, Thinking about it a bit more should proto_registrar_get_id_byname() assert on a non valid name? This may be the simplest safe guard. Regards Anders From: Wireshark-dev On Behalf Of Anders Broman Sent: den 18 september 2018 10:29 To: Developer support list for Wireshark Subject: Re:

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Pascal Quantin
Hi Anders, Le mar. 18 sept. 2018 à 10:19, Anders Broman a écrit : > Hi, > I think that the problem is that one of these fields has changed name, but > debugging the registration phase is hard on Windows as the console is not > open...GRR > this seems to be the ssl.record.content_type field. We

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Pascal Quantin
https://code.wireshark.org/review/c/29715/ Cheers, Pascal. Le mar. 18 sept. 2018 à 10:22, Pascal Quantin a écrit : > I'm uploading a patch. > > Pascal. > > Le mar. 18 sept. 2018 à 10:20, Pascal Quantin > a écrit : > >> Hi Anders, >> >> Le mar. 18 sept. 2018 à 10:19, Anders Broman >> a écrit

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Pascal Quantin
I'm uploading a patch. Pascal. Le mar. 18 sept. 2018 à 10:20, Pascal Quantin a écrit : > Hi Anders, > > Le mar. 18 sept. 2018 à 10:19, Anders Broman > a écrit : > >> Hi, >> I think that the problem is that one of these fields has changed name, >> but debugging the registration phase is hard

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Anders Broman
Hi, Perhaps filter names referenced in other dissectors should be a define in a common .h file to make it obvious that the name must be changed in more than one place. Solving part of the problem. Then TRANSNUM should check for -1 I suppose and perhaps my trouble shooting patch: if

Re: [Wireshark-dev] Windows dumpcap -i TCP@

2018-09-18 Thread Anders Broman
What version of Wireshark and what Linux version on the remote side? I think some work has ben done on rpcap recently so trying out the development version is an option. https://www.wireshark.org/download/automated/win64/ Regards Anders From: Wireshark-dev On Behalf Of James Ko Sent: den 18

Re: [Wireshark-dev] tools/check[hf|APIs|filtername].pl need updating?

2018-09-18 Thread Jakub Zawadzki
Hi, W dniu 2018-09-18 16:56, Maynard, Chris napisał(a): While investigating the transum-related crash, I had suspected some unregistered hf's and ran the various tools like checkhf.pl. I then noticed that a number of dissectors seemed to have changed a bit from what I was used to before (...)

Re: [Wireshark-dev] tools/check[hf|APIs|filtername].pl need updating?

2018-09-18 Thread Alexis La Goutte
Thanks Jakub for historic I think a good idea is revert to use "standard" API or write a tools for convert old dissector to new API... Cheers On Tue, Sep 18, 2018 at 6:05 PM Jakub Zawadzki wrote: > Hi, > > W dniu 2018-09-18 16:56, Maynard, Chris napisał(a): > > While investigating the

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Anders Broman
From: Wireshark-dev On Behalf Of Maynard, Chris Sent: den 18 september 2018 15:55 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Unhandled exception >This particular crash with transum didn’t occur just by launching Wireshark >though, but only when reading a capture

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Anders Broman
Hi, At the very least we should have a test step activating all protocols and starting the application. As they are disabled by default perhaps fussing is overkill, they might prolong fussing time unduly? Regards Anders From: Wireshark-dev On Behalf Of Maynard, Chris Sent: den 18 september

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Maynard, Chris
This particular crash with transum didn’t occur just by launching Wireshark though, but only when reading a capture file or attempting to capture packets from an interface, so merely starting the application wouldn’t have caught it. - Chris From: Wireshark-dev

Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)

2018-09-18 Thread Anders Broman
> I'm currently exploring how to create a deb package of Wireshark 2.6.4 From my notes: For Ubuntu 16.04, Ubuntu 18.04 in tree build must be done if building .deb dpkg-buildpackage -rfakeroot -j6 -us -uc (Add parameter -nc to not apply patches? export DPKG_GENSYMBOLS_CHECK_LEVEL=0 ) At some

Re: [Wireshark-dev] Unhandled exception

2018-09-18 Thread Maynard, Chris
Thanks. Should the fuzz tester(s) enable all dissectors by default? If I “enable all protocols”, then currently the enabled_protos file lists these 3: prp, stcsig and transum. - Chris From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin Sent: Tuesday,

[Wireshark-dev] tools/check[hf|APIs|filtername].pl need updating?

2018-09-18 Thread Maynard, Chris
While investigating the transum-related crash, I had suspected some unregistered hf's and ran the various tools like checkhf.pl. I then noticed that a number of dissectors seemed to have changed a bit from what I was used to before, which lead me to the realization that at least some of these