From owner-freebsd-hackers Thu May 16 03:03:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA13464 for hackers-outgoing; Thu, 16 May 1996 03:03:57 -0700 (PDT) Received: from art-1.acorn.co.uk (art-1.acorn.co.uk [136.170.131.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA13447 for ; Thu, 16 May 1996 03:03:51 -0700 (PDT) Received: by art-1.acorn.co.uk (SMI-8.6/SMI-SVR4) id LAA23492; Thu, 16 May 1996 11:03:09 +0100 X-Account: 1130 Date: Thu, 16 May 96 11:02:50 BST From: kbracey@art.acorn.co.uk (Kevin Bracey) To: freebsd-hackers@freebsd.org Subject: Problem with non-blocking TCP connects? Message-Id: <319B0B5A@kbracey> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is an interesting anomaly in the processing of non-blocking TCP connections. In the case of a loop like while (!connected) { if (connect(s, addr, addrlen) < 0) { if (errno == EINPROGRESS || errno == EALREADY) continue; else if (errno == EISCONN) connected = 1; else return errno; } else connected = 1; } you would normally expect a sequence of errors from connect like: EINPROGRESS EALREADY EALREADY EALREADY EISCONN or, if the connection is refused EINPROGRESS EALREADY EALREADY ECONNREFUSED The former happens, but in the latter case you get EINVAL instead of ECONNREFUSED. This is because when the connection is refused, TCP discards its PCBs and refuses to have anything to do with the relevant socket. Should there be some sort of patch to tcp_usrreq() to check so->so_error (which in the above case is actually set to ECONNREFUSED) and return that if set, before complaining about the lack of a PCB? Kevin Bracey Acorn RISC Technologies