DaveBarribeau
Programmer
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.
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.