Wireshark reassembly stops working after "TCP previous segment not captured"

asked 2021-09-08 02:09:46 +0000

Xiawq
1 ●1 ●1

updated 2021-09-08 07:07:11 +0000

Guy Harris
19890 ●3 ●659 ●207

I'm analiayze the rtp's packet over TCP by wireshark's dissector.

But i found some problem that the rtp dissector stop to dissection when see the TCP packet of retransmitted. I am sorry i cannot upload the image and pcap file to show the question, because i havent 60 points. but doesn't matter, i upload the file to google drive. this is the image and pcap file.

image description

captured packets file, https://drive.google.com/file/d/1SWz6...

On TCP preferences, i already enabled the "Allow subdissector to reassemble TCP streams", "Reassemble out-of-order segments", "Analyze TCP sequence numbers" options, and disabled the "Try heuristic sub-dissectors first", "Do not call subdissectors for error packets."

edit retag flag offensive close merge delete

Comments

This image show the problem. https://drive.google.com/file/d/14e42...

either to use lua dissector, i found the wireshark not called the lua subdissector after the number 860 packet.

Xiawq ( 2021-09-08 02:18:59 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2021-09-08 07:06:05 +0000

Guy Harris
19890 ●3 ●659 ●207

The problem has nothing to do with Lua.

It has to do with the capture not having all the packets in the TCP flow from 36.28.180.30:29156 to 192.168.100.3:6862.

Frame 860 has bytes with relative TCP sequence numbers 910601 to 912580 (the starting sequence number is 910601, and the TCP segment has 1980 bytes).

Frame 862 has bytes with relative TCP sequence numbers 913902 to 915189.

So the bytes from 912581 through 913901 are missing from the capture.

If "Allow subdissector to reassemble TCP streams" is on, the attempt to reassemble the RTP packet that begins in frame 860 will fail, causing all subsequent attempts to reassemble RTP packets to fail.

This mean that the RTP dissector won't be called after frame 860; if your Lua dissector is called by the RTP dissector, that means that it won't be called, either.

Unfortunately, there's no way to get Wireshark to give up on trying to reassemble that RTP packet and to start over again trying to reassemble and dissect RTP packets.

edit flag offensive delete link

Comments

Frame 860 has bytes with relative TCP sequence numbers 910601 to 912580 (the starting sequence number is 910601, and the TCP segment has 1980 bytes).
Frame 862 has bytes with relative TCP sequence numbers 913902 to 915189.
So the bytes from 912581 through 913901 are missing from the capture.

In my opinion, in frame 861 to frame 8865, on the tcp-layer, the data was be out-of-order the sequence. Then TCP procotol must cached frame 862,863,865,867,869,871,873,875,877,879,881,883 until received the retransmission frame 884, then tcp protocol must sorted by order these frame‘s sequence number.

The action of cached and sorted the frame is low-lever action on the TCP protocol, isn't that? It make the data is order by the sequence number to upper layer.

If "Allow subdissector to reassemble TCP streams" is on, the attempt to reassemble the RTP ...

(more)

Xiawq ( 2021-09-08 07:56:30 +0000 )edit

Hi Guy Harris, maybe we should check the follow codes:

in packet-tcp.c line 3450, if we comment the return action and recomiple wireshark, the rtp dissector can process the retransmission tcp packet well. And can decode all of rtp packets in capture files.

Unfortunately, now I could find no plausible explanation this change. Do you have any ideas.

Xiawq ( 2021-09-10 11:10:21 +0000 )edit

add a comment

answered 2021-09-09 08:02:18 +0000

BigFatCat
31 ●3 ●90 ●5

My answer really makes no sense to me. I tried this with other versions 3.4.8 and 3.5.1. Enable the TCP option "validate the TCP checksum if possible" and Wireshark decodes the RTP after packet 860.

edit flag offensive delete link

Comments

Hi, thanks for you answer. if enable "validate the TCP checksum if possible", Wireshark will mark the normal tcp packt to checksum incorrect. it caused the frame of normal cannot decoded.

It not a finally solution.

Xiawq ( 2021-09-09 12:57:44 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Wireshark reassembly stops working after "TCP previous segment not captured"

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark reassembly stops working after "TCP previous segment not captured" edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark reassembly stops working after "TCP previous segment not captured"