This evening (US Central time), I will be committing BMS0101 to the cvs. It
will miss the 04Jul2002 snapshot. This is the SSLWATCHDOG for the problems
w/ "NS6.2.2" https://. I'm calling it a "fix" for want of a better term.
More on that in a sec.
With that, the status on the six items (stuff to work on pre 2.1) I posted
earlier becomes this:
--in CVS
1. SSLWATCHDOG
2. facilitynames / glibc / __gnuc__
3. Segmentation fault
Two reports that Luca's 3Jul2002 patch has fixed things.
5. <hostSymIpAddress>Bridge Sp. Tree/OSI Route <IMG SRC="/card.gif"
--Not fixed
4. ntop slows down and crashes on large network
Nothing back from Michael, probably not solvable in the very near
term...
6. ntop hangs freeing an entry in the myGlobals.tcpSvc structure on
shutdown.
I found two problem areas and have referred them to Luca for a proper
fix. Since this is only during shutdown, it's lower priority.
Accordingly, as promised this morning, I will be creating and posting ntop
2.0.99RC3 to SourceForge (I don't have access to ntop.org). rpms will
follow in a little bit - as soon as I can get them built. I will build the
rpms with the command line option available.
However, people need to understand the issue related to the SSLWATCHDOG.
And I need people to test the code, because it's pretty invasive.
Because I know people don't read long messages, let me put the meat here.
I've been having problems w/ the ntop web server hanging when accessed via
ssl (https://) from Netscape 6.2.2 (Win2K) (and others).
I put a fix into ntop to create a "watchdog". It waits for 3 seconds and
then if the SSL_accept call (openSSL) hasn't finished, it aborts it. This
leaves the user with nothing on their web browser, but at least ntop's web
server continues on. I don't know of a way to send something back to the
user, because it's the browser-server handshake that's hung. It looks - to
the user - like a failed connection.
Please run with --ssl-watchdog if you are using https:// and check if the
new code is working... The item to look for on the configuration page
(info.html) is:
# HTTPS Request Timeouts
Or messages in the log:
Jul 3 17:20:57 tigger ntop[20240]: SSLWDERROR: Watchdog timer has expired.
Aborting request, but ntop processing continues!
-----Burton
At least I got to learn about pthreads, condvars and stuff...
The background:
The problem is that ntop's web server is single threaded until we determine
that the request is simply one that will be reading data. At that point we
fork to generate the page. But the basic "accept a request" code is single
threaded. This happens all but instantaneously and hasn't been a problem
previously.
The code is pretty basic and pretty common:
select() to wait for a connection, then
ssl_accept() to fireup a "server", meaning the ssl handshake.
Then process the http request (i.e. the GET and associated headers).
With Netscape 6.2.2 (and others), there seems to be a bug in the Netscape
code (ntop's is identical to other projects like sshd).
According to something I read - but now can't find again - Netscape doesn't
accept a legal combination of options on the handshake back from openSSL and
hangs in a deadly embrace. Supposedly openSSL 0.9.6c (or was it d - it's
not in the changelog) built in a patch. However, I didn't find the new
version changed the behavior, nor are a lot of vendors shipping those
releases (yet). There is stuff about a bug w/ Netscape 4.x on the openSSL
website, but I'm not having trouble with Netscape 4.x.
I don't understand the details and really don't care to find out. It boils
down to a hang in a call, SSL_accept() that doesn't have a timeout
parameter. Argh...
Because the code is invasive, I've built it (like the SIGPIPE stuff) so you
can turn it on at ./configure time:
--enable-sslwatchdog Watchdog for ssl hangups (Netscape 6.2.2)
[default=disabled]
or via a command line option:
--ssl-watchdog Use ssl watchdog (NS6 problem)
With the "fix", ntop's web server hangs for at most 3 seconds, then
continues on. The user gets nada - and I don't know a way to send them
anything, because we haven't retrieved the request yet nor done the
handshake (so there isn't a TCP connection!)
It only affects https:// requests and I've coded the watchdog so it doesn't
activate unless we have openSSL and either the compile or runtime parameter
set. If you don't get https:// requests, it's just another idle thread.
The fix is working for me... What I've tested (and the results with and
without the watchdog):
Win2k
MS Internet Explorer 5.5 - ok
Netscape 4.61 - ok
Netscape 4.79 - ok
Netscape 6.2.2 - user gets no response
- old: ntop webserver hung and must restart ntop!!
Opera 6.03 - user gets a partial response
- old: browser says "setting up secure connection" and never
continues, but ntop webserver is ok (SOMETIMES you get SSL errors in log,
esp. if you cancel the browser)
Linux
Konqueror 2.2.2 - ok
Mozilla - 1.0 - ok
Netscape 4.78 - ok
Galeon 1.2.5 - almost complete response, browser session is toast (must
restart)
- old: user gets nothing, but the ntop webserver is ok
Opera 6.0B1 - user gets a partial response, but browser session is ok
- old: browser says "setting up secure connection" and never
continues, but ntop webserver is ok.
Note that this version may not be final - Luca wants to see and test the
code, and it hasn't been tested under anything but Linux. Solaris needs to
be tested - Win32 shouldn't be an issue (no threads)...
-----Burton
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
