news@clyde.att.com (Netnews Admin) (09/28/86)
Path: clyde!cbatt!cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <2629@cbosgd.ATT.COM> Date: 28 Sep 86 15:54:40 GMT References: <8609280151.AA12210@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 13 Summary: False SMTP mail is easy to generate, but so is false paper mail AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: > A while back I saw a copy of a newsletter titled "2600" which included > source code demonstrating how one could pretend to be an SMTP engine and > inject false mail into a host. Although the code had a few flaws, its > general structure looked plausable (and short -- about 25 lines of C). Sure it is. But that's not surprising. I can easily generate false paper mail with a phony return address, and dump it into a paper mailbox, too. Nobody ever said EMail was hard to forge. Mark
mark@cbosgd.att.com (Mark Horton) (09/29/86)
Path: cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <2632@cbosgd.ATT.COM> Date: 29 Sep 86 00:25:32 GMT References: <8609280151.AA12210@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 13 Summary: False SMTP mail is easy to generate, but so is false paper mail AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: > A while back I saw a copy of a newsletter titled "2600" which included > source code demonstrating how one could pretend to be an SMTP engine and > inject false mail into a host. Although the code had a few flaws, its > general structure looked plausable (and short -- about 25 lines of C). Sure it is. But that's not surprising. I can easily generate false paper mail with a phony return address, and dump it into a paper mailbox, too. Nobody ever said EMail was hard to forge. Mark
egisin%watmath.waterloo.edu@RELAY.CS.NET.UUCP (11/21/86)
Path: watmath!egisin From: egisin@Math.Waterloo.EDU (Eric Gisin @ University of Waterloo) Newsgroups: mod.protocols.tcp-ip,comp.protocols.tcp-ip,comp.unix.wizards Subject: Symmetric TCP connection in 4.2 BSD Message-ID: <3487@watmath.UUCP> Date: 21 Nov 86 19:59:20 GMT Sender: egisin@watmath.UUCP Lines: 21 I'm trying to develop an IP application under 4.2 BSD that requires a symmetric TCP connection, as opposed to the assymmetric connection commonly used in the client/server scheme. The application is a RSCS line driver. I was initially going to use UDP in place of BISYNC, but BISYNC is too brain damaged for this to be done easily. So I decided to replace the lower half of the RSCS line protocol (VMB) with TCP. I haven't been able to come up with a way to establish the TCP connection between two RSCS line daemons symmetrically, which was trivial to do with UDP (with a socket, bind, and connect). The TCP specifcation says a TCP should be able to establish a connection with two active sockets, or that you can passively wait for a connection from a specified host. 4.2 allows neither of these. Does anyone have any 4.2/4.3 code to do this? It would be preferable if it used one well know port and had the ability to have more than one line daemon per host. RSCS does not easily allow me to use listen, accept, fork; the line daemon processes are started at boot time.
uppal@uwvax.UUCP (Sanjay Uppal) (11/30/86)
Path: uwvax!uppal From: uppal@rsch.WISC.EDU (Sanjay Uppal) Newsgroups: mod.protocols.tcp-ip,misc.wanted Subject: MIT PC/IP request Keywords: HELP, crosscompiler, MITPC/IP Message-ID: <3010@rsch.WISC.EDU> Date: 30 Nov 86 03:15:18 GMT Distribution: na Organization: U of Wisconsin CS Dept Lines: 20 HELP! We obtained the PC/IP code of March 1986 from the MIT Lab.(the tar tape). However, we are unable to get the cross compiler. The person at MIT didn't know from where we could get it. Meanwhile, we had an old cross compiler version, and went about making the changes as mentioned in the INSTALL file in the release. The "context diffs were merged by hand", and the instructions were followed to the letter. However, we are in a deeper mess now, as we are getting strange errors while doing "make". Could somebody please direct us to the source of the cross compiler which is compatible with the March 1986 distribution? Or better, send/mail/ftp to us if you have a running version? Thanks (In desperation) Sanjay Uppal (uppal@rsch.wisc.edu) C.W. Bhide (bhide@jack.wisc.edu)
mtxuucp@seismo.CSS.GOV@elsie.UUCP (mt Xinu uucp login) (12/16/86)
Path: elsie!cvl!mimsy!mark From: mark@mimsy.UUCP (Mark Weiser) Newsgroups: mod.protocols.tcp-ip Subject: Re: Protcol Development on SUN 2 and 3 computers. Message-ID: <4760@mimsy.UUCP> Date: 16 Dec 86 07:39:39 GMT References: <8612152127.AA05241@spam.istc.sri.com> Reply-To: mark@mimsy.UUCP (Mark Weiser) Organization: Computer Sci. Dept, U of Maryland, College Park, MD Lines: 22 In article <8612152127.AA05241@spam.istc.sri.com> robert@SPAM.ISTC.SRI.COM (Robert Allen) writes: > > I'm wondering if anyone has attempted to develop other >protocols on Sun computers using the "open-architecture". From >initial inspection of the Sun document "Network Implementation" >it appears that one can provide different protocol routines at >various layers, and make use of the kernel hooks built into the >system, thus provideing socket-type interfaces for protocols other >than the currently supported TCP/IP and UDP ... > Actually, Suns open network architecture is just Berkeley 4.2bsd's architecture, which is not so open if you try to do a really different protocol, as we did with XNS. 4.3bsd Unix is much more amenable to different protocols, and we have (twice now) stripped out Sun's networking code and replaced it with the 4.3 code, in order to include 4.3's XNS support. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.cs.umd Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
uucp@SEISMO.CSS.GOV.UUCP (12/16/86)
Path: seismo!mimsy!mark From: mark@mimsy.UUCP (Mark Weiser) Newsgroups: mod.protocols.tcp-ip Subject: Re: Protcol Development on SUN 2 and 3 computers. Message-ID: <4760@mimsy.UUCP> Date: 16 Dec 86 07:39:39 GMT References: <8612152127.AA05241@spam.istc.sri.com> Reply-To: mark@mimsy.UUCP (Mark Weiser) Organization: Computer Sci. Dept, U of Maryland, College Park, MD Lines: 22 In article <8612152127.AA05241@spam.istc.sri.com> robert@SPAM.ISTC.SRI.COM (Robert Allen) writes: > > I'm wondering if anyone has attempted to develop other >protocols on Sun computers using the "open-architecture". From >initial inspection of the Sun document "Network Implementation" >it appears that one can provide different protocol routines at >various layers, and make use of the kernel hooks built into the >system, thus provideing socket-type interfaces for protocols other >than the currently supported TCP/IP and UDP ... > Actually, Suns open network architecture is just Berkeley 4.2bsd's architecture, which is not so open if you try to do a really different protocol, as we did with XNS. 4.3bsd Unix is much more amenable to different protocols, and we have (twice now) stripped out Sun's networking code and replaced it with the 4.3 code, in order to include 4.3's XNS support. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.cs.umd Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
bill@ucbvax.Berkeley.EDU@tifsie.UUCP (12/18/86)
Path: tifsie!bill
From: bill@tifsie.UUCP (Bill Stoltz)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: VM Interface for TCP/IP
Keywords: VM, TCP/IP, network
Message-ID: <278@tifsie.UUCP>
Date: 17 Dec 86 21:39:07 GMT
Article-I.D.: tifsie.278
Posted: Wed Dec 17 15:39:07 1986
Organization: TI Process Automation Center, Dallas
Lines: 54
I just received my copy of "The IBM Software Catalog for VM Systems"
in the mail today. The following is an excerpt from this catalog.
VM Interface Program for TCP/IP
-------------------------------
Program Number: 5798-DRG
Purpose: This program offering provieds the VM/SP user with
the ability to participate in a network using the
TCP/IP transmission protocol. This includes the
ability to transfer files, send mail, and log on
remotely to a VM host. The Program uses a
System/370 channel, attached to a front-end Series/1
with EDX or RPS, or a Device Access Control Unit.
Sample programs are provided for these system
configuratuions to permit intrfaceing to local area
networks including X.25, ProNET, or Ethernet.
Manuals: Availability Notice, GB13-7712.
I was wondering if anyone has had any experience
with this product and what likes and dislikes they have with this
product.
I have not talked with my IBM salesman yet, so I don't have any other
information (cost, availability, etc).
If you mail any reques to me I will be glad to send you any additional
information when I get it. If there is enough demand I will post a summary
to the net.
Thanks for any help.
Bill
-----------------
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice: (214) 995-2786dorl@seismo.CSS.GOV@uwmacc.UUCP (12/22/86)
Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: Ethernet loading tools Message-ID: <756@uwmacc.UUCP> Date: 22 Dec 86 15:04:12 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 7 I am looking for some tools to load an Ethernet. I am interested in software for use with BSD Unix or Wollongong WIN/VX that puts a heavy load on a Ethernet. I want to be able to put a known load on the network and hopefully also gather some statistics such as collisions, late collisons, byte counts, packet counts (good and bad), etc. I'd be satisfied to find client programs that generate traffic with specifed characteristics to use with the ECHO and DISCARD servers.
dorl@seismo.CSS.GOV@uwmacc.UUCP (12/22/86)
Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.bugs.4bsd Subject: Telnet - Local flow control Message-ID: <757@uwmacc.UUCP> Date: 22 Dec 86 15:08:57 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 2 Keywords: telnet, flow control I am looking for patches to BSD 4.3 telnet that allows local flow control. Ideally, telnet should allow the user to specify this as an option.
deller@seismo.CSS.GOV@vrdxhq.UUCP (12/25/86)
Path: vrdxhq!deller From: deller@vrdxhq.UUCP (Steven Deller) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: UNIX supports other filesystem names better than any other OS Message-ID: <2688@vrdxhq.UUCP> Date: 25 Dec 86 05:01:17 GMT References: <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM> Organization: Verdix Corporation, Chantilly, VA Lines: 54 In article <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM>, sned@PEGASUS.SCRC.Symbolics.COM (Steven L. Sneddon) writes: > . . . > you'd be no better off. As I see it, the problem is really the lack > of support for anything but UN*X filesystem syntax in UN*X. The UN*X filesystem syntax, at least BSD, with 256 arbitrary characters per file "level", and up to 4096 arbitrary characters total, appears to be a superset of any names needed by other OS's. We have, ourselves, provided a simple VMS pathname to UNIX pathname converter for keeping a VMS hierarchy on UNIX. It parses: ddnn:[dir1.dir2.dir3]file.ext;ver into ddnn/dir1/dir2/dir3/file.ext;ver There is special handling if ";ver" is missing (use one greater than the highest existing, or use ;1). The only problems we have, is when going from an arbitrary and "unlimited" naming scheme as BSD UNIX provides, to limited, heavily structured naming schemes in systems such as VMS. The solutions (for example, as found in Eunice or on Apollo machines) are not "pretty" because those file systems have so many restrictions on the characters allowed, and the meaning of those characters. I will admit to not having used SYSV, or other AT&T incantations of UNIX, so please do not confuse "generic UN*X" with the UNIX I know. The problem would be removed only if all systems used the same system. Having used about 100 systems in my 25 years of programming, I would strongly vote for BSD UNIX -- that is, no "operational" naming limitations for a normal user. > . . . > By the way, it's interesting that Lisp Machines, which were designed > from the beginning to be used as workstations on a network, adopted the > pathname syntax of host:string-for-host for 'open'. UN*X, which was > designed as a self-contained system, has to indirectly chop a local > pathname, in UN*X pathname syntax, into host and string-for-host via > Special Files and Mount Tables. That the only thing you could pass to > a UN*X 'open' is a UN*X pathname seems to me to be at the root of the > problem. When I think about what it would take to change this, my head > starts to hurt [I know my share about UN*X, too]. Sorry, but putting host names into file names at the application level is a step backward. I want to get to a file "/xxx/yyy/zzz" regardless of where it is located today. And I want the system administrator, or myself, to be able to relocate the file to where it makes the most sense, without breaking my application. Examined closely, the ONLY naming scheme that makes sense is a strictly independent pure hierarchy, with lots of name freedom. Now you can object to "/" as the separator of the hierarchical names, and you can object to the method for mapping logical names to physical addresses, but you really shouldn't object to an implementation of the only sensible naming approach. Steven Deller -- <end_message> ::= <disclaimer> | <joke> | <witty_saying> | <cute_graphic> {verdix,seismo,umcp-cs}!vrdxhq!deller
deller@seismo.CSS.GOV@vrdxhq.UUCP (12/25/86)
Path: vrdxhq!deller From: deller@vrdxhq.UUCP (Steven Deller) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: BSD UNIX supports other filesystem names better than any other OS Message-ID: <2690@vrdxhq.UUCP> Date: 25 Dec 86 07:11:04 GMT References: <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM> Organization: Verdix Corporation, Chantilly, VA Lines: 58 In article <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM>, sned@PEGASUS.SCRC.Symbolics.COM (Steven L. Sneddon) writes: > . . . > you'd be no better off. As I see it, the problem is really the lack > of support for anything but UN*X filesystem syntax in UN*X. The UN*X filesystem syntax, at least BSD, with 256 arbitrary characters per file "level", and up to 4096 arbitrary characters total, appears to be a superset of any names needed by other OS's. We have, ourselves, provided a simple VMS pathname to UNIX pathname converter for keeping a VMS hierarchy on UNIX. It parses: ddnn:[dir1.dir2.dir3]file.ext;ver into ddnn/dir1/dir2/dir3/file.ext;ver There is special handling if ";ver" is missing (use one greater than the highest existing, or use ;1). The only problems we have, is when going from an arbitrary and "unlimited" naming scheme as BSD UNIX provides, to limited, heavily structured naming schemes in systems such as VMS. The solutions (for example, as found in Eunice or on Apollo machines) are not "pretty" because those file systems have so many restrictions on the characters allowed, and the meaning of those characters. I will admit to not having used SYSV, or other AT&T incantations of UNIX, so please do not confuse "generic UN*X" with the UNIX I know. The problem would be removed only if all systems used the same system. Having used about 100 systems in my 25 years of programming, I would strongly vote for BSD UNIX -- that is, no "operational" naming limitations for a normal user. > . . . > By the way, it's interesting that Lisp Machines, which were designed > from the beginning to be used as workstations on a network, adopted the > pathname syntax of host:string-for-host for 'open'. UN*X, which was > designed as a self-contained system, has to indirectly chop a local > pathname, in UN*X pathname syntax, into host and string-for-host via > Special Files and Mount Tables. That the only thing you could pass to > a UN*X 'open' is a UN*X pathname seems to me to be at the root of the > problem. When I think about what it would take to change this, my head > starts to hurt [I know my share about UN*X, too]. Sorry, but putting host names into file names at the application level is a step backward. I want to get to a file "/xxx/yyy/zzz" regardless of where it is located today. And I want the system administrator, or myself, to be able to relocate the file to where it makes the most sense, without breaking my application. Examined closely, the ONLY naming scheme that makes sense is a strictly independent pure hierarchy, with lots of name freedom. Now you can object to "/" as the separator of the hierarchical names, and you can object to the method for mapping logical names to physical addresses, but you really shouldn't object to an implementation of the only sensible naming approach. Steven Deller -- <end_message> ::= <disclaimer> | <joke> | <witty_saying> | <cute_graphic> {verdix,seismo,umcp-cs}!vrdxhq!deller (Steven Deller) -- <end_message> ::= <disclaimer> | <joke> | <witty_saying> | <cute_graphic> {verdix,seismo,umcp-cs}!vrdxhq!deller
news@seismo.CSS.GOV@sun.UUCP (12/29/86)
Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Summary: OK, what *about* "tmpfile"? Message-ID: <10850@sun.uucp> Date: 29 Dec 86 08:24:25 GMT References: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM> Sender: news@sun.uucp Lines: 20 > In all this discussion of ways that NFS doesn't quite meet the > "UNIX semantics" (this means "UNIX System V semantics", since > UNIX is a trademark of AT&T and AT&T considers only its own > releases to be UNIX) there is one more gotcha lurking. > > The traditional implementation of (tmpfile) is to make up a name > in /tmp, create the file, keep it open, and unlink it. This works fine > on System V and 4BSD. It probably fails on VMS/Eunice. As far as I'm > aware, it also fails when /tmp is NFS mounted on a remote system. Well, you aren't aware of how the Sun NFS implementation works; it works just fine when "/tmp" is NFS mounted on a remote system. (I just tried it, with "tmpfile" - "tmpnam", actually - modified to use an NFS-mounted file system.) The local kernel knows that the file is open, and instead of unlinking it, it renames it to a temporary name and deletes the temporary file when the last program on the client that created it finishes with it. Yes, this will fail if a process on a *different* machine unlinks it. However, it's difficult for another such process to unlink it under UNIX, since it only has a name for a very short time.
news@seismo.CSS.GOV@sun.UUCP (12/29/86)
Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: Pathname syntax/semantics and file formats are two separate issues. Message-ID: <10851@sun.uucp> Date: 29 Dec 86 08:32:06 GMT References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: news@sun.uucp Lines: 15 > Consider TOPS-20 directory structure, VM/CMS mini-disks, file system > that permit "/" characters in their filenames, or especially file > systems (like VMS and VM/CMS) that have structured (non-byte stream) > files. None of them map very quietly into a hierarchical set of > directories separated by "/" characters, and there are more and harder > where they came from. The problem with VMS pathnames has nothing whatsoever to do with the fact that some operating systems keep file attributes like file format around and that a certain level of those OSes (not the kernel, in the case of VMS, but RMS) imposes a certain interpretation of the bytes in the file, based on these file attributes, on its clients. Those are separate issues; you can build a system with a VMS-style pathname syntax but with no interpretation of the file's contents below user-mode code, or a system with UNIX-style pathnames but with VMS-style file attributes handled by something like RMS.
Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM.UUCP (12/29/86)
Date: 29 Dec 86 08:32:06 GMT
From: sun!news@seismo.CSS.GOV
Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Need information on NFS
Summary: Pathname syntax/semantics and file formats are two separate issues.
Message-ID: <10851@sun.uucp>
Date: 29 Dec 86 08:32:06 GMT
References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
Sender: news@sun.uucp
Lines: 15
> Consider TOPS-20 directory structure, VM/CMS mini-disks, file system
> that permit "/" characters in their filenames, or especially file
> systems (like VMS and VM/CMS) that have structured (non-byte stream)
> files. None of them map very quietly into a hierarchical set of
> directories separated by "/" characters, and there are more and harder
> where they came from.
The problem with VMS pathnames has nothing whatsoever to do with the fact
that some operating systems keep file attributes like file format around and
that a certain level of those OSes (not the kernel, in the case of VMS, but
RMS) imposes a certain interpretation of the bytes in the file, based on
these file attributes, on its clients. Those are separate issues; you can
build a system with a VMS-style pathname syntax but with no interpretation
of the file's contents below user-mode code, or a system with UNIX-style
pathnames but with VMS-style file attributes handled by something like RMS.
Indeed. Perhaps if I changed the last sentence to:
"None of them map very quietly into a hierarchical set of directories
separated by "/" characters where all of the files are expected to be
simple vectors of 8bit bytes"
you would like it better. They are separate problems. They are both
hard.Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies) (12/29/86)
Date: 29 Dec 86 08:32:06 GMT From: sun!news@seismo.CSS.GOV Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: Pathname syntax/semantics and file formats are two separate issues. Message-ID: <10851@sun.uucp> Date: 29 Dec 86 08:32:06 GMT References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: news@sun.uucp Lines: 15 > Consider TOPS-20 directory structure, VM/CMS mini-disks, file system > that permit "/" characters in their filenames, or especially file > systems (like VMS and VM/CMS) that have structured (non-byte stream) > files. None of them map very quietly into a hierarchical set of > directories separated by "/" characters, and there are more and harder > where they came from. The problem with VMS pathnames has nothing whatsoever to do with the fact that some operating systems keep file attributes like file format around and that a certain level of those OSes (not the kernel, in the case of VMS, but RMS) imposes a certain interpretation of the bytes in the file, based on these file attributes, on its clients. Those are separate issues; you can build a system with a VMS-style pathname syntax but with no interpretation of the file's contents below user-mode code, or a system with UNIX-style pathnames but with VMS-style file attributes handled by something like RMS. Indeed. Perhaps if I changed the last sentence to: "None of them map very quietly into a hierarchical set of directories separated by "/" characters where all of the files are expected to be simple vectors of 8bit bytes" you would like it better. They are separate problems. They are both hard.
brad@seismo.CSS.GOV@sun.UUCP (12/31/86)
Path: sun!brad From: brad@sun.uucp (Brad Taylor) Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Summary: Clearing the air about authentication and NFS Message-ID: <10911@sun.uucp> Date: 31 Dec 86 07:38:36 GMT References: <4889@cornell.UUCP> <8612281219.AA16219@gvax.cs.cornell.edu> Organization: Sun Microsystems, Inc. Lines: 79 There are many misconceptions about authentication. Let my try to clear them up. > In article <4889@cornell.UUCP> nowicki@Sun.COM (Bill Nowicki) writes: > >Let me try to correct some misconceptions: > > ..., NFS has no security or authentication. > >Authentication is done at the RPC level in a very open-ended > >manner. The default in the first implementation was to trust UIDs, > >since that is all that Unix provides. A scheme based on public-key > >encription has been discussed in papers (Goldberg and Taylor, Usenix > >conference 1985). > Although Bill is technically correct, it still seems fair to say that > "NFS has no security or authentication" and that this is a VERY serious > weakness of the SUN NFS standard. The statement "NFS has no security or authentication" is simply not true. There *is* a limited form of security with UNIX authentication. If you trust all of the nodes connected to the network, then the entire system is secure. We know this assumption is unreasonable in many cases, and that is why we proposed the alternative system. In the alternative system, you do not have to trust your network. It also fixes the other problem with UNIX authentication, that being that it is to UNIX-oriented (good name for the authentication system, eh?). In the alternative scheme, users are not reference by a uid, but by a string of characters only and a database is used by the server to convert from the string into the particular form of authentication required by the OS. For UNIX, it's uids, but other operating systems are free to map it into something else. > SUN RPC is open ended in this regard, > but the only form of authentication standardized is "UNIX-style" i.e. > none. Since SMI has not officially endorsed the Goldberg&Taylor scheme, > the situation is far worse than a simple lack of implementation. The > fact remains that one can easily break security on any SUN NFS cluster > if he/she has access to any diskless client. Wrong. The situation is no more than a lack of implementation. And again one must have more than mere access to a client machine to break security with the UNIX form of authentication: you must have root access to do it. (With the proviso being that, on Unix at least, init is changed to prompt for a password during single user boots: a simple hack). > More abstractly, it is arguable that authentication at the RPC level is > inappropriate for application-level security. It requires that the > application (NFS) have a much closer coupling than I would like to the > transport mechanism (RPC). First of all, RPC is not a transport protocol. Secondly, it makes a lot of sense to put authentication at the RPC level. Think of the analogy to transport protocols, where you can think of the source address as a primitive form of authentication (and used as such by many network applications). Also, implementation-wise, since all of the RPC applications have the RPC code in common, it is a natural place to put the other thing they have in common here too. I don't feel this is a very important issue though. What's far more important than layering is how secure and general purpose the authentication system is. > As an example of the problems that this > confusion of layering causes, consider how you'd handle a file system type > that required secondary authentication, e.g. a Tops-20 like system that > had both user id's and file "accounts", with perhaps a password associated > with the account -- seems to me your NFS-level authentication scheme must > of necessity be specific to the particular type of remote file system if > you want file security equal to what you have in a local file system. Nothing in the RPC protocol prevents you from implementing your TOPS-20 authentication scheme, since RPC can support several authentication schemes. We aim for more general purpose authentication systems than this, though. > For comparison, consider Authentication in the Xerox Filing (distributed > file system) protocol, which is much more robust than anything I've > seen considered as an NFS extension (but which still has major flaws...). > See "Authentication Protocol", XSIS 098404, and "Filing Protocol", > XNSS 108605. Well, if you like the XEROX protocol so much, then you'll should like our proposal too because it's pretty similar. (By the way, the date on the paper describing the alternative system is 1986, not 1985 as stated above).
UUCP@seismo.CSS.GOV@vu-vlsi.UUCP (01/02/87)
Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!news@seismo.CSS.GOV@sun.UUCP From: news@seismo.CSS.GOV@sun.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8612290824.AA11689@sun.Sun.COM> Date: 29 Dec 86 08:24:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 App@wved: tcp-ip@sri-nic.arpa Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: More NFS discussion Summary: OK, what *about* "tmpfile"? Message-ID: <10850@sun.uucp> Date: 29 Dec 86 08:24:25 GMT References: <8612242233.AA06278@cbosgd.MIS.OH.ATT.COM> Sender: news@sun.uucp Lines: 20 > In all this discussion of ways that NFS doesn't quite meet the > "UNIX semantics" (this means "UNIX System V semantics", since > UNIX is a trademark of AT&T and AT&T considers only its own > releases to be UNIX) there is one more gotcha lurking. > > The traditional implementation of (tmpfile) is to make up a name > in /tmp, create the file, keep it open, and unlink it. This works fine > on System V and 4BSD. It probably fails on VMS/Eunice. As far as I'm > aware, it also fails when /tmp is NFS mounted on a remote system. Well, you aren't aware of how the Sun NFS implementation works; it works just fine when "/tmp" is NFS mounted on a remote system. (I just tried it, with "tmpfile" - "tmpnam", actually - modified to use an NFS-mounted file system.) The local kernel knows that the file is open, and instead of unlinking it, it renames it to a temporary name and deletes the temporary file when the last program on the client that created it finishes with it. Yes, this will fail if a process on a *different* machine unlinks it. However, it's difficult for another such process to unlink it under UNIX, since it only has a name for a very short time.
UUCP@seismo.CSS.GOV@vu-vlsi.UUCP (01/02/87)
Path: vu-vlsi!cbmvax!rutgers!ames!ucbcad!ucbvax!SAPSUCKER.SCRC.SYMBOLICS.COM!Margulies From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <861229093712.6.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: 29 Dec 86 14:37:00 GMT References: <8612291349.AA17416@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 App@oved: tcp-ip@sri-nic.arpa Date: 29 Dec 86 08:32:06 GMT From: sun!news@seismo.CSS.GOV Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: Pathname syntax/semantics and file formats are two separate issues. Message-ID: <10851@sun.uucp> Date: 29 Dec 86 08:32:06 GMT References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM> Sender: news@sun.uucp Lines: 15 > Consider TOPS-20 directory structure, VM/CMS mini-disks, file system > that permit "/" characters in their filenames, or especially file > systems (like VMS and VM/CMS) that have structured (non-byte stream) > files. None of them map very quietly into a hierarchical set of > directories separated by "/" characters, and there are more and harder > where they came from. The problem with VMS pathnames has nothing whatsoever to do with the fact that some operating systems keep file attributes like file format around and that a certain level of those OSes (not the kernel, in the case of VMS, but RMS) imposes a certain interpretation of the bytes in the file, based on these file attributes, on its clients. Those are separate issues; you can build a system with a VMS-style pathname syntax but with no interpretation of the file's contents below user-mode code, or a system with UNIX-style pathnames but with VMS-style file attributes handled by something like RMS. Indeed. Perhaps if I changed the last sentence to: "None of them map very quietly into a hierarchical set of directories separated by "/" characters where all of the files are expected to be simple vectors of 8bit bytes" you would like it better. They are separate problems. They are both hard.
whna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) (01/06/87)
Path: cgcha!whna
From: whna@cgcha.UUCP (Heinz Naef)
Newsgroups: mod.protocols.tcp-ip
Subject: Please put me on the tcp-ip mailing list
Message-ID: <202@cgcha.UUCP>
Date: 6 Jan 87 16:08:54 GMT
Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH
Lines: 7
Please enter the following symbolic mail address into the distribution list
for TCP/IP related mail/news:
tcpip@cgcha.UUCP
Thanks and best regards,
Heinz Naefwhna%cgcha.UUCP%cernvax.BITNET@WISCVM.WISC.EDU (Heinz Naef) (01/14/87)
Path: cgcha!whna From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: comp.sources.wanted,mod.computers.sun,mod.protocols.tcp-ip Subject: SLIP (Serial IP over asynchronous line) Keywords: SLIP, IP, PC/IP, TCP/IP, asynchronous. Message-ID: <204@cgcha.UUCP> Date: 14 Jan 87 14:12:11 GMT Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, Basel, CH Lines: 15 Does anybody have implemented a piece of software on a UN*X 4.2bsd system that supports the DoD Internet Protocol (IP) over asynchronous serial lines? There are products available for MS/DOS PC's that offer this type of attachment. These would allow PC-like systems that are located far away from the Ethernet to get connected to the UN*X systems over phone lines. PC users could take advantage of the Telnet, FTP etc. client functions as if they were directly attached to the Ethernet, except they would experience slower speed and some operational differences (dial-up, point-to-point etc.). Thanks for your help, Heinz Naef. Please respond by electronic mail: ..!mcvax!cgcha!whna.
lear@rutgers.edu@aramis.UUCP (01/15/87)
Path: aramis!lear
From: lear@aramis.RUTGERS.EDU (eliot lear)
Newsgroups: mod.protocols.tcp-ip,comp.unix.wizards
Subject: routed question/survey
Message-ID: <220@aramis.RUTGERS.EDU>
Date: 15 Jan 87 01:06:29 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 15
Hi,
I am writing a graphically oriented network monitoring facility and
I am interested in using routed to derive a map of systems on the
various networks. My first question: Is routed used enough to get a
good picture of the net? My second question: Does anyone know if
protocol specs exist for routed?
Thanks in advance,
...eliot
--
[lear@rutgers.rutgers.edu]
[{harvard|pyrnj|seismo|ihnp4}!rutgers!lear]stever@videovax.tek.com.UUCP (01/16/87)
Path: videovax!stever
From: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tektronics TCP/IP for VMS
Summary: Please spell it correctly. . .
Keywords: Tektronix TCP/IP VMS free
Message-ID: <4159@videovax.Tek.COM>
Date: 16 Jan 87 17:22:48 GMT
References: <8701131751.AA17600@cieunix.rpi.edu> <8701141554.AA18711@ohio-state.ARPA>
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 11
Aarrrrggghhhh!!!!!!
Subject: Tektronics TCP/IP for VMS
^^^^^^^^^^
There are neither "cee"s nor "ess"s in "Tektronix"!!
Steve Rice
----------------------------------------------------------------------------
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!steverstever@videovax.tek.com.UUCP (01/16/87)
Path: videovax!stever From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Newsgroups: mod.protocols.tcp-ip Subject: Re: Analyzing Acknowledgement Strategies Summary: Please continue to let us in on the discussion! Message-ID: <4160@videovax.Tek.COM> Date: 16 Jan 87 17:41:18 GMT References: <8701151850.AA18157@lbl-csam.arpa> Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 22 In article <8701151850.AA18157@lbl-csam.arpa>, Van Jacobson (van@LBL-CSAM.ARPA) writes: > Dave - [ body of the article deleted ] > - Van > > ps- perhaps we should take this discussion off line? I've been > filling up peoples' mailboxes lately and I get the impression > that there are only two or three of us interested in this topic. I cannot speak for anyone but myself, but I appreciate seeing the discussion of these issues. I am not at present directly involved with such networks, but the problems discussed are food for thought and the solutions proposed have bearing in other areas. Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
mrs2@seismo.CSS.GOV@bunny.UUCP (Mark Scherfling) (01/17/87)
Path: bunny!mrs2 From: mrs2@bunny.UUCP (Mark Scherfling) Newsgroups: mod.protocols.tcp-ip Subject: SUN RPC for VMS TCP/IP Query Keywords: Help, SUN RPC, Wollongong TCP/IP, VMS Message-ID: <886@bunny.UUCP> Date: 17 Jan 87 18:44:22 GMT Distribution: usa Organization: GTE Laboratories, Waltham, MA Lines: 13 Has anyone ever thought of or completed a port of the Public Domain SUN RPC protocols to other operating systems, particularly VMS? We are running the Wollongong TCP/IP for VMS and would like to also support RPC. I know Wollongong now sells NFS, but I don't want to pay for it just to get RPC. Also, if such a port is possible, we would also like to support RPC on our IBM mainframe. We are running the Spartacus KNET software for MVS. Any help would be appreciated. -- Mark Scherfling GTE Labs
shapiro@oucs.ohiou.edu.UUCP (02/02/87)
Path: oucs!shapiro From: shapiro@oucs.OHIOU.EDU (Brian Shapiro) Newsgroups: mod.protocols.tcp-ip Subject: Help: tcp-ip vs. xns Message-ID: <472@oucs.OHIOU.EDU> Date: 2 Feb 87 19:15:31 GMT Distribution: mod Organization: Ohio University CS Department, Athens Lines: 19 There has been consideration given to the idea of converting our Bridge communications XNS based network over to TCP-IP protocol. This is being considered because a statewide supercomputer center is in the works. We are not a DoD research site have no access to ARPAnet without going thru the BITNET-ARPA net gateways. Is ther anyone out there that can tell me what advantages we will have using TCP-IP vs. XNS? I also know very little about TCP-IP and would like to know more. Can anyone send me a brief comparison between the two. Oh, I almost forgot what are the disadvantages of TCP-IP vs. XNS. Any help that can be given would be gratefully appreciated..... Brian Shapiro Ohio University Computing and Learning Services Haning Hall Athens, Ohio 45701 (614) 593-1608
LYNCH@A.ISI.EDU.UUCP (02/03/87)
Brian, In a nutshell: TCP/IP and XNS are very similar in the kinds of low level services they offer (like connecting terminals to hosts). In the higher level services (like file transfer and email) they differ only in the aspect of how many different host types does your situation need to communicate with. TCP/IP has implementations on essentially every host in existence. XNS is much more limited in that respect. In your situation going with TCP/IP can only open up your choices. Bridge is offering you equivalent initial functionality with a "bridge" to further functionality (by moving to TCP/IP). You say that you will be connecting to a supercomputer center soon. It will undoubtedly be TCP/IP based. And gaining access to BITNET (meanwhile) is very close to working in TCP/IP land as their mail protocols are very close to TCP/IP's and getting closer. I'll send you some more materials in the US Snail, includi9ng a reading list. Dan -------
scarter@CAIP.RUTGERS.EDU.UUCP (02/04/87)
Path: caip!scarter From: scarter@caip.RUTGERS.EDU (Stephen M. Carter) Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for Tcp/Ip for Prime's PRIMOS system Message-ID: <4060@caip.RUTGERS.EDU> Date: 4 Feb 87 06:55:57 GMT References: <8702030109.AA11365@ucbvax.Berkeley.EDU> Reply-To: scarter@caip.UUCP (Stephen M. Carter) Organization: Rutgers Univ., New Brunswick, N.J. Lines: 21 In article <8702030109.AA11365@ucbvax.Berkeley.EDU> Henry Nussbacher <Hank@Barilvm> writes: >I have seen that Prime has a Tcp/Ip version. I am interested in hearing >any user experience with this package - costs, benefits, pros, cons, etc. > >Please reply directly to me since I am not on this list. ...Also add to this question the status of hardware the tcp uses. When I first asked Prime these questions, they said that tcp only interfaced to their X.25 hardware. Plans for an Ethernet board have not been considered (they were thinking about OEM'ing Bridge's X.25/Ethernet gateway as this interface). Granted this was almost two years ago, anyone know the latest? -SCarter uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!scarter arpa: SCARTER@RUTGERS or SCARTER@RED.RUTGERS.EDU
richb.UUCP@seismo.css.gov@dartvax.UUCP (02/09/87)
Path: dartvax!richb From: richb@dartvax.UUCP (Richard E. Brown) Newsgroups: mod.protocols.tcp-ip Subject: Re: network password protection/TCP spec Message-ID: <5665@dartvax.UUCP> Date: 9 Feb 87 17:05:24 GMT Reply-To: richb@dartvax.UUCP (Richard E. Brown) Organization: Dartmouth College, Hanover, NH Lines: 30 References: A while back, there was a discussion of protecting passwords, which lead to a discussion of taking over someone's TCP connection. One person noted that if a spoofer simply startd sending in-sequence messages, they could take over the session and the victim would be relatively helpless. Another person responded that he thought TCP specified that an ACK with a sequence number that was too high would result in a RST to clean out the connection. (Further discussion revealed that TCP does *not* specify this -- in fact, it allows the session to continue.) My question: Is this behavior (sending RST if the ACKs get too high) desirable? Are there any pitfalls to doing this? Here at Dartmouth, we have developed a stream protocol which runs over AppleTalk. It is in use throughout the campus with our Macintosh terminal emulator, and several commercial vendors are also implementing this protocol. If it is useful, a stroke of a pen will implement it (well, you know what I mean). Thanks. Rich Brown Dartmouth College Kiewit Computer Center Hanover, NH 03755 603/646-3648 richb@dartmouth.edu richb@dartmth.bitnet richb@dartvax.UUCP A0183 on AppleLink
steve@BRL.ARPA.UUCP (02/11/87)
Brian -
If you run the TCP/IP protocols, you can connect your
campus to the nationwide NSFNET and gain access to lots of other
supercomputers besides your own, a transparent interconnection to
the ARPANET (and CSNET too, for that matter), and all the other
interesting things that go with Internet membership.
It's even possible to apply for an NSF grant to connect
up. If you're interested, drop me a note with your Snail Mail
address and ask for the "Connections Program Announcement".
-snews@seismo.CSS.GOV@sun.UUCP (02/15/87)
Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet 8th bit: a good use for that bit... Message-ID: <13334@sun.uucp> Date: 15 Feb 87 06:17:35 GMT References: <969432.870211.JBVB@MX.LCS.MIT.EDU> <8702140255.AA14335@hoptoad.uucp> Sender: news@sun.uucp Reply-To: guy@sun.UUCP (Guy Harris) Organization: Sun Microsystems, Mountain View Lines: 11 >I think that it would be good to specify that 8-bit values passed >on Telnet connections are in ISO Latin I (essentially, extend NETASCII >to 8 bits using the ISO character set that contains all the graphics >for all the Latin languages). That would leave all the non-Latin languages, like Japanese, Chinese, Korean, etc., out in the cold. It would be a mistake to require that 8-bit values (i.e, GR characters, with the 8th bit set) passed over TELNET connections be in one particular character set. If need be, there could be TELNET options to indicate which character set is being sent over the wire.
MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP (02/15/87)
I don't know what is done with Chinese or Korean, but Japanese
uses a 14-bit character set, using only the values 21h-7Eh (that's
041 to 176 for us octal fans); that is, those values in 7-bit ASCII
that represent printing characters. An ESCAPE sequence shifts between
ASCII and JIS (Japanese Industrial Standard).
An alternate means supports katakana only, using either the
eighth bit or ASCII shift codes (SO/SI, a.k.a. CTRL/N and CTRL/O).
Some terminals support both systems; however, the katakana-only
system is obsolete today.
One must recognize that 8 bits are never enough! It is perfectly
alright to assign an 8-bit system for your local use, but it is pure
egotism to believe that your 8-bit system is somehow superior to
anyone else's and therefore should be adopted as a standard. Really,
the eighth bit is best left for parity or undefined for a local
application. To represent international characters, you need a
larger character set.
If a vote were taken today, I would vote for JIS. I believe that
as long as your terminal supports overstriking you can get all the
silly ISO characters using JIS. In addition, you also get Greek and
Russian. I'm not sure about Chinese, but JIS includes several thousand
Chinese characters (kanji), most of which aren't generally used in
Japanese.
-------kik@CERNVAX.BITNET.UUCP (02/17/87)
Path: cernvax!kik
From: kik@cernvax.UUCP (kik)
Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans
Subject: IEEE/Blue Book problem and MAC-level bridges
Message-ID: <439@cernvax.UUCP>
Date: 17 Feb 87 08:07:52 GMT
References: <12277078297.16.ROMKEY@XX.LCS.MIT.EDU>
Reply-To: kik@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw
Lines: 33
The discussion on MAC-level bridging seems to have concentrated so far
on the difference between the Ethernet 2.0 and IEEE 802.3 formats (i.e.
Type/length field). What seems considerably more worrying is the problem
raised by the IBM insistence for the acceptance by the standardisation
bodies of their "source-level routing" for Token Ring (TR).
For those of you in the happy state of ignorance about this approach, it
works as follows: for an unknown MAC-level address, an enquiry frame is
broadcast through all TR-bridges, which add their own address to the
recorded route. The bridge on the ring that carries the desired address
returns the enquiry (with the recorded route) to the enquirer. All
subsequent frames to this address then carry this routing (ISO level 3!!)
information directly after the destination and source address fields (i.e.
before the LLC). In addition, to indicate that source routing is in
action, the source address has the "casting" bit (least significant of most
significant byte) set.
One can imagine the excitement that this sort of frame will cause if
it appears via a (normal) bridge on an Ethernet segment. Even if the IBM
pollution is purged by an intelligent bridge, the reverse path for the
response is somewhat problematical, and would entail maintaining a "TR
routing table" in the bridge.
It is clear that the IBM approach is (to say the least) not optimised
for a connectionless environment. What is not clear, however, is whether
it has *any* advantages over a true MAC-level bridge.
I would be grateful for clarification from people who understand both
approaches more cpmpletely than I.
Crispin (KIK) Piney
CERN, Geneva, Switzerlandmark@MIMSY.UMD.EDU.UUCP (02/20/87)
Path: mimsy!mark From: mark@mimsy.UUCP (Mark Weiser) Newsgroups: mod.protocols.tcp-ip Subject: Re: nice book on TCP/IP ?? Message-ID: <5532@mimsy.UUCP> Date: 20 Feb 87 19:37:10 GMT References: <8702191826.AA14972@bu-cs.bu.edu> Reply-To: mark@mimsy.UUCP (Mark Weiser) Organization: PRISM Group, University of Maryland, College Park, MD 20742 Lines: 15 In article <8702191826.AA14972@bu-cs.bu.edu> bzs@BU-CS.BU.EDU (Barry Shein) writes: > >Yes, get Doug Comer's new book Volume II of his "The Design of the >XINU Operating System, an Internetworking Approch" (I think I got that >right, don't have it right here.) > This is a good book, but it has nearly zero about TCP (or SMTP or other higher protocols) in it. Lots of IP, and lots of network applications and low-level network support built from scratch and justified. And lots of UDP, I think. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
news@decwrl.DEC.COM@dopey.AMD.COM (02/23/87)
Path: dopey!amdcad!cae780!hplabs!sdcrdcf!trwrb!ucla-an!stan
From: stan@ucla-an.UUCP (Stan Stead M.D.)
Newsgroups: comp.dcom.lans,mod.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc,comp.unix.wizards,comp.unix.xenix
Subject: Wanted: Xenix driver for PC Network/Token Ring
Keywords: network token-ring xenix source driver
Message-ID: <3@ucla-an.UUCP>
Date: 23 Feb 87 05:49:15 GMT
Distribution: usa
Organization: Dept. Anesthesia, Sch. of Med., UCLA, Los Angeles
Lines: 19
We are interested in using the Token Ring or PC Network as a DDN interface
into our local ethernet, to ARPA and beyond. While it doesn't look that
difficult (it never does) we are reluctant to re-invent the wheel.
What we really need is source code for a PC Network or Token Ring driver.
Has anyone developed a Xenix driver for either the PC Network boards or
Token Ring? I have heard that SCO has such a driver, but I do not know
of anyone using it.
Thanks in advance.
Stanley W. Stead
UCLA School of Medicine / Dept of Anesthesiology
BELL: (213) 206-6238
ARPA: ucla-an!stan@ee.UCLA.EDU
UUCP: {trwrb|ucla-cs|cepu}\
!ucla-an!stan
UUCP: {ihnp4|decvax}!hermix/larry@pdn.UUCP.UUCP (02/25/87)
Path: pdn!larry From: larry@pdn.UUCP (Larry Swift) Newsgroups: mod.protocols.tcp-ip Subject: Re: Vertically Moving Congestion (VMC) Message-ID: <651@pdn.UUCP> Date: 25 Feb 87 13:14:59 GMT References: <8702200048.AA02250@ucbvax.Berkeley.EDU> Reply-To: larry@pdn.UUCP (0000-Larry Swift) Organization: Paradyne Corporation, Largo, Florida Lines: 17 In article <8702200048.AA02250@ucbvax.Berkeley.EDU> JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes: >Vary often you end up solving the problem at the layer you >wanted only to find that a new layer has become congested. > That's why the OSI Reference Model has some form of flow control in *all* layers one thru five. The Session Layer (layer 5) is where the data path is finally narrowed to a single user, and therefore s/his ability to consume network resources can be limited there. There are many good reference works on the OSI Model. -------------------------------- Larry Swift UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541 Phone: (813) 530-8605
brian@sdcsvax.ucsd.edu.UUCP (02/27/87)
Path: sdcsvax!brian
From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: duplicate message in SMTP ("sndmsg balks, try again later")
Message-ID: <2766@sdcsvax.UCSD.EDU>
Date: 26 Feb 87 23:20:09 GMT
References: <8702241936.AA19824@ucbarpa.Berkeley.EDU>
Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Distribution: world
Organization: UCSD wombat breeding society
Lines: 71
This is a message I sent a few weeks ago to someone locally who was
seeing this problem. Some of the information in here is therefore
UCSD-specific, but you'll get the idea....
-----
More than you ever wanted to know about VMS SMTP mail:
Brief description of problem: mail addressed to many recipients on a
VMS machine has been received as multiple duplicates by some of the
recipients.
What's going on: When mail is sent over an SMTP connection such as is
used on the ethernet, a RCPT TO:<address> line is sent for each
individual recipient to be delivered to on that connection (i.e., on
that host). The receiving mailer (in this case, the Wollongong VMS
mail package) is responsible for validating and delivering the mail to
those recipients.
It has been previously noticed that one somewhat common VMS practice
can cause difficulties with mail: that of removing the home directory
of a user who is still in the VMS User Authorisation File. (Apparently
this prevents logins whilst still maintaining accounting information in
the UAF. Or something; I'm not a VMS guru by a long shot.) The
Wollongong mail system apparently checks the validity of a mail
delivery address (the RCPT TO:<mailbox> line) during the SMTP
transaction by checking the UAF. If a user is still in that file, it
OK's the destination mailbox and continues. If the user is NOT in the
UAF, a reject message is instead returned, and the mail will be
returned to the sender as having one or more "recipient unknown"
problems.
After the list of recipients is negotiated, the mail message itself is
sent. At the end of this DATA portion of the SMTP connection, the
Wollongong VMS software invokes the VMS mailer to deliver the actual
mail. The SMTP connection is still open to the originating mailer (in
this case, sdcsvax's sendmail daemon), and will remain that way until
OK and QUIT transactions take place. Ordinarily, the Wollongong
software delivers the mail to the user's mailbox file, and returns an
OK to the sender, who in turn QUITS the connection, and all is well.
However, if the recipients's home directory on the VMS system is
missing, the delivery fails, and an error code is returned. Sendmail
then assumes that the mail wasn't delivered, since it never got the OK,
and requeues the message for delivery on the next queue run (about 20
minutes later under our circumstances), and the whole process repeats
until either the mail is successfully delivered to all validated
recipients, or until the message times out after 3 days (or someone
goes in and snuffs it).
Where this is a real pain is when you have a long list of recipients
and somewhere in the middle of it (or worse, near the end!) there is
one whose mailbox isn't available for delivery - if, for instance, his
home directory is missing. Then what happens is that all the
recipients PREVIOUS to him have gotten the mail message delivered to
them, but sendmail gets an error back from the Wollongong VMS mailer,
and requeues the message to ALL the recipients again, so they'll get
another copy 20 minutes later.
There isn't any cure for this, except for Wollongong to make their
software smarter. There's no provision in the SMTP specification to
allow the mail transport mechanism to accept a recipient in the earlier
part of the transaction, and later selectively reject it. Obviously
one should not send messages to people who aren't there anymore, but
sometimes it is difficult to tell which are valid addresses when doing
massive bulk mailings. Neither is it particularly intelligent to
return an error message to sendmail that applies to only one recipient
when the message isn't totally lost. I guess sendmail is at fault here
too. Maybe its the SMTP specification that's losing.
Brian Kantor UCSD Office of Academic Computing
Academic Network Operations Group UCSD B-028,
La Jolla, CA 92093 USArandy@june.cs.washington.edu@bcsaic.UUCP (02/27/87)
Path: bcsaic!randy From: randy@bcsaic.UUCP (Randy Groves) Newsgroups: comp.sys.ibm.pc,mod.protocols.tcp-ip,mod.computers.ibm-pc Subject: TCP-IP implementations for the PC anyone?? Keywords: tcp-ip pc Message-ID: <461@bcsaic.UUCP> Date: 27 Feb 87 18:52:16 GMT Organization: Boeing Computer Services ATC, Seattle Lines: 17 We have a requirement for network connections between IBM PC's and various mainframe/workstations, all of which speak either TCP or DECnet. I need to find out what is available - either commercial or PD in either realm. So if you know of or use a TCP or DECnet implementation on PC's - using Ethernet or some other medium, please let me know by email. I need basic file transfer at the minimum, some sort of ipc or telnet capability would be nice if available. Thanks much. -randy groves Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-44 VOICE: (206)865-3212 Seattle, WA 98124
dorl@seismo.CSS.GOV@uwmacc.UUCP (03/01/87)
Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.sys.dec,comp.mail.misc Subject: VMS Mail Systems Message-ID: <1163@uwmacc.UUCP> Date: 1 Mar 87 16:41:41 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 10 We run a Vax VMS system with connections to the IP Internet (The Wollongong Groups WIN/VX), BITNET (Joiners JNET and GMAIL), and DECNet. Both the IP and BITNET systems are accessable from DEC's MAIL utility but the user interface is poor. We are looking for something that presents a better more fully coordinated interface to these nets. If you have or know of such products, please mail to.... dorl@unix.macc.wisc.edu dorl@wiscmacc.bitnet
jh@seismo.CSS.GOV@tut.fi (03/02/87)
Path: tut!jh
From: jh@tut.UUCP (Juha Hein{nen)
Newsgroups: mod.protocols.tcp-ip
Subject: How to have two networks in a single Ethernet?
Message-ID: <646@sotka.tut.UUCP>
Date: 2 Mar 87 16:12:44 GMT
Reply-To: jh@tut.UUCP ()
Distribution: world
Organization: Tampere University of Technology, Finland
Lines: 15
We have just got Bridge GS-3M boxes with Vitalink software that
connect protocol independently four separate Ethernets. The separate
Ethernets each have their own Class C Internet numbers. Our problem
is, how to configure the 4.2bsd machines (Suns and Vaxen) in each of
the separate networks so that they could talk to each other.
We have tried to add new entries in /etc/hosts and add new arp info
but when trying to connect a machine in another network, we get back
an error message "Network is unreachable". It looks like we should be
able to generate one of our machines as a gateway machine with only
one Ethernet controller. Any help is appreciated.
--
Juha Heinanen
Tampere Univ. of Technology
Finlandben@CERNVAX.BITNET.UUCP (03/02/87)
Path: cernvax!ben From: ben@cernvax.UUCP (ben) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP for OS-9 Anywhere? Keywords: TCP/IP OS-9 NFS Message-ID: <445@cernvax.UUCP> Date: 2 Mar 87 16:16:25 GMT Reply-To: ben@cernvax.UUCP (via mcvax) Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 5 We are looking for possible TCP/IP implementations for 68K systems running the Microware OS-9 operating system. We are interested both in the case where all of the protocols and utilities run on the 68K, or where an intelligent board is used, e.g. Excelan, CMC, etc. (for VME-based systems). A big bonus would be the additional availability of (at least client) NFS.
nobody@COLUMBIA.EDU.UUCP (03/02/87)
Path: columbia!cunixc!cck From: cck@cunixc (Charlie C. Kim) Newsgroups: mod.protocols.tcp-ip Subject: Re: Ultrix TCP/IP Message-ID: <4410@columbia.UUCP> Date: 2 Mar 87 20:43:10 GMT References: <8703021756.AA15720@ucbvax.Berkeley.EDU> Sender: nobody@columbia.UUCP Reply-To: cck@cunixc.UUCP (Charlie C. Kim) Distribution: world Organization: Columbia University Center for Computing Activities Lines: 45 In article <8703021756.AA15720@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: >The following is a trace (excelan monitor) of a PC communicating to a GPX >micro-vax running ULTRIX. The ethernet is < 1% loaded, the GPX has no other >... > >QUESTION: > Why does Ultrix wait about 5 seconds after the PC ACK's to send it's >next packet? Remember there are no gateways and almost noload on the >network or GPX. > I'm not sure what software you're running on your pc or what version of ultrix you are running, but both BSD 4.3 and Ultrix 1.2 delays sends by the TCP 'PERSIST' timeout if the window is too "small" (e.g. segment to be sent is "larger" than remotely advertised window). This might have been the case in Ultrix 1.1 and is probably the case in Ultrix 2.0. The PERSIST timeout is around 5 seconds. The tcp segments resulting from the cat output are probably pretty large, so in the following you can see that the delay happens when the window advertised by the PC TCP/IP is quite small - probably quite a bit smaller than the segment that the Unix TCP wants to send. >2 : CFB/OUT >ether: IP 02-60-8c-10-46-46 -> aa-00-04-00-07-04 64 6.981 6.981 > ip: TCP 01.004646 -> 01.00001f > tcp: 7464 -> TELNET ACK > tcp: seq: 40 ack: 64807459 win: 82 len: 0 > >3 : CFB/IN >ether: IP aa-00-04-00-07-04 -> 02-60-8c-10-46-46 140 4998.996 ***.*** > ip: TCP 01.00001f -> 01.004646 > tcp: TELNET -> 7464 ACK > tcp: seq: 64807459 ack: 40 win: 4096 len: 82 > 0: 61 79 20 3d 20 58 4f 70 65 6e 44 69 73 70 6c 61 |ay = XOpenDispla| >... Enough of the analysis, what you probably want is a workaround which I can offer for the MIT version of PC/IP: simply set the telnet low window close to the telnet window using custom and you'll find things a lot more zippy. (This I discovered by experimentation much before I tried to figure out what was really happening). Charlie C. Kim User Services Columbia University
hedrick@seismo.CSS.GOV@topaz.rutgers.edu (03/03/87)
Let us suppose that you have the following configuration: --------- network 192.1.1 | router, with addresses 192.1.1.1 and 192.1.2.2 | --------- network 192.1.2 | router, with addresses 192.1.2.1 and 192.1.3.1 | --------- network 192.1.3 Now suppose you have a 4.2 machine on network 192.1.2, whose own address is 192.1.2.10. Here is the way I would set up routing. /usr/etc/route add 192.1.1 192.1.2.2 1 /usr/etc/route add 192.1.3 192.1.2.1 1 That is, you tell route the address of the router that is used to get to each other the other networks. The address you give must be the address of the router's interface on your own network. With this approach, you need one route command for each network other than the one your machine is on. If the router has the ability to issue ICMP redirects, you can do things with a single entry: /usr/etc/route add 0 192.1.2.1 1 A network number of 0 specifies this as a default route. That means that any address not on the local network is sent to 192.1.2.1. If that machine is not the right one, it should issue a redirect command that will cause your machine to add a proper routing entry automatically. I don't know whether the Bridge products issue ICMP redirects or not.
whna@cgcha.UUCP (Heinz Naef) (03/17/87)
Path: cgcha!whna From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: TCP/IP software for HyperChannel II (HyperBus) on IBM mainframes Keywords: TCP/IP, Hyperchannel, Hyperbus, IBM Message-ID: <314@cgcha.UUCP> Date: 17 Mar 87 17:42:23 GMT Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, CH-4002 Basel, Switzerland Lines: 10 Does anyone know about a TCP/IP protocol package and the appropriate driver for IBM 30xx mainframes to interface to Network Systems Corp.'s HyperChannel II controller/media without using NETEX? As far as we know, this type of attachment exists for Cray's UNICOS operating system and for VME-Bus based systems using the IKON board set. Any hints - via e-mail whna@cgcha.UUCP - will be highly appreciated. Thanks, Heinz.
dorl@uwmacc.UUCP.UUCP (03/24/87)
Path: uwmacc!dorl From: dorl@uwmacc.UUCP (Michael Dorl) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: Bruknet Protocols Message-ID: <1282@uwmacc.UUCP> Date: 24 Mar 87 14:34:56 GMT Organization: UWisconsin-Madison Academic Comp Center Lines: 14 I have a Ethernet supporting both the TCP/IP and DECNet protocols. A user in Biochemistry wishes to attach some German machinery using something called Bruknet to this network. The manual seems to indicate that it coexists with DECNet. It appears to use Ethernet type 10-10 or 4112 (base 10). This type number does not conflict with IP but its not listed in the Assigned Numbers section of the DDN Protocol Handbook. Has anyone used this product? Is it known to coexist with both DECNet and TCP/IP? Michael Dorl dorl@unix.macc.wisc.edu dorl@wiscmacc.bitnet
solomon@CRYS.WISC.EDU.UUCP (03/26/87)
Path: crystal!solomon From: solomon@crys.WISC.EDU (Marvin Solomon) Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Summary: There's more to data communication than bits/second. Message-ID: <291@crys.WISC.EDU> Date: 26 Mar 87 17:19:24 GMT References: <VAX-MM(195)+TOPSLIB(124).25-Mar-87.20:55:50.VAX.DARPA.MIL> Organization: U of Wisconsin CS Dept Lines: 31 Vint Cerf has pointed out one pitfall in trying to use a single number to compare very different technologies: One must consider not only bandwidth, but also latency. But all the discussion on this topic so far has failed to note that the information-carrying capacity of a station wagon full of tapes (or a knapsack full of CS's, or whatever) and a 56Kbps leased line have different dimensions! Vint's "Johnny Appleseed" has units capacity*velocity = bits*length/time, whereas a communications line is measured in bits/time. Thus, to compare the two, one has to mention the distance. The problem we are considering was posed by Jon Bentley in his delightful Programming Pearls column, "The Back of the Envelope" in the March 1984 issue of "Communications of the ACM": At what distances can a courier on a bicycle with a reel of magnetic tape be a more rapid carrier of information than a 56-kilobaud [sic] telephone line? Than a 1200-baud line? [op cit, p. 182] The answers (based on considerably more realistic estimates about magnetic tape than have been bandied about in this forum, by the way) are, respectively, 20 miles and the distance the cyclist can travel in a week. The point is that a communication line can beat ANY bulk transfer over sufficiently long distances. Of course, we can effectively cut off discussion at (say) the diameter of the earth. To summarize: The advantages of networking are both low latency and distance-independence. -- Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@gjetost.wisc.edu or seismo!uwvax!solomon
usenet@JADE.BERKELEY.EDU.UUCP (04/02/87)
Path: jade!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: mod.protocols.tcp-ip
Subject: jkh annoys the net
Message-ID: <3011@jade.BERKELEY.EDU>
Date: 2 Apr 87 18:48:50 GMT
Sender: usenet@jade.BERKELEY.EDU
Reply-To: jkh@violet.berkeley.edu(Jordan K. Hubbard)
Organization: University of California, Berkeley
Lines: 95
By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)
So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"
I will attempt to explain.
I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:
...
Any of three fields can be empty, in which case it signifies
a wild card. Thus
universal (,,)
defines a group to which everyone belongs. Field names that ...
...
Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.
Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.
Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?
All of this has raised some interesting points and problems.
1. Rwall will walk through your entire hosts file and blare at anyone
and everyone if you use the (,,) wildcard group. Whether this is a bug
or a feature, I don't know.
2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
who you are as long as you're root (which is trivial to be, on a work-
station), I have to wonder what other RPC services are open holes. We've
managed to do some interesting, unauthorized, things with the YP service
here at Berkeley, I wonder what the implications of this are.
3. Having a group called "broadcast" in your netgroup file (which is how
it comes from sun) is just begging for some novice admin (or operator
with root) to use it in the mistaken belief that he/she is getting to
all the users. I am really surprised (as are many others) that this has
taken this long to happen.
4. Killing rwall is not going to solve the problem. Any fool can write
rwall, and just about any fool can get root priviledge on a Sun workstation.
It seems that the place to fix the problem is on the receiving ends. The
only other alternative would be to tighten up all the IMP gateways to
forward packets only from "trusted" hosts. I don't like that at all,
from a standpoint of reduced convenience and productivity. Also, since
many places are adding hosts at a phenominal rate (ourselves especially),
it would be hard to keep such a database up to date. Many perfectly well-
behaved people would suffer for the potential sins of a few.
I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!
Jordan Hubbard
jkh@violet.berkeley.edu
(ucbvax!jkh)
Computer Facilities & Communications.
U.C. Berkeleygordan@maccs.UUCP.UUCP (04/04/87)
Path: maccs!gordan
From: gordan@maccs.UUCP (Gordan Palameta)
Newsgroups: mod.protocols.tcp-ip
Subject: TCP retransmission
Keywords: retransmission algorithm
Message-ID: <519@maccs.UUCP>
Date: 4 Apr 87 03:48:50 GMT
Reply-To: gordan@maccs.UUCP (Gordan Palameta)
Distribution: world
Organization: DCSS, McMaster University, Hamilton, Ontario, Canada
Lines: 20
Hello...
I'm currently writing some TCP-IP code (for a PDP-11 running RT-11), and am
looking to do retransmissions correctly.
From what I've read here, poor retransmission behavior is a major source
of congestion... although my code is intended for a very lightly loaded
Ethernet and I can get away with being sloppy, if there's a painless way to
do it right for the general case, it would be nice to put it in.
I understand the idea of exponential backoff, and know of the RTT-based
algorithm suggested in the RFC (which I believe is what BSD 4.2 uses (?))...
is this the proper algorithm to use, or is there a better one?
Thanks for any info...
--
UUCP: ... !seismo!mnetor!lsuc!maccs!gordan (note ..dAn or mail may bounce)
BITNET: GP@TANDEM ^ <---'
Gordan Palametamhsc@oce.nl.UUCP (04/08/87)
Path: oce!mhsc From: mhsc@oce.nl (Maarten Schoonwater) Newsgroups: mod.protocols.tcp-ip,comp.sys.m68k,mod.computers.68k Subject: TCP-IP for 68000 VERSAdos system Message-ID: <29@oce-rd2.oce.nl> Date: 8 Apr 87 10:02:23 GMT Reply-To: mhsc@oce-rd2.UUCP (Maarten Schoonwater) Organization: Oce-Nederland bv, Venlo, the Netherlands Lines: 10 We have several 68000 based systems that we need to interface with an Ethernet using TCP-IP protocols. The systems run under the Motorola VERSAdos operating system on a VME-bus. Till now we only found Unix based TCP-IP implementations. Support for ftp and perhaps telnet would be sufficient. Does anyone know of possible solutions?? Maarten Schoonwater Usenet: mhsc@oce.nl Oce-Nederland B.V. mail : P.O. 101 5900MA Venlo R&D department The Netherlands
haque@umn-cs.UUCP.UUCP (04/11/87)
Path: umn-cs!haque From: haque@umn-cs.UUCP (Samudra E. Haque) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP on an HP 3000 Keywords: TCP HP3000 HP9000 Message-ID: <1476@umn-cs.UUCP> Date: 11 Apr 87 04:52:09 GMT Article-I.D.: umn-cs.1476 Posted: Fri Apr 10 22:52:09 1987 References: <5985@dartvax.UUCP> Organization: CSci Systems Group,University of Minnesota,Mpls. Lines: 24 In article <5985@dartvax.UUCP>, richb.UUCP@dartvax.UUCP (Richard E. Brown) writes: > > I wasn't paying much attention a couple of months ago, but I seem > to remember that someone said that there was an implementation of > TCP on HP3000 computers. > Speaking of HP's.. We have HP 9000/200 and /300 machines. While the /300 have full networking (psuedo BSD), the /200 machines do not have any networking hardware available for them. (according to our HP rep) We are running HP/UX on them. Am I wrong in assuming that there really is no future for networking the /200 machines or that they might become very expensive to have networking on ? Samudra E. Haque Computer Science Systems Group University of Minnesota Minneapolis, MN 55455 haque@umn-cs.arpa or ..!dayton!umn-cs!haque or (612) 625-0876
tai%hpltyj@HPLABS.HP.COM.UUCP (04/12/87)
|Speaking of HP's.. | |We have HP 9000/200 and /300 machines. While the /300 have full |networking (psuedo BSD), the /200 machines do not have any networking |hardware available for them. (according to our HP rep) We are running |HP/UX on them. | |Am I wrong in assuming that there really is no future for networking |the /200 machines or that they might become very expensive to have |networking on ? | | Samudra E. Haque The 9000/200 is virtually identical to the 9000/300 series. That is, they can run the same software (kernel is different though) and use the same networking hardware. However, the 200 is no longer supported; the 5.17 release of HP-UX is the last release which works for the 200 series. On the other hand, I've built a 5.17 kernel with the latest networking code (5.3) for use with the 200 series. ..tai
daemon@DECWRL.DEC.COM.UUCP (04/13/87)
Path: decwrl!tpov02.dec.com!mobbylin
From: mobbylin@tpov02.dec.com (Mobby Lin, Taiwan Software Services)
Newsgroups: mod.protocols.tcp-ip
Subject: What's vendor support TCP-IP
Message-ID: <9269@decwrl.DEC.COM>
Date: 13 Apr 87 06:29:50 GMT
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 16
hi everyone,
I am more interested in TCP/IP. Does someone know what's third party software
and its hardware can support the tcp/ip and what's model and how to contact
those products can ported into Wang, Tandem, IBM and NEC.
Now I am planning to connect VAX to Wang, Tandem, IBM and NEC, based on X25
on layer 1, 2, 3 and layer 4,5 used on tcp/ip.
my address at
mobbylin%22599.dec.com@decwrl.arpa
Software Services, Taiwan Digital Equipment.
regards,
Mobby Lin