Ask Your Question

I have problem when update plugins for latest version of Wireshark

asked 2021-05-14 06:19:08 +0000

123 gravatar image

updated 2021-05-14 07:19:06 +0000

I am trying to update a plugins that worked well for Wireshark version 1.6.0, I want this plugins to work for also the latest version of Wireshark. I have done some modified, changes, but it still does not really work.

Wireshark seems can not load my plugins, it appears with the error:

Dissector bug C:\Development...\proto.c:8709 failed assertion "DISSECTION_ASSERT_NOT_REACHED"

What this error means? Does it mean there is some error in the plugins code?

edit retag flag offensive close merge delete


It means that some internal test in Wireshark failed; the test may be a test to make sure a plugin is not doing something incorrectly, so it might be a problem with your plugin.

We'd need to know what version of Wireshark you tried this with, because the error message isn't as helpful as it could be - it just says that the code shouldn't reach line 8790 of the file proto.c (epan/proto.c in the Wireshark source), but there isn't such an assertion test on line 8790 of that file in the latest release of Wireshark, which is Wireshark 3.4.5.

Guy Harris gravatar imageGuy Harris ( 2021-05-14 07:04:56 +0000 )edit

The Wireshark that I tried is version 3.4.5. So does it mean that it does some warning about problem in my plugins code, but did not show me what is the problem?

EDIT: I have been type incorrectly, the problem is c:8709, not 8790.

123 gravatar image123 ( 2021-05-14 07:27:32 +0000 )edit

I would say that Wireshark 1.6 and 3.4 are almost completely different animals. So I would be surprised if it had worked.

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2021-05-14 07:53:32 +0000 )edit

If you read the indicated row in proto.c it will give a clue to what the problem is.

Anders gravatar imageAnders ( 2021-05-14 13:16:56 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-05-14 19:16:07 +0000

Guy Harris gravatar image

The test on line 8709 is part of a loop that checks whether the "abbreviation" for a named field contains only:

  • ASCII alphabetic characters (A-Z, a-z);
  • digits (0-9);
  • ASCII dash (hyphen);
  • period (.);
  • underscore (_).

It also requires that the period not be at the beginning or the end of the abbreviation, that there are not two periods in a row.

So you must update your dissector so that if, in the abbreviations of the fields that it registers, it's using any characters other than the ones listed there, or if it puts a period at the beginning or end of the abbreviation, or if it has two or more periods in a row, it no longer does so.

The descriptive name of the field, which is what's used in the packet details display, is not restricted in that fashion. The abbreviation, which is what's used in packet-matching expressions ("display filters"), and when telling Wireshark or TShark to use certain fields when drawing graphs or when printing particular field values, is restricted in that fashion. So a dissector can, for example, have a field registered as

{ &hf_ip_hdr_len,
  { "Header Length", "ip.hdr_len", FT_UINT8, BASE_DEC,
    NULL, 0x0, "Header length in 32-bit words", HFILL }},

with a space in the description a space in the "blurb" ("Header length in 32-bit words"), but you can't have a field registered as

{ &hf_ip_hdr_len,
  { "Header Length", "ip hdr len", FT_UINT8, BASE_DEC,
    NULL, 0x0, "Header length in 32-bit words", HFILL }},

with spaces in the abbreviation.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2021-05-14 06:19:08 +0000

Seen: 40 times

Last updated: May 14