Yeah, I forgot that the 'SSLWATCHDOG_xxxx' constants needed to be declared in open code. However, Luca seems to prefer #ifdef/#endif anyway, vs. my macro, so he's fixed it. It's in the CVS
-----Burton --------- Original Message ---------------------------------- From: "Jac Engel" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Fri, 5 Jul 2002 19:25:01 +0200 >I 've been trying to compile RC3 on Win2K using MinGW but >a lot of warnings and an error: > >gcc -O -DHAVE_FCNTL_H=1 -DHAVE_PCAP_H=1 -DHAVE_STDARG_H=1 -I. -Ic:/mingw/gdb >m/in >clude -Ic:/mingw/wpdpack/include -Ic:/mingw/wpdpack/include/NET -I../gdchart >0.94 >c -o webInterface.o -c webInterface.c >In file included from ntop.h:2408, > from webInterface.c:23: >globals-core.h:283: warning: `struct timespec' declared inside parameter >list >globals-core.h:283: warning: its scope is only this definition or >declaration, w >hich is probably not what you want. >webInterface.c: In function `handleWebConnections': >webInterface.c:3423: `SSLWATCHDOG_BOTH' undeclared (first use in this >function) >webInterface.c:3423: (Each undeclared identifier is reported only once >webInterface.c:3423: for each function it appears in.) >webInterface.c:3435: `SSLWATCHDOG_PARENT' undeclared (first use in this >function >) >make: *** [webInterface.o] Error 1 > >Jac > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf >Of Burton Strauss >Sent: Thursday, July 04, 2002 10:42 PM >To: [EMAIL PROTECTED] >Subject: Re: [Ntop-dev] ntop RC3 - PLEASE read > > >MinGW doesn't support threads... > >That's why the code is commented OUT... > >(Um, basically, it is never going to work) > >-----Burton > > >---------- Original Message ---------------------------------- >From: Juan Ramon Duarte <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >Date: Thu, 4 Jul 2002 19:12:23 +0100 (BST) > >> >>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../wpdpac >k/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 >> > > >__________________________________________________ >D O T E A S Y - "Join the web hosting revolution!" > http://www.doteasy.com >_______________________________________________ >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 > __________________________________________________ D O T E A S Y - "Join the web hosting revolution!" http://www.doteasy.com _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop-dev
