Newsgroups: bit.listserv.big-lan
Date:         Fri, 24 Jul 1992 12:31:41 EDT
From:         BIG-REQ@SUVM.BITNET
Subject:      BIG-LAN Digest, Volume 4, Number 50, Friday, July 24, 1992

BIG-LAN DIGEST             Friday, 24 July 1992        Volume 4 : Issue 50

Today's Topics:

            new mailing list - UM network modeling tool users
                Re: Simultaneous Mainframe/Network Access
                NDIS over a Cogent E/Master II-AT (EM2AT)
             Re: ODS fiber xcvrs - I kind of got it sideways

Moderated by John Wobus, Syracuse University

Relevant addresses:
                                  Internet                BITNET
Submissions:              big-lan@suvm.acs.syr.edu     BIG-LAN@SUVM
Subscriptions:    big-lan-request@suvm.acs.syr.edu     BIG-REQ@SUVM
LISTSERV/Archives:       listserv@suvm.acs.syr.edu    LISTSERV@SUVM
Moderator:                jmwobus@syr.edu              JMWOBUS@SYREDU
Anonymous ftp archives:           syr.edu

Note: BIG-LAN is redistributed through many mailing lists at other sites
run by other individuals.  If you subscribe(d) through such a
"redistribution" list, you will need to remember its owner.

syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
asked questions) under the path information/big-lan/big-lan.faq

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

Date: Thu, 23 Jul 92 17:51:51 EDT
From: Dave Bachmann <dave@citi.umich.edu>
Subject:      new mailing list - UM network modeling tool users

We are pleased to introduce a new mailing list for users of NetMod,
a network modeling and capacity planning tool developed at the University
of Michigan.  This mailing list will introduce NetMod and provide a forum
for NetMod users to communicate and keep informed of product enhancements.

To subscribe to the list or to learn more about NetMod send mail to:

      netmod-interest-request@citi.umich.edu

Dave Bachmann             dave@citi.umich.edu
Darin Quest               darin@citi.umich.edu

NetMod is a trademark of The Regents of the University of Michigan.

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

Date:         Tue, 21 Jul 92 13:33:44 EDT
From:         Joe Simpson <JSIMPSON@miamiu.acs.muohio.edu>
Subject:      Re: Simultaneous Mainframe/Network Access

There are several ways to do this depending upon the details of the
connection.

We use Novell as our NOS and lots of tcp/ip capable hosts( although
the administrative host is via a terminal server).

We use the Clarkson packet drivers and the Novell packet driver ipx.
This work quite well for ethernet.  For token-ring we use the
ibmtoken "packet driver" for tcp/ip service.  This requires the IBM
LAN program DXM mods be applied to the token ring driver.  When you do
this YOU MUST use the Novell software generator to generate an ipx
for DXM mod token ring.  The default ipx will not work.

Joe Simpson, Academic Computer Service, Miami University,
              Oxford OH45056    (513) 529-6237
Internet: jsimpson@miamiu.acs.muohio.edu  Bitnet: jsimpson@miamiu

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

Date: Tue, 21 Jul 1992 13:49 EDT
From: BOB FORSTER <SYSTEM%IMDNET@utrcgw.utc.com>
Subject:      NDIS over a Cogent E/Master II-AT (EM2AT)

	I am trying to install Wollongong Pathway Access Version 2.0 and
DEC Pathworks Version 4.1 on two different COMPAQ 486 color portables that
are primarily Network General Expert Sniffers.

       I received the NDIS driver from NG, but they do not support it.
       Cogent does not ship a protocol.ini or a protman$ file.
       Wollongong says they can not bench test the configuration since
       they don't have the card.
       DEC said the thought there were some missing pieces but couldn't
       identify them.

       Both Pathworks and Pathway are unable to bind the application
       driver to the ndis driver.

       If someone on the list has been able to make either of these
       applications work on this hardware set, I would greatly appreciate
       a copy of config.sys, autoexec.bat, protocol.ini, a description of
       what directories contained what files and any other unobvious
       gotcha's in the process.

	                          Thanks,

 -----------------------------------------   Robert W. Forster (Beeper 1532)
/_______________________________________/ |  Supervisor, DEC Systems
| | |                 | | |       | ____|/   Business Systems Department
| | |___    _______   | | |___    | | |      Sikorsky Aircraft
| |/___/ | /______/ | | |/___/ |  | |/_/|    (203) 386-5493, fax (203)386-5858
|  ___ | | |  ___ | | |  ___ | |  | ___|/    UT PROFS:  SIKVSCS(RFORSTER)
|  /_| | | | |/_| | | | |/_| | |  | | | UT mailbus: dnc::mrgate::dnc::forster
|______|/  |______|/  |______|/   |_|/  Internet: system%imdnet@utrcgw.utc.com

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

Date: Tue, 21 Jul 92 15:15:14 -0400
From: William H. Magill <magill@dccs.upenn.edu>
Subject:      Re: ODS fiber xcvrs - I kind of got it sideways

It seems that I had the right church, but the wrong pew on this one.
I apparently got two related problems mixed up.

Originally I said:

  > Basically, we finally found out why nobody but ODS makes these units.
  > They are "thoretically flawed". If I remember the explanation given to
  > me by our engineering group - If you have a bad packet with an invalid
  > CRC for example, the ODS units will transmit that packet (as they
  > should), howver, since the packe is "re-calculated" at the
  > "transmitting end" Viola! you suddenly have a garbage packet with a
  > VALID CRC!  As I said, on a clean segment, no big deal, but on one with
  > lots of noise it can be trouble. Especially, since it is not obvious
  > what the source of the problem happens to be.

One of our engineering people straightened me out.

< The regenerated checksum was from some bridge or router (I don't
< remember exactly) that assumed it had an error free path to the
< endpoint ethernet.  It stripped off the ethernet checksum to save
< transmission bandwidth.  It then sometimes corrupted the packet and
< then regenerated the checksum to fit the packet.  This only affected
< DECnet since it assumed that if the Ethernet checksum was ok, then
< the packet was ok.  Since IP has its own checksum, it was not
< susceptible to it.

Here's the correct description of the ODS problem.

< coax -- xcvr -- ODS 234 ------- fiber ------- ODS 236 --- DTE
<
< The problem with the ODS was that they transmitted the
< transceiver's detection of collision over the fiber.
< If the fiber was longer than some fairly short distance,
< it was possible for the DTE to transmit a short packet
< have it collide on the coax, and the DTE would never
< detect the collision because the collision did not occur
< while it was transmitting.
<
< The timing is way outside the 802.3 spec.  I used to have the
< numbers on delay, length, and the like, but I can't seem to find
< them at the moment.
<
< A call to ODS confirmed the scenario.  Later, an ODS sales rep
< denied that this was the case, so I don't know what to believe.  But
< certainly we experienced short packet loss on busy ethernets using
< the ODS fiber extenders which tended to confirm our theory.
<
< Rather than build unreliable networks, we switched to FOIRL stuff
< from Cabletron.

Apparently since then, ODS has also come out with a FOIRL product.

William H. Magill                         Manager, PennNet Computing Services
Data Communications and Computing Services (DCCS)  University of Pennsylvania
Internet: magill@dccs.upenn.edu                   magill@eniac.seas.upenn.edu
          magill@upenn.edu

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


End of BIG-LAN Digest
*********************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU