I am thinking about it "logically" - all ntop does is use libpcap. So I just have a hard time blaming ntop - ntop-runs in user space. No kernel hooks, nothing, once it gives up privileges... Packet mangling can muck w/ the packet headers, but ntop doesn't do much with them. And even if it did, it wouldn't cause a segmentation fault, not a hardware reboot.
Until I finally rebuilt tigger just for development, I was running and developing ntop on my Linux firewall just fine. Never a single kernel crash. And if you think I wasn't filtering heavily, you're nuts. I wasn't doing any mangling (but lots in -t nat)... Even now, tigger is a RedHat 7.2 w/ custom kernel (I've listed is what's in my .config below) IMHO the most likely problem is the nic driver. That's (or bad memory/cpu) is the one place where data could be stuffed into erroneous places in memory and cause the computer to reset. Questions: What NICs are you using? You said you used a variety - were they all the same chipset (e.g. driver??) I'm using a Sis900 onboard and a 3C460B USB, I've also used LinkSys LNE100 and NetGear FA-311/310s. Also one of the RelTek 8139s... And various 3Coms at time (3C905 and 3C590 and 3C509). What version of the kernel were you running? I'm running 2.4.13, 2.4.17 and 2.4.18-uml (ur-tigger, used for the rpm builds). Was this an early 2.4, when there were kernel patches as part of it? When you stripped it, what were the switches you had set? Are you running anything from the Patch-o-matic sets? (Some of those are experimental and patch the kernel). How long does it run before rebooting? Does it reboot if you simply fire up tcpdump or ethereal or something else that uses libpcap and put's the nic into promiscuous mode?? -----Burton More stuff if anyone cares: First off, we need to be a little careful about terminology... (http://netfilter.samba.org/): "The netfilter/iptables project is the Linux 2.4.x / 2.5.x firewalling subsystem.It delivers you the functionality of packet filtering (stateless or stateful), all different kinds of NAT (Network Address Translation) and packet mangling. If you are running a recent Linux system (Kernel 2.4.x or above) on a router, you can use netfilter/iptables for all kinds of firewalling, NAT or other advanced packet processing. The major part of netfilter/iptables (doing all the hard work) is included in the standard Linux Kernel. In order to do your runtime configuration of the firewalling subsystem, you will need the iptables userspace command, which can be downloaded from here. Note that in most cases, the vendor of your Linux distribution (Debian, RedHat, SuSE, Conectiva, Mandrake, ...) will provide you with a pre-built version of this tool." So "netfilter" is the kernel part and "iptables" is a user-space program that manipulates the tables used by netfilter... OK so far? The usual ASCII art of packet flow through the kernel is at http://netfilter.samba.org/documentation/HOWTO//packet-filtering-HOWTO-6.htm l), but this one (http://netfilter.samba.org/documentation/HOWTO//netfilter-hacking-HOWTO-3.h tml#ss3.2) is better, because it shows mangle and nat: The hooks that are registered with netfilter are as follows (with the functions in each hook in the order that they are actually called): --->PRE------>[ROUTE]--->FWD---------->POST------> Conntrack | Mangle ^ Mangle Mangle | Filter | NAT (Src) NAT (Dst) | | Conntrack (QDisc) | [ROUTE] v | IN Filter OUT Conntrack | Conntrack ^ Mangle | Mangle | NAT (Dst) v | Filter What's not clear is whether turning on promiscuous mode bypasses this! In fact, it's sort of implied by the text: "On the left is where packets come in: having passed the simple sanity checks (i.e., not truncated, IP checksum OK, not a promiscuous receive), they are passed to the netfilter framework's NF_IP_PRE_ROUTING [1] hook." .config is: # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m # CONFIG_IP_NF_IRC is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m # CONFIG_IP_NF_MATCH_TCPMSS is not set CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_TCPMSS=m # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Shaf Ali Sent: Thursday, June 06, 2002 11:39 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop] A reason for dying > Shaf, > so who's fault? ntop, Linux or your machine? machine ? I have tested this on several machines with different/same NICs most definately ntop... ntop is not happy with pre-post routing packets which the kernel is managing. Think about it logically... ntop is not running at kernel level and if packets are being mangled in the kernel what will ntop think about it ? (Sorry I have not looked at the src for ntop in detail yet) If you can provide me with a link to the latest most stable version of ntop I will happily test it for you. I'll build kernel 2.4.18 with similar configs on seperate machines... I am sure that when I build a kernel with basic packet filtered ntop will fail. Shaf ----- Original Message ----- From: "Luca Deri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 06, 2002 5:15 PM Subject: Re: [Ntop] A reason for dying > Shaf, > so who's fault? ntop, Linux or your machine? > > Cheers, Luca > > > Shaf Ali wrote: > > That's the honest truth and I can prove it... > > > > Mind you I have deep concerns on the reaction of ntop if you're kernel is > > packet filtering.... > > Which is what my kernel is doing... > > > > I placed ntop on my production machine several months back which was also > > packet filetering and the results were a lot more serious.... Typically when > > the machine went live and the network packets started flowing - the machine > > rebooted ! SHEESH I rebuilt the kernel stripping everything out except > > iptables of course and again the same problem : REBOOT. > > > > Finally I removed ntop and we had stability. > > > > > > ----===================----- > > Shaf Ali [ ContentFusion.com ] > > ----===================----- > > [EMAIL PROTECTED] > > www.shaf.net > > > > > > > > > > ----- Original Message ----- > > From: "Devon Harding - GTHLA" <[EMAIL PROTECTED]> > > To: "'Shaf Ali'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Thursday, June 06, 2002 4:12 PM > > Subject: RE: [Ntop] A reason for dying > > > > > > > >>So you're saying that when you ran ntop with '-i' it dies? > >> > >>-Devon > >> > >>-----Original Message----- > >>From: Shaf Ali [mailto:[EMAIL PROTECTED]] > >>Sent: Thursday, June 06, 2002 11:09 AM > >>To: [EMAIL PROTECTED] > >>Cc: [EMAIL PROTECTED] > >>Subject: Re: [Ntop] A reason for dying > >> > >>I have had this problem... > >>And mailed the group...Not to add that I got a very UNHELPFUL and RUDE > >>response... If only the support was as great as ntop.... > >> > >>Anyway I realized that I had to use rc1 src but the problem re-occued.... > >> > >>Solved by : > >> > >>root gw:/etc/rc.d/init.d> cat network-monitor > >>#!/bin/sh > >> > >>/etc/rc.d/init.d/ntop-mySQLserver.pl & > >>##/usr/local/bin/ntop --mysql-host "ntop:ntop:ntop:localhost" -N -d -i > >>"eth0,eth1,eth2" -u nobody > >>## Multiple interfaces CRASH > >>/usr/local/bin/ntop --mysql-host "ntop:foo:bar:localhost" -d -u nobody > >> > >>Hope this helps you... > >> > >>----===================----- > >>Shaf Ali [ ContentFusion.com ] > >>----===================----- > >> [EMAIL PROTECTED] > >> www.shaf.net > >> > >>----- Original Message ----- > >>From: "Devon Harding - GTHLA" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Thursday, June 06, 2002 2:09 PM > >>Subject: [Ntop] A reason for dying > >> > >> > >> > >>>Does anyone know what are the MAIN reasons that ntop dies or seg. fault? > >>>Could it be too much traffic/bandwidth? Not enough memory/processor? > >> > >>Could > >> > >>>OS/Kernel have something to do with it? > >>> > >>>I'd like try a process of elimination to fix this. > >>> > >>>_____________________ > >>>Devon Harding > >>>System Administrator > >>>Gilat Latin America > >>>954-858-1600 > >>>[EMAIL PROTECTED] _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
