Re: ncat --max-conns

[David Fifield <david () bamsoftware com>]

On Tue, Oct 06, 2009 at 02:52:00AM +0400, Solar Designer wrote:
> Disclaimer: I am replying out of context (I did not read the thread).
> Yet I think my posting might be of help.
>
> On Mon, Oct 05, 2009 at 09:56:59AM -0600, David Fifield wrote:
> > It won't be safe to call logdebug from the handler function. It should
> > be only
> >
> > static void handle_conn_count(void)
> > {
> >     conn_count--;
> > }
>
> Am I correct that there will be a "conn_count++;" somewhere else?  If
> so, this is likely unreliable, because the "conn_count++;" will often be
> non-atomic (it's read-modify-write).  Additionally, conn_count would
> need to be declared "volatile sig_atomic_t", which is not great because
> of the unknown range and maybe even signedness of this type (I am not
> sure of the latter, though - maybe the signedness is in fact defined in
> a standard).
>
> To solve this new problem, I think something like the following will
> have to be used:
>
> volatile sig_atomic_t conn_dec_changed;
>
> static void handle_conn_count(void)
> {
>       conn_dec_changed = 1;
>       conn_dec++;
> }
>
> static int get_conn_count(void)
> {
>       unsigned int conn_count;
>       do {
>               conn_dec_changed = 0;
>               conn_count = conn_inc - conn_dec;
>       } while (conn_dec_changed);
>       if (conn_count > INT_MAX) return -1; // error, counts got out of sync
>       return conn_count;
> }

Thank you for this--insightful as usual. Venkat, I'll find a way to
include your patch along with Alexander's code for the signal handler.
Keeping the same function interface between the POSIX and Window netrun
turns out to be problematic. The main execution loop has to have
knowledge of when signals are delivered so it can react to the flags the
signal handler sets. But I don't think it will be difficult.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org