Displaying gaps or drops in private UDP sequence numbers

Question

I've seen several topics here that relate to this issue, but none of the solutions have worked for me so far, so hopefully someone can point out where I'm going wrong.

I have a capture with 4 separate UDP streams being received on 4 well known ports, 30300 - 30303.

The UDP packets have a private "sequence number" that increments monotonically for each port.

I've been able to write a dissector in Lua that highlights that sequence number, but want to go to the next step: highlighting or somehow calling out packets just after a packet drop has been detected, indicated by a break in the sequence.

Here's my attempt so far: http://pastebin.com/nL9TCPWq

I've seen discussions indicating a Tap may be more appropriate for this purpose, but haven't found any Lua examples as yet.

Accepted Answer

1

The code looks like it could work. So, what is your question?

BTW: why

port_seq[port_str] = { seq }

instead of

port_seq[port_str] = seq

??

Regards
Kurt

answered 12 Sep '13, 14:15

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

That was a mistake, probably an attempt to build a nested table initially, which wasn't necessary. I've corrected it as you've shown.

As to my question, through various trial and error, the script seems to just stop at this line, where I try to increment the last sequence number and store it in expected:

local expected = port_seq[port_str] + 1

I'm wondering if the value I extracted from the packet with buffer(8,8) as the sequence number is actually being interpreted as an integer.

(13 Sep '13, 15:35) Gordon Marler

as the sequence number is actually being interpreted as an integer.

good question. Impossible to answer without a sample capture file ;-) Can you please post one on google drive, dropbox or cloudshark?

(14 Sep '13, 04:20) Kurt Knochner ♦

That makes sense - here's a sample capture:

dropped-test.pcapng

(17 Sep '13, 04:26) Gordon Marler

The first 8 bytes are not a counter in any way, as the bytes are the same for every frame, and I can't see any other byte sequence that increments in a detectable/predictable way.

So, where exactly is that sequence number within the frame?

(17 Sep '13, 05:22) Kurt Knochner ♦

1

hold on. My mistake. I was looking at the beginning of the UDP payload, whereas in the code it says: at byte 8. O.K. then there is an increasing seq number. I'll have to check how that gets read by the lua code.

(17 Sep '13, 07:17) Kurt Knochner ♦

strange thing.

If you change the code to this:

                    warn("P#1")
                local expected = port_seq[port_str] + 1;
                warn("P#2")

and then run tshark like this:

tshark -nr input.pcap -Xlua_script:udprecv-info.lua

The output look like this:

  1 0.000000000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
P#1
  2 0.000275000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
P#1
  3 0.000277000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
P#1
  4 0.000278000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301

So, P#1 gets printed, but not P#2, as if code execution stops after (or with) the declaration of local expected. Currently I have no idea what's going wrong (maybe a bug), but if code execution really stops there, your code to analyze the sequence number will not be executed either!

If you remove the declaration of local expected, the output looks like this.

  1 0.000000000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
P#1
P#2
not sequential
  2 0.000275000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
P#1
P#2
not sequential

So, now P#2 gets printed and the rest of the code gets executed as well, although with wrong result, due to the missing variable.

Looks like a strange bug to me.

BTW: The seq is extracted correctly by the code.

(17 Sep '13, 07:38) Kurt Knochner ♦

O.K. the problem is the data type of seq. It gets extracted as type userdata (see: warn("Seq type: " .. type(seq)). Even if you make it a uint64, it's type is still userdata

local seq = buffer(8, 8):uint64()

Apparently there is no + operator defined for that data type and thus the code

local expected = port_seq[port_str] + 1

fails.

So, we need to find a way to make seq a number object. Unfortunately I have not found a way to do that yet. tonumber() does not work.

(17 Sep '13, 08:06) Kurt Knochner ♦

1

well, there seems to be a problem with unit64(). If I change the code to this

local seq = buffer(12, 4):uint()

it works well, as the data type of seq is then a number instead of userdata (with uint64())

HOWEVER: That's just 4 bytes of your sequence!!

Test:

tshark -nr input.pcap -Xlua_script:udprecv-info.lua

Output:

  1 0.000000000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
not sequential
  2 0.000275000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
it was equal
  3 0.000277000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
it was equal
  4 0.000278000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
it was equal
  5 0.000279000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
not sequential
  6 0.000281000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
it was equal
  7 0.000282000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301
it was equal
  8 0.000283000 10.126.45.147 -> 239.255.6.82 UDP 1066 0x0000 (0) Source port: 53486  Destination port: 30301

I don't know if this is a bug or if there are internal representation problems with 64 bit values in Lua !?! Please file a bug report at https://bugs.wireshark.org with a reference to this question and my 'findings'.

(17 Sep '13, 08:19) Kurt Knochner ♦

Excellent troubleshooting! Thanks for taking the time.

I've submitted Bug ID 9162

(17 Sep '13, 17:51) Gordon Marler

Thanks for submitting the bug.

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(18 Sep '13, 00:25) Kurt Knochner ♦

showing 5 of 10 show 5 more comments

Answer 2

Support for 64-bt integers in Lua has now been added in Wireshark 1.11.3, and should be in the latest nightly builds. It provides Int64/UInt64 objects with abilities to use math and comparison operators and such. See wiki.wireshark.org/LuaAPI/Int64 for details.