Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] dissector_add(tcp.proto... / where to find parameter for dis

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 23 Apr 2009 11:00:36 -0700

On Apr 23, 2009, at 3:41 AM, Eddie.1@xxxxxx wrote:

I want to dissect all TCP and UDP-Protocols (actually I only want to dissect Protocols with a special data length, but tvb_length(tvb) doesn't work before initializing.)

tvb_length() doesn't return the data length of a packet; it returns the amount of *captured* data in the tvbuff. You would want tvb_reported_length(), so it gives the right answer even for captures where the full packet data isn't necessarily captured, due to a snapshot length having been specified.

What you should do is have a *heuristic* dissector, which you would register with

	heur_dissector_add("udp", dissect_red, proto_red);

dissect_red() would return a gboolean - FALSE if the packet isn't a packet for your protocol, TRUE if it is. It would probably look like

	static gboolean
	dissect_red(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
	{
		if (tvb_reported_length(tvb) != CORRECT_DATA_LENGTH)
			return FALSE;

		dissect the packet;

		return TRUE;
	}

although I would strongly suggest that, if there's anything else in the packet to check whether it's a packet for your protocol or not (a message type field, for example) that you

1) check, using tvb_bytes_exist(), whether the data for that field is available in the tvbuff - if not, reject the packet;

2) if the data for that field is available, fetch it and check it, and if it doesn't look right for your protocol, reject the packet;

before dissecting the packet - the stronger the heuristics for a dissector, the better, as there will be fewer false positives (packets *not* for your protocol that your dissector accepts and dissects as packets for your protocol, possibly preventing it from being dissected for the right protocol).

For TCP, it's more complicated, as TCP is a byte-stream protocol, with no notion of packet boundaries for packets for the protocol being carried above it. What the dissector for a protocol running atop TCP gets handed is the contents of a TCP segment, which doesn't necessarily correspond to a packet. Presumably the protocols you're dissecting on top of TCP have some mechanism, such as a packet length field, to delimit packets in the byte stream. For those, you would probably want to check the length field in your heuristic dissector, if possible.