Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

TCP source port selection

Status
Not open for further replies.
Sep 16, 2003
1
GB
I am investigating a TCP/IP problem and would like to confirm proper behavior following a connection abort (RST flag set) for selecting the next available source port on the client.

Following graceful termination (FIN, ACK, FIN ACK), the client starts the next conversation using the next available source port.

However...

The server I am connecting to sometimes does not terminate the connection gracefully and aborts the connection with a RST packet. The client then starts up the next conversation using the SAME source port. This is causing me a problem as the firewall I am using (Firewall-1 NG FP3) drops the packet because it believes the packet is from an already established connection. I have worked round the problem by altering a parameter on the firewall, however could someone possibly confirm if the client (Windows XP) is behaving correctly by reusing the same source port following a connection abort?

Many thanks,
Lee
 
Is this client one that you have written? If so, why not use source port 0, which will cause the OS to choose an available ephemeral port for your client?

If not, what application is it that is increasing its port number by 1 each connection? And what does it do when the next port is already in use by another applicaiton?

But it is curious that the firewall is not closing a connection which has clearly received a RST packet.

From RFC 793:

Reset Processing

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state.


pansophic
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top