This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

destport and payload

0

What is the commands that allows the extraction of port destination and payload of packet

asked 11 May '16, 12:50

Khadidja%20Khadidja's gravatar image

Khadidja Kha...
415611
accept rate: 0%


One Answer:

0

Have you tried to read the tshark documentation page?

In short, the field names can be used both to compose the display filter (-Y udp.dstport == 1234 in tshark parameters) and to indicate fields which should be displayed instead of the default dissection (-T fields -e udp.dstport -e udp.srcport). To find the field names, you can click at the line representing the field in the packet dissection pane, and you'll see the field name in the left bottom corner of the Wireshark window. Or, if you can only use tshark for some reason, have a look at the online display filter reference.

You'll have to elaborate on what exactly you mean by "payload".

answered 11 May '16, 13:07

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

thanks a lot for your response, it is helpful for me payload of packet I mean it the data itself that needs to transfer (usually the user's data).

(11 May '16, 13:32) Khadidja Kha...
1

by "payload of packet" I mean the data itself that need to be transported

This is exactly the wording I didn't want to see :-)

The transport (protocol) in most cases doesn't transport just a plain byte stream; a typical payload of a transport protocol is some application protocol, or is at least structured in some way, and Wireshark can dissect these payload types in most (well, at least many) cases. So a single "filterable field" like udp.payload doesn't exist as normally no one needs it. Therefore,

  • for application protocols which can be dissected (like RTP), you have to use the corresponding filterable field names to access individual fields of these protocols,

  • the part of a packet which cannot be dissected is sometimes accessible as a filterable field named data. This may be the case even for udp if neither the source or destination port, nor analysis of an associated control communication captured, nor any heuristic allows Wireshark (tshark) to determine which dissector to feed the payload to.

What you could do, but would probably find it useless, would be to disable dissection of all protocols, and then enable just ethernet,ip,tcp and udp. That way, Wireshark would be prohibited from dissecting the payload, and anything following the tcp or udp headers would be available as data (and, most likely, totally incomprehensible).

(11 May '16, 13:54) sindy

I am grateful to you for your explanation :) thank you but how I can disable dissection of all protocols, and enable just ethernet,ip,tcp and udp. :)

(11 May '16, 14:19) Khadidja Kha...