I believe the TS4 does not comply with RFC793 section 3.4 under "Half-open connections and other anomalies". http://www.faqs.org/rfcs/rfc793.html 
Half open connections are supposed to autorecover as follows:
In figure 10 of , the crashed host (TCP-A) attempts to reconnect, and sends a SYN, (eg with SEQ=0, ACK=0 in our case) - step 3 in fig 10
The sequence number 0 is outside the current TS4 TCP window, so the TS4 (TCP-
should respond with an acknowledgement indicating what sequence it next expects to hear (eg, ACK=1234) - step 4
The host TCP-A sees that this segment does not acknowledge anything it sent for any existing connection, detects this as a half-open connection, and sends an RST, SEQ=1234 to the TS4 which aborts the connection.
What actually happens is, instead of the ACK in step 4, the TS4 sends an immediate RST, ACK=0, SEQ=0, and prevents the host from detecting the half open port as it never learns the next sequence number and in any case the RST from the TS4 aborts the whole sequence.
I assume the TS4 is resetting the connection on the basis that it specifically dis-allows port-sharing, ie one exclusive instance of the tty process which is "mapped" to the specific user port on the host. The TS4 cannot create a new connection because its port is in exclusive use, and sends an RST without aborting the current tty process.
However, this method defeats the detection and recovery of half-open ports as per RFC 793.