FW: ATM, Fast PC, NFR, OpenBSD, Efficient Networks EN-155 (fwd)

[Mark Poepping]

I think Peter might have already posted about this project,
but in case there is further interest..
mark.

-----Original Message-----
From: owner-nfr-users at nfr.net [mailto:owner-nfr-users at nfr.net] On Behalf
Of Peter Van Epp
Sent: Tuesday, March 09, 1999 7:33 PM
To: nfr-users at nfr.net
Subject: Re: ATM, Fast PC, NFR, OpenBSD, Efficient Networks EN-155 (fwd)


	In my case I have an %80/%20 optical splitter (www.netoptics.com) in
the fibre path so with 2 ATM cards (one for each way) on my Argus/NFR
monitor
PC (Dual Pentium/Xenon capable MB with currently a single 450 Mhz P2 running
FreeBSD 3.1) connected to the %20 tap I can, assuming I can convince the
HARP
code to activate a known VCI without seeing signalling for it on the 2 PC
ATM
cards, (which is why the HARP source is important) I can silently tap the
PVC
carrying my Internet traffic in to a BPF interface and then to argus or NFR
as
usual. Since I am interested in establishing a receive session on a fixed
VCI
without trying to get the card to go promiscious (and it can transmit if it
likes, no one will hear it) this should be doable since HARP comes with
source
which should tell me what I need to do to convince it to do so.
	I suspect that getting performance in the NFR case would have to wait
for NFR to see the demand for ATM in the commercial version so they port
their
high performance mods to the HARP ATM stuff. Since argus only cares about
headers I expect it to be easier to get the required performance out of so
we will start there.
	This is far from simple, and we haven't successfully done it yet, but
at present it looks possible to me assuming we can get the time together to
do
what needs to be done. We have the hardware, we have the sources, we maybe
have
the knowledge, we are short on time to play however.
	This is getting pretty far from NFR related things, so perhaps we
should take this to private email if there is further interest.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada

>
> ANY ATM implementation WILL be problematic. It IS a switched acrhitecture
> after all. Or have you folks found something that will allow for passive
> sniffing of an ATM network that I've overlooked. All I've ever been able
to
> gleen are broadcasts over ELANs and traffic directed at the sensor.
>
> DuckMan
>
> Mark E. Duck, Owner
> AquaScape, Internet Services http://www.aquascape.com
>
> -----Original Message-----
> Axed for brevity 8)
>
> ****************************************************************
> TO POST A MESSAGE on this list, send it to nfr-users at nfr.net.
> TO UNSUBSCRIBE from this list, send the following text in the
> message body (not subject line) to majordomo at nfr.net
>
> unsubscribe nfr-users your-email-address
> ****************************************************************
>

****************************************************************
TO POST A MESSAGE on this list, send it to nfr-users at nfr.net.
TO UNSUBSCRIBE from this list, send the following text in the
message body (not subject line) to majordomo at nfr.net

unsubscribe nfr-users your-email-address
****************************************************************