Just an FYI, the RealTek units have a bit of a rep as crap. Now that's not been my experience - I've used them without problems. But I do know that there were some ugly things WRT the drivers (see How this driver differs from the 2.4 "8139too.c" at http://www.scyld.com/network/rtl8139.html)...
"3 : Is anyone running ntop successfully with 2 or more NICs binded ?" - that may be the key. I've never heard of anyone using it with ntop (there's really no point - from ntop's perspective - you only bind interfaces to get more throughput), and frankly I have no clue how libpcap will present the data, but I have a guess or two... One is that ntop may be seeing the same packets from BOTH interfaces. The second is that the two (or more) interfaces bound together may retain their separate MAC addresses. This only matters on the local collision domain, but would affect the packets ntop sees originating from the firewall/ntop box and also those directed to it. A lot of ntop uses the MAC address, so you could well be causing problems deep inside... If you have access to that configuration, try the -j | --border-sniffer-mode switch - it suppresses much of that at the cost of degraded functionality. The only way to be sure would be to run tcpdump and capture some part of the stream into a file, then feed that into ntop. If you got lucky with a small file that crashes ntop, then we could figure it out. But even a small capture should show the packet doubling and the MAC addresses used, if those are even part of the problem. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Shaf Ali Sent: Thursday, June 06, 2002 1:24 PM To: [EMAIL PROTECTED] Subject: Re: [Ntop] A reason for dying Excellent - good pointers... Think we are a lot closer now. Production Machine {Reboot issue} --------------------- 1 : I never had any core dumps or kernel panics and there was nothing in syslog :( 2 : I just can't remember the config strip in detail but you may be right with respect to NIC drivers because if memory serves me right... when I cut the kernel back by removing unnessary stuff like sensors etc. I feel that I left ans.o in there which could have possibly caused the problems(reboot issue) I was having at that time with ntop and so I stopped ntop. Let me explain ans.o(Intel driver) is an ugly beast which performs adaptive load balancing over 2 or more nics by believe it or not broadcasting on the local subnet. A week later I stripped ans.o out also because it was broadcasting erratically and just used Intel's driver. 3 : Is anyone running ntop sucessfully with 2 or more NICs binded ? <snip /> Shaf _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
