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

Capture from NetMon shows commas with sequence numbers

Hi There:

I have a capture that was done using NetMon.

Some of the streams seem disjointed, there are FIN, SYN, RST, PSH ECN flags set.

Also what is weird is that the sequence number has comma's in them, like 1082,0

No idea what to do with this.

Thank you

paul

streaming netmon

asked 16 Oct '17, 14:27

Pauli
0●4●4●5
accept rate: 0%

We'd need to see the capture file (preferably not a screenshot or a printout of it, but the file itself) to look at it and determine what's happening.

(16 Oct '17, 15:53) Guy Harris ♦♦

link text

(17 Oct '17, 06:09) Pauli

Hi Guy:

Thanks for the reply, I added a screen shot in the previous comment.

The trouble packet is 364.

The packet is a response from the server (which is actually and MFP).

The communication is from packet 348 to 367, which is communication over port 50003.

What is weird is that packet 364 shows a completely different port number. We know this is the correct packet stream because we see it on the other side.

Thanks for any help you can provide.

Pauli

(17 Oct '17, 06:14) Pauli

Please show the detailed dissection of frame 364. Without that, we can't determine 1) why there are two sequence numbers being shown in the SEQ column and 2) why it shows a different port number.

(17 Oct '17, 11:17) Guy Harris ♦♦

Here you go, I dont think you will need the TLS:

link text

(17 Oct '17, 11:29) Pauli

One Answer:

OK, the SSL/TLS dissector somehow thinks that what's being carried over TLS is raw TCP, so, as interpreted by Wireshark, there are (as I suspected) two TCP headers in the packet, and there are therefore

two sequence numbers in the packet, so it's displaying two sequence numbers in the SEQ column (which is presumably a custom column showing the tcp.seq field);
two source port numbers in the packet, and two destination port numbers in the packet, and the Info column shows the ones for the headers that are last in the packet, i.e. the purported TCP header atop TLS.

This may just be a bug in Wireshark. Please file a bug in the Wireshark Bugzilla, and attach the raw capture file (not a screenshot, but the raw capture file) to the bug. In order to determine the cause of the bug, and to test the fix, we need the raw capture file, so that we can see how Wireshark dissects it, and make sure it dissects it correctly once we've made a fix.

answered 17 Oct '17, 11:35

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

edited 17 Oct '17, 11:36