DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon) (07/21/89)
Novell sells a product developed by Micom-Interlan, called their tcp/ip
gateway. We have had it here for about a year, working with Novell to test
and debug it. There were many many problems with their early implementations
of tcp/ip. But to their credit they have stuck with it and fixed all the
problems we kept telling them about. Now it is to the point that we can declare
it a basically working and useable product for our campus internet.
It is not yet in wide use here, as we have been primarily a Banyan campus.
Bob Dixon
Ohio State University
-------chenn@tame.cs.umd.edu (Jenn-San Peter Chenn) (08/10/89)
I would like to make more infomation about tcp/ti on ibmpc. With or W/O Novell. What HW or SW do I need? Who is selling them ? Thank you.
grant@clleth.UUCP (Grant Fengstad) (08/13/89)
In article <18985@mimsy.UUCP>, chenn@tame.cs.umd.edu (Jenn-San Peter Chenn) writes: > > I would like to make more infomation about tcp/ti on ibmpc. With or > W/O Novell. What HW or SW do I need? Who is selling them ? Thank you. Probably as far as getting support from Novell is concerned, your best bet would be to go with the Excelan Solution. It is quite expensive but also is a good performer. Other manufacturers that I am aware of are: Wollongong, Inc. 3-Com Excelan FTP -- Grant M. Fengstad "The ideas expressed are my own - not my employers" Sr. CSR, Systems Integration - ComputerLand (Canada) UUCP: !uunet!{ubc-cs|utai}!calgary!xenlink!clroslyn!clleth!grant "There's nothing worse than a confirmed fanatic"
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (08/15/89)
The question of "coordinating" use of TCP/IP with a proprietary protocol,
such as Novell's Netware, surfaces on one of the lists periodically. In
looking for solutions, it is important to be clear about the problem, since
there are two, VERY different operational styles and they need two, VERY
different kinds of solutions:
1. Proprietary Network
The entire (sub-)network operates with the proprietary protocol, but you
would like to connect it to a TCP/IP network. This requires that the
various hosts on the proprietary network communicate over their
sub-network through some sort of relay device (router/gateway) which
connects the proprietary protocol into the TCP/IP protocols. There are
different technical solutions to this.
2. Shared Network
You wish to run the proprietary protocols AND TCP/IP over the SAME wire and
want you host (pc) to be able to use BOTH sets of protocols. If done
efficiently, this requires having the protocol stacks share the network
device driver for the host. (An alternative is to make this case look
like #1, above, and have the relay device connected twice to the network,
so that the proprietary network looks as if it is on a separate wire.)
It is my understanding that the Excelan product, which was suggested in
a previous note, solves only case #2, for shared networks. (Note that if
{you already have another network interface card, you get to buy the
Excelan card anyhow. There are alternate products whi allow you to share
various other cards.
Daveperand@ttds.UUCP (Per Andersson) (08/19/89)
In article <18985@mimsy.UUCP> chenn@tame.cs.umd.edu (Jenn-San Peter Chenn) writes: > > I would like to make more infomation about tcp/ti on ibmpc. With or >W/O Novell. What HW or SW do I need? Who is selling them ? Thank you. One thing you might want to try is using a packet driver ( See packet driver announcements ). This allows you to let your own PC run both IPX and , for example NCSA Telnet simultanously ( is my spelling correct ? ). You have to get a special version of IPX from Novell of course. And you might have to change the drivers on the server too. I think you have to have the type-field/ length field in the ethernet frames set to 8137, which is assigned to Novell. In some versions of Novells drivers the field is interpreted as a length field ( that's 802.3 i think ). In this case you can run applications which support packet driver from your local disc. If you run them from the server you will need a server that support RARP or something equal. This because if you, as you can do in NCSA Telnet, put a fixed IP-number in a configuration file, all clients starting the program will get the same IP-number. BANG - goes your network. I have been running this configuration for a couple of weeks and it has been working really well. Per -- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @tds.kth.se, @nada.kth.se or perhaps {backbone}!sunic!ttds!perand
jim@syteke.UUCP (Jim Sanchez) (08/19/89)
Since this question has come up several times, I thought I'd mention that
Hughes LAN Systems (Formerly Sytek) has had support for multiple protocols
for some 2.5 years now. With our stuff you can run Novell, TCP/IP, and LAT
concurrently. This is kinda nice when you want to FTP directly to a file
server without having to store the file on your pc in the interim. Please
contact your local sales/tech guy at HLS for the details. And, like any
good vendor, you have to buy our cards.
--
Jim Sanchez {sun,hplabs}!sun!sytek!syteke!jim OR
Hughes LAN Systems, Brussels mcvax!prlb2!sunbim!syteke!jimpprindev@wellfleet.com (Philip Prindeville) (08/23/89)
> to get a special version of IPX from Novell of course. And you might have to > change the drivers on the server too. I think you have to have the type-field/ > length field in the ethernet frames set to 8137, which is assigned to Novell. > In some versions of Novells drivers the field is interpreted as a length field > ( that's 802.3 i think ). In this case you can run applications which support Well, it's sort of 802.3; if there was a valid SAP after the length, then this would be legitimate. But it isn't. Fortunately, Novell ships there boxes with checksumming turned off (sound familiar?) so that the checksum (the first two bytes after the frame length) is always 0xffff. This is not a valid LSAP, and most hosts will ignore this. This bogusity got me the first time. Novell ships a tool called econfig, that allows you to fix the driver to use Ethernet-II frames (and put 0x8137 in the length/type field). How many sites have their PC's using the pseudo-802.3 encapsulation? Not many I hope, but I would be interested in hearing from you if you do. -Philip
perand@tds.kth.se (Per Andersson) (08/24/89)
Hi, At the site I have been connected to all servers have been converted to use the 8137 type field. They were apperently delievered using the bogus 802.3 header. As I am a user and not an administrator of the novell system I have no deeper knowledge why this was so. Per
pete@NCSC.NAVY.MIL (Fernandez) (09/06/89)
From pete Tue Sep 5 15:35:54 1989 Received: by ncscnavy.mil id AA04248; Tue, 5 Sep 89 15:35:47 CDT Date: Tue, 5 Sep 89 15:35:47 CDT From: pete (Fernandez) Message-Id: <8909052035.AA04248@ncscnavy.mil> To: pete Status: R 1. A Software solution is needed to allow users of the our Novell LAN who are located remote to us access to the local LAN file server via the DDN. Following is an outline of what we have now in the form of hardware and software, and what type of software is necessary to solve the present hold-up: 2. We have four (4) stripped-down 286 microcomputers slated to be DDN "host" systems. We've purchased four (4) Micom/Interlan NP600A Protocol Processors (Intelligent Ethernet Cards with 80186 Microprocessors, 82586 LAN co-processors, 5212K RAM, EPROM, and NP627-NW-DI5Q Intelligent TCP S/W for Netware), one for each of the DDN host systems. 3. We would like each of the DDN host computers (with Intelligent Workstation) to access our LAN File Server as a remote host for users accessing the system via the DDN. Netware Login, program loading (.EXE/.COM & .OVL) and database access would be sent over the Ethernet to the pur File Server via netware Protocol. 4. Despite earlier vendor claims, there currently is not any software on the market (that we are aware of) that will allow TCP/IP remote host capability on micros that are concurrently running Netware/DOS. Any information on software products that will support dual Protocol stacks (which the NP600A does) and at the same time allow TCP/IP remote login and execution to a Netware LAN Node would help out a great deal. We would prefer to utilize the intelligent work stations for both software requirements over installing two controllers in each DDN host micro (one for the TCP/IP Protocol requirements, one for accessing the LAN File Server). The reason for this approach is that the intelligent work station's processor(s) will take some of the load off of our file server, the end result being a faster network for all users whenever a user(s) accesses our file server via the DDN. A software solution that does not require more than 50-70K of memory in the host computers would suit our needs best (to maximize the amount of free RAM for program execution in each host computer). 4. I thank you in advance for any assistance/direction you can give us in solving this problem. Pete Fernandez Naval Coastal Systems Center/Code 02 Panama City, FL 32407 pete@ncsc.navy.mil (904) 234-4120; AV 436-4120