Access lower layer protocol information from dissector

retag add tags

Hi,

I'm sure it's a question that has been asked many times, but I could not find it... In the C dissector I'm writing on top of UDP (triggered by udp.port), I need to access the 'total length' field from the UDP header. I need this because captured packet length is not enough as there can be Ethernet padding.

But when the dissector gets called, I can only access payload, not header from lower layer protocol. I guess I'll have to mess around with packet_info or proto_tree but I did not figure it out.

Thanks in advance!

Comments

If there's Ethernet padding you won't find that in the length field of the UDP header either.

Jaap (2018-06-14 10:56:01 +0000) edit

Well, actually I need to read the UDP header to be able to know what part is actually padding...

Florian Haradji (2018-06-14 13:37:54 +0000) edit

add a comment see more comments

The UDP dissector calls sub-dissectors with the length of the UDP payload. From packet-udp.c:

decode_udp_ports(tvb, offset, pinfo, tree, udph->uh_sport, udph->uh_dport, udph->uh_ulen);

Whether there's Ethernet padding present or not, your dissector won't know about it. In fact, your dissector won't even know if the UDP datagram was transmitted over Ethernet or some other link layer protocol.

11.1k

cmaynard

answered 2018-06-14 14:21:08 +0000

edit flag offensive 0 remove flag delete link

Comments

cool, so how do I get this? dissector prototype is (tvbuff_t, packet_info, proto_tree, void*). I guess I'll have to cast the void* into something else...but what?

Florian Haradji (2018-06-14 14:27:17 +0000) edit

ôk looking at the code it seems it is just the reported length of the tvbuff...

Florian Haradji (2018-06-14 15:04:12 +0000) edit

You get the length from the tvb, in most cases using tvb_reported_length().

Maybe have another read through README.dissector, README.developer and friends?

cmaynard (2018-06-14 15:06:15 +0000) edit

I did, but it is not exactly crystal clear what "reported length" actually means...anyway like most of the time you find the answer looking at the code :) Thanks a lot for your help

Florian Haradji (2018-06-14 15:08:20 +0000) edit

Well, there's reported length and captured length. The reported length is how much data should be in the buffer; the captured length is how much data is actually in the buffer. These values may be different due to such things as malformed packets or sliced packets (a snaplen was specified during capturing). In most cases, you want to use the reported length so Wireshark can tell you the packet was truncated or if it's malformed.

cmaynard (2018-06-14 15:37:51 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Access lower layer protocol information from dissector edit

Comments

1 Answer

Comments