losing TCP ACKs: SYN_RCVD

losing TCP ACKs: SYN_RCVD

Post by ulsterban » Fri, 04 Oct 1996 04:00:00



Hello

We're having a problem on a few of our networks:
each network has a number of PCs connected to a SCO 3.4 Unix server
that,
in turn, is connected to an X.25 network.
Frequently, for no apparent reason, a random PC fails to connect.
The server-side of the connection is stuck in SYN_RCVD so it would seem
that the ACK from the PC to server is getting lost somewhere!

During our search for a solution we were informed that some variants of
the SVR4 TCP/IP kernel would occasionally ignore TCP ACKs.
Is this correct?

If so, would someone please give me more information?

Please respond via email; thanks in advance.

-- Marty

 
 
 

losing TCP ACKs: SYN_RCVD

Post by Casper H.S. D » Fri, 04 Oct 1996 04:00:00



>We're having a problem on a few of our networks:
>each network has a number of PCs connected to a SCO 3.4 Unix server
>that,
>in turn, is connected to an X.25 network.
>Frequently, for no apparent reason, a random PC fails to connect.
>The server-side of the connection is stuck in SYN_RCVD so it would seem
>that the ACK from the PC to server is getting lost somewhere!

Or the ack from the server to the PC.  Are you sure that there's a route from
the server to the PC and vice versa?  Can you ping the PC from
the server?

Casper
--
Casper Dik - Sun Microsystems - via my guest account at the University

Statements on Sun products included here are not gospel.
Unsolicited e-mail adverti*ts will be proofread for $250.

 
 
 

losing TCP ACKs: SYN_RCVD

Post by Pedro Roqu » Sat, 05 Oct 1996 04:00:00



    >> We're having a problem on a few of our networks: each network
    >> has a number of PCs connected to a SCO 3.4 Unix server that, in
    >> turn, is connected to an X.25 network.  Frequently, for no
    >> apparent reason, a random PC fails to connect.  The server-side
    >> of the connection is stuck in SYN_RCVD so it would seem that
    >> the ACK from the PC to server is getting lost somewhere!

    Casper> Or the ack from the server to the PC.  Are you sure that
    Casper> there's a route from the server to the PC and vice versa?
    Casper> Can you ping the PC from the server?

The original poster can check that if it's PC has anything similiar to
netstat (I believe windows does have). If the state in the PC is SYN-SENT
the server reply never arrived, if it is ESTABLISHED then the server's
SYN,ACK packet got through.

The more probable explanation is in fact the server not being able to reach the
client.

./Pedro.

 
 
 

losing TCP ACKs: SYN_RCVD

Post by Ulster Ban » Sun, 06 Oct 1996 04:00:00




> ...
> >Frequently, for no apparent reason, a random PC fails to connect.
> >The server-side of the connection is stuck in SYN_RCVD so it would seem
> >that the ACK from the PC to server is getting lost somewhere!

> Or the ack from the server to the PC.  Are you sure that there's a route from
> the server to the PC and vice versa?  Can you ping the PC from
> the server?

Yup, there is a route from the server to PC and back (they're on the
same
physical ethernet LAN) and both PC and server can happily ping each
other.
The same PC can connect after a reboot.

It could be the SYN/ACK from server to PC that is being lost but, as I
mentioned,
we have been told that some variants of the SVR4 TCP/IP kernel
occasionally
ignore ACKs.  We were not told under what circumstances this occurs;
this is
what I'd really like to know.

Another bit of info that I'd omitted: this usually happens in the
morning while
all the PCs are rebooting; network traffic at this time would be very
heavy with
all PCs using bootp and then a proprietry file transfer protocol on TCP.

Any more help appreciated.

Thanks.

-- Marty

 
 
 

1. TCP RFC and SYN_RCVD state

Hi,

 I have a question regarding TCP's RFC 793. There is no mention of TCP
event processing when in SYN_RCVD state.

 Page 64 (http://www.freesoft.org/CIE/RFC/Orig/rfc793.txt)
discusses what happens when a SEGMENT arrives. Only three states are
mentioned here: CLOSED, LISTEN and SYN_SENT.

 What I am interested in is what happens when we are in the SYN_RCVD
state and the ESTABLISHED state (or the rest of the CLOSE/FIN/TIME_WAIT)
states and a segment arrives.  Am I missing something from the RFC?

 The SYN_SENT state (and LISTEN and CLOSED) are explained in great
details. Like- check for ACK first, then RST, then FIN and so on. Is
there a similar treatment for SYN_RCVD, ESTABLISHED and the rest of the
states?

Any suggestions and help will be *highly* appreciated.

thanks
-P

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Syslog setup

3. ACK! Lost some files!

4. /dev/ttyS2 access denied : HELP!!

5. TCP sequence verifier: Invalid ACK number - with nfs mount from AIX to Solaris

6. 4-port expansion card

7. Linux TCP ACKing problem

8. Pls help: What's the best use of a Optical JukeBox ?

9. Linux doesn't delay TCP ACKs -- why?

10. GrimLock kernel: *** tcp.c: tcp_data bug acked < copied

11. Q: RPC on TCP/IP not setting ACK bit

12. PPP link died with tcp.c:tcp_data bug acked < copied

13. iptables tcp-logged ACK PSH