carrs@TROUT.NOSC.MIL (Stephen M. Carr) (01/25/88)
-------
Ladies/Gentlemen,
1. We are about to lay the keel for networking at this command
and we must devise a game plan for MILNET and local TCP/IP
interconnectivity.
2. Among other incompatibilities, we have some unknowns in the
form of a WANG VS-300, a community within the command that has
procured and started installation of an ARCNET with I believe
Novell Netware, and many Honeywell DPS-6 minicomputers.
3. My objective is to try to implement an IEEE 802.3 Ethernet as
a backbone network gatewayed into a MILNET PSN. All other
networks in the command would be gatewayed into this backbone
Ethernet. This backbone Ethernet would have no hosts directly
connected to it, only gateways. The networks with hosts directly
connected would be subnets. This is the game plan that Mike
Karels, UC Berkeley suggested to me at the UNIX Berkeley
Networking symposium at Techmart that Advanced Computing
Environments held in August 1987. I have to believe that he
knows what he is talking about.
4. My problem is that we are complete neophytes when it comes to
TCP/IP internet as well as local networking. We cannot afford to
spend a lot of taxpayer funds making lots of mistakes trying to
learn what is going on.
5. Unfortunately, we are confronted with several problems.
a. The command has a WANG VS-300 which I don't know how we
are going to connect via TCP/IP. Is there anybody out there that
can tell me if there is a TCP/IP solution out there or in the
wings for a WANG VS-300? The vendor is promising the moon, but
WANG sales representatives promised me this same moon about 12
months ago. They are going to brief us on Tuesday, 26 January
1988 with their latest promises. I would sure appreciate some
straight skinny from any other users out there that have any
experiences with getting a WANG VS-300 singing on the internet!
I would like to go to this meeting armed with comments from this
forum if at all possible.
b. Some forces within the command that are concerned with
PCs have procured and are already installing an ARCNET with
Novell Netware. I don't know much about ARCNET, and I seem to
remember seeing some comment about it about 2 months ago in this
forum. I see no evidence to indicate to me that you can get the
ARCNET/Novell Netware to interoperate via TCP/IP at the present
time. Again, any comments from users having experience in trying
to get the ARCNET to sing along with TCP/IP in an internet
environment would be most appreciated.
c. We have some 18 or more Honeywell DPS-6s in this command
that we are going to have to internet also. There are already a
few IEEE 802.3 Ethernets installed on aircraft carriers servicing
the DPS-6 hardware onboard. My understanding is that this is
actually Bridge Communications Corporation's IEEE 802.3
hardware/software with a Honeywell label on it. In any event, we
as a CDA (Central Design Agent) must be able to emulate this
Ethernet environment on our aircraft carriers. Problem! I
understand that they have implemented XEROX XNS in this IEEE
802.3 environment vice TCP/IP. Does anybody make a gateway or
protocol converter that will allow Honeywell DPS-6s singing XNS
on an Ethernet to communicate TCP/IP with the internet?
6. We seem to be off to the races with all of the hardware and
software necessary to build our own Tower of Babel. My objective
is to somehow, some way, see if we cannot get all of this to
interoperate via TCP/IP and the MILNET.
7. Many thanks to the dozen or so folks that responded to my
plea for help on KERMIT for the Honeywell DPS-6! We did draw
down the object code, but for some reason, the source is not
available. We seem to be making progress as a result of your
help. Your immediate response was most appreciated!
8. Any suggestions, comments, or recommended alternatives
regarding our TCP/IP internetworking dilemma will be most
appreciated.
Very Respectfully,
Steve Carr
LCDR, SC, USN
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
MILNET: carrs@trout.nosc.mil
MILNET: navmasso42a@nardacva.arpa
(804) 445-2171, 445-1595 (extension 36)
AUTOVON: 565-2171, 565-1595 (extension 36)
-------W8SDZ@SIMTEL20.ARPA (Keith Petersen) (01/25/88)
Steve, I saw your note in the TCP/IP newsgroup and I think we have what you need to run TCP/IP on ARCNET. The following files are available via standard anonymous FTP from SIMTEL20: Filename Type Bytes CRC Directory PD1:<MSDOS.PCIP> BOOTP.ARC.1 BINARY 15088 6A80H DOC.ARC.1 BINARY 622913 53C7H INCLUDE.ARC.1 BINARY 38768 D21FH INSTALL.BAT.1 ASCII 2354 9BC2H PCIP-DIS.TXT.1 ASCII 2334 19ACH PPP.ARC.1 BINARY 6768 407BH README..1 ASCII 4931 DF58H ROOT.ARC.1 BINARY 8494 5070H SRCCMD.ARC.1 BINARY 228864 F269H SRCDEV.ARC.1 BINARY 6768 6298H SRCLIB.ARC.1 BINARY 331417 C8C3H TARREAD.EXE.1 BINARY 17704 D35AH WATCH.EXE.1 BINARY 34304 E21FH The files above are the CMU PCIP package. In addition to those you will need the ARCNET-specific files (be careful when extracting as some member filenames are the same as those in other ARCs). Filename Type Bytes CRC Directory PD1:<MSDOS.ARCNET-PCIP> ARCNET.ARC.1 BINARY 19889 4B5CH ARCNET-RFC.TXT.1 ASCII 5622 E04CH CUSTOM.ARC.1 BINARY 16061 8391H INCLUDE.ARC.1 BINARY 9294 7B81H INTERNET.ARC.1 BINARY 17017 A921H Here is a message from the author of the ARCNET version. Please contact him for further details. Date: Saturday, 9 January 1988 23:46-MST From: Philip A. Prindeville <PAP4@AI.AI.MIT.EDU> To: w8sdz@SIMTEL20.ARPA Re: New Release of KA9Q TCP/IP Package I saw your posting to pcip about ka9q. I've used simtel20.arpa many times, and I very much appreciate it's function. It the same spirit (I hope), I've done some work on the mit/cmu pc/ip that I think many people will find use for, including fragmentation and reassembly in IP, support for ARCnet hardware, and currently a supdup.sys console driver for ms-dos and multiple connection tcp. -Philip
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (01/25/88)
Date: Sun, 24 Jan 1988 19:05 MST
Cc: tcp-ip@sri-nic.arpa
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
[ ... ]
The files above are the CMU PCIP package. In addition to those you
will need the ARCNET-specific files (be careful when extracting as
some member filenames are the same as those in other ARCs).
Filename Type Bytes CRC
Directory PD1:<MSDOS.ARCNET-PCIP>
ARCNET.ARC.1 BINARY 19889 4B5CH
ARCNET-RFC.TXT.1 ASCII 5622 E04CH
CUSTOM.ARC.1 BINARY 16061 8391H
INCLUDE.ARC.1 BINARY 9294 7B81H
INTERNET.ARC.1 BINARY 17017 A921H
I will take this chance to clarify a few things (my fault: I was
too lazy to write a README). The ".ARC" extension means ARChive,
the format the files are grouped as; previous users of SIMTEL20
will recognize this. The first two files above are the device
driver for an ARCnet interface (PDI, DATAPOINT, or SMC) and the
accompanying RFC that describes IP over ARCNET. CUSTOM includes
some generic modifications to support memory (not IO) mapped
devices (which ARCNET IFs tend to be). INCLUDE and INTERNET
are changes to the standard distribution that offer increased
functionality to IP and ICMP -- some of that functionality was
required to support ARCNET, but is not ARCNET specific. For
instance, fragmentation/reassembly had to be added to get decent
performance out of ARCNET, but will work equally well with
pronet, ethernet, and token ring. The files in INCLUDE, INTERNET,
and CUSTOM are meant to replace their counterparts in the CMU
distribution in \INCLUDE, \SRCLIB\INTERNET, and \SRCCMD\CUSTOM
respectively. You may want to back up these files before
replacing them.
Enjoy,
-PhilipPAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (01/25/88)
[ ... ]
forum. I see no evidence to indicate to me that you can get the
ARCNET/Novell Netware to interoperate via TCP/IP at the present
time. Again, any comments from users having experience in trying
to get the ARCNET to sing along with TCP/IP in an internet
environment would be most appreciated.
Your assumption about TCP/IP & NETWARE co-existance is correct: they
don't (at this time). The actual standard for IP over ARCNET is
quite new. You can get a copy of my draft RFC as "pub/arcnet.rfc"
on the host gmu90x.gmu.edu (via anonymous/ftp). John Romkey of
FTP Software, Inc. devised a standard LLC level access method for
applications to access a network interface that is not datalink
or hardware dependent (see the PCIP archives for details). Novell
supports this interface for several network types (including
ethernet), and could be convinced to support it on ARCnet as well
(if you have the bucks to make it worth their while).
I had intended to write such a driver myself, but haven't had time.
Should someone care to provide me with such software, I will make
a version of PCIP to utilize it concurrently with Netware.
Lastly, ARCNET packets do contain sufficient information to
demultiplex IP and Netware protocols, so they can be run over
the same wire.
Good luck in resolving you situation,
-Philipstev@ftp.COM (Stev Knowles) (01/26/88)
In article <315728.880124.PAP4@AI.AI.MIT.EDU>, PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes: > > [ ... ] > forum. I see no evidence to indicate to me that you can get the > ARCNET/Novell Netware to interoperate via TCP/IP at the present > time. Again, any comments from users having experience in trying > Your assumption about TCP/IP & NETWARE co-existance is correct: they > don't (at this time). The actual standard for IP over ARCNET is > > -Philip sorry, but i was under the impression that Novell offered a card for their file server (a micom interlan NP-600) that allowed for tcp-ip access from any novell netware to a tcp-ip ethernet. i am under the impression that they are running tcp-ip buried inside their own packets, and the file server is stripping them out and passing them to the NP600. i have seen this work for ethernet, and was under the impression that it worked for all the networking schemes that novell supported. stev knowles ftp software inc. 617 868 4878 /* all comments are mine */
backman@interlan.UUCP (Larry Backman) (01/26/88)
>> [ ... ] >> forum. I see no evidence to indicate to me that you can get the >> ARCNET/Novell Netware to interoperate via TCP/IP at the present >> time. Again, any comments from users having experience in trying >> Your assumption about TCP/IP & NETWARE co-existance is correct: they > >sorry, but i was under the impression that Novell offered a card for their >file server (a micom interlan NP-600) that allowed for tcp-ip access from any >novell netware to a tcp-ip ethernet. i am under the impression that they >are running tcp-ip buried inside their own packets, and the file server >is stripping them out and passing them to the NP600. i have seen this [] Disclaimer - I am prejudiced, this is my product. Micom - Interlan is shipping a Netware\TCP gateway. The gateway consists of an NP600 board placed within the file server. This board runs our standard TCP image. The gateway also consists of processes within the file server that act as daemons (FTPD, RWHOD, SMTPD, etc.). An additional process, the NETBIOS listener, is used to communicate with workstations. Workstations ( up to 31) talk to the file server and ultimately the gateway via NETBIOS. Application programs (FTP, TELNET et. al) ported from Bsd 4.3 encapsulate socket calls within NETBIOS NCB's and send the socket calls to the gateway where they are passed to the NP600. There are no TCP packets encapsulated within Netware IPX packets, instead socket calls are encapsulated within NETBIOS RPC's. Any Novell supported subnet can talk to TCP hosts using the gateway. I have seen it running on at least 6 different types of media, including ARCNET, and assume that it is running on at least another 6 types. For more information, please contact me directly. Larry Backman Micom - Interlan
Staff.Hershman@KL.GBA.NYU.EDU (Ittai Hershman) (01/26/88)
Date: 25 Jan 88 16:21:00 GMT
From: spdcc!ftp!stev@husc6.harvard.edu (Stev Knowles)
Organization: FTP Software Inc., Cambridge, MA
Subject: Re: TCP/IP Versus WANG, ARCNET/NOVELL Netware, & Honeywell
> Your assumption about TCP/IP & NETWARE co-existance is correct: they
> don't (at this time). The actual standard for IP over ARCNET is
>
> -Philip
sorry, but i was under the impression that Novell offered a card for their
file server (a micom interlan NP-600) that allowed for tcp-ip access from any
novell netware to a tcp-ip ethernet. i am under the impression that they
are running tcp-ip buried inside their own packets, and the file server
is stripping them out and passing them to the NP600. i have seen this
work for ethernet, and was under the impression that it worked for all the
networking schemes that novell supported.
stev knowles
The Micom-Interlan TCP Gateway will work with any Novell supported
networking schemes, but does not run TCP directly to the client PCs.
The way it works is that the server contains whatever card is used to
talk to the clients (eg: ethernet, starlan, arcnet (I suppose)), and
additionally an NP600A (with a chip serialized to the TCP Gateway
software). Communication between client and server is done using the
Novell protocol and then converted to TCP/IP by the server and sent to
the ethernet backbone via the NP600A.
This has the added interesting property that only a single IP number is
needed for up to 32 simultaneous client PCs, making the administration
of "subnets" (I mean it in the sense of a PC lab, or a floor of offices)
much easier. It is also very cost effective, because you can buy very
cheap networking cards (Starlan in my case) for the client PCs. On the
negative side, some speed is obviously lost to the gatewaying.
-Ittai
-------CERF@A.ISI.EDU (01/26/88)
NOVELL Netware and TCP/IP have been made to interoperate by Novell. My understanding of the method is that the file server in the Novell Netware system also has TCP/IP implemented. A user's PC forms a connection using Netware to a server process in the machine that also runs the file server and that process permits a TCP/IP connection to be formed going to the desired destination. I do not know any of the details of the software or how one conveys the desired IP destination to the TCP/IP server. It may behave like TELNET piggybacking (where you log into a host and TELNET back out again, specifying where you want to go to the User Telnet). Vint Cerf
lyndon@ncc.UUCP (Lyndon Nerenberg) (01/27/88)
In article <8801242026.AA29303@trout.nosc.mil>, carrs@TROUT.NOSC.MIL (Stephen M. Carr) writes: > [...] > 5. Unfortunately, we are confronted with several problems. > a. The command has a WANG VS-300 which I don't know how we > are going to connect via TCP/IP. Is there anybody out there that > can tell me if there is a TCP/IP solution out there or in the > wings for a WANG VS-300? The vendor is promising the moon, but > WANG sales representatives promised me this same moon about 12 > months ago. They are going to brief us on Tuesday, 26 January > 1988 with their latest promises. I would sure appreciate some > straight skinny from any other users out there that have any > experiences with getting a WANG VS-300 singing on the internet! > I would like to go to this meeting armed with comments from this > forum if at all possible. After having dealt with Wang regarding communications software on a number of occasions, all I can suggest is that you believe absolutely NOTHING they say... I highly doubt Wang will come out with Ethernet at any time. They have been promising this to us for over two years... As a result of the above, we decided to purchase their 2780RJE software to (at least) allow file transfer. As it turns out, their "IBM Standard 2780 RJE software won't talk to our Convergent Technologies 2780 RJE package", according to the Wang salesman. I know the CT software works, but I have been unable to get the VS65 to talk to it, so I guess (for once) the Wang salesman was not lying! Of course, I'd really like to know why they didn't tell us this prior to our purchasing the software (this configuration was in the spec) ... I have also been unable to get their X.25 software working in the same environment. If we could get this to function at least the Wang users would be able to call out to another host, although this doesn't even begin to approach the flexibility of having TCP/IP. We *did* find a solution though. We are scrapping the VS65, and replacing the workstations with PC/XT's (clones actually) running the Wang WP under MS-DOS. The clones have a replacement keyboard identical to the Wang keyboard. The VS65 will be replaced by a Sun 3/280. The clones will be running PC/NFS, allowing them to share file system space on the Sun. They can also telnet to any host on the Ethernet and can ftp files around as well. The *best* part of all this is the Sun + the PC's + the NFS cards and all the glue costs 30% less than the VS65 alone... I know this won't directly solve your problem, but I hope it gives you (and others) a bit of insight into alternatives to the very restricted Wang operating environment. [ Wow, I feel better now :-) ] --lyndon
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (01/27/88)
[ .... ]
My understanding of the method is that the file server in the
Novell Netware system also has TCP/IP implemented. A user's PC
forms a connection using Netware to a server process in the
machine that also runs the file server and that process permits
a TCP/IP connection to be formed going to the desired destination.
Well, I meant something more along the lines of each PC being its own
IP host (rather than TCP being a resource a remote server provides [I
hesitate to call the server a translating gateway]) where a user
could have both file service and TCP/IP software (say SMTP), without
the two applications fighting for the interface's interrupt...
-Philipbackman@interlan.UUCP (Larry Backman) (01/28/88)
In article <316966.880127.PAP4@AI.AI.MIT.EDU> PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") writes: >The TCP is on the server, not on the client. The server merely presents >it as resource accessible via IPX. Because the TCP never really exists on >the client, it can't be called co-resident. [] Philip, Please get your ts correct. TCP is on a coprocessor resident within the server. It is advertised to workstations via Novell's Service Advertising Protocol (SAP). It is accessable via NETBIOS rather than IPX. Larry Backman Micom - Interlan
backman@interlan.UUCP (Larry Backman) (02/01/88)
In article <[A.ISI.EDU]26-Jan-88.08:13:44.CERF> CERF@A.ISI.EDU writes: >NOVELL Netware and TCP/IP have been made to interoperate by Novell. > >I do not know any of the details of the software or how one conveys >the desired IP destination to the TCP/IP server. It may behave like >TELNET piggybacking (where you log into a host and TELNET back out >again, specifying where you want to go to the User Telnet). > [] Sorry to bang the drum loudly but... Micom-Interlan implemented the TCP gateway under Netware with OS support from Novell. They know Netware, we know TCP.(or kind of). Client programs on the gateway were ported from Bsd4.3, they look and act exactly the same. A user wishing to use TELNET goes through the following script: ipx /* load Netware driver in workstation*/ net3 /* load Netware redirector */ f:login server\username netbios /* load NETBIOS emulator */ gwattach gatewayname /*make a NETBIOS connection between PC and server */ Telnet vax4 ..... The server and gateway are roughly analogous to a real OS with TCP. You log on to a file server, prepare your environment, and then use TCP as a service. We ifconfig addresses just like UNIX, and have an /etc/hosts file just like UNIX. In our next release we will have domain name resolution... Hope I clarified things. Larry Backman Micom - Interlan