bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

There are two places in process.c where getsockopt(,,SO_ERROR,,) is
used to check the status of a socket connection attempt.  The first is
at line 3289, where it is done on all platforms except MS Windows.  The
second is at line 5500, where it is done only on GNU/Linux:

#ifdef GNU_LINUX
	      /* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
		 So only use it on systems where it is known to work.  */
	      {
		socklen_t xlen = sizeof (xerrno);
		if (getsockopt (channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
		  xerrno = errno;
	      }
#else
	      {
		struct sockaddr pname;
		socklen_t pnamelen = sizeof (pname);

		/* If connection failed, getpeername will fail.  */
		xerrno = 0;
		if (getpeername (channel, &pname, &pnamelen) < 0)
		  {
		    /* Obtain connect failure code through error slippage.  */
		    char dummy;
		    xerrno = errno;
		    if (errno == ENOTCONN && read (channel, &dummy, 1) < 0)
		      xerrno = errno;
		  }
	      }
#endif

It would be better to use it on as many platforms as possible, since
it's much more likely to give the real reason for a connection failure
than the "error slippage" method.

Ken

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Eli Zaretskii]

> From: Ken Brown <kbrown@cornell.edu>
> Date: Tue, 24 May 2016 20:26:13 -0400
> 
> There are two places in process.c where getsockopt(,,SO_ERROR,,) is
> used to check the status of a socket connection attempt.  The first is
> at line 3289, where it is done on all platforms except MS Windows.  The
> second is at line 5500, where it is done only on GNU/Linux:

FYI, the first instance is ifdef'ed away for Windows because we can
never have EINTR on Windows, and the surrounding code that handles
that case is tricky to get to compile on Windows (since we override
the definitions of FD_* macros with our own).  MS-Windows does support
SO_ERROR.

> It would be better to use it on as many platforms as possible, since
> it's much more likely to give the real reason for a connection failure
> than the "error slippage" method.

Perhaps you or someone could write a small test program, and then
people here could run it various platforms and provide feedback.

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On 5/25/2016 12:24 PM, Eli Zaretskii wrote:
> Perhaps you or someone could write a small test program, and then
> people here could run it various platforms and provide feedback.

Test program attached.  It simulates the situation of bug 23606 (before 
the bug was fixed).  Here's what happens on Cygwin:

$ gcc -o socket_test socket_test.c

$ ./socket_test.exe
Server listening on port 50176.
Attempting client connection...failure: Connection refused.

Ken

[-- Attachment #2: socket_test.c --]
[-- Type: text/plain, Size: 3032 bytes --]

#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>

/* Return file descriptor or -1.  */
int make_connection (int server, int *pservice);

int
main(void)
{
  int sfd, cfd, xerrno, service;
  socklen_t xlen = sizeof (xerrno);
  
  sfd = make_connection (1, &service);
  if (sfd == -1)
    {
      fprintf (stderr, "Can't start server.\n");
      exit(1);
    }
  printf ("Server listening on port %d.\n", service);

  cfd = make_connection (0, &service);
  if (cfd == -1)
    {
      fprintf (stderr, "Can't start client.\n");
      exit (1);
    }
  fprintf (stderr, "Attempting client connection...");

  /* Here we should use 'select' to wait for cfd to be ready for
     writing.  To simplify the test, I’m just calling 'sleep'.  */
  sleep (2);

  if (getsockopt (cfd, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
    {
      perror ("getsockopt");
      exit (1);
    }

  if (xerrno)
    printf ("failure: %s.\n", strerror (xerrno));
  else
    printf ("success.\n");
  exit (0);
}

int
make_connection (int server, int *pservice)
{
  struct addrinfo hints, *result, *rp;
  int family, optval, ret, s = -1;
  const char *host;
  const char *portstring;
  char portbuf[128];
  struct sockaddr_in sa;
  socklen_t len = sizeof (sa);

  if (server)
    /* Assigned port will be returned in pservice.  */
    {
      family = AF_INET;
      portstring = "0";
      host = "127.0.0.1";
    }
  else
    /* Client; desired port should be specified in pservice.  */
    {
      family = AF_UNSPEC;
      portstring = portbuf;
      sprintf (portbuf, "%d", *pservice);
      host = "localhost";
    }

  memset (&hints, 0, sizeof (struct addrinfo));
  hints.ai_socktype = SOCK_STREAM;
  hints.ai_family = family;

  if (getaddrinfo (host, portstring, &hints, &result))
    return -1;

  optval = 1;
  for (rp = result; rp; rp = rp->ai_next)
    {
      s = socket (rp->ai_family, rp->ai_socktype, rp->ai_protocol);
      if (s == -1)
	continue;

      if (server)
	{
	  if (setsockopt (s, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval))
	      == -1)
	    {
	      perror ("setsockopt");
	      close (s);
	      return -1;
	    }

	  if (bind (s, rp->ai_addr, rp->ai_addrlen))
	    {
	      perror ("bind");
	      close (s);
	      return -1;
	    }
      
	  if (listen (s, 5))
	    {
	      perror ("listen");
	      close (s);
	      return -1;
	    }

	if (getsockname (s, (struct sockaddr *) &sa, &len))
	  {
	    perror ("getsockname");
	    close (s);
	    return -1;
	  }
	  *pservice = ntohs (sa.sin_port);
	}
      else
	/* Nonblocking client.  */
	{
	  if (fcntl (s, F_SETFL, O_NONBLOCK) == -1)
	    {
	      close (s);
	      s = -1;
	      continue;
	    }
	}
      ret = connect (s, rp->ai_addr, rp->ai_addrlen);
      if (ret == 0 || errno == EISCONN)
	break;
      if (!server && errno == EINPROGRESS)
	break;
      close (s);
      s = -1;
    }
  freeaddrinfo(result);
  return s;
}

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

> Cc: 23615@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Wed, 25 May 2016 15:21:56 -0400
> 
> On 5/25/2016 12:24 PM, Eli Zaretskii wrote:
> > Perhaps you or someone could write a small test program, and then
> > people here could run it various platforms and provide feedback.
> 
> Test program attached.  It simulates the situation of bug 23606 (before 
> the bug was fixed).  Here's what happens on Cygwin:
> 
> $ gcc -o socket_test socket_test.c
> 
> $ ./socket_test.exe
> Server listening on port 50176.
> Attempting client connection...failure: Connection refused.

With MinGW, I get this instead:

  D:\usr\eli\data>socket_test
  Server listening on port 2213.
  Attempting client connection...success.

Do we have to have a failure in this case?  Or is the above a valid
outcome?

Of course, I needed to hack the code quite a lot to get it compile on
MS-Windows; the result is attached below.  Maybe I broke the code
while doing that?

(I don't think calling 'connect' after 'listen' is supposed to work;
on Windows it predictably fails with EINVAL, as documented on MSDN.)


[-- Attachment #2: socket_test.c --]
[-- Type: application/octet-stream, Size: 4705 bytes --]

#ifdef __MINGW32__
#define _WIN32_WINNT 0x0501
#include <winsock2.h>
#include <ws2tcpip.h>
#define sleep(s) Sleep(s*1000)
#define SOCK_DESC SOCKET
#include <errno.h>
#ifndef EISCONN
# define EISCONN WSAEISCONN
#endif
#ifndef EINPROGRESS
# define EINPROGRESS WSAEINPROGRESS
#endif
#ifndef EWOULDBLOCK
# define EWOULDBLOCK WSAEWOULDBLOCK
#endif
#else
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#define SOCK_DESC int
#endif
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>

/* Return file descriptor or -1.  */
SOCK_DESC make_connection (int server, int *pservice);

int
set_nblock (SOCK_DESC s)
{
#ifdef __MINGW32__
  unsigned long nblock = 1;

  return ioctlsocket (s, FIONBIO, &nblock);
#else
  return fcntl (s, F_SETFL, O_NONBLOCK)
#endif
}

void
close_socket (SOCK_DESC s)
{
#ifdef __MINGW32__
  closesocket (s);
#else
  close (s);
#endif
}

#ifdef __MINGW32__
char *
w32_strerror (int error_no)
{
  static char buf[500];
  DWORD ret;

  if (error_no == 0)
    error_no = GetLastError ();

  ret = FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM |
		       FORMAT_MESSAGE_IGNORE_INSERTS,
		       NULL,
		       error_no,
		       0, /* choose most suitable language */
		       buf, sizeof (buf), NULL);

  while (ret > 0 && (buf[ret - 1] == '\n' ||
		     buf[ret - 1] == '\r' ))
      --ret;
  buf[ret] = '\0';
  if (!ret)
    sprintf (buf, "w32 error %u", error_no);

  return buf;
}
#endif

int
main(void)
{
  SOCK_DESC sfd, cfd;
  int  xerrno, service;
  socklen_t xlen = sizeof (xerrno);

#ifdef __MINGW32__
  WSADATA  winsockData;
  WSAStartup (0x101, &winsockData);
#endif

  sfd = make_connection (1, &service);
  if (sfd == (SOCK_DESC)-1)
    {
      fprintf (stderr, "Can't start server.\n");
      exit(1);
    }
  printf ("Server listening on port %d.\n", service);

  cfd = make_connection (0, &service);
  if (cfd == (SOCK_DESC)-1)
    {
      fprintf (stderr, "Can't start client.\n");
      exit (1);
    }
  fprintf (stderr, "Attempting client connection...");

  /* Here we should use 'select' to wait for cfd to be ready for
     writing.  To simplify the test, I’m just calling 'sleep'.  */
  sleep (2);

  if (getsockopt (cfd, SOL_SOCKET, SO_ERROR, (char *)&xerrno, &xlen))
    {
      perror ("getsockopt");
      exit (1);
    }

  if (xerrno)
    {
#ifdef __MINGW32__
      printf ("failure: %s.\n", w32_strerror (xerrno));
#else
      printf ("failure: %s.\n", sterror (xerrno));
#endif
    }
  else
    printf ("success.\n");
  exit (0);
}

SOCK_DESC
make_connection (int server, int *pservice)
{
  struct addrinfo hints, *result, *rp;
  int family, optval, ret;
  SOCK_DESC s = (SOCK_DESC)-1;
  const char *host;
  const char *portstring;
  char portbuf[128];
  struct sockaddr_in sa;
  socklen_t len = sizeof (sa);
  int xerrno;

  if (server)
    /* Assigned port will be returned in pservice.  */
    {
      family = AF_INET;
      portstring = "0";
      host = "127.0.0.1";
    }
  else
    /* Client; desired port should be specified in pservice.  */
    {
      family = AF_UNSPEC;
      portstring = portbuf;
      sprintf (portbuf, "%d", *pservice);
      host = "localhost";
    }

  memset (&hints, 0, sizeof (struct addrinfo));
  hints.ai_socktype = SOCK_STREAM;
  hints.ai_family = family;

  if (getaddrinfo (host, portstring, &hints, &result))
    return -1;

  optval = 1;
  for (rp = result; rp; rp = rp->ai_next)
    {
      s = socket (rp->ai_family, rp->ai_socktype, rp->ai_protocol);
      if (s == (SOCK_DESC)-1)
	continue;

      if (server)
	{
	  if (setsockopt (s, SOL_SOCKET, SO_REUSEADDR, (const char *)&optval,
			  sizeof(optval))
	      == -1)
	    {
	      perror ("setsockopt");
	      close_socket (s);
	      return -1;
	    }

	  if (bind (s, rp->ai_addr, rp->ai_addrlen))
	    {
	      perror ("bind");
	      close_socket (s);
	      return -1;
	    }

	  if (listen (s, 5))
	    {
	      perror ("listen");
	      close_socket (s);
	      return -1;
	    }

	  if (getsockname (s, (struct sockaddr *) &sa, &len))
	    {
	      perror ("getsockname");
	      close_socket (s);
	      return -1;
	    }
	  *pservice = ntohs (sa.sin_port);
	  ret = 0;
	}
      else
	/* Nonblocking client.  */
	{
	  if (set_nblock (s) == -1)
	    {
	      close_socket (s);
	      s = -1;
	      continue;
	    }
	  ret = connect (s, rp->ai_addr, rp->ai_addrlen);
	}
#ifdef __MINGW32__
      xerrno = WSAGetLastError ();
#else
      xerrno = errno;
#endif
      if (ret == 0 || xerrno == EISCONN)
	break;
      if (!server && (xerrno == EINPROGRESS || xerrno == EWOULDBLOCK))
	break;
      close_socket (s);
      s = -1;
    }
  freeaddrinfo(result);
  return s;
}

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

On 5/28/2016 8:57 AM, Eli Zaretskii wrote:
>> From: Ken Brown <kbrown@cornell.edu>

>> Test program attached.  It simulates the situation of bug 23606 (before
>> the bug was fixed).  Here's what happens on Cygwin:
>>
>> $ gcc -o socket_test socket_test.c
>>
>> $ ./socket_test.exe
>> Server listening on port 50176.
>> Attempting client connection...failure: Connection refused.
>
> With MinGW, I get this instead:
>
>   D:\usr\eli\data>socket_test
>   Server listening on port 2213.
>   Attempting client connection...success.
>
> Do we have to have a failure in this case?  Or is the above a valid
> outcome?

It's a valid outcome.  I think the reason the connection is refused on 
Cygwin (and apparently on RHEL 7.2) is that the first addrinfo structure 
returned by getaddrinfo has an IPv6 address.  There's no reason to 
expect this to happen on all platforms.

> Of course, I needed to hack the code quite a lot to get it compile on
> MS-Windows; the result is attached below.  Maybe I broke the code
> while doing that?

No, you didn't.  I get the same results as before with your version, 
after fixing a couple of typos that don't affect the MinGW build.  (You 
forgot a semicolon at the end of line 41, and you misspelled "strerror" 
in line 126.)

> (I don't think calling 'connect' after 'listen' is supposed to work;
> on Windows it predictably fails with EINVAL, as documented on MSDN.)

I think on Posix systems it fails with EISCONN.  I put the call in 
because it's done in the code in process.c that I was imitating, but 
omitting it as you did is fine also.

Thanks for testing.

Ken

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Eli Zaretskii]

> Cc: 23615@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sat, 28 May 2016 13:18:27 -0400
> 
> > With MinGW, I get this instead:
> >
> >   D:\usr\eli\data>socket_test
> >   Server listening on port 2213.
> >   Attempting client connection...success.
> >
> > Do we have to have a failure in this case?  Or is the above a valid
> > outcome?
> 
> It's a valid outcome.  I think the reason the connection is refused on 
> Cygwin (and apparently on RHEL 7.2) is that the first addrinfo structure 
> returned by getaddrinfo has an IPv6 address.  There's no reason to 
> expect this to happen on all platforms.

OK, thanks.  So hopefully others will chime in with results from other
platforms.

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Paul Eggert]

On Solaris 10 on a host with only IPv4 configured, socket_test.c fails 
with the diagnostic "Can't start server." 'truss' says connect(3, 
0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.

On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno == 
EADDRNOTAVAIL.

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

On 6/2/2016 12:00 PM, Paul Eggert wrote:
> On Solaris 10 on a host with only IPv4 configured, socket_test.c fails
> with the diagnostic "Can't start server." 'truss' says connect(3,
> 0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.
>
> On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno ==
> EADDRNOTAVAIL.

Thanks for testing.  This means that my test program is not portable 
enough to answer the question in the subject; the failure occurred 
before the program reached the getsockopt call.  I'll see if I can fix that.

Ken

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

On 6/2/2016 1:17 PM, Ken Brown wrote:
> On 6/2/2016 12:00 PM, Paul Eggert wrote:
>> On Solaris 10 on a host with only IPv4 configured, socket_test.c fails
>> with the diagnostic "Can't start server." 'truss' says connect(3,
>> 0x00021EE8, 16, SOV_DEFAULT) failed with errno == EOPNOTSUPP.
>>
>> On Solaris 11 with both IPv4 and IPv6, the same symptoms except errno ==
>> EADDRNOTAVAIL.
>
> Thanks for testing.  This means that my test program is not portable
> enough to answer the question in the subject; the failure occurred
> before the program reached the getsockopt call.  I'll see if I can fix
> that.

I wonder if the problem was calling 'connect' after calling 'listen'. 
Eli pointed out that this doesn't work on MS-Windows, and in any case I 
can't see why it would ever be needed.  (I only did it because the code 
in process.c that I was imitating did it.)

Does the following help?

--- socket_test.c~      2016-05-25 21:27:46.000000000 -0400
+++ socket_test.c       2016-06-02 13:47:52.719883900 -0400
@@ -122,6 +122,7 @@
             return -1;
           }
           *pservice = ntohs (sa.sin_port);
+         ret = 0;
         }
        else
         /* Nonblocking client.  */
@@ -132,8 +133,8 @@
               s = -1;
               continue;
             }
+         ret = connect (s, rp->ai_addr, rp->ai_addrlen);
         }
-      ret = connect (s, rp->ai_addr, rp->ai_addrlen);
        if (ret == 0 || errno == EISCONN)
         break;
        if (!server && errno == EINPROGRESS)

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

On 6/2/2016 1:55 PM, Ken Brown wrote:
> I wonder if the problem was calling 'connect' after calling 'listen'.
> Eli pointed out that this doesn't work on MS-Windows, and in any case I
> can't see why it would ever be needed.  (I only did it because the code
> in process.c that I was imitating did it.)

Sorry, I misread the code.  process.c doesn't call 'connect' after 
calling 'listen'.

Ken

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Ken Brown]

I see that you've made the change I suggested, so my test program is no 
longer relevant.  I'm closing the bug.

Ken

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?

[Paul Eggert]

Ken Brown wrote:
> I see that you've made the change I suggested, so my test program is no longer
> relevant.  I'm closing the bug.

Thanks, to be honest I had forgotten all about the bug! I ran into this problem 
again why trying to fix another bug, and this patch was separable from the main 
fix (which I haven't installed yet).