This allows much better and more accurate measurements of packet-loss and retransmissions than is available in any other protocol analyzer. This requires some extra state information and memory to be kept by the dissector but allows much better detection of interesting TCP events such as retransmissions. See the TCP Analysis section of the User's Guide for more up to date documentation.īy default Wireshark and TShark will keep track of all TCP sessions and implement its own crude version of Sliding_Windows. I'll try the SQLNET.ora changes first.This page might not be accurate. If that is the issue, then Im looking at TCP changes AND/OR manipulating the tcp packet sizes in the SQLNET.ora with send/recv_buffer_sizes. Searching the firewall log for the timeout event, we see TCP stream from above example making it out on port 125, but around 2 minutes later the accept gets handed back, although this delay is quite long it may be a case of delayed ACKs. The TCP stream associated with the timeout event has a start, we thought it had no accept but On the firewall log, we see all those connections, nothing being dropped, start - accept. Each stream takes a second or under, the timeout causes a hang for 5 seconds, which is the application timeout. when we get the timeout event, for example, we see the the following. Running on a test server, the test app is connecting every 1 second.
I can see the database connections as one TCP stream in the wireshark log, on the client I see each stream has the TNS connection and the data returning. Interesting, I'll explore that as a theory. Continuing to see the timeouts.Īnyone any suggestions of what to try? theres a couple of support notes on TCP retransmissions but nothing leading me to the answer here. Im running a RAC, I tried it on the SCAN and then forced it down the VIP, bypassing the SCAN. Internal or external firewalls not showing any drops. The listener log does not show the connection hitting it for the timeout event. A good start/accept port exchange would take 1-2 seconds max.
Im guessing its not as the client has opened many streams since it opened the start connection and port has closed at that stage. The return is not on the client pcap though. If I search the firewall for the start on the port, I can see it make the start attempt, but it doesnt make the return for over 2 minutes. The external firewall is showing the start packet from the source client IP/port, I then have a 5 second timeout of no traffic that coincides with a 5 second command timeout in the program at which time data starts flowing again. Examining the PCAP for the timeout event, I track the TCP flow, I see it making the attempt out a source port, followed by 2 tcp retransmissions. I set up a connection program that runs every 5 seconds.
#Wireshark tcp retransmission windows#
Windows client > external firewall > internal firewall > database Examining the PCAP in wireshark, I see tcp retransmission for the tcp flow at timeout event in a packet capture
Getting a program intermittently timing out. 1.7K Training / Learning / Certification.165.3K Java EE (Java Enterprise Edition).7.9K Oracle Database Express Edition (XE).3.8K Java and JavaScript in the Database.
0 kommentar(er)
