change in semantics of socket(PF_INET, SOCK_STREAM, 0)?

[Dale Hagglund]

I upgraded from 4.8 to 4.9 and my install of net/vnc couldn't connect
to a remote server any more.  The connection is via an ssh tunnel, but
I don't think that's relevant.  The interesting thing was that I
*could* connect to the local end of the tunnel via telnet, but not via
vnc.  A few ktraces later, I got the following partial dumps:

telnet:
         88320 telnet   CALL  socket(0x2,0x1,0x6)
         88320 telnet   RET   socket 3
         88320 telnet   CALL  connect(0x3,0x8069020,0x10)
         88320 telnet   RET   connect 0

vncviewer:

         80280 vncviewer CALL  socket(0x2,0x1,0)
         80280 vncviewer RET   socket 4
         80280 vncviewer CALL  connect(0x4,0xbfbff630,0x10)

For vncviewer, the connect is the last call in the trace.  If I leave
it long enough, the connection times out.  A bit of decoding (and
source code inspection) gives the following C equivalents:

        telnet:    socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)
        vncviewer: socket(PF_INET, SOCK_STREAM, 0)

When I check ip(4), I find that a _proto_ argument of zero implies
IPPROTO_RAW.  Since vnc used to work before, I'm guessing this has
changed sometime recently.  However, tcp(4) still gives the exact same
call used by vncviewer in its SYNOPSIS section; ditto for udp(4).

Anyway, I guess the basic question is whether or not this change in
the semantics of socket(2) was intended.  In either case, I can submit
an appropriate PR if that will help.

Dale Hagglund