Revision history [back]

Does a UDP connection contain data?

UDP is what's called a connectionless protocol, meaning that UDP doesn't start up by establishing a connection between two hosts and ports, and each packet between a given host/port pair and another given host/port pair is, at the UDP layer, independent of all other packets. There's no sequence number to indicate which packets come before which other packets; there is no guarantee that packets will arrive on the receiver in the order in which they were sent. There is also no mechanism at the UDP layer for the receiver or sender to discover that a packet didn't make it from the sender to the receiver and thus no mechanism at the UDP layer for the sender to retransmit packets that didn't make it to the receiver.

However, you can think of a "conversation" between two host/port pairs. (I think the term "flow" is used for packets from one host/port pair to another, but I'm not sure there's a term to cover the two flows in both directions.)

Some protocols running on top of UDP provide their own mechanisms to maintain enough state that they can handle packets that arrive out of order, and so that they can arrange that packets lost in transit can be retransmitted. One such protocol is QUIC, and HTTP can run over QUIC rather than over TCP.

And, yes, each UDP packet contains data, so each flow contains data.

Is it possible to view this data on WS?

"Follow UDP stream" shows both flows. However, that doesn't dissect the data in detail; that can happen only if Wireshark 1) supports the protocol(s) running on top of UDP and 2) can recognize the traffic as being one of those protocols. Sometimes that works, sometimes it doesn't, either because 1) Wireshark doesn't support the protocol or 2) can't recognize it as that traffic without help from the user.

It is actually a UDP connection made by Brave browser to a Google IP during the browser startup.

Perhaps it's QUIC traffic. Brave is based on Chromium, and Chromium supports QUIC.

Is the result I've uploaded in the image above is the UDP data?

No. Showing the data as YAML turns it into YAML text of the form

# Packet 1
peer0_0: !!binary |
  {binary data encoded in base64}
# Packet 2
peer1_0: !!binary |
  {binary data encoded in base64}

and the only part that's the data is the binary data encoded in base64. The comment indicates which packet is being described, and the "peerN_M" just indicates 1) which direction the packet traveled in and 2) which packet it was going in that direction - N is 0 for "client -> server" ("client" and "server" are the code's best guess as to which host is the client and which host is the server), and M is a packet count in that direction.

The converter appears not to have bothered doing anything with the binary data, so you're not seeing the data.

Again, this might be QUIC. Wireshark tries to recognize QUIC traffic. If it fails, then you could try using Analyze > Decode As... to specify that the UDP port in question be decoded as GQUIC (the Google version) or QUIC (the IETF version).