Date: Fri, 21 Feb 1997 00:22:16 +1100 From: David Nugent <davidn@labs.usn.blaze.net.au> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: David Nugent <davidn@labs.usn.blaze.net.au>, freebsd-hackers@freebsd.org Subject: Re: "connection refused" Message-ID: <19970221002216.09741@usn.blaze.net.au> In-Reply-To: <199702201229.XAA00375@unique.usn.blaze.net.au>; from Darren Reed on Feb 02, 1997 at 11:29:25PM References: <19970220013902.53279@usn.blaze.net.au> <199702201229.XAA00375@unique.usn.blaze.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 02, 1997 at 11:29:25PM, Darren Reed wrote: > > I'm currently working on a network server that needs to use local > > creditials on a remote connection, and if that fails, to issue a > > "connection refused". > > You can't do this (using sockets). Hmm, the manpage seems to suggest otherwise. See below. > I don't quite understand how you want to use the credentials...the > description seems confusing. Can you put it in TCP/IP terms ? :) Sorry, just the remote address, as determined by accept(). I don't want or need network probes finding the server, which is why I'd like an attempted connection from anyone but specific ip addresses to get "connection refused", as though there was nothing there. The protocol in question will do challenge/key and encryption, but this is just to prevent probes from seeing it as a possible target in the first place. Anyway, the manpage for accept(2) states: One can obtain user connection request data without confirming the con- nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non- zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, one can provide user connection rejection information by issuing a sendmsg(2) call with providing only the control information, or by call- ing setsockopt(2). Unless I'm reading this incorrectly, this is precisely what I'd like to do. I just can work out how to do it. :-) FWIW, the connections will exchange user accounting information; the server being basically a database server, and the clients will either be read-only or allow transactions as well. Hence the need for a fairly tight way of accepting connections and use of key-based encryption. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970221002216.09741>