TCP segment of a reassembled PDU length 1

0
votes

I have timeout errors in a Oracle database and when I sniff it using Wireshark I get a packet with the following info: TCP segment of a reassembled PDU.

It has this TCP information:

Transmission Control Protocol, Src Port: ncube-lm (1521), Dst Port: 57861 (57861), Seq: 1, Ack: 1, Len: 1

I have 10 packets more with the same origin and destination as the mentioned above.

After the first packet with info 'TCP segment of a reassembled PDU' there come 9 identical packets:

2728 596.537143000 10.XX.XX.XX 10.YY.YY.YY TCP 55 [TCP Keep-Alive] ncube-lm > 57861 [ACK] Seq=1 Ack=1 Win=258 Len=1.

Then I have one last packet:

2746 605.585011000 10.XX.XX.XX 10.YY.YY.YY TCP 54 ncube-lm > 57861 [RST, ACK] Seq=2 Ack=1 Win=0 Len=0

This last packet appears at the exact time when the timeout occurs in the database.

How can a length 1 packet having been reassembled? Why does it have been reassembled when it comes from our own local machine?

This packet's source its our Oracle database (port 1521). Why does it send a packet with one byte of data (with value '00')?

Thank you!

2
databasenetworkingtcpwiresharkpacket

2 Answers

0
votes

Usually, TCP packets with a len of 1 are control packets (ACK,SYN,FIN,RST). I'm guessing this is the case you encountered. Moreover, the Wireshark packet extra info (in your case - 'TCP segment of a reassembled PDU') sometime labels packets incorrectly, so you should not rely on it entirely.

I don't think these packets are the reason for the timeout issue. could you supply more info about the rest of the session and the packets timing?

1
votes

By default the keep-alive(tcp_keepalive_probes) probe count is 9. The machine has sent 9 keep-alive probes but didn't get any response from the other end so it has reset the connection.