 | 1 | initial version |
A few assumptions before I give it a try to explain what happens.
The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds
Here are the facts.
The client sends its initial SYN packet with a TSVAL of tcp.options.timestamp.tsval == 4062472739
The server's SYN ACK gets lost - or was never sent.
The client retransmits with 1 second tcp.options.timestamp.tsval == 4062473739
The client retransmits after 2 seconds tcp.options.timestamp.tsval == 4062475739
-
The server retransmits its SYN_ACK with tcp.options.timestamp.tsecr == 4062472739
As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting
Now to the answers. Why the server does not accept in time can have multiple reasons. Either the listener's backlog is full or the server tries to reverse lookup the client's ip address
If the client receives 2 ACKs during the handshake it should simply discard them. If it is a SYN_ACK and carries the correct TSEcr it should complet the 3-way handshake.
Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course
Regards Matthias
| | 2 | No.2 Revision |
A few assumptions before I give it a try to explain what happens.
The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds
Here are the facts.
The client sends its initial SYN packet with a TSVAL of tcp.options.timestamp.tsval == 4062472739
The server's SYN ACK gets lost - or was never sent.
The client retransmits with 1 second tcp.options.timestamp.tsval == 4062473739
The client retransmits after 2 seconds tcp.options.timestamp.tsval == 4062475739
-
The server retransmits its SYN_ACK with tcp.options.timestamp.tsecr == 4062472739
As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting
Now to the answers. Why the server does not accept in time can have multiple reasons. Either the listener's backlog is full or the server tries to reverse lookup the client's ip address
If the client receives 2 ACKs during the handshake it should simply discard them. If it is a SYN_ACK and carries the correct TSEcr it should complet the 3-way handshake.
Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course
Regards Matthias
| | 3 | No.3 Revision |
A few assumptions before I give it a try to explain what happens.
The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds
Here are the facts.
As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting
Now to the answers.
Why the server does not accept in time can have multiple reasons.
Either the listener's backlog is full or
the server tries to reverse lookup the client's ip address
Or the SYN_ACK got dropped internally before it made it to the trace point.
If the client receives 2 ACKs during the handshake it should simply discard them.
If it is a SYN_ACK and carries the correct TSEcr it should complet complete the 3-way handshake.
Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course
Regards Matthias
| | 4 | No.4 Revision |
A few assumptions before I give it a try to explain what happens.
The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds
Here are the facts.
As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting
Now to the answers.
Why the server does not accept in time can have multiple reasons.
Either the listener's backlog is full or
the server tries to reverse lookup the client's ip address
Or the SYN_ACK got dropped internally before it made it to the trace point.
If the client receives 2 ACKs during the handshake it should simply discard them. If it is a SYN_ACK and carries the correct TSEcr it should complete the 3-way handshake.
Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course
Regards Matthias
| | 5 | No.5 Revision |
A few assumptions before I give it a try to explain what happens.
The client is running MAC and its initial RTO is 1 second The server is running Solaris and its initial RTO is 3 seconds
Here are the facts.
As this TSEcr does not match the latest client's SYN packet the client discards the SYNACK and both sides keep on re-transmitting
Now to the answers.
Why the server does not accept in time can have multiple reasons.
Either the listener's backlog is full or
the server tries to reverse lookup the client's ip address
Or the SYN_ACK got dropped internally before it made it to the trace point.
If the client receives 2 ACKs during the handshake it should simply discard them. If it is a SYN_ACK and carries the correct TSEcr it should complete the 3-way handshake.
Maybe reducing tcp_rexmit_interval_initial in Solaris down to 1 second can circumvent this - besides disabling tcp timestamp option of course
Regards Matthias
