TCP/IP on Xenix - summary

[Rob Peglar x615]

Some time ago, I asked the group to comment on their TCP/IP configurations
for Xenix systems.

Here are the (distilled) responses.

Enjoy,

Rob

--------------------------------------------------------------------
Daniel Wynalda writes:

From: uunet!wugate!wuarchive!sharkey!wyn386!danielw (Daniel Wynalda)

We are running SCO Xenix 386 2.3.2 and Excelan LAN workplace on two machines.
The LAN workplace comes with Telnet, FTP, rlogin, and alot of other goodies -
remote printing etc.  This setup uses EXOS cards from Excelan and their
own drivers. 

On top of these, we run SCO Xenix-Net and can access all files/devices on 
either machine from either machine.


Bill Davidsen writes:

From: uunet!crdos1.crd.ge.com!davidsen

  Some systems with Excelan, some with SCO. Both work, SCO is a bit more
like BSD in terms of having sendmail, etc.


Ronald Srodawa writes:

From: Ronald Srodawa <uunet!unix.secs.oakland.edu!srodawa>

I am running single user 2.3.2.  I have a 3C505 ethernet card.  I have NOT
purchased SCO TCP/IP products.  I am building NCSA_Telnet (PD package) to
run on a small MSDOS partition (I haven't purchased VP/ix either).
I hope to write a driver for Xenix then port NCSA Telnet to Xenix.
(Such is life in universities.)


Chip Rosenthal writes:

From: uunet!wugate!vector.dallas.tx.us!chip (Chip Rosenthal)

We have been using Excelan's LAN Workplace for 386 XENIX here (under 2.3.1),
which includes the EXOS-205T card and TCP/IP software and utilities.  The
basic utilities, namely FTP and telnet, work just fine.  We have a very
heterogenous mixture of machines on our network, and I would say that the
utilities on the XENIX box are the best behaved and most consistent.

However, there are several problems with the Excelan stuff:

1)  The SMTP is totally brain dead.  The installation assumes that you
    run a totally vanilla SCO mail system, and the smtp server (i.e. the
    thing which transmits messages to the network) is built into a version
    of mail.local which replaces SCO's mail.local.  A horrible kludge of
    placing "exos:" in front of addresses is used to note SMTP routing.
    It is very painful to use this stuff if you are running something
    like smail.  Also, the SMTP client is not robust.  I have a problem
    on a VMS SMTP (also by Excelan) which munges From: addresses (in
    forwarded mail).  The XENIX SMTP server sees this as a syntax error
    and rejects the message, with the end result of all forwarded mail
    being delivered into a black hole.

2)  The socket library interface is *ahem* novel.  If you plan to do any
    software development or porting, you are going to have to provide two
    sections of conditionally compiled code:  one for Excelan, and one
    for everybody else who does it right.  I have tried to ease this
    problem with coming up with a set of compatibility routines to give
    the BSD netdb-library type functions, but the whole sequence of setting
    up sockets is incompatible with BSD syntax.  Syd Weinstein mumbled
    something in this newsgroup about providing additional compatibility
    routines.  I wish him luck.  It does not look to be an easy task, but
    would be of enormous benefit.

3)  You are limited to a single 205T card, so you couldn't do any bridging.
    99.9% of the time this isn't a problem (it isn't for me), but might
    effect some folks.

4)  As of yet, I don't believe that Excelan has announced any NFS support
    under XENIX.  They have started providing it under some platforms,
    so one would expect it is only a matter of time.

5)  There are a lot of applications where Excelan does not provide the
    software for the machine to be a host.  For example, you can do remote
    printing to another machine through the network, but they don't provide
    a server so that one of the printers on the XENIX machine may be a
    remote printer.  You can use a domain name resolver or request a hosts
    table, but you can't be a domain name resolver or the server which
    provides host tables.

6)  Their phone system sucks.  Excelan won't give you any phone numbers
    except their main one.  So, if you try to place a call you call up
    the main number, punch in a code for support, sit on hold for fifteen
    minutes, finally talk to somebody who can't answer your problem, leave
    a message, and then sit around your phone waiting for a return call.
    What gets me, though, is when a particular apps person leaves a message
    for me, I need to go through this entire routine because they won't
    give me a direct phone number.

I know this is a long list of bitches, but all in all I would say the
product has done the job I've needed, for the most part.  (However, I've
had to totally scrap Excelan's SMTP and use something else because theirs
is so screwed up.)  Right now, my biggest problem is #2, and for that
reason I would move to SCO's product when I move to UNIX.

However, you must keep in mind that SCO's TCP/IP will be useless to you
as long as you run XENIX.  That's because TCP/IP is built upon SysV
streams, which are unavailable (and I would expect to remain so) under
XENIX.  Another issue is that TCP/IP is becoming a more integral part of
the system.  That is, it no longer merely supports remote terminals and
file transfers, but you want it to support remote file systems, remote
procedure calls, windowing systems, etc.  Since it must integrate with
all these functions, I would think the OS vendor is going to be in the
best position to supply it rather than a third party.

So, in summary I have to say that Excelan's product, for all of its warts,
does the job under XENIX.  But long term you have to look at migrating
towards SCO UNIX and their TCP/IP.  (Gawsh...I hope they get it right!)


Daniel Wynalda (again) writes:

We have RG-58 cable strapped between the on-board tranceivers.  Thin-net is the
term I believe, but I just used some extra HAM RADIO stuff I had lying around.
It works really well for my desires.  When Xenix-Net gets up on top of the
Excelan system, I can copy files across between the 386 machines almost
as fast as I can copy them to another area of the same hard disk on a
286 Xenix machine (pretty good, but not un-noticeable).  Of course, I can
use the files on either machine just like they are on the same computer -
except it's slower... I've used the modem on another computer via the
Xenix-Net and I've used the Excelan workplace "rlogin", "rsh", "rpr"
etc ALOT.  I must say the Excelan rlogin, telnet, etc are much better
than their work-alike equivalents by SCO under Xenix-Net.


Bill Davidsen (again) writes:

Never tried token ring. I am writing this on a SCO machine with Excelan,
connected to an enet with 500+ nodes, VAXen, Suns, etc. We also have ten
or so machines with WD enet cards and SCO TCP support. Both combinations
work fine, SCO has sendmail, while Excelan has some non-standard but
useful things included.

I assume that either WD or Excelan make a thinnet card, we run standard
(big) cable here, although some workstations have gone to t.p. I haven't
looked to see what support cards there are for PCs.


Scott O'Connell writes:

From: uunet!pnet01.cts.com!scotto (Scott O'Connell)

I'm using the Excelan Hardware & Software on two Compaq 386/20 machines.


Kayvan Sylvan writes:

>From uunet!apple.com!mrspoc!kayvan Sat Oct 28 04:41:41 1989

We use Excelan TCP/IP concurrent with XenixNet (for pseudo NFS).


William R. Pearson writes:

>From uunet!ginosko!aplcen!haven!uvaarpa!hudson!biochsn!wrp Thu Oct 26 07:46:23 1989

	I am using Streamlined Networks TCP/IP for Xenix386 2.3.2.
It provides ftp, telnet, rcp, rlogin, rsh, and works with the WD8003e
board. Cost: $495.

	It works, but it isn't perfect.  I can rcp out to any machine,
and I can rsh into my machine, and I can ftp out, but I cannot ftp
in.  I can rcp into my machine while logged into a remote machine, e.g.

	sun> rcp file xenix:

But I cannot do:

	xenix> rcp sun:file .

(I can do:)

	xenix> rcp file sun:

I can rlogin out but not it.  I can ftp in and out from xenix, but not
into xenix. (It says it only supports some sort of anonymous login, but
that doesn't even work).

	One last problem, when I am rlogin-ed from xenix to a remote 
machine (or telnet), the connection seems to die for 15 - 60 seconds
periodically, and then it comes back.  Perhaps some timing parameter
is not set up properly.

	There was very little documentation about how to set it up
for my location, which has subnets and routers, but after I asked
our network guru, it was working quickly.  I also had some problems
figuring how to get the wd8003e working on and inboard 386 computer,
but that wasn't their fault.

	Technical support is poor, I have mentioned all of these problems
to them, but nothing has happened.  I don't think they like supporting
Xenix very much, as opposed to Unix 3.2.

	But it works, I use it every day.  I cost less than SCO, but I'm
thinking of switching.

Bill Pearson


Aaron Burns writes:

To: stpl!yunexus!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!csinc!rpeglar

One of the sites in our corporation is using SCO TCP/IP over top of
Xenix-Net between two machines.  They aren't happy with it for performance
reason, and the feeling is that they should have stuck to the TCP/IP 
drivers that came with the Excelan cards and not bothered with 
Xenix-Net at all.  

I'm interested in the results of your poll, as my site will be installing
ethernet in the near future.  In particular, i need to find a 16-bit
card and an 8-bit card that will talk to each other.


John Romkey writes:


I don't entirely remember the original posting, but I think I was
talking about the ethernet cards that SCO TCP supports. SCO TCP
doesn't support the Excelan card, per se, because SCO TCP (and other
TCP's like Streamlined Networks TCP) is a host-resident TCP and the
Excelan card provides its own. So it's an entirely different option
for getting TCP into your machine, and I didn't mention it.

I avoid Xenix-net like the plague, personally.

Excelan only produced 8 bit cards last time I knew, but that was quite
a while back.

8 bit vs. 16 bit is a rough guideline to performane, but you shouldn't
expect it to be the dominant factor in determining your network
interface's performance. For instance, early 3COM 3C505's had 16 bit
interfaces on them, but there was so much overhead in communicating
with the card that transfer rates were often slower with it than they
were with the 3C501 8 bit card. I'm not about to start up the smart
vs. dumb card argument again, but I've not seen many examples of
"intelligent" ethernet cards where you really got a good performance
boost because of the card's onboard processor. The reason is that they
often have very complicated interfaces (host to card, card to host) so
that as many instruction cycles or more get spent just dealing with
the card as the system would spend doing TCP processing. There goes
the advantage...

One intelligent card that I've worked with that did seem to perform
reasonably well is the CMC ENP 66 (and I guess the later CMC 640)
ethernet card. This comes with TCP. RACAL-Interlan also sells an
intelligent ethernet card with TCP for Xenix.
-- 
Rob Peglar	Control Systems, Inc.	2675 Patton Rd., St. Paul MN 55113
...uunet!csinc!rpeglar		612-631-7800

The posting above does not necessarily represent the policies of my employer.