Ask Your Question
0

Is my methods to view data in this UDP Protocol correct?

asked 2021-03-27 04:46:54 +0000

ShimizuH gravatar image

updated 2021-03-27 05:07:03 +0000

Hi, A newbie question here. Does a UDP connection contain data? Is it possible to view this data on WS?

I did the following. It is actually a UDP connection made by Brave browser to a Google IP during the browser startup. But, I wonder if my techniques are correct.

  1. I right-clicked on one of the UDP connections > Follow > UDP stream > Get a new window with lots of random characters. Like .Q050......R....E4y.%[sK

  2. At the bottom of the window, I select show and save data as > YAML. Save as > wireshark.yml.

  3. From my browser, I browsed to https://localise.biz/free/converter/yml. Choose file > wireshark.yml. Convert to HTML.

  4. Finally I get an HTML file that shows something like this, in a table. image description

Is the result I've uploaded in the image above is the UDP data? Or are my methods above wrong?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2021-03-27 06:36:51 +0000

Guy Harris gravatar image

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 ... (more)

edit flag offensive delete link more

Comments

Here's what I did. I clicked view > name resolution > resolve physical address, resolve network address, resolve transport address. That will display which connections connect to Google.

Analyze > Decode As... to specify that the UDP port in question be decoded as GQUIC (the Google version)

I did what you told me above and then get this screenshot. Some of the packets are malformed packets. image description

I sort the packets and ignored all malformed packets. image description

I clicked on one of the packets that says DATA PKN 683 (the second last from the above SS). And get this: image description

What data was there in the above screenshot? Was there data to begin with?

I decoded the same packet into QUIC and get this SS.

image description

What data was there in the above screenshot?

I know some of my questions above could be silly, but I'm still learning.

ShimizuH gravatar imageShimizuH ( 2021-03-28 03:11:39 +0000 )edit

What do you mean by "data"?

It's all data in some sense. In an Ethernet packet, everything after the Ethernet header is "data" from the point of view of Ethernet, but if it's an IPv4 packet, the "data" in the Ethernet packet begins with an IPv4 header, and after that header, everything after that is "data" from the point of view of IPv4. But if that's a UDP packet, the "data" in the IPv4 packet begins with a UDP header and, after that header, everything after that is "data" from the point of view of UDP.

From the point of view of QUIC, the stuff that's labeled as "Stream Data" and the stuff that's labeled as "Remaining Payload" is "data".

Guy Harris gravatar imageGuy Harris ( 2021-03-28 08:58:53 +0000 )edit

Thanks a lot.

ShimizuH gravatar imageShimizuH ( 2021-03-28 10:03:10 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-03-27 04:46:54 +0000

Seen: 212 times

Last updated: Mar 27