Problem with setsockopt - SO_CONDITIONAL_ACCEPT

[mrdave2]

Usually, I dont have problems with setsocketopt, but this time I am.

I am trying to use the socket option: SO_CONDITIONAL_ACCEPT, and it says it set it fine (getsocketopt even shows it set) - But it does not do what its supposed to do, as if I never set it.

For those unfamiliar with this, SO_CONDITIONAL_ACCEPT tells windows to not respond to SYN packets unless you allow it in WSAAccept. (can accept connection, or respond with RST - connection refused).

Anyway, I just dont understand why this wont work for me. I searched it and saw plenty of places where people have used it...

I am testing this on Windows XP Pro, btw.

Thanks!

[Mathew Joy]

AFAIK, this is conditional accept is not supported by TCP. Not atleast in windows. In-fact non of the protocols that is implemented in win32 platforms supports it.

If getsockopt() shows that a sockopt is set, it only means that exactly. The OS always has the option to ignore it.

[mrdave2]

But its whole concept is based around the TCP 3-way handshake. Its even listed as a "possible problem (with fix)" on Microsoft. ( http://support.microsoft.com/?kbid=328264 ). Aswell, there are other articles on it, such as: http://www.winnetmag.com/WindowsScripting/Article/ArticleID/9632/WindowsScripting_9632.html

It *looks* like its been used successfully, and im sure it has. Im just wondering if there is any setting I have to modify/delete/add to make this option work. To be honest, I think the idea of accepting a connection then asking me whether I want to accept or reject is pretty stupid - Just a waste of bandwidth.

[Mathew Joy]

Well, I was talking about a complete conditional accept in my previous post, not just the address. ie sending a SYN packet with data.
But its whole concept is based around the TCP 3-way handshake.That's right. The idea is to have the application nodding rather than the stack, to complete a handshake.

it *looks* like its been used successfully, and im sure it has. Im just wondering if there is any setting I have to modify/delete/add to make this option work.There is nothing much different other than setting the socket opt and calling WSAAccept with a pointer to the callback function. Only thing is that the option should be set before listen.
To be honest, I think the idea of accepting a connection then asking me whether I want to accept or reject is pretty stupid - Just a waste of bandwidth.Logically, you seem to be right. And conditional accpet seems to solve the problem.But the problem is that, MS implementation of SO_CONDITIONAL_ACCEPT socket option was "flaw"ed right from the start.

First of all, there were reports (you can find it in Anthony Jones's book) that even if this socket option is set, by the time you respond with a CF_REJECT, the stack mostly will be completed the handshake. (What you posted in the second link only says what it is supposed to do) Though I haven't read anywhere that this is fixed, some later discussions indicate that the actual deferring takes place.

secondly, the idea behind SO_CONDITIONAL_ACCEPT is to reject a client connection with an RST packet if the application respond with a CF_REJECT. If this was the case, a connecting client doesn't know that a socket is listening on the port. But the problem is that the MS TCP stack implementation ignores the RST and retries with another SYN. So in effect the client timesout after 3 attempts, rather than rejecting the connection attempt right away. I don't know if it is fixed and in what way.

Thirdly, as a side-effect of the second one, if your server gets bogged down (which usually does) the backlog gets filled up and the client gets a RST packet. This client may be legitimate one. So in effect you see a valid connection being rejected. This is especially clear if the client is a non-MS platform app.

Fourthly, this is a slow and inefficient process. The stack is in the kernal mode while the app is in the user mode. Without much explanation I think it is obvious why it is so.

Fifthly, the accept should be very responsive at any given time. Otherwise you will be looking at missed timeouts, connection rejection, conn retransmission, and a lot of other complicated and unnecessary packet transfers.

Lastly but most importantly, the whole idea of conditional accept is to prevent malicious clients from connecting. But by using this option you are leaving your server vulnerable to a common and easy attack that can knock out your server. DOS attack in the form of spoofed source address or in other words, SYN flooding, which defets the whole purpose of SO_CONDITIONAL_ACCEPT .

Due to these, there is a general consensus that SO_CONDITIONAL_ACCEPT should not be used in servers. In-fact some of experts are trying to put this socket option in the lame-list of WinSock FAQ.

BTW let me see if I can get any more info on the first three.