rpeglar@csinc.UUCP (Rob Peglar x615) (12/14/89)
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.
pb@ethz.UUCP (Patrick Baur) (12/14/89)
It's a bit late but I will throw in my remarks for what their worth.
We have a small network with 2 x AST Premium 386, 3 Mac's, 1 Opus
1 Textronics, 1 Sun. All (except 2 Mac's) running some sort of Unix/Xenix.
1 Mac is a gateway to Appletalk. We have 2 Excelan terminal servers
(Export 2000), 2 CMC terminal servers (TranServer). As Network software
server for the execlan terminal servers a sperry AT is also connected
to the network running Excelan NMS under DOS.
I have had experience with
1) Excelan's Lan Workplace for Xenix with a excelan 205 board
2) SCO TCP/IP with a WD 8003 board
Xenix version 2.3.2
Excelan Lan Workplace version 3.5
SCO TCP/IP version 1.0 (controlled release)
1) Excelan Lan Workplace
- As remarked by Chip Rosenthal the SMTP is lousy.
It took me 4 houres to get it to work at all. (mail exos:host@user ?)
I won't repeat what he said about it but it's all true.
- Same for the socket libary interface. Again Chip discriped it
acuratly. This means that installing sendmail is out (as is every
other network software without major rewriting).
- For all the psuedo devices for rlogin and telnet a getty is started
(Not like BSD where a getty (and the rlogind as for that matter) is
started when needed). This is not so bad but adds 16 processes.
- It happens painfully often that when logged in via rlogin that
the rlogind or telnetd locks up. I don't no why or what causes it.
The result it that ALL processes you where running on the machine
are locked and they CANNOT be killed, only by rebooting the
machine !!.
- The rlogin deamon is like SMTP 'brain dead'. It does no autologin
The manual states that the onboard rlogind is actually the same
as the telnet deamon (!).
- telnet, rlogin to and from any machine is oke
- rcp, rsh : At this point I lost all faith in Excelan.
rcp and rsh form the Excelan to any other computer we have
functions oke. rcp and rsh from any other machine to Excelan does
not function. As long as your program does not produce output
all is oke, but as soon as data has to be send back ('rsh host ls'
or any rcp) the connection is broken.
- Could not get Domain name resolver to work, but I suppose this
is due to the fact that I don't know must about this. (Can
anybody tell how to set a DNS up for a small network ?).
- ftp, rpr not tested
All the above points are tested from and to several machines
all running different flavors of Unix. With one exception. When
working on a terminal connected to an Excelan terminal server,
the connection seems to crash less often.
2) SCO TCP/IP
Altough I tested this must less thoroughly, seems to work oke
A few remarks:
- It is based on Lachman System V Streams TCP.
- rcmd (=rsh), rlogin telnet work fine. To and from any machine
- rcp works oke, but makes a mistake when handeling remote to
remote copies (e.g rcp host1:file1 host2:file2). It sends
a wrong request to host1:
'sh -c rcp file1 (null)host2:file2'
(it tries to print a NULL pointer).
solution:
rcmd host1 rcp file1 host2:file2
- Never had a crash or a locked process.
- We had a lot of trouble getting the new kernel with
Streams/WD/TCP support to boot on our AST/386. It reboots
as soon as I start the kernel. The funny thing is that this only
happens when you do a COLD boot (power on/off). When you first
boot a old kernel without Streams/WD/TCP then do a shutdown
and reboot the machine, the new kernel works fine. We have
an other AST/386 which only difference is a newer ROM BIOS,
on which this trick does not function, and the kernel will not
boot at all.
Since I installed the software on other 386's without any
problems I think it is a hardware problem.
- ftp, sendmail not tested
- I don't know about porting other network software
(We only have a runtime system, I think)
When testing for speed, load average etc. I could not notice any difference
between the two. (Maybe I didn't use the right tests).
Again I can't say that I tested SCO TCP/IP very well but enough to form
a opinion. When also taking into account that the WD board is much
cheaper as the Excelan board (I don't know about the software prices), I'd
say go for SCO.
Any response is welcome. If you reply by News please Mail me a copy
since I'm leaving for a two weeks and might miss it.
mail address: ...!seismo!mcvax!chx400!pan!epr!maarten
or the address below
Maarten Huisjes. ...!seismo!mcvax!chx400!ethz!pb
(Temporary using this account)
[Life is hard, then you die!]dyer@spdcc.COM (Steve Dyer) (12/15/89)
The article quotes someone (Rosenthal?) who is misinformed about SCO's
TCP/IP for XENIX and UNIX. It certainly DOES run under XENIX 386 as
well as UNIX V/386. XENIX 386 can optionally run STREAMS, and the
TCP/IP runs as a set of STREAMS modules above this. Most of the
typical Berkeley applications run on top of a socket emulation
library.
I can say that it appeared to work OK, although I never bothered
wrestling with their sendmail; I was sending and receiving mail on
another of my systems.
Apparently, however, the Lachman TCP/IP which SCO sells contains
a "copy-protection" feature which broadcasts the product's serial
number to a particular UDP port on some regular basis. If two
different systems have the same serial no., something bad happens.
(Presumably one or both go off-line; I've never tested.)
Needless to say, this is unacceptable in any system which pretends to
be a production system. The marketeers were unrepentant as of last
August at the SCO Forum. I don't know whether things have changed
since then.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.educhip@chinacat.Lonestar.ORG (Chip Rosenthal) (12/15/89)
In article <157@csinc.UUCP> rpeglar@csinc.UUCP (Rob Peglar x615) writes: #>Some time ago, I asked the group to comment on their TCP/IP configurations #>for Xenix systems. [...] #> #>Chip Rosenthal writes: #>From: uunet!wugate!vector.dallas.tx.us!chip (Chip Rosenthal) #> #>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. Brappzhht! My speculation was off base, and this is no longer true. TCP is available from SCO under XENIX. I don't have any experience with it, so I can't say anything about the implementation. However, I do want to take this opportunity to dislodge my foot from my mouth. Sorry for the misinformation.
sl@van-bc.UUCP (Stuart Lynne) (12/15/89)
In article <875@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: }Apparently, however, the Lachman TCP/IP which SCO sells contains }a "copy-protection" feature which broadcasts the product's serial }number to a particular UDP port on some regular basis. If two }different systems have the same serial no., something bad happens. }(Presumably one or both go off-line; I've never tested.) } }Needless to say, this is unacceptable in any system which pretends to }be a production system. The marketeers were unrepentant as of last }August at the SCO Forum. I don't know whether things have changed }since then. It basically fails silently (I seem to remember there is a message logged somewhere). The symptom is that things work ok for a few seconds and then stop on one system (not the same one every time). I have this happen about 50% of the time when I'm re-installing - I can never remember which key goes with which machine. It's a *royal* pain in the *ss. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
jim@bahamut.fsc.com (James O'Connor) (12/15/89)
In article <2840@ethz.UUCP>, pb@ethz.UUCP (Patrick Baur) writes: > > 1) Excelan Lan Workplace > - For all the psuedo devices for rlogin and telnet a getty is started > (Not like BSD where a getty (and the rlogind as for that matter) is > started when needed). This is not so bad but adds 16 processes. It also keeps you from using the psuedo-ttys for other purposes for which a getty is not needed, such as "usemouse" or the X window client "xterm". > 2) SCO TCP/IP > Altough I tested this must less thoroughly, seems to work oke > A few remarks: > - It is based on Lachman System V Streams TCP. I wonder if this will change now that Lachman is a part of Interactive (or is it the other way around)? > Since I installed the software on other 386's without any > problems I think it is a hardware problem. > - ftp, sendmail not tested If you are using an alternate mail transfer agent (smail2.5, smail3), installing SCO TCP/IP does a fair job of munging your mail system. When installing SCO TCP/IP, be prepared to re-install your alternate mail software right after installing TCP/IP, or you will have mail problems. The easy solution to this would be for SCO to make SENDMAIL one of the selections on the installation package menu, so you can choose not to install any of the SENDMAIL programs, or related programs that go with it. > - I don't know about porting other network software > (We only have a runtime system, I think) smail3 compiled just fine with the SCO TCP/IP Dev Sys. I haven't tried anything else, but should be working on porting, or writing, some TCP/IP sys admin software in the near future, so I'll know much more once I get into that. > When testing for speed, load average etc. I could not notice any difference > between the two. (Maybe I didn't use the right tests). Even using an 8-bit card, the SCO TCP/IP seems to perform very well. ------------- James B. O'Connor Work: jim@tiamat.fsc.com Data Processing Manager Play: jim@bahamut.fsc.com Ahlstrom Filtration, Inc. UUCP: uunet!tiamat!jim