On Thu, 26 Feb 2015, Darren Tucker wrote:> I noticed this error log spam on the tinderbox when looking at one of the > failures. It happens with Unix domain socket forwarding is requested: > > debug1: channel 1: new [forwarded-streamlocal at openssh.com] > get_socket_address: getnameinfo 1 failed: ai_family not supported > get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supportedThat's strange, because we do: if (addr.ss_family == AF_UNIX) { /* Get the Unix domain socket path. */ return xstrdup(((struct sockaddr_un *)&addr)->sun_path); } so AF_UNIX should never get to getnameinfo...
On Thu, Feb 26, 2015 at 4:34 PM, Damien Miller <djm at mindrot.org> wrote:> > > On Thu, 26 Feb 2015, Darren Tucker wrote: > > > I noticed this error log spam on the tinderbox when looking at one of the > > failures. It happens with Unix domain socket forwarding is requested: > > > > debug1: channel 1: new [forwarded-streamlocal at openssh.com] > > get_socket_address: getnameinfo 1 failed: ai_family not supported > > get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported > > That's strange, because we do: > > if (addr.ss_family == AF_UNIX) { > /* Get the Unix domain socket path. */ > return xstrdup(((struct sockaddr_un *)&addr)->sun_path); > } > > so AF_UNIX should never get to getnameinfo... >I added an error() call just before that check and here's what it gave: debug1: channel 1: new [forwarded-streamlocal at openssh.com]^M DAZ: fd 10 ss_family 1 expect AF_UNIX 1^M DAZ: fd 10 ss_family 0 expect AF_UNIX 1^M get_socket_address: getnameinfo 1 failed: ai_family not supported^M get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported^M looks like something is clearing ss_family? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Thu, 26 Feb 2015, Darren Tucker wrote:> I added an error() call just before that check and here's what it gave: > > debug1: channel 1: new [forwarded-streamlocal at openssh.com]^M > DAZ: fd 10 ss_family 1 expect AF_UNIX 1^M > DAZ: fd 10 ss_family 0 expect AF_UNIX 1^M > get_socket_address: getnameinfo 1 failed: ai_family not supported^M > get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported^M > > looks like something is clearing ss_family?Could these be closed sockets? (Though I couldn't see how getsockname/ getpeername could succeed in this case). Otherwise, is ipv64_normalise_mapped screwing it up?
On Thu, 26 Feb 2015 19:37:43 -0500, Darren Tucker wrote:> debug1: channel 1: new [forwarded-streamlocal at openssh.com]^M > DAZ: fd 10 ss_family 1 expect AF_UNIX 1^M > DAZ: fd 10 ss_family 0 expect AF_UNIX 1^M > get_socket_address: getnameinfo 1 failed: ai_family not supported^M > get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported^M > > looks like something is clearing ss_family?What OS is this? ISTR that getpeername() or getsockname() on some systems may not support AF_UNIX. - todd
On Fri, 27 Feb 2015 11:19:22 -0700, "Todd C. Miller" wrote:> What OS is this? ISTR that getpeername() or getsockname() on some > systems may not support AF_UNIX.This is probably due to getpeername(). We can probably change: /* Unix domain sockets don't have a port number. */ if (from.ss_family == AF_UNIX) return 0; To: /* Non-inet sockets don't have a port number. */ if (from.ss_family != AF_INET && from.ss_family != AF_INET6) return 0; - todd