Identify sequence number errors in UDP captures

Question

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.

Answer 1

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.

Answer 2

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