HDTenEightyP/NetNews huggingface dataset:
From: pat@hprnd.rose.hp.com (Pat Thaler)
Subject: Re: UTP, voice and data together ??
Date: Fri, 11 Dec 1992 22:29:56 GMT
Distribution: w
Organization: Roseville Networks Division
X-Newsreader: TIN [version 1.1.8 PL6]

Peter Wood (xtpw@trentu.ca) wrote:
: 
: 1) We're running voice and data inside the same 4-pair wire. I'm a dcom
: idiot, but I wonder what a ring coming down the wire does to the data
: pairs. Are we on the road to hell in this regard as well ?

When developing 10BASE-T, we spent a lot of time looking at voltages
induced on the 10BASE-T pairs when sharing a 4-pair cable.  We designed
10BASE-T to work in this situation.  It can tolerate hits of up to 
264 mV without producing an error and it has input filters that help
hold the impulse noise from a phone ringer to under that.  

One caveat, there is no standard or regulation covering phone ringers.  
With deregulation, PBX suppliers in the US can do what they like.  We tried 
to test particularly bad old style ringers, but it is possible that an 
exceptionally bad ringer could cause higher noise.  The worst noise 
comes when the phone is taken off hook during a ring.

Other uses of twisted pair wire may not tolerate phone rings without
generating errors.  Therefore, it is good practice to put in separate
4 pair cables for phone and data.  That is what is recommended in 
EIA/TIA 568 Generic Building Wiring.  If you are doing a new installation,
this is what I would recommend.  
: 
: 2) Can some kind soul direct me to references on 10BaseT cabling ? In
: the simplest instance, this would be specs for each category of UTP
: cabling. 
: 
10BASE-T was designed for what is now called Category 3 cable.  The specs
relevant to 10BASE-T are in the 10BASE-T standard IEEE 802.3i.  More
general specs on how to wire a building are in the EIA/TIA 568 Generic
Building Wiring spec which was written pre-Category.  The Category 4/5
specs can be found in EIA/TIA TSB 36 (for the wire) and TSB 40 (connectors).

Pat Thaler
From: loeblich@nz.dlr.de (Michael Loeblich)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: PC-NFS?
Date: 16 Dec 92 06:34:07 GMT
Distribution: na
Organization: DLR-Neustrelitz

swisher@cs.utexas.edu (Janet M. Swisher) writes:

>Could someone give me pointers on where to find information on PC-NFS
>(including a more appropriate newsgroup, if there is one)?

>	Thanks,
>	Janet

Yes, try comp.protocols.nfs.

-- 
Michael Loeblich, DLR Neustrelitz, loeblich@nz.dlr.de
From: George Loftus <George_Loftus@Brown.Edu>
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: shielded vs. unshielded for 10baseT
Date: 15 Dec 1992 20:30:54 GMT
Organization: Brown University - CIS
Distribution: world
NNTP-Posting-Host: cis_staff-kntx21.cis.brown.edu
X-UserAgent: Nuntius v1.1.1d7
X-XXMessage-ID: <A753A7A60D01B06B@cis_staff-kntx21.cis.brown.edu>
X-XXDate: Tue, 15 Dec 92 20:17:58 GMT

Subject: shielded vs. unshielded for 10baseT
From: Bill Marshall, marshall@cs.iastate.edu
Date: Mon, 14 Dec 1992 21:40:40 GMT
In article <marshall.724369240@stimpy.cs.iastate.edu> Bill Marshall,
marshall@cs.iastate.edu writes:
>On the campus of my undergrad institution there is a dorm that is
>wired with 2 pair + ground shielded cable with each pair individually
>shielded. It was put in place with serial communications in mind.
>
>Now there is talk of removing this wiring (which has never been used)
>and replacing it with 4 pair unshielded level 3 cabling. (I think)
>
>I'm interested in what the 10baseT specs say and advice on future
>cabling requirements. 
>
>Currently there is a lot of mis-information floating about.  People
>there are saying the current cabling is "too slow".
>
>Thanks,
>Bill
>
>--
>			    Bill Marshall
>		     Computer Science Department
>			Iowa State University
>		       marshall@cs.iastate.edu

Conventional wisdom, these days, says to install Level 5 UTP, although
level 3 is all that is needed to meet the 10BaseT spec. The "existing"
cable you describe does not sound like it is compliant. 

There is a good article on the EIA/TIA 568 specifications in the November
1992 issue of Data Communications magazine, it may be helpful.

I don't know what they mean by "too slow" except that because the wiring
is non-compliant there may be an excess of collisions.
From: kgirrard@oregon.uoregon.edu (Ken Girrard)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: RJ-45 Connectors
Date: 15 Dec 92 01:03:00 GMT
Article-I.D.: oregon.14DEC199217032672
Distribution: world
Organization: University of Oregon
NNTP-Posting-Host: oregon.uoregon.edu
News-Software: VAX/VMS VNEWS 1.41

> 
> My question is:  Are there any manufacturers of RJ-45 connectors that anyone
> here has found less reliable than others?  Also, when crimping, is is better
> to apply lots of pressure or use the minimum possible (I'm wondering if the
> cable conductors are being broken in the process).
> 
Some combinations of plugs and jacks can be problematic.  I try and use
AMP or Panduit plugs, and have Hubble jacks in some buildings.  Hubble
uses a wide, flat wire in their jacks that sometimes won't fit in the
slots of some plugs, especially if they aren't crimped well (if spades
don't crimp the first time, don't try and make it work -- cut off the plug
and try again).
Newsgroups: comp.dcom.lans.ethernet
From: kewta@solomon.technet.sg (Kew Tow Ann)
Subject: Etherswitchers
Organization: TECHNET, Singapore
X-Newsreader: TIN [version 1.1 PL8]
Date: Sun, 13 Dec 1992 17:03:03 GMT

I am new in the area of networking and I came across this term
etherswitchers. Can someone tell me what this is and where I can get more
information about it?
Thanks and regards.
From: george@ache.mad.adelaide.edu.au (George Travan)
Newsgroups: comp.dcom.lans.ethernet
Subject: TDR error
Date: 15 Dec 1992 05:43:31 GMT
Organization: University of Adelaide
Distribution: world
Reply-To: george@frodo.ua.oz.au
NNTP-Posting-Host: ache.mad.adelaide.edu.au
Keywords: TDR
Originator: george@ache.mad.adelaide.edu.au


I have just put a PC on a thin wire ethernet network. It has a NI5210
card with packet drivers.
When the pc boots I get the following:

TDR:0 Clocks away is a short (not completely reliable)

When the boot finishes, I can telnet Ok and their seem be little or no
errors (reflections/retransmissions) on the server.

Anyone know what this may be due to??

/Geo


-- 
                  George Travan "A Rebel Without A Clue!"                   
                  E-mail: george@ache.mad.adelaide.edu.au                       
     Phone: (Australia) +61 08 228 5968   Fax: (Australia) +61 08 224 0464  
        University of Adelaide,G.P.O Box 498 Adelaide, AUSTRALIA 5001       
Newsgroups: comp.dcom.lans.ethernet
From: seifert@netcom.com (Rich Seifert)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Bad CRC's (was late collisions)
Date: 11 Dec 92 19:15:06 GMT
Organization: Networks & Communications Consulting

In article <1992Dec11.165443.7591@ucsu.Colorado.EDU>, barr@tramp.Colorado.EDU (BARR DOUG) writes:
> >A transmitting station (properly behaving) NEVER stops listening for
> >collisions, regardless of how far into the frame it has gotten. The problem
> >with late collisions is that certain implementations, upon detecting a 
> >late collision, cannot just go back and retransmit the frame (after
> >backing off, etc.), because it may have already released the buffers
> >from the beginning of the frame. This is common in chain-linked
> >DMA-type implementations. The minimum buffer is kept at 64 bytes, so that
> >the buffer will never have been released during a normal collision, and
> >backof and retransmission can occur. For late collisions( which  indicate
> >a fault condition, either in a controller or the cable design), the
> >silicon will report late collision (whether the driver tells higher layer
> >software is driver-dependent) to the driver, and go to the next frame.
> >There is little else the controller can do.
> >
> >If late collision retransmission does not occur at the data link, it
> >would appear to the Transport protocol (if ther is one) as a lost
> >packet, and retransmission should occur at Transport (e.g., TCP).
> >
> 
> What happens when there is a bad CRC (with TCPIP frames)? Other frames?
> 

Collision detection, backoff and retry is a transmitter function.
CRC checking is a receiver function. If a bad CRC is detected, the
controller will discard the frame (and possibly report it to management
or bump ap a counter). From the point of view of TCP (or any connection-
oriented transport protocol) it just looks like a lost frame, znd
is recovered using the normal time-out and retransmit strategy.


-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"
Newsgroups: comp.dcom.lans.ethernet
From: pat@hprnd.rose.hp.com (Pat Thaler)
Subject: Re: flat cable and 10BaseT (was Re: 10baseT Question)
Date: Fri, 11 Dec 1992 22:05:23 GMT
Organization: Roseville Networks Division
X-Newsreader: TIN [version 1.1.8 PL6]

: In article <1992Dec3.214905.24412@trentu.ca> xtpw@trentu.ca (Peter Wood) writes:
: 
: >A quick question. Our local 10BaseT lan uses flat silver telephone cable
: >and RJ-45 connectors in between the NICs and the connector on the end of
: >the UTP run. Similarly, at the hub end, we have the same inbetween the
: >punch down block and the hubs.
: 
: >Is this legal ? Is it good :-) ? Are there any alternatives ?
: 
If this is what is called "silver satin," it is not twisted and will not
meet 10BASE-T specs for crosstalk.  It often results in flakey connections
and can cause poor network performance or even non-operation.  It is 
commonly used to connect phones.

However, I have also seen a cable from AT&T that looks pretty flat but,
if you open it up, you will find that it is twisted.  The cable I saw
was grey and met the crosstalk spec.  It was bulkier than silver satin.
So there are some cables that look flat but are twisted.  If you have
any doubts, you should be able to check out the part number on the cable
with the manufacturer.

Pat Thaler

Newsgroups: comp.dcom.lans.ethernet
From: mwb@jpradley.jpr.com (Michael Brown)
Subject: Intel PC-Link/PCL-2
Organization: Unix in NYC
Date: Fri, 11 Dec 1992 20:28:29 GMT

I'm posting this for a friend w/o Usenet access. He's looking for information
on an 8-bit Ethernet board called either the Intel PC-Link or PCL-2. This
board supposedly has an 80186 processor on board and is related to the 
Cubix Quick Link boards. Any technical information, or on available drivers
would be appreciated.

Thanks in advance,
MB

-- 
Michael Brown          mwb@jpradley.jpr.com or uunet!murphy!jpradley!vtssys!mike
VTS Systems            718-968-1971
871 East 55th Street   Brooklyn, NY 11234
-------------------------------------------------------------------------------
Newsgroups: comp.dcom.lans.ethernet
From: seifert@netcom.com (Rich Seifert)
Subject: Re: BRouter question.
Organization: Networks & Communications Consulting
Date: Wed, 16 Dec 1992 22:52:01 GMT

In article <887@quirm.terminus.ericsson.se>, srl@terminus.ericsson.se (Steve Langstaff) writes:
> I have a couple of questions regarding the operation of BRouters....
> 
> 1. What *should* a BRouter do about duff CRC on a received frame?
> 
> 2. What *do* BRouters do about...
> 
> I know that bridges should just bridge frames, regardless of CRC errors
> and that routers should discard frames with duff CRCs, so what should
> the (illegitimate crossbred) BRouters do?
> 

Since there is no agreed-upon definition of a Brouter, this is a tough 
questions. Some people call it a brouter when it is (architecturally)
a bridge, but has some intelligent link selection capability (e.g.,
can use multiple WAN links, load share, etc.). Some people (including
myself) considera brouter to be a bridge and a router in the same box.
Thus, it would route those packets which it understandt the network layer
protocl, and bridge others.

In any case, BOTH bridges and routers will discard frames with bad CRC.
A bridge which forwards a frame with a bad received-CRC is in violation
of the industry standard 802.1 specification. In practice, this won't
cause major problems, since the end station will discard the frame
(a bad CRC is still a bad CRC!).



-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"
From: srl@terminus.ericsson.se (Steve Langstaff)
Newsgroups: comp.dcom.lans.ethernet
Subject: BRouter question.
Date: 16 Dec 92 16:43:39 GMT
Reply-To: srl@terminus.ericsson.se
Distribution: world
Organization: Camtec Electronics (Ericsson), Leicester, England

I have a couple of questions regarding the operation of BRouters....

1. What *should* a BRouter do about duff CRC on a received frame?

2. What *do* BRouters do about...

I know that bridges should just bridge frames, regardless of CRC errors
and that routers should discard frames with duff CRCs, so what should
the (illegitimate crossbred) BRouters do?


---

Thanks,
	Steve.
From: hr@yoda.cul-ipn.uni-kiel.de ()
Newsgroups: comp.dcom.lans.ethernet
Subject: Packet-Driver for Intel EtherExpress 16
Date: 15 Dec 1992 09:37:14 GMT
Organization: Department of Computer Science, University of Kiel, Germany
Distribution: world
NNTP-Posting-Host: yoda.cul-ipn.uni-kiel.de

We have an Intel EtherExpress 16-card in
our PC and want to connect to TCP/IP with
NCSA-Telnet.
With several PacketDrivers we have no success.
So my questions:

    1.) Is anyone using the IntelEtherExpress16 
        with TCP/IP and how ?
        For example with a packetDriver or so.
    
    2.) Is anyone using NCSA with option 'hardware = packet'
        and what other options must then be included
        in config.tel
        
        Thank you for your help,
        Heiko

Newsgroups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip
From: "Chris Martin" <wk04331@psilink.com>
Subject: Re: Different Subnets on one Ethernet segment?
Reply-To: chris.martin@amd.com
Organization: Advanced Micro Devices, Inc.
Date: Fri, 11 Dec 1992 16:10:04 GMT
X-Mailer: PSILink-DOS (3.3)

>DATE:   8 Dec 92 16:39:15 GMT
>FROM:   Art Berggreen <art@acc.com>
>
>In article <1992Dec8.091111.28843@penet.fi> an1880@anon.penet.fi writes:
>>
>>can anybody tell me, if I can have TWO different IP-subnets in ONE ethernet
>>segment???
>>
>>Just for illustration:
>>net: 141.33.0.0
>>subnet1: 141.33.128.0
>>subnet2: 141.33.160.0
>
>Sure, having multiple subnets on one wire is often used in many site's
>subnetting strategy.  Most routers can deal with assigning multiple
>subnets to their interfaces.  The biggest problem though, is that most
>host TCP/IP implementations only support one IP address on a physical
>interface, and thus they must be defined on only one subnet.  This
>means that traffic between subnets may have to be sent via a router.
>(BSD Unix derived implementations usually can use a direct subnet route
>to avoid the extra hop)

In the scenerio of multiple subnets on one physical network in the
presence of not-incredibly-intelligent TCP/IP hosts, wouldn't the
router generate an ICMP redirect to the sender for hosts on the same
cable but different subnet?  If this is the case, then the extra 
hop effect isn't all that bad after all.

	--Chris
	chris@amd.com
	postmaster@amd.com
Newsgroups: comp.dcom.lans.ethernet
From: Mike Turpin <dmt@ornl.gov>
Subject: Re: Reliability (?) of Cabletron MT-800 Multiport XCeiver
X-Xxmessage-Id: <A754F1D45C01963D@dmtmac.ctd.ornl.gov>
X-Xxdate: Wed, 16 Dec 92 19: 46:44 GMT
Organization: Martin Marietta Energy Systems
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 16 Dec 1992 20:40:08 GMT

>> >But in the past year four of our MT-800s have toasted their
>> >power supplies, out of a population of about twenty....
>
>Thanks guys - misery loves company.  Same here.  We've had several die
>suddenly over the last couple of years - 2 within the last 6 weeks or so.
>
We've had a similar experience here.  Out of 30 units we had 8 croak due
to power supply problems.  All of the failed units had power supplies
identified as "Power General C7972-1Q".  Although they mumbled as they
did it, Cabletron replaced all the bad supplies at no charge (it seems
that there were many problems with supplies furnished from that vendor.)

While we're on the subject of chronic MT-800 problems, there's another
one that some of you may have experienced:  

In some later MT-800s the receiver sensitivity was increased.  Most times
this is no problem EXCEPT when one of the devices connected to the MT-800
has an AMD7992B chip.  This chip has higher than average crosstalk
between send/receive and when combined with the increased receiver
sensitivity of the MT800, this crosstalk is treated as real data.  The
result: extremely poor performance.  Cabletron didn't believe us at first
so we took them to a place where this was happening, showed it to them,
and then replaced the MT-800 with a DELNI.  The problem immediately went
away.  

Cabletron Engineering finally duplicated the problem, changed the design,
*and* retrofitted all of our MT-800s that we identified with this problem
(for free).
---
Mike Turpin
Martin Marietta Energy Systems, Oak Ridge, TN
dmt@ornl.gov
Newsgroups: comp.dcom.lans.ethernet
From: gary@sci34hub.sci.com (Gary Heston)
Subject: Re: how to get ethernet host name
Reply-To: gary@sci34hub.sci.com (Gary Heston)
Organization: SCI Systems, Inc., Huntsville, Al.
Date: Mon, 14 Dec 1992 17:56:58 GMT

In article <Bz4MLp.1L1@newsserver.technet.sg> dbsbanka@solomon.technet.sg (Teo Pit Koon) writes:
>We have a problem: How do we get an ethernet server's host name from a 
>workstation on the LAN.

Depends upon what software you're using. TCP/IP expects you to know it 
already, but there's a way to set up remote boot, NetWares' host will
answer a question, and other things work in other ways.

>Would appreciate any help. Thanks.

More info needed. BTW, there's not really any such thing as an "ethernet
server"; there are servers connected by ethernet, but they are hosts, 
database, or communications servers. Ethernet is just how they're connected.
 

-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chairman of the Board and the CFO speak for SCI. I'm neither.
"Data sheet: HSN-3000 Nuclear Event Detector. The [NED] senses the gamma
radiation pulse [from a] nuclear weapon." As if we wouldn't notice...
From: nelson@crynwr.com (Russell Nelson)
Newsgroups: comp.dcom.lans.ethernet
Subject: Ethernet card 
Distribution: world
Date: Fri, 18 Dec 92 16:54:38 GMT
Organization: Crynwr Software

In article <1992Dec18.014021.24510@fallst> tkevans@eplrx7.es.dupont.com writes:

   ccewch@nuscc.nus.sg (Wong Chee Heng) writes:
   
   >Can anyone suggest a brand of ethernet card with these features:

   >-have both Rj-45 and BNC connector, or with AUI connector
   >-auto-sense between these connectors
   >-Have NDIS drivers for DOS and OS/2 1.x and 2.0
   >-have 16-bit ISA and/or 32-bit EISA version
   >-reasonablly well perform, comparable to 3c503

   What's wrong with the 3c503?  It meets all your spec's
   above.  Well, it doesn't auto-sense which connector is
   connected, but it is software settable.  Yes, there is a
   BNC/Twisted Pair model, and it's a 16-bitter.

The 11.x 3c503 packet driver will auto-sense.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.
Newsgroups: comp.dcom.lans.ethernet
From: daniel@nstn.ns.ca (Daniel MacKay)
Subject: Re: MacSLIP
Organization: NSTN Network Operations Centre, Nova Scotia, Canada
Date: Sun, 13 Dec 1992 13:36:55 GMT

In <yatesbd-041292234056@pharm15.med.upenn.edu> yatesbd@pharm.med.upenn.edu 
	(Brian Yates) writes:

>Where can I find MacSLIP software and docs?

Seriously wrong newsgroup.  But since you asked- it's not shareware, it's
not PD, it's not copyleft.  Buy it for 50$US from Hyde Park Software/Box
7133/Austin, TX, 78713/USA.  Phone 512-454-1170, email info@hydepark.com.

I'm a satisfied customer.  Good product, good support.
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	902-494-NSTN
	Dalhousie University, Halifax, Nova Scotia, Canada
Newsgroups: comp.dcom.lans.ethernet
From: aboyd@quantum.on.ca (Andrew Boyd)
Subject: Re: le0: Transmit late collision - net problem?
Date: Fri, 18 Dec 92 19:49:54 GMT
Organization: Quantum Software Systems
Keywords: SunOS, twisted-pair Ether, Synoptics

In article <1992Dec16.181735@is.morgan.com> sergei@is.morgan.com 
(Sergei Poliakoff) writes:
>le0: Transmit late collision - net problem?
>Does anybody have any additional information, idea or pointers

Too many repeaters/hubs/concentrators between any two transmitters.

Excessive cable lengths (eg more than 185m of thin coax or 500m of 
thick coax in a segment).

Out-of-window collisions mean that small packets can get lost, which
makes the hardware guys feel bad.  This incurs higher-level timeouts,
and hurts your performance, but since software guys don't trust the
hardware guys not to lose packets anyways, any protocol will retransmit
a packet several times until an ACK comes back.  

Unless you've got a pathological case, where all your small packets
always get "lost".  Sorta like your bread always landing jelly side down.

----
#include <std.disclaimer>
From: ccewch@nuscc.nus.sg (Wong Chee Heng)
Newsgroups: comp.dcom.lans.ethernet
Subject: Ethernet card
Date: 15 Dec 92 05:47:06 GMT
Organization: National University of Singapore

Can anyone suggest a brand of ethernet card with these features:

-have both Rj-45 and BNC connector, or with AUI connector
-auto-sense between these connectors
-Have NDIS drivers for DOS and OS/2 1.x and 2.0
-have 16-bit ISA and/or 32-bit EISA version
-reasonablly well perform, comparable to 3c503

Any input is welcomed. Thank you in advance.  

--
Wong Chee Heng
Systems Programmer
ccewch@nuscc.nus.sg.
Organisation: European Space Operation Centre (E.S.O.C)
Date: Monday, 14 Dec 1992 09:14:35 CET
From: <RHUNTER@ESOC.BITNET>
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: 10baseT pin assignments

If you use AT&T PDS cabling you will indeed see that it IS using the twisted
pairs. Can someone else confirm this is the case for all manufacturers PDS type
systems? I suspect it is.

FYI pair 1 = white blue/blue white = pins 4 & 5
    pair 2= white orange/orange white = pins 1 & 2
    pair 3 = white green/green white = pins 3 & 6
    pair 4 = white brown/brown white = pins 7 & 8

Ray Hunter:
Cray Systems on contract to the European Space Agencyy
SMTP mail: RHUNTER@ESOC.BITNET
#include <std.disclaimer>
Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.misc
From: dcooper@bluff.compserv.utas.edu.au (David Cooper)
Subject: Re: BNC connectors
Followup-To: comp.dcom.lans.ethernet
Summary: Crimp versus solder BNC connectors
Keywords: crimp, solder, BNC
Organization: University of Tasmania at Launceston
Date: Tue, 15 Dec 92 09:13:21 GMT

In article <1992Dec14.160613.19205@sci34hub.sci.com>, gary@sci34hub.sci.com (Gary Heston) writes:

>
>Besides, the twisties won't work with the stranded-conductor cable (like
>Belden 9907) specified for 10Base2. Borrow a pair of crimpers, or use the
>solder style.
>

Having worked with lots of both crimp and solder style BNC connectors, I'd
opt for crimp anytime. Our failure rate with crimp has been a couple of
connections out of 100s in three years. The failure rate with solder,
particularly in student labs, was much higher. Problems with crook
connections in ThinWire segments are compounded by the fact that everyone in
that segment suffers until the offending connector is located and replaced.

cheers
David
-- 
David Cooper                        Senior Computing Officer (Academic)
Computing Services                                  UTL Network Manager
University of Tasmania                             Phone: +61 03 260598
PO Box 1214 Launceston 7250 Australia                Fax: +61 03 264232
Xref: sparky comp.dcom.lans.ethernet:2791 comp.protocols.tcp-ip:5607