Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!csinc!rpeglar From: rpeglar@csinc.UUCP (Rob Peglar x615) Newsgroups: comp.unix.xenix Subject: TCP/IP on Xenix - summary Keywords: TCP,IP,Xenix,Ethernet,Excelan Message-ID: <157@csinc.UUCP> Date: 13 Dec 89 16:00:15 GMT Organization: Control Systems, Inc., St. Paul MN Lines: 266 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 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.