>hmm is pbuf.c part of ntop or part of libpcap? i'm no expert on ntop's
>inner workings but it looks to me like this could be a faulty
>libpcap... perhaps try rebuilding libpcap from source on that box, and
>make sure that the ntop build uses that instead of.. whatever it is
>that it has now?
pbuf.c is part of Ntop's libs...It's possible libpcap is bad but....
I got the same results on Solaris 9 had to use the same LIBS line as Solaris 8
but I had to take it one step futher and hand edit the config.h becuase
HAVE_PCAP_OPEN_DEAD was not defined and it caused the make to fail (detect to
versions one in pcap.c and one in ntop's code....
Here's the GDB session from Solaris 9.....
12/Jun/2003 21:44:28 THREADMGMT: Started thread (6) for network packet
sniffing on hme0
12/Jun/2003 21:44:28 THREADMGMT: web connections thread (27423) started...
12/Jun/2003 21:44:28 THREADMGMT: pcap dispatch thread started...
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 2]
processIpPkt (bp=0x7ef79f66 "E", h=0x7ef7bf80, length=60, ether_src=0x4000
<Address 0x4000 out of bounds>,
ether_dst=0x7ef79f8e "", actualDeviceId=0, vlanId=20) at pbuf.c:902
902 u_char *tcp_data = (u_char *)((int)tcp + tcp->th_off * 4);
(gdb) backtrace
#0 processIpPkt (bp=0x7ef79f66 "E", h=0x7ef7bf80, length=60, ether_src=0x4000
<Address 0x4000 out of bounds>,
ether_dst=0x7ef79f8e "", actualDeviceId=0, vlanId=20) at pbuf.c:902
#1 0x7f826728 in processPacket (_deviceId=0x0, h=0x7ef7bf80, p=0x7ef79f58
"\b") at pbuf.c:2514
#2 0x7f8249ac in dequeuePacket (notUsed=0x7f86f120) at pbuf.c:1645
I'll poke at it again tomorrow.
--
Mike Tremaine
[EMAIL PROTECTED]
http://www.stellarcore.net
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
