Towards a 2.4.4 release

Julien ÉLIE julien at trigofacile.com
Sun Apr 6 11:28:37 UTC 2008


> And finally, does someone see what else should be done for INN 2.4.4?

Do you think this patch should be committed to both STABLE and CURRENT?

We currently have nothing better than it...  Otherwise, some SSL clients
do not work well with INN.  Outlook Express/Windows Mail/Forté Agent are
fine but Thunderbird/slrn/mutt-ng are *not*, amongst the news clients
I tested.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<http://groups.google.fr/group/news.software.nntp/browse_frm/thread/53f4043e2bc0da8f/61a1e2379a04489e>

Hi,

This may not be exactly the same issue started this thread... I think there
is a dead lock issue with the current SSL code in NNRPD. I meant to bring
this up several times, but always missed the opportunity.

Basically, the SSL_read cannot be mixed with select(...) as in the current
code. SSL communicates in its own data blocks and hand shaking. The
do_readline using SSL_read could return, but still with a partial line in
the SSL_read buffer. Then the server SSL routine would sit there waiting for
completion of that data block while NNRPD sat at the select(...) routine
waiting for more data from the server.

OE as NNTP client caused easy dead locks with multiple return lines commands
such as XOV. Agent seemed OK... they probably coordinated their lines with
the SSL blocks. And, using any SSL wrappers should definitely has problem,
since they would not know to align their data blocks with line breaks.

The correct fix probably was to make sure the full SSL block was read from
SSL_read before going into the select(...) wait. Nevertheless, for general
release, it would be very hard to guarantee the interaction between the SSL
IO code and the raw select IO, especially with so many different platforms.

I took the short route of just bypass the select(...) wait (see patch
below). Unlike INND with multiple threads, the select on NNRPD just waiting
on a single file descriptor, so it is not really essential with blocked read
like SSL_read. Using an alarm signal around SSL_read for non active timeout,
we has been running a patched version of NNRPD in SSL without the dead lock
condition for quite many months. Of course, without the select(...) wait,
the IDLE timer stat won't be collected..

Kachun

*** line.c.orig Thu May  3 02:07:33 2007
--- line.c      Thu May  3 15:01:39 2007
***************
*** 141,146 ****
--- 141,150 ----
                    line->allocated = newsize;
                }
            }
+
+ #ifdef HAVE_SSL
+       if (tls_conn == NULL) {
+ #endif
            /* wait for activity on stdin, updating timer stats as we
             * go */
            do {
***************
*** 157,162 ****
--- 161,169 ----
                    syswarn("%s can't select", ClientHost);
                    return RTtimeout;
                }
+ #ifdef HAVE_SSL
+             }
+ #endif



More information about the inn-workers mailing list