Ask Your Question
0

What is a field type of label?

asked 2018-06-09 00:33:10 +0000

ahaywood gravatar image

When reading through the Display Filter Reference, most of the field types are pretty straight forward.

However, what is the Label field type?

More specifically I am looking at: https://www.wireshark.org/docs/dfref/...

In version 2.6.1 the only thing I see available related to the payload is: websocket.payload Payload Label

What does it mean here by Label?

I'd expect to see a type of sequence of bytes for the payload, but cannot find one for 2.6.1, only the one that indicates type Label.

Thanks.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-06-09 02:47:21 +0000

Guy Harris gravatar image

What does it mean here by Label?

It means that the field doesn't have a value, and just acts as a "label" for other data in the packet.

It should be used for "composite" data, such as structures and arrays, for example. However, it shouldn't be used for uninterpreted blobs of bytes in the packet, but people might use it instead of "Sequence of bytes", for example, because they don't want a large blob of bytes to display as a whole bunch of hex digits.

Wireshark should probably allow the developer to indicate whether a "Sequence of bytes" displays as the hex data or as, for example, the count of bytes, e.g.

Frobozz: DEADBEEFCAFEBABE

vs.

Frobozz: 16 bytes

and the cases where "Label" is used for uninterpreted blobs of bytes should be changed to work that way.

(For the benefit of Wireshark developers reading this, "Label" means FT_NONE and "Sequence of bytes" means FT_BYTES.)

edit flag offensive delete link more

Comments

Not in favour of that suggestion. It's all nice and clean when the packets are correct, when looking at errored packets (one of the important reasons to look at packet with Wireshark) I want to see that misaligned data right there and then.

Also, who wants to miss out on the DEADBEEFCAFEBABE? She's smoking.

Jaap gravatar imageJaap ( 2018-06-09 07:40:17 +0000 )edit

Not in favour of that suggestion.

The suggestion to allow the Wireshark core to do the work that some dissectors already do by hand of displaying a byte count for FT_BYTES fields rather than showing the first N bytes of the field in hex? (N = 16 in the master branch.)

There are about 303 calls to proto_tree_add_bytes_format() and proto_tree_add_bytes_format_value() in the epan/dissectors tree in the master branch; I don't know how many of them format the value as "N bytes", but, for what it's worth, there are about 426 instances of "%d byte" and "%u byte" that aren't on the same line as proto_item_append_text, col_add_fstr, col_append_fstr, and g_strdup_printf, so a number of them might be doing what is being suggested. Others might just be giving it a name such as "mumble nonce" - "N bytes" isn't useful if it's a fixed-length field.

It's all ...

(more)
Guy Harris gravatar imageGuy Harris ( 2018-06-09 18:46:37 +0000 )edit

In a nutshell, "Label type" has no value?

If that is the case, then I will accept this as the answer.

I do have a followup question though, which, if I need to I'll create a new question for (just let me know), but since we are on the topic.

If the Label type has no value, what field does have the unmasked websocket payload sequence of bytes (or equivalent)?

ahaywood gravatar imageahaywood ( 2018-06-11 19:15:59 +0000 )edit

I believe I found the answer as to where the data is.

It looks like the websocket dissector passes the unmasked payload to the data dissector, and it is exposed in field data.data

ahaywood gravatar imageahaywood ( 2018-06-11 20:44:28 +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

1 follower

Stats

Asked: 2018-06-09 00:33:10 +0000

Seen: 2,969 times

Last updated: Jun 09 '18