Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Duplicate source port after reboot, host won't SYN,ACK

Duplicate source port after reboot, host won't SYN,ACK

Duplicate source port after reboot, host won't SYN,ACK

We are using HP thin clients with Windows embedded 7 with enhanced write filter on. Connecting to a host for TN3270E telnet communications in plants at a large auto manufacturer.

After a reboot and Windows loading on the thin client, we attempt to connect to the host on port 23 with a dynamic source port. We usually get source port 49157, then connect normally to the host with a SYN packet from the client, SYN,ACK from the host, then an ACK from the client and everything works fine.

Because these devices do not write to their flash drive (no hard drive), users power them off, then on at will, so there is no FIN packets being sent to the host to nicely close the TCP connection. As a result, when the thin client reboots and attempts to log back in to the host, TCP gives it the SAME source port of 49157. The client then tries to send a SYN to the host on port 23, but the host does not know that this is a new connection attempt since the IP, source and dest ports are the same - it thinks this is a duplicate SYN packet from the old connection request, so it just sends a PSH,ACK packet to the client. This is what I would expect and seems normal in this situation.

Here's where it changes - with a wired ethernet connection, TCP sees this PSH,ACK and then sends a RST packet to the host. After 3 seconds it retries the TCP connection using the SAME source port of 49157, which now succeeds because of the RST.

With a wireless connection, TCP sees the PSH,ACK packet from the host and sends another SYN packet 3 seconds later, gets another PSH,ACK from the server, then tries a 3rd time 6 seconds later. The same PSH,ACK response from the host makes it fail the connection attempt.

To convert from wired to wireless, we just disable the ethernet interface and enable the wireless interface and let it connect to the access point.

So the question is: what settings would control whether a TCP connection attempt would intentionally send a RST, then retry the connection if it received a PSH,ACK response versus just retrying another SYN as if the host hadn't responded to its SYN connection requests? There is a definite difference between the two interfaces, so we are trying to figure out if this is a TCP thing, or part of the wireless adapter's driver or settings.

Thanks for any insight.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close