Ask Your Question
0

Setting a field optional when registering the header? (possible?)

asked 2018-11-21 19:59:37 +0000

anonymous user

Anonymous

updated 2018-11-21 20:00:56 +0000

I am a complete newbie when it comes to Wireshark and know just some basics of networking. This is my first time trying to make a dissector and I am using C++ to make the dissector. I have a protocol that has a large number of messages with unique element which tells me what kind of message it is, in the header. But, there are two formats for the header in the spec, one has 4 values while the other has 3. The 3 values are common between them. Is there any way I can set the header value to be optional? (and if I do set it optional, how would wireshark know is it is present or not?) If there is no way to do that, what would be a good way of making a dissector that meets the aforementioned requirements?

edit retag flag offensive close merge delete

Comments

Is there a field in the header that indicates which format for the header is being used?

Guy Harris gravatar imageGuy Harris ( 2018-11-21 20:50:55 +0000 )edit

Hi Harris, I have a field which says which type of message I have and from the message I know what it's header looks like!

do_more gravatar imagedo_more ( 2018-11-26 00:05:02 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-11-21 20:54:51 +0000

grahamb gravatar image

A first observation is that using C++ for a dissector isn't supported, but, depending on what C++ constructs you use, you might get it to work. The normal target for dissectors is C99.

Many dissectors handle field presence. In general, you register all the fields, but you only add data to it (.e. with proto_tree_add_item) if the field is present in the packet.

If your protocol provides sufficient info in the packet to determine which header is in use (maybe a key value, or message length or something else distinctive), then you can simply program that in your dissector. If it doesn't, then you'll require user support with a preference to indicate which header type is in use.

edit flag offensive delete link more

Comments

Thank you so much Graham for the answer. Although I have a question on the proto_tree_add_item thing. I have to register my header before I dissect yeah? So if I have different headers, can I only register the part of my header that is going to be that same and then dissect the other part according to the message using the proto_tree_add_item? Or do I register the whole header and then use proto_tree_add_item on the fields that I need to dissect?

do_more gravatar imagedo_more ( 2018-11-26 00:07:59 +0000 )edit

Field registration is (normally) done before dissection, so register all fields, then dissect and add items as required.

grahamb gravatar imagegrahamb ( 2018-11-26 18:41:22 +0000 )edit

I'm not quite sure I follow your question so this response may not be relevant but here it is anyway: keep in mind you're not registering an entire packet header (with the hf fields). You're registering individual fields. A given protocol header will (typically) consist of several (if not many) fields. For example a version field, a length field, etc.

Then you write C code which dissects these fields. Step 1 might be to dissect the version field. Once you know that you might call 2 different functions depending on the version. The v3 dissection function might dissect fields A, B, and C. The v4 dissection function might dissect fields A, X, Y, and Z (yes, a given field might be the same in both versions). What hf's you register must simply include all fields for all versions of the protocol.

JeffMorriss gravatar imageJeffMorriss ( 2018-11-26 18:43:11 +0000 )edit

Okay. So, from what I understand-

  1. Register all fields in the header for all the types of header.
  2. Dissect only the fields which I need until I get what type of packet I am dissecting.
  3. Then dissect the packet accordingly.

Is that correct?

Also, another question from the Wireshark Developer Guide, the proto_tree_add_item, is it used to display the details on the screen yes?

do_more gravatar imagedo_more ( 2018-11-27 05:23:42 +0000 )edit

The order you noted is correct, apart from the field registration should include all fields that might possibly be dissected.

Pedantic note, dissectors don't "display on the screen", they add items to the proto tree and\or columns that then allows whatever UI is being used, Qt, cli etc. to render the items accordingly. So yes, use proto_tree_add_item() to add protocol elements to the tree so that they can be displayed on screen.

grahamb gravatar imagegrahamb ( 2018-11-27 11:13:16 +0000 )edit

Your Answer

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

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-11-21 19:59:37 +0000

Seen: 396 times

Last updated: Nov 21 '18