CODEWITHSUNDEEP
csockets
c00kiemonster
c00kiemonster

Reputation: 23351

How can I refuse a socket connection in C?

If I want to accept a connection I call accept, but how can I refuse a connection?

In a working socket echo client I have this if statement. In the echo server, how can I make the echo client reach this printf statement? 

...
if (connect(sock, (struct sockaddr *) &server, sizeof(server)) < 0) { 
    printf("Connecting failed\n"); 
    return 1; 
}
...

Upvotes: 22

Views: 18952

Answers (6)

Arioch &#39;The
Arioch &#39;The

Reputation: 16045

One more crazy option seems to set the socket into a refuse always mode, see setsockopt call with SO_PAUSE_ACCEPT parameter.

Use this option for listening sockets. When the option is set, the socket responds to all incoming connections with an RST rather than accepting them.

I wonder if notification events would still be passed to the application about the connection attempts then (services like WSAEventSelect( , , FD_ACCEPT) and WSAAsyncSelect( , , FD_ACCEPT)) for making application like "port knocking", where mere attempts matters.

UPD. at least with Win10 FD_ACCEPT notifications indeed cease to come on a "paused" socket. Neither come FD_CONNECT or FD_CLOSE.

Also, it seems the clients then are getting time-outed rather than outright rejected. The paused connection fails in somehow more explicit way (telnet reports the rejection outright, while it waits for any user input to send when faces WSAAccept-based rejection) but after a significant delay (seen in Firefox, telnet always has 1-2 seconds delay of its own).

SysInternals TCPView though does not see any special state on such a listening socket.

UPD2. oops, i forgot to add SO_CONDITIONAL_ACCEPT to socket options in between bind and listen. Now telnet (still slow to launch) does no more wait for user input. Firefox OTOH became much slower to report error (it makes about a dozen of attempts before giving up, and did it faster). Maybe it is related to the listen -> WSAAsyncSelect -> WndProc -> WSAAccept pipeline in the test server.

Upvotes: 0

Gixxernaut
Gixxernaut

Reputation: 431

A little late to the party, but you can use WSAAccept() instead of accept(). WSAAccept() has an optional callback function that allows you to take a peek at who's knocking at the door and decide if you want to answer. Your callback function can return the constants CF_ACCEPT, CF_REJECT and CF_DEFER. The first two are obvious. The 3rd one allows you to defer answering in case you need to decide later. Once you've decided for sure you call WSAAccept() again and either accept or reject.

Unfortunately, you have to either accept or reject in order to remove the entry from the front of the listen queue. The reason I say it's unfortunate is there is an obvious difference to the connecting machine between getting rejected and never getting a response (timeout).

If a hacker is using a port scanner they'll know you're listening on the port if you reject. At that point they can start hacking their way in. It would be nice to be able to remove the entry from the front of the queue without ever doing anything with it such that whoever's on the other end doesn't know you're listening on that port.

Upvotes: 1

Remy Lebeau
Remy Lebeau

Reputation: 595887

In standard socket APIs on most platforms, there is no way to reject a connection. You must accept() the connection and then close it immediately if you don't want it.

The exception to this rule is the Winsock-specific WSAAccept() function. It provides a callback that allows an application to decide, on a per-connection basis, whether a connection should be accepted, rejected, or kept in the backlog queue.

Upvotes: 6

jxh
jxh

Reputation: 70392

To get the behavior you want (only accept one connection at a time, other clients attempting should get a failure), there are two choices.

  • You can close your listen socket after you have accepted a connection. Re-create your listen socket after the accepted connection closes.

  • You can close newly established connections if there is already a connection in progress. If you want the client to see a TCP reset, most TCP stacks will trigger one if you enable the linger option with a timeout of 0.

    struct linger lo = { 1, 0 };
    setsockopt(s, SOL_SOCKET, SO_LINGER, &lo, sizeof(lo));
    close(s);

Upvotes: 13

glglgl
glglgl

Reputation: 91017

It might be helpful

  1. to close the listening server socket after having successfully accept()ing the client connection and
  2. to re-establish it after the client connection has gone due to whatever reason.

Upvotes: 2

UltraInstinct
UltraInstinct

Reputation: 44444

To my knowledge, that isn't how TCP works. The accept(..) call will always return with the client details. There is no way to peek at the connection and selectively refuse.

The way you are doing it now is actually the correct way: accept and then close. In case you have another message structure over and above this layer, you can create a custom "Reject message". This option completely depends on your use case.

In case you are looking for rejecting on the basis of IP address, its not within your apps domain. Its the job of your firewall (As @Bart Friederichs says). That way, the request will not even touch the TCP stack.

Actually I want strictly one connection only on this particular port. Any other connection should ideally fail in a very obvious way.

Do not let the accept call in your control flow. Only when you wait on accept will your program wait for a socket connection, never otherwise.

Upvotes: 8

Related Questions