Hi,

I've been trying to compile RC3 on Win2K using MinGW.
As you can see I've added the SSLWATCHDOG flags to the makefile to enable 
the watchdog code but it's not compiling. 

GCC dies with the following error message:


--------- GCC Output -----------
gcc -O -DHAVE_FCNTL_H=1 -DHAVE_PCAP_H=1 -DHAVE_STDARG_H=1 
-DUSE_SSLWATCHDOG=1 -DPARM_SSLWATCHDOG=1 -I. -Ic:/MinGW/include -I../wpdpack/include 
-I../wpdpack/include/NET -I../gdchart0.94c -o initialize.o -c initialize.c

In file included from ntop.h:2408,
                 from initialize.c:25:
globals-core.h:283: warning: `struct timespec' declared inside parameter 
list
globals-core.h:283: warning: its scope is only this definition or 
declaration, which is probably not what you want.
initialize.c: In function `initThreads':
initialize.c:707: structure has no member named `sslwatchdogCondvar'
initialize.c:708: structure has no member named `sslwatchdogCondvar'
make: *** [initialize.o] Error 1
--------- End GCC Output -----------


Any ideas?

JRD


On Wed, 3 Jul 2002, Burton M. Strauss III wrote:

> 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-dev mailing list
> [EMAIL PROTECTED]
> http://lists.ntop.org/mailman/listinfo/ntop-dev
> 

_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop-dev

Reply via email to