Update. I got this working but for future reference to folks, the
kernel functions in_aton() and in_ntoa() if passed a '\n' or '\r'
character at the end of the IP address string, will totally garbage the
TCPIP address into 255.255.255.255 then attempt to connect, which
results in the tcp_v4 functions in-kernel malfunctioning. If you pass
ip address strings as text in kernel mode, be certain to remove any
trailing '\r' or '\n' characters before calling in_aton() or you will
see sock->ops->connect() hang when attempting a SOCK_STREAM connection
operation.
This shows up on 2.2.17
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> If you open s socket and pass the handle into user space, then connect
> on SOCK_STREAM works from user space, but does not seem to work in
> kernel space (hangs on signal). I noticed tht ncpfs, smbfs, nbd, and
> just about every other drivers opens the socket in user space and
> connects then passes the socket handle into the drivers via an ioctl().
> The only exception seems to be the /net/sunrpc stuff.
>
> connecting in kernel seems to be a "jolting" experience. I see hangs,
> -512, -98, -111, and -115 errors returned in an arbitrary manner. This
> seems busted on 2.2.17.
>
> Is it just a bad idea to use connect() in-kernel?
>
> Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:33 EST