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

[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 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 (...)
>
> These changes are quite old. For udp I did it in Aug 2013
> (88eaebaedf2e19c493ea696f633463e4f2a9a757).
>
> some wireshark-dev threads:
>   - https://www.wireshark.org/lists/wireshark-dev/201307/msg00222.html
>   - thread continuation:
> https://www.wireshark.org/lists/wireshark-dev/201308/msg00035.html
>
> Nobody stopped me that time.
>
> > And I guess I missed the reasoning behind the restructuring, but what
> > is the purpose/benefit of this restructuring
>
> To sum up:
>
> Restructuring idea was to remove usage of int hf_foo, so you would need
> only to declare header_field_info hfi_foo (unfortunate, you still need
> to do it on top of file).
>
> Benefit is no more ints, so:
>   - proto_tree_ api checks if you passed header_field_info structure,
>   - You don't need to declare int hf_foo = -1; (bonus: binary size
> smaller 4 bytes per hf),
>   - no need for table lookup in proto_tree_add_*
>
> > and use of HAVE_HFI_SECTION_INIT?
>
> Idea was that HFI_INIT(proto_bar) would put all protocol hfi's into
> single binary section. This way wireshark could auto-register these
> fields
> without need of some indirect array (bonus: binary size smaller by
> sizeof(void *) per hfi).
>
>
> After 5 years simple grep shows that only 36 dissectors are using
> NEW_PROTO_TREE_API, so it seems that this API is not well known or not
> liked.
> If it makes problem I would suggest to drop it.
>
> Alexis suggested the same in 2015:
> https://www.wireshark.org/lists/wireshark-dev/201508/msg00087.html
>
>
> Jakub.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[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 (...)


These changes are quite old. For udp I did it in Aug 2013 
(88eaebaedf2e19c493ea696f633463e4f2a9a757).


some wireshark-dev threads:
 - https://www.wireshark.org/lists/wireshark-dev/201307/msg00222.html
 - thread continuation: 
https://www.wireshark.org/lists/wireshark-dev/201308/msg00035.html


Nobody stopped me that time.


And I guess I missed the reasoning behind the restructuring, but what
is the purpose/benefit of this restructuring


To sum up:

Restructuring idea was to remove usage of int hf_foo, so you would need 
only to declare header_field_info hfi_foo (unfortunate, you still need 
to do it on top of file).


Benefit is no more ints, so:
 - proto_tree_ api checks if you passed header_field_info structure,
 - You don't need to declare int hf_foo = -1; (bonus: binary size 
smaller 4 bytes per hf),

 - no need for table lookup in proto_tree_add_*


and use of HAVE_HFI_SECTION_INIT?


Idea was that HFI_INIT(proto_bar) would put all protocol hfi's into 
single binary section. This way wireshark could auto-register these 
fields
without need of some indirect array (bonus: binary size smaller by 
sizeof(void *) per hfi).



After 5 years simple grep shows that only 36 dissectors are using 
NEW_PROTO_TREE_API, so it seems that this API is not well known or not 
liked.

If it makes problem I would suggest to drop it.

Alexis suggested the same in 2015: 
https://www.wireshark.org/lists/wireshark-dev/201508/msg00087.html



Jakub.
___
Sent via:Wireshark-dev mailing list 
Archives: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] tools/check[hf|APIs|filtername].pl need updating?

[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 scripts 
no longer work as effectively as they once did, at least as far as I can tell.

For example, if you remove an hf entry from the packet-wol.c's hf_register_info 
array and run checkhf.pl on packet-wol.c, you get output like this:

$ tools/checkhf.pl epan/dissectors/packet-wol.c
ERROR: NO ARRAY: epan/dissectors/packet-wol.c: hf_wol_passwd

... but if you remove an entry from the packet-udp.c's header_field_info, such 
as _udp_srcport, then checkhf.pl won't detect it.  Later you end up with a 
dissector bug when running Wireshark of the form:

  10:44:53.343  Warn Dissector bug, protocol UDP, in packet 1: 
proto.c:3377: failed assertion "(guint)hfinfo->id < gpa_hfinfo.len" 
(Unregistered hf!)

While it's nice to get the warning, the bug would have been caught much earlier 
using the checkhf.pl tool had the code been structured like it used to be.  Do 
these tools need to be updated to detect problems that were easily caught 
previously?

And I guess I missed the reasoning behind the restructuring, but what is the 
purpose/benefit of this restructuring and use of HAVE_HFI_SECTION_INIT?

Thanks.
- Chris












CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Unhandled exception

[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 file or attempting to capture packets 
>from an interface, so merely starting the application wouldn’t >have caught it.
>
>- Chris

Ah it’s my proposed patch https://code.wireshark.org/review/#/c/29716/ that 
makes it assert during startup 
Didn’t think of that…
Regards
Anders

From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Anders Broman
Sent: Tuesday, September 18, 2018 9:42 AM
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

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 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of Maynard, Chris
Sent: den 18 september 2018 15:36
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

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, September 18, 2018 4:26 AM
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

https://code.wireshark.org/review/c/29715/

Cheers,
Pascal.

Le mar. 18 sept. 2018 à 10:22, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 

Re: [Wireshark-dev] Unhandled exception

[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 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Anders Broman
Sent: Tuesday, September 18, 2018 9:42 AM
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unhandled exception

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 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of Maynard, Chris
Sent: den 18 september 2018 15:36
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

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, September 18, 2018 4:26 AM
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

https://code.wireshark.org/review/c/29715/

Cheers,
Pascal.

Le mar. 18 sept. 2018 à 10:22, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unhandled exception
>
> 











CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are 

Re: [Wireshark-dev] Unhandled exception

[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 2018 15:36
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unhandled exception

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, September 18, 2018 4:26 AM
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

https://code.wireshark.org/review/c/29715/

Cheers,
Pascal.

Le mar. 18 sept. 2018 à 10:22, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unhandled exception
>
> 











CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 

Re: [Wireshark-dev] Unhandled exception

[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, September 18, 2018 4:26 AM
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unhandled exception

https://code.wireshark.org/review/c/29715/

Cheers,
Pascal.

Le mar. 18 sept. 2018 à 10:22, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unhandled exception
>
> 











CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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

[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 point in time I also needed to install these libraries:
sudo apt-get install libjs-openlayers

Regards
Anders


-Original Message-
From: Wireshark-dev  On Behalf Of Geoff Lee
Sent: den 18 september 2018 07:04
To: 'Developer support list for Wireshark' 
Subject: Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a 
Raspberry Pi model 3B (armv7 processor?)

Hi Jaap

First and foremost, absolutely agree this was far from a bad experience for me 
(I would say very good! - everything is working for me, and I learnt lots of 
new and interesting stuff!).  The only other time (many years ago) I needed to 
compile a package from source I "disappeared" for about two months before 
getting anywhere!  The build system and documentation for Wireshark are very 
impressive.  

As are you folk on the mailing list!  Very much aware I was (am) an 
**absolute** novice attempting something pretty complex - that's why I was so 
appreciative of the time you experienced folk have taken to help me get over my 
initial sticking points.

I also agree my suggestions are not really suited to the general documentation 
(really far too basic for anyone who has the faintest idea about compiling 
using cmake / ninja, and also quite specific to my hardware / system software 
combination).  Perhaps their incarnation on this mailing list  - or my 
"personal" tutorial to myself which I've put here [Compiling wireshark 2.6.4 
from source, for and on a Raspberry 
Pi](https://gist.github.com/Geoff99/fd7d1e68134cdca5742fa54821f79212) - might 
be helpful for some future novice who finds them via a search engine - or maybe 
not, that's OK, someday in the future I might need reminding about something 
myself :-)

Once again, many thanks for all the help (and for a really useful product!)

Geoff

PS I'm currently exploring how to create a deb package of Wireshark 2.6.4, 
given that I've used cmake / ninja to compile it rather than autotools, but 
I've got a lot more reading of source code, looking up how various things work, 
and learning in general to do before I'll need any help (if indeed I do).  
PPS Of course, I'll also take a peek at the current master version in the next 
day or so, to see what I can earn from there as well, since as you say 
autotools is being phased out.

-Original Message-
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Jaap Keuter
Sent: 18 September, 2018 3:05 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a 
Raspberry Pi model 3B (armv7 processor?)

HI,

Just a few responses on some items here. It seems that you got into building a 
(rather complicated) program for the first time. Please excuse us for not being 
in the business of teaching ‘first timers’ how this is done on the multitude of 
platforms this software is supposed to run on. That is just out of our scope. 
However, we do try to make the process as smooth as possible by preparing the 
build system in great detail.

  

The use of sudo apt-get build-dep wireshark is nice, as in it prepared the 
system for building *that version* of Wireshark. These build dependancies, 
although fairly stable, do change from time to time. It could be that the 
build-dep you’ve installed only partially matches the intended build target. 
Fortunately this didn’t cause a problem.

  

It’s good to see that you’ve found a multitude of instructions. The fact that 
you found one more up to date and/or more relevant to your issues, leads to two 
conclusions. 1. The documentation (the Wiki) should be maintained to be up to 
date. 2. Duplication of documentation needs to be reduced. All this is an 
ongoing effort.

The getting to know cmake (and ninja) could be considered ‘basic knowledge’ of 
a software developer. When I was first confronted with them I just took to the 
web (like you did), found some excellent material that answered my specific 
questions, then went on to use it tweaking Wireshark builds. BTW: the autotools 
are on their way out, being removed from the repository master branch.
As for your specifics on compiling on the Pi, again the multitude of platforms 
this software is supposed to run on, makes it impossible to have detailed 
documentation on all of them. Maybe a Wiki page with tips on specific 
platforms, where tips on building, setting up, different capture options, etc, 
would be useful.

The two Debian packages with the name ninja, is a Debian naming conflict 
resolution thing. So, this is specific to this distribution (and derivatives).

The mailing lists are a somewhat undervalued resource, in this day and age of 
web based 

Re: [Wireshark-dev] Unhandled exception

[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: [Wireshark-dev] Unhandled exception

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 (hf_of_interest[i].hf < 0) {
g_warning("hf %s not found, index %u", 
hf_of_interest[i].proto_name);
}
Regards
Anders


From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of Pascal Quantin
Sent: den 18 september 2018 10:23
To: Developer support list for Wireshark 
mailto:wireshark-dev@wireshark.org>>
Subject: Re: [Wireshark-dev] Unhandled exception

I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unhandled exception
>
> 
>
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This message is the property of International Game 
> Technology PLC and/or its subsidiaries and may contain proprietary, 
> confidential or trade secret information.  This message is intended solely 
> for the use of the addressee.  If you are not the intended recipient and have 
> received this message in error, please delete this message from your system. 
> Any unauthorized reading, distribution, copying, or other use of this message 
> or its attachments is strictly prohibited.
> ___
> Sent via:Wireshark-dev mailing list 
> mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: 

Re: [Wireshark-dev] Unhandled exception

[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 (hf_of_interest[i].hf < 0) {
g_warning("hf %s not found, index %u", 
hf_of_interest[i].proto_name);
}
Regards
Anders


From: Wireshark-dev  On Behalf Of Pascal 
Quantin
Sent: den 18 september 2018 10:23
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unhandled exception

I'm uploading a patch.

Pascal.

Le mar. 18 sept. 2018 à 10:20, Pascal Quantin 
mailto:pascal.quan...@gmail.com>> a écrit :
Hi Anders,

Le mar. 18 sept. 2018 à 10:19, Anders Broman 
mailto:anders.bro...@ericsson.com>> 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 should check if we can make Transum more robust to this kind of errors in 
the future.


* The following are the field ids for the protocol values used by TRANSUM.
Make sure they line up with ehf_of_interest order */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev 
mailto:wireshark-dev-boun...@wireshark.org>>
 On Behalf Of João Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
>
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
>
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>
> Thanks.
> - Chris
>
> -Original Message-
> From: Wireshark-dev 
> [mailto:wireshark-dev-boun...@wireshark.org]
>  On Behalf Of Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> mailto:wireshark-dev@wireshark.org>>
> Subject: Re: [Wireshark-dev] Unhandled exception
>
> 
>
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This message is the property of International Game 
> Technology PLC and/or its subsidiaries and may contain proprietary, 
> confidential or trade secret information.  This message is intended solely 
> for the use of the addressee.  If you are not the intended recipient and have 
> received this message in error, please delete this message from your system. 
> Any unauthorized reading, distribution, copying, or other use of this message 
> or its attachments is strictly prohibited.
> ___
> Sent via:Wireshark-dev mailing list 
> mailto:wireshark-dev@wireshark.org>>
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>   
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: 

Re: [Wireshark-dev] Unhandled exception

[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 :
>>
>>> 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 should check if we can make Transum more robust to this kind of errors
>> in the future.
>>
>>
>>
>>> * The following are the field ids for the protocol values used by
>>> TRANSUM.
>>> Make sure they line up with ehf_of_interest order */
>>> HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
>>> { -1, "ip.proto" },
>>> { -1, "ipv6.nxt" },
>>>
>>> { -1, "tcp.analysis.retransmission" },
>>> { -1, "tcp.analysis.keep_alive" },
>>> { -1, "tcp.flags.syn" },
>>> { -1, "tcp.flags.ack" },
>>> { -1, "tcp.flags.reset" },
>>> { -1, "tcp.flags.urg" },
>>> { -1, "tcp.seq" },
>>> { -1, "tcp.srcport" },
>>> { -1, "tcp.dstport" },
>>> { -1, "tcp.stream" },
>>> { -1, "tcp.len" },
>>>
>>> { -1, "udp.srcport" },
>>> { -1, "udp.dstport" },
>>> { -1, "udp.stream" },
>>> { -1, "udp.length" },
>>>
>>> { -1, "ssl.record.content_type" },
>>>
>>> { -1, "tds.type" },
>>> { -1, "tds.length" },
>>>
>>> { -1, "smb.mid" },
>>>
>>> { -1, "smb2.sesid" },
>>> { -1, "smb2.msg_id" },
>>> { -1, "smb2.cmd" },
>>>
>>> { -1, "dcerpc.ver" },
>>> { -1, "dcerpc.pkt_type" },
>>> { -1, "dcerpc.cn_call_id" },
>>> { -1, "dcerpc.cn_ctx_id" },
>>>
>>> { -1, "dns.id"},
>>> };
>>> Regards
>>> Anders
>>>
>>> -Original Message-
>>> From: Wireshark-dev  On Behalf Of
>>> João Valverde
>>> Sent: den 18 september 2018 10:10
>>> To: wireshark-dev@wireshark.org
>>> Subject: Re: [Wireshark-dev] Unhandled exception
>>>
>>>
>>>
>>> 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 divide-and-conquer/trial-and-error, I discovered that it was
>>> due to enabling the transum dissector, although I can't figure out why
>>> enabling the transum dissector causes this, and then only for master.
>>> Enabling it for 2.6.2 seems fine.
>>> >
>>> > Maybe someone could just confirm if they also experience this
>>> exception if they enable the transum dissector?  If confirmed, I will file
>>> a bug report.
>>>
>>> Confirmed on the latest master. Enabling transum crashes wireshark.
>>>
>>> > The exception, for reference:
>>> >
>>> > Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid <
>>> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>>> >
>>> > Thanks.
>>> > - Chris
>>> >
>>> > -Original Message-
>>> > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On
>>> Behalf Of Richard Sharpe
>>> > Sent: Monday, September 17, 2018 4:22 PM
>>> > To: Developer support list for Wireshark 
>>> > Subject: Re: [Wireshark-dev] Unhandled exception
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > CONFIDENTIALITY NOTICE: This message is the property of International
>>> Game Technology PLC and/or its subsidiaries and may contain proprietary,
>>> confidential or trade secret information.  This message is intended solely
>>> for the use of the addressee.  If you are not the intended recipient and
>>> have received this message in error, please delete this message from your
>>> system. Any unauthorized reading, distribution, copying, or other use of
>>> this message or its attachments is strictly prohibited.
>>> >
>>> ___
>>> > Sent via:Wireshark-dev mailing list 
>>> > Archives:https://www.wireshark.org/lists/wireshark-dev
>>> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>> >   mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>> >
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  

Re: [Wireshark-dev] Unhandled exception

[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 on Windows as the console is
>> not open...GRR
>>
>
> this seems to be the ssl.record.content_type field.
> We should check if we can make Transum more robust to this kind of errors
> in the future.
>
>
>
>> * The following are the field ids for the protocol values used by TRANSUM.
>> Make sure they line up with ehf_of_interest order */
>> HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
>> { -1, "ip.proto" },
>> { -1, "ipv6.nxt" },
>>
>> { -1, "tcp.analysis.retransmission" },
>> { -1, "tcp.analysis.keep_alive" },
>> { -1, "tcp.flags.syn" },
>> { -1, "tcp.flags.ack" },
>> { -1, "tcp.flags.reset" },
>> { -1, "tcp.flags.urg" },
>> { -1, "tcp.seq" },
>> { -1, "tcp.srcport" },
>> { -1, "tcp.dstport" },
>> { -1, "tcp.stream" },
>> { -1, "tcp.len" },
>>
>> { -1, "udp.srcport" },
>> { -1, "udp.dstport" },
>> { -1, "udp.stream" },
>> { -1, "udp.length" },
>>
>> { -1, "ssl.record.content_type" },
>>
>> { -1, "tds.type" },
>> { -1, "tds.length" },
>>
>> { -1, "smb.mid" },
>>
>> { -1, "smb2.sesid" },
>> { -1, "smb2.msg_id" },
>> { -1, "smb2.cmd" },
>>
>> { -1, "dcerpc.ver" },
>> { -1, "dcerpc.pkt_type" },
>> { -1, "dcerpc.cn_call_id" },
>> { -1, "dcerpc.cn_ctx_id" },
>>
>> { -1, "dns.id"},
>> };
>> Regards
>> Anders
>>
>> -Original Message-
>> From: Wireshark-dev  On Behalf Of
>> João Valverde
>> Sent: den 18 september 2018 10:10
>> To: wireshark-dev@wireshark.org
>> Subject: Re: [Wireshark-dev] Unhandled exception
>>
>>
>>
>> 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 divide-and-conquer/trial-and-error, I discovered that it was
>> due to enabling the transum dissector, although I can't figure out why
>> enabling the transum dissector causes this, and then only for master.
>> Enabling it for 2.6.2 seems fine.
>> >
>> > Maybe someone could just confirm if they also experience this exception
>> if they enable the transum dissector?  If confirmed, I will file a bug
>> report.
>>
>> Confirmed on the latest master. Enabling transum crashes wireshark.
>>
>> > The exception, for reference:
>> >
>> > Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid <
>> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
>> >
>> > Thanks.
>> > - Chris
>> >
>> > -Original Message-
>> > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On
>> Behalf Of Richard Sharpe
>> > Sent: Monday, September 17, 2018 4:22 PM
>> > To: Developer support list for Wireshark 
>> > Subject: Re: [Wireshark-dev] Unhandled exception
>> >
>> > 
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This message is the property of International
>> Game Technology PLC and/or its subsidiaries and may contain proprietary,
>> confidential or trade secret information.  This message is intended solely
>> for the use of the addressee.  If you are not the intended recipient and
>> have received this message in error, please delete this message from your
>> system. Any unauthorized reading, distribution, copying, or other use of
>> this message or its attachments is strictly prohibited.
>> >
>> ___
>> > Sent via:Wireshark-dev mailing list 
>> > Archives:https://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> >   mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>> >
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: 

Re: [Wireshark-dev] Unhandled exception

[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 should check if we can make Transum more robust to this kind of errors
in the future.



> * The following are the field ids for the protocol values used by TRANSUM.
> Make sure they line up with ehf_of_interest order */
> HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
> { -1, "ip.proto" },
> { -1, "ipv6.nxt" },
>
> { -1, "tcp.analysis.retransmission" },
> { -1, "tcp.analysis.keep_alive" },
> { -1, "tcp.flags.syn" },
> { -1, "tcp.flags.ack" },
> { -1, "tcp.flags.reset" },
> { -1, "tcp.flags.urg" },
> { -1, "tcp.seq" },
> { -1, "tcp.srcport" },
> { -1, "tcp.dstport" },
> { -1, "tcp.stream" },
> { -1, "tcp.len" },
>
> { -1, "udp.srcport" },
> { -1, "udp.dstport" },
> { -1, "udp.stream" },
> { -1, "udp.length" },
>
> { -1, "ssl.record.content_type" },
>
> { -1, "tds.type" },
> { -1, "tds.length" },
>
> { -1, "smb.mid" },
>
> { -1, "smb2.sesid" },
> { -1, "smb2.msg_id" },
> { -1, "smb2.cmd" },
>
> { -1, "dcerpc.ver" },
> { -1, "dcerpc.pkt_type" },
> { -1, "dcerpc.cn_call_id" },
> { -1, "dcerpc.cn_ctx_id" },
>
> { -1, "dns.id"},
> };
> Regards
> Anders
>
> -Original Message-
> From: Wireshark-dev  On Behalf Of
> João Valverde
> Sent: den 18 september 2018 10:10
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] Unhandled exception
>
>
>
> 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 divide-and-conquer/trial-and-error, I discovered that it was
> due to enabling the transum dissector, although I can't figure out why
> enabling the transum dissector causes this, and then only for master.
> Enabling it for 2.6.2 seems fine.
> >
> > Maybe someone could just confirm if they also experience this exception
> if they enable the transum dissector?  If confirmed, I will file a bug
> report.
>
> Confirmed on the latest master. Enabling transum crashes wireshark.
>
> > The exception, for reference:
> >
> > Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid <
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
> >
> > Thanks.
> > - Chris
> >
> > -Original Message-
> > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On
> Behalf Of Richard Sharpe
> > Sent: Monday, September 17, 2018 4:22 PM
> > To: Developer support list for Wireshark 
> > Subject: Re: [Wireshark-dev] Unhandled exception
> >
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > CONFIDENTIALITY NOTICE: This message is the property of International
> Game Technology PLC and/or its subsidiaries and may contain proprietary,
> confidential or trade secret information.  This message is intended solely
> for the use of the addressee.  If you are not the intended recipient and
> have received this message in error, please delete this message from your
> system. Any unauthorized reading, distribution, copying, or other use of
> this message or its attachments is strictly prohibited.
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >   mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> >
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Unhandled exception

[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 */
HF_OF_INTEREST_INFO hf_of_interest[HF_INTEREST_END_OF_LIST] = {
{ -1, "ip.proto" },
{ -1, "ipv6.nxt" },

{ -1, "tcp.analysis.retransmission" },
{ -1, "tcp.analysis.keep_alive" },
{ -1, "tcp.flags.syn" },
{ -1, "tcp.flags.ack" },
{ -1, "tcp.flags.reset" },
{ -1, "tcp.flags.urg" },
{ -1, "tcp.seq" },
{ -1, "tcp.srcport" },
{ -1, "tcp.dstport" },
{ -1, "tcp.stream" },
{ -1, "tcp.len" },

{ -1, "udp.srcport" },
{ -1, "udp.dstport" },
{ -1, "udp.stream" },
{ -1, "udp.length" },

{ -1, "ssl.record.content_type" },

{ -1, "tds.type" },
{ -1, "tds.length" },

{ -1, "smb.mid" },

{ -1, "smb2.sesid" },
{ -1, "smb2.msg_id" },
{ -1, "smb2.cmd" },

{ -1, "dcerpc.ver" },
{ -1, "dcerpc.pkt_type" },
{ -1, "dcerpc.cn_call_id" },
{ -1, "dcerpc.cn_ctx_id" },

{ -1, "dns.id"},
};
Regards
Anders

-Original Message-
From: Wireshark-dev  On Behalf Of João 
Valverde
Sent: den 18 september 2018 10:10
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Unhandled exception



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 divide-and-conquer/trial-and-error, I discovered that it was due to 
> enabling the transum dissector, although I can't figure out why enabling the 
> transum dissector causes this, and then only for master.  Enabling it for 
> 2.6.2 seems fine.
> 
> Maybe someone could just confirm if they also experience this exception if 
> they enable the transum dissector?  If confirmed, I will file a bug report.

Confirmed on the latest master. Enabling transum crashes wireshark.

> The exception, for reference:
> 
> Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < 
> gpa_hfinfo.len" (Unregistered hf!)", group=1, code=6)
> 
> Thanks.
> - Chris
> 
> -Original Message-
> From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
> Richard Sharpe
> Sent: Monday, September 17, 2018 4:22 PM
> To: Developer support list for Wireshark 
> Subject: Re: [Wireshark-dev] Unhandled exception
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This message is the property of International Game 
> Technology PLC and/or its subsidiaries and may contain proprietary, 
> confidential or trade secret information.  This message is intended solely 
> for the use of the addressee.  If you are not the intended recipient and have 
> received this message in error, please delete this message from your system. 
> Any unauthorized reading, distribution, copying, or other use of this message 
> or its attachments is strictly prohibited.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>   mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives: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] Unhandled exception

[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 divide-and-conquer/trial-and-error, I discovered that it was due to 
enabling the transum dissector, although I can't figure out why enabling the 
transum dissector causes this, and then only for master.  Enabling it for 2.6.2 
seems fine.

Maybe someone could just confirm if they also experience this exception if they 
enable the transum dissector?  If confirmed, I will file a bug report.


Confirmed on the latest master. Enabling transum crashes wireshark.


The exception, for reference:

Unhandled exception ("proto.c:6497: failed assertion "(guint)hfid < gpa_hfinfo.len" 
(Unregistered hf!)", group=1, code=6)

Thanks.
- Chris

-Original Message-
From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of 
Richard Sharpe
Sent: Monday, September 17, 2018 4:22 PM
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Unhandled exception













CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information.  This message is intended solely for 
the use of the addressee.  If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


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

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

[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 september 2018 02:22
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Windows dumpcap -i TCP@


Hi,



I am trying to connect to a remote PCAPNG stream from Windows using the TCP@ 
socket interface but the connection closes immediately after connecting.  The 
same dumpcap command on linux works just fine to the remote TCP socket.



No errors indicating any failure are printed from dumpcap.exe

C:\>"\Program Files\Wireshark\dumpcap.exe" -i 
TCP@192.168.1.100 -w -

Capturing on 'TCP@192.168.1.100'

dumcap:



C:\>



On the remote end running in linux I see a connect and disconnect with EPOLLHUP 
event.



Has anyone else tried or have remote TCP socket connections working with 
dumpcap in Windows?



James


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