How do I track packet loss when I have the UDP protocol? asked 20 Sep '12, 11:02  souss edited 20 Sep '12, 13:54  Jim Aragon |
3 Answers:
Short answer: You don't. UDP does not have anything equivalent to TCP's sequence number / acknowledgement number mechanism to let you track packets and detect packet loss. If the higher-level protocol that's running on top of UDP (RTP, TFTP, etc.) has some sort of identification number or sequence number or block number that is unique per packet and that changes in a predictable way, then you could display that number in a custom column and manually look for missing numbers, but there is no way in the UDP protocol itself to identify missing packets. answered 20 Sep '12, 13:00 Jim Aragon There's an easier way; merge 2 packet captures together in Wireshark, if you looking for dropped UDP packets say between 2 routers for example. Go to Statistics>Compare, filter by ip.id then click create, if there are any missed ID packets between both files then the results indicate which ip.id packets were lost and then you know which router interface dropped which packet. (06 Feb '15, 07:03) mortirolo |
First, welcome to Wireshark. There may be a way if there's nothing in a higher protocol for you to use, but it's fairly implementation specific. When I was developing a new piece of network hardware, I noticed that Linux sends out all IP packets with an incrementing identification field in their header, so if you're capturing packets that have been sent out by Linux then you've got a chance. I'm not sure how the Windows or Unix Stacks handle the ident field and not every version of Linux uses the standard stack, so you'll need to check to see if this is happening first. Another down side to this is it's the protocol below UDP that's giving you this trackable sequence, which means that even if you suspect a packet has been dropped, there's no way to know whether it was UDP or another protocol. I should also mention that if the NIC is using a hardware TSO then the Ident field might not be entirely predictable even with Linux, (some TSO engines don't bother to update it as most network stacks ignore this field.). It's not a robust solution, but it may suit your needs. Cheers, Craig answered 20 Sep '12, 15:46  CTNOBLE edited 20 Sep '12, 15:48 The Identity field in the IP header does indeed increase monotonously. However, it does so for all connections. So yes, if the linux box is not sending out other IP traffic watching the ip.id field increase could be an indication of packet loss. But if you miss a particular value for the ip.id, you have no way of knowing whether there was UDP packet loss or if the linux host sent another IP packet, so this defeats the purpose of using this field for packet loss detection... (20 Sep '12, 16:17) SYN-bit ♦♦ Also, there are some stack implementations that do not increase the IP ID, but use a value of 0 unless fragmentation happens (OpenBSD, for security reasons). Furthermore, there are Firewalls that randomize the IP ID for the same purpose. (23 Sep '12, 04:18) Jasper ♦♦ |
Well, if the protocol running atop UDP is "predictable", with every request packet resulting in a fixed number of response packets (or vice versa), then you might be able to count the total number of requests and compare it to the total number of responses. If the values don't correlate, then you can reasonably conclude that some packet loss occurred. An example of this is TFTP, where for every data block transferred, there's an acknowledgement sent in reply. Using TFTP as an example then, if you utilize the Wireshark "Statistics -> Follow UDP" feature and then "Statistics -> Conversations -> UDP", selecting also "Limit to display filter", then you can easily see the number of packets transferred in each direction. They should be the same. While your protocol may not work exactly like TFTP, you may be able to use a similar technique. Additionally, in the packet details pane, if response packets were lost, you'd see fewer response packets in between requests than expected. If the protocol is "ping-pong", such as TFTP, with 1 response per request, then you'd see back-to-back requests, so that would be something to look for. But of course if request packets were lost and not captured by Wireshark, then you might not be able to directly tell if there was any packet loss since there would obviously be no response either, thus the packet counts would seem correct and might mislead you into thinking there's no loss. However, you might also be able to surmise possible packet loss if the packets are expected to flow at some more or less steady rate. For example, you could filter just the request packets then sort by "delta time displayed" (I suggest you add it as a column if you haven't already). If you notice larger gaps in time than usual, then that may be an indication of packet loss, since, if either the previous request or response packet were lost, the next request would likely be sent after some longer period of time after a response timeout had occurred. None of this is guaranteed though and your results will depend greatly on the dynamics of how your UDP-based protocol actually behaves. Still, if you have nothing else to go by, this might help. As Jim mentioned though, whenever possible, it's far better to use the information from the payload to help determine packet loss. If you don't have a Wireshark dissector written for this UDP-based protocol, then probably the best solution would be to write one. :) answered 21 Sep '12, 07:30  cmaynard ♦♦ |
Hello Jim, When you said : then you could display that number in a custom column and manually look for missing numbers. Can you explain to me how can I do or where in Wireshark ? Thanks for all the answers !
First, there must be a dissector for the higher-level protocol so that Wireshark puts the unique number into its own field. If so, in the Packet Details pane, right-click on the field you want to use and select "Apply as Column."
Which is unfortunate. It would be nice if [t|Wire]shark supported being able to display the hex bytes from a display filter expression such as "frame[n:m]". If it did, then you wouldn't necessarily need to have a higher-level protocol with a registered field.
Well, in the absence of a higher-level protocol and the above feature, it may also be possible to achieve this with Lua, although I have no experience with it so I can't offer much help there.