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

Identify sequence number errors in UDP captures

0

I have a 10 minute period of captures, during which we have seen out of sequence packets being delivered over a UDP channel in a log file. This is on a custom trading platform that does not subscribe to the exchanges retransmission service, so our retail platforms are fine but the custom one is being spanked 2-3 times per hour.

Is there a way I can quickly view where a sequence is broken or packets are missing?

I can see it increment but there are far too many captures to go through 1 by 1 every time there is an issue.

asked 22 Aug '13, 02:30

SJennings's gravatar image

SJennings
11112
accept rate: 0%

There are people much smarter than me who will weigh in here...but using the terms "sequence" and "UDP" together seems contradictory. By definition, UDP is connectionless. So in the context of your description, I fail to understand how one UDP packet can be seen as being related any other. Perhaps the application sees them as being related, but Wireshark doesn't know anything about your application - it only knows the UDP protocol as defined by the RFC, which is connectionless. I wouldn't expect Wireshark to be able to find any "sequence" of UDP packets.

(22 Aug '13, 06:31) smp

If the ip identifier for that stream goes up by one each time, then you could use that to detect sequence problems. It may be possible to add support for this to the ip or udp dissector..

(22 Aug '13, 07:06) MartinM

: If the ip identifier for that stream goes up by one each time

Perhaps the OP is talking about IP sequence, and I misinterpreted as UDP sequence. See, that's what I meant by "smarter people"...

(22 Aug '13, 07:17) smp

More likely, it's an upper-layer protocol sequence number that is being referred to here. What protocol atop UDP is this?

And maybe OP could be a little more clear as to what, "the custom one is being spanked 2-3 times per hour." means?

(22 Aug '13, 10:22) cmaynard ♦♦

2 Answers:

0

I have a 10 minute period of captures, during which we have seen out of sequence packets being delivered over a UDP channel in a log file.

As Chris Maynard and smp both noted, there is no such thing as a sequence number error in an arbitrary UDP channel (or even such a thing as a UDP channel!). There might be sequence errors in, for example, an RTP channel running over UDP, but, to recognize that, you need to dissect RTP.

The sequence errors are in whatever protocol you're running over UDP, so you'd need a dissector for whatever protocol that is.

answered 22 Aug '13, 14:57

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

0

during which we have seen out of sequence packets being delivered over a UDP channel in a log file. This is on a custom trading platform

O.K. so, you have a trading system that sends transactions via UDP and obviously depends on the order of the transactions.

UDP gives no guarantee at all about the receive order of the packets, unless you enabled additional 'measures' on the whole network to prevent packet reordering, however you would do that with your network equipment.

Is there a way I can quickly view where a sequence is broken

Well, as there is no sequence number in UDP and you did not mention the application protocol used, the short answer is: NO, as UDP itself cannot tell you anything about packet re-odering in the network.

HOWEVER: As you only need to know if the packets arrived in the same order they were sent, you can use the IP ID of the packets as an indicator for packet reordering. If the IP ID within a conversation (client IP, source port --> server IP, destination port) constantly increases (only positive deltas), there is no packet reordering (please think about the wrap around of the IP ID at 65535!). If there are negative deltas, there is packet reordering.

Example #1: no reordering

IP ID: 10478
IP ID: 10552   Delta: 74
IP ID: 10564   Detla: 12
IP ID: 10587   Delta: 23

Example #2: reordering took place (somewhere in the network)

IP ID: 10478
IP ID: 10552   Delta: 74
IP ID: 10587   Delta: 35
IP ID: 10564   Detla: -23  !!!

So, you need the sequence of IP IDs for all UDP conversations and you can do this with tshark and some scripting.

The following command will return all UDP conversations

tshark -nr input.pcap -q -z conv,udp

Take that output and extract the IP addresses and the ports for each conversation. Then, loop over all conversations (through a script) and run this command

tshark -nr input.pcap -R "ip.addr eq x.x.x.x and ip.addr eq y.y.y.y and udp.port eq aaaa and udp.port eq bbbb" -T fields -e frame.number -e IP.ID

Take that output and generate the delta of the IP IDs as shown above. As soon as you get a negative delta, you found packet reordering. Think about the IP ID wrap around at 65535!! as you will then get a negative delta, although there is no packet reordering?

or packets are missing?

With only one capture point and no sequence number whatsoever in the application protocol, there is no way to know if a UDP packet got lost or not! The IP ID does not help you, unless you know for sure, that the packets were sent with a constantly increasing IP ID (+1, +2, +4, etc.), which is very rarely the case!

Regards
Kurt

answered 26 Aug '13, 07:03

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

If the IP ID within a conversation (client IP, source port --> server IP, destination port) constantly increases (only positive deltas)

...AND if the operating system sending the packets assigns sequential numbers as IP IDs...

there is no packet reordering

(26 Aug '13, 10:39) Guy Harris ♦♦