From netramet-owner  Mon May 15 19:04:03 1995
Return-Path: <netramet-owner>
Received: by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA21067; Mon, 15 May 1995 19:03:20 +1200
Received: from ccvcom.auckland.ac.nz by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA21059; Mon, 15 May 1995 19:03:11 +1200
Received: from ccu1.auckland.ac.nz by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
15 May 1995 19:02:59 GMT+1200
Received: by ccu1.auckland.ac.nz (931110.SGI/940509)
for [email protected] id AA14844; Mon, 15 May 95 19:02:54 +1200
Date: Mon, 15 May 1995 19:02:54 +1200 (NZT)
From: [email protected] (Russell Street)
Subject: NeTraMet ADMIN: mailing list working again....
To: [email protected]
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1304
Sender: [email protected]
Precedence: bulk

[If you see this message again it was because of a DUD address in the
member list, so this an attempt to see if I have fixed it <sigh>]

Hello NeTraMeters...

This mailing list and its archive should be working normally again
now, and you can send things to it and hopefully they won't bounce
with nasty looking error messages.

If it does play up again, please tell the list owner, Nevil Brownlee
(n.brownlee@auckland) who will tell me.

The archive of the mailing list contents can be found at

       ftp://ftp.auckland.ac.nz/pub/iawg/NeTraMet/ml-archives/netramet.yymm

Sorry for the inconvience,
Russell [majordomo]
-------------------------------------------------------------------
Russell Street ([email protected]) +64 (9) 373-7599 extn 6487
  UNIX Systems Programmer, Computer Centre, University of Auckland
            http://www.auckland.ac.nz/cc/People/RS.html

  Like the blind man in the dark room looking for the black cat
                         that isn't there

-------------------------------------------------------------------
Russell Street ([email protected]) +64 (9) 373-7599 extn 6487
  UNIX Systems Programmer, Computer Centre, University of Auckland
            http://www.auckland.ac.nz/cc/People/RS.html

  Like the blind man in the dark room looking for the black cat
                         that isn't there


From netramet-owner  Mon May 15 19:12:02 1995
Return-Path: <netramet-owner>
Received: by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA21246; Mon, 15 May 1995 19:08:07 +1200
Received: from ccvcom.auckland.ac.nz by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA21233; Mon, 15 May 1995 19:07:58 +1200
Received: from ccu1.auckland.ac.nz by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
15 May 1995 19:07:46 GMT+1200
Received: by ccu1.auckland.ac.nz (931110.SGI/940509)
for [email protected] id AA14925; Mon, 15 May 95 19:07:43 +1200
Date: Mon, 15 May 1995 19:07:43 +1200 (NZT)
From: [email protected] (Russell Street)
Subject: NeTraMet ADMIN: one more for the road...
To: [email protected]
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 43
Sender: [email protected]
Precedence: bulk

.. I think you get the drill ...

Russell


From netramet-owner  Mon May 15 21:47:10 1995
Return-Path: <netramet-owner>
Received: by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA25937; Mon, 15 May 1995 21:32:14 +1200
Received: from ccvcom.auckland.ac.nz by net.auckland.ac.nz (5.0/SMI-SVR4)
       id AA25864; Mon, 15 May 1995 21:29:46 +1200
Received: from pukapuka.ethz.ch by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
15 May 1995 21:29:39 GMT+1200
Received: (from moser@localhost) by pukapuka.ethz.ch (8.6.10/8.6.10)
id LAA00758; Mon, 15 May 1995 11:28:39 +0200
Date: Mon, 15 May 1995 11:28:39 +0200
From: Stefan Moser <[email protected]>
Subject: NeTraMet problem/bug?
To: [email protected]
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: exmh version 1.6 4/21/95
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT
Content-Length: 0
Sender: [email protected]
Precedence: bulk


Hi,

I've sent this message to this list before, but I don't think it made it
with the recent problems with the mailing list. Anyway here it is:

I've recently tried to write a rule file for NeTraMet to do accounting
on an IP protocol basis. However, when working with this file the results
delivered by NeTraMet are not really what I expect, when I run the
meter on a PC.

The rule file in the pretty much stripped down form following below is
supposed to track all ftp and ftpdata flows. To make things simple I have
restricted the accounting to packets going to and coming from
129.132.40.17.

Here's the rule file:

SET 2
#
RULES
  SourcePeerType & 255 = IP:         Pushto, IP_pkt;
  Null & 0 = 0:                      Ignore, 0;
#
IP_pkt:
  SourceTransType     & 255 = UDP:             PushPktto, UDPTCP_pkt;
  SourceTransType     & 255 = TCP:             PushPktto, UDPTCP_pkt;
  Null & 0 = 0:       Ignore, 0;

UDPTCP_pkt:
  SourcePeerAddress   & 255.255.255.255 = 129.132.40.17:
                PushPkttoAct, source_pkt;
  DestPeerAddress     & 255.255.255.255 = 129.132.40.17:
                PushPkttoAct, dest_pkt;
  Null & 0 = 0:       Ignore, 0;
#
source_pkt:
  DestPeerAddress     & 255.255.255.255 = 0: PushPktto, determ_prot;

dest_pkt:
 SourcePeerAddress   & 255.255.255.255 = 0: PushPktto, determ_prot;

determ_prot:
  SourceTransAddress  & 255.255 = ftpdata:    PushPkttoAct, source_prot;
  DestTransAddress    & 255.255 = ftpdata:    PushPkttoAct, dest_prot;
  SourceTransAddress  & 255.255 = ftp:        PushPkttoAct, source_prot;
  DestTransAddress    & 255.255 = ftp:        PushPkttoAct, dest_prot;
  Null & 0 = 0:       Ignore, 0;

source_prot:
  DestTransAddress       & 255.255 = 0:               PushPktto, count_pkt;

dest_prot:
 SourceTransAddress     & 255.255 = 0:               PushPktto, count_pkt;

count_pkt:
  Null & 0 = 0:  Count, 0;
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
   SourcePeerType SourcePeerAddress DestPeerAddress "  "
   SourceTransAddress DestTransAddress "  "
   ToPDUs FromPDUs "  " ToOctets FromOctets;


If I run this filter with the meter on the 129.132.40.0 subnet, make an ftp
connection from 129.132.40.17 to 129.132.98.56 and then get a single file of
290544 bytes size, the result looks like this:

#Time: 16:40:00 Thu 11 May 95 129.132.40.61 Flows from 10520 to 16560
#Stats: aps=188 apb=3 mps=376 mpb=14 lsp=0 avi=94.2 mni=77.2 fiu=16 frc=0
gci=10 rpp=3.6 tpp=0.0 cpt=1.0 tts=512 tsu=1
2 17 11389  2 129.132.40.17 129.132.98.56  3048 21  42 215  2564 304213

There's not 2 flows as I would expect, one for ftp and one for ftpdata,
but the byte count for the one single flow indicates that the ftpdata flow
somehow has been folded into the ftp control flow.

If I do the same as above, but transfer the file two times in a row in the
same ftp session, the result looks like:

#Time: 16:53:00 Thu 11 May 95 129.132.40.61 Flows from 935 to 6991
#Stats: aps=253 apb=11 mps=898 mpb=109 lsp=0 avi=91.2 mni=27.9 fiu=5 frc=0
gci=10 rpp=6.1 tpp=0.0 cpt=1.0 tts=512 tsu=2
2 5 1474  2 129.132.40.17 129.132.40.56  3050 21  45 218  2771 304495
2 6 3203  2 129.132.40.56 129.132.40.17  20 3052  204 26  303299 1560

While one file still appears to be folded into the ftp control flow,
the other one is accounted for in a separate flow. This also works for
every file transferred thereafter. If I do an mget first thing, all the files
retrieved by the mget get their own flows. Also if I try get a file that
doesn't exist as the first thing, the second file transferred gets its
own flow as well.

When I run the meter with the same rulefile on SunOS, the results are
as expected, two distinct flows, one with destination port 21 and the
other with source port 20.

Does anyone have an idea what the cause for this behaviour could possibly be?
Admittedly, I'm not very experienced with NeTraMet, so it could well be my
mistake.

Thanks for you time

Stefan Moser



------------------------------------------------------------------------------
Stefan Moser           ETH Zuerich            "The first precept was never to
[email protected]    Communication Systems   accept a thing as true until
Voice: (01) 63-23480   Clausiusstrasse 59      I knew it as such without a
Fax: (01) 63-21225     CH-8092 Zuerich         single doubt"   Rene Descartes
------------------------------------------------------------------------------


From netramet-owner  Tue May 30 19:07:12 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id SAA19740 for netramet-outgoing; Tue, 30 May 1995 18:37:24 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id SAA19005 for <[email protected]>; Tue, 30 May 1995 18:23:15 +1200
Received: from brolga.cc.uq.oz.au by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
30 May 1995 18:22:44 GMT+1200
Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Tue,
30 May 1995 16:22:13 +1000
Date: Tue, 30 May 1995 16:22:06 +1000
From: David Vu <[email protected]>
Subject: BPF port?
To: [email protected], [email protected]
Cc: [email protected]
Message-id: <"brolga.cc.uq:202890:950530062217"@cc.uq.oz.au>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


Hi folks,

I 've ftp'ed NeTraMet 3.1 and have been trying to compile the meter
on NetBSD 1.0 without success.  This is because the meter uses
the NIT interface on SunOS and Solaris to do the network sniffing
which NetBSD doesn't have.

NetBSD has a Berkeley Packet Filter Interface, which is far more
efficient I believe.

Has anyone ported NeTraMet 3.1 or later to BPF/NetBSD?  I've checked
the mail archive and no one has mentioned this.  How about some good
pointers on how to port from NIT to BPF anyone?

Thanks in advance,


From netramet-owner  Wed May 31 01:07:22 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id AAA04146 for netramet-outgoing; Wed, 31 May 1995 00:52:24 +1200
Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by net.auckland.ac.nz (8.6.12/8.6.12) with ESMTP id AAA03901 for <[email protected]>; Wed, 31 May 1995 00:40:04 +1200
From: [email protected]
Received: from watson.ibm.com by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Wed,
31 May 1995 00:39:54 GMT+1200
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3)
with BSMTP id 8995; Tue, 30 May 95 08:38:55 EDT
Date: Tue, 30 May 1995 08:37:02 -0400 (EDT)
Subject: Fragmentation
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

 How are fragmented packets counted? Is each fragment counted individually,
or is the information extracted from the header of the first packet and used
to describe the entire (unfragmented) packet?

                                                   Stephen Stibler

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.