7.2. Following Protocol Streams (2024)

It can be very helpful to see a protocol in the way that the applicationlayer sees it. Perhaps you are looking for passwords in a Telnet stream,or you are trying to make sense of a data stream. Maybe you just need adisplay filter to show only the packets in a TLS or SSL stream. If so,Wireshark’s ability to follow protocol streams will be useful to you.

To filter to a particular stream,select a packet in the packet list of the stream/connection you areinterested in and then select the menu item you want under Analyze → Follow(or in the context menu in the packet list). Wireshark will set anappropriate display filter and display a dialog box with the data from thestream laid out, as shown in Figure7.1, “The “Follow TCP Stream” dialog box”.

	Tip
	Following a protocol stream applies a display filter which selects allthe packets in the current stream. Some people open the “Follow TCPStream” dialog and immediately close it as a quick way to isolate aparticular stream. Closing the dialog with the “Back” button will resetthe display filter if this behavior is not desired.

Wireshark supports following the streams of many different protocols, includingTCP, UDP, DCCP, TLS, HTTP, HTTP/2, QUIC, WebSocket, SIP, and USB CDC.The dialog for following TCP streams is covered in detail here;most other supported protocols will show dialogs which are very similar.

	Note
	If the type of stream you wish to follow is disabled or missing from the menu,Wireshark did not find the respective protocol in the currently selected packet.

	Tip
	To follow TLS or SSL streams, see the wiki page onTLS for instructionson providing TLS keys.

The stream content is displayed in the same sequence as it appeared on thenetwork. Non-printable characters are replaced by dots.Traffic from the client to the server is colored red, while trafficfrom the server to the client iscolored blue. These colors can be changed by opening Edit → Preferences andunder Appearance → Font and Colors, selecting different colors for theSample "Follow Stream" client text and Sample "Follow Stream" server textoptions.

The stream content won’t be updated while doing a live capture. To get thelatest content you’ll have to reopen the dialog.

You can choose from the following actions:

By default, Wireshark displays both client and server data. You can select theEntire conversation to switch between both, client to server, orserver to client data.

You can choose to view the data in one of the following formats:

The YAML output is divided into 2 main sections:

peers: - peer: 0 host: 127.0.0.1 port: 54048 - peer: 1 host: 127.0.10.1 port: 5000packets: - packet: 1 peer: 0 index: 0 timestamp: 1599485409.693955274 data: !!binary | aGVsbG8K - packet: 3 peer: 1 index: 0 timestamp: 1599485423.885866692 data: !!binary | Ym9uam91cgo=

The same example but in old YAML format (before version 3.5):

# Packet 1peer0_0: !!binary | aGVsbG8K# Packet 3peer1_0: !!binary | Ym9uam91cgo=

How the old format data can be found in the new format:

...packets: - packet: AAA peer: BBB index: CCC data: !!binary | DDD

# Packet AAApeerBBB_CCC !!binary | DDD

AAA: packet number in the original captureBBB: peer indexCCC: packet index for this peerDDD: data in base64 encoding

You can optionally show the delta time each time the direction changes (turns) or for every packet or event.

You can switch between streams using the “Stream” selector.

You can search for text by entering it in the “Find” entry box andpressing Find Next.

The HTTP/2 Stream dialog is similar to the "Follow TCP Stream" dialog, exceptfor an additional "Substream" dialog field. HTTP/2 Streams are identified bya HTTP/2 Stream Index (field name http2.streamid) which are unique within aTCP connection. The “Stream” selector determines the TCP connection whereas the“Substream” selector is used to pick the HTTP/2 Stream ID.

The QUIC protocol is similar, the first number selects the QUIC connection numberwhile the "Substream" field selects the QUIC Stream ID.

The SIP call is shown with same dialog, just filter is based on sip.Call-IDfield. Count of streams is fixed to 0 and the field is disabled.