Date: Mon, 08 Mar 2004 23:34:12 -0700 From: Dale Hagglund <rdh@yottayotta.com> To: freebsd-questions@freebsd.org Subject: change in semantics of socket(PF_INET, SOCK_STREAM, 0)? Message-ID: <86smgizfyz.fsf@ponoka.ed.shawcable.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86smgizfyz.fsf>