Well its easy to say, I had unnumbered problems compiling the current
versions. =( (I mean in FreeBSD) Maybe the portability of ntop is not so
good that the person who makes the ports of ntop is uwvilling to deal with
it until ntop is stable. Also to upgrade to current version easier to
say than done.
One thing for sure, the configure script is very clumsy about finding
gdchart libraries installed from FreeBSD ports and another thing is that
the gdchart libraries which come with ntop is old.
OK I fixed the configure script and it found everything correctly and I
ran ntop. The charts came only with background color (well I assume it was
background color) I dont know why really. Well I had the same problem with
the currently ported version in FreeBSD too.
I think maybe ntop development should be frozen for a while and should be
put into bug-fixing mode or at least documentation should be revised
REQUEST: If you are compiling and using ntop on FreeBSD why dont you let
us know the secret of successful installation of ntop on FreeBSD. If it is
compiled so easily perhaps a ssh session log of a successful installation
on a FreeBSD would provide enough information. Of course the installation
should be done on a freshly installed FreeBSD so that we will get a
glimpse of how and where you install the other libraries(like gdchart)
etc.
Thanks,
Evren
PS. I guess I also have a kind of attitude to the subject but I am sure
that my attitude will get back to normal if I just could install
ntop easily and successfully next time I try ;)
On Sun, 13 Oct 2002, Burton M. Strauss III wrote:
> Once again, *******, lose the attitude and use the current (supported)
> versions...
>
>
> The answer to your primary question,
> "How do I fix my installation of ntop so that when I type in: https://";
>
> REMAINS THE SAME
>
> UPGRADE TO A CURRENT VERSION OF ntop, not an unsupported beta.
>
> The current versions are 2.1.3 and 2.1.51 (development snapshot), both
> available on SourceForge. I happen to KNOW - because I occasionally use it
> and develop there myself - that the current versions work just fine under
> FreeBSD 4.6.2.
>
> If you have a problem with the version provided in the FreeBSD ports, then
> take it up with the FreeBSD ports people.
>
>
> As to the presence or absence of information about SSL in the docs/FAQ file,
> yes, it's in there... If you read the CURRENT one, not the six month old
> beta version you insist on being wedded to...
>
>
> Q: What is the ssl watchdog?
> A: (Added 2002-Sep-09, Burton)
>
> Short answer: There are reported problems w/ the ntop web server hanging
> when
> accessed via ssl (https://) from Netscape 6.2.2 (Win2K)
> (and others).
>
> The ssl "watchdog" keeps an eye on the web server - 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.
>
> There is no know way to send something back to the user.
> DON'T EVEN ASK.
> It's not in ntop, it's the browser-server handshake that's
> hung.
> So, it looks - to the user - like a failed connection.
> S'be'it...
>
> If you are using https:// and seem to have the problem, run ntop with
> the --ssl-watchdog
> command line parameter... The item to look for on the configuration page
> (info.html) is:
>
> # HTTPS Request Timeouts
>
> Or messages in the log:
>
> ...: SSLWDERROR: Watchdog timer has expired. Aborting request, but ntop
> processing continues!
>
> You can also enable it via a ./configure parameter (./configure --help |
> less) if it's
> something you're going to always require.
>
>
> Q. Tell me more
> A. 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 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.
>
>
>
> -----Burton
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Firsto Lasto
> Sent: Sunday, October 13, 2002 3:01 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Ntop] SSL timeout fix
>
>
>
> It gives me no satisfaction or happiness to contradict you, but the problem
> with SSL we are talking about is _not_ documented in the FAQ file. It's
> not. <-- It's not.
>
> (it isn't)
>
> So once again, if I may - how do you solve the SSL problem (I refer to it as
> "the ssl problem" since usenet archives show that this is a long standing
> issue faced by many) ? How do I fix my installation of ntop so that when I
> type in:
>
> https://some.example.com:3001
>
> I do not get the timeout error ? I have no intention of removing my ntop
> installation, I am perfectly happy to just fix the existing installation and
> just need to know the right secret to do it.
>
> thanks!
>
>
>
> >
> >Problems with SSL have been tested and problems fixed - in the RELEASED
> >version. The remaining ones are documented in the FAQ file.
> >
> >It's not my fault, nor my concern if the FreeBSD people choose to package
> >and distribute a beta release. Take it up with them... or you could grab
> >the cvs or released code and back-port the patch.
> >
> >Either way, lose the attitude! If you want commercial quality support,
> >then
> >PAY commercial quality prices. How about when shooting your mouth off, you
> >use that thing between your ears first? It's called a brain and supposedly
> >it thinks for you.
> >
> >-----Burton
> >
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> >Firsto Lasto
> >Sent: Saturday, October 12, 2002 10:54 PM
> >To: [EMAIL PROTECTED]
> >Cc: [EMAIL PROTECTED]
> >Subject: RE: [Ntop] SSL timeout fix
> >
> >
> >
> >How about when releasing an SSL enabled product actually testing (just once
> >even) to see if the SSL support works in any fashion.
> >
> >I am having the exact same problem with:
> >
> >ntop v.2.0.99 MT (SSL) [i386-unknown-freebsd4.6.2] (09/28/02 06:03:30 AM
> >build)
> >
> >(not RC2, please note)
> >
> >Also, a review of usenet archives shows that this is not exactly a new
> >problem.
> >
> >So, since 2.0.99 is the version installed by the FreeBSD ports tree in the
> >latest version of FreeBSD (I cvsupped my ports tree mere days ago) could
> >someone tell us the fix to make SSL work and not get the timeout error ?
> >
> >thanks in advance!
> >
> >
> >
> > >
> > >How about trying the current versions (2.1.3 and 2.1.51)?
> > >
> > >2.0.99 RC2 is a six month old beta?
> > >
> > >-----Burton
> > >
> > >-----Original Message-----
> > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> > >Oliver Maul
> > >Sent: Sunday, October 06, 2002 1:42 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: [Ntop] SSL timeout fix
> > >
> > >
> > >Hi,
> > >
> > >I've installed 2.0.99-RC2 on a FreeBSD 4.6 and had
> > >troubles with https (openssl 0.9.6e). Every https
> > >request lead to a timeout response. It seems the
> > >select() in readHTTPheader() in http.c works not
> > >this way with SSL. So I changed the code, so that
> > >this select is used only for http requests. And it works
> > >fine now.
> > >
> > >
> > >Regards,
> > >Oliver
> > >
> > >
> > >--- work/RC2/ntop/http.c Mon Jun 3 08:39:37 2002
> > >+++ http.c Sun Oct 6 20:33:02 2002
> > >@@ -198,7 +198,8 @@
> > >
> > > /* select returns immediately */
> > > wait_time.tv_sec = 10; wait_time.tv_usec = 0;
> > >- if(select(myGlobals.newSock+1, &mask, 0, 0, &wait_time) == 0) {
> > >+ if(myGlobals.newSock > 0 &&
> > >+ (select(myGlobals.newSock+1, &mask, 0, 0, &wait_time) == 0)) {
> > > errorCode = HTTP_REQUEST_TIMEOUT; /* Timeout */
> > > #ifdef DEBUG
> > > traceEvent(TRACE_INFO, "Timeout while reading from socket.\n");
> > >
> > >
> > >_______________________________________________
> > >Ntop mailing list
> > >[EMAIL PROTECTED]
> > >http://lists.ntop.org/mailman/listinfo/ntop
> > >
> > >_______________________________________________
> > >Ntop mailing list
> > >[EMAIL PROTECTED]
> > >http://listgateway.unipi.it/mailman/listinfo/ntop
> >
> >
> >
> >
> >_________________________________________________________________
> >MSN Photos is the easiest way to share and print your photos:
> >http://photos.msn.com/support/worldwide.aspx
> >
> >_______________________________________________
> >Ntop mailing list
> >[EMAIL PROTECTED]
> >http://listgateway.unipi.it/mailman/listinfo/ntop
> >
> >_______________________________________________
> >Ntop mailing list
> >[EMAIL PROTECTED]
> >http://listgateway.unipi.it/mailman/listinfo/ntop
>
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop
>
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
