Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!ut-emx!sirius.cc.utexas.edu!spurgeon
From: spurgeon@sirius.cc.utexas.edu (Charles E. Spurgeon)
Newsgroups: comp.dcom.lans
Subject: Re: 10Base-T hubs
Message-ID: <47323@ut-emx.uucp>
Date: 17 Apr 91 13:24:49 GMT
References: <1991Apr10.150801.2519@ux1.cso.uiuc.edu> <1991Apr15.214932.9635@jhereg.osa.com> <1991Apr16.182217.6151@netcom.COM>
Sender: news@ut-emx.uucp
Reply-To: spurgeon@sirius.cc.utexas.edu.UUCP (Charles E. Spurgeon)
Distribution: usa
Organization: UTexas Computation Center, Austin, Texas
Lines: 33

In article <1991Apr16.182217.6151@netcom.COM> jbreeden@netcom.COM (John Breeden) writes:
>
>I've been paying around with a new hub - AT&T's "smart" hub - includes an
>SNMP agent (save the pink little but from work) and also has another in-
>teresting feature - security.
>
(details of hub operation deleted)
>
>But the most interesting feature is this - a frame sent to a specific
>mac address only shows up at the port that mac address is attached to. All
>other ports get the header with the data field blank! (filled with 1s & 0s)
>- you can't capture other people's traffic! only your own! (they're doing the
>filtering during the normal buffer copy in the repeater - so there is no
>impact on delay - it's within 10baseT spec).
>

That's interesting.  The old 802.3c-1988 repeater spec I have states
in 9.5.5 ("Data Handling"):

"The repeater unit, when presented a packet at any of its ports, shall
pass the data frame of said packet intact and without modification,
subtraction, or addition to all other ports connected with the
repeater unit.  The only exceptions to this rule are when contention
exists among any of the ports or when the receive port is partitioned
as defined in 9.9.6."

I wonder if this repeater spec has been changed in the last few years?

-ces
Charles Spurgeon     
spurgeon@emx.utexas.edu
---------------------------------------------------------------------------
Rule #1. Don't sweat the small stuff.