well, it would be strange as FreeBSD use thread in kernel.i've not figured it was a thread about openbsd, so i just discover it. after few test with openbsd (3.5), i can only confirm many problems. seems compiling was only a small step, much stay to do (with threads at least)
Could well be that OpenBSD has the same userland threads as FreeBSD.
The only work-around we have for that is the -set-pcap-nonblock option (converts the select() operation to a poll). That is dependent upon a version of libpcap which offers the call - so you may have a dependency with the very latest (0.8.x has it, 0.7.2 MAY -
I don't remember).
well, there is some lag here ... as 3.5 has lipbcap 0.5 (last import from openbsd is 2.7; libpcap is in base system, not ports) i ask on misc@ why.
after the test discussed at the end of the mail, i try to compile with an extra libpcap (0.8.3) in /opt (setnonblock was detected by configure) but where libpcap is binded ? # ldd /export/tmp/ports-obj/ntop3-3.0/fake-i386/usr/local/bin/ntop |grep pcap # -> test ntop doesn't respond more
-> after a reboot # ntop -i xl0 -t 5 -M -m 192.168.2.0/24 --ipv4 --skip-version-check -u _ntop ntop doesn't respond # lsof|grep ntop|grep IPv ntop 21834 _ntop 11u IPv4 0xd0fbb2e8 0t0 TCP *:3000 (LISTEN)
-> with -set-pcap-nonblock, doesn't seem to help more
-> same as -u root respond but very slowly (telnet + firefox) after some time, seems it runs normally
Report created on Mon Apr 12 19:57:09 2004 [ntop uptime: 24:19] Generated by ntop v.3.0 SourceForge .tgz MT (SSL) [i386-unknown-openbsd3.5] Build: Apr 12 2004 19:06:39. Listening on [xl0] without a kernel (libpcap) filtering expression Web report active on interface xl0
-> retry as _ntop same here after ~15 sec, normal
(note also than it seems you have to way before rebooting ntop and the port is free again) -> another try with ssl # ntop -i xl0 -t 5 -M -m 192.168.2.0/24 --ipv4 --skip-version-check -u _ntop -w 0 -W 3000
Mon Apr 12 20:02:14 2004 [MSGID0986275] WEB: ntop's web server is now processing requests Mon Apr 12 20:02:14 2004 [MSGID0393976] THREADMGMT: pcap dispatch thread running... Mon Apr 12 20:02:16 2004 [MSGID0587829] **ERROR** SSL(ssl_init_connection)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:02:16 2004 [MSGID0587829] **ERROR** SSL(read)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:02:16 2004 [MSGID8807438] SECURITY: Loading items table Mon Apr 12 20:02:43 2004 [MSGID0587829] **ERROR** SSL(ssl_init_connection)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:02:43 2004 [MSGID0587829] **ERROR** SSL(read)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:02:43 2004 [MSGID0587829] **ERROR** SSL(ssl_init_connection)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:02:43 2004 [MSGID0587829] **ERROR** SSL(read)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:03:11 2004 [MSGID0587829] **ERROR** SSL(ssl_init_connection)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:03:11 2004 [MSGID0587829] **ERROR** SSL(read)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:03:54 2004 [MSGID0587829] **ERROR** SSL(ssl_init_connection)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400) Mon Apr 12 20:03:54 2004 [MSGID0587829] **ERROR** SSL(read)ERROR [Thread 23462]: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request at /usr/src/lib/libssl/ssl/../src/ssl/s23_srvr.c(400)
# lsof|grep ntop|grep IPv ntop 23462 _ntop 11u IPv4 0xd0fbb180 0t0 TCP *:3000 (LISTEN)
telnet connects but returns nothing $ telnet localhost 3000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.0 Connection closed by foreign host.
-> retry without ssl
slow response (telnet+firefox)
after 7 mins, it becomes normal
with some zombies
# ps ax|grep ntop|grep ZW|wc -l
11
and big cpu loadvery strange behavior
two problems: * Sun Apr 11 17:11:05 2004 [MSGID8837990] Loading plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' Sun Apr 11 17:11:05 2004 [MSGID0592890] **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Unable to resolve symbol] + double-check perms: ok $ file /usr/local/lib/ntop/plugins/icmpPlugin.so /usr/local/lib/ntop/plugins/icmpPlugin.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped what is the "symbol problem" ?
Not a clue - it's an OpenBSD message, just passed through ntop. I did post a smidge from a google search yesterday - might be relevant.
seems not a ldconfig issue, so how other thing are needed/loaded ? i've made a turn with ldd/objdump/nm and find nothing particular
* web server in all case, lsof report socket as LISTEN but telnet return conn refused with gdb, some responses for others (but very/slow/nothing under normal browser)
Yup - that's the select()/bpf problem.
this mealage seems to vary as after sending my last mail, i have ntop turning for 3 hours without a hitch as daemon or not (with libpcap 0.5) (ntop -i xl0 -t 5 -M -m 192.168.2.0/24 --ipv4 --skip-version-check -u _ntop -d)
Dropped (libpcap) 1.5% 14,114 Dropped (ntop) 0.0% 0 Total Received (ntop) 924,539 Total Packets Processed 924,539
Report created on Mon Apr 12 14:48:46 2004 [ntop uptime: 3:36:15] Generated by ntop v.3.0 SourceForge .tgz MT (SSL) [i386-unknown-openbsd3.5] Build: Apr 11 2004 19:22:43. Listening on [xl0] without a kernel (libpcap) filtering expression
but next when i try to play with -w/-W, i return on the problem ... don't know if it's a randow problem or a cleaning problem, or whatever else
Sounds like there may be more than a few missed tags for pre1. No real issue, IMHO, since I don't WANT people going back to a pre release w/o a really really good reason. In your case, the .tgz is available @ SourceForge (the full archives are available at http://osdn.dl.sourceforge.net/sourceforge/ntop - or pick any of the mirrors instead of osdn). So 3.0pre1 is at http://osdn.dl.sourceforge.net/sourceforge/ntop/ntop-3.0pre1.tgz.
ok, i've only check ntop sf project page where there is only 3.0.
else on the on the old zombie problem, could this be here ? http.c:19930 => wait() for parent ? when ntop was working, i quickly finish to sysctl limit of procs syslog: Apr 12 13:50:03 etenemanki /bsd: proc: table is full
$ ps ax|grep ntop|grep ZW| wc -l
413* i joined last port revision
so for now, at least, it doesn't seem the problem comes from libpcap but problem stays mostly unidentified and random ...
i will probably not have much time during week, so no big advance before next week-end.
Regards
Julien
note: request option for configure: --user/--group (so we could define the default user without extra options on run)(on openbsd policy is port user begin with '_')
ntop3-ob.tar.gz
Description: application/gzip
