From netramet-owner  Tue Aug  1 01:18:28 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id BAA19157 for netramet-outgoing; Tue, 1 Aug 1995 01:02:45 +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 BAA19104 for <[email protected]>; Tue, 1 Aug 1995 01:01:47 +1200
Received: from mailhost.tue.nl by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
1 Aug 1995 01:01:46 GMT+1300
Received: from sg3.urc.tue.nl [131.155.4.135] by mailhost.tue.nl (8.6.10)
for <[email protected]> id PAA24065 (SMTP). Mon,
31 Jul 1995 15:01:39 +0200
Received: from rccarel@localhost by sg3.urc.tue.nl (8.6.11)
for [email protected] id OAA06068. Mon, 31 Jul 1995 14:58:55 +0200
Date: Mon, 31 Jul 1995 14:58:55 +0200 (MDT)
From: Carel Braam <[email protected]>
Subject: Modified Logging discussion
To: [email protected]
Message-id: <[email protected]>
X-Mailer: ELM [version 2.4 PL23]
Content-type: text
Content-transfer-encoding: 7BIT
Content-length: 607
Sender: [email protected]
Precedence: bulk

Hello all:

Stephen is right with his remarks about NOT zeroing counters.
The Internet Accounting model implements the counters as SNMP COUNTERS,
which means they are NEVER reset - this allows multiple collectors to
retrieve information asynchronously.

If we want to produce a file with just the differences between samples,
we should do that within NeMaC.

I'm a little surprised that Glen finds it necessary to open/append/close
the flow data file - under Irix I can read all the way to the current
end of file, as Andy says.

I'm still in Europe, but I'll be home again around 10 Aug 95.

Cheers, Nevil

From netramet-owner  Tue Aug  1 08:18:10 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id IAA04962 for netramet-outgoing; Tue, 1 Aug 1995 08:02:47 +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 HAA04504 for <[email protected]>; Tue, 1 Aug 1995 07:57:15 +1200
Received: from cc-server9 (cc-server9.massey.ac.nz)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
1 Aug 1995 07:57:00 GMT+1300
Received: from cc-swdev1.massey.ac.nz (actually cc-swdev1)
by cc-server9 with SMTP(PP); Tue, 1 Aug 1995 07:55:15 +1200
Received: from massey.ac.nz by cc-swdev1.massey.ac.nz id
<[email protected]>; Tue, 1 Aug 1995 07:55:10 +1200
Date: Tue, 01 Aug 1995 07:55:10 +1200
From: Glen Eustace <[email protected]>
Subject: Re: Modified Logging discussion
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
X-Sun-Charset: US-ASCII
Sender: [email protected]
Precedence: bulk

> Stephen is right with his remarks about NOT zeroing counters.
> The Internet Accounting model implements the counters as SNMP COUNTERS,
> which means they are NEVER reset - this allows multiple collectors to
> retrieve information asynchronously.

The idea of multiple collectors never occured to me :-(  I haven't read
the document describing the model either :-( :-(

> If we want to produce a file with just the differences between samples,
> we should do that within NeMaC.

Probably a better option.

> I'm a little surprised that Glen finds it necessary to open/append/close
> the flow data file - under Irix I can read all the way to the current
> end of file, as Andy says.

It isn't a case of not being able to read the files.  I am charging the
traffic in real time.  I didn't want the complication of the charging program
needing to work out which files to process or to cope with the file
being closed by NeMaC and then having to find the new one.  Also, if the
charging program was stopped and started, I didn't want to reprocess and
hence possible double charge flows.

What I have works great.  The awkward part was merging the flow files and
the acp_logfile being produced by the annex.  But that seems ok now too.

This whole exercise was to charge those users doing dial-in IP for all
the resources they consume, which includes network traffic and I think
I have succeeded in doing so.



From netramet-owner  Fri Aug  4 14:53:38 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id NAA04182 for netramet-outgoing; Fri, 4 Aug 1995 13:55:19 +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 NAA04074 for <[email protected]>; Fri, 4 Aug 1995 13:53:37 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
4 Aug 1995 13:53:15 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA09293; Fri, 4 Aug 95 10:01:49 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA03089; Fri, 4 Aug 95 09:43:41 CST
Date: Fri, 04 Aug 1995 09:43:41 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: test
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

test

From netramet-owner  Fri Aug  4 20:54:23 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id TAA27196 for netramet-outgoing; Fri, 4 Aug 1995 19:52:14 +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 TAA25941 for <[email protected]>; Fri, 4 Aug 1995 19:22:55 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
4 Aug 1995 19:22:49 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA10636; Fri, 4 Aug 95 15:31:57 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA03514; Fri, 4 Aug 95 15:13:49 CST
Date: Fri, 04 Aug 1995 15:13:49 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: Re: [Q]: Packets Counters
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

>Look at the third paragraph of section 2.6 in the version 3.2 manual. This
>seems to suggest that it will swap source and destination when it is looking
>for a counter to increment. Since you are performing a Count action even on
>packets that you do not mean to count, it may cause this behavior. Perhaps
>a packet coming in the "opposite" direction gets counted by the spurious
>count action. It is all somewhat mysterious to me too. Try this:

The Second paragraph of section 2.6 say:
"If the match fails, the keys are interchanged and the packet is tested
against the rules again. If it fails this time it is discarded"

 Does it mean that we need not use "Retry" action and the program will
"Automatically" interchange the source and destination, then test again?
So why is the "Retry" action there? When do we need it?

 In addition, the last two paragraphs said that we can write rules which
enforce a particular "source-to-destination" order. But it confuse me!!
If I want to count the packets flow send from every host (just use the
"toPDU" to count the packets and wish the "fromPDU" in every flow is zero)
How could I write the rule files?

 Any information or pointers are appreciated.

                                               Jason

===========================================================================
TTTTTTTTT LLLLL          Mr. Jeng-Sen Lin
T  TTT  T  LLL           jason%[email protected]
  TTT     LLL   L       Telecommunication Laboratories of Information
 TTTTT   LLLLLLLLL o    Technology Laboratory, Taiwan, R.O.C

From netramet-owner  Fri Aug  4 21:53:18 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id UAA00266 for netramet-outgoing; Fri, 4 Aug 1995 20:52:14 +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 UAA29714 for <[email protected]>; Fri, 4 Aug 1995 20:44:15 +1200
Received: from decgat (tlrouter.motctl.gov.tw)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Fri,
4 Aug 1995 20:44:06 GMT+1300
Received: by decgat (5.57/Ultrix3.0-C) id AA10636; Fri, 4 Aug 95 15:31:57 +0800
Received: by jugar.tlnm (4.1/SMI-4.1) id AA03514; Fri, 4 Aug 95 15:13:49 CST
Date: Fri, 04 Aug 1995 15:13:49 -0600 (CST)
From: jason%[email protected] (Lin Jeng-Sen)
Subject: Re: [Q]: Packets Counters
To: [email protected]
Message-id: <[email protected]>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

>Look at the third paragraph of section 2.6 in the version 3.2 manual. This
>seems to suggest that it will swap source and destination when it is looking
>for a counter to increment. Since you are performing a Count action even on
>packets that you do not mean to count, it may cause this behavior. Perhaps
>a packet coming in the "opposite" direction gets counted by the spurious
>count action. It is all somewhat mysterious to me too. Try this:

The Second paragraph of section 2.6 say:
"If the match fails, the keys are interchanged and the packet is tested
against the rules again. If it fails this time it is discarded"

 Does it mean that we need not use "Retry" action and the program will
"Automatically" interchange the source and destination, then test again?
So why is the "Retry" action there? When do we need it?

 In addition, the last two paragraphs said that we can write rules which
enforce a particular "source-to-destination" order. But it confuse me!!
If I want to count the packets flow send from every host (just use the
"toPDU" to count the packets and wish the "fromPDU" in every flow is zero)
How could I write the rule files?

 Any information or pointers are appreciated.

                                               Jason

===========================================================================
TTTTTTTTT LLLLL          Mr. Jeng-Sen Lin
T  TTT  T  LLL           jason%[email protected]
  TTT     LLL   L       Telecommunication Laboratories of Information
 TTTTT   LLLLLLLLL o    Technology Laboratory, Taiwan, R.O.C

From netramet-owner  Mon Aug  7 05:52:39 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id EAA15414 for netramet-outgoing; Mon, 7 Aug 1995 04:52:33 +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 EAA14796 for <[email protected]>; Mon, 7 Aug 1995 04:33:02 +1200
Received: from info.forthnet.gr by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
7 Aug 1995 04:32:58 GMT+1300
Received: from iris by info.forthnet.gr via FORTHnet with SMTP; id TAA27593
(8.6.12/FORTHNET-2.0); Sun, 6 Aug 1995 19:29:31 +0300 (EET DST)
Date: Sun, 06 Aug 1995 19:29:23 +0200
From: [email protected] (Kokitis Kostas)
Subject: NetraMet + DOS  =  ERROR 0x88  => Help me.
X-Sender: [email protected]
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0
X-Mailer: Windows Eudora Version 1.4.3
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

Hello,

I would like to run Netramet on DOS.

I have this NetraMet.exe

If I run it by itself it says it halts because it cannot find a packet driver.

I put a packet driver called Etherslip (a simulated Ethernet adapter) I try
again and I get the message

ERROR 0x88 setting receive mode.

I've also tried with another packet driver called slip8250

I would need some help.

Bye
kostas kokitis
Hellas


From netramet-owner  Tue Aug  8 14:03:02 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id MAA02346 for netramet-outgoing; Tue, 8 Aug 1995 12:52:46 +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 MAA27558 for <[email protected]>; Tue, 8 Aug 1995 12:00:02 +1200
From: [email protected]
Received: from AARNet.ncom.nt.gov.au by ccvcom.auckland.ac.nz
(PMDF V4.3-7 #2864) id <[email protected]>; Tue,
8 Aug 1995 11:56:58 GMT+1300
Received: from MailHub.ncom.nt.gov by aarnet.ncom.nt.gov.au (PMDF V4.3-7 #4927)
id <[email protected]>; Tue, 8 Aug 1995 09:31:00 CST
Received: from nmdl01 (nmdl01.ncom.nt.gov.au) by mailhub.ncom.nt.gov.au
(PMDF V4.3-7 #4927) id <[email protected]>; Tue,
8 Aug 1995 09:27:07 CST
Date: Tue, 08 Aug 1995 09:22:03 +1030
Subject: Installation of netramet on OSF/1
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: SMTP%"[email protected]"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I am attempting to install netramet on an OSF/1 system. The program compiles
but will not bind to the snmp_port.  The snmp daemon is using the port and the
error from the bind is address in use.  I have set the socket options for the socket to accept multiple addresses but this is not working.

Any suggestions to correcting the problem?

David Hoey
NCOM, N.T. Government, Australia
[email protected]

From netramet-owner  Mon Aug 14 19:27:31 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id TAA21682 for netramet-outgoing; Mon, 14 Aug 1995 19:12:29 +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 TAA21287 for <[email protected]>; Mon, 14 Aug 1995 19:03:45 +1200
Received: from brolga.cc.uq.oz.au by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Mon,
14 Aug 1995 19:03:41 GMT+1300
Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Mon,
14 Aug 1995 17:03:29 +1000
Date: Mon, 14 Aug 1995 17:03:24 +1000
From: David Vu <[email protected]>
Subject: Non symmetrical counts
To: [email protected]
Cc: [email protected]
Message-id: <"brolga.cc.uq:182160:950814070334"@cc.uq.oz.au>
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


Hi,

I am using Netramet 3.1 to count traffic flowing between hosts in
a network to other networks.  Unfortunately, the rule file below
works for counts having different masks in both direction but
doesn't for counts having the same masks.
That is, for flows that have source in the 130.102.128.0 subnet and
destination in the 130.102.128.0 subnet I get 0 fromOctets for these
flows:

6 108 18179945  2 130.102.128.5 130.102.128.4  6989673 0
6 107 18179632  2 130.102.128.32 130.102.128.5  396806 0
6 106 18179528  2 130.102.128.21 130.102.128.5  337102 0

>From my tests, the toOctets counts above include all fromOctets
counts. ie. if I transfer a 6 Meg file from 130.102.128.4 to 130.102.128.5,
the toOctets should be <small non-zero> and the fromOctets should
be <about 6,000,000>.

In Section 2.6 of the Netramet manual, this indicates the flow is counted
symmetrically.  What do I need to do to be able to count non-symmetrically
for counts having the same masks?

#  16/6/96
#
#  Rule specification file to tally host <-> networks and networks <-> networks
#  traffic
#
#  DV
SET 8
#
RULES
 SourcePeerType & 255 = IP:         Pushto, IP_pkt;
 Null & 0 = 0:                      Ignore, 0;
# force source to destination
IP_pkt:
sourcePeerAddress & 255.255.255.0 = 130.102.128.0: gotoact, qwerty;
sourcePeerAddress & 255.255.255.0 = 130.102.190.0: pushpktto, srcmatched;
sourcePeerAddress & 255.255.255.0 = 130.102.108.0: pushpktto, srcmatched;
 null & 0 = 0: retry, 0;
 null & 0 = 0: ignore, 0;
# source subnet matches the ones we are interested in
srcmatched:
 destpeeraddress & 255.255.255.0 = 130.102.128.0: gotoact, destmtc;
 destpeeraddress & 128.0.0.0 = 0.0.0.0: gotoact, to_a;
 destpeeraddress & 192.0.0.0 = 128.0.0.0: gotoact, to_b;
 destpeeraddress & 224.0.0.0 = 192.0.0.0: gotoact, to_c;
 null & 0=0: gotoact, next;
 destpeeraddress & 240.0.0.0 = 0: countpkt,0;
count_pkt:
 null & 0 = 0: count, 0;
to_a:
 destpeeraddress & 255.0.0.0 =0: pushpkttoact, count_pkt;
to_b:
 destpeeraddress & 255.255.0.0 =0: pushpkttoact, count_pkt;
to_c:
 destpeeraddress & 255.255.255.0 =0: pushpkttoact, count_pkt;
# record full sourcepeeraddress if coming from 130.102.128.0
qwerty:
 sourcePeerAddress & 255.255.255.255 = 0: pushpktto, srcmatched;
# record full destpeeraddress if going to 130.102.128.0
destmtc:
 destpeeraddress & 255.255.255.255 = 0: pushpkttoact, count_pkt;
#
STATISTICS
#
FORMAT FlowRuleSet FlowIndex FirstTime "  "
  SourcePeerType SourcePeerAddress DestPeerAddress "  "
#   SourceTransType SourceTransAddress DestTransAddress "  "
  ToOctets FromOctets;
#
# end of file

Thanks
David Vu                             | Prentice Centre
Email  [email protected]              | The University of Queensland
Phone: +61 7 3365 3941               | Brisbane Q  4072
FAX:   +61 7 3365 4477               | Australia

From netramet-owner  Tue Aug 15 09:42:48 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id JAA27745 for netramet-outgoing; Tue, 15 Aug 1995 09:27:35 +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 JAA27330 for <[email protected]>; Tue, 15 Aug 1995 09:19:46 +1200
Received: from flagship.csuohio.edu by ccvcom.auckland.ac.nz
(PMDF V4.3-7 #2864) id <[email protected]>; Tue,
15 Aug 1995 09:16:25 GMT+1300
Received: by flagship.csuohio.edu (NX5.67e/NeXT-2.0) id AA07468; Mon,
14 Aug 95 17:14:05 -0400
Received: by NeXT.Mailer (1.118.2)
Date: Mon, 14 Aug 1995 17:14:04 -0400
From: Nemtallah Daher <[email protected]>
Subject: Netramet on NeXT 3.3 ?
To: [email protected]
Message-id: <[email protected]>
MIME-version: 1.0 (NeXT Mail 3.3 v118.2)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk


hi all,

has anyone managed to get netramet working on a nextstation?  i am having a
hard time getting it to compile.  any help would be appreciated.  thank you
very much.

Nemtallah Daher
Cleveland State U.

From netramet-owner  Mon Aug 21 18:45:10 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id SAA24686 for netramet-outgoing; Mon, 21 Aug 1995 18:28:49 +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 SAA23992 for <[email protected]>; Mon, 21 Aug 1995 18:17:45 +1200
From: [email protected]
Received: from AARNet.ncom.nt.gov.au by ccvcom.auckland.ac.nz
(PMDF V4.3-7 #2864) id <[email protected]>; Mon,
21 Aug 1995 18:13:04 GMT+1300
Received: from MailHub.ncom.nt.gov by aarnet.ncom.nt.gov.au (PMDF V4.3-7 #4927)
id <[email protected]>; Mon, 21 Aug 1995 15:41:50 CST
Received: from nmdl01 (nmdl01.ncom.nt.gov.au) by mailhub.ncom.nt.gov.au
(PMDF V4.3-7 #4927) id <[email protected]>; Mon,
21 Aug 1995 15:38:49 CST
Date: Mon, 21 Aug 1995 15:33:40 +1030
Subject: Problems starting NeMaC
To: [email protected]
Message-id: <[email protected]>
X-VMS-To: SMTP%"[email protected]"
Content-transfer-encoding: 7BIT
Sender: [email protected]
Precedence: bulk

I have the meter running on a Digital PC using a CRYNWYR packet driver.
When I start NeMaC I get the following messages:
Using MIB file: /usr/netramet/mib/mib.txt
Mangled packet
Mangled packet
Mangled packet
Mangled packet
Couldn't get meter info from 150.191.176.140!
  Does community writemeter have read or write access to the meter?
No meters to monitor !!!

Any ideas as to what is causing the problems?

David Hoey
Department of Transport and Works
NCOM Services (computing and communications)
NT Government Australia
[email protected]

From netramet-owner  Tue Aug 22 02:13:56 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id BAA12396 for netramet-outgoing; Tue, 22 Aug 1995 01:58:55 +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 BAA12104 for <[email protected]>; Tue, 22 Aug 1995 01:49:25 +1200
Received: from nrnsinc.on.ca (rads.dnd.ca)
by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Tue,
22 Aug 1995 01:49:18 GMT+1300
Received: from nrnsinc.on.ca by nrnsinc.on.ca id <[email protected]>; Mon,
21 Aug 1995 09:46:54 -0400
Date: Mon, 21 Aug 1995 09:46:51 -0400 (EDT)
From: Ken Robinson <[email protected]>
Subject: Re: Problems starting NeMaC
In-reply-to: <[email protected]> from
"[email protected]" at Aug 21, 95 03:33:40 pm
To: [email protected]
Cc: [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: DREnet Network Coordination Centre, 1-613-599-7860, 1-613-990-9302
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL21]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Content-length: 919
Sender: [email protected]
Precedence: bulk

>
> I have the meter running on a Digital PC using a CRYNWYR packet driver.
> When I start NeMaC I get the following messages:
> Using MIB file: /usr/netramet/mib/mib.txt
> Mangled packet
> Mangled packet
> Mangled packet
> Mangled packet
> Couldn't get meter info from 150.191.176.140!
>    Does community writemeter have read or write access to the meter?
> No meters to monitor !!!
>
> Any ideas as to what is causing the problems?

Any chance it's a hardware problem?  Perhaps you have a conflict with the
ethernet card and some other card in the system. (eg, both ethnet and serial
using IRQ3).

I think you may also have problems with some ethernet cards and CPU
caches.  You may need to exclude a particular region.

--
Ken Robinson
DREnet Network Coordination Centre (NCC)
NRNS Incorporated
Phone: 613.599.7860  Fax: 613.599.7739
135 Michael Cowpland Dr., Suite 302
Kanata, Ontario K2M-2E9

From netramet-owner  Thu Aug 24 16:16:59 1995
Received: (from majordom@localhost) by net.auckland.ac.nz (8.6.12/8.6.12) id PAA23122 for netramet-outgoing; Thu, 24 Aug 1995 15:59:27 +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 PAA22884 for <[email protected]>; Thu, 24 Aug 1995 15:53:51 +1200
Received: from ccu1.auckland.ac.nz by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864)
id <[email protected]>; Thu,
24 Aug 1995 15:53:46 GMT+1300
Received: (from nevil@localhost) by ccu1.auckland.ac.nz (8.6.12/8.6.12)
id PAA10708 for [email protected]; Thu, 24 Aug 1995 15:53:43 +1200
Date: Thu, 24 Aug 1995 15:53:42 +1200 (NZT)
From: J Nevil Brownlee <[email protected]>
Subject: Re: Accounting Meter Rules
In-reply-to: <[email protected]> from
"[email protected]" at Aug 15, 95 01:52:48 pm
To: [email protected] (NeTraMet mailing list)
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: 3155
Sender: [email protected]
Precedence: bulk

Hello all:

I've been home for nearly two weeks, and I'm just catching up on e-mail!

Quite a few people have asked questions recently about NeTraMet
on the PC, and about problems with Packet Drivers.

To address these I've written a short note on 'getting started with
Packet Drivers,' copy attached below.

Cheers, Nevil

+-----------------------------------------------------------------------+
| Nevil Brownlee       [email protected]        Deputy Director |
|   FAX: 64 9 373 7425      Computer Centre, The University of Auckland |
| Phone: 64 9 373 7599 x8941   Private Bag 92019, Auckland, New Zealand |
+-----------------------------------------------------------------------C

NeTraMet and 'Packet Drivers:' brief notes

1) The Packet Drivers are now known as the CRYNWR drivers.
  Information about them - including how to get them - is available
  from   http://www.crynwr.com/crynwr/home.html

2) To use a packet driver you must start it up; normally you'd do so
  as part of your AUTOEXEC.BAT file.  The steps are:
     a) Select the packet driver for your ethernet card from the
        CRYNWR collection.  Read the documentation file to see what
        it's command-line parameters are (they vary slightly for
        different cards).
     b) Start it up.  For example I use
        loadhigh WD8003E -n 0x60 5 0x300

3) To test whether the packet driver is installed properly, there are
  a set of programs in the CRYNWR collection.  Their names start with
  'pkt'  For example, if you are using 0x60 for your packet driver
  interrupt (as in the example above),
     pktchk  0x60      tells you that the driver is present in memory
     pktaddr 0x60      shows you the card's ethernet address
     pktstat 0x60      shows you how many packets have been
                          sent and received
     pktmode 0x60      shows you what mode the driver is currently in

4) NeTraMet needs to be in mode 6 ('promiscuous' mode) to let it see
  every packet on the wire.  Some cards don't allow the driver to use
  mode 6.  You can test this using pktmode, e.g.
     pktmode 0x60 6
  will try to set the mode for interrupt 0x60 to 6.  If it can't do
  this it returns an error message.  The only way round this is to
  find another type of card.

5) When NeTraMet starts up it begins by setting the packet driver mode.
  Many of the error messages are straightforward, e.g.
     NO PACKET DRIVER FOUND,            while others, e.g.
     ERROR 0x80 setting receive mode    are not.
  The hexadecimal number in these is the error code returned by the
  packet driver; these are documented in the Packet Driver Specification,
  which is available from the CRYNWR server (URL above).

6) If you run NeTraMet and don't see any packets, as indicated by zeroes
  in the 'packet counts' (top left) part of the screen display, this
  usually means that the packet driver failed to initialise, but no
  no error was reported by the driver (yes, it can happen like this),
  or that the network hasn't been connected to the card.

------------------------------------------------------------------------

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.