HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: HELP: VAX to PC Communications questions?
From: Aengus Lawlor <RBYAML@rohvm1.rohmhaas.com>
Date: Tue, 22 Dec 1992 09:32:18 EST
Organization: Rohm and Haas Company

In article <BznHHv.A33@world.std.com>, dlowe@world.std.com (Miller Lowe) says:
>
>In our office we have Three Netware Servers, A couple
>of VAX and tens of PCs.  We want to connect the PCs to the VAX
>systems using a LAT terminal emulator such as SmartTerm 340.
>
>Here is the current cabeling picture;
>
>UNFORTUNATE QUESTION #3
>-----------------------
>If commercial software/hardware is the only answer, what do you
>suggest and how would it apply to our situation.  I really don't
>want to re-configure the whole system with a big expensive router
>in the middle.  I have a hard enough time attempting to justify
>additional PCs.
There is another possibility if you just want to use terminal emulation.
Consider installing TES on the VAX. Terminal Emulation Services from
Interconnections allows the VAX to speak IPX, and a client TSR on the
PC will use allow any PC comms package that uses INT-14 to login to the
VAX. If you haven't already bought Smart-Term for all your PCs, this might
even work out cheaper than the LAT solution. Because it's IPX based, you
won't have any routing problems getting through the Novell server.

A similiar solution would be to install some TCP/IP package on the VAX,
and use Telnet, but the management of such a solution might be a headache.

I can dig out Interconnections phone number, if you want. (I'm just a
satisfied customer).
>
>
>Any comments would be greatly appricated.  I am very new to DECNET
>requirements and still being a neophyte with TCP/IP and IPX I am stuck!
>
>
>Thanks in advance!
>
>D. Miller Lowe
>Email: dlowe@world.std.com
Aengus
--
RBYAML@ROHMHAAS.COM                    Aengus Lawlor
RBYAML@ROHVM1.BITNET                   (who used to be ALAWLOR@DIT.IE)
"How about some of that famous Dublin wit, Barman?"
"Certainly, sir. Would that be Dry or Sparkling?"
Organization: Stanford Linear Accelerator Center
Date: Monday, 28 Dec 1992 17:24:33 PST
From: Tim Streater   (415) 926-2743 <STREATER@SLACVM.SLAC.STANFORD.EDU>
Newsgroups: comp.dcom.lans.ethernet
Subject: Dec and IEEE Spanning Tree differences

I am trying to understand spanning tree a little better, particularly as we
have Cisco routers doing bridging, and bridges from DEC (LANBridge 150) and
NAT (LAN100M).

As I understand it there are two spanning tree algorithms, so-called DEC and
IEEE. Bridges implementing these protocols exchange multicast packets between
themselves in order to decide who should go into backup mode, in the case where
bridges are connected redundantly in loops.

In Radia Perlman's book "Interconnections" she mentions that there is a special
multicast address assigned to "all bridges", but does not then say what the
address is.

I would like to know:

1) What this multicast address is and are there two of them, one for the DEC
   and one for the IEEE protocols?

2) Radia Perlman also describes the format of the multicast packets. Are there
   any differences here between the two algorithms?

We plan to have the Cisco routers running the DEC protocol and the bridges
running IEEE, with no mixture of bridge vendors on a given subnet. Is this a
sensible scheme?

Thanks - Tim Streater / SLAC Network Development.
Newsgroups: comp.dcom.lans.ethernet
From: ffuentes@tolten.puc.cl (Fernando Fuentes SCC)
Subject: Group bit in IEEE 802
Organization: Pontificia Universidad Catolica de Chile
X-Newsreader: TIN [version 1.1 PL8]
Date: Mon, 21 Dec 1992 16:06:38 GMT

In IEEE 802 standard, in the address field there is a bit called
group/individual bit, that is intended to be used for multicast (send a
message to some type of servers for instance).

I would like to know what applications use this facility, and at what
level the bit is set (who sets it)

I will appreciate any information


Fernando Fuentes
ffuentes@tolten.puc.cl

Newsgroups: comp.dcom.lans.ethernet
From: rich@grebyn.com (Richard Lawrence)
Subject: Re: le0: Transmit late collision - net problem?
Keywords: SunOS, twisted-pair Ether, Synoptics
Organization: Grebyn Timesharing
Date: Tue, 22 Dec 1992 03:55:02 GMT

In article <1992Dec16.181735@is.morgan.com> sergei@is.morgan.com (Sergei Poliakoff) writes:
>
>We are tracking an uncommon condition : having enabled a ledebug
>in SunOS kernel,  we discovered fair amount of 
>
>le0: Transmit late collision - net problem?
>
>appearing in syslogs of stations on just one subnet. I can reproduce it on 
>any workstation on that segment by forcing massive transfers from the 
>workstation, which points me towards some network-related rather then 
>system related explanation. It never occurs on other subnets.

Which type of UTP cabling are you using? You may have stretched past
your delay budget...also, note that even if you force if from every
station and get late collisions, it STILL might be another station that
is attempting to transmit erroneously (in other words, you jam the
wire with traffic from station A, and sooner or later station B wants to
send a packet for some reason (ARP, whatever) and collides).

If you have managment options on your Synoptics concentrators (you
didn't specify which ones you have) you can get diagnostic information
from the concentrator itself. It will tell you to the port level about
conditions such as late collisions. 

>
-- 
Rich Lawrence, Synoptics Systems Engineer  DOD#9630  rich@grebyn.com
     '92 Seca II "Yuri"  CI$:71101,2272  GEnie:R.LAWRENCE14
   216 years ago my government gave me certain inalienable rights.
     Since then, they've been trying to correct their mistake.
Newsgroups: comp.dcom.lans.ethernet
From: krsato@srv.PacBell.COM (Kenn Sato)
Subject: Mfg MAC Addresses
Organization: Pacific * Bell
Distribution: usa
Date: Mon, 28 Dec 1992 19:41:31 GMT

I'm sorry to be using bandwidth for this FAQ-like request, but ...
does anyone out there have the latest (relative) listing of manufacturer's
MAC addresses? And could they post it or e-mail it to me.  We are doing
a little network analysis and have come across '00 60 8C' and can't figure
out who the vendor is. Any help would be greatly appreciated.

Thanks and happy holly-daze!!!

Kenn Sato
Pacific Bell, LAN Management Center
510/901-9215
krsato@dcg.pacbell.com

Newsgroups: comp.dcom.lans.ethernet
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Subject: Ethernet FAQs
Summary: Is the an Ethernet FAQ and if so where is it?
Keywords: Ethernet LAN Local Area Network FAQs
Organization: Boeing Computer Services
Date: Thu, 31 Dec 1992 04:56:26 GMT


The summary says it all.
Is there an Ethernet FAQ and if so where is it?

Many thanks,


Jeff Silverman, Boeing
Newsgroups: comp.dcom.lans.ethernet
From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Information about BOOTP
Summary: How do I set up a BOOTP server?
Organization: Queen's University
Date: Tue, 29 Dec 1992 15:29:13 GMT

I'm looking for information about setting up a BOOTP server.  We have a 
couple of dozen PCs in a lab, and it would make maintenance a lot easier if 
they could all have the same configuration.  A book reference would be fine 
if the process is involved.

Apologies in advance if this is a FAQ, but I couldn't find a FAQ list.  
Please respond by email, and I'll summarize.


Duncan Murdoch
dmurdoch@mast.queensu.ca
Newsgroups: comp.dcom.lans.ethernet
From: rich@grebyn.com (Richard Lawrence)
Subject: Followup: TR<->8209<->Ethernet bootp/tftp problem
Organization: Grebyn Timesharing
Date: Wed, 23 Dec 1992 07:56:17 GMT

A few people have asked for the results of this, so I'm going to post a
followup to my posting of a couple of weeks ago concerning bootp/tftp
problems across an 8209 translational bridge (I forgot! so shoot me! :-)
).

The basic problem as stated was that bootp never worked, and tftp
sporadically, across an 8209 bridge at a customer site. I spent a little
time with a protocol analyzer and came to the following conclusions:

1) bootp will never work across an 8209. Reference RFC 1951 (check that,
it's off the top of my head) for the bootp protocol definition. The
basic answer is that a bootp broadcast request contains *within* the
datagram the MAC address of the requestor. There is no ARP or similar
resolution from IP to MAC layer, it is assumed that the bootp server
will respond to the MAC address contained in the bootp request. I
suppose this was done so that you could have proxy bootp requests (ie, a
machine with an intelligent device attached could request that it be
booted, even if the device itself wasn't smart enough to send the
request).

In any case, the 8209 will never see the embedded MAC address (it's just
data to the 8209) and therefore won't work it's translation voodoo on
it. The only solution here is to use a router with bootp helper, which
*will* modify the embedded MAC address if appropriate.

2) As I suspected, the tftp problems were related to ARP difficulties.
Since the 8209 is a bridge and cannot perform proxy ARP, we run into
much the same problem as above with bootp. Take this example: machine A
is a token ring Unix station, machine B is an ethernet station. B makes
a tftp read request. A broadcasts an ARP for B's IP address. Said ARP
crosses the 8209, reaches B, and B correctly responds "that's my IP
address, here is my MAC address". When this response crosses the 8209,
again it modifies the send/receive appropriately for the packet itself,
but the contained MAC address is left untouched. So machine A receives a
response to its ARP with an embedded MAC address, *but the embedded
address is the correct ethernet MAC, not the translated one*.
Afterwords, A attempts to send data to B using the ethernet MAC address,
and the 8209 takes that MAC and crunches it up because it assumes it's a
Token Ring address that needs to be modified.

Anyway, that's that. The two solutions available were to turn off
translation in bridging (not feasible) or replace with a router in the
same configuration. Eventually a router will be put in place, for now
the customer is using a bootp server on the ethernet side.
-- 
Rich Lawrence, Synoptics Systems Engineer  DOD#9630  rich@grebyn.com
     '92 Seca II "Yuri"  CI$:71101,2272  GEnie:R.LAWRENCE14
   216 years ago my government gave me certain inalienable rights.
     Since then, they've been trying to correct their mistake.
Newsgroups: comp.dcom.lans.ethernet
From: seifert@netcom.com (Rich Seifert)
Subject: Re: Adapter to use all 4 pairs in 10BaseT
Organization: Networks & Communications Consulting
Date: Thu, 31 Dec 1992 01:29:39 GMT

In article <brunetti-301292145224@spanky.dcrt.nih.gov>, brunetti@alw.nih.gov (Jim Brunetti) writes:
> Does anyone know of a company who sells an adpater to split out the 4 pairs
> of a standard 10BaseT run so all 4 pairs can be utilized?  We have a case
> where the wiring has already been run and terminated and someone needs one
> more drop in a lab.  The room has been sealed and the conduits are filled. 
> There is an RJ-45 outlet box in the lab and the wire is terminated in a
> RJ45 patch panel.  Any help or suggestions would be appreciated. 

All you really need is a "T" connector for the RJ-45, and some special
cables to use the other two pairs in the cable. There is no electrical
problem (interference, etc.) between two 10BaseT signals in the same cable
like this, so it is just a matter of pinout. Just be careful to use
these "special cables" (wired to bring a standard 10BaseT NIC to use
pins 4/5 and 7/8 as the pairs) only where you have this situation.
You will have to make the equivalent adapter at the wiring closet end
as well.


-- 
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: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Group bit in IEEE 802
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 23 Dec 1992 05:45:02 GMT

ffuentes@tolten.puc.cl (Fernando Fuentes SCC) writes:
+---------------
| In IEEE 802 standard, in the address field there is a bit called
| group/individual bit, that is intended to be used for multicast (send a
| message to some type of servers for instance).
| I would like to know what applications use this facility
+---------------

First, note that broadcast [destination address = all 1's] is a special case
of multicast, and *lots* of protocols (over)use broadcast. The most common
example of this is probably ARP (Address Resolution Protocol), which is used
to find the MAC-level address of a station with a given network-level address.
Other broadcast protocols include RARP, BOOTP, "timed", "rwho", etc.

True multicast packets are less commonly seen, but RFC 1340, "Assigned
Numbers", lists several dozen known Ethernet multicast addresses. Among
them is the range 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF, which is
used for IP multicast. RFC 1340 also lists over a dozen registered IP
multicast addresses (or ranges).

The prevelance of multicast (especially IP multicast) is increasing. Many
people now use IP multicast for multimedia conferencing: videoconferencing,
"broadcasting" audio (e.g., the now-standard multicasting of audio feeds
from IETF meetings over the entire global Internet), and the like.

While IP multicast is (in practice) currently limited to UDP, several
protocol suites support multicasting as a first-class citizen. XTP and
VMTP come to mind in particular.

+---------------
| ...and at what level the bit is set (who sets it)
+---------------

Each network protocol family has its own way of assigning network-level
multicast addresses, and of translating those to MAC_level addresses.
In practice, the "group" bit is not "set" separately, rather, it's just
part of the MAC-level multicast address provided by the network-layer code
(or provided by some network-to-MAC translation service).


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.lans.ethernet
From: berry@enuxha.eas.asu.edu (Joel R. Berry)
Subject: Tape Backup over network.
Keywords: Tape Network
Organization: Arizona State University
Date: Thu, 31 Dec 1992 16:02:41 GMT

Hello Netters,
   I am asking for some advice on what type of tape backup scheme 
people are using out there.  I have 6 or 7 PC's which will be running
various types of CAD applications one being CADKEY.  I need to back
up the computers onto a tape.  They are not on any type of network, but
the computers can be put on ethernet ( coax ) relatively easily.  What
type of network products would allow one computer on the network
to backup all of the rest.  All suggestions are valid even non network
ones.  Thanks for any help


--

-----------------------------------------------------------
Joel Berry | berry@enuxha.eas.asu.edu
-----------------------------------------------------------
Newsgroups: comp.dcom.lans.ethernet
From: norman@netsys.com (Norman Gillaspie)
Subject: need SMC BBS or FTP site for Elite 16 combo
Organization: Netsys Inc.
Date: Thu, 31 Dec 1992 07:31:08 GMT

I need the BBS or FTP site for SMC ethernet cards. In particular the
SMCMAC.DOS driver for use with Chameleon.

	Regards Norman Gillaspie 	norman@pagesat.com


=============================================================================
	Norman Gillaspie         norman.pagesat.com
	(v) 415-424-0380 (fax) 415-424-0405       PageSat Inc.
	For information regarding Pagesat's Satellite delivered usenet news 
  	mail to "pagesat@pagesat.com" or call: 415-424-0380 (ask for marketing)
    	.. Delivering 45+ megabytes of Usenet news each day, at 9600 bps .. 
==============================================================================
Organization: Bar-Ilan University Computing Center, Israel
Date: Mon, 21 Dec 1992 02:15:06 IST
From: Doron Shikmoni <P85025@BARILVM.BITNET>
Newsgroups: comp.dcom.lans.ethernet
Subject: WD/SMC MicroChannel cards?

I have bumped into a set of SMC MCA cards that I can't figure out,
and I need some help.
                                       61c9
The cards are apparently SMC WD8013WP/A (or close, I'm at home now).
They have 10BaseT and AUI outlets. That's about what I know (except
that the RJ45 jack looks shielded - not ordinary on the cards I've
seen previously).

The cards came in a box, no manual no disk no nothing. Trying to configure
them (long before I was brought into the picture), they appeared to
require the file @61C9.ADF - again, not like the MCA cards I knew
(which used @6FC0/1/2).

But all the above is not a problem - YET. Now: The above mentioned ADF
file, when run on the ref diskette (PS/2 55SX), lets you choose from
the weirdest range of adapter I/O addresses. These numbers are usually
between 0x200-0x3E0; in these cards, I get to choose between 0x800,
0x1800, 0x2800 and so forth.

No *this* is a major problem. To start with, I can't figure out what
kind of i/o address this is. Then, all the drivers I know (start with
crynwr packet, and then PC/NFS and everything) refuse to use such an
address, saying it's in an invalid range. SMC's own packet driver,
and NDIS driver, do run and operate the card, but other "standard"
WD/SMC drivers wouldn't; also, I'm confused as to what an I/O address
like 0x2800 will do to DOS et al.

Can anyone shed some light on this apparent mystery? ANY information
you can give me would help.

Please E-Mail any reply, as I'm away from my office and can't read
news - just mail.

Thanks a lot in advance.
Doron
Newsgroups: comp.dcom.lans.ethernet
From: Richard.Milward@launchpad.unc.edu (Richard Milward)
Subject: Re: Adapter to use all 4 pairs in 10BaseT
Followup-To: richard_milward@unc.edu
Summary: adapter exists
Keywords: 10BaseT adapter
Organization: University of North Carolina Extended Bulletin Board Service
Distribution: usa
Date: Thu, 31 Dec 1992 18:35:44 GMT

For adapting the office-jack end of a 10BaseT cable to support 2 connections,
look at the BR851D adapter from Hubbell Premise Wiring, Inc. -- it'll do
just what you want.  They don't make a corresponding adapter for the PLUG-end
of such a cable, however, so you'll have to make your own.
  Hubble Premise Wiring, Inc.
(a subsidiary of Hubble Incoporated)
  1600 West Main Street
  Building A
  Willimantic, Connecticut  06226
  203/423-7783
Also carried by fine electronics parts distributors like Anixter.

--Richard Milward / LAN Design Consultant
  Office for Information Technology
  University of North Carolina
  Chapel Hill, NC  27599-1405




--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80
Newsgroups: comp.dcom.lans.ethernet
From: fitz@wang.com (Tom Fitzgerald)
Subject: Re: le0: Transmit late collision - net problem?
Organization: Wang Labs, Lowell MA, USA
Date: Fri, 25 Dec 1992 03:50:28 GMT
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

aboyd@quantum.on.ca (Andrew Boyd) writes:

> 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).

There are other things that would give you the same error message without
actually being that problem:

- Electrical problems like bad connectors or un-twisted phone cable
  injecting noise into the middle of people's packets;

- A system with a bad interface card is sending out its own packets when
  another system is already sending.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."
From: khweis1@mvmhp.ciw.uni-karlsruhe.de (Karl-Heinz Weiss)
Newsgroups: comp.dcom.lans.ethernet
Subject: Packet-driver NE2000
Date: Mon, 21 Dec 1992 12:19:29 GMT
Organization: University of Karlsruhe, Germany
Distribution: world
NNTP-Posting-Host: mvmweiss.ciw.uni-karlsruhe.de
Keywords: NE2000

Is here anyone, who has experience with the NE2000 Packet-Driver 
from Clarksom? I am using some Ne2000- compatible cards on our PC's
which will work fine only if netload is rather *high*. If 
traffic is low, connections or/and the transferrate are breaking down. This 
effect occurs,  when there is a connection to the other 
side of our gateway (an fddi/ethernet-Bridge). I suppose, there are 
timing-problems, because all seems to work without problems, if I 
simulate a lot of traffic (5%) by pinging repetivly to another host.

Who can help?

 
Newsgroups: comp.dcom.lans.ethernet
From: rich@grebyn.com (Richard Lawrence)
Subject: I am exonerated
Organization: Grebyn Timesharing
Date: Wed, 30 Dec 1992 04:37:32 GMT

I have received many replies to my posting re: whether or not my
messages are interpreted as commercial plugs or not.

Response was universally supportive. Apparently the reader community
does not share the opinion of my disgruntled e-mailer. 

Thank you for the comments.

-- 
Rich Lawrence, Synoptics Systems Engineer  DOD#9630  rich@grebyn.com
     '92 Seca II "Yuri"  CI$:71101,2272  GEnie:R.LAWRENCE14
   216 years ago my government gave me certain inalienable rights.
     Since then, they've been trying to correct their mistake.
From: b_goodwin@saar.enet.dec.com
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Heartbeat/SQE ...
Date: 29 Dec 92 13:25:00 GMT
Reply-To: b_goodwin@saar.enet.dec.com ()
Organization: Digital Equipment Corporation


In article <1992Dec26.110438.7064@gw.wmich.edu>, x90farleigh1@gw.wmich.edu writes:
|>Path: nntpd2.cxo.dec.com!pa.dec.com!decwrl!wupost!gumby!wmichgw!x90farleigh1
|>From: x90farleigh1@gw.wmich.edu
|>Newsgroups: comp.dcom.lans.ethernet
|>Subject: Heartbeat/SQE ...
|>Message-ID: <1992Dec26.110438.7064@gw.wmich.edu>
|>Date: 26 Dec 92 11:04:38 EST
|>Organization: Western Michigan University
|>Lines: 18
|>
|>I am looking for information on the "heartbeat" or SQE signal (probably
|>different!?)
|>
|>I have gotten the 802.3 standard and it simply mentions a flow chart or two,
|>but does not mention what these sinals ARE (are they real transmissions, or a
|>loopback to check operational status?) Also, why do they hose up a repeater?
|>(I believe they totally screw up a DEC DEMPR).
|>
|>I think this info may be in the 802.3 a,b,c,etc. addendums, but I have no
|>access to these documents-
|>
|>Can anyone help ?
|>
|>Thanks!
|>
|>Fred Farleigh ...
|>x90farleigh1@gw.wmich.edu
|> 
|>

Heartbeat/SQE/CPT(collision presense test) are all the same thing. It is a test
sent from the transceiver to the ethernet controller on a node to determine if
the controller can still detect collisions. In the case of repeaters, most 
of them will not have a problem with it, including the DEC DEMPR, as long as
the repeater is directly connected to the transceiver. If you connect a DEMPR
to a DELNI, then problems will occur if heartbeat is enabled.

The test is performed after every transmission from a controller, when a 
transmission is finished, the transceiver will then send back heartbeat, if
enabled, to the controller to see if it still can sense collisions. In the 
case with DEC systems running DECnet, you can tell by looking at the line
counters for the enet controller. There is a counter called "Collision
detect check failure", if this counter is incrementing at the same rate as 
"Data blocks sent" then heartbeat is disabled.

Brad Goodwin
Newsgroups: comp.dcom.lans.ethernet