From netramet-owner Thu Apr 3 04:24:44 1997

From netramet-owner Thu Apr 3 04:24:44 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id DAA16018 for netramet-outgoing; Thu, 3 Apr 1997 03:37:28 +1200 (NZST)
Received: from csu-e.csuohio.edu (csu-e.csuohio.edu [137.148.49.12]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id DAA15938 for <[email protected]>; Thu, 3 Apr 1997 03:37:14 +1200 (NZST)
Received: from athena.csuohio.edu (athena.csuohio.edu [137.148.5.13]) by csu-e.csuohio.edu (8.6.12/8.6.12) with SMTP id KAA16582 for <[email protected]>; Wed, 2 Apr 1997 10:36:59 -0500
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 02 Apr 1997 10:36:59 -0500
To: [email protected]
From: "Matthew B. Thomson" <[email protected]>
Subject: Interpreting Flow Files
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email protected]
Precedence: bulk

Hi all.

I have successfully modified a sample rule set to collect the data we want,
but I am having great difficulty in using the data. What I want to do is
something that should seem to be very simple: I want to be able to list
total octets transmitted and received and by all subnets. How would I
write the fd_filter or fd_extract format files to do this?

Also, I would like to be able to break the subnet down into % by protocol
(Telnet, FTP, WWW, etc...).

Are these two things possible with fd_filter and fd_extract. If so, can
someone send me samples of format files that accomplish this?

Thanks much,
Matt
----------------------------------------------------------------
- Matthew B. Thomson -
- Network Support Specialist -

- Cleveland State University Information Services & Technology -
- [email protected] - 216-687-9217 - Fax 216-687-9200 -
----------------------------------------------------------------

From netramet-owner Thu Apr 3 12:53:15 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id MAA19561 for netramet-outgoing; Thu, 3 Apr 1997 12:48:23 +1200 (NZST)
Received: from ln.edu.hk (lnc.hk [202.40.192.240]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id MAA19447 for <[email protected]>; Thu, 3 Apr 1997 12:48:12 +1200 (NZST)
Message-Id: <[email protected]>
Received: from CSC_Tim.ln.edu.hk ([202.40.193.41]) by ln.edu.hk with SMTP
(1.39.111.2/16.2) id AA173278562; Thu, 3 Apr 1997 08:49:22 +0800
Date: Thu, 3 Apr 1997 08:49:22 +0800
X-Sender: [email protected]
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [email protected]
From: Timothy You <[email protected]>
Subject: Interpreting Flow Files
Sender: [email protected]
Precedence: bulk

Hi all,
>
>I have successfully modified a sample rule set to collect the data we want,
>but I am having great difficulty in using the data. What I want to do is
>something that should seem to be very simple: I want to be able to list
>total octets transmitted and received and by all subnets. How would I
>write the fd_filter or fd_extract format files to do this?
>
>Also, I would like to be able to break the subnet down into % by protocol
>(Telnet, FTP, WWW, etc...).
>
>Are these two things possible with fd_filter and fd_extract. If so, can
>someone send me samples of format files that accomplish this?
Please send me one as well as we are also doing the same thing.
Thanks for all your attention.

tim.ln.edu.hk

Best Regards
Tim

_________________________________________________________________________
Tim K.H.You Internet : [email protected],
Computer Services Centre
Lingnan College, Tuen Mun, Tel no. : (852) 26168418
NT, HONG KONG. Fax no. : (852) 25758763
__________________________________________________________________________

From netramet-owner Thu Apr 3 14:49:42 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id OAA13051 for netramet-outgoing; Thu, 3 Apr 1997 14:47:47 +1200 (NZST)
Received: from brolga.cc.uq.edu.au ([email protected] [130.102.128.5]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id OAA09215; Thu, 3 Apr 1997 14:29:16 +1200 (NZST)
Received: from brolga.cc.uq.edu.au ([email protected] [130.102.128.5])
by brolga.cc.uq.edu.au (8.8.5/8.8.5) with SMTP id MAA01531;
Thu, 3 Apr 1997 12:29:12 +1000 (EST)
Message-Id: <[email protected]>
X-Authentication-Warning: brolga.cc.uq.edu.au: [email protected] [130.102.128.5] didn't use HELO protocol
To: Nevil Brownlee <[email protected]>
Subject: Re: Security Considerations for RTFM Meters
cc: [email protected], [email protected]
In-reply-to: Your message of "Fri, 28 Mar 1997 09:59:34 +1200."
<[email protected]>
Date: Thu, 03 Apr 1997 12:29:11 +1000
From: David Vu <[email protected]>
Sender: [email protected]
Precedence: bulk

Nevil,

We have experienced this problem when performing host-based accounting
and what we do to prevent the meter running out of flows is to

1. increase the number of flows and
2. reduce the collection interval

so that the flows get collected and reused.

Given the memory is quite accessible these days, I would say that a simple
fix is to throw lots of memory at the meter, and increase the flow ID to a
32 bit quantity rather than a 16 bit quantity as it is now. A 16 bit flow ID only
covers one full class B network. From the user point of view, this would allow
a single meter to account for all possible IP addresses. Until IPv6 comes out :-)

Smarts can be introduced into the meter to detect this port scan attacks and send
an SNMP trap but in the end, the traffic still has to be attributed to individual hosts
IMHO.

Thanks,

David.

>>>> 2) Port Scan Attacks

In a port scan attack a remote user sends packets to all
possible IP addresses within a network. If an RTFM meter is
observing these packets and creating flows with full details
of soure/dest PeerAddresses, the meter will create new flows
for each of the port scan packets. This usually means it
will run out of flow memory and switch to Flood Mode.

The best way to guard against this is to put the meter behind
a firewall, so as to reduce the number of scan packets reaching
the meter. If this is not possible - perhaps because the meter
is being used to detect such attacks - then how should the
meter behave in the face of them?

From netramet-owner Thu Apr 3 19:38:06 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id TAA04367 for netramet-outgoing; Thu, 3 Apr 1997 19:30:45 +1200 (NZST)
Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.10]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id TAA04299 for <[email protected]>; Thu, 3 Apr 1997 19:30:30 +1200 (NZST)
Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id RAA18248 for <[email protected]>; Thu, 3 Apr 1997 17:29:48 +1000 (EST)
Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3)
id sma018179; Thu Apr 3 17:29:17 1997
Received: (from uucp@localhost) by mail_gw.fwall.telecom.com.au (8.8.2/8.6.9) id RAA09233 for <[email protected]>; Thu, 3 Apr 1997 17:28:47 +1000 (EST)
Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail-gw.fwall.telstra.com.au via smap (V1.3)
id sma009203; Thu Apr 3 17:28:41 1997
Received: from gandalf.dn.itg.telecom.com.au. (gandalf.dn.itg.telecom.com.au [144.136.188.222]) by cdn-mail.telecom.com.au (8.8.2/8.6.9) with ESMTP id RAA20880 for <[email protected]>; Thu, 3 Apr 1997 17:29:02 +1000 (EST)
Received: (from damian@localhost) by gandalf.dn.itg.telecom.com.au. (8.6.11/8.6.9) id DAA14032 for [email protected]; Fri, 4 Apr 1997 03:21:24 +1000
Date: Fri, 4 Apr 1997 03:21:24 +1000
From: Damian Eagle <[email protected]>
Message-Id: <[email protected].>
To: [email protected]
Subject: NeTraMet use on a busy FDDI ring.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: C5mjIx0yKSBXsPqcFDhQcA==
Sender: [email protected]
Precedence: bulk

Hello,

I am investigating the use of NeTraMet to
monitor traffic on FDDI rings within my company. The
aim is to be able to capacity manage traffic running
through the core of our network. We would like to be
able to get a breakdown by volume of traffic types (ie
FTP, TELNET, HTTP, IPX), record traffic volumes to a
particular address, and profile traffic of a
particular type (ie. histograms over time).

The core of our network is made up of a number
of regionalised FDDI rings. We operate a large network
and the traffic on the FDDI rings is often sustained at
6000-7000 packets/sec.

Recently we have investigated using FDDI
connected RMON probes from a number of vendors (Cisco,
3Com, HP) and found that none were able to properly
handle our traffic rate.

I'm now looking to NeTraMet to see what it can offer.

Does it sound suitable? Has anyone else used NeTraMet
in a similar environment?

I would prefer to use Sun Solaris. What size of
dedicated machine would I need to get to handle the
sustained 6000-7000 pkts/sec (ie. is an Ultra 1 with
170Mhz CPU likely to suffice)?

thanks in advance,

Damian Eagle.

Senior Network Specialist.
Corporate Data Network.
Telstra Australia.

From netramet-owner Thu Apr 3 22:15:24 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id WAA25972 for netramet-outgoing; Thu, 3 Apr 1997 22:11:57 +1200 (NZST)
Received: from casimir.easynet.fr (casimir.easynet.fr [194.51.27.235]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id WAA25896 for <[email protected]>; Thu, 3 Apr 1997 22:11:28 +1200 (NZST)
Received: (qmail 22453 invoked from network); 3 Apr 1997 10:11:56 -0000
Received: from casimir.easynet.fr (@194.51.27.235)
by casimir.easynet.fr with SMTP; 3 Apr 1997 10:11:56 -0000
Date: Thu, 3 Apr 1997 12:11:56 +0200 (MET DST)
From: David Ramahefason <[email protected]>
To: [email protected]
Subject: Need help :(
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

I've installed Netramet under FreeBSD and Linux, but got the same outputs:

[root@casimir|/usr/local/NeTraMet]-> ./NeMaC -c10 casimir public
NeMaC: NeTraMet Manager & Controller V3.3
Using MIB file: mib.txt
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

Couldn't get meter info from casimir!
Does community public have read or write access to the meter?
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

What did I miss ???
Thanks for answering

|David Ramahefason, [email protected],[email protected]|
|Administrateur Systeme/Reseau, Easynet France SA |
|Think different Think BSD http://www.FreeBSD.org |
|Wrap around probs with Python http://www.python.org |

From netramet-owner Fri Apr 4 17:18:08 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id RAA05230 for netramet-outgoing; Fri, 4 Apr 1997 17:00:23 +1200 (NZST)
Received: from ns.buptnet.edu.cn (ns.buptnet.edu.cn [202.112.10.37]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id QAA05000 for <[email protected]>; Fri, 4 Apr 1997 16:59:11 +1200 (NZST)
Received: from noya.bupt.edu.cn (noya.bupt.edu.cn [202.112.96.2])
by ns.buptnet.edu.cn (8.8.4/8.8.4) with SMTP
id MAA01468 for <[email protected]>; Fri, 4 Apr 1997 12:58:33 +0800 (CST)
Received: from cct.bupt.edu.cn ([202.112.10.134]) by noya.bupt.edu.cn (5.x/SMI-SVR4)
id AA04429; Fri, 4 Apr 1997 12:58:43 +0800
Message-Id: <[email protected]>
Date: Fri, 04 Apr 1997 12:56:55 +0800
From: ccstu <[email protected]>
Reply-To: [email protected]
Organization: bupt
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: [email protected]
Subject: Computer Center
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

hello,

I am an engineer of computer center of Beijing University Posts and
Telecommunications.
Now ,I have got a NeTraMet 3.4 .But I don't know how to compile it
and Install it on my RS6000(AIX 4.x) server.
Please help me...
my email :[email protected]
fax:086-010-62283044

From netramet-owner Fri Apr 4 22:09:57 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id WAA22801 for netramet-outgoing; Fri, 4 Apr 1997 22:03:47 +1200 (NZST)
Received: from casimir.easynet.fr (casimir.easynet.fr [194.51.27.235]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id WAA22740 for <[email protected]>; Fri, 4 Apr 1997 22:03:38 +1200 (NZST)
Received: (qmail 20035 invoked from network); 4 Apr 1997 10:03:52 -0000
Received: from casimir.easynet.fr (@194.51.27.235)
by casimir.easynet.fr with SMTP; 4 Apr 1997 10:03:52 -0000
Date: Fri, 4 Apr 1997 12:03:52 +0200 (MET DST)
From: David Ramahefason <[email protected]>
To: [email protected]
cc: [email protected]
Subject: NeTramet Don't understand how to make it works !!
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

I've reinstalled all the stuff under my FreeBSD box, and it doesn't change
anything :((

Here's an output:

[root@casimir|/usr/local/src/Netra/linux/bin]-> ./nm_rc -c 10 -h 20 -g 11
194.51.27.222 public
nm_rc: Remote Console for NeTraMet: V3.3
Using MIB file: mib.txt
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

Warning: meter 194.51.27.222 (version 0.0) not same as nm_rc!
Community public doesn't have write access to meter 194.51.27.222!
Collections won't trigger recovery of idle flows <<<
#Format: firsttime topdus frompdus tooctets fromoctets sourcepeertype
sourcepeeraddress destpeeraddress sourcetranstype sourcetransaddress
desttransaddress
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

#--- 194.51.27.222 0 flows 0pps 0Bps 11:59:38 Fri 4 Apr 97 ---
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

#--- 194.51.27.222 0 flows 0pps 0Bps 11:59:40 Fri 4 Apr 97 ---
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

#--- 194.51.27.222 0 flows 0pps 0Bps 11:59:50 Fri 4 Apr 97 ---
Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

#--- 194.51.27.222 0 flows 0pps 0Bps 12:00:00 Fri 4 Apr 97 ---

Could someone tell me why it doen't work ??? and why do I have the error:

Error in packet, reason = There is no such variable name in this MIB.
This name does not exist:
iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

?????

Please help :( I need this tool working for soon....
ps: are there some FAQ/Docs/Examples somewhere ??? cause the one given
with the distrib are quite hard to understand for a rookie :(

Thanks for answering

|David Ramahefason, [email protected],[email protected]|
|Administrateur Systeme/Reseau, Easynet France SA |
|Think different Think BSD http://www.FreeBSD.org |
|Wrap around probs with Python http://www.python.org |

From netramet-owner Sat Apr 5 00:10:34 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id AAA08406 for netramet-outgoing; Sat, 5 Apr 1997 00:06:47 +1200 (NZST)
Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id AAA07656 for <[email protected]>; Sat, 5 Apr 1997 00:00:46 +1200 (NZST)
Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.3/8.7.3) with SMTP id NAA14355; Fri, 4 Apr 1997 13:58:44 +0200 (MET DST)
Date: Fri, 4 Apr 1997 13:58:37 +0200 (MET DST)
From: Andrzej Bialecki <[email protected]>
To: David Ramahefason <[email protected]>
cc: [email protected]
Subject: Re: NeTramet Don't understand how to make it works !!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

On Fri, 4 Apr 1997, David Ramahefason wrote:

>
>
> I've reinstalled all the stuff under my FreeBSD box, and it doesn't change
> anything :((

First of all: let me encourage you. I run this package on a FreeBSD
box, so it can be done :-)

I compiled the whole stuff using Makefiles for Linux.

> Using MIB file: mib.txt
> Error in packet, reason = There is no such variable name in this MIB.
> This name does not exist:
> .iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0

This looks to me like it's the wrong mib file to the wrong snmp agent. It
could be that you already had some mibs hanging around (guessing...). Try
to set env variable to make sure you're getting the right one (i.e.
mib.txt taken from mib/mib.txt under the dist tree)

>
> Warning: meter 194.51.27.222 (version 0.0) not same as nm_rc!

Guessing again: one of possible reasons could be that the remote machine
runs an snmp daemon which answers queries to the SNMP_PORT. Obviously, it
would implement quite different mib tree, hence the warnings. I notice
also the weird version number - something is really wrong with that snmp
guy at the other end!

Hey, gotcha!!!!! I just checked with "snmpwalk" proggy your machine.
Indeed, you're already running an SNMP agent, and of course it's
incompatible with Netramet accounting MIB! You have to kill it and start
the NetraMet agent on that machine, THEN try to collect data with NeMaC or
nm_rc.

BTW. Leaving your snmp agent with community "public" is generally The Bad
Thing (tm) to do. It allows to gather many sensitive informations
unknowingly to you.

Here are the results of my probe :-)

----------------------------------- cut --------------------------------

baby:/cmu/apps% ./snmpwalk -v 1 194.51.27.222 public
iso.org.dod.internet.mgmt.mib.system.sysDescr.0 = "Linux version 2.0.29
(root@golem) (gcc version 2.7.2) #1 Thu Apr 3 12:48:17 MET DST 1997"
iso.org.dod.internet.mgmt.mib.system.sysObjectID.0 = OID:
enterprises.1575.1.5
iso..org.dod.internet.mgmt.mib.system.sysUpTime.0 = Timeticks: (8958112) 1
day, 0:53:01
iso.org.dod.internet.mgmt.mib.system.4.0 = "Kaept'n Koerg"
iso.org.dod.internet.mgmt.mib.system.5.0 = "golem"
iso.org.dod.internet.mgmt.mib.system.6.0 = "Outer Regions"
iso.org.dod.internet.mgmt.mib.system.7.0 = 72
iso.org.dod.internet.mgmt.mib.system.8.0 = Timeticks: (8959424) 1 day,
0:53:14
iso.org.dod.internet.mgmt.mib.system.9.1.2.1 = OID:
enterprises.1575.1.5.1.1
iso.org.dod.internet.mgmt.mib.system.9.1.3.1 = "LINUX agent"
iso.org.dod.internet.mgmt.mib.system.9.1.4.1 = Timeticks: (8960253) 1
day, 0:53:22
iso.org.dod.internet.mgmt.mib.interfaces.ifNumber.0 = 2
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifIndex.1 = 1
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifIndex.2 = 2
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifDescr.1 =
"lo0" Hex: 6C 6F 30
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifDescr.2 =
"eth0" Hex: 65 74 68 30
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifType.1 = 24
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifType.2 =
ethernet-csmacd(6)
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifMtu.1 = 3584
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifMtu.2 = 1500
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifSpeed.1 =
Gauge: 20000000
iso.org.dod.internet.mgmt.mib.interfaces.ifTable.ifEntry.ifSpeed.2 =
Gauge: 10000000
^C
baby:/cmu/apps%

----------------------------------- cut --------------------------------

Sincerely yours,

---
Andrzej Bialecki FreeBSD: Turning PCs Into Workstations
<[email protected]> http://www.freebsd.org
Research and Academic Network in Poland

From netramet-owner Sat Apr 5 00:15:53 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id AAA09526 for netramet-outgoing; Sat, 5 Apr 1997 00:15:16 +1200 (NZST)
Received: from casimir.easynet.fr (casimir.easynet.fr [194.51.27.235]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id AAA09462 for <[email protected]>; Sat, 5 Apr 1997 00:15:05 +1200 (NZST)
Received: (qmail 26282 invoked from network); 4 Apr 1997 12:15:34 -0000
Received: from casimir.easynet.fr (@194.51.27.235)
by casimir.easynet.fr with SMTP; 4 Apr 1997 12:15:34 -0000
Date: Fri, 4 Apr 1997 14:15:34 +0200 (MET DST)
From: David Ramahefason <[email protected]>
To: Andrzej Bialecki <[email protected]>
cc: [email protected]
Subject: Re: NeTramet Don't understand how to make it works !!
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 4 Apr 1997, Andrzej Bialecki wrote:

> First of all: let me encourage you. I run this package on a FreeBSD
> box, so it can be done :-)

Cool :))

>
> I compiled the whole stuff using Makefiles for Linux.
>

That's what I did also, with some patches to files

> > Using MIB file: mib.txt
> > Error in packet, reason = There is no such variable name in this MIB.
> > This name does not exist:
> > .iso.org.dod.internet.mgmt.mib.acctMIB.acctControl.acctLastCollectTime.0
>
> This looks to me like it's the wrong mib file to the wrong snmp agent. It
> could be that you already had some mibs hanging around (guessing...). Try
> to set env variable to make sure you're getting the right one (i.e.
> mib.txt taken from mib/mib.txt under the dist tree)
>

Is export MIBFILE=/usr/local/NeTraMet/mib.txt good ??

> >
> > Warning: meter 194.51.27.222 (version 0.0) not same as nm_rc!
>
> Guessing again: one of possible reasons could be that the remote machine
> runs an snmp daemon which answers queries to the SNMP_PORT. Obviously, it
> would implement quite different mib tree, hence the warnings. I notice
> also the weird version number - something is really wrong with that snmp
> guy at the other end!

You mean I need a NeTraMet running on client machines ????

>
>
> Hey, gotcha!!!!! I just checked with "snmpwalk" proggy your machine.
> Indeed, you're already running an SNMP agent, and of course it's
> incompatible with Netramet accounting MIB! You have to kill it and start
> the NetraMet agent on that machine, THEN try to collect data with NeMaC or
> nm_rc.

Then that mean I need an NeTraMet on the client host..... but the prob is when I try on my box (launching NeTraMet and
then issueing a nm_rc.... that's what I've got:

[root@casimir|/usr/local/NeTraMet]-> ./nm_rc -c10 -i10 -h20 casimir public
nm_rc: Remote Console for NeTraMet: V3.4
Using MIB file: mib.txt
Couldn't get meter info from casimir!
Does community public have read or write access to the meter?
No meters to monitor !!!

Thanks for answering

|David Ramahefason, [email protected],[email protected]|
|Administrateur Systeme/Reseau, Easynet France SA |
|Think different Think BSD http://www.FreeBSD.org |
|Wrap around probs with Python http://www.python.org |

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBM0TwjmOnL3WiJ8ItAQH3SgP9EFKCSBovs1a/Hn/q0UPZAXDML59eDW3A
/Rf7VdMptGa6/HxORAirm1J9/oVr09PJIOKOWQu3KyA3kM1lnxDcn5/TvjZMrEZN
YyOpTPgfK58nkiN6jSxp3bu/WyNPPt/TvlMXkQXWgTdvEvny+k/TAJ839J96+p5x
/uGJICX+1+Q=
=990G
-----END PGP SIGNATURE-----

From netramet-owner Sat Apr 5 01:22:16 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id BAA17722 for netramet-outgoing; Sat, 5 Apr 1997 01:19:11 +1200 (NZST)
Received: from obelix.tele.net (obelix.tele.net [194.183.128.34]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id BAA17706 for <[email protected]>; Sat, 5 Apr 1997 01:18:56 +1200 (NZST)
Received: from ws253.teleport.vol.at (ws253.teleport.vol.at [194.208.20.253]) by obelix.tele.net (8.7.3/8.7.3) with SMTP id PAA25188 for <[email protected]>; Fri, 4 Apr 1997 15:18:38 +0200 (MET DST)
Received: by ws253.teleport.vol.at with Microsoft Mail
id <[email protected]>; Fri, 4 Apr 1997 15:18:15 +0200
Message-ID: <[email protected]>
From: "Eugen A. Russ" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Unsubscibe netramet
Date: Fri, 4 Apr 1997 15:19:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Unsubscibe netramet

From netramet-owner Mon Apr 7 23:45:12 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id XAA23721 for netramet-outgoing; Mon, 7 Apr 1997 23:23:40 +1200 (NZST)
Received: from nosc.ja.net (nosc.ja.net [128.86.16.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id XAA23502 for <[email protected]>; Mon, 7 Apr 1997 23:21:54 +1200 (NZST)
Received: from nosc.ja.net by nosc.ja.net with Internet SMTP
id <[email protected]>; Mon, 7 Apr 1997 11:53:32 +0100
To: Damian Eagle <[email protected]>
cc: [email protected]
Subject: Re: NeTraMet use on a busy FDDI ring.
In-reply-to: Your message of "Fri, 04 Apr 1997 03:21:24 +1000." <[email protected].>
Date: Mon, 07 Apr 1997 11:53:18 +0100
Message-ID: <[email protected]>
From: Kevin Hoadley <[email protected]>
Sender: [email protected]
Precedence: bulk

> The core of our network is made up of a number
> of regionalised FDDI rings. We operate a large network
> and the traffic on the FDDI rings is often sustained at
> 6000-7000 packets/sec.
>
> I'm now looking to NeTraMet to see what it can offer.
>
> Does it sound suitable? Has anyone else used NeTraMet
> in a similar environment?

We use NeTraMet to monitor most of the international links out of JANET
(the UK's national academic network). We have monitors running on both fast
ethernet and FDDI, including one monitoring an FDDI ring with a working hours
sustained load around 6000-8000 packet/sec. So yes, we're running NeTraMet
in a similar enviroment.

> I would prefer to use Sun Solaris. What size of
> dedicated machine would I need to get to handle the
> sustained 6000-7000 pkts/sec (ie. is an Ultra 1 with
> 170Mhz CPU likely to suffice)?

We use Pentium P200's running FreeBSD, with a fairly complicated rule set
running to nearly 1000 rules. To keep up with the volume of traffic we
have to configure NeTraMet to sample one packet in eight.

We've considered using DEC Alpha's, but one of our goals was to have a small
and inexpensive package which could be widely deployed around the network,
hence the Pentiums.

Kevin Hoadley, UKERNA.

From netramet-owner Tue Apr 8 03:22:38 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id DAA24601 for netramet-outgoing; Tue, 8 Apr 1997 03:17:17 +1200 (NZST)
Received: from csu-e.csuohio.edu (csu-e.csuohio.edu [137.148.5.27]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id DAA24582 for <[email protected]>; Tue, 8 Apr 1997 03:17:14 +1200 (NZST)
Received: from athena.csuohio.edu (athena.csuohio.edu [137.148.5.13]) by csu-e.csuohio.edu (8.6.12/8.6.12) with SMTP id LAA00631 for <[email protected]>; Mon, 7 Apr 1997 11:17:06 -0400
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 07 Apr 1997 11:17:06 -0400
To: [email protected]
From: "Matthew B. Thomson" <[email protected]>
Subject: FTP data counting
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email protected]
Precedence: bulk

It would appear that when I use Netscape to FTP, the data does not get
counted with FTPdata, if I use a a normal FTP client, it gets counted
correctly. Has anyone seen this, and have a solution?

Thanks,
Matt
----------------------------------------------------------------
- Matthew B. Thomson -
- Network Support Specialist -

- Cleveland State University Information Services & Technology -
- [email protected] - 216-687-9217 - Fax 216-687-9200 -
----------------------------------------------------------------

From netramet-owner Tue Apr 8 04:41:29 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id EAA05659 for netramet-outgoing; Tue, 8 Apr 1997 04:37:31 +1200 (NZST)
Received: from nosc.ja.net (nosc.ja.net [128.86.16.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id EAA05651 for <[email protected]>; Tue, 8 Apr 1997 04:37:14 +1200 (NZST)
Received: from nosc.ja.net by nosc.ja.net with Internet SMTP
id <[email protected]>; Mon, 7 Apr 1997 17:33:50 +0100
To: "Matthew B. Thomson" <[email protected]>
cc: [email protected]
Subject: Re: FTP data counting
In-reply-to: Your message of "Mon, 07 Apr 1997 11:17:06 EDT." <[email protected]>
Date: Mon, 07 Apr 1997 17:33:49 +0100
Message-ID: <[email protected]>
From: Kevin Hoadley <[email protected]>
Sender: [email protected]
Precedence: bulk

> It would appear that when I use Netscape to FTP, the data does not get
> counted with FTPdata, if I use a a normal FTP client, it gets counted
> correctly. Has anyone seen this, and have a solution?

Netscape tries to use passive FTP, which means although the FTP control
connection will be counted correctly, the actually data transferred will
be on an unknown port number and won't use the normal FTP-data port.

I've never had need to turn off passive FTP in Netscape, so I don't know
if it can be done.

Kevin Hoadley, JANET.

From netramet-owner Tue Apr 8 05:11:28 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id FAA09701 for netramet-outgoing; Tue, 8 Apr 1997 05:07:38 +1200 (NZST)
Received: from papaioea.manawatu.gen.nz ([email protected] [202.36.148.67]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id FAA09696 for <[email protected]>; Tue, 8 Apr 1997 05:07:36 +1200 (NZST)
Received: from papaioea.manawatu.gen.nz ([email protected] [202.36.148.67]) by papaioea.manawatu.gen.nz (8.6.12/8.6.12) with SMTP id EAA23807; Tue, 8 Apr 1997 04:55:50 +1200
Date: Tue, 8 Apr 1997 04:55:05 +1200 (NZST)
From: Alan Brown <[email protected]>
To: "Matthew B. Thomson" <[email protected]>
cc: [email protected]
Subject: Re: FTP data counting
In-Reply-To: <[email protected]>
Message-ID: <Pine.SUN.3.90.970408042919.2504c-100000-100000-100000@papaioea.manawatu.gen.nz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

On Mon, 7 Apr 1997, Matthew B. Thomson wrote:

> It would appear that when I use Netscape to FTP, the data does not get
> counted with FTPdata, if I use a a normal FTP client, it gets counted
> correctly. Has anyone seen this, and have a solution?

Turn off the proxy settings.

AB

From netramet-owner Tue Apr 8 09:22:50 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id JAA19000 for netramet-outgoing; Tue, 8 Apr 1997 09:17:19 +1200 (NZST)
Received: from jeff.med.iacnet.com (jeff.med.iacnet.com [140.244.8.125]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id JAA18992 for <[email protected]>; Tue, 8 Apr 1997 09:17:15 +1200 (NZST)
Received: from jeff.med.iacnet.com (localhost [127.0.0.1])
by jeff.med.iacnet.com (8.8.5/8.8.5) with SMTP id RAA01427
for <[email protected]>; Mon, 7 Apr 1997 17:06:48 -0400
Message-ID: <[email protected]>
Date: Mon, 07 Apr 1997 17:06:48 -0400
From: Jeff Macdonald <[email protected]>
Organization: Information Access Center
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: [email protected]
Subject: Linux Redhat 4.1 and Netramet
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,
I've just compiled the netramet package, with libpcap 0.3. It compiles
file. However, when running the meter, I get a segmentation fault. I
made up the snmp names. At this point in time I'm just trying to get it
to run.

[root@jeff meter]# ./NeTraMet -k -r jeff -w netramet
NeTraMet: Network Traffic Meter V3.4
Running on jeff.med.iacnet.com, interface eth0
Segmentation fault (core dumped)

Here are my system details:

[root@jeff meter]# uname -a
Linux jeff.med.iacnet.com 2.0.29 #3 Thu Feb 27 16:49:12 EST 1997 i586

[root@jeff meter]# ldd NeTraMet
libc.so.5 => /lib/libc.so.5.3.12

The same thing happens with the precompiled binaries. Anyone get this
working?

--
Jeff Macdonald
Systems Development
Information Access Center
Medford, MA 02155

From netramet-owner Tue Apr 8 13:55:08 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id NAA17755 for netramet-outgoing; Tue, 8 Apr 1997 13:49:39 +1200 (NZST)
Received: from avarice.nepean.uws.edu.au ([email protected] [137.154.210.11]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id NAA17709 for <[email protected]>; Tue, 8 Apr 1997 13:49:29 +1200 (NZST)
Received: from localhost (david@localhost)
by avarice.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id LAA31019;
Tue, 8 Apr 1997 11:49:09 +1000
Date: Tue, 8 Apr 1997 11:49:09 +1000 (EST)
From: David J N Begley <[email protected]>
Reply-To: David J N Begley <[email protected]>
To: Jeff Macdonald <[email protected]>
cc: [email protected]
Subject: Re: Linux Redhat 4.1 and Netramet
In-Reply-To: <[email protected]>
Message-ID: <Pine.LNX.3.96.970408114113.30916B-100000@avarice.nepean.uws.edu.au>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

On Mon, 7 Apr 1997, Jeff Macdonald wrote:

> I've just compiled the netramet package, with libpcap 0.3. It compiles
> file. However, when running the meter, I get a segmentation fault. I
> made up the snmp names. At this point in time I'm just trying to get it
> to run.

I don't have too much joy for you, only hope. I've got NeTraMet 3.4 with
libpcap 0.3 running on a Slackware '96 (3.1.0) based system .. certainly
not "well" (as it freezes after a period of time and doesn't talk to NeMaC
anymore), but not segfaulting, either. Like you, I've also made up my
SNMP community names.

> [root@jeff meter]# ./NeTraMet -k -r jeff -w netramet

/NeTraMet -w foo -r bar -k -s -i eth0

"eth0" is an ISA-based 3Com EtherLink III (3C509B). The machine also has
"eth1" (Intel EtherExpress 16, ISA-based), used for getting in/out of the
machine ("eth0" is left to do promiscuous work).

> [root@jeff meter]# uname -a
> Linux jeff.med.iacnet.com 2.0.29 #3 Thu Feb 27 16:49:12 EST 1997 i586

Linux wrath 2.0.29 #1 Wed Feb 12 15:08:23 EST 1997 i386

> [root@jeff meter]# ldd NeTraMet
> libc.so.5 => /lib/libc.so.5.3.12

libc.so.5 => /lib/libc.so.5.2.18

Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs
gcc version 2.7.2

(ie., I'm not using 2.7.2.1)

> The same thing happens with the precompiled binaries. Anyone get this
> working?

Anyone know why mine freezes? ;-)

dave

From netramet-owner Wed Apr 9 02:31:15 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id CAA18510 for netramet-outgoing; Wed, 9 Apr 1997 02:14:12 +1200 (NZST)
Received: from noc.belwue.de ([email protected] [129.143.2.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id CAA18501 for <[email protected]>; Wed, 9 Apr 1997 02:14:08 +1200 (NZST)
Received: from tunix.mathematik.uni-stuttgart.de (tunix.mathematik.uni-stuttgart.de [129.69.116.156])
by noc.belwue.de (8.8.5/8.8.5) with SMTP id QAA27901;
Tue, 8 Apr 1997 16:14:03 +0200 (MET DST)
Received: by tunix.mathematik.uni-stuttgart.de (AIX 3.2/UCB 5.64/BelWue-1.0AIXRS)
id AA20166; Tue, 8 Apr 1997 16:13:33 +0200
From: [email protected] (Frieder Loeffler)
Message-Id: <[email protected]>
Subject: Re: Linux Redhat 4.1 and Netramet
To: [email protected] (Jeff Macdonald)
Date: Tue, 8 Apr 1997 16:13:33 +0200 (MSZ)
Cc: [email protected]
In-Reply-To: <[email protected]> from "Jeff Macdonald" at Apr 7, 97 05:06:48 pm
X-Mailer: ELM [version 2.4 PL25 PGP6]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,

Jeff Macdonald wrote:
> [root@jeff meter]# ./NeTraMet -k -r jeff -w netramet
> NeTraMet: Network Traffic Meter V3.4
> Running on jeff.med.iacnet.com, interface eth0
> Segmentation fault (core dumped)

On my Linux, it works:

[root@ksoc3mon2 meter]# ./NeTraMet -k -r jeff -w netramet
NeTraMet: Network Traffic Meter V3.4
Running on ksoc3mon2.rus.uni-stuttgart.de, interface eth0

System Information:

> [root@jeff meter]# uname -a
> Linux jeff.med.iacnet.com 2.0.29 #3 Thu Feb 27 16:49:12 EST 1997 i586

[root@ksoc3mon2 meter]# uname -a
Linux ksoc3mon2.rus.uni-stuttgart.de 2.0.28 #2 Tue Feb 4 18:53:01 MET 1997 i586

> [root@jeff meter]# ldd NeTraMet
> libc.so.5 => /lib/libc.so.5.3.12

[root@ksoc3mon2 meter]# ldd NeTraMet
libc.so.5 => /lib/libc.so.5.4.23

I've got no idea why you experience those problems. Could you try
"strace ./NeTraMet"? - This should give you a hint on which system call
failed...

Cheers,
Siegfried
--
Siegfried Loeffler, DG1SEK, Moehringer Str. 96, 70199 Stuttgart, Germany
Phone: +49-711-6074762 Fax: +49-711-6074763 Mobile: +49-172-9021563
http://www.mathematik.uni-stuttgart.de/~floeff
NEW: Watch me "working": http://ksoc3mon2.rus.uni-stuttgart.de/qcam.html

From netramet-owner Wed Apr 9 02:31:18 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id CAA19486 for netramet-outgoing; Wed, 9 Apr 1997 02:21:55 +1200 (NZST)
Received: from la.ducksfeet.com (la.ducksfeet.com [206.55.129.222]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id CAA19465 for <[email protected]>; Wed, 9 Apr 1997 02:21:45 +1200 (NZST)
Received: from zippy (zippy.ducksfeet.com [206.151.149.10]) by la.ducksfeet.com (8.8.4/8.7.1) with SMTP id HAA08889 for <[email protected]>; Tue, 8 Apr 1997 07:19:34 -0700
Received: by zippy with Microsoft Mail
id <01BC43ED.07CB37C0@zippy>; Tue, 8 Apr 1997 07:18:17 -0700
Message-ID: <01BC43ED.07CB37C0@zippy>
From: Steve Resnick <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Docs?
Date: Tue, 8 Apr 1997 07:18:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

I am looking for docs for NeTraMet in some other form than postscript.
The 3.1 docs under ghostscript showed up as one page, and the 3.4 docs, although
they showed 34 pages under ghostscript, would not print on my printer after churning for some 45 minutes on a 120MHz pentium.

I noticed from ghostscript the .ps files were generated with MS Word. Is this format available at all?

Thanks, in advance,

Steve Resnick

---
Steve Resnick -- [email protected] -- http://www.ducksfeet.com/steve
0x2b ~| 0x2b -- What was the question?

From netramet-owner Wed Apr 9 03:47:20 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id DAA00532 for netramet-outgoing; Wed, 9 Apr 1997 03:44:02 +1200 (NZST)
Received: from csu-e.csuohio.edu (csu-e.csuohio.edu [137.148.5.27]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id DAA00522 for <[email protected]>; Wed, 9 Apr 1997 03:43:58 +1200 (NZST)
Received: from athena.csuohio.edu (athena.csuohio.edu [137.148.5.13]) by csu-e.csuohio.edu (8.6.12/8.6.12) with SMTP id LAA21651 for <[email protected]>; Tue, 8 Apr 1997 11:43:51 -0400
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 08 Apr 1997 11:43:51 -0400
To: [email protected]
From: "Matthew B. Thomson" <[email protected]>
Subject: rules help
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email protected]
Precedence: bulk

Hello all. I have this rule file, listed below. It works if the port is
defined in the rule set, but I also want to count those packets that do not
match to a port (DestTransAddress). Can someone tell me where my mistake
is? I'm sure the rule file could be better, so if anyone feels like
tweaking, by all means! I think it's pretty self explanatory as far as
what I'm trying to do.

Thanks for all your help!

Matt

#
SET 2
#
RULES
SourcePeerType & 255 = IP: PushTo, IP_pkt;
SourcePeerType & 255 = dummy: Ignore, 0;
Null & 0 = 0: GoToAct, Next;
Null & 0 = 0: Ignore, 0;
#
IP_pkt:
SourceTransType & 255 = tcp: PushTo, TCP_UDP;
SourceTransType & 255 = udp: PushTo, TCP_UDP;
Null & 0 = 0: GoToAct, Next;
Null & 0 = 0: Ignore, 0;
#
TCP_UDP:
#
t_FTP: # 21
DestTransAddress & 255.255 = ftp: PushToAct, CountThis;
SourceTransAddress & 255.255 = ftp: Retry, 0;
t_FTPdata: #
DestTransAddress & 255.255 = ftpdata: PushToAct, CountThis;
SourceTransAddress & 255.255 = ftpdata: Retry, 0;
t_Telnet: # 23
DestTransAddress & 255.255 = telnet: PushToAct, CountThis;
SourceTransAddress & 255.255 = telnet: Retry, 0;
t_SMTP: # 25
DestTransAddress & 255.255 = smtp: PushToAct, CountThis;
SourceTransAddress & 255.255 = smtp: Retry, 0;
t_Domain: # 53
DestTransAddress & 255.255 = domain: PushToAct, CountThis;
SourceTransAddress & 255.255 = domain: Retry, 0;
t_Web: # 80
DestTransAddress & 255.255 = www: PushToAct, CountThis;
SourceTransAddress & 255.255 = www: Retry, 0;
t_POP: # 110
DestTransAddress & 255.255 = 110: PushToAct, CountThis;
SourceTransAddress & 255.255 = 110: Retry, 0;
t_NNTP: # 119
DestTransAddress & 255.255 = nntp: PushToAct, CountThis;
SourceTransAddress & 255.255 = nntp: Retry, 0;
t_Routing: # 520
DestTransAddress & 255.255 = rip: PushToAct, CountThis;
SourceTransAddress & 255.255 = rip: Retry, 0;
t_Mystery: # Other
DestTransAddress & 255.255 = 0: PushToAct, CountThis;
SourceTransAddress & 255.255 = 0: PushToAct, CountThis;
#
Null & 0 = 0: GoToAct, Next;
Null & 0 = 0: Ignore, 0;
Null & 0 = 0: GoToAct, IgnoreThis;
#
CountThis:
SourcePeerAddress & 255.255.255.255 =0: PushPktToAct, Next;
DestPeerAddress & 255.255.255.255 = 0: PushPktToAct, Next;
DestTransAddress & 255.255 = 0: PushPktToAct, Next;
SourceTransAddress & 255.255 = 0: CountPkt, 0;
IgnoreThis:
Null & 0 = 0: Ignore, 0;
#
FORMAT
FlowRuleSet FlowIndex FirstTime
SourcePeerType SourceTransType
SourceTransAddress DestTransAddress
SourcePeerAddress DestPeerAddress
ToPDUs FromPDUs ToOctets FromOctets;
#
STATISTICS
#

----------------------------------------------------------------
- Matthew B. Thomson -
- Network Support Specialist -

- Cleveland State University Information Services & Technology -
- [email protected] - 216-687-9217 - Fax 216-687-9200 -
----------------------------------------------------------------

From netramet-owner Wed Apr 9 07:15:21 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id HAA28216 for netramet-outgoing; Wed, 9 Apr 1997 07:11:29 +1200 (NZST)
Received: from jeff.med.iacnet.com (jeff.med.iacnet.com [140.244.8.125]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id HAA28209 for <[email protected]>; Wed, 9 Apr 1997 07:11:25 +1200 (NZST)
Received: from jeff.med.iacnet.com (localhost [127.0.0.1])
by jeff.med.iacnet.com (8.8.5/8.8.5) with SMTP id PAA06029;
Tue, 8 Apr 1997 15:10:30 -0400
Message-ID: <[email protected]>
Date: Tue, 08 Apr 1997 15:10:29 -0400
From: Jeff Macdonald <[email protected]>
Organization: Information Access Center
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: Frieder Loeffler <[email protected]>
CC: [email protected]
Subject: Re: Linux Redhat 4.1 and Netramet
References: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

ok, I updated to libc-5.4.23, run ldconfig -v. Still got a segfault.
Here is the strace output..... I may have missed a few lines because I
cut and pasted...

execve("./NeTraMet", ["./NeTraMet", "-k", "-r", "jeff", "-w",
"netramet"], [/* 17 vars */]) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40006000
mprotect(0x8048000, 50340, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=4746, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 4
mmap(0, 4746, PROT_READ, MAP_SHARED, 4, 0) = 0x40007000
close(4) = 0
open("/lib/libc.so.5.4.23", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 868352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40009000
mmap(0x40009000, 632084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4,
0) = 0x40009000
mmap(0x400a4000, 22708, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4,
0x9a000) = 0x400a4000
mmap(0x400aa000, 206032, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400aa000
close(4) = 0
mprotect(0x40009000, 632084, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x40007000, 4746) = 0
mprotect(0x8048000, 50340, PROT_READ|PROT_EXEC) = 0
mprotect(0x40009000, 632084, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX) = 0
geteuid() = 0
getuid() = 0
getgid() = 0
getegid() = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 1), ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40007000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "NeTraMet: Network Traffic Meter "..., 37) = 37
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
bind(4, {sin_family=AF_INET, sin_port=htons(161),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
gettimeofday({860523447, 742721}, NULL) = 0
brk(0x805c0a4) = 0x805c0a4
brk(0x805d000) = 0x805d000
brk(0x8068000) = 0x8068000
brk(0x806d000) = 0x806d000
uname({sys="Linux", node="jeff.med.iacnet.com", ...}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
ioctl(5, SIOCGIFCONF, 0xbffff888) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff890) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff890) = 0
close(5) = 0
socket(PF_INET, SOCK_PACKET, 0x300 /* IPPROTO_??? */) = 5
ioctl(5, SIOCGIFFLAGS, 0xbffffa80) = 0
ioctl(5, SIOCSIFFLAGS, 0xbffffa80) = 0
getuid() = 0
setuid(0) = 0
write(1, "Running on jeff.med.iacnet.com, "..., 47) = 47
times({tms_utime=1, tms_stime=2, tms_cutime=0, tms_cstime=0}) = 8320280
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
230000})
recvfrom(5, "\252\0\4\0\311,\0\240$\201\6\177"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
times({tms_utime=1, tms_stime=2, tms_cutime=0, tms_cstime=0}) = 8320282
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
230000})
recvfrom(5, "\0\0\370\"\240\362\0\240$P\357,\201"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 62
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\240$P\357,\0\0\370\"\240\362\201"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 62
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
240000})
recvfrom(5, "\0`\227\6, \252\0\4\0\311,\10\0E"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 74
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
240000})
recvfrom(5, "\3\0\0\0\0\1\10\0+\275%\362\0\235"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 171
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
230000})
recvfrom(5, "\253\0\4\1\"\2\252\0\4\0\220,`\7"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 128
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
220000})
recvfrom(5, "\252\0\4\0\311,\0\240$\212\346m\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\10\0 s\215\37\252\0\4\0\311,\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\10\0 s\215\37\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 88
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\10\0 s\215\37\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\10\0 s\215\37\252\0\4\0\311,\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\0.\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\240$\212\346m\252\0\4\0\311,\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\10\0 s\215\37\252\0\4\0\311,\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\10\0 s\215\37\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
230000})
recvfrom(5, "\0`\22oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in
[5], left {0, 250000})
recvfrom(5, "\252\0\4\0\311,\0`\227\6, \10\0E"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
160000})
recvfrom(5, "\252\0\4\0\311,\0\240$\212\346m\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
times({tms_utime=1, tms_stime=2, tms_cutime=0, tms_cstime=0}) = 8320308
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\240$\212\346m\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\240$\212\346m\252\0\4\0\311,\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0`\227\6,\201\10"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
230000})
recvfrom(5, "\3\0\0\0\0\1\10\0+\275\332\316\0"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 186
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 62
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 110
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 546
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 546
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 546
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 180
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
7\6,\201\252\0\4\0\311,\10"..., 4096, 0, {sun_family=AF_UNIX,
sun_path="eth0"}, [16]) = 74
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 76
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 546
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 546
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\377\377\377\377\377\377\252\0\4"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 366
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 70
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\240$\201\6\177"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 110
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\240$\201\6\177\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 77
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 182
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 106
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 80
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 99
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\252\0\4\0\311,\0\0\300\345\351W"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 88
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\0\300\345\351W\252\0\4\0\311,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0`\260\33\311\355\0\240$\26E\266"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\0\240$\26E\266\0`\260\33\311\355"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 60
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
oldselect(6, [4 5], NULL, NULL, {0, 250000}) = 1 (in [5], left {0,
250000})
recvfrom(5, "\1\200\302\0\0\24\252\0\4\0\372,"..., 4096, 0,
{sun_family=AF_UNIX, sun_path="eth0"}, [16]) = 1514
ioctl(5, SIOCGSTAMP, 0xbffffad8) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

--
Jeff Macdonald
Systems Development
Information Access Center
Medford, MA 02155

From netramet-owner Wed Apr 9 14:07:58 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id OAA22306 for netramet-outgoing; Wed, 9 Apr 1997 14:03:26 +1200 (NZST)
Received: from nevil.fedex.net (ietfpool76.fedex.net [199.81.221.86]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id OAA22217; Wed, 9 Apr 1997 14:03:00 +1200 (NZST)
From: Nevil Brownlee <[email protected]>
Reply-To: Nevil Brownlee <[email protected]>
To: Steve Resnick <[email protected]>, [email protected]
Subject: Re: Docs?
Message-ID: <[email protected]>
Date: Wed, 9 Apr 1997 14:03:04 +1200 (New Zealand Standard Time)
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 4.1 Build (3)
X-Authentication: none
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [email protected]
Precedence: bulk

Hello Steve:

> I am looking for docs for NeTraMet in some other form
than postscript.
> The 3.1 docs under ghostscript showed up as one page, and the 3.4 docs, although
> they showed 34 pages under ghostscript, would not print on my printer after churning for some 45 minutes on a 120MHz pentium.
>
> I noticed from ghostscript the .ps files were generated with MS Word. Is this format available at all?

The Microsoft Word originals of the documents are in the FTP directory
as ntm-word.zip.

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee Director, Technology Development |
| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland |
| FAX: +64 9 373 7425 Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------P

From netramet-owner Wed Apr 9 23:59:56 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id XAA29070 for netramet-outgoing; Wed, 9 Apr 1997 23:52:54 +1200 (NZST)
Received: from nosc.ja.net (nosc.ja.net [128.86.16.20]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with SMTP id XAA29062 for <[email protected]>; Wed, 9 Apr 1997 23:52:49 +1200 (NZST)
Received: from nosc.ja.net by nosc.ja.net with Internet SMTP
id <[email protected]>; Wed, 9 Apr 1997 12:52:21 +0100
To: "Matthew B. Thomson" <[email protected]>
cc: [email protected]
Subject: Re: rules help
In-reply-to: Your message of "Tue, 08 Apr 1997 11:43:51 EDT." <[email protected]>
Date: Wed, 09 Apr 1997 12:52:16 +0100
Message-ID: <[email protected]>
From: Kevin Hoadley <[email protected]>
Sender: [email protected]
Precedence: bulk

> Hello all. I have this rule file, listed below. It works if the port is
> defined in the rule set, but I also want to count those packets that do not
> match to a port (DestTransAddress). Can someone tell me where my mistake
> is? I'm sure the rule file could be better, so if anyone feels like
> tweaking, by all means! I think it's pretty self explanatory as far as
> what I'm trying to do.

Are you trying to match certain known ports, plus a catch-all category for
everything else ?

If so, you might try something like:

> t_Routing: # 520
> DestTransAddress & 255.255 = rip: PushToAct, CountThis;
> SourceTransAddress & 255.255 = rip: Retry, 0;
> t_Mystery: # Other
> DestTransAddress & 255.255 = 0: PushToAct, CountThis;
> SourceTransAddress & 255.255 = 0: PushToAct, CountThis;

t_Mystery: # Account all other traffic with in category DestTransAddress=0
Null & 0 = 0: GotoAct, Next; # If we get this far, we know this packet
# failed to match any of the designated
# port numbers - so jump to action to store
# zero as port number
DestTransAddress & 255.255 = 0: PushRuleToAct, Next; # Push 0 from rule, not
# from the packet
SourceTransAddress & 255.255 = 0: PushRuleToAct, CountThis;

Kevin Hoadley, JANET.

From netramet-owner Fri Apr 11 06:37:11 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id GAA17468 for netramet-outgoing; Fri, 11 Apr 1997 06:17:41 +1200 (NZST)
Received: from jeff.med.iacnet.com ([140.244.8.125]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id GAA17397 for <[email protected]>; Fri, 11 Apr 1997 06:17:13 +1200 (NZST)
Received: from jeff.med.iacnet.com (localhost [127.0.0.1])
by jeff.med.iacnet.com (8.8.5/8.8.5) with SMTP id OAA00728
for <[email protected]>; Thu, 10 Apr 1997 14:06:37 -0400
Message-ID: <[email protected]>
Date: Thu, 10 Apr 1997 14:06:36 -0400
From: Jeff Macdonald <[email protected]>
Organization: Information Access Center
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: [email protected]
Subject: Linux RedHat 4.1 and Netramet
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,
This is a continuation of my previous posts....

Here's a short summary:
* Linux RedHat 4.1 with libc 5.3.12 on a 2.0.29 kernel - segfault
* a strace showed it recieving packets, then a segfault
* an upgrade to libc 5.4.23 - segfault

New stuff:
* Moved the binary to a RedHat 4.0 system, different subnet - works
ok (only ran it for a minute)
* Upgraded Kernel to 2.0.30 - segfault
* Removed IPX support from kernel - segfault
* noticed that binary has debug support - run through gdb

here is where the segfault happens:

in meter_ux.c line 348

if (h->ts.tv_sec != last_t_sec) {
last_t_sec = h->ts.tv_sec;
one_second_process();
}

(xxgdb) print h->ts.tv_sec
Cannot access memory at address 0x0.
(xxgdb) print *h->ts.tv_sec
Cannot access memory at address 0x0
(xxgdb) print last_t_sec
$2 = 860692914

So, it looks like an un-intialized pointer problem. Any have a clue? I
will start looking at the source, but I'm not an expert in this area.

Thanks in advance.

--
Jeff Macdonald
Systems Development
Information Access Center
Medford, MA 02155

From netramet-owner Sat Apr 12 00:07:22 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id XAA22170 for netramet-outgoing; Fri, 11 Apr 1997 23:58:40 +1200 (NZST)
Received: from noc.belwue.de ([email protected] [129.143.2.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id XAA22094 for <[email protected]>; Fri, 11 Apr 1997 23:58:13 +1200 (NZST)
Received: from tunix.mathematik.uni-stuttgart.de (tunix.mathematik.uni-stuttgart.de [129.69.116.156])
by noc.belwue.de (8.8.5/8.8.5) with SMTP id NAA08230;
Fri, 11 Apr 1997 13:58:09 +0200 (MET DST)
Received: by tunix.mathematik.uni-stuttgart.de (AIX 3.2/UCB 5.64/BelWue-1.0AIXRS)
id AA25380; Fri, 11 Apr 1997 13:57:39 +0200
From: [email protected] (Frieder Loeffler)
Message-Id: <[email protected]>
Subject: Re: Linux RedHat 4.1 and Netramet
To: [email protected] (Jeff Macdonald)
Date: Fri, 11 Apr 1997 13:57:38 +0200 (MSZ)
Cc: [email protected]
In-Reply-To: <[email protected]> from "Jeff Macdonald" at Apr 10, 97 02:06:36 pm
X-Mailer: ELM [version 2.4 PL25 PGP6]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,

Jeff Macdonald wrote:
> (xxgdb) print h->ts.tv_sec
> Cannot access memory at address 0x0.
> (xxgdb) print *h->ts.tv_sec
> Cannot access memory at address 0x0
> (xxgdb) print last_t_sec
> $2 = 860692914
>
> So, it looks like an un-intialized pointer problem. Any have a clue? I
> will start looking at the source, but I'm not an expert in this area.

I just had a look at the source. The data structure "h" is given as a parameter
to void ether_callback(u_char *user, struct pcap_pkthdr *h, u_char *p)

struct pcap_pkthdr looks suspicuously like it has to do with libpcap...

I do not know anything about libpcap, but I guess you should look for the
fault in libpcap.a -- especially since the binary is running on my machine.

If you want, I can give you my libpcap.a - maybe that solves the problem...

Cheers,
Siegfried
--
Siegfried Loeffler, DG1SEK, Moehringer Str. 96, 70199 Stuttgart, Germany
Phone: +49-711-6074762 Fax: +49-711-6074763 Mobile: +49-172-9021563
http://www.mathematik.uni-stuttgart.de/~floeff
NEW: Watch me "working": http://ksoc3mon2.rus.uni-stuttgart.de/qcam.html

From netramet-owner Sun Apr 13 22:34:15 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id WAA08049 for netramet-outgoing; Sun, 13 Apr 1997 22:15:27 +1200 (NZST)
Received: from ns.buptnet.edu.cn (ns.buptnet.edu.cn [202.112.10.37]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id WAA07994 for <[email protected]>; Sun, 13 Apr 1997 22:15:09 +1200 (NZST)
Received: from noya.bupt.edu.cn (noya.bupt.edu.cn [202.112.96.2])
by ns.buptnet.edu.cn (8.8.4/8.8.4) with SMTP
id TAA01984 for <[email protected]>; Sun, 13 Apr 1997 19:15:08 +0900 (CDT)
Received: from cct.bupt.edu.cn ([202.112.96.69]) by noya.bupt.edu.cn (5.x/SMI-SVR4)
id AA05072; Sun, 13 Apr 1997 19:15:30 +0900
Message-Id: <[email protected]>
Date: Sun, 13 Apr 1997 18:17:41 +0900
From: ccstu <[email protected]>
Reply-To: [email protected]
Organization: bupt
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: [email protected]
Subject: How to manage a class C net segment?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

hello
I want to manage a class C net segment.Gateway is 202.112.10.129.
Subnet mask is 255.255.255.224.Protocal is TCP/IP.I want to monitor the
flows of ip and the www PDUs of TCP.I have tried many times but failed.
I don't know how to write rules of this kind.
If you have time to help me ,please help me.
yours GX

From netramet-owner Tue Apr 22 05:33:05 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id FAA26343 for netramet-outgoing; Tue, 22 Apr 1997 05:15:37 +1200 (NZST)
Received: from jeff.med.iacnet.com ([140.244.8.125]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id FAA26292 for <[email protected]>; Tue, 22 Apr 1997 05:15:20 +1200 (NZST)
Received: from jeff.med.iacnet.com (localhost [127.0.0.1])
by jeff.med.iacnet.com (8.8.5/8.8.5) with SMTP id NAA24625;
Mon, 21 Apr 1997 13:14:41 -0400
Message-ID: <[email protected]>
Date: Mon, 21 Apr 1997 13:14:40 -0400
From: Jeff Macdonald <[email protected]>
Organization: Information Access Center
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: netramet list <[email protected]>
CC: Ed Gorton <[email protected]>, Cliff <[email protected]>
Subject: Linux, FDDI, and netramet
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,
Has anyone used the following combination:

Red Hat Linux 4.1 with kernel 2.0.30
FDDI driver (DEC)

When I first installed the FDDI driver, ifconfig showed

fddi0 Link encap:UNSPEC HWaddr
00-00-F8-63-26-BE-00-F7-00-00-00-00-00-00-00-00
inet addr:140.244.8.158 Bcast:140.244.8.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:4470 Metric:1
RX packets:0 errors:0 dropped:0 overruns:2
TX packets:0 errors:0 dropped:0 overruns:0

The UNSPEC for Link encap worried me, so a mail message to Larry Stefani
<[email protected]>, the maintainer of the FDDI driver, resulted in
him sending a patch to net-tools. Thus the newly compiled net-tools and
ifconfig resulted with this:

fddi0 Link encap:Fiber Distributed Data Interface HWaddr
00-00-F8-63-26-BE
inet addr:140.244.8.158 Bcast:140.244.8.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:4470 Metric:1
RX packets:0 errors:0 dropped:0 overruns:2
TX packets:0 errors:0 dropped:0 overruns:0

Now, running netramet results in this:

[root@juan2 bin]# ./NeTraMet -i fddi0
NeTraMet: Network Traffic Meter V3.4
Running on juan2.med.iacnet.compcap_open_live(fddi0): linux: unknown
physical layer type

I should mention that the FDDI card isn't plugged into anything as of
yet. I don't think that that would affect the outcome.

I also had a problem on just running this on a local ethernet. It seems
that libpcap passes null pointers to the ether_callback routine. Our net
has many types of packet types and protocols. When the machine was put
on just an IP based net, the meter ran fine. Are there any known packet
types that cause problems with Netramet? I been debugging the code, and
haven't gotten to the actual type as of yet. However, since it works on
IP only nets (with ethernet), I'm more interested in getting the FDDI
support working.

Any pointers would be of great help.

--
Jeff Macdonald
[email protected]
Systems Development
Information Access Center
Medford, MA 02155

From netramet-owner Wed Apr 23 10:49:58 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id KAA29606 for netramet-outgoing; Wed, 23 Apr 1997 10:33:20 +1200 (NZST)
Received: from exchange.iconz.co.nz (exchange.iconz.co.nz [202.14.100.130]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id KAA29601 for <[email protected]>; Wed, 23 Apr 1997 10:33:18 +1200 (NZST)
Received: by exchange.iconz.co.nz with Internet Mail Service (5.0.1457.3)
id <241RX5BZ>; Wed, 23 Apr 1997 10:36:46 +1200
Message-ID: <[email protected]>
From: Rowan Smith <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Netramet on MSDos
Date: Wed, 23 Apr 1997 10:36:44 +1200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)
Content-Type: text/plain
Sender: [email protected]
Precedence: bulk

Can anybody think of any reasons why a meter running on MSDos would be
less efficient than a meter running on the same platform using Linux?

I'm considering installing a P166 with 64Mb RAM, as a Netramet Meter and
using MSDos as the OS for simplicity of maintenance and operation.

-Rowan

From netramet-owner Thu Apr 24 01:21:54 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id BAA21491 for netramet-outgoing; Thu, 24 Apr 1997 01:13:51 +1200 (NZST)
Received: from one.ti-edu.ch (one.ti-edu.ch [195.176.176.129]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id BAA21453 for <[email protected]>; Thu, 24 Apr 1997 01:13:30 +1200 (NZST)
Received: from one ([195.176.176.129]) by one.ti-edu.ch
(post.office MTA v2.0 0813 ID# 0-18241U110) with SMTP id AAA6185
for <[email protected]>; Wed, 23 Apr 1997 15:13:18 +0200
Message-ID: <[email protected]>
Date: Wed, 23 Apr 1997 15:13:17 +0200
From: Mario Gay <[email protected]>
Organization: Universita` della Svizzera Italiana / TI-EDU
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u)
MIME-Version: 1.0
To: [email protected]
Subject: Script to summarize NeTraMet output files
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,

has anybody already written a script or a program that takes as input
a set of files produced by NeTraMet and calculate the total traffic
for each type of flow between two dates?

I would like to avoid to reinvent the wheel...

Thanks,
Mario

--
Mario Gay Universita` della Svizzera Italiana
Servizi Informatici / TI-EDU
E-mail: [email protected] Galleria 2
Tel.: +41 91 610 8531 CH-6928 Manno (Switzerland)

From netramet-owner Thu Apr 24 01:31:14 1997
Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) id BAA23696 for netramet-outgoing; Thu, 24 Apr 1997 01:30:17 +1200 (NZST)
Received: from noc.belwue.de ([email protected] [129.143.2.1]) by mailhost.auckland.ac.nz (8.8.5/8.7.3-ua) with ESMTP id BAA23691 for <[email protected]>; Thu, 24 Apr 1997 01:30:14 +1200 (NZST)
Received: from tunix.mathematik.uni-stuttgart.de (tunix.mathematik.uni-stuttgart.de [129.69.116.156])
by noc.belwue.de (8.8.5/8.8.5) with SMTP id PAA04119;
Wed, 23 Apr 1997 15:29:56 +0200 (MET DST)
Received: by tunix.mathematik.uni-stuttgart.de (AIX 3.2/UCB 5.64/BelWue-1.0AIXRS)
id AA29103; Wed, 23 Apr 1997 15:29:21 +0200
From: [email protected] (Frieder Loeffler)
Message-Id: <[email protected]>
Subject: Re: Netramet on MSDos
To: [email protected] (Rowan Smith)
Date: Wed, 23 Apr 1997 15:29:21 +0200 (MSZ)
Cc: [email protected]
In-Reply-To: <[email protected]> from "Rowan Smith" at Apr 23, 97 10:36:44 am
X-Mailer: ELM [version 2.4 PL25 PGP6]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk

Hi,

Rowan Smith wrote:
> Can anybody think of any reasons why a meter running on MSDos would be
> less efficient than a meter running on the same platform using Linux?

The only reason I could think of would be that the Networking Stack used
under DOS, especially the network card drivers, are probably not as
performant as the one in Linux is. This could especially be important
if you are using a PCI Networking card that supports Busmaster Mode. Often
the DOS drivers do not support this, and then this would indeed make quite
a large difference. An example for such a Card could be HPs 100VG AnyLan /
10-base-T combo adapter HP J2585B, which I am using and for which I wrote
the extended busmaster driver for Linux.

Regards,
Siegfried
--
Siegfried Loeffler, DG1SEK, Moehringer Str. 96, 70199 Stuttgart, Germany
Phone: +49-711-6074762 Fax: +49-711-6074763 Mobile: +49-172-9021563
http://www.mathematik.uni-stuttgart.de/~floeff
NEW: Watch me "working": http://ksoc3mon2.rus.uni-stuttgart.de/qcam.html