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 ?
{ntop just dies abruptly}
---------------------
I am performing tests on this now.... Just waiting for ntop to die ;) It
usually takes 6 hours to die....
I am trying your suggestions of trying to use tcpdump but things are stable
at the moment.
I'll feed you back results with kernel versions et al.
Shaf
----- Original Message -----
From: "Burton M. Strauss III" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, June 06, 2002 6:45 PM
Subject: RE: [Ntop] A reason for dying
> 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
>
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://lists.ntop.org/mailman/listinfo/ntop
