iBet uBet web content aggregator. Adding the entire web to your favor.
Link to original content: https://web.archive.org/web/20171208231416/http://securitydigest.org/tcp-ip/archive/1989/02
|
|
ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for February 1989 (348 messages, 167074 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/02.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 00:12:29 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: FTP et al
Agreed; there is no way to transfer an arbitrary "Vendor" file which has attributes stuffed in other parts of the file system (like UNIX inodes) with the current FTP standard with out falling back on an administrative hack using pre and post-processor's. Would it be useful to consider a new standard which would allow for a eXternal File Representation XFR "on-the-wire"? We have a Central File Store (CFS) at LANL which allows for "user maintained" control information (file attributes). This is not XFR by any means, but it allows VMS, CTSS, etc. systems to save files on CFS and get them back with the correct attributes. However, the file is not transportable between different operating systems. An XFR would allow for this. A "standard" representation of a text file has been defined. A user can pre-process the file and store it on CFS in "stext" (standard text) format. However, it is up to the user of the file, after he gets it, to "ntext" (native text) it. I'm not suggesting this as a mechanism! Just throwing out some ideas. Phil
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 00:47:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Loose and Strict source routing
Phil, Unless I'm badly mistaken, there isn't any guarantee that a non-source-routed internet packet has a valid source address. Of course, responses to such a spoofed packet may not make it back to the origin unless a cooperating gateway helps out, or the source is on an Ethernet and is operating in promiscuous mode. I suggest that, if source authentication is an issue, you will need stronger tools/mechanisms than avoiding the use of source routing of either type. The general problem of authentication in the Internet is very important, applies to many areas including, for example, various control methods (e.g. network management subsystems) and will probably require some form of cryptographic protection to solve. The cryptography need not be used to conceal information - merely to provide an unforgeable authentication of the source. Vint Cerf
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 01:43:52 GMT From: mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: first release of IMAP software
The IMAP software is now ready for distribution from SUMEX-AIM.STANFORD.EDU (internet address [36.44.0.6]). The IMAP distribution is available by anonymous FTP from SUMEX as imap/imap.tar.Z . So, the following commands on your favorite Unix should snarf things: % ftp sumex-aim.stanford.edu Name: anonymous Password: foo ftp> binary ftp> cd imap ftp> get imap.tar.Z ftp> quit % uncompress imap.tar.Z % tar -xf imap.tar You should take a look at imap/README before doing anything. If you connect to imap and do a "make" it should build all the software. The two most important binaries built by "make" will be imap/clients/ms/ms and imap/servers/imapd/imapd. Please report any problems to Mark Crispin at mrc@Blake.ACS.Washington.EDU and to Bill Yeager at yeager@SUMEX-AIM.STANFORD.EDU. -------
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 09:47:02 PST From: adelman@TGV.COM (Kenneth Adelman) To: jam@radc-lonex.Arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP "STRU VMS" extension
> [ text deleted ]
[ text deleted ]
> The deleted text is not pertinent to what I want to say.
> I don't want to swing towards either side of the fence
> here. I do raise my eyebrow, ie: Spock ;-), when there is
> a discussion going on about adding "machine specific"
> things to INTERNET protocols. For so long so many have
> worked so hard to keep things "machine independent".
> We do tend, yes even us in the UNIX community ;-), to
> forget that we aren't designing things for just our operating
> system. I'm not really sure what all is involved in "STRU-VMS",
> but I am wondering if the idea is generic enough that more
> than one system could be involved?
Nope. STRU VMS is designed for one operating system. There is no
way to do it in a transportable way without sacrificing speed, and
there is a need for high-speed transparent VMS-to-VMS transfers. Unix
people might have trouble understanding this problem because the Unix
concept of a file exactly matches the FTP concept of a file and you
can use TYPE I to do high-speed transfers.
>> I'm not sure this is appropriate to involve the entire TCP-IP list
> >in this discussion. Anyone interested receiving copies of future
> >correspondance, please send mail to stru-vms-request@tgv.com.
> Why not? This is exactly what this forum is for! We
> are concerned with what is going on in tcp/ip land ;-).
> I don't see why discussions of pertenint items should
> start splitting off to new places.
Because I won't want to discuss the merits or disadvantages of
such a protocol. I believe I can get enough VMS TCP vendors to come to
a consensus, and I do not believe that the TCP-IP list is a good place
to discuss the particulars of the protocol extension (i.e. the
encoding of VMS file attributes on the wire).
Ken
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 01:55:12 GMT From: mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
Once upon a time, there was an operating system called Tenex (and its greater child, TOPS-20) which lots of sites ran. In fact, it was the Standard ARPANET Operating System. To accomodate its internal format of files, STRU P was defined especially for that purpose. To this day, this is the format that TOPS-20 systems prefer to exchange files. I see nothing wrong with the STRU VMS proposal, although it would be nice if they could use the existing STRU P mechanism if at all possible. I'm a little surprised there isn't a STRU TAR for better Unix file transfers yet... -- Mark -- -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 02:53:14 GMT From: postel@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
Hey! What about the STRU PAGE suggestion copied below? Can someone explain why it is not an adaquate soultion to the problem? --jon. Date: 30 Jan 89 16:13:33 GMT From: sun.soe.clarkson.edu!abstine@tcgould.tn.cornell.edu (Arthur Stine) Subject: Re: FTP "STRU VMS" extension To: tcp-ip@sri-nic.arpa .... Dale Moore & Co at CMU have done this with CMU/TEK FTP. They use STRU PAGE to accomplish the same thing between two machines using CMU FTP. You might want to talk to him about it and find out the internals of it. (Dale.Moore@moore.fac.cs.cmu.edu) art stine sr network engineer clarkson u
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 04:05:20 GMT From: tonym@FLORA.WUSTL.EDU (Tony Mazraani) To: comp.protocols.tcp-ip Subject: TOS, priority
I was informed that there are people suggesting the use of TOS and some kind of a priority scheme to provide variable grade service with some statistical guarantee on top of datagram networks. Could you please let me know how I can have access to the work being done in this area. Also, are there any published papers yet? Thank you for your assistance. -Tony Mazraani
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 05:49:09 GMT From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan) To: comp.protocols.tcp-ip Subject: While we are debating extensions to the FTP spec...
While we are fighting about STRU VMS, I would like to propose another FTP extension (and this one I WOULD like to make interoperable with other vendor FTPs). We have implemented in our FTP for VMS a non-standard mode "LZ-COMPRESS" which places an adaptive L-Z data compression module between FTP (both client and server) and the network. Why do this you ask?? Well, there are some sites that are connected to the internet by VERY slow communication paths (my particular concern was a machine that had effectively a 4800 baud communication path). Now L-Z compression usually gets between 50% and 80% data compression (depending on the how structured the data is). So by turning on MODE LZ we typically see 8Kbaud to 32Kbaud transfer rates on this pitiful line (which actually makes the line quite usable). So, I am proposing a new transfer mode LZ in which the data on the data connection is in L-Z form. Now if you want to have a specific "MODE LZ" or want a sub-mode of the already specified FTP compress mode is fine with me -- but I WOULD very much like to be able take advantage of this most useful transfer mode when communicating with machines that don't have our software. David -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 13:02:58 MST From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: 4bsd-bugs@berkeley.edu Cc: tcp-ip@sri-nic.arpa Subject: IP Timestamp option structure needs work
Description:
If you pass an IP Timestamp with record route option through
a Sun mc68000 or sparc machine the route is not recorded.
Repeat-By:
Send an icmp echo with time stamp option and flag == 1 to
some thing that returns it (cisco router will do, or A.ISI.EDU)
Fix:
------- ip.h -------
*** /tmp/da0293 Wed Feb 1 12:55:19 1989
--- ip.h Wed Feb 1 12:46:18 1989
***************
*** 77,84 ****
--- 77,90 ----
u_char ipt_code; /* IPOPT_TS */
u_char ipt_len; /* size of structure (variable) */
u_char ipt_ptr; /* index of current entry */
+ #if defined(vax) || defined(i386)
u_char ipt_flg:4, /* flags, see below */
ipt_oflw:4; /* overflow counter */
+ #endif
+ #if defined(mc68000) || defined(sparc)
+ u_char ipt_oflw:4, /* overflow counter */
+ ipt_flg:4; /* flags, see below */
+ #endif
union {
n_long ipt_time[1];
struct ipt_ta {
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 11:22:03 EST From: jas@proteon.com (John A. Shriver) To: mrc@tomobiki-cho.cac.washington.edu Cc: TCP-IP@sri-nic.arpa Subject: first release of IMAP software
What's an IMAP? (It might help to put a copy of README outside the .Z file, since I don't want to get all that just to find out what it is.)
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 12:32:00 EST From: jam@radc-lonex.arpa To: adelman@tgv.com Cc: tcp-ip@sri-nic.arpa Subject: Re: FTP "STRU VMS" extension
>From: adelman@TGV.COM (Kenneth Adelman) >To: braden@venera.isi.Edu > > I was hoping that I wouldn't have to defend the need for a "STRU VMS" >but here goes... > >> The aproach you suggest works against interoperability and therefore must >> be approached with suspicion. If STRU VMS, then also STRU MVS? What if >> you want to FTP an ISAM file from a VMS to an MVS system? Is this >> infeasible? > > The idea is to provide a 'standard' way of transfering an arbitrary >VMS file UNINTERPRETED through the network. There are two reasons for this: > [ text deleted ] > 2) The need for such an extension to FTP is already recognized by > many VMS TCP vendors. What I want is a 'standard' which will > allow each of these different *VMS* FTP implementations to > speak the same language. [ text delete ] > This is *NOT* an attempt to solve a very difference problem such >as FTPing beasts like ISAM files between VMS and MVS. Even if FTP >contained a specification to allow any of today's VMS file types to be >FTPed, we're back in the same boat when DEC adds a NEW file type. > >> Rather than extend the STRU command of ftp to add "STRU VMS", how >> about doing it through the SITE command instead? From RFC959, pg 33: > > I'm aware of the SITE command, but my understanding was that >the SITE command was reserved for `non-standards', whereas this >proposal would only be useful as an extension to the protocol. As I >said above, I'm looking for more than just us to implement this. > > Perhaps what we need to add to FTP is a "STRU O VMS", where O is >short for operating system, and the resulting structure is the >VMS-specific one defined... The deleted text is not pertinent to what I want to say. I don't want to swing towards either side of the fence here. I do raise my eyebrow, ie: Spock ;-), when there is a discussion going on about adding "machine specific" things to INTERNET protocols. For so long so many have worked so hard to keep things "machine independent". We do tend, yes even us in the UNIX community ;-), to forget that we aren't designing things for just our operating system. I'm not really sure what all is involved in "STRU-VMS", but I am wondering if the idea is generic enough that more than one system could be involved? > I'm not sure this is appropriate to involve the entire TCP-IP list >in this discussion. Anyone interested receiving copies of future >correspondance, please send mail to stru-vms-request@tgv.com. Why not? This is exactly what this forum is for! We are concerned with what is going on in tcp/ip land ;-). I don't see why discussions of pertenint items should start splitting off to new places. Joel A. Mussman jam@radc-lonex.arpa, jam@etn-wlv.eaton.com
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 15:32:54 PST From: lm@Sun.COM (Larry McVoy) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
In article <8901312003.AA13471@hogg.cc.uoregon.edu> jqj@HOGG.CC.UOREGON.EDU writes: >One alternative to the STRU VMS suggestion is to bury a set of >permitted filters in the remote filename space supported by a >particular implementation, e.g. something suitably gross like: > FTP> bin > FTP> put "|encode foo.bar;3" "|decode foo.bar" Yuck. It's stuff like this that security holes are made of. What about FTP> put "|/bin/rm -rf /" You get the idea. And don't tell me that you would be very careful. The only way I'd believe it is if encode,decode,etc are all builtins. Any additions that require a popen() or a fork/exec are security problems and highly suspect. -- Larry McVoy, Lachman Associates. My opinions are that.
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 08:00:51 GMT From: adelman@TGV.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
> > ... (In UNIX terms, encoding == dump, decoding == restore).
>
> In theory, I agree with Phil. Any type of compression/encryption/encoding
> program that includes O/S-specific file information can have as its output a
> file. The contents of the file may be transferred via FTP to another machine
> which runs a program to reverse the algorithm to decompress/decrypt/format the
> result into a file.
> This approach treats FTP as a bulk-transport mechanism, NOT as an intelligent
> file-transfer mechanism that converts between file representations, but is
> handy for several applications, such as distributing software among like-minded
> O/S (the compressed .z files under UNIX come to mind.)
The problem is that the market recognizes a need to an intelligent
file-transfer mechanism which isn't any harder to use than FTP.
> The first purpose of the SITE VMS or STRU VMS command is to allow a
> pre-specified two-step process to be performed automatically within the FTP
> command to each file AS IT IS TRANSFERRED, where this process is so common that
> it might be applied to every file in a directory. This eliminates the two-step
> process, the problems of storing or naming an intermediate file, and the
> problems of applying this process in automated scripts or to entire directory
> trees.
Understand that 'building' the 'filter' program into FTP isn't enough.
We need a way of determining if the receiving FTP will decode the file before
we encode it. Yes, the "SITE" command could be used for this.
> Second, if you are implementing an O/S-specific command, I applaud the attempt
> to have it be the same across multiple TCP/IP implementations, to improve
> interoperability. Since you are trying to specify a useful VMS "protocol
> extension" as an ad-hoc standard, you might consider including not only the RMS
> headers, but flags to indicate compression and/or encryption that might be
> optionally implemented. Or a field to specify a procedure, command file, or
> program to be executed upon completion of each individual file transfer to
> perform these and/or other conversions.
Actualy ENCRYPTION and COMPRESSION should probably be a MODE command.
There is already defined a standard for run-length data compression
(MODE C) which the server on IU.AI.SRI.COM implements for those would
would like to test it against their implementations. Our FTP also has
the Unix 'comress' LZ-compression built in as a non-standard extension
called "MODE LZ" (try picking up a file in MODE LZ from IU.AI.SRI.COM
and uncompressing it on your Unix machine; actually, this will only work
in TYPE I, because otherwise the transfermation LF->CRLF->compressed(CFLF)->
network->decompress(CRLF)->CRLF->LF won't work).
Note MODE LZ does not conflict with STRU VMS, and they can be used together
to increase performance over most slower-than-ethernet speed lines.
No flames, I'm not arguing for a standard for this. But, we
implemented it because our customers asked for it.
Ken
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 18:10:00 PST From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: Re: FTP "STRU VMS" extension
Joel Mussman raises a very good point. Historically, open systems protocol standards, such as the TCP stack, are careful to be universal. To that end, standardizing the VMS-specific facility constitutes a philosophical deviation. It is, I believe, warranted; however, we may want to include a concern for any other such deviations. Should the new standard attempt also to solve MVS-specific, or Unix System V.3 or Unix BSD-specific issues? Probably. Dave
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Feb 89 16:46:44 EST From: jam@radc-lonex.arpa To: tcp-ip@sri-nic.arpa
The following are comments to a private reply I made to Ken after my posting of this morning. I feel the subject bears discussion by the tcp-ip community. >From: adelman@TGV.COM (Kenneth Adelman) >> My statement still stands about adding machine specific >> protocols to INTERNET definitions. I would say the same >> thing about UNIX here. If the need is that specific, >> perhaps the VMS people should look at creating their own tool, >> such as some UNIX vendors built NFS. > > "some UNIX vendors" is SUN, and NFS is presumable Rev 2 of the NFS >spec (what most people call NFS). Note that Rev 3 of the specification >includes extensions such as arbitrary attributes attached to files, >which SUN added at our request. I.e. NFS isn't tied to Unix either. > > Look at what happened with other "UNIX-specific" tools, like the >'R' services. Yep, we implement them for VMS because the market >requires it. I doubt the market will require Unix machine understand >VMS file... Yes, I realize NFS is not limited to UNIX. And you won't find any disagreement from me on the necessity to implement the defacto standards on other machines due to market insistence. That wasn't quite my point. > Anyway --- exactly what I'm proposing is that the VMS people >create their 'own' tools, STRU VMS, for transfering files in a >standard way between VMS machines, just like the "UNIX" people >invented R-services, NFS, etc, for performing those functions between >Unix machine. Ah, that is much closer to my point. But you see, when implementing vendor specific protocols, it may not be in our best interest to attach them to the supposedly independent INTERNET protocols. It sort of goes against the grain. And that is what needs to be hashed out by the community: do we add them directly to our "generic" protocols? or do we make people write vendor specific packages to do the job along side of the INTERNET tool (ie: ftp, telnet) specifications? You see, if you want a fast file transfer protocol to go just between VMS machines, perhaps the judgement will be that you have to create your own version of a file transfer protocol, not attach additions to the generic one the rest of the world is using. I'm not saying one way or the other; I'm just saying let the world decide if this type of addition to INTERNET protocols (VMS or other vendor dependent) is a justifiable policy. Or at least let the committee decide... You may want to let that battle rage before you start deciding what the protocol specifications will be. Joel A. Mussman
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 11:48:23 GMT From: jv@mhres.mh.nl (Johan Vromans) To: comp.protocols.tcp-ip Subject: Question on Telnet and CR/LF handling
Sorry if this has been asked before, but ... I'm using several Unix systems, and access them via TCP/IP. I use both a Macintosh with NCSA Telnet and a terminal connected to a Bridge CS200 terminal server. My problem is as follows. When I run an application on the Unix machines which switches off CR to LF mapping on input (e.g. stty -icrnl), some of the systems behave correct, but others don't. The Telnet protocol, as defined in RFC854, specifies that the sequence CR-LF is to be treated as a single newline, and that CR-NUL must be used where a CR alone is desired. NCSA Telnet lets you specify this, but the CS200 does not. I did a simple experiment. In the columns, CR-NUL means: NCSA Telnet sends CR-NUL when the CR key is hit, CR-LF means: NCSA Telnet sending CR-LF, and CS200 indicates access via the Bridge CS200 terminal server. "ok" means the application can tell which key (CR or LF) was hit, "-" means: it can not (it only sees a LF). System CR-NUL CR-LF CS200 ------------------------------------- 1. Ultrix 3.0 ok ok ok 2. UTX 2.0 ok - ok 3. HPUX 5.3 ok ok ok 4. HPUX 6.2 ok - - ------------------------------------- I can understand that CR-NUL works ok for all systems. I can understand that systems 2 and 4 adhere to RFC854 and that an application cannot switch off CR to LF mapping because the telnet protocol has already translated it. I don't understand why systems 1 and 3 allow the application to do so, in spite of RFC854. And I cannot understand why systems 1, 2 and 3 can be used via the CS200, but not system 4. Can anyone shed some light into this darkness? Please reply by E-mail, I'll summarize if relevant. Thanks, Johan -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 13:36:39 GMT From: rcb@cccvs1.ncsu.edu (Randy Buckland) To: comp.protocols.tcp-ip Subject: Proxy arp
Does anybody know where I can get a copy of proxy arp code for either an IBM PC/RT V2.2.1 or an Ultrix system V3.0? Randy Buckland rcb@ncsuvx.ncsu.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 14:20:24 GMT From: kchon@secola.Columbia.NCR.COM (Kun Sop Chon) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Remote Peripheral Access
We(our group) try to build an End-to-End solution for TCP/IP Local Area Network. The hardware configuration for this system will include Unix mini computers(as server or client), Unix PCs(client), and DOS PCs(client). One of thing, We like to include in this system is a remote printer access. In other words, any clients can submit printing jobs on server computer via the TCP/IP network, moniter the printer, and cancel the job if he/she wants. If any of you know TCP/IP software package (perhaps NFS) allows me to do these functions please let me know. If you prefer to call I can be reached at (803) 739-7708 during 8 to 5 in Eastern Standard Time. There is the Novell package that allows one to print from DOS client machines to a Unix server machine but not from other Unix machine.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 16:42:45 GMT From: mckenzie@bbn.com (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Re: terminating connections
TCP and ISO TP handle the closing of a connection differently because of different assumptions about the environment in which they will be embedded. TCP assumes that it (alone) is responsible for the reliability of the data transport; a user application which doesn't want to be concerned with transport reliability may be built directly on top of it. This might even be an application which has only a one-way data flow. The application can just hand a lot of data to the TCP module and the give the module a command like "when you are done sending the data, close the connection". So TCP better be sure that all the data has been correctly received by the receiver befor the connection is closed and the TCP resources are deallocated. ISO TP assumes that it is in the middle of a protocol stack. It is responsible for ensuring reliable transmission (let's not argue about this phrase - I know it is not literally correct) but that higher layers of protocol will be doing their own handshaking to be sure their resources are not prematurely deallocated. In particular, since the Transport layer "knows" that the Session layer will perform a handshake which must be completed before either Session entity asks the Transport layer to close the connection, no value is added by having the Transport entities also shake hands; the pipe is truely empty when the "Close Transport" command comes down from Session. Hope this helps, Alex McKenzie
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 17:20:37 GMT From: booloo@lll-lcc.llnl.gov (Mark Boolootian) To: comp.protocols.tcp-ip Subject: Obtaining internet addresses
---
Is it possible (under Ultrix 2.0) for a server to obtain the internet
address that the client used to contact the server? My need to know this is
based on the following situation: I have written an ftp gateway server which
we would like to gateway to two machines. User should be able to specify
either machine using the normal ftp client syntax:
ftp mach1
or
ftp mach2
The host table on the client machine will contain distinct internet addresses
for mach1 and mach2; however, they will have to resolve to the same physical
address since there is only a single ethernet interface on the gateway machine.
So, if the ftp server had some way of determining the internet address that was
used to contact it, the server could gateway to the appropriate machine.
My guess is that, even if this information did exist, there is no way
to get at it. In either case, if anyone has any suggestions as to how I might
solve this problem, I will heap praise upon thou.
Thanks for reading this.
mb
--
uucp: {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa: booloo@lll-lcc.arpa
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 18:45:36 GMT From: sbradley@mipos3.intel.com (Seth Bradley ~) To: comp.sources.wanted,comp.protocols.tcp-ip Subject: Testing NFS performance
I am looking for bechmark programs that test the relative performance
of NFS fileservers. I am particularly interested in simulating requests
from several clients simultaneously. Any help would be appreciated.
--
UUCP: {dalek|decwrl|hplabs|oliveb|pur-ee|amdcad}!intelca!mipos3!sbradley
Phone: (408) 765-4147
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Feb 89 4:41:04 EST From: Phil Dykstra <phil@BRL.MIL> To: tcp-ip@sri-nic.arpa Subject: Instability in the Core
Tonight I was trying to talk to some machines on XEROX-NET (net 13), and once again was hit with oscillating Net-Up/Net-Unreachable. This has been happening to me for the past several days for net 13 as well as several other nets (FYI, I'm 26.2.0.29). We have been getting EGP info from the RESTON-DCEC Butterfly (26.21.0.104). I started watching tonight to see why these routes kept appearing and disappearing and found major unrest in the routing information we were getting. Here are nine consecutive EGP routing updates (taken at three minute intervals). They span 0400 EST. Int Ext Routes (~A B C) 5 95 479 6 85 536 5 95 401 6 86 598 17 333 263 6 84 507 15 266 241 5 94 456 8 270 193 6 91 599 16 335 263 4 93 453 8 266 194 6 87 580 17 321 257 The fields are number of internal and external EGP gateways, total number of routes, and the approximate number of class A, B, and C (approx because this includes a few of our fixed routes). I have complete EGP dumps for the last six updates if anyone wishes to study the changes. It really bothers me that the number of class A networks could double/half every three minutes! There is also a 10% to 50% change in the total number of routes every three minutes. One wouldn't expect the number of internal EGP gateways to change so fast either [thought the LSI-11's used to flop like that too]. It is nearly impossible to get data through when the routes come and go this fast. I realize that the Butterfly folks are probably working on this, but I wasn't sure everyone was aware how bad things are right now (I recall one other TCP-IP note about it). Is there anything we can do to help diagnose this? - Phil <phil@brl.mil> uunet!brl!phil
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 1 Feb 89 23:54:00 GMT From: martillo@cpoint.UUCP (Joacim Martillo) To: comp.protocols.tcp-ip Subject: Re: Subnets on an unsubnetted network
I am not sure I understand the problem. Perhaps, I am wrong but I would consider subnetting a useful administrative kludge when I have several physical networks but one network number. With such understanding gateways between two subnets of one network number should not behave much differently than gateways between two networks with two different network numbers. I would not want my gateway to forward IP broadcast packets from one network or subnet to the other network or subnet. That just allows little sins to turn into big sins. Now if I have hosts that understand subnets and hosts that do not understand subnets on the same physical network. I would expect the hosts that understand subnets to use the subnet IP broadcast and hosts that do not understand subnets to use the standard network IP broadcast. I would expect the subnet understanding hosts to understand all IP broadcasts while the hosts which do not subnet would not understand subnet IP broadcasts. Such is life and may be acceptable, otherwise you have to run subnetting software on all machines. Now if I understand the case presented, you have gateways which understand subnetting and on one side of each gateway you have hosts which understand subnets while on the other side of each gateway you have hosts which do not understand subnets and there is but one network for all the hosts which do not understand subnets. On the subnetted side, life is simple. A given host either arps IP address on the subnet or sends IP packets to the gateway when the destination IP address is not on the same subnet. On the unsubnetted side, life is rotten. Suppose a host which does not understand subnets wants to send IP packets to a subnetted host. This host will assume that the subnetted host is on the same physical network and will arp it. Unless the gateway on the subnet host can do proxy arp, there will be no response to the original arp request and the IP address will not be resolved. If the non-subnetted hosts can be pursuaded to send IP packets with unresolved IP addresses to a gateway, it would be possible to establish communication but there would be no obvious basis on which to choose to which gateway to send the packet. I suppose you could depend on ICMP redirect to fix this but it seems rather gross and lots of hosts ignore ICMP redirect so that an IP packet might always be sent to the wrong gateway first which would then send the packet to the right gateway. The bottom line really is that in your network hosts which do not have a subnet address should still be doing subnet routing, and until you get the appropriate software you will have problems. As for the gateways, as long as they understand subnet routing properly, it should be possible for one interface to be attached to a subnetted physical network with appropriate subnet mask while the other interface is attached to an unsubnetted physical network. By the way, subnetting should be just as possible on a class C network as on a class B network.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 00:18:43 GMT From: ncs@srhqla.UUCP (Sekar) To: comp.databases,comp.dcom.lans,comp.lsi,comp.protocols.tcp-ip,comp.software-eng,comp.std.internat,comp.std.misc Subject: Re: Network Definition Language
In article <153@qusunb.queensu.CA> fokas@qucis.queensu.CA (Elias Fokas) writes: > > Abstract > > Network Definition Language (NDL) > Unisys (Detroit,MI) has had this language ( called NDL ! - same expansion ) on all its (Burroughs) mainframes with proprietary OS ( MCP - master control program) for many,many years. I know it handles some ( not all ) of your conceptual requirements. Hope this helps. - sekar
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 00:32:52 GMT From: martillo@cpoint.UUCP (Joacim Martillo) To: comp.protocols.iso,comp.std.internat,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Layer Encapsulation in OSI
In article <2016@cpoint.UUCP> martillo@cpoint.UUCP (Joacim Martillo) writes: >Anyone know of any references to layer encapsulation in official >OSI or CCITT documents. The problem is as follows: >LLC type II is reliable and one might want to provide security >on a per logical link basis, Unless you want to provide reliability >in the security layer itself, to make sure that applications which >run in a secure environment, you want to put the security layer >between LLC and the MAC layer, but at that point in the stack >the protocol software should only be looking at the MAC addresses >and security cannot be provided on a per logical link basis. >And if the security layers lives at the top of LLC, then the >security layer has to provide reliability. >I vaguely remember having this problem at Bell Labs when working >on Data Teleconferencing and the solution was layer encapsulation >where the security procedures would encapsulate the protocol >layer, but I simply don't remember where this was described in >the CCITT or OSI documents. If someone could give a pointer, >I would be grateful. I am following the current deliberations of the 802.10 committee on this issue. Tony Bono had what I consider a good original proposal for an architecture to deal with the issue. Apparently, the committee could not shoot down the proposal, but because he did not give a detailed functional specification (which was not what I understood to have been originally requested), the committee decided that they would only provide security procedures at the boundary between LLC and the MAC (based on pairwise MAC addresses) and not at the boundary between the Network Layer and LLC based on LSAP/DSAP pairs for a given MAC layer connection. Personally, I can think of many reasons why one might want to provide pairwise LSAP/DSAP security rather than simply point-to-point MAC address based security. It seems to me perfectly reasonable that Network Management communications streams, OSI communications streams or TCP/IP communications streams might all require different security procedures at the boundary between LLC and the network layer. Personally, I would think distributed multi-level security would be a nice thing. Providing security procedures on a per LSAP/DSAP basis would give the possibility of multi-level security at the link-layer, so that a given host might be able to realize that a given data stream from a host was trusted at a secret level because the user had logged into the console in a room guarded by guys with machine guns while another data stream from the same host was not trusted at all because the user had dialed in from outside. I see this situation all the time. Everytime someone wants to incorporate some new idea into OSI which actually give some reason to switch from TCP/IP to OSI, it gets shot down at the committee level. Now I understand why the best standards are those which were ad hoc standards first, and only much later standardized by the international committees. Any comments?
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 01:31:58 GMT From: mhampson@wpi.edu (Mark A. Hampson) To: comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip Subject: ATT 3b2/400 and TCP/IP
We have recently implimented a campus-wide TCP-IP network and have several AT&T 3B2/400 machines running S5. These machines each have a transever port. Currently we have software to impliment '3BNET'. (Yes, the inventors of UNIX did not include any TCP-IP support). I am wondering if anyone has heard of any TCP-IP software for this machine. Please respond via E-Mail to: mhampson@wpi.wpi.edu (internet)
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Thu, 02 Feb 89 12:07:38 EST From: Rudy.Nedved@RUDY.FAC.CS.CMU.EDU To: Mark Crispin <mrc@Tomobiki-Cho.cac.WASHINGTON.EDU> Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Unix TCP connectivity problems
Mark et al, The CMU version of the pseudo terminal (pty) driver for 4.3BSD based Unix (or for Mach Unix) has the concept of detached jobs. For this reason, it is not a big deal to lose a network connection for Mach systems (assuming you are running the CMU modified telnet daemon which uses the CMU pty driver). For programs that use the network, you can detect a problem with an aborted connection by checking errno which is documented in intro(2). You will get an errno of ENETUNREACH, ENETRESET, ECONNABORTED or ECONNRESET (most likely). But for general transparent network support of terminal sessions, the concept of a detached terminal is needed. We have had this concept since 4.0BSD Unix before the days of TCP (we used it for Xerox BSP/PUP 'Chat' connections). -Rudy
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 14:27:38 GMT From: mhampson@wpi.edu (Mark A. Hampson) To: comp.sys.att,comp.protocols.tcp-ip Subject: TCP-IP for AT&T 3B2's
would like to take this oportunity to thank the folks at Bell Labs for taking such good care of me on the TCP for 3B2 problem. To summarize: There is a package (Enhanced TCP/WIN 3B) from the Wollongong Group that is sold through AT&T that uses the 3BNET hardware and gives TCP/IP support. The package is refered to as 1040-TE1 for S5R2 and 1040-TE2 for S5R3. Thanks again. Mark A. Hampson (internet) mhampson@wpi.wpi.edu
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 15:41:12 GMT From: danno@onm3b2.UUCP (dan notov) To: comp.protocols.tcp-ip Subject: r* Command Incompatibilities?
I am running the following on a TCP/IP network: An AT&T 3B2/310 SVR3.1 with WIN/3B An AT&T 6386E WGS SVR3.1 with Micom/Interlan NP622A I have found that rlogin from the 3B2 to the 386 always prompts me for a password. Is this normal? I do have both hosts defined in /etc/hosts.equiv and ~/.rhosts, so I'm wondering if there is a problem elsewhere. However, the remote shell commands work properly. On another network with a VAX/VMS & 3B2/UNIX (both WIN s/w), rlogin works as advertised. Is there some incompatibility between the MICOM & WIN versions of these commands? Inquiring minds want to know... -- danno Daniel S. Notov Ogilvy & Mather, Inc. New York, NY uunet!onm3b2!danno
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 16:28:01 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
I think we should either attempt to solve the interoperablity problem using: an eXternal File Representation? Pre and post-processing options? (tar; compress/uncompress; tar for example) . . . with FTP. or, else realize that it is an os specific problem, and interoperablity is not the goal. Maybe "we" want a 'vcp' for VMS copy, etc. The vendor and it's third parties could come up with the standard for that. They probably already have one, it just needs to operate on top of TCP/IP instead of DECNET. Phil Wood, cpw@lanl.gov
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 16:58:06 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
One more thing and I'll leave it to the experts.
Rather than STRU VMS, make it STRU {LOCAL|EXOTIC}. If two VMS hosts
were "inter-operating" than either option would work correctly.
STRU LOCAL means that files transfered from the local host
to the "exotic" host (I could not use Foreign or Remote because
of File and Record) would be in a standard-for-local-operating-system
format (SFLOS) ('tar;compressed' for UNIX, 'cpio;???' for ATT, ...).
Conversely, files transfered to the local host would be in this
"standard" format. The "Exotic" host would have to understand
this "standard".
STRU EXOTIC means that the structure for a "file" transfer
would be in standard-for-remote-operating-system (SFROS) format.
That way we don't run out of single character mneumonics for all the
"Open" operating systems coming down the line.
Phil Wood, cpw@lanl.gov
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 17:07:38 GMT From: Rudy.Nedved@RUDY.FAC.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: Unix TCP connectivity problems
Mark et al, The CMU version of the pseudo terminal (pty) driver for 4.3BSD based Unix (or for Mach Unix) has the concept of detached jobs. For this reason, it is not a big deal to lose a network connection for Mach systems (assuming you are running the CMU modified telnet daemon which uses the CMU pty driver). For programs that use the network, you can detect a problem with an aborted connection by checking errno which is documented in intro(2). You will get an errno of ENETUNREACH, ENETRESET, ECONNABORTED or ECONNRESET (most likely). But for general transparent network support of terminal sessions, the concept of a detached terminal is needed. We have had this concept since 4.0BSD Unix before the days of TCP (we used it for Xerox BSP/PUP 'Chat' connections). -Rudy
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 17:50:47 GMT From: chm@nbires.nbi.com (Paul Chmielewski) To: comp.protocols.tcp-ip Subject: IP over X.25 (request for info)
We're in the process of putting together an IP-over-X.25 package for our 4.3 derivative UNIX systems. We currently have an intelligent communications card (VME bus) on which we run X.25. The UNIX kernel and networking subsystem are pretty much straight from BSD4.3. We plan to write a network interface driver to interface with the X.25 code. I'm interested in hearing from people who have already done this or something similiar. I'd like to hear about problems you ran into, what type of performance to expect, or what documentation you found useful. I've read RFC 877, but it doesn't seem to address all of the issues. I do have one specific question concerning the internet address to virtual circuit pairings. Is there a standard mechanism for telling the called end of a virtual circuit what the internet address of the calling host is? I'm thinking that each X.25 VC or PVC will be configured as a point-to-point link. The machine initiating the call can fairly easily map the pt-to-pt IP addresses to the virtual circuit. But I'm not sure how the machine accepting the call would do this. One possibility would be to include the initiating machines IP address in the Call User Data Field after the protocol demultiplexing octet. Any comments?? Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 938-2926
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 19:15:26 GMT From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) To: comp.protocols.tcp-ip Subject: Re: Dial up SLIP
In article <32958@tut.cis.ohio-state.edu> Bill Wisner <wisner@cis.ohio-state.edu> writes: >A protocol called SLFP, developed at MIT, has been added to the Atari ST port >of KA9Q TCP/IP by a University of Michigan person, and has been implemented >on Michigan's MERIT network. It allows dial-up Internet access like SLIP, >but with an interesting twist. When an ST with KA9Q dials into MERIT, both >ends automatically begin talking SLFP. But MERIT dynamically allocates >the ST an IP address. The address assigned is different every time a >connection is made. Howard Chu (umix!hyc), myself, and Bill Doster (Bill_Doster@um.cc.umich.edu) have worked on slfp with ka9q. The net result is that MERIT users possessing a modem and a PC can ftp files and use telnet. The files were available for anonymous ftp from umix.cc.umich.edu. Non internet people might try a public access unix system available at (313) 994-6333. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Thu, 3 Feb 89 00:33:42 From: Tod.Shannon@DRAGON.CIMDS.RI.CMU.EDU To: tcp-ip@sri-nic.arpa Cc: stru-vms@tgv.com Subject: Re: Using Page structure
We used the page structure for the CMU-TEK FTP because we wanted to stay nominally within the FTP spec. I don't think the page structure is really the way that we should go, since it really is a TOPS-20/Tenex-ism. The 255 (if I remember correctly) byte limit per page isn't really suited to VMS; if we are going to make some VMS specific changes to the spec, they should be oriented towards efficiency as well as functionality. On the matter of having filters, I think the real world demands a better solution. A two step process for special file transfers would be awkward and confusing; I think if filters became a "standard" that it would be a standard soon retired to the dusty shelves of disuse. It would be nice if everything could be designed and implemented in a vacuum, and if everyone used the same "standards," and if all the "standards" were of excellent quality. Unfortunately, we don't live in a vacuum, standards are often ignored (for good and bad reasons), and they are often of poor quality. I think it is pointless to discuss whether or not the addition of VMS specific changes to the FTP spec. is appropriate. The need for the functionality exists and it is unreasonable to believe that vendors and other institutions will discontinue efforts in support of such a need. It is our job to try to meet the functionality requirements in the best way that we can. -Tod Shannon
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 20:25:55 GMT From: ted@blia.BLI.COM (Ted Marshall) To: comp.protocols.tcp-ip Subject: IP Encapsulation on HP 3000/9000 computers
I have heard that HP's TCP/IP implementation, when sending over Ethernet, uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP) instead of Ethernet V2 format (i.e. protocol type) like most Unixes. Can anyone confirm or deny this? Specifically, I need to know if one can put an HP machine and one of our own boxes (which will only speak Ethernet V2 format) on an Ethernet and have them communicate. If the answer is that the HP box will only talk 802.3 format, can someone suggest an inexpensive bridge/router/etc box that could translate between the two? Thank you in advance. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 2 Feb 89 20:36:15 GMT From: booloo@lll-lcc.llnl.gov (Mark Boolootian) To: comp.protocols.tcp-ip Subject: Re: Obtaining internet addresses
In article <2266@lll-lcc.llnl.gov> booloo@lll-lcc.llnl.gov.UUCP I write:
>
>The host table on the client machine will contain distinct internet addresses
>for mach1 and mach2; however, they will have to resolve to the same physical
>address since there is only a single ethernet interface on the gateway machine.
After looking through some source code, I have determined that it isn't
actually possible to have two ip addresses resolve to a single physical
address (at least in the case of a vax running Ultrix). So my question
can't be answered (at least to my liking).
mb
--
uucp: {gatech,ihnp4,pyramid,rutgers}!lll-lcc!booloo
arpa: booloo@lll-lcc.arpa
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 02:24:32 GMT From: adelman@TGV.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: STRU VMS
> Rather than STRU VMS, make it STRU {LOCAL|EXOTIC}. If two VMS hosts
> were "inter-operating" than either option would work correctly.
> That way we don't run out of single character mneumonics for all the
> "Open" operating systems coming down the line.
Just a STRU EXOTIC isn't enough, because we'd like to be able to
send a STRU VMS on client startup. If it is accepted, then we use that
mode by default. The problem with STRU EXOTIC is that something else
might accept it.
I think that "STRU O VMS" is a good idea, where "O" stands for Operating
System dependent. There are two reasons for this:
1) It would be a big help to Wollongong not to call the result STRU VMS
since they already have software in the field which uses this with
a non-standard encapsulation. Calling it something else would give
them compatibility between releases.
2) We don't run into the 26 character limit (for those people who only
look at the first character).
Any objections to this????
Ken
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 03:18:01 GMT From: smart@ditmela.oz (Robert Smart) To: comp.protocols.tcp-ip Subject: Interactive game playing over an internet network
I am amazed that there don't seem to be protocols and programs for
supporting game playing over an internet network. The sort of thing I
envisage would allow a client program to connect to a game control
server. They could then start a game, or join an existing game. The
protocol would include the ability to send move information to the
control server, receive state-of-game information from the control
server, send text information to opponents, opponents and partners,
just partners [this last not allowed in some games, e.g. Bridge!].
Given the appropriate control server it should then be easy to modify
programs like the Sun gammontool and chesstool to provide nice human
interfaces to various games.
I really feel that something like this would be extremely worthwhile
in demonstating the sort of things that you can do with networks. I
try to convince people that interactive computer networking doesn't
have to mean that you use the network to log into an interactive
account on a remote machine. In fact logging in over a network tends
to be both a horrible security problem and a very inefficient use of
network resources. But when you try to describe other ways that a
network could be used interactively, there aren't a lot of examples:
remote disk and file access and the talk/phone system (which isn't
used a lot). I am sure a system such as I propose would inspire people
with interests in worthwhile activities like remote education,
learning through serious role playing and computer conferencing.
Anybody else interested? Any existing work? Should we write an RFC?
Bob Smart, CSIRO Division of Information Technology, Australia
smart@ditmelb.oz.au (or smart%ditmelb.oz.au@uunet.uu.net)
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 05:59:49 GMT From: jdm@starfish.Convergent.COM (John McLean) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
From article <6402@blia.BLI.COM>, by ted@blia.BLI.COM (Ted Marshall): > > I have heard that HP's TCP/IP implementation, when sending over Ethernet, > uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP) > instead of Ethernet V2 format (i.e. protocol type) like most Unixes. This is correct; the encapsulation used by the HP's is IEEE802.3. They also use PROBE for address resolution (instead of ARP). In addition, HP has their own set of user-level programs (instead of TELNET and FTP). I guess HP really did want to have it *their* own way! We have been able to get our UNIX hosts to communicate with a HP3000/CLASSIC by doing the following: 1. Purchasing a gateway server box from cisco. This box does the conversion from Ethernet 2.0 to IEEE802.3 encapsulation. (The gateway server understands both PROBE and ARP, however, we are currently operating from manually-created IP-to-Ethernet address entries.) 2. Purchasing the WIN/HP product from Wollongong. This package includes TELNET and FTP. It runs on the HP3000/CLASSIC model only. (We also have two HP3000/SPECTRUM systems; the WIN/HP product does not run on these systems.) All of our HP systems are on the same physical ethernet as the UNIX hosts. Of course, this means that all data from the UNIX systems to the HP systems goes thru the net twice; the additional overhead has not caused a problem yet. John McLean jdm@starfish.Convergent.COM Systems Engineer Convergent Technologies ---
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 89 12:53 EST From: EWOLF@rcca.bbn.com To: tcp-ip@sri-nic.arpa Cc: ewolf@rcca.bbn.com Subject: Remove from list
Please remove my name from the tcp-ip distribution list.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 07:53:40 GMT From: JOHN@MATHOM.CISCO.COM (John Wright) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
Yes, it is my understanding that they need some sort of translator. The company I work for makes a router device which also can act as a 802.3/V2 converter it supports both Probe & ARP. If you would like more information we can send you something in the mail. Make a request to 'customer-service@cisco.com', as I am about to leave town for a while. John Wright Customer Engineer cisco Systems, Inc. 1350 Willow Rd Menlo Park, CA 94205 (415) 326-1941 -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 08:33:42 GMT From: Tod.Shannon@DRAGON.CIMDS.RI.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: Using Page structure
We used the page structure for the CMU-TEK FTP because we wanted to stay nominally within the FTP spec. I don't think the page structure is really the way that we should go, since it really is a TOPS-20/Tenex-ism. The 255 (if I remember correctly) byte limit per page isn't really suited to VMS; if we are going to make some VMS specific changes to the spec, they should be oriented towards efficiency as well as functionality. On the matter of having filters, I think the real world demands a better solution. A two step process for special file transfers would be awkward and confusing; I think if filters became a "standard" that it would be a standard soon retired to the dusty shelves of disuse. It would be nice if everything could be designed and implemented in a vacuum, and if everyone used the same "standards," and if all the "standards" were of excellent quality. Unfortunately, we don't live in a vacuum, standards are often ignored (for good and bad reasons), and they are often of poor quality. I think it is pointless to discuss whether or not the addition of VMS specific changes to the FTP spec. is appropriate. The need for the functionality exists and it is unreasonable to believe that vendors and other institutions will discontinue efforts in support of such a need. It is our job to try to meet the functionality requirements in the best way that we can. -Tod Shannon
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 13:10:39 GMT From: mleonard@secola.Columbia.NCR.COM (Michael Leonard) To: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Network Security
In article <9424@pasteur.Berkeley.EDU> vincent@zubenelgenubi.uucp () writes: >I am working on a network security project and am looking for pointers >to papers, books .... etc or your own comments and views. >More specifically, I'm looking at >security measures at both hardware and network layer level. > >Thanks. >Vincent. The April 1987 issue of IEEE Network Magazine has a number of articles on network security. The references in those articles will lead you to many more. mike
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 1989 19:01-EST From: CERF@A.ISI.EDU To: nbires!chm@UCBVAX.BERKELEY.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: IP over X.25 (request for info)
Paul, After the VC is established, the first packet over the link is an IP packet containing source/destination IP addresses and, probably, a TCP SYN packet or a UDP packet. Won't the Source/Dest address in the first IP packet be sufficient or have I missed some initialization problem on the receiving end? Vint Cerf
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Feb 89 20:32:50 EST From: Brad Clements <bkc@omnigate.clarkson.edu> To: pcip@twg.com Cc: tcp-ip@sri-nic.arpa Subject: Packet Driver version of NCSA Telnet 2.2 is now Available
(sorry for the cross-post)
1/31/89
A Beta Test version of NCSA telnet V2.2C is now available via anonymous FTP
from omnigate.clarkson.edu (128.153.4.2) from the directory pub/ncsa2.2c
This is the readme file from that directory.
A uuencoded compressed tar file of the binaries is also available by mail:
% mail archive-server@sun.soe.clarkson.edu
Subject: send ncsabin.tar.Z.uu
(206Kbytes long)
Version 2.2C is a highly modified copy of NCSA Telnet version 2.2
It has been recompiled under Turbo C 2.0, supports the Packet Driver
interface, 43 Line mode EGA, domain name search paths, BOOTP, connecting
to a specified destination port, internal random FTP password, enhanced
directory listing under FTP, display clock and a host of other enhancements.
*** This is a Beta release, no warranties are expressed or implied ***
*** Use at your OWN risk. Neither Clarkson University nor the National
*** Center for Supercomputing Applications implies any warrenty or
*** fitness for use, etc.
This version was developed independently of NCSA, please do not bother them
with bug reports or questions (NCSA support of this version may be
a future possibility)
Plase Send bug reports and/or questions to:
bkc@omnigate.clarkson.edu
The following files are available:
/pub/ncsa2.2c
-rw-r--r-- 1 bkc 109755 Feb 3 18:12 PCtelnet2.2c.ascii
-rw-r--r-- 1 bkc 47812 Feb 3 18:08 PCtelnet2.2c.ascii.Z
-rw-r--r-- 1 bkc 9452 Jan 31 18:56 config.tel
-rw-r--r-- 1 bkc 208896 Feb 3 18:13 ncsabin.tar
-rw-r--r-- 1 bkc 150264 Feb 3 18:11 ncsabin.tar.Z
-rw-r--r-- 1 bkc 988160 Feb 3 19:22 ncsasrc.tar
-rw-r--r-- 1 bkc 374373 Feb 3 19:29 ncsasrc.tar.Z
-rw-r--r-- 1 bkc 3126 Feb 3 20:04 readme
PCtelnet2.2c.ascii.Z You should read this first for a detailed
description of changes. This is version 2.2 documentation
with margin comments describing the new features.
ncsabin.tar.Z contains the binaries for telbin.exe, telpass.exe
(ftpbin.exe is not included due to a serious bug)
ncsasrc.tar.Z contains all the source (for Turbo C 2.0)
config.tel a sample config.tel file (is included in both tar files)
readme This file.
NOTE!: Both tar files are binary images of the PC source. Thats good
for ncsabin.tar, but bad for ncsasrc.tar. If you untar the source
on a unix system you'll have to strip off trailing CR's and a ^Z at the
end of each file, unless you do a binary copy to your PC.
Known bugs:
currently ftpbin.exe can not upload to a host w/o crashing.
The best new feature in this version is support for the Packet Driver
interface (from FTP Software). Some packet drivers are available from
grape.ecs.clarkson.edu in the file comm/drivers.arc
This version has been tested with the following packet drivers:
ni5210
ni5010
3c501
The second best feature is support for BOOTP. This is a method
whereby the client PC can get information from a server about its
IP address, gateway, nameservers and netmask. You should read
RFC1048 for detailed information.
I would appreciate comments and bug reports. This version is currently
in use at Clarkson University in our public terminal areas (hence Bootp).
Brad Clements
Network Engineer
Educational Resources Center
Clarkson University
Potsdam, NY /* the land that time forgot */
(315)268-2292
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 16:25:02 GMT From: amanda@lts.UUCP (Amanda Walker) To: comp.protocols.tcp-ip Subject: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
In our Macintosh TCP/IP product, we face the same issue of exchanging non-vanilla files between like systems, and so far my preference is to use "SITE" commands to modify the interpretation of Image mode. I don't want to leap into the fray here, that's just how I read the RFC. Something else that we do with our FTP client is to make it as intelligent as possible if it can figure out what it's talking to. Theoretically, this is pretty easy: just use the SYST command. Unfortunately, very few FTP servers seem to implement it, even though it's dead simple to do. We get along pretty well by looking at the HINFO fields in DNS replies, but that doesn't help us differentiate from, say, half a dozen different VMS FTP servers. I encourage anyone working on an FTP server to add the SYST command. I'd also be interested to know what the responses are from any servers out there that aleady do implement it. Just to get things started, here's what our products return: 200 MAC-OS TCP/Connect for the Macintosh Version x.x 200 MS/DOS TCP/Connect for the PC Version x.x Even if you don't think anyone else cares :-), please at least mail it to me... -- Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net InterCon, 11732 Bowman Green Drive, Reston, VA 22090 -- "NO one expects the Spanish Inquisition!"
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 16:29:16 GMT From: jam@RADC-LONEX.ARPA To: comp.protocols.tcp-ip Subject: INTERNET.vendor_specific
>I think it is pointless to discuss whether or not the addition of VMS specific >changes to the FTP spec. is appropriate. The need for the functionality exists >and it is unreasonable to believe that vendors and other institutions will >discontinue efforts in support of such a need. It is our job to try to meet >the functionality requirements in the best way that we can. >From some of the comments I've seen, I think that some people are still misinterpreting what I said. I didn't request that we kill the discussion of a protocol under ftp for vms. Let that go on... and on... whatever. I realize that nobody is going to stop trying to do specific work to transfer files between VMS, or TOPS-20, or UNIX, or MS-DOS, and whatever other systems are out there. Thats great! There is NOTHING wrong with that! All I asked was should we add it as secondary protocols layers under existing tool protocols (ie: telnet, ftp, etc.) or should new tool protocols be developed. If the goal is to keep the basic tools (ftp...) "open", then new standards for "specific" tools need to be developed. In either case, somebody (the committee) has to make a statement on how us chickens, in "nobody here but us chickens" ;-), in the world of software development are supposed to approach this. I thought there would be enough interest concerning the goals of the network to warrent such a discussion. I'm not going to flame out one way or the other. It's just that this is the first time in recent memory (in this group) where someone has swung near that question again. Perhaps I am wrong. In that case I see myself going down in flames. Wouldn't be the first time. ;-) Joel A. Mussman
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 16:37:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: IP encapsulation on HP3000
I don't normally phrase things as commercial hype, but today is Friday and Ted Marshall asked the right question... While you are stopping at Wollongong to buy the applications for Telnet, FTP, and mail (SMTP), you might also consider getting WIN/ROUTE2 for DOS. This allows you to turn any DOS machine into an IP router that translates the HP 802.3 IP frames into ethernet frames. You will like the price. Dave Crocker VP, Engineering The Wollongong Group, Inc.
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 16:52:15 GMT From: barns@GATEWAY.MITRE.ORG (Bill Barns) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
Paul, If you have not made the acquaintance of the Defense Data Network (DDN) X.25 Standard Service, it would probably be a good idea to do so. It will NOT answer your immediate question, but considering the type of product you are developing, it seems to me that it would be rather silly not to support the DDN Standard Service as a configuration option. That may be the largest single market for IP over X.25. I will not describe it in detail as there are documents for that, but very briefly, it uses an algorithmic transformation between IP addresses and X.121 addresses. This transformation has some limitations which make it undesirable or unusable in many other situations, but it seems like it would be worth implementing, or at least leaving hooks for. DDN Standard X.25 has a couple of other twists which involve network-specific X.25 facilities at SVC initiation, as well as the CUD which is essentially as described in the RFC. Also, it imposes some implicit restrictions on the assignment of IP datagrams to X.25 VCs, so that Precedence will work. If you code it right to start with, the extra work is minimal; retrofitting may or may not be easy, "depending." The common method of address handling (that I know of) involves keeping static address mapping tables in all the X.25 endpoints involved. These tables associate IP addresses with X.121 DTE addresses. This method has the advantage of providing the basis for some security checking. Since the static configuration table lists all the DTE's that are expected to call and talk IP with you, you can clear calls from impostors. You would also have the IP layer do its routing based on this information, which prevents a legitimate DTE address from acquiring packets destined to an IP address properly belonging to some other DTE. The utility of this depends on the validity of the DTE address, but there is some validation of this in most public data networks, I believe. I would certainly want such a feature to be available in any box that I used on a public data network in this way. Send mail if you would like to chat about this further... this seems like enough for the public wire. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000050][next][prev][last][first]----------------------------------------------------
Date: 3 Feb 89 16:56:53 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: IP Encapsulation on HP 3000/9000 computersFor HP 9000's at least, you're not stuck with IEEE encapsulation -- it's a configurable option whether to use 802.3 or standard Ethernet IP encapsulation. We're using one right on our Ethernet, it interoperates just fine. I don't know about the HP 3000 series, though. Stuart Levy, Minnesota Supecomputer Center slevy@uc.msc.umn.edu
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 17:53:00 GMT From: EWOLF@RCCA.BBN.COM To: comp.protocols.tcp-ip Subject: Remove from list
Please remove my name from the tcp-ip distribution list.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 18:11:29 GMT From: stev@VAX.FTP.COM To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
*Yes, it is my understanding that they need some sort of translator. The *company I work for makes a router device which also can act as a *802.3/V2 converter it supports both Probe & ARP. If you would like *more information we can send you something in the mail. Make a request *to 'customer-service@cisco.com', as I am about to leave town for a while. *John Wright *cisco Systems, Inc. i believe that only the 3000 is like this. i thought that the 9000 could speak this "special IP" to act as a gateway. i was also under the impression that it wasnt even "real" ehternet based IP they were using, they didnt use ARP or something. i am sure someone from HP will set us all straight, though . . . . stev knowles ftp software
-----------[000053][next][prev][last][first]----------------------------------------------------
Date: 3 Feb 89 19:03:26 GMT
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To: comp.protocols.tcp-ip
Subject: Re: IP Encapsulation on HP 3000/9000 computersAn even better solution is to throw away HP-UX, and run 4.3 BSD on your 9000 series. Then you get full 4.3 networking code, and all the other things 4.3 gives you that HP-UX doesn't. It works quite well, and you can get from the folks at Utah. Maybe one of them would like to send out information on how to get the distribution. Some people STILL don't understand that people buy Unix systems for compatibility and portability. Sigh... Thanks, Milo PS Standard disclaimers apply re: US Government, NASA, etc... IE, this should not be construed as an official position, but the you probably realized that already.
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 19:32:26 GMT From: minshall@kinetics.UUCP (Greg Minshall) To: comp.protocols.tcp-ip,comp.protocols.appletalk Subject: IP over AppleTalk
I am hoping to put together/edit an RFC defining how IP is sent over AppleTalk (ala KIP gateways, K-STAR gateways, etc.). There is an existing "way" of doing this (though its never been set down as an RFC). There are a few things in the current scheme I think need to be dropped (ie: using NBP to do proxy ARP), and at least one important thing I think needs to be added (a "cross protocol" redirect message). [Sorry to the non- AppleTalkers for the crypt here...] At any rate, I'd love to gather a group to review the RFC before it is issued. If you are interested, please send your name, e-mail address, and USPS address. I hope to have a first draft for review by next week. Greg Minshall Kinetics 1-415-947-0998 ...!ucbvax!unisoft!kinetics!minshall 2540 Camino Diablo Walnut Creek California 94596
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 20:30:20 GMT From: postel@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: IAB Ethics Statement
Network Working Group Internet Activities Board
Request for Comments: 1087 January 1989
Ethics and the Internet
Status of this Memo
This memo is a statement of policy by the Internet Activities Board
(IAB) concerning the proper use of the resources of the Internet.
Distribution of this memo is unlimited.
Introduction
At great human and economic cost, resources drawn from the U.S.
Government, industry and the academic community have been assembled
into a collection of interconnected networks called the Internet.
Begun as a vehicle for experimental network research in the mid-
1970's, the Internet has become an important national infrastructure
supporting an increasingly widespread, multi-disciplinary community
of researchers ranging, inter alia, from computer scientists and
electrical engineers to mathematicians, physicists, medical
researchers, chemists, astronomers and space scientists.
As is true of other common infrastructures (e.g., roads, water
reservoirs and delivery systems, and the power generation and
distribution network), there is widespread dependence on the Internet
by its users for the support of day-to-day research activities.
The reliable operation of the Internet and the responsible use of its
resources is of common interest and concern for its users, operators
and sponsors. Recent events involving the hosts on the Internet and
in similar network infrastructures underscore the need to reiterate
the professional responsibility every Internet user bears to
colleagues and to the sponsors of the system. Many of the Internet
resources are provided by the U.S. Government. Abuse of the system
thus becomes a Federal matter above and beyond simple professional
ethics.
IAB Statement of Policy
The Internet is a national facility whose utility is largely a
consequence of its wide availability and accessibility.
Irresponsible use of this critical resource poses an enormous threat
to its continued availability to the technical community.
The U.S. Government sponsors of this system have a fiduciary
responsibility to the public to allocate government resources wisely
Internet Activities Board [Page 1]
RFC 1087 Ethics and the Internet January 1989
and effectively. Justification for the support of this system
suffers when highly disruptive abuses occur. Access to and use of
the Internet is a privilege and should be treated as such by all
users of this system.
The IAB strongly endorses the view of the Division Advisory Panel of
the National Science Foundation Division of Network, Communications
Research and Infrastructure which, in paraphrase, characterized as
unethical and unacceptable any activity which purposely:
(a) seeks to gain unauthorized access to the resources of the
Internet,
(b) disrupts the intended use of the Internet,
(c) wastes resources (people, capacity, computer) through such
actions,
(d) destroys the integrity of computer-based information,
and/or
(e) compromises the privacy of users.
The Internet exists in the general research milieu. Portions of it
continue to be used to support research and experimentation on
networking. Because experimentation on the Internet has the
potential to affect all of its components and users, researchers have
the responsibility to exercise great caution in the conduct of their
work. Negligence in the conduct of Internet-wide experiments is both
irresponsible and unacceptable.
The IAB plans to take whatever actions it can, in concert with
Federal agencies and other interested parties, to identify and to set
up technical and procedural mechanisms to make the Internet more
resistant to disruption. Such security, however, may be extremely
expensive and may be counterproductive if it inhibits the free flow
of information which makes the Internet so valuable. In the final
analysis, the health and well-being of the Internet is the
responsibility of its users who must, uniformly, guard against abuses
which disrupt the system and threaten its long-term viability.
Internet Activities Board [Page 2]
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 21:07:54 GMT From: dlt@csuna.UUCP (Dave Thompson) To: comp.protocols.tcp-ip Subject: tcp/ip on vms
I have just installed cmu's tcp/ip tackage. Not having RFC952, which describes the format of the known hosts file, I need to know the format of this file and which will reside in SYS$LIBRARY:HOSTS.TXT. I ported over /etc/hosts from one of our unix boxes, but evidently the format is different for I get an invalid keyword message for each line in the file when NAMSRV comes up. Can anyone help???? Thanks, Dave -- Dave Thompson uucp: dlt@csuna.csun.edu Computer Center Cal State University, Northridge phone: (818) 885-2790 18111 Nordhoff Street, Northridge, CA 91330
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 21:15:17 GMT From: VAF@SCORE.STANFORD.EDU (Vince Fuller) To: comp.protocols.tcp-ip Subject: Internet commercial uses policy?
Could someone refresh my memory about this? Several recent messages to this mailing list seem to have, in my opinion, exceded the bounds of what might be termed "non-commercial usage". I was under the impression that Internet mailing lists were not to be used for commercial advertising. Vince Fuller, Stanford University -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 3 Feb 89 21:16:48 GMT From: kincl@KITZBUHL.IAG.HP.COM (Norman Kincl) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
HP9000 (UNIX systems) speak both 802.2 and Ethernet V2 encapsulation. They can communicate transparently with either protocol. Nothing special is required to make this work. HP3000 (MPE systems) currently only speak 802.2 encapsulation. A cisco box can translate from this to Ethernet encapsulation. -Norm Kincl Information Architecture Group Hewlett-Packard
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 00:01:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
Paul, After the VC is established, the first packet over the link is an IP packet containing source/destination IP addresses and, probably, a TCP SYN packet or a UDP packet. Won't the Source/Dest address in the first IP packet be sufficient or have I missed some initialization problem on the receiving end? Vint Cerf
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 01:32:50 GMT From: bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) To: comp.protocols.tcp-ip Subject: Packet Driver version of NCSA Telnet 2.2 is now Available
(sorry for the cross-post)
1/31/89
A Beta Test version of NCSA telnet V2.2C is now available via anonymous FTP
from omnigate.clarkson.edu (128.153.4.2) from the directory pub/ncsa2.2c
This is the readme file from that directory.
A uuencoded compressed tar file of the binaries is also available by mail:
% mail archive-server@sun.soe.clarkson.edu
Subject: send ncsabin.tar.Z.uu
(206Kbytes long)
Version 2.2C is a highly modified copy of NCSA Telnet version 2.2
It has been recompiled under Turbo C 2.0, supports the Packet Driver
interface, 43 Line mode EGA, domain name search paths, BOOTP, connecting
to a specified destination port, internal random FTP password, enhanced
directory listing under FTP, display clock and a host of other enhancements.
*** This is a Beta release, no warranties are expressed or implied ***
*** Use at your OWN risk. Neither Clarkson University nor the National
*** Center for Supercomputing Applications implies any warrenty or
*** fitness for use, etc.
This version was developed independently of NCSA, please do not bother them
with bug reports or questions (NCSA support of this version may be
a future possibility)
Plase Send bug reports and/or questions to:
bkc@omnigate.clarkson.edu
The following files are available:
/pub/ncsa2.2c
-rw-r--r-- 1 bkc 109755 Feb 3 18:12 PCtelnet2.2c.ascii
-rw-r--r-- 1 bkc 47812 Feb 3 18:08 PCtelnet2.2c.ascii.Z
-rw-r--r-- 1 bkc 9452 Jan 31 18:56 config.tel
-rw-r--r-- 1 bkc 208896 Feb 3 18:13 ncsabin.tar
-rw-r--r-- 1 bkc 150264 Feb 3 18:11 ncsabin.tar.Z
-rw-r--r-- 1 bkc 988160 Feb 3 19:22 ncsasrc.tar
-rw-r--r-- 1 bkc 374373 Feb 3 19:29 ncsasrc.tar.Z
-rw-r--r-- 1 bkc 3126 Feb 3 20:04 readme
PCtelnet2.2c.ascii.Z You should read this first for a detailed
description of changes. This is version 2.2 documentation
with margin comments describing the new features.
ncsabin.tar.Z contains the binaries for telbin.exe, telpass.exe
(ftpbin.exe is not included due to a serious bug)
ncsasrc.tar.Z contains all the source (for Turbo C 2.0)
config.tel a sample config.tel file (is included in both tar files)
readme This file.
NOTE!: Both tar files are binary images of the PC source. Thats good
for ncsabin.tar, but bad for ncsasrc.tar. If you untar the source
on a unix system you'll have to strip off trailing CR's and a ^Z at the
end of each file, unless you do a binary copy to your PC.
Known bugs:
currently ftpbin.exe can not upload to a host w/o crashing.
The best new feature in this version is support for the Packet Driver
interface (from FTP Software). Some packet drivers are available from
grape.ecs.clarkson.edu in the file comm/drivers.arc
This version has been tested with the following packet drivers:
ni5210
ni5010
3c501
The second best feature is support for BOOTP. This is a method
whereby the client PC can get information from a server about its
IP address, gateway, nameservers and netmask. You should read
RFC1048 for detailed information.
I would appreciate comments and bug reports. This version is currently
in use at Clarkson University in our public terminal areas (hence Bootp).
Brad Clements
Network Engineer
Educational Resources Center
Clarkson University
Potsdam, NY /* the land that time forgot */
(315)268-2292
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Feb 89 11:11:09 PST From: braden@venera.isi.edu To: sun.soe.clarkson.edu!nelson@tcgould.tn.cornell.edu, tcp-ip@sri-nic.arpa Subject: Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
Speaking of FTP, has anyone implemented RESTart? Restart requires MODE C (compressed), which is a simple repeated-byte-packing algorithm. I checked radc-tops20's FTP server as well as several flavors of Unix FTP servers, and none of them support Compressed mode... :-( Russ, I am happy to say that this is WRONG!! All that is required to send Restart Markers is Block Mode, which is a trivial byte count header shlunked into the stream whenever the sender feels like it ... eg when it wants to send a Restart Marker. Bob Braden
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 04:36:05 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip Subject: Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
Speaking of FTP, has anyone implemented RESTart? Restart requires MODE C (compressed), which is a simple repeated-byte-packing algorithm. I checked radc-tops20's FTP server as well as several flavors of Unix FTP servers, and none of them support Compressed mode... :-( Several times I have gotten part of a .5 Megabyte file, and REST would have been a *real* big help. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) "I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her Christmas present of a whale "adoption" certificate. Bless her liberal heart.
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 20:56:00 PST From: art@sage.acc.com To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Re: IP over X.25 (request for info)
>Paul, >After the VC is established, the first packet over the link is an IP >packet containing source/destination IP addresses and, probably, a TCP >SYN packet or a UDP packet. Won't the Source/Dest address in the >first IP packet be sufficient or have I missed some initialization >problem on the receiving end? > >Vint Cerf Vint, Unfortunately, the Source address in the IP packet may have little relation to the X.121 address at the other end of the VC. If there is at least one gateway between the local machine and the remote machine, the virtual circuit really exists as a logical level 2 connection between the local machine and gateway. It's probably better to translate from the X.121 calling address to an associated IP address. The IETF Performance Working Group has been working on a paper that covers, amoung other things, issues around SVC management for IP over X.25. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 23:07:36 GMT From: guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) To: comp.protocols.tcp-ip Subject: Extended internet model
Recently, I completed a "revision" of a tech report called "Towards a Framework for High Speed Communication in a Heterogenous Networking Environment." I think it may be of interest to people on this list. If you want a copy, please send me a note, and I'll try to send it out asap. BTW, it is going to be published in the proceedings of IEEE INFOCOM'89. So you can wait until then. DISCLAIMER: One of the reviewers thought it is too early to be writing a paper based on these ideas, whereas other reviewers thought it has good ideas about the functionality expected of future internet. -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net Campus Box 1045, Bryan 509 One Brookings Drive St. Louis MO 63130-4899 (314) 889-4621 Here is an intro to the paper. ------------------------------------------------------------------------------ Towards to a Framework for High Speed Communication in Heterogeneous Networking Environment Guru Parulkar Jon Turner Department of Computer Science Washington University in St. Louis In this paper we attempt to formulate a framework for high speed communication in an environment comprising a mix of subnetworks with widely varying characteristics. Recent work on high speed wide area packet switching systems is expected to lead to the development of large public networks capable of supporting applications ranging from low speed data to voice, high speed data and video. If such networks are to realize their full potential, they must be designed to operate in an environment that includes networks with widely varying characteristics. Since the early seventies, much of the work on computer communication has been directed toward the development of protocols that allow interworking among computers, operating systems and communication subnetworks of different types. These efforts have culminated in the \Arpa\ Internet Protocol Suite which has introduced a number of ideas of fundamental importance. Since the development of the internet protocols, the technological context in which we find ourselves has changed dramatically. The development of high speed \Lan s and workstations, and the growing role of supercomputers in scientific computing have led to new and largely unfulfilled requirements for high speed computer communication. These needs have been difficult to satisfy for a combination of reasons. First, existing wide-area computer networks have been unable to support the data rates required and second, the existing end-to-end protocols and host computers are unable to deliver the data to the application at those rates. On the other hand, fiber optic transmission systems are being introduced rapidly into the national communications infrastructure offering vast amounts of bandwidth at fairly modest costs. Several research groups at industrial and academic laboratories around the world have demonstrated that new high speed packet switching techniques can make these resources available in a flexible fashion, but up to now these groups have failed to consider the need to operate in a complex networking environment consisting of autonomous and/or technologically dissimilar subnetworks. We feel that it is important to recognize that this kind of heterogeneous environment is here to stay and if we are to make the best possible use of new developments in networking, we need to establish a framework that supports such diversity. In this paper we attempt to address these issues. We first provide some background on both the current internet model and high speed packet switching. We then outline the major elements of an extended internet model that allows interworking of new high speed packet networks with a wide range of other networks, including current data networks and national telephone networks. Finally, we discuss some end-to-end and host interface issues.
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 4 Feb 89 23:42:00 GMT From: guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) To: comp.protocols.tcp-ip Subject: ICC'90 - Session on High Speed Internetworking and Gateway Arch
I am considering organizing a technical session for SUPERCOMM ICC'90 on "High Speed Internetworking and Gateway Architectures". The conference will be held in in Atlanta Georgia during April 16-19 1990. I would like to invite you to submit a paper to this session. Please let me know if you would like to. Of course, I can send you more information if you haven't seen the announcement yet. I am enclosing the note that I sent to conference organizers about this session. Thanks. -guru Dr. Guru Parulkar Asst Professor guru@flora.wustl.edu Dept of Computer Science parulkar@udel.edu Washington University wucs1!guru@uunet.uu.net Campus Box 1045, Bryan 509 One Brookings Drive St. Louis MO 63130-4899 (314) 889-4621 ------------------------------------------------------------------------ High Speed Internetworking and Gateway Architectures Dr. Guru Parulkar Dept of Computer Science Washington University in St. Louis This session will serve as an excellent platform for presenting research on the issues related to the next generation internetworking and gateway architectures. A new model for internetworking has been motivated in part by recent work on high speed packet switching and in part by the limitations of ARPA Internet model in supporting guaranteed levels of performance to a number of applications. The work on high speed packet switching is expected to lead to the development of large public networks capable of supporting applications ranging from low speed data to voice, high speed data and video. If such networks are to realize their full potential, they must be designed to operate in an environment that includes networks with widely varying characteristics. The internet model based on the ARPA Internet has worked well for internetworking of the first generation networks, but is not appropriate for the internetworking of newer high speed networks for a variety of reasons. Thus, there is a need to address the issues related to the interplay of component networks' diversity and our ability to support a variety of applications with guaranteed levels of performance in the next generation internet. Some of the topics that will be covered by papers in this session include: - model for the next generation internet: connectionless and connection-oriented transport facility, addressing model, diversity of component networks, functionality expected of component networks, routing model, etc. - design and specification of a connection-oriented internet protocol which can work well with the emerging high speed networks as well as with the existing neworks. - design of gateway architectures for high speed networks based on the lessons of high speed packet switches - resource management in an internet of diverse networks to provide variable grade performance with guarantees
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 02:45:36 GMT From: nelson@SUN.SOE.CLARKSON.EDU (Russ Nelson) To: comp.protocols.tcp-ip Subject: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
I went back to the hosts that I looked at for MODE C to see if MODE B would work. They all say "We only support stream mode, sorry". However, Bob *is* right, I misread the RFC, Compressed or Block mode will do. Let me ask the more experienced people on the net: Which do we need first? Chickens (clients that implement MODE and REST) or Eggs (servers that ...) I suspect that modifying the freely copyable Berkeley ftp and ftpd would go a long way to making REST implementation universal. Is anyone volunteering or am I volunteering by bringing the issue up? :-) -russ
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 03:17:27 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Packet Driver version of NCSA Telnet 2.2 is now Available
In article <8902041218.AA06180@ucbvax.Berkeley.EDU> bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) writes: The best new feature in this version is support for the Packet Driver interface (from FTP Software). Some packet drivers are available from grape.ecs.clarkson.edu in the file comm/drivers.arc Actually, the packet drivers are in /c/files/uploads, but since grape has not been providing the best service lately, I'll convince Brad to put the latest and greatest packet drivers on omnigate.clarkson.edu. We have freely copyable packet drivers for the ni5210, ni5010, 3c501, wd8003e, and SLIP8250. .ASM source is included, and all the functions that are common to all the drivers has been split out. I encourage anyone who writes a packet driver to send a copy to me so that I can distribute it with the rest of the packet drivers. I am also offering to write a packet driver for any Ethernet card(s) donated to Clarkson University. We have PCs, ATs, and PS/2s. This driver(s) will be freely copyable, of course. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) "I saved the whales!" - Rebecca L. Nelson, 3.5 years old, on receiving her Christmas present of a whale "adoption" certificate. Bless her liberal heart.
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 04:56:00 GMT From: art@SAGE.ACC.COM To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
>Paul, >After the VC is established, the first packet over the link is an IP >packet containing source/destination IP addresses and, probably, a TCP >SYN packet or a UDP packet. Won't the Source/Dest address in the >first IP packet be sufficient or have I missed some initialization >problem on the receiving end? > >Vint Cerf Vint, Unfortunately, the Source address in the IP packet may have little relation to the X.121 address at the other end of the VC. If there is at least one gateway between the local machine and the remote machine, the virtual circuit really exists as a logical level 2 connection between the local machine and gateway. It's probably better to translate from the X.121 calling address to an associated IP address. The IETF Performance Working Group has been working on a paper that covers, amoung other things, issues around SVC management for IP over X.25. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1989 12:22-EST From: CERF@A.ISI.EDU To: VAF@SCORE.STANFORD.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Internet commercial uses policy?
Vince, The "bounds of usage" question is being reviewed by the government sponsors of the Internet - We should be getting some guidance soon. Vint
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1989 12:53-EST From: CERF@A.ISI.EDU To: munnari!murtoa.cs.mu.oz.au!wcc!latcs1!ditmela!smart@UUNET.UU.NET Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Interactive game playing over an internet network
There have been some interesting dynamic games run on low-delay nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember the names - one involved a chase though a maze of corridors and you got zapped if a big, CBS-like EYE was caught staring at you - your opponent). What might be interesting is a delayed/deferred kind of game which you could essentially join or leave at any time, catch up on, as in computer-based teleconferencing, etc. Maybe some sort of group adventure? I suppose some board games would work if the delays were reasonably short. Chess obviously works fine in delayed mode. Vint
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 1989 15:37-EST From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: X.25 and IP
Art, Now I am confused. Two cases: 1. no gateways intervene 2. one or more gateways intervene between source and destination. In the first case, the source needs to initiate an X.25 VC to the destination. Given the IP destination address, known to the source, the source must translate from IP destination to comparable X.121 address. This is going to have to be either straight table look-up or algorithmic (mapping of a 32 IP address into an X.121 address - non-trivial in most cases). The receiving host will get a call set-up packet at the X.25 level which contains at least the source X.121 address. For this special case, one might be able to map from the source X.121 address in the X.25 call set-up packet to the source IP address, but this seems unnecessary since the arriving IP packet coming on the set-up link will contain source and destination IP addresses. Are you trying to bind the call set-up to a particular service process before finding out the originating IP source address? In the second case, as you point out, the calling address of the final X.25 call set-up may bear no relationship to the source IP address of the caller since the last VC is between a gateway andthe target host, not between the source host and thetarget host. That being the case, it doesn't seem possible to try to map the calling X.121 address into a source IP address at all. I have the continuing feeling that I have not understood the problem originally posed since I'm not able to make sense of your most recent answer. Vint
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 16:57:57 GMT From: kre@cs.mu.oz.au (Robert Elz) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
In article <220@cutter.nbi.com>, chm@nbires.nbi.com (Paul Chmielewski) writes: > Is there a standard mechanism for telling the called end > of a virtual circuit what the internet address of the calling host is? I doubt that looking at the address on the first datagram is the right way, that may have come from anywhere, and just happens to be being routed through this X.25 connection (the calling site may have restrictions on for whom it will forward datagrams over x.25, but then again, it also might not). A useful question might be "Do you care?" I think not, datagrams arrive over the link, they carry source addresses, the address of the particular site at the other end of the link shouldn't matter much. When you come to sending out a datagram, you need (somehow) to translate the IP address to a DTE address - you have to be able to do this to cope with the case where your end initiates the connection anyway. Its likely that this translation will produce the same DTE address as was in the "calling address" x.25 field in the initial call packet. In that case, you can send your datagram(s) back out over this same call (if its still active). kre
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 17:22:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Internet commercial uses policy?
Vince, The "bounds of usage" question is being reviewed by the government sponsors of the Internet - We should be getting some guidance soon. Vint
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 17:52:22 GMT From: cheriton@PESCADERO.STANFORD.EDU (David Cheriton) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
VMTP (RFC 1045) is intended support the type of communication required for distributed games (as well as other uses). We are in the middle of modifying mazewars to use VMTP and IP multicast, and will announce it when available. We are not planning to solve all the directory issues raised by needing to register games, locate a particular game, etc. I think a network directory service that could record this information is the major missing piece. X.500? David Cheriton
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 17:53:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
There have been some interesting dynamic games run on low-delay nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember the names - one involved a chase though a maze of corridors and you got zapped if a big, CBS-like EYE was caught staring at you - your opponent). What might be interesting is a delayed/deferred kind of game which you could essentially join or leave at any time, catch up on, as in computer-based teleconferencing, etc. Maybe some sort of group adventure? I suppose some board games would work if the delays were reasonably short. Chess obviously works fine in delayed mode. Vint
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 18:10:58 GMT From: david@ms.uky.edu (David Herron -- One of the vertebrae) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
Ah, but there are some such games. For instance, empire.
In any case, my impression is that not much noise is made lest management
take a dim view of this sort of use of the network.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<-- Stop! Wait! I didn't mean to!
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 18:32:34 GMT From: dwaitzma@bbn.com (David Waitzman) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
In article <4051@ditmela.oz> smart@ditmela.UUCP (Robert Smart) writes: >I am amazed that there don't seem to be protocols and programs for >supporting game playing over an internet network. The sort of thing I >envisage would allow a client program to connect to a game control >server. They could then start a game, or join an existing game. The >protocol would include the ability to send move information to the >control server, receive state-of-game information from the control >... >Anybody else interested? Any existing work? Should we write an RFC? >... May I suggest that new work in this area exploit IP Multicasting? Many-player games (and conferences) certainly could use multicasting, and multicasting certainly could use games to become more widely valued. Please see RFC-1054 and RFC-1075 for more information. thank you, -david (dwaitzman@bbn.com)
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 20:37:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: X.25 and IP
Art, Now I am confused. Two cases: 1. no gateways intervene 2. one or more gateways intervene between source and destination. In the first case, the source needs to initiate an X.25 VC to the destination. Given the IP destination address, known to the source, the source must translate from IP destination to comparable X.121 address. This is going to have to be either straight table look-up or algorithmic (mapping of a 32 IP address into an X.121 address - non-trivial in most cases). The receiving host will get a call set-up packet at the X.25 level which contains at least the source X.121 address. For this special case, one might be able to map from the source X.121 address in the X.25 call set-up packet to the source IP address, but this seems unnecessary since the arriving IP packet coming on the set-up link will contain source and destination IP addresses. Are you trying to bind the call set-up to a particular service process before finding out the originating IP source address? In the second case, as you point out, the calling address of the final X.25 call set-up may bear no relationship to the source IP address of the caller since the last VC is between a gateway andthe target host, not between the source host and thetarget host. That being the case, it doesn't seem possible to try to map the calling X.121 address into a source IP address at all. I have the continuing feeling that I have not understood the problem originally posed since I'm not able to make sense of your most recent answer. Vint
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 21:38:33 GMT From: jg@jumbo.dec.com (Jim Gettys) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
In article <[A.ISI.EDU].5-Feb-89.12:53:46.CERF> CERF@A.ISI.EDU writes: >There have been some interesting dynamic games run on low-delay >nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember >the names - one involved a chase though a maze of corridors >and you got zapped if a big, CBS-like EYE was caught staring at >you - your opponent). There are quite a few such games for X these days, including a re-implementation of MAZEWAR (which actually precedes XEROX PARC; I played it in 1972 or 1973 at MIT on IMLAC displays). The possibly dubious claim was made to me that it had been banned from the Internet because of excessive use between MIT and Stanford, which was skewing network use statistics. (Maybe someone out there actually knows....). There is also xtrek, and at least one other empire like game, which are network based. Only mazewar is really distributed; the others involve invoking a single server which then use multiple machines for display, which X facilitates. I guess I know X has succeeded by the proliferation of games for it... :-) Jim Gettys
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 23:07:24 GMT From: VAF@SCORE.STANFORD.EDU (Vince Fuller) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
The two most memorable games from the Xerox PUP days were MazeWar (which Vint Cerf described) and AltoTrek, in which you controlled a ship on one of three teams and went around blasting members of the other teams and planting your bases around various planets (which could later be used for purposes such as spying and self-distruction, if other players approached). Xtrek is a game similar to AltoTrek which is implemented using the X protocol (which is layered over TCP/IP) and I believe an almost identical copy of MazeWar has also been implemented using X. I believe there are also others of this sort: Xtank and Xconq (multi-player Empire), though I haven't seen them myself. --Vince -------
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 23:38:22 GMT From: vjs@rhyolite.SGI.COM (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
In article <4051@ditmela.oz>, smart@ditmela.oz (Robert Smart) writes: > I am amazed that there don't seem to be protocols and programs for > supporting game playing over an internet network.... > Anybody else interested? Any existing work? Should we write an RFC? > > Bob Smart, CSIRO Division of Information Technology, Australia > smart@ditmelb.oz.au (or smart%ditmelb.oz.au@uunet.uu.net) A standard would be nice. It should support not only "low-speed" games such as chess or bridge, but also those which require at least a couple dozen updates/second, such as Silicon Graphics' "arena" and "dogfight." "Dogfight" has been a very useful tool for these past several years. It has sold lots of systems, and, since it was converted from XNS-multicast to UDP-broadcast, killed a number of obsolete machines which happened to be on the same networks. (We're working on IP-multicast so "dog" can get across gateways as well as be friendlier to old stuff.) Vernon Schryver Silicon Graphics vjs@sgi.com
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 5 Feb 89 23:38:37 GMT From: philipp@physicsa.mcgill.ca (Philip Prindeville Comp Ctr) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
I would be more inclined to think of something like Project Athena's Zephyr notification system, but that could be out of lack of respect for X.500. See the Winter 1988 Usenet proceedings for a description or ftp it from athena-dist.mit.edu, in pub/usenet (I think)... -Philip
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 08:17:00 PST From: art@sage.acc.com To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: More on IP over X.25
Vint, Remember that level 2 does not really care about the ultimate destination, only the "next-hop" IP address (which could also be the destination). In most cases what X.25 needs to do is to translate the the IP address OF THE GATEWAY into an X.121 address. If an X.25 Call is received from a gateway (or host), one can translate from the Calling X.121 address to an IP address, so that the next time a packet needs to make that hop, it can use the same SVC. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Mon, 06 Feb 89 10:04:31 PST From: satz@cisco.com To: CERF@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: X.25 and IP
Vint, >> Now I am confused. Two cases: >> >> 1. no gateways intervene >> 2. one or more gateways intervene between source and destination. I would relabel these two cases as 1. packet sourced by host on connected subnet 2. packet sourced by host behind connected subnet (behind a router) 3. packet destined for host on connected subnet 4. packet destined for host behind connected subnet (behind a router). And, I am not sure the distinction is necessary. Since the X.25 virtual circuit source may not be from the originator but from the previous hop, you can't necessarily believe the IP source address. Also security and configuration reasons may require you to enumerate the complete list of connected hosts you will speak with. For example if you want to verify that an X.25 VC can Reverse Charge, some neighbor information will need to be preconfigured. This information is needed before the first X.25 DATA packet arrives to determine whether the VC can be accepted. The cisco implementation requires preconfigured table entries about other entities sharing the same connected subnet unless a mapping function exists (DDN or BFE). Preconfigured entries can always be used to provide additional information (such as subnet multicast). Greg
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 07:23:15 GMT From: mah@hpuviea.UUCP (Michael Haberler) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
From article <6402@blia.BLI.COM>, by ted@blia.BLI.COM (Ted Marshall): > > I have heard that HP's TCP/IP implementation, when sending over Ethernet, > uses IEEE802.3 data link format (i.e. packet length, SSAP and DSAP) > instead of Ethernet V2 format (i.e. protocol type) like most Unixes. ^^^^^^^^^^ replace by 'and'. All HP 9000 series 300 and 800 talk both. The HP 3000 series currently only speak IEEE802.3. > Can anyone confirm or deny this? Specifically, I need to know if one > can put an HP machine and one of our own boxes (which will only speak > Ethernet V2 format) on an Ethernet and have them communicate. You wont have any problems with the default setup, which is to talk both protocols concurrently. -michael -- Michael Haberler mah@hpuviea.uucp Hewlett-Packard Austria GmbH, ...mcvax!tuvie!hpuviea!mah Lieblgasse 1 ...hplabs!hpfcla!hpbbn!hpuviea!mah A-1220 Vienna, Austria Tel: (0043) (222) 2500 x412 (9-18 CET)
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 16:17:00 GMT From: art@SAGE.ACC.COM To: comp.protocols.tcp-ip Subject: More on IP over X.25
Vint, Remember that level 2 does not really care about the ultimate destination, only the "next-hop" IP address (which could also be the destination). In most cases what X.25 needs to do is to translate the the IP address OF THE GATEWAY into an X.121 address. If an X.25 Call is received from a gateway (or host), one can translate from the Calling X.121 address to an IP address, so that the next time a packet needs to make that hop, it can use the same SVC. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 16:36:02 GMT From: bzs@pinocchio.UUCP (Barry Shein) To: comp.protocols.tcp-ip Subject: FTP "STRU VMS" extension
What I don't understand is why this isn't taken care of extra-FTP by some sort of archiving utility like tar. How does one transfer ISAM (eg.) files by tape between VMS systems? Why can't a similar mechanism be used? The obvious advantage is that such representations should even work when one wants to push such files through third-party, non-VMS systems since all the info to re-create the file gets bundled into the transferred file itself rather than relying on wire transmission as server/client commands. It wouldn't really occur to me to ask for an extension to FTP to transfer an arbitrary file tree between Unix's (for example), I'd just bundle it up with tar and send *that* (possibly compressing and/or uuencoding if need be.) In fact, that's SOP. At best I could imagine some sugar in the VMS server/clients which might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command, send the result of that, and if the other side is a VMS site he'll recognize the header and automatically do the opposite", but none of that needs a change in the protocol spec since it only affects the OS interface, not the network interface (the file would just be xferred binary I'd guess.) Personally I hate that kind of magic. No FTP extensions should be needed (eg. something like embedding UNIX magic numbers should do it.) And again, if the other side wasn't a VMS site it would work also (that is, would store the file image but make no attempt to unpack it.) A good example of the utility of this approach is putting VMS files for Anonymous FTP onto a non-VMS system. Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc have been using for years? -Barry Shein, ||Encore||
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 17:00:58 GMT From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) To: comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: ATT 3b2/400 and TCP/IP
The Wollongong Group does TCP/IP products for 3B2s running SysV. We're running it under SysVRel3.[02].
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 18:04:31 GMT From: satz@CISCO.COM To: comp.protocols.tcp-ip Subject: Re: X.25 and IP
Vint, >> Now I am confused. Two cases: >> >> 1. no gateways intervene >> 2. one or more gateways intervene between source and destination. I would relabel these two cases as 1. packet sourced by host on connected subnet 2. packet sourced by host behind connected subnet (behind a router) 3. packet destined for host on connected subnet 4. packet destined for host behind connected subnet (behind a router). And, I am not sure the distinction is necessary. Since the X.25 virtual circuit source may not be from the originator but from the previous hop, you can't necessarily believe the IP source address. Also security and configuration reasons may require you to enumerate the complete list of connected hosts you will speak with. For example if you want to verify that an X.25 VC can Reverse Charge, some neighbor information will need to be preconfigured. This information is needed before the first X.25 DATA packet arrives to determine whether the VC can be accepted. The cisco implementation requires preconfigured table entries about other entities sharing the same connected subnet unless a mapping function exists (DDN or BFE). Preconfigured entries can always be used to provide additional information (such as subnet multicast). Greg
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 19:15:00 GMT From: jpederse@encad.Wichita.NCR.COM (John Pedersen) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: netbios over tcp-ip
In article <23313@beta.lanl.gov> ddk@beta.lanl.gov (David D Kaas) writes: |>Are there any hardware/software |>systems available to allow connections between these protocols? |>Any boards to insert in a UNIX workstation or IBM PC/AT/2 that |>will run both protocols? I have a 3C505 with NRC's dual protocol software here but haven't loaded it up to try it. It supposedly allows both protocols to exist on the same board at the same time. -- John Pedersen, Project Leader N5DKQ NCR Engineering & Manufacturing Engineering Computer Support Services 3718 N. Rock Road John.Pedersen@wichita.NCR.Com Wichita KS 67226 316-636-8837 FAX 316-636-8889
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 19:39:43 GMT From: wunder@HP-SDE.SDE.HP.COM (Walter Underwood) To: comp.protocols.tcp-ip Subject: Re: Re: IP Encapsulation on HP 3000/9000 computers
OK, here is the real story. I work for HP, and this information is from recent printed information announcing new products. Up to now, the HP3000 has only used 802.3 encapsulation with the old IP-over-802.3 standard. This was done in the naive expectation that an official standard was the right way to go. Anyway, with the V-Delta-5 release of MPE for the "classic" HP3000, Ethernet and ARP are supported. It has TCP/IP of course, and there are two sets of services available: the NS services, which are HP proprietary and tweaked for the 3000 (sort of like STRU VMS, but not based on FTP), avalable from HP; and regular ARPA services (Telnet, FTP, and SMTP), available from The Wollongong Group. The HP3000 can also talk IP over X.25 links, but I'm not sure of the exact encapsulation for that. The HP3000 does not have UDP. The Precsion Architecture HP3000 (OS is MPE/XL, machines are HP3000/935, HP3000/950, etc.) has TCP/IP and the NS services, but does not have ARPA services or Ethernet/ARP. Ethernet/ARP is promised, though I don't know which release, and I don't know whether we have promised ARPA services. The HP9000 (Unix) systems, both Motorola and Precision Architecture (aka "Spectrum") have ARPA, Berkeley, and NS services; TCP/IP; Ethernet and 802.3 (old); IP-over-X.25 (DDN, I think, s800 only?); and soon, Jacobson/Karels TCP, BIND (supported), and probably other stuff. The HP1000 has TCP/IP, NS services, and 802.3 (old). We resell FTP Software, Inc.'s PC/FTP for the HP Vectra PC's as PC/ARPA. I don't know whether 802.3/SNAP is planned for any of our systems. Clear? Walter Underwood HP Software Engineering Systems PS: I think that the Wollongong product for the HP3000 is called WIN/H3000 (is that right, Dave?). Also, the HP3000 *always* talks half-duplex to its terminals, so client Telnet can be aggravating if you are talking to a full-duplex application.
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 20:26:00 GMT From: berger@clio.las.uiuc.edu To: comp.protocols.tcp-ip Subject: Re: Internet commercial uses policy?
Isn't there a better place to discuss this? I have the opposite
concern - that some users are trying to force all others to conform
to the lowest common denominator of service ("since I have to pay
per byte, YOU should limit what you write").
Mike Berger
Department of Statistics
University of Illinois
berger@clio.las.uiuc.edu
{convex | pur-ee}!uiucuxc!clio!berger
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 22:12:33 GMT From: kent@WSL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
There have been some interesting dynamic games run on low-delay nets, mostly LANs (e.g. XEROX PARC has several, but I don't remember the names - one involved a chase though a maze of corridors and you got zapped if a big, CBS-like EYE was caught staring at you - your opponent). I ported Mazewar to X and UDP a while back. Other people have built distributed games on top of IP (xtrek and xconq come to mind). I'm not sure that a centralized server/protocol would have done me a lot of good -- there's a lot of traffic and the extra hops can become significant. In Mazewar, one of the games acts as a central server for people who join the game and does "rebroadcast" of some of the packets, but there are also some short circuits for efficiency. I only use broadcasts to try to find an existing game. Of course, if there had been an existing protocol implementation, I might have built on top of it, and not noticed any loss in game responsiveness. What might be interesting is a delayed/deferred kind of game which you could essentially join or leave at any time, catch up on, as in computer-based teleconferencing, etc. Maybe some sort of group adventure? This sort of game has been built, too. Peter Langston's empire for Unix, built starting in the late 70s, has contributed to more than one academic suicide. (it's a highly detailed world conquest game, based on a board game played at Reed College.) I've lost track of the game in recent years, but he developed it actively for quite some time. As many as 20 players could play in a single game, playing moves when they wished. Games sometimes lasted weeks on end... chris
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 6 Feb 89 23:43:17 GMT From: lance@hermix.UUCP (Lance Ellinghouse) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Printing over LAN
I have a LAN set up with a Xenix server running TCP/IP with ~ 14 PC's running DOS. We do a lot of graphic developement on the DOS machines and we would like to print them out on the laser printer on the Xenix server. What we would like to do is do it either by a batch script or by direct command. We have only telnet and ftp available for use. If anyone out in net land knows how we can do this with minimal cost please email me!! Lance Ellinghouse Mark V Systems -- Lance Ellinghouse Mark V Systems, Ltd. UUCP: ...!hermix!lance ARPA: ucla-an!hermix!lance@ee.UCLA.EDU
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 00:33:39 GMT From: klaas@hpindda.HP.COM (Darin J Klaas) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
/ hpindda:comp.protocols.tcp-ip / stev@VAX.FTP.COM / 10:11 am Feb 3, 1989 /
> i believe that only the 3000 is like this. i thought that the 9000
> could speak this "special IP" to act as a gateway. i was also under the
> impression that it wasnt even "real" ehternet based IP they were using,
> they didnt use ARP or something.
> i am sure someone from HP will set us all straight, though . . . .
> stev knowles
> ftp software
> ----------
To rescue HP's reputation ... (:-)
The Series 9000's can talk either ethernet or 803.3; its a configurable
on a per interface basis. The ethernet is standard ethernet, nothing
special. You can even configure it to talk both on the same interface.
Beware that currently HP-UX will prefer to talk 802.3 over ethernet if
given the choice.
The series 3000's are a different story; they talk 802.3 exclusively,
although I've heard that straight ARP and ethernet are coming to
a MPE system near you soon.
In either case, if you wish to talk 802.3 to an HP machine, you must use
HP's proprietary address resolution protocol, Probe ; ethernet uses ARP.
/ hpindda:comp.protocols.tcp-ip / medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) / 11:03 am Feb 3, 1989 /
> An even better solution is to throw away HP-UX, and run 4.3 BSD on your
> 9000 series. Then you get full 4.3 networking code, and all the other things
> 4.3 gives you that HP-UX doesn't. It works quite well, and you
> can get from the folks at Utah. Maybe one of them would like to send
> out information on how to get the distribution.
>
> Some people STILL don't understand that people buy Unix systems for
> compatibility and portability. Sigh...
>
> Thanks,
> Milo
We've heard this over and over again, and we are working toward a resolution.
Many people at HP DO realize that compatability is of utmost importance.
Stay tuned ...
-- darin klaas
klaas@hpda
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 07:02:00 EST From: "BURKE D.N." <burke@nusc-npt.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: TCP-IP IMPLEMENTATION UNDER XENIX
does anyone know of a tcp-ip implementation that runs under xenix, and supports a 3COM ethernet card? (preferably public domain) Dave Burke Aquidneck Data Corporation (Sub. of Kodak)
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 05:09:42 GMT From: minshall@VIOLET.BERKELEY.EDU To: comp.protocols.tcp-ip Subject: Re: tn3270
There is a new "bug fix" version of tn3270 - 4.1.1. This supercedes version 4.1 (released December, 1988). The files are on ucbarpa.berkeley.edu in the directory pub/tn3270. The file 4.1TO4.1.1diffs.Z contains a set of diff's which will bring a 4.1 release up to a 4.1.1 system (at least in all important aspects). This includes three new versions of the man pages and a newer version of /etc/map3270. The file tn3270.4.1.1.tar.Z is the new release. The main fix is to telnet.c - to notice that we have negotiated out of a mode (for UCLA-based MVS systems mostly - but also for protocol correctness). Other changes include some more byte ordering considerations, eliminating some unused macros from screen.h, checking the parameters to the 3270 orders RA and EUA (and bailing out if the parameters are bad - 3270 programmers beware!), tolerating the Gould C compiler, and making sure that debugging information actually gets out (even if the programs dumps core or goes into a loop). A note to "by mail" customers: I apologize to those who have ordered their system in the last month and a half from the Campus Software Office. I have not supplied the SW office with a new master and they have thus been unable to satisfy your order. I hope to provide a new master (of 4.1.1) within the next two weeks. Thanks to all those providing such early bug reporting to my 4.1 release (and for bearing with it all). Greg Minshall
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 06:55:40 GMT From: hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
> From: DECWRL::"encore!pinocchio!bzs@talcott.harvard.edu" "Barry Shein 6-Feb-89 1136 EST" 7-FEB-1989 08:50
> To: KASHTAN@IU.AI.SRI.COM
> Subj: FTP "STRU VMS" extension
>
> Cc: braden@venera.isi.edu, tcp-ip@sri-nic.arpa
>
>
> What I don't understand is why this isn't taken care of extra-FTP by
> some sort of archiving utility like tar.
>
There certainly is. Its known as BACKUP.
> How does one transfer ISAM (eg.) files by tape between VMS systems?
> Why can't a similar mechanism be used? The obvious advantage is that
> such representations should even work when one wants to push such
> files through third-party, non-VMS systems since all the info to
> re-create the file gets bundled into the transferred file itself
> rather than relying on wire transmission as server/client commands.
>
It does work.
> It wouldn't really occur to me to ask for an extension to FTP to
> transfer an arbitrary file tree between Unix's (for example), I'd just
> bundle it up with tar and send *that* (possibly compressing and/or
> uuencoding if need be.) In fact, that's SOP.
>
The reason is UNIX (I'm sorry) has a very simple file system and
structure. Correct me if I'm wrong but a UNIX file can be safely treated
as a binary byte stream, isn't that so?
> At best I could imagine some sugar in the VMS server/clients which
> might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
> send the result of that, and if the other side is a VMS site he'll
> recognize the header and automatically do the opposite", but none of
> that needs a change in the protocol spec since it only affects the OS
> interface, not the network interface (the file would just be xferred
> binary I'd guess.) Personally I hate that kind of magic.
>
> No FTP extensions should be needed (eg. something like embedding UNIX
> magic numbers should do it.) And again, if the other side wasn't a VMS
> site it would work also (that is, would store the file image but make
> no attempt to unpack it.) A good example of the utility of this
> approach is putting VMS files for Anonymous FTP onto a non-VMS system.
>
> Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
> have been using for years?
>
> -Barry Shein, ||Encore||
What Kenneth was asking for is an intelligent option where a VMS
implementation of FTP will attempt to establish that fact to its
counterpart. And if both parties are VAX/VMS then hey we can do things a
lot faster and cheaper since we have some "mutual understanding". If
not, then too bad, its back to the "standard FTP". Ken is trying to
establish a standard for this "mutual understanding" among VMS/FTP ONLY.
Your suggestion regarding the use of archival facility (ie BACKUP) as a
pre-post processor is of course valid. But as some one else has
mentioned, that pre-post processor takes time (cpu) and resources (read
disk space). On VMS systems, disk quota are tightly controlled and if
you don't have enough, its No Can Do. Eg if you retrieve a 1000 blocks
archive file (in VMS its called a backup saveset), you need to have 2500
blocks (1000 to keep the saveset, at least temporarily, and another
1000+ for the files that will be extracted from the save set).
For a long time, I was using Kermit to transfer files between 2 VAXes
that weren't on the same DECnet. Now to transfer an indexed (read ISAM)
file or a directory tree, I had to back it up then send it through
Kermit in binary, and then restore it on my end. As I said, diskquota
control can be a real restriction. (Most of the place wouldn't simply
give you more disk space you know, you have to ask and justify for it).
Besides there's the hassle of backing up the files and then restoring
it. Not only that, efficiency on the wire suffers because BACKUP
(unlike TAR) impose substantial overhead as it will keep lots of extra
information about the files. This is to allow the recovery of data even
when the saveset has some corruptions. Although I don't use much of
UNIX, I know TAR's internal very well. It is nowhere compared to BACKUP,
sort of comparing a Toyota to a Jaguar.
Ken, I am in favour of your STRU O VMS option. In which case, all OS can
have such an option .. STRU O MVS, STRU O U43, STRU O EMBOS...
It does nothing to harm interoperability, as far as I can see. Its what
the real world needed, if there's no standard then it'll just be
non-standard features, so why not standardize it and make everybody
happy?
Rgds,
Choy Heng Wah
Software Specialist
._._._._._._._.
|d|i|g|i|t|a|l| Digital Equipment Singapore
._._._._._._._.
Disclaimer : What I express here is purely my own opinion and does not
represent any policy of Digital Equipment Corp and its
subsidiaries ... blah blah blah ...
EASYnet : {zposws|zpovc|zpoact}::hwchoy
InterNET : hwchoy%zpovc.dec@decwrl.dec.com
<@decwrl.dec.com:hwchoy@zpovc.dec.com> <-- source route addressing
hwchoy@zpovc.dec.com
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Feb 89 14:43:21 EST From: Brad Clements <bkc@omnigate.clarkson.edu> To: pcip@twg.com Cc: tcp-ip@sri-nic.arpa Subject: How to get NCSA Telnet version 2.2C via E-mail
Previous directions on how to retrieve version 2.2C of NCSA Telnet via the mail archiver were incorrect. To get a uuencoded compressed tar file of the binaries, do the following: % mail archive-server@sun.soe.clarkson.edu Subject: path <your return address goes here> send ncsa2.2c ncsabin.tar.Z.uuaa ^D Then send a second mail message that is identical, except substitute send ncsa2.2c ncsabin.tar.Z.uubb (each file is approximately 100K long) The path statement should be whatever address you want the file sent to (presumably your own E-mail address) You can get the modified ascii documentation by sending the following command to the archive-server: send ncsa2.2c PCtelnet2.2c.ascii As mentioned previously, the binaries, source and documentation is available via anonymous ftp from omnigate.clarkson.edu from the directory pub/ncsa2.2c Some packet drivers have also been added to the ncsa2.2c directory on omnigate, or You can get packet drivers (and source) via mail by using the following command: % mail archive-server@sun.soe.clarkson.edu Subject: path <your return address goes here> send ka9q drivers01 drivers02 drivers03 (You can also send seperate messages to the archive server, requesting one driver file at a time, otherwise all three files will be sent as one message, which may be too long for your mailer to handle) The binaries on sun.soe.clarkson.edu, and omnigate.clarkson.edu have been changed as of 14:30 EST 2/7/89. These new binaries fix a bug in the NLST command of the ftp server, which would cause mget's to fail. A fixed source module (bkgr.c) is also available via ftp from omnigate. The old source tar file has not been updated. bugs, comments to bkc@omnigate.clarkson.edu
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 10:13:13 GMT From: prinz@gmdzi.UUCP (Wolfgang Prinz) To: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Network Security
From article <9424@pasteur.Berkeley.EDU>, by vincent@zubenelgenubi.uucp: > I am working on a network security project and am looking for pointers > to papers, books .... etc or your own comments and views. > More specifically, I'm looking at > security measures at both hardware and network layer level. > > Thanks. > Vincent. You might find some interesting articels in: Computer and Network Security, M.D. Abrams and H.J. Podell IEEE Computer Society Press regards Wolfgang
-----------[000101][next][prev][last][first]----------------------------------------------------
Date: 7 Feb 89 12:02:00 GMT
From: burke@NUSC.ARPA ("BURKE D.N.")
To: comp.protocols.tcp-ip
Subject: TCP-IP IMPLEMENTATION UNDER XENIXdoes anyone know of a tcp-ip implementation that runs under xenix, and supports a 3COM ethernet card? (preferably public domain) Dave Burke Aquidneck Data Corporation (Sub. of Kodak)
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 14:59:55 GMT From: keith@SPIDER.CO.UK (Keith Mitchell) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
I am nearing completion of a Unix V.3 STREAMS-based implementation of IP over X.25, which is part of our SpiderTCP and SpiderX.25 protocol software products. We call it IXE (IP/X.25 Encapsulation). It fits into the STREAMS protocol stack as a multiplexing driver underneath IP and above our X.25 stack. It conforms fully to the rather skimpy RFC 877 spec, and although at present it will only work with CCITT-flavour X.25 PDNs, DDN support is on the way. (CCITT is a lot more in demand in Europe than DDN, obviously). On the other hand, it *does* work with both the 1980 and 1984 flavours of X.25. Clearing down of idle X.25 calls and pre-emption of these when resources are scarce are implemented. Address mapping for this stuff is something of an issue. At present we use a lookup table, which is the only way of really doing the job, but if you have a lot of WAN destinations to talk to then there is a danger of guzzling up lots of kernel memory. Some kind of address resolution protocol would be nice, but another way to look at it is from a security point of view. If you are connected to a public network, then anyone could call you up and claim to be some host with a remote IP address that higher- level software trusts. This leaves you wide open to spoofing by Public Data Network hackers. On the other hand, PDNs are usually set up so you can trust the X.25 calling address, so we use this to look back into the table and check that the remote IP host is who it claims to be. Using the CUDF field for address resolution does not seem like a good idea to me. I would prefer the use of X.25 facilities for this, most specifically the extended addressing one of X.25(1984). When used for the ISO CONS, this carries an NSAP. It is interesting to note that a scheme for encoding IP addresses into NSAPs already exists (RFC 986), at least for the connection-less world. Some scheme along these lines would thus bypass the need for table lookup, and I think is probably the right approach. (Again you have to trust the address you get from the PDN). It strikes me that generally RFC 877 leaves a lot of issues unanswered, and the introduction of the 1984 (and now 1988) standards for X.25 have aggravated this. Is is perhaps time for a new standard in this area ? Any such work probably ought to take into account using ISO IP (or CLNP) over X.25 circuits as well. Does anyone have any thoughts on this ? Keith Mitchell Spider Systems Ltd. Spider Systems Inc. 65 Bonnington Road 12 New England Executive Park Edinburgh, Scotland Burlington, MA 01803 +44 31-554 9424 +1 (617) 270-3510 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net keith@uk.co.spider ...!uunet!ukc!spider!keith
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 17:24:41 GMT From: dbercel@twg-ap.UUCP (Danielle S. Bercel) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
In article <8902061939.AA26324@hp-ses.sde.hp.com>, wunder@HP-SDE.SDE.HP.COM (Walter Underwood) writes: > > Walter Underwood > HP Software Engineering Systems > > PS: I think that the Wollongong product for the HP3000 is called > WIN/H3000 (is that right, Dave?). Also, the HP3000 *always* talks > half-duplex to its terminals, so client Telnet can be aggravating if > you are talking to a full-duplex application. The product is called WIN/TCP for MPE/V. Release 1.1 is available and this includes block mode support through our telnet server. The half-duplex communication in character mode is certainly not the best of circumstances and it is for this reason that the 3000 telnet client comes up in line mode. danielle bercel Project leader, WIN/TCP for MPE/V -- Danielle Bercel - Senior Software Engineer - The Wollongong Group Email: dbercel@twg-ap.com or dbercel@twg.com US Mail: 1129 San Antonio Rd. * Palo Alto, CA. 94303 * (415)962-7160
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 17:30:55 GMT From: amanda@lts.UUCP (Amanda Walker) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
bzs@pinocchio.UUCP (Barry Shein) writes:
What I don't understand is why this isn't taken care of extra-FTP by
some sort of archiving utility like tar.
[...]
It wouldn't really occur to me to ask for an extension to FTP to
transfer an arbitrary file tree between Unix's (for example), I'd just
bundle it up with tar and send *that* (possibly compressing and/or
uuencoding if need be.) In fact, that's SOP.
[...]
Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
have been using for years?
-Barry Shein, ||Encore||
I agree with Barry's philospophy. What our FTP does is to bundle up
Macintosh files into MacBinary format and send them in Image mode. If the
other machine is anything but another Macintosh, they just get stored as-is.
If the other side is a Macintosh, it says, "gee, this is a MacBinary file;
I'll unpack it." This lets you FTP applications and so on between two
Macs without any hassle. The only problem is that MacBinary is a brain-
damaged format (no magic numbers), so we add SITE commands to turn the
automatic unpacking on and off. This prevents tar files from being
falsely recognized as MacBinary and resulting in several-megabyte
invisible files full of garbage :-). Using Apple's AppleSingle &
AppleDouble formats will solve this problem in future releases.
Nopw, I must admit that this approach works best on systems where
files are basically "Streams o' Bytes" like UNIX, but I can't imagine
it would be too hard to use a variant of ANSI tape format D or something
under VMS/TOPS-20/whatever.
--
Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
I humans were meant to fly, the airlines wouldn't keep losing our luggage...
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 17:59:20 GMT From: kincl@hpiag2.iag.hp.com (Norman Kincl) To: comp.protocols.tcp-ip Subject: Re: IP Encapsulation on HP 3000/9000 computers
> HP3000 (MPE systems) currently only speak 802.2 encapsulation. A cisco box can
^^^^^^^^^
> translate from this to Ethernet encapsulation.
A correction---as of version V-Delta-5, MPE-V supports BOTH 802.3 and standard
Ethernet encapsulation. This includes ARP. As with the HP 9000, it is
transparent to botht he user and the system administrator which protocol is
being used. For MPE-XL, Ethernet compatability is a stated direction, the
schedule is under investigation.
-Norm Kincl
Information Architecture Group
Hewlett-Packard
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 18:54:53 GMT From: shaver@atanasoff.cs.iastate.edu (Dave Shaver) To: comp.protocols.tcp-ip Subject: Internet "time servers" and UNIX timed
I know that "network time servers" exist on the Internet. Here's the
list I have:
192.5.8.1 time
128.9.2.129 time1 isi
128.8.10.1 umd1 time2
128.5.0.1 ford1 time3
128.116.64.2 ncar time4
Now my question is how to use them. How does one ask any of these
machines for the correct time? On which IP port number and using what
protocol can I get the correct time? Port numbers I know of: 13, 37,
and 525 (UNIX timed). I know that you can just connet to port 13 and
read the time. What is the best way of doing this? Any help would be
appreciated.
My second problem is UNIX timed. My goal is to get the "correct" time
from a time server and then pass it out on our LAN via timed. We have
an HP 350 running HP-UX (System V/BSD "mix"). Has anyone ported
the 4.3 BSD timed to HP-UX or SYSV? (This could be hard without
the adjtime(2) system call.)
Another option would be to use something other than timed. Any other
comments or ideas are welcomed.
/\ Dave Shaver -=*=- CS Systems Support Group, Iowa State University
\\ UUCP: {hplabs!hp-lsd, uunet!umix!sharkey}!atanasoff!shaver
\/ Internet: shaver@atanasoff.cs.iastate.edu
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 19:43:21 GMT From: bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) To: comp.protocols.tcp-ip Subject: How to get NCSA Telnet version 2.2C via E-mail
Previous directions on how to retrieve version 2.2C of NCSA Telnet via the mail archiver were incorrect. To get a uuencoded compressed tar file of the binaries, do the following: % mail archive-server@sun.soe.clarkson.edu Subject: path <your return address goes here> send ncsa2.2c ncsabin.tar.Z.uuaa ^D Then send a second mail message that is identical, except substitute send ncsa2.2c ncsabin.tar.Z.uubb (each file is approximately 100K long) The path statement should be whatever address you want the file sent to (presumably your own E-mail address) You can get the modified ascii documentation by sending the following command to the archive-server: send ncsa2.2c PCtelnet2.2c.ascii As mentioned previously, the binaries, source and documentation is available via anonymous ftp from omnigate.clarkson.edu from the directory pub/ncsa2.2c Some packet drivers have also been added to the ncsa2.2c directory on omnigate, or You can get packet drivers (and source) via mail by using the following command: % mail archive-server@sun.soe.clarkson.edu Subject: path <your return address goes here> send ka9q drivers01 drivers02 drivers03 (You can also send seperate messages to the archive server, requesting one driver file at a time, otherwise all three files will be sent as one message, which may be too long for your mailer to handle) The binaries on sun.soe.clarkson.edu, and omnigate.clarkson.edu have been changed as of 14:30 EST 2/7/89. These new binaries fix a bug in the NLST command of the ftp server, which would cause mget's to fail. A fixed source module (bkgr.c) is also available via ftp from omnigate. The old source tar file has not been updated. bugs, comments to bkc@omnigate.clarkson.edu
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 22:01:38 GMT From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
>What I don't understand is why this isn't taken care of extra-FTP by >some sort of archiving utility like tar. That has, in fact, been the solution for a LONG time. Make a program that can PACK/UNPACK VMS Backup Savesets using files that can be transferred in FTP IMAGE mode. Aside from various the system administration problems that have already been enumerated there is also a psychological implication. The fewer steps you have to go through to get a file transfered the happier you are (witness the preference of "rcp" over FTP when available). There have been many times that I have used slower file transfer methods just because it was less work for me (the difference in transfer times has to be pretty significant for me to prefer the more laborious method). There is also the issue of ensuring that EVERYBODY you might want to exchange VMS files with has all the appropriate tools (isn't this what standards are for?). As a TCP vendor we are very concerned about providing MAXIMUM functionality to our customers -- and this issue is of pretty serious concern to us. So, rather than just DO something so that machines running our software can communicate in this fashion we have asked the TCP community to discuss the best way to set a standard so that we can interoperate with other VMS TCPs for this "extended" service yet still interoperate with the rest of the TCPs in the world. I feel that Ken's suggestions are a good solution to the problem (but I am obviously biased). >It wouldn't really occur to me to ask for an extension to FTP to >transfer an arbitrary file tree between Unix's (for example), I'd just >bundle it up with tar and send *that* (possibly compressing and/or >uuencoding if need be.) In fact, that's SOP. But that is just the point -- UNIX files and FTP IMAGE transfer are a good match (i.e. they give you the functionality that you need). We are looking to do something equivalent for VMS, where IMAGE transfers are not sufficient. >At best I could imagine some sugar in the VMS server/clients which >might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command, >send the result of that, and if the other side is a VMS site he'll >recognize the header and automatically do the opposite", but none of >that needs a change in the protocol spec since it only affects the OS >interface, not the network interface (the file would just be xferred >binary I'd guess.) Personally I hate that kind of magic. AHA - but now you have implied some "standard" in the FTP protocol that would allow both sides to recognize that they can do this. In fact, this is really what Ken's suggestion amounts to. >No FTP extensions should be needed (eg. something like embedding UNIX >magic numbers should do it.) And again, if the other side wasn't a VMS >site it would work also (that is, would store the file image but make >no attempt to unpack it.) A good example of the utility of this >approach is putting VMS files for Anonymous FTP onto a non-VMS system. But you would still need to know what "mode" the other side is in to correctly interoperate with it. What if you assumed that you were in "include-the-magic-number-and-transfer-the-file-transparently" mode and were talking to a "standard" FTP on the other side. What if you were transferring an ASCII file. In this case, the correct thing to do is to use the standard ASCII transfer mode. How do you recognize automagically that you should do this. Once again -- we need some sort of "standard" specified to allow the recognition that the other side can do what you want it to. David -------
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 22:06:05 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip Subject: Need help testing FTP's REST cmd.
Well, I had some work that I wanted to avoid doing, so I hacked REST and MODE B into a version of Phil Karn's NET's FTP server. However, I haven't yet added the capability of *using* REST into the FTP client. Interoperability is also desirable. So, somewhere out there is someone who has an FTP client that understands REST, MODE B, and marks. Whoever you are, will you please test the REST capability of grape.ecs.clarkson.edu [128.153.13.196]? Grape is a MS-DOS software repository, as well as the semi-official comp.binaries.ibm.pc archive. Also, my anonymous friend, how did you implement the mark storage? The only clean way I can think of to do it is to create a temporary file whose name is derived from the 'get' filename. This temporary file is used to contain the marks sent out by the sending process. If the transfer is completed, then the temporary file gets deleted. The ftp client, when asked to 'get' a file whose mark file exists, will output the latest mark using REST, and will continue the transfer. The marks *could* be written into the user's file, but I would rather ensure that the partial file is usable. The user may choose to use only what they have instead of retrying. The marks *could* be kept inside the user's ftp process, but I would rather make the mark storage independent of the ftp process. After all, one of the reasons for an interrupted transfer is because the user's machine crashed. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) If you can, help others. If you can't, at least don't hurt others--the Dalai Lama
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 7 Feb 89 22:46:22 GMT From: kolb@NISC.NYSER.NET To: comp.protocols.tcp-ip Subject: Re: Request to be added to mailing list
you are added. chris
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 00:17:47 GMT From: pat@SM.UNISYS.COM (Pat Ward) To: comp.protocols.tcp-ip Subject: TELNET NVDET questions
I am new to posting news articles...so I will appreciate all the help I can get. I need to implement TELNET (client & host) based on DIA's DODIIS TELNET Network Virtual Data Entry Terminal (NVDET) Option Specifications or RFC1043 TELNET Data Entry Terminal Option DODIIS Implementation. Questions: Is DIA's DRS-2600-4841-85 5/85 the updated version of DODIIS TELNET NVDET Option Specs, Apr 83? Is there a real quick way I can get the DRS-2600...document? Is there C source code for TELNET with the DET option available on the news net such that I don't have to reinvent the wheel? Has TELNET NVDET already been talked about or am I breaking new ground? Thanks in advance, pat@sm.unisys.com
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 03:49:05 GMT From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
In article <8902071459.AA22881@redrump.spider.co.uk>, keith@SPIDER.CO.UK (Keith Mitchell) writes: > Address mapping for this stuff is something of an issue. At present > we use a lookup table, which is the only way of really doing the > job, but if you have a lot of WAN destinations to talk to then there > is a danger of guzzling up lots of kernel memory. I have an implementation of IP over Datakit(r) VCS circuits that I did for 4.3bsd; I had the same problems. One thing I did was to do call setup from user-level. If a circuit to a destination is needed, but none is available, the IP address is passed to a daemon process; this process looks up the dialstring, makes the call, and hands the circuit back to the dkip driver. Because I'm using a user-level process, the mappings can reside in a file. The problem, though, is that *lots* of IP drivers need this sort of lookup, especially for wide-area non-broadcast nets. Dkip has one version, assorted X.25 implementations have their own, dial-up SLIP needs analogous data, etc. Perhaps we can find some way to store the information via the Domain Name System. What we'd need, more or less, is a new record type PHYSADDR in class IN; its data field would contain a type code (Datakit VCS, X.25, etc., and a type-dependent set of dialing instructions. The inverse mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would be useful as well, for validation of incoming calls. I'm not entirely happy with this idea, though; the format of the dialing instructions is rather too variable for a single record type. But the PHYSADDR record needs to be tied to the IN class, since IP is the primary client for the information. Suggestions, anyone? --Steve Bellovin smb@ulysses.att.com
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 05:38:57 GMT From: griefer@ibmarc.uucp (Allan D. Griefer) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
You might look at DREGS, a distributed games package from the University of Wisconsin.
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: Wed, 08 Feb 89 14:15:31 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: tcp-ip@sri-nic.ARPA Subject: Jan '89 SIGCOMM Bibliography
Is available via anonymous FTP from sh.cs.net:sigcomm/jan89.refer
The bibliography is in UNIX refer format. A LaTeX version is available,
if people are interested in it, please contact me.
The bibliography attempts to list every paper or book published on computer
networking and distributed systems in the preceding 3 months (note that
some things slop over -- publication dates and mailing dates aren't
always in sync).
The bibliography is printed quarterly in SIGCOMM Computer Communication
Review. A postscript copy of the application to join SIGCOMM is appended.
Anyone who wants to submit a listing should e-mail it to me (craig@bbn.com).
Thanks,
Craig Partridge
--- cut here ----
/box-6 { % x y box-6
newpath
moveto
0 6 rlineto
6 0 rlineto
0 -6 rlineto
closepath
stroke
} def
/Helvetica-Bold findfont 16 scalefont setfont
306 (APPLICATION FOR SIGCOMM MEMBERSHIP*) stringwidth pop 2 div sub 720 moveto
(APPLICATION FOR SIGCOMM MEMBERSHIP*) show
306 (ASSOCIATION FOR COMPUTING MACHINERY) stringwidth pop 2 div sub 660 moveto
(ASSOCIATION FOR COMPUTING MACHINERY) show
/Helvetica-Bold findfont 12 scalefont setfont
306 (11 WEST 42nd STREET, NEW YORK, N.Y. 10036) stringwidth pop 2 div sub 640 moveto
(11 WEST 42nd STREET, NEW YORK, N.Y. 10036) show
/Helvetica findfont 12 scalefont setfont
306 (Please enroll me as a member of the SPECIAL INTEREST GROUP) stringwidth pop 2 div sub 600 moveto
(Please enroll me as a member of the SPECIAL INTEREST GROUP) show
306 (ON DATA COMMUNICATION) stringwidth pop 2 div sub 585 moveto
(ON DATA COMMUNICATION) show
/Helvetica findfont 10 scalefont setfont
306 (Membership includes CCR Subscription. Please make checks payable to) stringwidth pop 2 div sub 560 moveto
(Membership includes CCR Subscription. Please make checks payable to) show
/Helvetica-Bold findfont 10 scalefont setfont
306 (ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) stringwidth pop 2 div sub 548 moveto
(ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) show
% left side text
/Helvetica findfont 10 scalefont setfont
72 468 moveto
288 0 rlineto stroke
72 458 moveto
(Name -- please print or type) show
72 424 moveto
288 0 rlineto stroke
72 414 moveto
(Mailing Address) show
72 380 moveto
288 0 rlineto stroke
72 334 moveto
288 0 rlineto stroke
72 324 moveto
(City) show
180 324 moveto
(State) show
324 324 moveto
(Zip) show
72 268 moveto
(Signature) show
124 268 moveto
240 0 rlineto stroke
72 220 box-6
82 220 moveto
(Please send information on ACM membership.) show
72 200 box-6
82 200 moveto
(New address. Please change my ACM record.) show
72 150 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(*NOTE: ) show
/Helvetica findfont 10 scalefont setfont
(ACM members renewing within the next three months do not need to use this application.) show
72 138 moveto
(Simply add SIGCOMM to your renewal invoice.) show
72 100 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(BACK ISSUES: ) show
/Helvetica findfont 10 scalefont setfont
(Back issues of SIGCOMM Computer Communication Review are available) show
72 88 moveto
(at the single copy price of $10. ACM members receive a 25% discount.) show
% right side text
390 480 moveto
(Annual Membership Dues are:) show
394 468 moveto
($15 for ACM Members) show
394 456 moveto
($10 for ACM Student Members) show
394 444 moveto
($37 for Non-ACM Members) show
380 420 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 420 moveto
(ACM MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 400 moveto
(Member #) show
436 400 moveto
108 0 rlineto stroke
390 390 moveto
(Send no money now. Dues are payable) show
390 380 moveto
(when ACM membership is renewed.) show
380 350 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 350 moveto
(ACM STUDENT MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 330 moveto
(Member #) show
436 330 moveto
108 0 rlineto stroke
390 320 moveto
(Send no money now. Dues are payable) show
390 310 moveto
(when ACM membership is renewed.) show
380 280 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 280 moveto
(NON-ACM MEMBER) show
390 260 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is annual dues of $37.) show
380 230 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 230 moveto
(SUBSCRIPTION TO CCR ONLY) show
390 210 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is $25 annual subscription fee.) show
390 200 moveto
(NOTE: SIGCOMM Membership includes) show
390 190 moveto
(subscription to CCR.) show
showpage
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 06:23:31 GMT From: dyer@spdcc.COM (Steve Dyer) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
In article <11194@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>Perhaps we can find some way to store the information via the
>Domain Name System. What we'd need, more or less, is a new record type
>PHYSADDR in class IN; its data field would contain a type code (Datakit VCS,
>X.25, etc., and a type-dependent set of dialing instructions. The inverse
>mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would
>be useful as well, for validation of incoming calls.
>
>I'm not entirely happy with this idea, though; the format of the dialing
>instructions is rather too variable for a single record type. But the
>PHYSADDR record needs to be tied to the IN class, since IP is the primary
>client for the information. Suggestions, anyone?
If you can live without the IN class, the Hesiod nameserver mods to
BIND we made at MIT would seem to be just what you want. It essentially
uses class HS, type TXT for its resource records. The TXT type
is just free-form ASCII text, and further qualification ("typing") is
done with a second string, the HesiodNameType, which when concatenated
with the name of the object to be resolved, is passed by the Hesiod
calls to the DNS. Since there was no way to predict what data Hesiod
would be carrying in the future, we decided against defining new RR types,
preferring to encode this in the domain names of the RRs.
char **cp;
e.g.,
cp = hes_resolve(hostname-or-ip-addr-as-octet-string, "physaddr");
/* Now cp == NULL */
/* or cp[0], cp[1], cp[N-1] contain strings and cp[N] == NULL */
cp[0] == "x25 some-long-ISO-addr", etc.
You get the idea.
In our use of Hesiod within Athena, we quite commonly return strings
of the form
TYPE strings-meaningful-for-said-TYPE
and application which use Hesiod know about the structure of the
strings for a particular HesiodNameType.
If you want to examine Hesiod, it can be retrieved as pub/hesiod.tar.Z
from athena-dist.mit.edu.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 06:38:25 GMT From: hutton@scubed.arpa (Thomas Hutton) To: comp.protocols.tcp-ip Subject: Request of info/recomendations on bridges or gateways
We are soon going to need to connect our three San Diego sites ethernets
via T1 lines. I am interseted in hearing recomendations on various
hardware for doing this.
Since we need to transfer not only IP traffic but DECNET as well Im assuming
I need to use a bridge vrs a gateway product. One of the things we would
like to do is have a redundent set of circuits:
Site A
/ \
/ \
T1 / \ T1
/ \
/ \
SiteB----------Site C
T1
I am concerned with the problem of routing loops. I would really like something
that could while avoiding loop problems, split the traffic over the links
to optimize the bandwidth of the links.
Help/Info is appreciated.
Thanks,
Thomas Hutton
hutton@scubed.com
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 1989 14:56 EST From: tmac@sol.engin.umich.edu To: VAF@Score.Stanford.EDU, CERF@A.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA, smart%ditmela%latcs1%wcc@murtoa.cs.mu.oz.au Subject: Re: Interactive game playing over an internet network
I haven't actually played xtrek (though we have it) but xconq I have played over the network and it does provide an intersting effect to the game. I wouldn't mind seeing more like this. Plus, building it using the X toolkit provides (though xconq could use a little improvement) a good user interface. _Tom
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 11:27:52 GMT From: heimir@rhi.hi.is (Heimir Thor Sverrisson) To: comp.protocols.tcp-ip,comp.unix.microport,comp.unix.xenix Subject: SLIP for 386/ix
Is there an implementation of SLIP (Serial Line Internet Protocol ?) for machines running under Interactive 386/ix. This is System V.3.2 and I think the TCP/IP-Ethernet implementations use STREAMS. Please respond via email, I'll summarize to the net if anything comes up. -- Heimir Sverrisson NeuroSoft Inc. heimir@rhi.hi.is
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 14:52:42 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: DoDIIS TELNET NVDET Option
RFC 1043 by Thompson and Yatsuda (sp?) is the best definition of DoDIIS TELNET Network Virtual Data Entry Terminal (NVDET) Option. The earlier DIA publications are not terribly clear on what is required. Most of the implementations that I have seen are embedded in systems that are not publicly available and have a tendency to be application specific. I have not seen or heard of anyone touting that they have a publicly or commercially available TELNET product with support for the NVDET option. Merton Campbell Crockett Contel Federal Systems System Software Manager Information Management Systems Division Production Systems 31717 La Tienda Drive, Box 5027 01(818)706-5573 Westlake Village, CA 91359-5027 Internet: mcc@etn-wlv.EATON.COM Easynet: DECWRL::"mcc@etn-wlv.EATON.COM"
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 16:02:08 GMT From: hal@GATEWAY.MITRE.ORG (Hal Feinstein) To: comp.protocols.tcp-ip Subject: mail filtering
Some time ago there was a discussion of mail filtering. The thrust was
to filter real mail (!) from things masquerading as mail. Seems hard to
do, maybe impossible. But does anyone remember how this discussion ended up
or of any work being done in this area?
-Hal
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 1989 22:02-EST From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: Re: More on IP over X.25
Art, Why struggle to translate from X.121 to IP if the arriving internet packet has a source IP address in it...oh, the source IP address isn't the address of the gateway, if there was a gateway, but the IP address of the source. Sorry, that's what I forgot. So you want a way to relay return traffic by way of the VC on which it was delivered. Seems to me that return traffic is going to get routed by the gateway based on the ultimate IP destination address of the returning traffic. If the IP address of the intermediate gateway can be mapped to an X.121 address, you could look for an existing X.25 VC with that destination X.121 address and put the packet on that - without having to map from X.121 to IP at any time, yes? Vint
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 17:11:06 GMT From: barns@GATEWAY.MITRE.ORG (Bill Barns) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
From offline sources I gather that some people were confused about what
the X.121/IP address mapping discussion really meant. Here is an
attempt at an explanation. After that, I have some remarks on the NSAP
vs. IP issue.
The point of an X.121/IP address mapping table is to enable mapping in
the IP -> X.121 direction, not the other way around. This is needed to
identify or create an appropriate X.25 virtual circuit to carry an IP
datagram through an X.25 subnet to its destination or an appropriate
gateway. The reverse mapping turns out not to be a very useful thing,
and thus is not really an issue.
It also happens that the list of X.121 addresses appearing in the
mapping table can be used for a rough validation of the legitimacy of
an incoming X.25 call. In general, however, it is not possible to use
the reverse mapping X.121 -> IP to validate the IP addresses contained
in datagrams arriving over an X.25 VC whose other end is an X.121
address in the table. Although the entity on the other end of the X.25
VC has an IP address, it does not necessarily follow that datagrams
received from the other end will have that particular IP address as the
IP source address.
There are three main reasons why the address might be different.
(1) The other end of the X.25 VC is an IP gateway (router). In
this situation there will be many IP source addresses appearing in the
datagrams arriving on that VC, and the IP address of the gateway itself
will not usually appear in those datagrams.
(2) Source routing is being used. In this case, the IP source
address might be anything, and the address of the gateway at the far
end of the VC will generally appear in the option, but this is not
assured.
(3) The device at the other end is claiming an inappropriate IP
address.
The idea of checking each datagram's IP source address and the X.121
address of the other end of the X.25 VC on which it arrived against the
static table to detect spoofing is meant to deal with (3) above, but it
causes legitimate actions (1) and (2) to fail. The functions (1) and
(2) are part of the normal IP definition and one ought not to break
these things unless there are particularly strong reasons to do so in a
specific limited usage environment.
One might try to cope with (1) by maintaining some knowledge of
legitimate backside network numbers for such gateways, but this
requires a more elaborate static table and tends to be impractical if
the backside has backdoors into other parts of the Internet.
If you distinguish between non-gateways and gateways in the static
table, it would be possible to use logic to cope with case (2) for
the non-gateways. This would require checking for source routing
options. This can work because the non-gateway is either the source
or has to have been named explicitly in the source route, in order
for a properly functioning gateway to have sent it the packet in the
first place. (This logic doesn't hold for gateways because gateways
may have been routed to because of extrinsically derived information at
the prior hop.)
For the gateway case, security protection against unauthorized use of a
network (remember that the X.25 VC is a network/subnet in the IP sense)
can be implemented separately from VC management and X.121 address
mapping, and this is a nice feature to have. It does not make sense to
shut down an X.25 VC to a gateway because an unauthorized party (or
someone impersonating one) has sent a datagram through it. If you do
this, you make it easy for troublemakers to induce denial of service to
legitimate users. Instead, filtering should be done at appropriate
gateways, and the undesirable datagrams should be dropped, with
appropriate ICMP messages to their source if feasible. This feature
exists in several commercial gateway boxes. The same thing can be done
in end systems, but the utility there is less clear.
Now then, about IP and ISO and so on. The RFC that discusses IP-flavored
NSAPs is not 100% up with the latest thinking there. As far as I know,
the current thought is IDEA003. This scheme talks explicitly about the
case of isolated end systems on PDNs but the NSAP treatment essentially
ignores the question of IP address association. The object of these
documents was to support ISO stacks, not IP. The reason for the hybrid
NSAP format was to provide hooks for using IP routing mechanisms to
support NSAP interpretation, rather than the other way around.
There is official ISO work on the usage of CLNP over X.25, and this is
the mode of operation envisioned (most of the time) by US GOSIP. But
it is not clear that all of the questions one might ask have really been
answered - or they may have been answered in ways you won't like. The
first octet of CUD is now officially supposed to contain the protocol
identifier when you plan to use OSI protocols. There is a designated
value, hex 81, identifying CLNP. Distinct values are assigned (I don't
recall them) for ES-IS and IS-IS, which apparently means that it is
necessary to have two X.25 VC's to support one user's traffic between
two network entities. I'm surprised that we aren't hearing howls from
gateway vendors already. ES-IS should handle the problem of converting
the NSAP to an X.121 address, but of course you need a preconfigured
X.121 address for the IS so you can talk to it to ask the question, and
the IS (or another IS) still needs to be told what the mapping and
topology are. These matters are outside the scope of the ISO specs.
Bill Barns
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 17:44:27 GMT From: Mills@udel.edu To: comp.protocols.tcp-ip Subject: Re: Internet "time servers" and UNIX timed
Dave, First, please note your list of truechimers is out of date. Fetch the file pub/ntp/clock.txt from louie.udel.edu as the latest list of servers that chime the Network TIme Protocol (NTP). See RFC-1059 for a description of NTP and either Louie Mamakos (louie@trantor.umd.edu) or Mike Petry (petry@trantor.umd.edu) for the ntpd Unix daemon. The list of NTP servers cited includes only the Fuzzball NTP servers, both primary (i.e. directly connected to a radio clock) or secondary (derives time from a primary clock via the network). There are many more NTP servers, a few primary and a lot secondary, using ntpd. A message to the ntp@trantor.edu list should smoke out a few near you. As suggested in RFC-1059, you may find your needs well met by peering with a couple of the primary servers on the NSFNET Bluebone (e.g. NCAR, SDSC or UIUC) and a couple of nearby secondary servers. NTP is not the only clock in town, even on the Fuzzballs. I found a couple of thousand responded to either UDP/TIME (37), UDP/NTP (113) or ICMP/Timestamp in a survey a year ago. While TCP-based time protocols such as TCP/DAYTIME (13) are available on many machines, I for one have strongly discouraged using TCP for that, as system resources can quickly become congested if large numbers of connections are clanking open and close. Both TIME and NTP can operate over UDP without any state storage in the server and with only minimal state storage in the client. While most organizations I know of that use NTP distribute time within their system with NTP as well, there is no reason in principle why timed could not be used within the LAN, other than a small change to the master-election algorithm. A query to the ntp@trantor.umd list will probably smoke somebody that has already done that. While not strictly part of NTP itself, the full accuracy of the service requires that the local-clock adjustment mechanism by engineered. Both the Fuzzballs and ntpd do a very careful job of that using phase-lock loop technology. In principle, timed could do that as well. Maybe somebody will even make that happen. Dave
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 19:01:49 GMT From: roy@phri.UUCP (Roy Smith) To: comp.protocols.tcp-ip Subject: Re: first release of IMAP software
mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin) writes:
> The IMAP software is now ready for distribution from SUMEX-AIM.STANFORD.EDU
> (internet address [36.44.0.6]).
Several problems. First, when I did "ftp sumex-aim.stanford.edu" I
got connected to sumex-2060.stanford.edu. I can't seem to reproduce it, so
maybe it was some transient nameserver problem? But, the real point of
this message is to remind people that when they announce the availability
of software, it would be a good idea to give some idea of what it was. I
havn't the foggiest idea what IMAP is and there isn't even a READ-ME file
that I can ftp; to figure out if I want it I have to pull the whole 365
kbyte compressed tar file from one coast to the other.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 19:15:31 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: Jan '89 SIGCOMM Bibliography
Is available via anonymous FTP from sh.cs.net:sigcomm/jan89.refer
The bibliography is in UNIX refer format. A LaTeX version is available,
if people are interested in it, please contact me.
The bibliography attempts to list every paper or book published on computer
networking and distributed systems in the preceding 3 months (note that
some things slop over -- publication dates and mailing dates aren't
always in sync).
The bibliography is printed quarterly in SIGCOMM Computer Communication
Review. A postscript copy of the application to join SIGCOMM is appended.
Anyone who wants to submit a listing should e-mail it to me (craig@bbn.com).
Thanks,
Craig Partridge
--- cut here ----
/box-6 { % x y box-6
newpath
moveto
0 6 rlineto
6 0 rlineto
0 -6 rlineto
closepath
stroke
} def
/Helvetica-Bold findfont 16 scalefont setfont
306 (APPLICATION FOR SIGCOMM MEMBERSHIP*) stringwidth pop 2 div sub 720 moveto
(APPLICATION FOR SIGCOMM MEMBERSHIP*) show
306 (ASSOCIATION FOR COMPUTING MACHINERY) stringwidth pop 2 div sub 660 moveto
(ASSOCIATION FOR COMPUTING MACHINERY) show
/Helvetica-Bold findfont 12 scalefont setfont
306 (11 WEST 42nd STREET, NEW YORK, N.Y. 10036) stringwidth pop 2 div sub 640 moveto
(11 WEST 42nd STREET, NEW YORK, N.Y. 10036) show
/Helvetica findfont 12 scalefont setfont
306 (Please enroll me as a member of the SPECIAL INTEREST GROUP) stringwidth pop 2 div sub 600 moveto
(Please enroll me as a member of the SPECIAL INTEREST GROUP) show
306 (ON DATA COMMUNICATION) stringwidth pop 2 div sub 585 moveto
(ON DATA COMMUNICATION) show
/Helvetica findfont 10 scalefont setfont
306 (Membership includes CCR Subscription. Please make checks payable to) stringwidth pop 2 div sub 560 moveto
(Membership includes CCR Subscription. Please make checks payable to) show
/Helvetica-Bold findfont 10 scalefont setfont
306 (ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) stringwidth pop 2 div sub 548 moveto
(ACM, Inc., PO Box 12115, Church Street Station, New York, NY 10249) show
% left side text
/Helvetica findfont 10 scalefont setfont
72 468 moveto
288 0 rlineto stroke
72 458 moveto
(Name -- please print or type) show
72 424 moveto
288 0 rlineto stroke
72 414 moveto
(Mailing Address) show
72 380 moveto
288 0 rlineto stroke
72 334 moveto
288 0 rlineto stroke
72 324 moveto
(City) show
180 324 moveto
(State) show
324 324 moveto
(Zip) show
72 268 moveto
(Signature) show
124 268 moveto
240 0 rlineto stroke
72 220 box-6
82 220 moveto
(Please send information on ACM membership.) show
72 200 box-6
82 200 moveto
(New address. Please change my ACM record.) show
72 150 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(*NOTE: ) show
/Helvetica findfont 10 scalefont setfont
(ACM members renewing within the next three months do not need to use this application.) show
72 138 moveto
(Simply add SIGCOMM to your renewal invoice.) show
72 100 moveto
/Helvetica-Bold findfont 10 scalefont setfont
(BACK ISSUES: ) show
/Helvetica findfont 10 scalefont setfont
(Back issues of SIGCOMM Computer Communication Review are available) show
72 88 moveto
(at the single copy price of $10. ACM members receive a 25% discount.) show
% right side text
390 480 moveto
(Annual Membership Dues are:) show
394 468 moveto
($15 for ACM Members) show
394 456 moveto
($10 for ACM Student Members) show
394 444 moveto
($37 for Non-ACM Members) show
380 420 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 420 moveto
(ACM MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 400 moveto
(Member #) show
436 400 moveto
108 0 rlineto stroke
390 390 moveto
(Send no money now. Dues are payable) show
390 380 moveto
(when ACM membership is renewed.) show
380 350 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 350 moveto
(ACM STUDENT MEMBER) show
/Helvetica findfont 10 scalefont setfont
390 330 moveto
(Member #) show
436 330 moveto
108 0 rlineto stroke
390 320 moveto
(Send no money now. Dues are payable) show
390 310 moveto
(when ACM membership is renewed.) show
380 280 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 280 moveto
(NON-ACM MEMBER) show
390 260 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is annual dues of $37.) show
380 230 box-6
/Helvetica-Bold findfont 10 scalefont setfont
390 230 moveto
(SUBSCRIPTION TO CCR ONLY) show
390 210 moveto
/Helvetica findfont 10 scalefont setfont
(Enclosed is $25 annual subscription fee.) show
390 200 moveto
(NOTE: SIGCOMM Membership includes) show
390 190 moveto
(subscription to CCR.) show
showpage
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 19:56:00 GMT From: tmac@SOL.ENGIN.UMICH.EDU To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
I haven't actually played xtrek (though we have it) but xconq I have played over the network and it does provide an intersting effect to the game. I wouldn't mind seeing more like this. Plus, building it using the X toolkit provides (though xconq could use a little improvement) a good user interface. _Tom
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 20:18:28 GMT From: tai%hpdstma@HP-SDE.SDE.HP.COM (Tai Jin) To: comp.protocols.tcp-ip Subject: Re: Internet "time servers" and UNIX timed
I'm not sure if anyone has ported timed to HP-UX, but we have ported ntp. Since HP-UX doesn't have an adjtime(2) system call I had to write an emulator (as a user process) which works on 6.0/2.0 or later releases. We don't have the latest ntp ported yet (I'm not sure if the latest code is stable yet), but if you need something now I can give you what we have that works. ...tai
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 21:05:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: Re: ATT 3b2/400 and TCP/IP
To clarify the note from Karl Kleinpaste (of Ohio State?): 1. WIN/TCP for 3b is produced by Wollongong, but is marketed and supported by AT+T. 2. A new release of the software, for SVR3.2, was just delivered to AT+T. Dave Crocker VP, Engineering The Wollongong Group
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 8 Feb 89 22:17:30 GMT From: bzs@pinocchio.UUCP (Barry Shein) To: comp.protocols.tcp-ip Subject: FTP "STRU VMS" extension
From: David L. Kashtan <IU.AI.SRI.COM!KASHTAN@talcott.harvard.edu> >That has, in fact, been the solution for a LONG time. Make a program that >can PACK/UNPACK VMS Backup Savesets using files that can be transferred in >FTP IMAGE mode. Aside from various the system administration problems that >have already been enumerated there is also a psychological implication. The >fewer steps you have to go through to get a file transfered the happier you >are (witness the preference of "rcp" over FTP when available). There have >been many times that I have used slower file transfer methods just because >it was less work for me (the difference in transfer times has to be pretty >significant for me to prefer the more laborious method). There is also the >issue of ensuring that EVERYBODY you might want to exchange VMS files with >has all the appropriate tools (isn't this what standards are for?). As a >TCP vendor we are very concerned about providing MAXIMUM functionality to our >customers -- and this issue is of pretty serious concern to us. So, rather >than just DO something so that machines running our software can communicate >in this fashion we have asked the TCP community to discuss the best way to set >a standard so that we can interoperate with other VMS TCPs for this "extended" >service yet still interoperate with the rest of the TCPs in the world. I >feel that Ken's suggestions are a good solution to the problem (but I am >obviously biased). (what's wrong with biased :-) If it's a matter of saving steps why not just build a DCL wrapper which does the job? Heck, Interlisp-D had what amounted to a very good NFS based on vanilla FTP, required no changes to the server (eg. UNIX or VMS) system as I remember. >>It wouldn't really occur to me to ask for an extension to FTP to >>transfer an arbitrary file tree between Unix's (for example), I'd just >>bundle it up with tar and send *that* (possibly compressing and/or >>uuencoding if need be.) In fact, that's SOP. > >But that is just the point -- UNIX files and FTP IMAGE transfer are a good >match (i.e. they give you the functionality that you need). We are looking >to do something equivalent for VMS, where IMAGE transfers are not sufficient. You missed my point. Unix directory trees and FTP IMAGE are *not* a good match. You have to bundle it up with tar (or equivalent) first. And saving/restoring file modes requires this even for a single file. Maybe this gets closer to the heart of the matter, perhaps what VMS really needs is an analog of Unix's RCP which can transfer directory trees and preserve file modes. Why not a separate VMSCP utility for VMS? At least that idea extrapolates cleanly to any number of OS's and we can leave FTP alone to do what it was designed to, zap the bytes from point A to point B with a minimum of interpretation (I'd be more in favor of dropping TENEX mode from FTP.) Just out of curiosity, how does DECNET handle all this (and, to go one step further, is FTAM powerful enough to satisfy this requirement?)? -Barry Shein, ||Encore||
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 03:02:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: More on IP over X.25
Art, Why struggle to translate from X.121 to IP if the arriving internet packet has a source IP address in it...oh, the source IP address isn't the address of the gateway, if there was a gateway, but the IP address of the source. Sorry, that's what I forgot. So you want a way to relay return traffic by way of the VC on which it was delivered. Seems to me that return traffic is going to get routed by the gateway based on the ultimate IP destination address of the returning traffic. If the IP address of the intermediate gateway can be mapped to an X.121 address, you could look for an existing X.25 VC with that destination X.121 address and put the packet on that - without having to map from X.121 to IP at any time, yes? Vint
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: Thu, 09 Feb 89 09:14:53 EST From: Douglas Greenwald <R1DAG%AKRONVM.BITNET@CUNYVM.CUNY.EDU> To: TCP/IP Readers <tcp-ip@sri-nic.arpa> Subject: Need info
Hello gentle readers.
We at the University of Akron's College of Engineering are in the
process of converting to a supermini to a system of workstations. They
will be connected using 802.3, TCP/IP, thin lan. We are looking for
recommendations for routers to connect us to the campus enet. The
campus net is located in a different building to which we have fiber
optic connections. We will eventually be the main engineering network
so we do need a router as opposed to a bridge.
Please respond to me directly as I don't think my subscribe command
ever made it to the listserv yet.
Thanx.
Doug Greenwald,
Engineering Computer Graphics Facility,
College of Engineering,
University of Akron.
(R1DAG@AKRONVM)
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 1989 18:36-EST From: CERF@A.ISI.EDU To: kent@WSL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Interactive game playing over an internet network
Chris, By academic suicide, I take it you mean failing to pay attention to studies, etc. Is Langston reachable? The distributed game sounds worth writing a paper or at least a column. Vint
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 14:14:53 GMT From: R1DAG@AKRONVM.BITNET (Douglas Greenwald) To: comp.protocols.tcp-ip Subject: Need info
Hello gentle readers.
We at the University of Akron's College of Engineering are in the
process of converting to a supermini to a system of workstations. They
will be connected using 802.3, TCP/IP, thin lan. We are looking for
recommendations for routers to connect us to the campus enet. The
campus net is located in a different building to which we have fiber
optic connections. We will eventually be the main engineering network
so we do need a router as opposed to a bridge.
Please respond to me directly as I don't think my subscribe command
ever made it to the listserv yet.
Thanx.
Doug Greenwald,
Engineering Computer Graphics Facility,
College of Engineering,
University of Akron.
(R1DAG@AKRONVM)
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 16:20:05 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: Request of info on bridges or gateways
In article <8902080638.AA14652@SCUBED.ARPA> >hutton@scubed.arpa (Thomas Hutton) writes: >We are soon going to need to connect our three San Diego sites ethernets >via T1 lines. I am interseted in hearing recomendations on various >hardware for doing this. > >Since we need to transfer not only IP traffic but DECNET as well Im assuming >I need to use a bridge vrs a gateway product. One of the things we would >like to do is have a redundent set of circuits: > If you install three bridges, you will need spanning tree or packet loops will result. You will not be able to use any part of the bandwidth of the redundant link. If you install routers, you can use all three links for throughput and for redundancy. If you need IP and DECnet, you can find routers that will route both. If you want bridging too (like LAT, ugh) you can buy a cisco HyBridge which will route IP and DECnet and bridge whatever other protocols you want. I have not yet personally set up a HyBridge, but I read the Rel 7.0 addendum and it looks like a reasonable hybrid. The new cisco hardware is full-ethernet bandwidth, so the old argument about packet switching slowness of routers is now moot. > >I am concerned with the problem of routing loops. I would really > like something >that could while avoiding loop problems, >split the traffic over the links >to optimize the bandwidth of the links. > All modern routing implementations should have no trouble with three links in your configuration. Spanning tree will stop bridge loops, but lose bandwidth, idling one link completely. BTW, are your sites within 4-5 miles line of sight of each other? You could save a lot of money with microwave and you could run full Ethernet bandwidth, too. There are, at last count, three vendors selling such products. Kent England, Boston University
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 18:36:23 GMT From: emv@a.cc.umich.edu (Ed Vielmetti) To: comp.sources.d,comp.protocols.tcp-ip Subject: multiparty, real-time, lightweight sequenced communications
What's the state of the art in real-time chat programs connected across an internet? The goal is something like 'party' only over multiple systems. I've heard of 'phone' but don't have any more pointers than that, & there must be others. I'm sure it would be a good testbed for multicast protocols or some sort of lightweight transaction scheme. [cross-posted to comp.protocols.tcp-ip, cause I'm not interested in single system solutions.] -- Edward Vielmetti, U of Michigan Computing Center mail group
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 22:41:35 GMT From: wiltzius@lll-lcc.llnl.gov (Dave P. Wiltzius) To: comp.protocols.tcp-ip Subject: SNMP client software.
Anyone know where I can get or purchase an SNMP client that runs on (in order of preference) SUN 3/50's running 3.4, Ultrix 2.0 or IBM PC (I suspect we are a bit behind the times on OS releases)? BTW I just received a Wellfleet LAN-LAN IP router that acts as an SNMP agent. Thank you, thank you. Dave (wiltzius@lll-lcc.llnl.gov)
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 9 Feb 89 23:36:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
Chris, By academic suicide, I take it you mean failing to pay attention to studies, etc. Is Langston reachable? The distributed game sounds worth writing a paper or at least a column. Vint
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 00:00:13 GMT From: gfb@wsc-sun.UUCP (Gareth Beale) To: comp.protocols.tcp-ip Subject: email/PROFS
Does anyone on this list know of a product that allows messages to flow between IBM PROFS and email? Please respond directly as well as to the net. Lately I have only been getting my mailing list stuff for the last few days of the week (I assume messages have still been going out Monday through Wednesday). Thank you, Gareth Beale (206)865-5375 # e-mail: Boeing Computer Services, M/S 7A-35 # gfb@wsc-sun.boeing.com P.O. Box 24346 # or: Seattle, Wa. 98124-0346 # bcsaic.boeing.com!wsc-sun!gfb
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 00:11:21 GMT From: kent@WSL.DEC.COM To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
Vint, By academic suicide, I take it you mean failing to pay attention to studies, etc. Yup, exactly. Someone wrote to me and said that a modern version of the game is available on ucbvax.berkeley.edu. chris
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 00:16:24 GMT From: brock@brock.cs.unc.edu (J. Dean Brock) To: comp.protocols.tcp-ip Subject: FTPable list of *.edu, *.com, *.org, etc.
Is there anyone out there who maintains an FTP-able list of the variously allocated 2nd-level domain names? The root name servers must exchange this information ---
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 00:40:01 GMT From: gfb@wsc-sun.UUCP (Gareth Beale) To: comp.protocols.tcp-ip Subject: RJE over TCP/IP?
Migration to newer technology is often gradual, and you can't always get rid of your favourite millstones. Assuming a batch processing machine with a UNIX operating system, and remote hosts capable of running TCP/IP protocols, does there exist an implementation of any kind of RJE support? I recently noticed port #5 is reserved for RJE, and from that dug up RFC's 407 and 740. However, these are very old (1972 and 1977 respectively), and it's not clear to me what protocol was used. Telnet and FTP are mentioned, but there is talk of ICP sockets (was ICP some predecessor of TCP?). Any information will be gratefully received, but I was hoping to avoid any discussion of the merits or otherwise of RJE type service. By the way, I view RJE as the ability to send a job stream to a remote system and get the output back, not any particular IBM-type definition of precisely what the term means. Since I am having some hiccoughs in my receipt of mail from this list, I would appreciate direct responses as well as anything posted. Thank you, Gareth Beale (206)865-5375 # e-mail: Boeing Computer Services, M/S 7A-35 # gfb@wsc-sun.boeing.com P.O. Box 24346 # or: Seattle, Wa. 98124-0346 # bcsaic.boeing.com!wsc-sun!gfb
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 02:18:44 GMT From: cmf@cisunx.UUCP (Carl M. Fongheiser) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
In article <8902061636.AA13703@pinocchio.UUCP> bzs@pinocchio.UUCP (Barry Shein) writes: >How does one transfer ISAM (eg.) files by tape between VMS systems? >Why can't a similar mechanism be used? The obvious advantage is that >such representations should even work when one wants to push such >files through third-party, non-VMS systems since all the info to >re-create the file gets bundled into the transferred file itself >rather than relying on wire transmission as server/client commands. Not a terrific example. Normally this is done using BACKUP, but BACKUP adds all kinds of extra gunk (like CRC's and ECC blocks) that shouldn't be necessary for FTP. Also, BACKUP savesets happen to be some of the hardest things to transfer using FTP, since BACKUP likes to create giant records (32,258 bytes by default for disk savesets), and unlike tar, can't deal with the file if it shows up with a smaller record size on the other end. Naturally, VMS users have ways of dealing with this, but they're ugly (probably uglier than the code required to deal with STRU VMS!) >It wouldn't really occur to me to ask for an extension to FTP to >transfer an arbitrary file tree between Unix's (for example), I'd just >bundle it up with tar and send *that* (possibly compressing and/or >uuencoding if need be.) In fact, that's SOP. Sure, and it works fine and dandy. But tar came with your system, and you didn't need any extra gunk to make that all work, did you? It just happens that Unix files are nice, simple, easy beasts to deal with. VMS files aren't. BACKUP makes it a little easier, but it really is a big hassle to do something like that, since you can't directly FTP a BACKUP saveset either. >At best I could imagine some sugar in the VMS server/clients which >might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command, >send the result of that, and if the other side is a VMS site he'll >recognize the header and automatically do the opposite", but none of >that needs a change in the protocol spec since it only affects the OS >interface, not the network interface (the file would just be xferred >binary I'd guess.) Personally I hate that kind of magic. OK, I'll bite here. What if the file I'm transferring contains that magic string or number which tells the FTP server/client to go into the magic mode, but doesn't need the interpretation. How do I turn that off? >No FTP extensions should be needed (eg. something like embedding UNIX >magic numbers should do it.) And again, if the other side wasn't a VMS >site it would work also (that is, would store the file image but make >no attempt to unpack it.) A good example of the utility of this >approach is putting VMS files for Anonymous FTP onto a non-VMS system. Sure, but as I said above, you'd need some out-of-band way to turn it off. >Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc >have been using for years? Sure it is, but all of those operating systems have comparatively simple file formats, and all of those programs write nice, simply formatted files themselves. VMS is blessed with neither, and unless someone's volunteering to write a program to do something like that, I'd rather let the VMS FTP's have a little private magic to themselves. Carl Fongheiser University of Pittsburgh cmf@unix.cis.pittsburgh.edu ...!pitt!cisunx!cmf CMF@PITTVMS.BITNET
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 03:32:00 GMT From: keyles@rubbs.FIDONET.ORG (Michael Keyles) To: comp.protocols.tcp-ip Subject: Network Management
Hi, Does anyone have a pointer to a SNMP package for a Sun and/or an RT? My firm is starting to have several machines that produce snmp stats, but we have no way of looking at it. Thanks. Mike -- Michael Keyles - via FidoNet node 1:107/520 UUCP: ...!rutgers!rubbs!keyles ARPA: keyles@rubbs.FIDONET.ORG
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 04:03:50 GMT From: hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS) To: comp.protocols.tcp-ip Subject: Whereabouts of NCD
Hi, NCD (Network Computing Devices) recently announced an X Windows Terminal, the NCD16. Can anyone give me the address/fax/phone to the company? Thanx Heng-Wah
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 04:52:01 GMT From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
>If it's a matter of saving steps why not just build a DCL wrapper >which does the job? Heck, Interlisp-D had what amounted to a very good >NFS based on vanilla FTP, required no changes to the server (eg. UNIX >or VMS) system as I remember. This is a solution -- though not a pretty one. It loses on several fronts: 1) It doesn't address the issues of system management and disk quotas. It is definitely not a selling point for the software if you are required to have 2 times the disk space available in order to transparently transfer the files 2) It is considerably slower than just transferring the files 3) Even with the wrapping (though I guess we could make the FTP client do it behind your back) it is not as convenient to use as directly using FTP. 4) What about the destination site where you don't have login access to invoke the wrapping. >>>It wouldn't really occur to me to ask for an extension to FTP to >>>transfer an arbitrary file tree between Unix's >>> . >>> . >> >>But that is just the point -- UNIX files and FTP IMAGE transfer are a good >>match (i.e. they give you the functionality that you need). We are looking >>to do something equivalent for VMS, where IMAGE transfers are not sufficient. > >You missed my point. Unix directory trees and FTP IMAGE are *not* a >good match. You have to bundle it up with tar (or equivalent) first. IMAGE mode exactly matches the transfer characterstics you need for the UNIX file data. The LIST/NLST FTP commands provide "almost" everything you need to implement directory tree copying (in fact -- you just need an extension to the UNIX wildcard syntax to make that possible). And the current FTP spec. is most definitely well suited to copying whole UNIX directories (MGET/MPUT). So in many cases "tar" is not needed -- and the facilities are already there for a vendor to implement a full UNIX directory tree copy without having to resort to an FTP protocol extension. We are just trying to arrange for the same situation for VAX/VMS. >Maybe this gets closer to the heart of the matter, perhaps what VMS >really needs is an analog of Unix's RCP which can transfer directory >trees and preserve file modes. Why not a separate VMSCP utility for >VMS? At least that idea extrapolates cleanly to any number of OS's and >we can leave FTP alone to do what it was designed to, zap the bytes >from point A to point B with a minimum of interpretation (I'd be more >in favor of dropping TENEX mode from FTP.) I wouldn't argue of this one much -- a VMS equivalent to UNIX's RCP is a good idea (and we will probably by supplying one sometime in the future) but it will be even more difficult to get all the VMS TCP vendors to agree on a whole NEW application protocol than for them to agree to an extension to an existing protocol (an extension which, by the way, requires very little effort for VMS TCP vendors to implement -- this goes a LONG way towards ensuring that all VMS TCP's can interoperate). >Just out of curiosity, how does DECNET handle all this DECNET uses a file data transfer protocol called DAP -- which was designed to address exactly these issues of sharing different "format" files between heterogeneous DEC systems (and, although the implementations are a bit slow for my taste, DAP managed to do a pretty decent job of allowing transparent file transfers between not just VAX/VMS systems but also to/from most other systems sold by DEC over the years -- like TOPS-20, RSX ...etc). I would point out that DAP is complicated enough that few people would WANT to adopt it as any kind of standard. Still battling for a "STRU O xxx" standard, David -------
-----------[000146][next][prev][last][first]----------------------------------------------------
Date: 10 Feb 89 05:13:00 GMT
From: WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: TENEX mode
(I'd be more in favor of dropping TENEX mode from FTP.)
Barry,
I hope you were just being flippant, but I saw no smiley there... So,
lest someone might take that comment seriously, let's make it clear
that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!).
But, if you really are seriously suggesting to drop TYPE L 8, then we
have a problem. How else can you send bytes from one machine
architecture to another? Certainly TYPE I (image) isn't a universal
solution, even between machines of the same word size and operating
system!
--Frank
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 05:40:57 GMT From: melvin@jacobs.CS.ORST.EDU (Todd Ferguson) To: comp.sources.d,comp.protocols.tcp-ip Subject: Re: multiparty, real-time, lightweight sequenced communications
In article <8879@mailgw.cc.umich.edu> emv@mailgw.cc.umich.edu (Ed Vielmetti) writes:
>What's the state of the art in real-time chat programs connected
>across an internet? The goal is something like 'party' only over
>multiple systems. I've heard of 'phone' but don't have any more
>pointers than that, & there must be others.
I have recently got ahold of a program called irc (Internet Relay Chat)
Each machine runs its own server and the servers are link in a tree fashion
to a master server. I've only messed with it a little, but it appears
to be a good program. I got it through anonymous ftp to 128.214.5.6
(tolsun.oulu.fi) and have asked the author about release to the USENET.
We currently have a small network of 5 machines, 2 at OSU and 3 at DU,
with orion.cair.du.edu as the master server. If you get this program,
you should try connecting to this network.
Hope this helps.
---------------------------------------------------------------------------
Todd Ferguson
UUCP: {tektronix,hp-pcd}!orstcs!jacobs.cs.orst.edu!melvin
INTERNET: melvin@jacobs.CS.ORST.EDU
Disclaimer: Uh?? What???
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 08:13:14 GMT From: MKL@SRI-NIC.ARPA (Mark Lottor) To: comp.protocols.tcp-ip Subject: Re: FTPable list of *.edu, *.com, *.org, etc.
A list of top and second level domains is available on SRI-NIC.ARPA as file NETINFO:DOMAIN-INFO.TXT. -------
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 18:13:08 GMT From: keith@SPIDER.CO.UK (Keith Mitchell) To: comp.protocols.tcp-ip Subject: IP, X.25 and OSI
It appears I may have contributed to the confusion on this topic myself, for which I can only apologise, and attempt to clarify what I meant when I mentioned using checking X.25 calling addresses for security purposes. Following on from Bill Barns <barns@GATEWAY.MITRE.ORG>: >In general, however, it is not possible to use >the reverse mapping X.121 -> IP to validate the IP addresses contained >in datagrams arriving over an X.25 VC whose other end is an X.121 >address in the table. When I advocated using the calling X.121 address as a validity check, I had *not* meant that it should be used to check the source IP addresses in the incoming datagrams, rather merely that the X.121 address belongs to someone with whom you are prepared to exchange IP datagrams with. The check is not to see that there is a valid relationship between a caller's X.121 address and a datagram's source IP address, but simply to see that the X.121 address is itself one of a known set of possible such addresses. >Although the entity on the other end of the X.25 >VC has an IP address, it does not necessarily follow that datagrams >received from the other end will have that particular IP address as the >IP source address. I accept that the IP address of the caller need not be the same as a datagram's IP source address. Nor do I believe that trying to deduce what the source IP address should be from the X.25 calling address is worth attempting. However, I think it *is* worth checking to determine whether this call is coming from someone who is part of the Internet. It is not a very rigourous check, but the assumption is that the Internet is a safer place than the PDN. My software works on the basis that if they're not in your IP <-> X.121 mapping table, then you don't know who they are and hence don't want datagrams from them. Once you have verified that someone is a legitimate source of datagrams, you can then perform higher-level scrutiny of these, filtering on network number as desired, which I agree is a nice facility. On to OSI and NSAPs. I must admit I do not have IDEA-0003 and so am not fully up to date with current thinking on this. Certainly we want to carry OSI services over both existing IP and X.25(80) networks, this is a sensible approach for transition to OSI. The question is, do we regard existing IP as a dead end, or is it still worth developing subnetwork services for it which can exploit the extra features being added to existing networks to make them OSI compatible ? I guess what I mean is, are the PTTs going to upgrade their PDNs to the 1984 CONS flavour of X.25 before the Internet starts using ISO CLNP, or will it be the other way round ? If it's the former, then we need some new standards. It would be nice if I could take the (NSAP + X.121) <-> IP address mapping table out of SpiderX.25 IXE, and just replace it with an algorithmic mapping. Too bad you can't use ES-IS for this sort of thing. This of course is why OSI will be the long-term solution to all this, and I appreciate that the CLNP over X.25 stuff is being addressed in GOSIP, even if I'm not terribly familiar with it. Of course, even in an OSI world, a lot of this stuff would be less of an issue if PTTs did not insist on providing Connection-Oriented service only. Roll-on public datagram networks. Keith Mitchell Spider Systems Ltd. Spider Systems Inc. 65 Bonnington Road 12 New England Executive Park Edinburgh, Scotland Burlington, MA 01803 +44 31-554 9424 +1 (617) 270-3510 keith@spider.co.uk keith%spider.co.uk@uunet.uu.net keith@uk.co.spider ...!uunet!ukc!spider!keith
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 18:17:35 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: TTL
Why do the "Mail bridges" not decrement the TTL? Or, do they? (on 26.0.0.90) #./traceroute ucbarpa.berkeley.edu traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets 1 UCBARPA.Berkeley.EDU (10.0.0.78) 633 ms 769 ms 595 ms #
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 19:36:17 GMT From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
The point of doing a X.121->IP address map is to economize on virtual circuits. That is, routes are often symmetric; if a packet from A to B goes through gateways G1 and G2, replies from B to A will often go through G2 and G1. If G1 and G2 communicate via X.25, G1 will call G2 to send the first packet; if the reply is going to traverse the same path, it makes sense to reuse the X.25 VC. If G2 has to open its own circuit back to G1, it will incur a delay, and -- probably more important -- it will waste a channel. Some boards only support a limited number of channels; requiring two circuits for each call will, more or less, halve the number of connections a gateway can handle. (I'm assuming we don't want it thrashing on connection setup/teardown.) The flip side is the security issue: can one trust the calling X.25 address supplied? That depends on how much trust one has in the underlying network, or, more precisely, in the underlying X.25 *internetwork*. If the network provider is corrupt, making a new outgoing call won't help, as it will be diverted as well. But if the X.25 network relays calls from other X.25 data networks, and doesn't check the source address properly, it is possible that some spoofing will occur. I note that the two X.25 drivers lying around my 4.3bsd system here (for the ACC 5256/6250 and the 625 board) both behave as I describe: they attempt to determine the IP address to associate with incoming calls. --Steve Bellovin
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 20:12:10 GMT From: emv@a.cc.umich.edu (Ed Vielmetti) To: comp.unix.questions,comp.mail.uucp,comp.protocols.tcp-ip Subject: Re: uucp via IP ?
In article <522@cvman.UUCP> gdelong@cvman.UUCP (Gary Delong) writes:
>How does one establish a uucp connection via an existing network
>connection such as TCP/IP where rlogin is available.
Two reasonably easy ways.
1. If your uucp supports 't' protocol (4.3, recent HoneyDanber)
then you're all set. L.sys lines look like this for 4.3:
2. If you have an Annex terminal server it can be configured to
pass all 8 bits with the magic string 'stty parity none bchar 8'.
Then run 'g' protocol over the line and use 'rlogin' to sign on.
Similar magic for ciscos is probably available.
One gotcha is embedding the space character into the expect-send string
for the 'rlogin foo.umich.edu' command, check your documentation on that one.
--
Edward Vielmetti, U of Michigan Computing Center mail group
Support dial-up tcp/ip -- help wipe out uucp.
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 20:35:42 GMT From: jburruss@osterville.UUCP (John Burruss) To: comp.protocols.tcp-ip Subject: SNMP client software
Wellfleet Communications Inc. will be releasing its SNMP client software in a couple of months. This package runs on Sun 3/50s, OS 3.5, X11R2 or 3. Of course a large component of the package is command oriented and doesn't require X at all. John Burruss Wellfleet Communications Inc.
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 21:47:33 GMT From: glenn@dlcdev.UUCP (Glenn Meader) To: comp.protocols.tcp-ip Subject: Mac NCSA Telnet 2.2 on Apple Ethernet card?
I tried to get NCSA Telnet 2.2 running on my MAC II with Apple ethernet card. I get an error: Network initialization failed! Couldnt open driver [E] then it goes back to the finder. The card and network work fine under AU/X. I have the hardware=Ether set in the config.tel file. Any suggestions?
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 10 Feb 89 22:47:40 GMT From: karn@jupiter..bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
>The point of doing a X.121->IP address map is to economize on virtual >circuits. That is, routes are often symmetric; if a packet from A to B >goes through gateways G1 and G2, replies from B to A will often go through >G2 and G1.... On the other hand, CSNET's experience with real commercial X.25 networks like Telenet has shown that multiple parallel virtual circuits are often necessary anyway to even approach acceptable performance. The problem is the small X.25 packet size limit and the tiny packet-layer flow control window. In the absence of a mechanism for increasing this window you are forced to open up additional circuits and distribute your traffic among them. Face it, X.25 was designed for remote slow-speed terminal networking, not serious computer networking. I can also say from experience that such a path is an excellent stress test for your TCP segment reordering code... Phil
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 03:46:53 GMT From: VAF@SCORE.STANFORD.EDU (Vince Fuller) To: comp.protocols.tcp-ip Subject: Re: TENEX mode
(I'd be more in favor of dropping TENEX mode from FTP.)
I hope you were just being flippant, but I saw no smiley there... So,
lest someone might take that comment seriously, let's make it clear
that TENEX is just an alias for TYPE L 8 (not TYPE L 32, please!).
But, if you really are seriously suggesting to drop TYPE L 8, then we
have a problem. How else can you send bytes from one machine
architecture to another? Certainly TYPE I (image) isn't a universal
solution, even between machines of the same word size and operating
system!
There's some confusion here as to what "TENEX mode" in FTP means. Back in the
old days, when the majority of ARPANET (pre-Internet) systems were TENEX's and
TOPS-20's, a means was devised for doing transparent file copying between such
systems. This became known as "TENEX mode", and is a actually a combination of:
TYPE L 36 (36-bit packing of the bytestream)
STRU P ("Paged" structure)
MODE S ("Stream" mode - actually this doesn't really matter)
In more recent times, the UNIX FTP client started calling TYPE L 8 "TENEX
mode", probably because it's the type of transfer used to retrieve a class of
shareware that is kept on a certain, popular TOPS-20 host.
In any case, I believe Barry is proposing the drop the original "TENEX mode"
from the FTP spec, not to drop TYPE L 8. I suppose this would consistant with
the philosophy that FTP should only implement the least-common-denominator of
pushing bits around and is sort of moot anyway, since the only machines that
implement this are not likely to hang around for more than a few more years.
Why not just make all non-interoperable FTP operations subject to the "SITE"
command? That's what it's there for. Why not "SITE VMS MODE RMSFILE", or
something like that? This will make implementation of "intermediary" machines
to store system-specific filetype difficult, but it will solve the immediate
problem of how to get systems running a common OS to transfer files that are
native to that OS.
--Vince
(P.S. The only reason I know about the two definitions of "TENEX mode" is
through experiencing similar confusion when someone asked me, onece the
de facto TOPS-20 FTP maintainer, about "TENEX mode" on UNIX systems -
"TENEX mode on UNIX systems??" I was a little surprised to hear about such
a thing until it was explained to me what the speaker meant by "TENEX mode")
-------
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 06:12:36 GMT From: sean@ms.uky.edu (Sean Casey) To: comp.sources.d,comp.protocols.tcp-ip Subject: Re: multiparty, real-time, lightweight sequenced communications
In article <8879@mailgw.cc.umich.edu> emv@mailgw.cc.umich.edu (Ed Vielmetti) writes:
>What's the state of the art in real-time chat programs connected
>across an internet? The goal is something like 'party' only over
>multiple systems. I've heard of 'phone' but don't have any more
>pointers than that, & there must be others.
>
>I'm sure it would be a good testbed for multicast protocols or some
>sort of lightweight transaction scheme.
I'm designing one of these. It actually works but it's not in alpha test
yet. State of the art? Hope so...
Can someone point me at what a multicast protocol is? If it's in an RFC,
can you tell me a site where I can grab it with FTP?
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean
*** U of K, Lexington Kentucky, USA ..where Christian movies are banned.
*** ``Fate? I thought you said Freight.''
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 06:15:05 GMT From: sean@ms.uky.edu (Sean Casey) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
In article <[A.ISI.EDU].9-Feb-89.18:36:57.CERF> CERF@A.ISI.EDU writes:
>Is Langston reachable? The distributed game sounds worth writing
>a paper or at least a column.
Langston is not really reachable, but UCSD empire is only based on
Langston empire. It is growing into another creature altogether. You
can find it on ucbvax.berkeley.edu in /empire.
There are scads of multiplayer games using Berkeley INET sockets, you
just have to look hard.
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** Who sometimes never learns. {backbone site|rutgers|uunet}!ukma!sean
*** U of K, Lexington Kentucky, USA ..where Christian movies are banned.
*** ``Fate? I thought you said Freight.''
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 07:18:02 GMT From: chris@GYRE.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
Those who are arguing over the proper predefined standard for VMS transmission might do well to observe that most of the successful parts of Unix that are considered `standard' got that way by being written first instead of defined first. Moreover, most of those evolved, so that if they had been standardised without first being tested, we would have something less useful. In other words, if you want it done, do it yourself, then hack away at it until you really like it. *Then* cry out for standards, if you still need them---likely most people will have installed your code already anyway. (I realise that some of you are doing this already. Make that, `I hope that some of you....' The approach is not perfect, but it is much more fruitful than sending mail to tcp-ip.) Chris
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: Sat, 11 Feb 89 20:26:45 PST From: hwchoy%zpovc.DEC@decwrl.dec.com (Heng-Wah Choy DEC Singapore SWS) To: TCP-IP%zpovc.DEC@decwrl.dec.com, DECWRL""::"kashtan@iu.ai.sri.com"%zpovc.DEC@decwrl.dec.com, DECWRL""::"adelman@tgv.com"%zpovc.DEC@decwrl.dec.com Subject: Flames too strong for me...
Hi,
I got the following flames over the STRU VMS affair. I cc: it to tcp-ip and to
both of you at TGV.
One of you may care to reply?
Rgds,
Heng-Wah
> From: DECWRL::"unisoft!sparker@uunet.UU.NET" "Steve Parker 8-Feb-89 1202 PST" 11-FEB-1989 07:26
> To: uunet!zpovc.DEC.COM!hwchoy@uunet.UU.NET
> Subj: Re: FTP "STRU VMS" extension
>
> You've successfully argued that pre/post-processing with BACKUP has drawbacks.
> However, you still haven't presented an argument in favor of mucking up FTP's
> protocol specification.
>
> Operating system dependencies have no business in FTP. Period. If one has
> to know about file types on VMS (as one does in order to use VMS), then one
> has to deal with them. It is clear to me that what you need is a good
> utility for *this* purpose that hangs off the back end like backup.
>
> Backup wasn't intended for this purpose, and so is wasteful. So get a better
> utility. It isn't a valid argument to bitch about VMS lacking a good, media
> independent method for transporting files, and claim FTP should be changed
> because of it!
>
> And disk quotas on VMS systems have nothing to do with it either. If you haven't
> got enough space, go buy another disk. We have quotas on UNIX too you know...
>
> Steve Parker
> {ucbvax,uunet,sun}!unisoft!sparker
> sparker@unisoft.com
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 12:53:48 GMT From: meissner@tiktok.dg.com (Michael Meissner) To: comp.protocols.tcp-ip Subject: Re: FTP implemetation issues (was Re: FTP "STRU VMS" extension)
In article <NELSON.89Feb3233605@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes: | Speaking of FTP, has anyone implemented RESTart? Restart requires MODE C | (compressed), which is a simple repeated-byte-packing algorithm. I | checked radc-tops20's FTP server as well as several flavors of Unix FTP | servers, and none of them support Compressed mode... :-( I beleive that Data General's native UNIX (DG/UX) 4.00 FTP does support RESTart and MODE C operations. Though of course you probably need both sides of the connection to support it. :-). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 16:58:48 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: NSFNET Fuzzbone statistics
Folks,
Intrepid archeologist Mike Davis sifted through his many megarocks of data
collected on the old NSFNET Fuzzbone and came up with the enclosed PostScript
graph, which shows the net gazinta and net gazouta traffic by week from the
birth to the death of that network. We are most fascinated by the discontinuity
near October 1987 for which no data seems to exist. In that month I made
many changes designed to improve the congestion management and routing
robustness. At the time some of you and including me wondered whether the
results justified the effort and intrusion on paying customers. From the graph
one might conclude (a) the changes worked and the peak prior to the changes
represented congestive retransmissions, (b) customers got disgusted and simply
walked away or (c) an artifact in the measurement and collection process messed
up the data. One might also conclude there is insufficient data to justify
any conclusion, so you can understand why the missing data are driving us
absolutely nuts. If anybody can come up with the missing data sloshing around
the various archives, we would truly love you a lot.
Dave
----- Forwarded message # 1:
Received: from nemo.udel.edu by Huey.UDEL.EDU id aa04757; 9 Feb 89 15:50 EST
Date: Thu, 9 Feb 89 15:52:30 EST
From: davis@UDEL.EDU
To: mills@UDEL.EDU
Message-ID: <8902091552.aa28133@Nemo.UDEL.EDU>
0 setgray 1 setlinecap
90 rotate 0 -576 translate .12 .12 scale
4 setlinewidth
/hfnt /Helvetica-Bold findfont 100 scalefont def
/vfnt hfnt [0 1 -1 0 0 0] makefont def
/setfnt { dup /curfnt exch def setfont } def
hfnt setfnt
/txt {show} def
/ctxt {dup stringwidth 2 div neg exch 2 div neg exch rmoveto show} def
/rtxt {dup stringwidth neg exch neg exch rmoveto show} def
/setlinetype {
dup 1 eq { [] 0 setdash } if
dup 2 eq { [150] 0 setdash } if
dup 3 eq { [75] 0 setdash } if
dup 4 eq { [150 75] 0 setdash } if
dup 5 eq { [100 75 25 75] 0 setdash } if
pop } def
/stxt {dup 0 get 42 eq {0 -30 rmoveto} if ctxt} def
/txtrotate {
dup 0 eq
{pop hfnt}
{dup 90 eq
{pop vfnt}
{matrix identmatrix rotate hfnt exch makefont}
ifelse}
ifelse setfnt } def
/txtscale {curfnt exch scalefont setfont} def
688 495 moveto
740 487 lineto
792 580 lineto
844 539 lineto
896 580 lineto
948 471 lineto
1000 469 lineto
stroke 1103 464 moveto
1155 479 lineto
1207 577 lineto
1259 666 lineto
1311 774 lineto
1363 872 lineto
1415 590 lineto
1467 644 lineto
1519 765 lineto
1571 772 lineto
1623 803 lineto
1675 836 lineto
1726 571 lineto
1778 858 lineto
1830 999 lineto
1882 931 lineto
1934 1014 lineto
1986 942 lineto
2038 807 lineto
2090 1092 lineto
2142 1233 lineto
stroke 2246 1396 moveto
2298 1298 lineto
2349 1339 lineto
2401 1327 lineto
2453 1494 lineto
2505 1603 lineto
stroke 2609 1719 moveto
2661 1703 lineto
2713 1921 lineto
2765 2452 lineto
2817 2359 lineto
2869 2036 lineto
2921 2018 lineto
2972 1993 lineto
3024 1946 lineto
3076 2217 lineto
3128 2103 lineto
3180 2538 lineto
3232 2113 lineto
3284 2134 lineto
3336 2490 lineto
3388 2594 lineto
stroke 3543 1923 moveto
3595 1986 lineto
3647 2252 lineto
3699 2377 lineto
3751 2308 lineto
3803 2189 lineto
3855 2098 lineto
3907 1936 lineto
3959 2007 lineto
4011 2271 lineto
4063 2316 lineto
4115 2035 lineto
4166 2078 lineto
4218 2363 lineto
4270 2786 lineto
4322 2549 lineto
4374 2559 lineto
4426 2624 lineto
4478 2917 lineto
4530 3064 lineto
4582 3091 lineto
4634 3137 lineto
4686 3242 lineto
4738 3235 lineto
4789 3288 lineto
4841 3380 lineto
4893 3462 lineto
4945 3807 lineto
4997 3661 lineto
5049 3612 lineto
5101 3614 lineto
5153 3751 lineto
5205 3261 lineto
5257 3534 lineto
5309 3203 lineto
5361 3135 lineto
5412 2941 lineto
5464 2863 lineto
5516 2642 lineto
5568 1459 lineto
5620 907 lineto
currentpoint stroke moveto
1.5 txtscale 3232 4389 moveto (Ethernet In/Out) ctxt
1 txtscale 3232 49 moveto (Comparison of Input/Ouput packets summed over all nodes) ctxt
3232 131 moveto (Julian Weeks \(2447420 -> 2448085\)) ctxt
90 txtrotate 349 2291 moveto (# Packets) ctxt
636 418 moveto
636 493 lineto
stroke 1155 418 moveto
1155 493 lineto
stroke 1675 418 moveto
1675 493 lineto
stroke 2194 418 moveto
2194 493 lineto
stroke 2713 418 moveto
2713 493 lineto
stroke 3232 418 moveto
3232 493 lineto
stroke 3751 418 moveto
3751 493 lineto
stroke 4270 418 moveto
4270 493 lineto
stroke 4789 418 moveto
4789 493 lineto
stroke 5309 418 moveto
5309 493 lineto
stroke 5828 418 moveto
5828 493 lineto
stroke 636 418 moveto
5828 418 lineto
currentpoint stroke moveto
0 txtrotate 636 295 moveto (0) ctxt
1155 295 moveto (10) ctxt
1675 295 moveto (20) ctxt
2194 295 moveto (30) ctxt
2713 295 moveto (40) ctxt
3232 295 moveto (50) ctxt
3751 295 moveto (60) ctxt
4270 295 moveto (70) ctxt
4789 295 moveto (80) ctxt
5309 295 moveto (90) ctxt
5828 295 moveto (100) ctxt
636 418 moveto
711 418 lineto
stroke 636 1042 moveto
711 1042 lineto
stroke 636 1667 moveto
711 1667 lineto
stroke 636 2291 moveto
711 2291 lineto
stroke 636 2915 moveto
711 2915 lineto
stroke 636 3540 moveto
711 3540 lineto
stroke 636 4164 moveto
711 4164 lineto
stroke 636 418 moveto
636 4164 lineto
currentpoint stroke moveto
90 txtrotate 513 418 moveto (0) ctxt
595 418 moveto (e0) ctxt
513 1042 moveto (5.0) ctxt
595 1042 moveto (e6) ctxt
513 1667 moveto (1.0) ctxt
595 1667 moveto (e7) ctxt
513 2291 moveto (1.5) ctxt
595 2291 moveto (e7) ctxt
513 2915 moveto (2.0) ctxt
595 2915 moveto (e7) ctxt
513 3540 moveto (2.5) ctxt
595 3540 moveto (e7) ctxt
513 4164 moveto (3.0) ctxt
595 4164 moveto (e7) ctxt
636 4164 moveto
636 418 lineto
5828 418 lineto
5828 4164 lineto
636 4164 lineto
stroke 688 487 moveto
740 465 lineto
792 509 lineto
844 494 lineto
896 531 lineto
948 451 lineto
1000 464 lineto
stroke 1103 475 moveto
1155 459 lineto
1207 533 lineto
1259 600 lineto
1311 683 lineto
1363 687 lineto
1415 610 lineto
1467 587 lineto
1519 683 lineto
1571 685 lineto
1623 729 lineto
1675 803 lineto
1726 548 lineto
1778 815 lineto
1830 882 lineto
1882 818 lineto
1934 1014 lineto
1986 942 lineto
2038 807 lineto
2090 1092 lineto
2142 1233 lineto
stroke 2246 1396 moveto
2298 1298 lineto
2349 1339 lineto
2401 1327 lineto
2453 1494 lineto
2505 1603 lineto
stroke 2609 1719 moveto
2661 1762 lineto
2713 1936 lineto
2765 2676 lineto
2817 2443 lineto
2869 2122 lineto
2921 2111 lineto
2972 2014 lineto
3024 1942 lineto
3076 2233 lineto
3128 2170 lineto
3180 2498 lineto
3232 2371 lineto
3284 2304 lineto
3336 2505 lineto
3388 2583 lineto
stroke 3543 1808 moveto
3595 1926 lineto
3647 2144 lineto
3699 2133 lineto
3751 2157 lineto
3803 2057 lineto
3855 1927 lineto
3907 1747 lineto
3959 1903 lineto
4011 2245 lineto
4063 2054 lineto
4115 1888 lineto
4166 1994 lineto
4218 2111 lineto
4270 2525 lineto
4322 2367 lineto
4374 2352 lineto
4426 2600 lineto
4478 2859 lineto
4530 2924 lineto
4582 2998 lineto
4634 3052 lineto
4686 3185 lineto
4738 3227 lineto
4789 3425 lineto
4841 3361 lineto
4893 3475 lineto
4945 3560 lineto
4997 3620 lineto
5049 3530 lineto
5101 3500 lineto
5153 3773 lineto
5205 3326 lineto
5257 3477 lineto
5309 3506 lineto
5361 3343 lineto
5412 3099 lineto
5464 2731 lineto
5516 2652 lineto
5568 1484 lineto
5620 751 lineto
currentpoint stroke moveto
gsave showpage grestore newpath 0 0 moveto
----- End of forwarded messages
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 17:43:09 GMT From: jbn@glacier.STANFORD.EDU (John B. Nagle) To: comp.protocols.tcp-ip Subject: Re: TENEX mode
In article <WANCHO.12469460754.BABYL@WSMR-SIMTEL20.ARMY.MIL> WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") writes:
>
> (I'd be more in favor of dropping TENEX mode from FTP.)
>
We used to call this ("TYPE L 8") "byte" mode in an implementation of
FTP that I controlled. Unfortunately, "Tenex" has been enshrined in too
much software. But I would suggest that "byte" be implemented as an alternate
name for the mode.
Incidentally, remember, FTP client implementors, when doing directory
operations, always switch back to ASCII mode for the directory transfer if
you're in some other mode.
John Nagle
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 17:48:23 GMT From: SOL@SRI-NIC.ARPA (Sol Lederman) To: comp.protocols.tcp-ip Subject: Re: multiparty, real-time, lightweight sequenced communications
Sean,
I belive RFC 1054 is the document you want. You can ftp it from SRI-NIC.ARPA
(login: anonymous, password: guest, filename: RFC:RFC1054.TXT). If it's
more convenient you can get the RFC via electronic mail by sending a message
to SERVICE@SRI-NIC.ARPA with the words RFC 1054 in the subject line.
-Sol
----------
1054 Deering, S.E. Host extensions for IP multicasting. 1988 May; 19 p.
(45465 bytes) (Obsoletes RFC 988)
-------
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 20:36:15 GMT From: abstine@sun.soe.clarkson.edu (Arthur Stine) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
How about if we take a quick vote on the various solutions to this problem and then someone can author an RFC describing how it would be done. I think the Un*x types are being somewhat prejudiced in this case by refusing to recognize that there is a need for this type of facility. Just because it doesn't apply to them in this case, they con't want to see it added to the overall FTP protocol. The whole point of this is interoperability. I don't see what is so wrong in adding something like this to the protocol to further that end. Lets face it: Unix is NOT the only OS in the world, nor will it probably ever be. Lets stop quibbling about this and get something moving here. Otherwise, the various vendors are going to just going to have to make something non-standard in their particular implementations to provide this very necessary service and we would not benefit from that. Art Stine Sr Network Engineer Clarkson U ABStine@CLVMS.Clarkson.Edu
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 22:38:25 GMT From: bzs@pinocchio.UUCP (Barry Shein) To: comp.protocols.tcp-ip Subject: TENEX mode
Vince is correct, I was referring to the 36-bit mode used between two PDP10 systems when I made the comment about TENEX mode. And no, I don't honestly think anyone should bother to drop it, what I meant was that it shouldn't be used as a precedent. -Barry Shein, ||Encore||
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 23:24:11 GMT From: werme@Alliant.COM (Ric Werme) To: comp.protocols.tcp-ip Subject: Re: Interactive game playing over an internet network
With the proliferation of X, I imagine a feature of interactive games would be a common user interface throughout the net. Keep in mind the possibilities of allowing individual sites or users to develop their own interface. Once upon a time, on an ARPAnet long, long ago (1973?) the Friday hackers forum at MIT start a discussion on a network-wide Star Trek game. I was C-MU, I think we had input from Perdue and Stanford. The idea was to inspire work on network graphics, a task that was languishing because everyone's system was different. We toyed around with the idea of developing Star Trek Protocol (STP) and servers on each machine that were identical. Each server would be responsible for some of the postional calculations, communicating with the other servers, and with local game clients. This would allow each site to write custom clients and encourage people to come up with really good, efficient, and informative interfaces for the game players. (And to develop automated players if there weren't enough real people around or if you wanted some extra help.) It had a lot of possibilities, but none of us had the time to devote to it and nothing came of it, as far as I know. Someone at PARC in a more authoritative position put forth a very similar proposal, but one aimed more at network graphic protocols than my interest in specialized clients. In 1974 I started fading from the ARPAnet. First to DEC, then to a dot matrix printer companies, then to starting a company to write a music teaching program for Apples. Now to Alliant and the Usenet. Maybe I'll make it back to the Internet someday. But I still won't have any time for STP! -- | A pride of lions | Eric J Werme | | A gaggle of geese | uucp: decvax!linus!alliant | | An odd lot of programmers | Phone: 603-673-3993 |
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 11 Feb 89 23:35:39 GMT From: Gene.Hastings@BOOLE.ECE.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: Whereabouts of NCD
Network Computing Devices, Inc. 350 N. Bernardo Ave. Mountain View, CA. 94043 415-694-0650 Model NCD16 16" dialgonal X-windows terminal. Ethernet and RS-232. 1024x1024 pixel MC68000 based. Starts at US$2550. All from trade rag announcement. For tomorrow's trivia question: Competitors are given as Visual Technology, Inc. of Lowell, Mass., and Acer Counterpoint of San Jose, CA. Does anyone have THEIR addresses? Has anyone seen any of these beasties to comment on their suitability as multiwindow terminals? Gene
-----------[000169][next][prev][last][first]----------------------------------------------------
Date: 12 Feb 89 04:04:00 GMT
From: WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: TENEX modeVince, At the risk of belaboring the point, but only to avoid rewriting history, I must defer to you as the former maintainer of the FTP server we use here as the more knowledgeable on FTP matters (I'm just a late comer). However, I don't ever recall seeing the "tenex" command (not mode) (on Unix and bsd-derived systems only) as an alias for PAGED mode file transfers. It has always sent TYPE L 8 to the remote host and conditioned the local host to receive a binary file. PAGED mode was originally called XTP (eXperimental TENEX PAGED) mode by Bob Clements in RFC 683. The tenex command first appeared in some early version of user ftp in bsd4.1 or so. As far as I can tell, the tenex command was never documented in any RFC related to FTP, although it should have been because of a certain broken implementation which sent TYPE L 32 and still causes us no end of complaints and misunderstandings. On the other hand, let's not confuse TENEX with PAGED mode either. PAGED mode was originally devised for possibly holey TENEX/TOPS20 file transfers, and as long as we have another TENEX/TOPS20 machine to talk to, let's keep PAGED mode around. In spite of the fact that Barry says we shouldn't use it as a precedent, I propose that PAGED mode be considered a generic mode to transfer an exact copy of a file, including FDB and other information between two machines with the same operating system. Note that in the specification for PAGED mode, the exact format of the attribute and descriptor blocks is not given. It could easily be adapted by mutual agreement between user and server ftp implementors to the VMS problem currently under discussion. When it is used between VMS systems, it is understood to mean TYPE L wordsize instead of TYPE L 36 (all else being left the same). --Frank
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 89 14:05:06 GMT From: mcvax!unido!fauern!faui44!eckert@uunet.uu.net (Toerless Eckert) To: tcp-ip@sri-nic.arpa Subject: Utilities for nameserver wanted
I am looking for utilities that can help me with the internet nameserver. I would like to have a program that queries the nameserver of different zones and generates a /etc/hosts compatible file from the resource records, for those hosts in our LAN that can not use the nameserver. I am also interested in programs that help creating nameserver database files, especially for the PTR records. -- Toerless Eckert (eckert@immd4.informatik.uni-erlangen.de)
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 89 17:33:35 GMT From: trn@warper.jhuapl.edu (Tony Nardo) To: comp.protocols.tcp-ip Subject: MILNET<->ARPANET woes (again)
Does anyone know if the latest DDN essage (regarding conversion to standard
packet formats) is a roundabout explaination for why MILNET<->ARPANET
connectivity has been rather erratic over the past two weeks?
For that matter, has anyone else noticed any connectivity problems? I seem
to be able to reach *West Coast* sites fairly reliably. Sites closer to
home, however, have been another matter entirely.
Tony
P.S. To whom it concerns: warper routes thru 26.1.0.102 (aplvax.jhuapl.edu).
------- ---------------- -------
ARPA, trn@aplcomm.jhuapl.edu, UUCP: {backbone!}mimsy!aplcomm!trn
BITNET: trn@warper.jhuapl.edu
leading edge (adj.): used to describe technology that is five years out of date
and therefore mature enough to be used in a product.
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 89 23:30:57 GMT From: arul@sdsu.UUCP (Arul Ananthanarayanan) To: comp.protocols.tcp-ip Subject: Need phone number for Cisco
Hello, Could someone please mail me the address and phone number for Cisco? Thanks, Arul -- San Diego State University Math Sciences Dept. Celerity 1230 BSD 4.3 UUCP: ....!ucsd!sdsu!arul work:(619) 594-7208 ARPA: arul%sdsu.uucp@ucsd.edu home:(619) 583-0439
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 12 Feb 89 23:44:32 GMT From: arul@sdsu.UUCP (Arul Ananthanarayanan) To: comp.protocols.tcp-ip Subject: interested in dialin SLIP
I am interested in any work that has been done or is in progress with regard to dialin slip. We have the SLIP code builtin to our 4.3 machine so I would be interested if anyone has done anywork along the lines of having personal computers dial up and request an address dynamically on connection. Could anyone point me in the proper direction? Thanks, Arul -- San Diego State University Math Sciences Dept. Celerity 1230 BSD 4.3 UUCP: ....!ucsd!sdsu!arul work:(619) 594-7208 ARPA: arul%sdsu.uucp@ucsd.edu home:(619) 583-0439
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Feb 89 08:24:19 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: ucsdhub!sdsu!arul@ucsd.edu Cc: tcp-ip@sri-nic.ARPA Subject: re: interested in dialin SLIP
Arul:
This seems to be the hot topic of the moment.
For a reference, see
L. Lanzillo, C. Partridge, "Implementation of Dial-up IP for UNIX Systems,"
Proc. 1989 Winter USENIX Technical Conf., San Diego, California,
January 30 - February 3, 1989.
ABSTRACT: CSNET has developed a software package to support the sending
of Internet Protocol (IP) datagrams over dial-up phone lines. This driver
can automatically establish and disconnect phone calls as IP traffic
dictates. This code works in binary-only BSD systems.
People who don't have easy access to a USENIX proceedings can drop me a
note and I'll e-mail you a postscript copy. (By the way, this conference was
a good one -- see, for example, Tom Duff's paper on the virus he let loose
at AT&T).
The software described in this paper is available only to CSNET members.
Conversations I had with folks in the hall led me to believe that several
prominent people were also working on dial-up packages and we might see
more offerings in the near future.
By the way, there's apparent concensus among all involved that we'd like
our dial-up systems to interoperate. The key problem may be using
a standard serial line protocol. Implementors are getting ahead of
the Point-To-Point Working Group (not what was intended when the P2P
group was established) and once software is distributed it is hard to
upgrade.
Craig
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Feb 89 09:44:11 PST From: braden@venera.isi.edu To: sean@g.ms.uky.edu, tcp-ip@sri-nic.arpa Subject: Re: multiparty, real-time, lightweight sequenced communications
I'm designing one of these. It actually works but it's not in alpha test yet. State of the art? Hope so... Can someone point me at what a multicast protocol is? If it's in an RFC, can you tell me a site where I can grab it with FTP? Sean Contact Steve Deering, deering@pescadero.stanford.edu, and read RFC-1054. Bob Braden
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Feb 89 12:24:41 -0500 From: Andy Malis <malis@BBN.COM> To: "Tony\, Nardo" <haven!aplcen!aplcomm!trn%warper.jhuapl.edu@ames.arc.nasa.gov> Cc: tcp-ip@sri-nic.arpa, malis@BBN.COM Subject: Re: MILNET<->ARPANET woes (again)
Tony,
The DDN bulletin has nothing to do with Arpanet-MILNET
connectivity, but rather with X.25 hosts requiring non-standard
default flow control parameters and the intra-MILNET
interroperability (and MILNET management) problems that result.
The connectivity problems are the result of a problem in the
Butterfly mailbridge software that was fixed late last week. New
disks were being sent out on Friday.
Regards,
Andy Malis <malis@bbn.com> UUCP: {harvard,rutgers,uunet}!bbn!malis
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Feb 89 12:38:58 -0500 From: Mike Brescia <brescia@BBN.COM> To: "C. Philip Wood" <cpw%sneezy@lanl.gov> Cc: tcp-ip@sri-nic.arpa Subject: Re: QUERY: TTL field in IP header
Why do the "Mail bridges" not decrement the TTL? Or, do they?
(on 26.0.0.90)
#./traceroute ucbarpa.berkeley.edu
traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
1 UCBARPA.Berkeley.EDU (10.0.0.78) 633 ms 769 ms 595 ms
#
Phil,
I am not sure whether you are claiming to find the "failure to decrement" bug
or the "failure to discard when TTL is 1" bug. We see the gateways
decrementing the TTL field in packets which they pass. They should also be
careful to pass a packet only if the TTL is still non-zero when they send it
on, but this may not have been rigorously tested. Think of it as a fencepost
problem.
Mike
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 08:11:24 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip Subject: Re: While we are debating extensions to the FTP spec...
| I would like to propose a ``MODE LZ'' extension to FTP. Don't forget that some hosts can't decode 16 bit LZ compressed streams. Maybe your mode had better be ``MODE LZ [BITS]'' with the default BITS = 16. Casey
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 08:24:59 GMT From: JOHN@MATHOM.CISCO.COM (John Wright) To: comp.protocols.tcp-ip Subject: Re: Need phone number for Cisco
cisco's address is: 1350 Willow Rd. Menlo Park, CA 94025 (415) 326-1941 -------
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 13:24:19 GMT From: craig@NNSC.NSF.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: interested in dialin SLIP
Arul:
This seems to be the hot topic of the moment.
For a reference, see
L. Lanzillo, C. Partridge, "Implementation of Dial-up IP for UNIX Systems,"
Proc. 1989 Winter USENIX Technical Conf., San Diego, California,
January 30 - February 3, 1989.
ABSTRACT: CSNET has developed a software package to support the sending
of Internet Protocol (IP) datagrams over dial-up phone lines. This driver
can automatically establish and disconnect phone calls as IP traffic
dictates. This code works in binary-only BSD systems.
People who don't have easy access to a USENIX proceedings can drop me a
note and I'll e-mail you a postscript copy. (By the way, this conference was
a good one -- see, for example, Tom Duff's paper on the virus he let loose
at AT&T).
The software described in this paper is available only to CSNET members.
Conversations I had with folks in the hall led me to believe that several
prominent people were also working on dial-up packages and we might see
more offerings in the near future.
By the way, there's apparent concensus among all involved that we'd like
our dial-up systems to interoperate. The key problem may be using
a standard serial line protocol. Implementors are getting ahead of
the Point-To-Point Working Group (not what was intended when the P2P
group was established) and once software is distributed it is hard to
upgrade.
Craig
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 14:53:41 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
I vote for something that provides "interoperability". But, interoperability is not the ability of one VMS system to talk to another. The mechanism I would vote for would create an eXternal File Representation (XFR), which would allow for REAL "interoperability" between HETEROGENEOUS hosts. It would take care of mapping file attributes to and from the file attribute scheme of all time. And, if a mapping was impossible, it would give the phone number of the nearest XYZ vendor sales office, so the user could switch to an OS that was flexible enough to handle the problem. Phil Wood, cpw@lanl.gov
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 16:48:21 GMT From: sdo@PHOEBE.LARC.NASA.GOV (Sharon O. Beskenis) To: comp.protocols.tcp-ip Subject: Re: Whereabouts of NCD
The following address was listed on their brochure handed out at the Usenix conference in San Diego, CA. Network Computing Devices, Inc. 350 North Bernardo Ave. Mountain View, CA 94043 Tel. (415)694-0650 FAX (415)961-7711 Sharon Beskenis Emhart/PRC NASA Langley Research Center MS 478 Hampton, VA 23665 (804)864-1703
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 17:24:41 GMT From: malis@BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: MILNET<->ARPANET woes (again)
Tony,
The DDN bulletin has nothing to do with Arpanet-MILNET
connectivity, but rather with X.25 hosts requiring non-standard
default flow control parameters and the intra-MILNET
interroperability (and MILNET management) problems that result.
The connectivity problems are the result of a problem in the
Butterfly mailbridge software that was fixed late last week. New
disks were being sent out on Friday.
Regards,
Andy Malis <malis@bbn.com> UUCP: {harvard,rutgers,uunet}!bbn!malis
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 17:38:58 GMT From: brescia@BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: QUERY: TTL field in IP header
Why do the "Mail bridges" not decrement the TTL? Or, do they?
(on 26.0.0.90)
#./traceroute ucbarpa.berkeley.edu
traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets
1 UCBARPA.Berkeley.EDU (10.0.0.78) 633 ms 769 ms 595 ms
#
Phil,
I am not sure whether you are claiming to find the "failure to decrement" bug
or the "failure to discard when TTL is 1" bug. We see the gateways
decrementing the TTL field in packets which they pass. They should also be
careful to pass a packet only if the TTL is still non-zero when they send it
on, but this may not have been rigorously tested. Think of it as a fencepost
problem.
Mike
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 17:40:29 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TENEX mode
Why are people talking about "Tenex mode in FTP", when that is just a user command in one particular implementation of a User FTP? There is no "Tenex mode" in the FTP protocol, RFC-959. If you don't like the command, complain to the people who wrote and maintain the operating system in which is appears. I'm sure you know the address. Bob Braden
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 18:48:33 GMT From: scottr@CSC-LONS.ARPA (Scott W. Rogers) To: comp.protocols.tcp-ip Subject: SLIP for SUN-3/SUN-2
Can anyone tell me where I can get SLIP for the SUN-3 running SUN OS 3.5, and for a SUN-2 running SUN OS 3.2. I need a source for the binaries/sources and installation instructions. Also, does anyone know if SLIP under Ultrix 3.0 in compatible with SUN OS 3.5 SLIP. ------------------------------------------------------------------------ Scott W. Rogers Computer Sciences Corporation - Systems Division AT&T: (703) 876-1363 3160 Fairview Park Dr. - Falls Church, VA 22152 Fax: (703) 876-4072 Internet: scottr@csc-lons.ARPA Disclaimer: Standard disclaimers apply! ------------------------------------------------------------------------
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 19:08:44 GMT From: quentin@umb.umb.edu (Quentin Fennessy) To: comp.protocols.tcp-ip Subject: Unhelpful error message
I have two machines on an Ethernet. I got NFS up and running between them, but a few days later it stopped for no apparent reason. The two machines are a uVAX 3500 and an Olivetti 3020. When I try to ping from the oliv to the VAX it is successful. When I try to ping the OLIV from the VAX I am successful. However I can not ping the VAX from the VAX. I get the following message: VAX : ping olivetti olivetti is alive VAX : ping VAX sendto: Can't assign requested address ping: wrote localhost 64 chars, ret=-1 ping: sendto: Can't assign requested address VAX : I will appreciate any hints at all. Quentin Fennessy 617-499-4291
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 19:43:17 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: DDN MGT Bulletin 54
So, not only are we the World's number one debtor nation, with other countries setting our interest rates, now, we are under the thumb of the CCITT. I guess it's back to two cans and a string. Phil Wood, cpw@lanl.gov
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 20:12:24 GMT From: mac@proteon.com (Michael A. Curtis) To: comp.protocols.tcp-ip Subject: Availability of Cataia software ported to Unix Workstation
Gentlemen,
Has anyone had any luck porting or obtaining a port of the Cataia
software?? I'm interested in any type of workstation anyone may have
this running on. Many thanks in advance.
Mike Curtis
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 20:29:27 GMT From: ron@ron.rutgers.edu (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: email/PROFS
Call IBM, the product is called PROFS Extended Mail and the Magic number is 5798-FBJ. -Ron
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 21:00:42 GMT From: ssb@picuxa.UUCP (Scott Strool 3D2 X1069) To: comp.protocols.tcp-ip Subject: libsocket.a
I have just installed Micom Interlan TCP/IP on a AT&T 6386. I am using the Interlan 6200 Ethernet board. In an appllication that uses the tcp driver, it is looking for a file called libsocket.a. I can't find this file anywhere. Does anybody know where this file gets put and how does it get there. I am using AT&T UNIX System V release 3.2 Scott Strool AT&T att!picuxa!Tinman!ss
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 21:27:00 GMT From: VANCE@JVNCC.CSC.ORG To: comp.protocols.tcp-ip Subject: Commercial use of the Internet
Hello, Could someone please send me any information that claifies what the policy is on commercial use of the internet? I have asked and have not received any info on this. Thanks in advance, Vercell Vance Manager of User Services John von Neumann National Supercomputer Center POB 3717 Princeton, NJ 98543 or Vance@jvnca.csc.org
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 21:34:13 GMT From: kzm@TWG.COM (Keith McCloghrie) To: comp.protocols.tcp-ip Subject: Re: Network Management
Mike & Dave, You both asked about the availability of a Network Management station supporting SNMP on a Sun workstation. We have such a product. We also have SNMP agent software to go with our TCP/IP products for VMS and 386/Streams. If you would like more information, let me know. Keith McCloghrie The Wollongong Group.
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 13 Feb 89 22:15:03 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
| From: cpw%sneezy@LANL.GOV (C. Philip Wood) | | I vote for something that provides "interoperability". But, | interoperability is not the ability of one VMS system to talk to | another. The mechanism I would vote for would create an eXternal File | Representation (XFR), which would allow for REAL "interoperability" | between HETEROGENEOUS hosts. It would take care of mapping file | attributes to and from the file attribute scheme of all time. And, if a | mapping was impossible, it would give the phone number of the nearest XYZ | vendor sales office, so the user could switch to an OS that was flexible | enough to handle the problem. Yech. Just what we need. Ftp written by AI people ... :-) Will I have to have 32Mb of swap space to run ftp now? Not flaming; just asking that we don't go over board on this one. Casey
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 02:25:44 GMT From: pha@cs.rit.edu (Paul H. Allen) To: comp.sys.att,comp.protocols.tcp-ip Subject: Users of Wollongong's WIN/3B Release 2.1
Last summer, I upgraded four 3B2/400s and one 3B2/600 to Wollongong's
"Enhanced" TCP/IP WIN/3B, Release 2.1 (WIN is a Trademark of The Wollongong
Group, Inc). These computers belong to the graduate computer science
department which is highly dependent on their network. The faculty and
students soon found out that the software had some serious problems and
looked to me for some answers. I couldn't believe how much functionality
we lost.
Specific problems that we experienced:
1. The remote rn, "rrn", failed due to the system functions, "read" and "write"
not working properly. I finally gave up and rewrote the networking code
using the TLI library.
2. All printing is done on a Citoh and Epson printer via remote shell to
the 3B2/600 from 3b1s. Unfortunately, large files failed to print completely
due to truncation by the remote shell. One grad. student told me he considered
a large file to be at least 5 pages. :-<
3. Screendumps from the 3b1 to the laser printer via remote shell to one
of the 3B2/400s completely failed. Well, sometimes you would get a
partial printing.
4. I use to backup my 40 meg. hard disk to the 3B2/600's 60 meg SCSI tape
drive by executing,
find pha -depth -print | cpio -oBc | remsh ma "dd of=/dev/rSA/qtape1 bs=10b"
But for some reason or other, the command failed complaining about
"too many processes". Huh? it use to work before the upgrade!
5. Now the undergrads fill their labs with suns that currently operate
SunOS4.0 (SunOS is a trademark of Sun Microsystems, Incorporated). Since
I am one of the maintainers of the CS Departments equipment, I occasionally
have a need to transfer files between the Suns and 3B2s. I could transfer
a file by ftp if the sun was doing the "getting" and "putting" but the 3B2
failed, usually producing a zero byte file.
We made all types of noise and finally got the attention of the right people in
that massive AT&T bureaucracy. Most of our problems have been solved by the
efforts of an individual belonging to the AT&T's Tier 4 support group in
Illinois.
What is this article about? You won't believe this, BUT, that same AT&T
bureaucracy claims WE are the only ones that have these problems with this
sofeware, at least that is what they tell our salesman. So, our salesman
asked me to query the readers of this net regarding their experience with
Wollongong's TCP/IP. At least I know better, I've been reading this group
for quite a while now. AND, if you are still having problems, I've been
told, that if you respond, someone from AT&T will contact you. No kidding!
Paul Allen
...!rutgers!rochester!rit!pha Rochester Institute of Technology
pha@cs.rit.edu Computer Science Dept.
pha1775@ritvax One Lomb Memorial Drive
Post Office Box 9887
Rochester, New York 14623-0877
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1989 0909-EST From: deseafo@TYCHO.ARPA (David E. Seafolk) To: tcp-ip at sri-nic.arpa Subject: CMIP/CMIS info
Can someone tell me where to get information about the CMIP/CMIS? I understand that they are available as draft standards now, and we are interested in seeing what is being proposed for network management standards? Thanks deseafo@tycho.arpa -------
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 1989 11:27-EST From: CERF@A.ISI.EDU To: bcsaic!wsc-sun!gfb@JUNE.CS.WASHINGTON.EDU Cc: uw-june!sri-nic.arpa!tcp-ip@JUNE.CS.WASHINGTON.EDU Subject: Re: email/PROFS
Gareth, MCI Mail has a link to PROFS via SOFTSWITCH Corp. software. SOFTSWITCH is in or near King of Prussia, PA. Vint Cerf
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 08:24:17 GMT From: fbraab@leuze.UUCP (Fritz B. Raab) To: comp.sources.wanted,comp.protocols.tcp-ip,eunet.sources Subject: Does anyone have a rdate for PC-NFS ?
Does anyone have a rdate (setclock) program, written for PC-NFS, which remotely reads the date of a time server and sets the clock of the PC ? Please mail to: ============================================================================== Fritz B. Raab email: fbraab@leuze.UUCP Leuze electronic, Abt. TDV ..uunet!unido!leuze!fbraab In der Braike 1 D7311 Owen / Teck voice: +49 7021 573185 West - Germany ============================================================================== Thanks, Fritz
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 11:55:35 GMT From: rajaei@ttds.UUCP (Hassan Rajaei) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
In article <13962@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >On the other hand, CSNET's experience with real commercial X.25 networks >like Telenet has shown that multiple parallel virtual circuits are often >necessary anyway to even approach acceptable performance. The problem is the >small X.25 packet size limit and the tiny packet-layer flow control window. >In the absence of a mechanism for increasing this window you are forced to >open up additional circuits and distribute your traffic among them. Face it, >X.25 was designed for remote slow-speed terminal networking, not serious >computer networking. I quite agree with Phil. X.25 can not satisfy the high performance needed for high-speed communication and certainly not for internetworking. Isn't it really funny to have VC over a large network while it is not necessary? I believe the PTTs have done some mistake and now it is hard for them to admit and backup. The investment is so enormous that nobody dare to backup just like FORTRAN. I don't care which protocol the commercial world want to use, but I do care what scientists and researchers use or will use. These people have already started the alternative solutions. If other people listen enough we can hope for a newer and better standard than X.25. Hassan Rajaei
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 14:09:00 GMT From: deseafo@TYCHO.ARPA (David E. Seafolk) To: comp.protocols.tcp-ip Subject: CMIP/CMIS info
Can someone tell me where to get information about the CMIP/CMIS? I understand that they are available as draft standards now, and we are interested in seeing what is being proposed for network management standards? Thanks deseafo@tycho.arpa -------
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 14:13:07 GMT From: steve@NOTE.NSF.GOV (Stephen Wolff) To: comp.protocols.tcp-ip Subject: Re: Commercial use of the Internet
> Could someone please send me any information that claifies what the > policy is on commercial use of the internet? Unhappily, there is as yet no SINGLE policy, because the Internet is administered by a number of different Federal agencies whose usage policies differ. The situation is complicated in the NSFNET case because the mid-level networks (e.g., JVNCNET) are autonomous business entities with their own policies. Until a formal policy is issued by NSF (we ARE working on it!), you should assume that traffic passed over the NSFNET Backbone must be "in support of scientific research and other scholarly activities." That does not rule out commercial use, obviously. If your traffic is going to remain on JVNCNET, ask the von Neumann Center folks for their policy. The Federal Research Internet Coordinating Committee (FRICC), comprised of folks who own bits of the Internet, has a draft joint usage policy under discussion. -s
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 16:27:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: email/PROFS
Gareth, MCI Mail has a link to PROFS via SOFTSWITCH Corp. software. SOFTSWITCH is in or near King of Prussia, PA. Vint Cerf
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 18:28:00 GMT From: aprm@HAWAII-EMH.ARPA To: comp.protocols.tcp-ip Subject: Re: terminating connections
In this discussion TCP is being compared to ISO TP. The network we run at Ft. Shafter, OpenNET by Intel, uses TP4 in the transport layer. Is TP the same as TP4? Gary Dunn WESTCOM DCSRM IMO Ft. Shafter, HI
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 18:28 GMT From: aprm @ Hawaii-EMH.arpa To: tcp-ip @ sri-nic.arpa Subject: Re: terminating connections
In this discussion TCP is being compared to ISO TP. The network we run at Ft. Shafter, OpenNET by Intel, uses TP4 in the transport layer. Is TP the same as TP4? Gary Dunn WESTCOM DCSRM IMO Ft. Shafter, HI
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 19:39:54 GMT From: casey@gauss.llnl.gov (Casey Leedom) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
I don't mind the idea of per vendor extensions to ftp just as long as they're not part of the official FTP RFC standard. And I don't mind the idea of the InterNet community serving as a host for vendor standardization efforts. I think that a separate RFC for each separate vendor extension (using a standard FTP escape mechanism) is the way to go. I think that more than enough evidence has been presented to justify such extensions and their standardization. But, that evidence also suggests that, barring AI extensions to FTP, these facilities are totally vendor specific with no known bound on the number of such. Therefore in order to promote standardization within vendor communities but also avoid rewriting the FTP RFC every time a vendor extension is thought up, it's fairly clear that each such extension should be described in a separate RFC. Given the InterNet's traditional desire to achieve and enhance interoperability, I think we should be receptive to hosting vendor standardization efforts in this manner. Part of the InterNet's role is as a standards body after all. But, aside from these thoughts, I think Chris is right: you VMS TCP/IP suppliers ought to get together on your own in a private meeting and agree on a standard between yourselves. I think you've received more than enough commentary about usage of both "SITE" and "STRU". My personal choice is "SITE" because it was explicitly put in for such non-standard extensions, but that's just me. Casey
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 21:59:23 GMT From: lance@hermix.UUCP (Sir Ellinghouse) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TCP/IP and printer daemons
I have a TCP/IP network running over ~ 14 PC's and one 386. We have two printers hooked up to the 386 and would like to use them over the net. I noticed that there was a socket address for printerd already. Does anyone have SCO Xenix 386 source and PC-DOS source for a host-server print program? Anyone have any ideas on where to get a program like that? PD not really necessary, but Nice. Thanks, Lance Ellinghouse -- Lance Ellinghouse Mark V Systems, Ltd. UUCP: ...!hermix!lance ARPA: ucla-an!hermix!lance@ee.UCLA.EDU
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 22:16:21 GMT From: eberard@ajpo.sei.cmu.edu (Edward Berard) To: comp.unix.aux,comp.protocols.tcp-ip Subject: The Relationship Between TCP/IP and B-Net?
I am looking for information regarding TCP/IP and B-Net. Specifically, I would like either an explanation of their relationship, or a pointer to where such an explanation could be found. Also useful would be an explanation of the relationship between B-Net and NFS (Network File System), and RPC (Remote Procedure Call). As I understand it... Pipes, socketpairs and sockets are part of B-Net. Sockets with Internet Domain map to TCP (stream) or UDP (datagram). A/UX (and Sun) have NFS that is built on TCP/UDP/IP to avoid using lower-level socket abstractions. Is NFS (and related layers) part of B-Net or a separate product (protocol)? Are there any good self-contained references on B-Net? (I am not even sure if "B-Net" is a generic name, or a vendor-specific term.) -- Greg M. Bowen (301) 695-6960 Toll Free: (800) 877-1815
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 14 Feb 89 23:12:21 GMT From: jon@ATHENA.MIT.EDU (Jon Rochlis) To: comp.protocols.tcp-ip Subject: MIT virus paper available for anonymous ftp
The MIT paper on the Internet virus of last Novemember, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", is now available via anonymous ftp from either bitsy.mit.edu (18.72.0.3) or athena-dist.mit.edu (18.71.0.38) in the pub/virus directory as mit.PS (and mit.PS.Z). A version of this paper will be presented at the 1989 IEEE Symposium on Research in Security and Privacy. -- Jon Abstract: In early November 1988 the Internet, a collection of networks consisting of 60,000 host computers implementing the TCP/IP protocol suite, was attacked by a virus, a program which broke into computers on the network and which spread from one machine to another. This paper is a detailed analysis of the virus program itself, as well as the reactions of the besieged Internet community. We discuss the structure of the actual program, as well as the strategies the virus used to reproduce itself. We present the chronology of events as seen by our team at MIT, one of a handful of groups around the country working to take apart the virus, in an attempt to discover its secrets and to learn the network's vulnerabilities. We describe the lessons that this incident has taught the Internet community and topics for future consideration and resolution. A detailed routine by routine description of the virus program including the contents of its built in dictionary is provided.
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 09:48:00 PST From: art@sage.acc.com To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: RE: Users of Wollongong's WIN/3B Release 2.1
>Last summer, I upgraded four 3B2/400s and one 3B2/600 to Wollongong's >"Enhanced" TCP/IP WIN/3B, Release 2.1 (WIN is a Trademark of The Wollongong >Group, Inc). These computers belong to the graduate computer science >department which is highly dependent on their network. The faculty and >students soon found out that the software had some serious problems and >looked to me for some answers. I couldn't believe how much functionality >we lost. > . > . > . >What is this article about? You won't believe this, BUT, that same AT&T >bureaucracy claims WE are the only ones that have these problems with this >sofeware, at least that is what they tell our salesman. So, our salesman >asked me to query the readers of this net regarding their experience with >Wollongong's TCP/IP. At least I know better, I've been reading this group >for quite a while now. AND, if you are still having problems, I've been >told, that if you respond, someone from AT&T will contact you. No kidding! > >Paul Allen >...!rutgers!rochester!rit!pha Rochester Institute of Technology >pha@cs.rit.edu Computer Science Dept. >pha1775@ritvax One Lomb Memorial Drive > Post Office Box 9887 > Rochester, New York 14623-0877 I would suggest anyone with WIN/3B problems to push on ATT to get Release 3.0 (or later) into release. This version has most of the current functionallity equivalent to BSD 4.3 (Van's TCP mods, bind 4.8, etc.). Release 3.0 seems to be a large step above 2.1. +-----------------------------------------------------------------------+ | Art Berggreen Advanced Computer Communications | | <art@sage.acc.com> Santa Barbara Street | | (805)963-9431 Santa Barbara, CA 93101 | +-----------------------------------------------------------------------+
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 1989 07:32-EST From: CERF@A.ISI.EDU To: hastings@MORGUL.PSC.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Whereabouts of NCD
Visual Technology 1703 Middlesex St. Lowell, MA 01851 (617) 459-4903 I saw a Visual Technology 640 XDS being installed yesterday and have seen/touched an NCD X-display. Both are quite nice. the NCD is 1024 X 1024 while the VT is 1024 X 800. The VT appears to be somewhat less expensive ($1995?) versus ($2550). When comparing, make sure you price with keyboards and mice! The VT runs out of PROM memory. I think the NCD downloads into RAM, but I'm not certain of that. Vint
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Feb 89 13:00:28 EST From: Cathy_Aronson@um.cc.umich.edu To: tcp-ip-RELAY@SRI-NIC.ARPA Subject: Packet Driver version of NCSA Telnet 2.2 is now Available
The land that time forgot!!!! My aunt and uncle live there and I didn't forget it. They live on the Raket ( I have never seen it spelled) River. It is really pretty there. ---Cathy
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 12:32:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Whereabouts of NCD
Visual Technology 1703 Middlesex St. Lowell, MA 01851 (617) 459-4903 I saw a Visual Technology 640 XDS being installed yesterday and have seen/touched an NCD X-display. Both are quite nice. the NCD is 1024 X 1024 while the VT is 1024 X 800. The VT appears to be somewhat less expensive ($1995?) versus ($2550). When comparing, make sure you price with keyboards and mice! The VT runs out of PROM memory. I think the NCD downloads into RAM, but I'm not certain of that. Vint
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 16:07:57 GMT From: amanda@lts.UUCP (Amanda Walker) To: comp.unix.aux,comp.protocols.tcp-ip Subject: Re: The Relationship Between TCP/IP and B-Net?
eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
I am looking for information regarding TCP/IP and B-Net. Specifically,
I would like either an explanation of their relationship, or a pointer
to where such an explanation could be found.
As far as I know, "B-Net" is a term used by Apple and/or Unisoft to refer
to "Berkeley Networking," i.e., something compatible with 4.[23]BSD
networking. In the case of A/UX this consists of a socket interface which
can be used with UNIX domain sockets, TCP/IP sockets, and so on.
--
Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...
-----------[000214][next][prev][last][first]----------------------------------------------------
Date: 15 Feb 89 16:59:54 GMT
From: schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: CMIP/CMIS info
Can someone tell me where to get information about the CMIP/CMIS?
I understand that they are available as draft standards now, and we are
interested in seeing what is being proposed for network management standard
Actually I understand it is still out for ballot so its still a DP.
Marty
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 17:36:27 GMT From: phil@Apple.COM (Phil Ronzone) To: comp.unix.aux,comp.protocols.tcp-ip Subject: Re: The Relationship Between TCP/IP and B-Net?
In article <468@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>I am looking for information regarding TCP/IP and B-Net. Specifically,
>I would like either an explanation of their relationship, ...
>Are there any good self-contained references on B-Net? (I am not
>even sure if "B-Net" is a generic name, or a vendor-specific term.)
B-NET stands for Berkeley NETworking. It is the name supplied to the BSD 4.x
networking code ported over to A/UX (which is System V based). A reasonable
reference is the A/UX manual "A/UX Communications User's Guide".
B-NET (or BNET) the term was coined by UniSoft. UniSoft has spelled it both
ways for a number of years.
+------------------------+-----------------------+----------------------------+
| Philip K. Ronzone | A/UX System Architect | APPLELINK: RONZONE1 |
| Apple Computer MS 27AJ +-----------------------+----------------------------+
| 10500 N. DeAnza Blvd. | Computer viruses don't cause security problems, |
| Cupertino CA 95014 | computer programmers do ... |
+------------------------+----------------------------------------------------+
|{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft}!apple!phil |
+-----------------------------------------------------------------------------+
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 18:30:52 GMT From: haas@wasatch.UUCP (Walt Haas) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
In article <13962@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes: > On the other hand, CSNET's experience with real commercial X.25 networks > like Telenet has shown that multiple parallel virtual circuits are often > necessary anyway to even approach acceptable performance. The problem is the > small X.25 packet size limit and the tiny packet-layer flow control window. I was waiting for somebody else to point out the obvious, but it didn't happen... the small packet size limit and flow control window are *NOT X.25* problems, they are problems with the Telenet implementation! Please read the literature before you post... Walt Haas haas@cs.utah.edu utah-cs!haas
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 20:08:25 GMT From: system@asuvax.asu.edu (Marc Lesure) To: comp.protocols.tcp-ip,misc.wanted Subject: Need IEN's
I'm trying to locate ftp'able copies if IEN-19,24,25, and 30. Does anyone know where I can get them? SRI-NIC doesn't seem to have them on-line. ----------------------------------------------------------------------- Marc Lesure / Arizona State University / Tempe, AZ "Between the world of men and make-believe, I can be found..." "False faces and meaningless chases, I travel alone..." "And where do you go when you come to the end of your dream?" UUCP: ...!ncar!noao!asuvax!lesure Internet/CSNET/ARPA: lesure@asuvax.asu.edu
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 20:09:11 GMT From: pat@hfsi.UUCP (Pat) To: comp.protocols.tcp-ip Subject: TCP/IP over 802.3.
I am conducting research on implementing TCP/IP on top of 802.3
protocols. I was wondering if anyone has any good source articles
or experience in making this work. Specifically if anyone has
experience in the 802.2 LLC implementation problems I would really
appreciate any input. I think E-mail may be most appropriate unless
it is really relevant to the net.
Thanks
Pat
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 21:44:00 GMT From: phil@uxg.cso.uiuc.edu To: comp.protocols.tcp-ip Subject: TELNET incompatibility questions
I have the following situation:
- A host that REQUIRES use of the TELNET IP (Interrupt Process) and
TELNET AO (Abort Output) commands (prefixed by IAC) in order to
properly conduct a terminal session. Without the ability to send
these commands to that host's TELNET server, it is impossible to
escape for runaway execution or runaway output.
- A terminal server that provides no configurable way to transmit
either the TELNET IP or TELNET AO commands.
Clearly, these two are not going to work well together. Conceivably,
a modification to either of these could correct the problem.
Are the TELNET IP and AO commands a requirement? Is it valid TELNET to
require use of them? Which of the above two would it be more appropriate
to make modifications to?
A change to the host increases the level of compatibility and workability
whereas a change to the terminal server increases the flexibility and
functionality. I am asking the above questions to get a better insight
on what the TELNET protocol expects of its implementations.
--phil
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 21:57:38 GMT From: abair@oakhill.UUCP (Alan Bair) To: comp.protocols.tcp-ip Subject: Source for FTP c callable functions
The group I work for would like to be able to pipe data to FTP instead of writting an intermediate file and then invoking FTP to transfer the file. As far as I know you cannot directly pipe to FTP or get it to read STDIN for the file to transfer. Therefore, I would like to know if there are any c callable functions that know the FTP protocol. Then the program that genreates the data file could open the connection and feed the data directly across the connection to the FTP server at the other end. If these types of rotuines do not already exist, how hard would it be to write a set of functions to do this. We only need a limited set of the capabilites of FTP, like only one direction, fixed record format, minimal error correction, etc. Please email, since I normally do not read this group. Thanks, Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 15 Feb 89 22:57:41 GMT From: karn@jupiter..bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: IP over X.25 (request for info)
>I was waiting for somebody else to point out the obvious, but it didn't >happen... the small packet size limit and flow control window are *NOT X.25* >problems, they are problems with the Telenet implementation! > >Please read the literature before you post... I did. Unfortunately nobody seemed particularly interested in implementing all those wonderful features like modulo-128 packet numbering and packet window negotiation. Nor did Telenet seem interested in fixing their switches to not act as though the D bit were always set. Paper specs by themselves don't do much for me. The more gratuitously complicated a protocol is, the greater the opportunity for the vender to screw it up. Phil
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 02:18:20 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Time Synchronization Protocol (Tempo) spec
We're running the 4.3bsd Time Synchronization Protocol (aka Tempo?) on
our Unix boxes here, and I'd like to implement servers on our
Symbolics machines. The man page for timed refers to a document,
"TSP: The Time Synchronization Protocol for UNIX 4.3BSD", by Gusella
and Zatti. Is this document available anywhere for anonymous FTP?
Please respond by mail.
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 10:07:32 GMT From: grn@stl.stc.co.UK (Gary Nebbett) To: comp.protocols.tcp-ip Subject: TELNET and 8-bit ascii codes
Should a computer and terminal communicating via TELNET and capable of
exchanging 8 bit ascii codes (say a VT220 and a VMS system) negotiate BINARY
TRANSMISSION mode?
The Draft Host Requirements RFC states that the high order bit should not be
set in NVT mode.
Regards,
Gary Nebbett STL, London Road, Harlow, Essex CM17 9NA, UK
Voice +44-279-29531 Email grn@stl.stc.co.uk | PSI%234237100122::GRN
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 16:23:22 GMT From: dgolber@SM.UNISYS.COM (David Lawrence Golber) To: comp.protocols.tcp-ip Subject: X.25 service (was Re: IP over X.25)
In article <14077@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >Nor did Telenet seem interested in fixing their >switches to not act as though the D bit were always set. The obvious thing to try: go to other vendors! That IS one of the advantages of a standard; there are lots of vendors - at least in the US. (When the only vendor is the government PTT, you may have a problem.) Nothing gets the attention of a vendor more than loosing business. I don't think it's the 7-bit sequence numbers you want; it's the act-as-though-no-D-bit is set. I'd be real interested in what you find out about different vendors ... and I'm sure lots of other people would to.
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 17:48:22 GMT From: gryphon!cadovax!ucla-an!hermix!lance@elroy.jpl.nasa.gov (Lance Ellinghouse) To: tcp-ip@sri-nic.arpa Subject: printerd for TCP/IP
Does anyone know where I can get a program that will allow me to print files over TCP/IP using the printerd socket? I'm sure SOMEONE out there has put something together or knows of someone that has. Please email me at the address below. Thanks, Lance Ellinghouse -- Lance Ellinghouse Mark V Systems, Ltd. UUCP: ...!hermix!lance ARPA: ucla-an!hermix!lance@ee.UCLA.EDU
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 17:54:34 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Need IEN's
Marc, A couple of those are on dcn6.udel.edu (anonymous/guest), but I suspect they are pointers to hardcopies, which may no longer exist. Poor Fuzzball dcn6.udel.edu is at the end of a 9600-bps line, so please don't try to mget everything at once. Dave
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 16 Feb 89 19:40:31 GMT From: hedrick@geneva.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: TELNET incompatibility questions
I would demand that *both* vendors change. IP and AO are part of the standard. They're not a part I am enthusiastic about, but they should be implemented. On the other hand, something should also be done by the host implementation to let it work with telnet's that don't implement IP and AO. TELNET BREAK should both stop the process and abort output. Either that, or you should emulate the multiple types of break by saying that the first break stops output, and if you do a second break witin 1/2 sec of the first, it aborts output, or some hack like that. An IBM implementation that ignores break is crazy. However I believe they should even try to coexist with systems that can't do any of the telnet special commands, and thus they should pick two control characters to do IP and AO on the host end.
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 00:21:41 GMT From: karn@jupiter..bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: X.25 service (was Re: IP over X.25)
>>Nor did Telenet seem interested in fixing their >>switches to not act as though the D bit were always set. > >The obvious thing to try: go to other vendors! >[...] >Nothing gets the attention of a vendor more than loosing business. We did! We junked the 9600 bps Telenet X.25 interface several years ago and went with a 56kbps leased line direct to a port on the ARPANET. Costs far less and works much better, although I did have to insist I wanted an 1822J (HDH) port, NOT an X.25 port. It's still amusing to see all that HDLC link layer overhead on the protocol monitor, but since the data frames are large and the delays small, it doesn't create any real problem. And, of course, our gateway is immune to "virtual cirkosis". >I don't think it's the 7-bit sequence numbers you want; it's the >act-as-though-no-D-bit is set. Actually, either one would have been a help, since "local significance" in the packet layer RRs would reduce the delays and therefore increase the protocol-imposed throughput limit just as a larger packet layer window would. Please don't take any of my criticisms of Telenet and X.25 as criticisms of the CSNET team at BBN. They did the best job possible given brain-damaged network facilities, and the fact they could make it work at all can be best described as heroic. Phil
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 01:12:44 GMT From: sara@SPAM.ISTC.SRI.COM (Sara Tietz, see Ed Kozel) To: comp.protocols.tcp-ip Subject: Lan Manager MIB meeting and agenda
The MIB Working Group meeting on Wednesday of next week is in fact the first meeting of a new IETF working group to define MIB for Lan Manager. This message includes a meeting agenda and a *** CHANGE OF LOCATION *** for the meeting Date/Location: Wednesday, 22 February 9am-5pm, Coffee/Pastries at 8:30am Sunnyvale Hilton Hotel 1250 Lakeside Drive Sunnyvale, CA 408-738-4888 Directions to Hotel: From Highway 101 South on Lawrence Expressway Left at Oakmead Parkway (the first light) Left on Lakeside Drive (one block) Please RSVP to me if you plan to attend this meeting or send someone. I have to order lunches and need an accurate count. Also, if you plan to stay at the hotel, let me know and I will try to get discounted rooms for meeting attendees. RSVP to: sara@spam.istc.sri.com / 415-941-3399 at ACE AGENDA: *Short introduction to Lan Manager *Objectives of the group *Relationship to the MIB working group *Process: meetings, mailing list, etc. *Lan Manager management objectives (initial discussion) Sara Tietz, Advanced Computing Environments
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 01:28:30 GMT From: nemo@altger.UUCP (Paolo Bevilacqua) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: LOCUS PC Interface problem
We have installed on our Bell-Tech Unix 3.0 Sys V/386 the tcp-ip support by Excelan with 205 Tboard and the PC Interface by Locus. Our DOS Workstation must use the wd 8003 S Ethernet board running the aposite module by Locus. We can't establish any connection between the pc and the host. Using a protocol analyzer the host send broadcast OK, but the PC send only incoherent packets missing also Ethernet physical addresses Locus have sent us an additional disk for the support of the wd 8003 S with two files : -wd8003.sys -wd8003.eth We have tried these in the config.sys file in conjunction with bridge.sys or bridge.ip and nothing seems to work. The documentation about use of these files is not of help because as usual miss important points. I can exclude any hardware and/or hardware setting problems and i hope someone with experience on this can help me. Any suggest will be greatly appreciated, thx in advance. Reply by news or by mail to : ...mcvax!unido!altger!nemo
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 01:29:49 GMT From: OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen) To: comp.protocols.tcp-ip Subject: Network Management information
The March 1989 issue of ConneXions--The Interoperability Report (Vol.3, No. 3) is a special 40 page report on Network Management. It contains descriptions of both the CMOT and SNMP architectures, as well as articles on tools that are common to both systems (Case Diagrams, The SMI & MIB, etc.). An overview of Unisys' Network Management Language (presented at ACM SIGCOMM 88) and an article on UCL's Project INCA on Network Management are also included. (If you are not a subscriber, drop me a note.) Ole J. Jacobsen, Editor. -------
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 02:10:24 GMT From: swartz@amethyst.bucknell.EDU To: comp.protocols.tcp-ip Subject: (none)
REQUEST: INFO TOPIC: HELP
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 03:29:51 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: TELNET incompatibility questions
> ... TELNET BREAK should both stop the process and abort output. Either > that, or you should emulate the multiple types of break by saying that > the first break stops output, and if you do a second break witin 1/2 sec > of the first, it aborts output, or some hack like that. ... Charles: When was the new RFC published that changed the TELNET definition for BRK? RFC 854 indicates that the TELNET BRK has no meaning except to those systems that implement support for a BREAK key. In those systems, its function is to perform the same function that it would perform when the BREAK key is pressed at a local terminal. The RFC explicitly states that BRK is not a substitute for IP and/or AO. Merton
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 04:03:49 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: TELNET incompatibility questions
Phil: RFC 854 which defines the TELNET Protocol defines both IP and AO as required commands. A User TELNET which does not provide the capability to generate an IP or AO command has not been implemented correctly. In your case, the User TELNET is the one that needs to be fixed. To fully support the AO command, the TELNET "synch" function needs to be implemented. The "synch" function is required to indicate to the User TELNET when it can stop discarding data received from the Server TELNET. Merton
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 06:18:57 GMT From: john@amc.UUCP (John Sambrook) To: comp.protocols.tcp-ip Subject: Commercial use of the Internet
I read with interest Stephen Wolff's article (8902140913.aa11462@note.nsf.gov) on "Commercial use of the Internet." As someone who has recently lost his access to the Internet (due to changing jobs) this topic is (now!) near and dear to my heart. I'd appreciate comments on the following suggestion: I would like to suggest that the rules for obtaining "connected status" be ammended to permit commerical use of the Internet. For the sake of discussion I will refer to this as "Commerical Connected Status (CCS)." Applying for, and receiving, this status would authorize a commerical organization to connect to the Internet. Of course, some means for cost recovery must be provided. I would suggest that this would be the domain (no pun intended) of the commerical communications companies. In particular, they could provide gateways to the Internet, that would perform a cost-accounting function. They would bill their customers, and in turn would be responsible for reimbursing the federal government for their use of the Internet. Comments? John Sambrook Internet: amc!john@uunet.uu.net Applied Microsystems Corporation UUCP: amc!john Redmond, Washington 98073 Dial: (206) 882-2000 ext. 630 -- John Sambrook Internet: amc!john@uunet.uu.net Applied Microsystems Corporation UUCP: amc!john Redmond, Washington 98073 Dial: (206) 882-2000 ext. 326
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 09:08:19 GMT From: rpw3@amdcad.AMD.COM (Rob Warnock) To: comp.protocols.tcp-ip Subject: Re: Source for FTP c callable functions
In article <1856@turbinia.oakhill.UUCP> abair@oakhill.UUCP (Alan Bair) writes:
+---------------
| The group I work for would like to be able to pipe data to FTP
| instead of writting an intermediate file and then invoking FTP to
| transfer the file. As far as I know you cannot directly pipe to
| FTP or get it to read STDIN for the file to transfer.
+---------------
Well, as a matter of fact, with Berkeley FTP you can, as least for plain
ASCII files, though it's really a kludge. On a "put" command, the special
filename "-" in the position of the input file says to use stdin, and on
a "get" command, "-" in the position of the output file says to use stdout.
Try this (setting $HOST, $USER, $PASS, and $DESTFILE as needed):
$ cmd... | (echo $USER; echo $PASS; echo put - $DESTFILE) | ftp $HOST
and the output of "cmd..." should end up in $DESTFILE on $HOST. Same thing
works to retrieve output from a remote site:
$ (echo $USER; echo $PASS; echo get $DESTFILE - ) | ftp $HOST | cmd...
with the remote file showing up as the standard input of "cmd...".
In fact, with some care, binary files usually work, too, but you may run into
problems with error messages ending up in the stream sometimes, etc. As you
say, what you really want is:
+---------------
| Therefore, I would like to know if there are any c callable functions
| that know the FTP protocol.
+---------------
One might think about trying to take the 4.3bsd FTP client and molding it into
a set of "library routines" for use inside random applications programs...
but it's not really that cleanly structured inside, though some of the routines
("command()", "getreply()") are at about the right level. You could do it, but
it would be a lot harder than the simple command-line client outlined below.
+---------------
| If these types of rotuines do not already exist, how hard would it
| be to write a set of functions to do this. We only need a limited
| set of the capabilites of FTP, like only one direction, fixed record
| format, minimal error correction, etc.
+---------------
DISCLAIMER: The "netcp" mentioned below is an internal tool within AMD, and
is not itself available (that I know of), though the general
idea (an FTP client with an "rcp"-like command line) is easily
duplicated. However, should you want to ask them about it, mail
to "postmaster@amdcad.amd.com" directly (not to me).
Several years ago, some folks here at AMD [where I am a consultant] wrote a
program called "netcp" which is an FTP client, but which uses an "rcp"-like
command line (you know, the "host:file" syntax). It also reads the "~/.netrc"
file (if present), which makes shell-script and pipeline use extremely easy
(if you are comfortable with the security implications of ".netrc"). Examples:
$ netcp srchost:srcfile - # sort of an "rcat", but using FTP
$ (cd gorp; tar cvf - . ) | compress | netcp -b - desthost:gorp.tar.Z
$ netcp -b srchost:~ftp/pub/foo.tar.Z - | uncompress | tar xvf -
Since it is merely an FTP client, it works with any standard FTP server.
Thus, there are a bunch of options for doing things you would do interactively
if you were running the usual FTP client, such as "-b" above for "binary"
(a.k.a. "MODE IMAGE").
They started with the source to the standard Berkeley 4.3bsd FTP client,
which is now freely available as one of the "liberated" files on the
4.3-Tahoe release, and you could do the same. Just doing the basics
above is pretty straightforward: Whenever the original code would read
an interactive command from the user, fake up the right command based
on the arguments given on the command line. And watch out that you don't
start proliferating options... ;-}
Note that -- at least in a Unix environment -- even though "netcp" is a
program rather than a set of library routines, it is still a useful tool
for faking a "remote file open". Just use the Unix "popen()" function.
For example, to open a file remotely and count form-feeds (minus any
error-checking):
FILE *remote_input;
char buf[BUFSIZ], *host = "somehost"; *filename = "somefile";
int c, n = 0;
sprintf(buf, "netcp -b %s:%s -", host, filename);
remote_input = popen(buf, "r");
while ((c = getc(remote_input)) != EOF) {
if (c == '\f')
++n;
}
fclose(remote_input); /* remember to gather zombie */
printf("File %s on host %s has %d form-feeds\n", filename, host, n);
You can even do this with the standard FTP client (modulo the caveats above
about getting error messages mixed in the stream), as many Unix implmentations
allow pipelines in "popen()" arguments:
remote_input = popen("echo get somefile - | ftp somehost", "r");
or, if you don't use "~/.netrc":
sprintf(buf,
"(echo %s; echo %s; echo get %s - ) | ftp %s",
username,
password,
filename
host);
remote_input = popen(buf, "r");
while ((c = getc(remote_input)) != EOF) {
...and so on...
If even that fails, you can write your own version of popen() which hands two
pipes (or stdio FILEs might be better) back to you for both stdin and stdout
(and stderr, for that matter), and then pump the commands "interactively" to
your system's normal FTP client:
FILE *fdi, *fdo, *fde;
sprintf(buf, "ftp %s", host);
my3popen(buf, "r", &fdi, &fdo, &fde);
fprintf(fdo, "%s\n%s\nget %s -\n", username, password, filename);
fclose(fdo); /* push it out to child */
while ((c = getc(fdi)) != EOF) {
if (c == '\f')
++n;
}
fclose(fdi);
...and so on...
Just a few of the many ways to hack out a solution...
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 09:14:18 GMT From: pasteur!sham.berkeley.edu!kiernan@ucbvax.Berkeley.EDU (Mike Kiernan) To: tcp-ip@sri-nic.arpa Subject: Pseudo headers in TCP/UDP checksum -- Why?
What is the historical reasoning behind including a pseudo header (IP src/dst addr, proto #, TCP/UDP len) in the TCP/UDP checksums? The RFCs state: This gives the TCP/UDP protection against misrouted segments. Misrouted segments from the IP level??? I can't buy this... People have suggested that it is because TCP might be layered on top of something else (that doesn't checksum its header), but that doesn't seem likely (adding a header checksum layer makes more sense). What is the real reason behind the pseudo header? Do misrouted packets really get through the IP level to the TCP/UDP level? Mike Kiernan kiernan@xcf.berkeley.edu
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 1989 19:03-EST From: CERF@A.ISI.EDU To: pasteur!sham.berkeley.edu!kiernan@UCBVAX.BERKELEY.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Pseudo headers in TCP/UDP checksum -- Why?
Mike, We wanted to make sure that we had true end/end (at TCP level) checking since the IP level passed through gateways as was potentially modified en route. We didn't want to literally duplicate information in the TCP header which was carried in the IP header, so we formed a pseudo header for efficiency (taking some of the IP fields which were not supposed to change and making them play a part in the TCP level checking). Vint Cerf p.s. This may sound like a "layer crossing violation" but was just a way of not duplicating header information.
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 16:56:11 GMT From: sow@ulmo1.mt.luth.se (Sven-Ove Westberg) To: comp.protocols.tcp-ip Subject: Re: TTL
In article <8902101817.AA03292@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes: |Why do the "Mail bridges" not decrement the TTL? Or, do they? | |(on 26.0.0.90) | |#./traceroute ucbarpa.berkeley.edu |traceroute to ucbarpa.berkeley.edu (10.0.0.78), 30 hops max, 40 byte packets | 1 UCBARPA.Berkeley.EDU (10.0.0.78) 633 ms 769 ms 595 ms |# Where can I find the traceroute program? Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. Internet: sow@cad.luth.se
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 18:12:43 GMT From: tomc@dftsrv.gsfc.nasa.gov (Tom Corsetti) To: comp.protocols.tcp-ip Subject: route tracing through gateways
Hi!
I recently found source for Van J's traceroute program. It is a really
neat program for finding out what gateways your packets are travelling
through, and for seeing how long it takes to get there. Unfortunately,
I can't get it to work on my Sun 3/260 running Sun OS 3.5. I went and
installed all the new TCP/IP from Berkeley, which includes new "slow
start" algorithms, and also made the patch to raw_output that was in
the README for traceroute. I reconfigured my kernel with all this
new tcp/ip stuff. The kernel works fine. All existing networking
functions still function. Traceroute compiled without serious errors.
But, when I run it, it dumps core. Has anyone out there gotten this
program to work on a Sun running OS 3.5 ?, or for that matter, Sun OS 3.x?
I would appreciate hearing from you! Thanks in advance!
- Tom Corsetti
--
Tom Corsetti * * * * internet - tomc@dftsrv.gsfc.nasa.gov
NASA/Goddard Space Flt Ctr * * * decnet - dftnic::tomc
Greenbelt Maryland * * * * bitnet - tomc at dftbit
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 21:14:05 GMT From: pete@NCSC.ARPA (Fernandez) To: comp.protocols.tcp-ip Subject: TCP/IP and DECNET
Fellow SIG Members,
I don't know exactly what would satisfy the following,
but I,m looking for a thing which can smooth the turbulent waters between
TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate
levels and uses the plusses of decnet in the higher levels. I know it's
a tall order, particularly since decnet is predicated upon DDCMP.
Thanx in advance
Pete Fernandez, pete@ncsc.arpa
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 23:01:31 GMT From: romkey@asylum.SF.CA.US (John Romkey) To: comp.protocols.tcp-ip Subject: Re: Pseudo headers in TCP/UDP checksum -- Why?
In article <10010@pasteur.Berkeley.EDU> kiernan@sham.berkeley.edu (Mike Kiernan) doesn't believe that the historical reason for the TCP pseudoheader is to detect misrouted IP datagrams. The keyword is "historical". It doesn't matter much now, but when the first IP implementations were being written, people knew a lot less about networking and layered protocols, and this was probably an important consistency check for the first TCP/IP implementations. -- - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@xx.lcs.mit.edu "Can you find me soft asylum..." - The Doors
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 17 Feb 89 23:57:36 GMT From: brazil@pawl.rpi.edu (Timothy E. Onders) To: comp.protocols.tcp-ip Subject: SysV SLIP
Does anyone know of a version of SLIP for SysV? I have seen lots of them for BSD, but we want to run it on a 3B2. Thanks Timothy Onders
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 00:03:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Pseudo headers in TCP/UDP checksum -- Why?
Mike, We wanted to make sure that we had true end/end (at TCP level) checking since the IP level passed through gateways as was potentially modified en route. We didn't want to literally duplicate information in the TCP header which was carried in the IP header, so we formed a pseudo header for efficiency (taking some of the IP fields which were not supposed to change and making them play a part in the TCP level checking). Vint Cerf p.s. This may sound like a "layer crossing violation" but was just a way of not duplicating header information.
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 1989 18:42-EST From: CERF@A.ISI.EDU To: tikal!amc!john@BEAVER.CS.WASHINGTON.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Commercial use of the Internet
John, There are several efforts to make links available from public email carriers into the Internet. DASNET based in San Fracisco area (I think) has one such link. UUNET has UUCP to Internet facility. My company is working on a link between Internet and MCI Mail. We hope to pursue other such links or to encourage them, as appropriate. This does NOT mean that the Internet should be used for commercial purposes - I distinguish between links between commercial organizations and the Internet for purposes of research support, exchanges with the academic and research community and commercial use (i.e. using the facilities of the Internet to support a profit-making enterprise). It should be legitimate for a commercial enterprise to provide for-profit services linking their users to users of the Internet, but the general purpose of such links should be to further exchanges among the R&D community members. A final statement of use and interconnect policy is still the subject of consideration by the members of the FRICC. Vint
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 1989 18:49-EST From: CERF@A.ISI.EDU To: pete@NCSC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP/IP and DECNET
Pete, how about running higher level DECNET stuff above TCP so we can use ordinary IP gateways to tie everything together? Rather like Marshal Rose's ISODE suggestion in which higher level OSI protocols are supported above the TCP layer. Vint Cerf
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 15:59:44 GMT From: adelman@TGV.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECNET
I don't know exactly what would satisfy the following, but I,m
> looking for a thing which can smooth the turbulent waters between
> TCP/IPers and DECNETters; something that uses the tcp/ip in the
> appropriate levels and uses the plusses of decnet in the higher
> levels. I know it's a tall order, particularly since decnet is
> predicated upon DDCMP.
Ah, DECnet isn't stuck on DDCMP. As part of our VMS TCP product,
MultiNet, we provide the ability to run DECnet lines and circuits over
an arbitrary IP network (and the inverse). You can make a
point-to-point DECnet circuit across the Internet, or any other place
where you have IP connectivity. One copy of MultiNet would be required
on each site of the link, and of course any other DECnet-only machines
could route through the link.
We attach DECnet at the lowest level of the protocol stack and
encapsulate the DECnet datagrams into UDP datagrams for transmission.
When they arrive at the other site, we pass them up to DECnet.
For more information about MultiNet, please contact me offline...
Kenneth Adelman
TGV, Incorporated
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Sat, 18 Feb 89 22:14:12 CST From: german@uxh.cso.uiuc.edu (Gregory German) To: tcp-ip@sri-nic.arpa Subject: Re: TCP/IP and DECNET
We are running a DECNET to TCP/IP gateway on a DECserver 3500.
This is a DEC software product running under Ultrix. TCP/IP users
can login on DECNET machines and DECNET users can login to TCP/IP
machines. Filetransfer is possible as well.
On a different level our campus backbone routes both TCP/IP and DECNET
traffic. We are using Proteon gateways between building networks and
the backbone is a collection of 10 and 80 megabit/sec Proteon Token
Rings. The two protocols do not interact, but they do co-exist.
Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293)
US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801
Office: 129 Digital Computer Lab., Network Design Office
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 19:23:25 GMT From: mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: re: TELNET and 8-bit ascii codes
In a word, the answer is yes, if you want to transmit 8-bit ASCII codes then you should use network binary mode. Note that network binary mode also turns off the special handling of CR; the concept of the "Telnet newline" only exists if binary mode is off. Also, remember that binary mode is unidirectional and if you want a bidirectional binary stream (e.g. for using the international character set on a VT220) you must negotiate binary mode in both directions (IAC DO BINARY + IAC WILL BINARY). An example of operating systems which support this are WAITS (the system at SAIL.STANFORD.EDU), ITS, and TOPS-20. The most important use is to support 8-bit keyboard controls (the so-called "EDIT" key) or to turn off local controls for people coming in from a TAC. The PANDA version of TOPS-20 also supports VT220 characters as one of its extensions. Beware!! Many Unix Telnet servers tie network binary mode to the internal Unix concept of "raw" vs. "cooked" terminal modes. Arguably, this is a bug or at least a misfeature, but it's much too late to hope for a fix. At least some Unix Telnet servers will process 8-bit characters even if the stream is not in binary mode. Also, many terminals send parity in the high order bit. For this reason, it is not safe for a Telnet client to enter binary mode on its own without explicit direction from the human user or from the Telnet server, since there is no "right" setting that is guaranteed to work on all systems. -------
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 20:16:08 GMT From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) To: comp.protocols.tcp-ip Subject: Re: TELNET incompatibility questions
The design intent of Telnet IP and AO (about which it happens I can speak with complete confidence) was certainly that USER Telnets must have the ability to convey the user's desire to invoke the respective functions to Server Telnets. (Explicit note was taken that not all Servers offer AO, and that we weren't demanding more of them than they would offer in their native states. This also applied to not expecting the output to stop immediately, since some systems would have no way of getting at data already in the "lowest" output buffers. For that matter, I expect the same principle ought to apply to the issue of whether User Telnets need to get into the act at all on stanching the flow, but let that ride.) Therefore, the onus in the case you cite should be on the User Telnet to give the user a way to cause the Generic Function Codes in question to be sent to the Server. Nor should the corresponding onus on ALL Servers to recognize the GFCs be overlooked, by the way-- for, at any rate, each of the Generic Functions they have specific native versions of (i.e., let's not forget Erase, Kill, and Are You There either). Of course, User Telnets are traditionally deficient; that it's traditional doesn't make it right, however: As it says in The Book, the first time I (and Multics) ever was approached by a User Telnet, it couldn't even send lower-case--which Multics needed (and I wanted)--and nearly 18 years (by now) haven't dimmed the indignation (much, anyway). cheers, map -------
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 23:42:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Commercial use of the Internet
John, There are several efforts to make links available from public email carriers into the Internet. DASNET based in San Fracisco area (I think) has one such link. UUNET has UUCP to Internet facility. My company is working on a link between Internet and MCI Mail. We hope to pursue other such links or to encourage them, as appropriate. This does NOT mean that the Internet should be used for commercial purposes - I distinguish between links between commercial organizations and the Internet for purposes of research support, exchanges with the academic and research community and commercial use (i.e. using the facilities of the Internet to support a profit-making enterprise). It should be legitimate for a commercial enterprise to provide for-profit services linking their users to users of the Internet, but the general purpose of such links should be to further exchanges among the R&D community members. A final statement of use and interconnect policy is still the subject of consideration by the members of the FRICC. Vint
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 23:46:01 GMT From: dtmiller@heart-of-gold To: comp.protocols.tcp-ip Subject: Whereabouts of "Comments on the IP Source Route Option"
Does anyone know where I can get a copy (anonymous FTP, preferrably)
of the RFC to be published by J. Postel and J. Reynolds "Comments on the IP
Source Route Option". This RFC to be was referenced in the Draft Host
Requirements Document in the IP Section.
Post to the Internet or send response to:
dtm@mbunix.mitre.org
Thanks in advance!!
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 18 Feb 89 23:49:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECNET
Pete, how about running higher level DECNET stuff above TCP so we can use ordinary IP gateways to tie everything together? Rather like Marshal Rose's ISODE suggestion in which higher level OSI protocols are supported above the TCP layer. Vint Cerf
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 89 06:39:07 GMT From: dpz@pilot.njin.net (David Zimmerman) To: comp.protocols.tcp-ip, tomc@dftsrv.gsfc.nasa.gov Subject: Re: route tracing through gateways
Tom, I've gotten route recording working at Rutgers. You need four conditions to exist to get back the information you want: 1- you have to be able to set up IP options to go out in an IP packet 2- your gateways have to do "the right thing"; that is, each has to look at the IP options, note the IPOPT_RR field, and append its Internet address to that field (if there is room) 3- if your destination machine has to turn the packet around, it must do so correctly (see below) 4- you have to be able to read the IP options out of a packet 4.3BSD-derived systems do the right thing for #1 and #4. cisco gateways do the right thing with #2. I'm not sure whether 4.2BSD-derived systems do the right thing with #1, #2, or #4, since our single link to the outside world is a 4.3BSD VAX here -> 4.2BSD VAX at JVNC, and we're more or less out of that manner of beast around here. However, my experience has been rather negative with 4.2BSD-derived systems in that respect. I wanted to set the IP options for route recording in a ICMP echo packet, so that the echo reply back to me would have the path, or as much of the path as possible, that the packet took. Due to the maximum length of the IP option area, you get a maximum of 9 Internet addresses. My problem was that a target Unix box using 4.xBSD-derived networking would do the wrong thing. 4.3BSD-derived systems (including SunOS 4.x) would send me back an echo reply without any IP options, so I would see that the machine is up, but not be able to tell what path the packet took to get there and back. 4.2BSD-derived systems (including SunOS 3.x) would get confused and not send me back anything, so not only would I not get the route back, I couldn't even tell if the machine was up. I'm not sure if your problem is related to any of this, but... I have fixes to sys/netinet/ip_input.c and sys/netinet/ip_icmp.c to take care of that. I also have a modified ping to send out and parse back these route recording creatures (although the code is a one night hack, and looks it). All our SunOS 4.x Suns and 4.3BSD VAX 11/750 now reflect the ICMP echo back correctly, and we get to see how our routing isn't working. Drop me a line if you are interested. David -- David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc dpz@dorm.rutgers.edu rutgers!dpz dpzimmerman@zodiac.bitnet
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 89 19:49:49 GMT From: stev@VAX.FTP.COM To: comp.protocols.tcp-ip Subject: SysV SLIP
*From: leah!rpi!pawl16.pawl.rpi.edu!brazil@csd4.milw.wisc.edu (Timothy E. Onders) *Subject: SysV SLIP *Does anyone know of a version of SLIP for SysV? I have seen lots of them *for BSD, but we want to run it on a 3B2. Thanks *Timothy Onders i believe that spyder systems (in Burlington mass) has slip for the 3B class of machines. i believe a 3B2 was then machine they used at the other end of the slip line we had at the InterOP(1) show. (1) InterOP is a trademark, i would imagine, of dan lynch's people (ACE).
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 19 Feb 89 23:37:46 GMT From: emv@starbarlounge.cc.umich.edu (Edward Vielmetti) To: comp.protocols.tcp-ip,comp.sources.d Subject: ftp'able software (as posted to tcp-ip list)
Here's a summary of software that people have annouced as being available on the tcp-ip list in the past month or so. This is a very brief list without a lot of accompanying details. zaphod.ncsa.uiuc.edu NCSA Telnet sphere.mast.ohio-state.edu 'phone' athena-dist.mit.edu Kerberos, Zephyr, MIT worm paper bitsy.mit.edu MIT worm paper sumex-aim.stanford.edu imap him1.cc.umich.edu KA9Q for Atari ST w/SLFP support (cd PC7:) sun.soe.clarkson.edu Packet drivers for various PC network devices omnigate.clarkson.edu NCSA Telnet w/packet driver support tolsun.oulu.fi IRC (Internet Relay Chat) ??? IEN 19,24,25,30 -- Edward Vielmetti, U of Michigan Computing Center
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 07:09:01 GMT From: gfengstad@laconn.FIDONET.ORG (Grant Fengstad) To: comp.protocols.tcp-ip Subject: TCP-IP <-> LAN Gateways
Can anyone who has had first hand experience clue me in on what are good choices to look at to gateway a LAN into the TCP-IP protocol. Specifically, Sun workstations to a Novell LAN. I am aware of a few products out there such as: Micom-InterLan, Wollongong, etc. Which are the best and what are the key differences? -- Grant Fengstad - via FidoNet node 1:134/104 UUCP: ...!calgary!xenlink!laconn!gfengstad ARPA: gfengstad@laconn.FIDONET.ORG
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 16:06:11 GMT From: greggt@VAX1.CC.UAKRON.EDU (Gregg Thompson) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.att,comp.sys.ibm.pc,comp.unix.questions,comp.unix.wizards Subject: NEED Network for AT&T and IBM computers running Unix and DOS
PLEASE REPLY VIA MAIL, PLEASE DO NOT WASTE "BANDWITH" ON DISCUSSING THIS MESSAGE I have been asked by a government organization to do some consulting for them. They need to set up a network so I thought I would ask here (Usenet) first to start. PLEASE reply to me AS SOON AS POSSIBLE. They need the information and prices for the network soon so they can bring it up in the next "network committee" meeting next month. EMAIL: greggt@vax1.cc.uakron.edu or greggt@[130.101.2.2] USMAIL Gregg F. Thompson 426 Janes Lane Macedonia, Ohio 44056-1820 I need to network the following type of configuration: AT&T 6386 3B2 IBM PC/XT (Maybe a Macintosh or Sun 386i need something for Desktop Publishing that will network easily with TCP/IP. Any DP WYSIWYG (as you are typing) for the Sun 386i??? Will NeXT sell to local, state, and federal gonvernment agencies?) All of the machines have at least a 20 megs. I need to have a network that will support TCP/IP AND NFS so that ALL the hard disks in the above list will be shared on both DOS and Unix levels. There will also be a need of allowing DOS and Unix to "access each other" in the sense of Unix must be allowed to access DOS data files and DOS must access data files on Unix. The 386 will be running both Unix and DOS if possible (preferred) and we need the ability for the PC to telnet to the Unix "server" (the 386 or 3B2). The network will start off with at least one or 2 of each of the above list and will eventually be networked with several other "offices" of the same configuration and then eventually networked to Internet. The Unix operating system is from AT&T SYSV. NEED NETWORK! Cards and software for Unix and DOS! Thank You!! GRegg P.S. They will eventually need the desktop publishing soon too. -- To live is to die, to die is to live forever; GRegg Thompson Where will you spend eternity? greggt@vax1.cc.uakron.edu
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 16:32:20 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: Re: TELNET and 8-bit ascii codes
One important thing to note about this discussion is its impact on user transparency. Ideally, a user wants to not know what underlying mechanism is used to connect him to his host. It should appear to be a direct cable link while in data transfer. Telnet, as implemented under many Un*x systems, causes problems in this respect. For instance, take a user who is using his PC as an ASCII terminal (YECH) and connecting to a number of hosts using a multiplexer that uses a number of protocols. This user is going to expect to be able to do file transfers over his async connection. If this user gets a real async hookup to his UN*X box, this works fine. If, however he happens to be sent to a Telnet session, this doesn't work. In the days when a user knew that his connection was going to be via Telnet, this may have been acceptable. But, in these days of heterogeneous networks, a non-technical user doesn't want to hear about the details of implementations. This is a call to end the days of "Well, UN*X is supposed to have these quirks. It is a programmers' environment." I think we need to re-think our attitudes and implement our systems with the non-technical end user in mind. The days of saying that UN*X bugs are part of the deal should be over. Lets face it, UN*X should not say that it will send 8 bit data when asked to do so, and then send 7 bit data. (NOTE- this is what SUN 3.5 does). Wishfully speaking Bill VerSteeg
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 18:20:12 GMT From: melpar!toppin@uunet.uu.net (Doug Toppin) To: tcp-ip@sri-nic.arpa Subject: TCP Examples?
Can anyone suggest where I can find some good examples on using TCP/IP? We are using PC/ATs running IBM Xenix with the Network Research Corporation version of TCP called 'Fusion'. We are new to the Ethernet world and would like to see some good public domain examples of software using it. I have the Comer book 'Internetworking with TCP' but it contains little in the way of actual software examples. I'd appreciate any references to books or software available in the archives that anyone can send me. thanks Doug Toppin uunet!melpar!toppin
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 19:42:20 GMT From: sra@MBUNIX.MITRE.ORG (Stan Ames) To: comp.protocols.tcp-ip Subject: IBM MVS TCP-IP
Does any one know of the performance characteristics of IBMs new TCP/IP product for MVS? Of particular interest is TCP performance, FTP performance and NFS performance. Information regarding how faithfully this implementation follows the standards is also of interest. Thanks Stan Ames
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 20 Feb 89 23:33:01 GMT From: abair@oakhill.UUCP (Alan Bair) To: comp.protocols.tcp-ip Subject: Summary- FTP c callable functions
I would like to thank everyone that responded to my request for help with
FTP. Sorry I was not able to respond directly to everyone that sent me
suggestions. And for those that wanted to know what I learned, here is a
summary of the suggestions.
First off, always read ALL of the man page. It turned out that toward the
end, in the section 'FILE NAMING CONVENTIONS', most of what other people
had to say was described. However, the examples made it a lot easier to
understand.
1. Using the filename '-' for the local file in a put or get will cause
FTP to read from stdin or write to stdout. Here is an example
from rpw3@amdcad.UUCP (Rob Warnock):
-----------------------------------------------------------------------------
Try this (setting $HOST, $USER, $PASS, and $DESTFILE as needed):
$ cmd... | (echo $USER; echo $PASS; echo put - $DESTFILE) | ftp $HOST
and the output of "cmd..." should end up in $DESTFILE on $HOST. Same thing
works to retrieve output from a remote site:
$ (echo $USER; echo $PASS; echo get $DESTFILE - ) | ftp $HOST | cmd...
with the remote file showing up as the standard input of "cmd...".
In fact, with some care, binary files usually work, too, but you may run into
problems with error messages ending up in the stream sometimes, etc.
----------------------------------------------------------------------------
This example also demonstrates the piping of commands to FTP, so you
could run it in a shell or in C with system("...") without user
input.
2. The local filename can also be '|program ..." which will cause FTP to either
read stdout of the program in a put or write to stdin of the program
in a get. Here is an example from "Stuart Levy"
<uc.msc.umn.edu!slevy@cs.utexas.edu>:
----------------------------------------------------------------------------
ftp> put "|shellcommand args ..." remote-file
and
ftp> get remote-file "|shellcommand args ..."
so if you can stand to call the pipeline from inside FTP, you can
have it read/write on pipelines rather than disk files.
----------------------------------------------------------------------------
This also gets around the problem of messages possibly ending up in
the data stream, as Rob mentioned above. He also mentioned, that
due to security reasons, this generally is not allowed for the
remote filename.
3. I also had an offer for source code that was C callable and acted like
one end of the FTP connection. However, it turned out that there
were some legal requirements(paperwork) to allow for the transfer.
If your interested, contact:
hermes.chpc.utexas.edu!xxss533@cs.utexas.edu (Kenneth J. Montgomery)
I think a combination of options 1 and 2 should do what I was looking for.
One final point that I failed to make in my first request, the machine at
the other end of the FTP connection is an IBM mainframe running the
Fibronnics KNET software. So some of the suggetions I received would not
have worked, along with some of the above options for the remote filename.
Again, Thanks for all the help.
It makes you wonder what the world would be like without a net.
Alan Bair
UUCP cs.utexas.edu!oakhill!turbinia!abair
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 01:54:18 GMT From: david@ms.uky.edu (David Herron -- One of the vertebrae) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: dumping LANbridge 100 info
Sometime recently I remember someone posting (Phil Karn maybe?) a note about some software
they'd written which did stuff to/from LANbridge 100's. Is my memory right? I looked
through all the 3+ weeks of news we save in these two newsgroups and couldn't find anything.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<-- Stop! Wait! I didn't mean to!
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 03:14:29 GMT From: sale@ed.uucp (Ed Sale) To: comp.protocols.tcp-ip Subject: Re-fragmenting IP Datagrams
I have just spent the large part of the day trying to determine if it is legal for an IP gateway to re-fragment an already fragmented datagram when it attempts to route the datagram from a network with a large MTU (Max Transmission Unit) to one with a smaller MTU. I have perused all *current* RFC's containing the word "fragment" and Douglas Comer's book to no avail. A simplified example of the problem arises when an 8 Kbyte UDP datagram originates on a network whose MTU is 2K bytes. The source must fragment the datagram before sending it and so makes 4 2K byte fragments. The destination of the datagram resides on another network whose MTU is 1 Kbyte. The fragments will be sent from the original source through 1 or more gateways to a gateway directly connected to the 1 Kbyte MTU network. This gateway will encounter fragments too large to send on the destination network. Is it legal for the gateway to make smaller fragments from the larger ones? The problem would also arise if any of the intermediate physical networks along the route had a smaller MTU than the original net. If the gateways can't re-fragment datagrams, the solution that immediately comes to mind is that when the datagram is originally fragmented that it be divided into some *small* fragment size that all gateways and physical nets supporting IP are required to handle. All IP implementations are required to have MTU's of at least 68 bytes one maximum sized (60 byte) IP header with one minimum-sized fragment (8 bytes). I sure hope that this isn't the case. Using this "make minimum-sized-fragments" scheme would reduce the throughput on large MTU nets, however, when sending large datagrams between two endpoints on the same network with an MTU smaller than the datagram size but much larger than the minimum size - unless a test was made before fragmenting to determine what the optimal fragment size should be. What do current implementations do? If there is an RFC addressing this please let me know so that I can read it. I apologize if this topic has been addressed in this newsgroup previously. Thanks for reading this far and (hopefully) responding. Ed Sale ..!uunet!ingr!b11!sale or b11!ed!sale@ingr.com
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 08:49:12 GMT From: trw@hrc63.co.uk (Trevor Wright "Marconi Baddow") To: comp.dcom.lans,comp.protocols.tcp-ip Subject: TRW Terminal Servers (ACU 2000's) v Bridge/3Com...
The TRW range of Access Control Units (Terminal Servers) are now being distributed in the UK. They appear to either run Bridge/3Com 'CS200' binary or their own TRW code. You can boot from a TRW loader or a Bridge NCS/AT. Does anyone have experience of these units, particularly in a mixed Bridge/TRW site - also is there any info on whatever the link between TRW and Bridge is/was... Trevor Wright GEC-Marconi Research Centre Chelmsford UK yc23%uk.co.gec-mrc@uk.ac.ucl.cs.nss
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 13:44:56 GMT From: ken@ingr.com (Ken Cox) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
in article <4014@ingr.com>, sale@ed.uucp (Ed Sale) says: > > I have just spent the large part of the day trying to determine if it is > legal for an IP gateway to re-fragment an already fragmented datagram > when it attempts to route the datagram from a network with a large MTU > (Max Transmission Unit) to one with a smaller MTU. I have perused all > *current* RFC's containing the word "fragment" and Douglas Comer's book > to no avail. > RFC 791 addresses this problem, but you have to read carefully to find it. To summarize, you can fragment as long as the don't fragment bit is not set. The receiving end does not know or care how many times the original datagram has been fragmented. If you look at the fragmentation example in the RFC, it will clearly outline the algorithm for fragmentation (or re-fragmentation.) --Ken Cox
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 13:57:16 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
It is perfectly legal and sometimes necessary to further fragment already fragmented datagrams. One item to watch out for is being sure that the MORE_FRAGMENTS bit is cleared only in the last fragment of the original datagram. That is, if a gateway fragments datagram A into AF1 and AF2, AF1 will have the MORE_FRAGMENTS bit set, while AF2 will have it cleared. If another gateway finds that it must fragment AF1, all of AF1's fragments (including the last one) would have the MORE_FRAGMENTS bit set. Similar considerations apply to the FRAGMENT_OFFSET field. 4.2 BSD got that case wrong the first time around, but it's been fixed for a long time. Thomas
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 14:17:20 GMT From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
Fragmentation is addressed in RFC 791 section 2.4. All Internet hosts must be able to accept, at a minimum, a 576 octet packet. Re-fragmentation of an IP datagram is permitted as long as the "don't fragment" flag is not set.
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 18:54:08 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: TCP/IP and DECNET
In article <8902172114.AA06098@ncsc.ARPA> pete@NCSC.ARPA (Fernandez) writes: > >Fellow SIG Members, > I don't know exactly what would satisfy the following, >but I,m looking for a thing which can smooth the turbulent waters between >TCP/IPers and DECNETters; something that uses the tcp/ip in the appropriate >levels and uses the plusses of decnet in the higher levels. Oh, what you want is "DECNet-over-TCP/IP", better known as DECNOT. This is similar to the concept of plugging ISO application layer protocols on top of TCP/IP, like CMOT, which is CMIP-over-TCP/IP. I was thinking of publishing the specs for DECNOT around the first of April. [note date] I was thinking this might take some of the wind out of DEC's sails when they come out with "ISO-compliant" DECNet Phase V. I like the acronym, DECNOT. Practically speaking, we should call it DECNEVER. The converse stack, "TCP/IP-over-DECNet", known as TIPDEC, is not nearly as feasible as DECNOT. IF all you want is "TCP/IP-over-DDCMP", that's no problem, just order TCPoMP, from Wollamagung software. Kent England, Boston University Disclaimer: None of the above should be taken seriously. It's all a personal whimsy of the author's. Seriously, the desired mongrel stack you seek is unfeasible and you should look for an application layer gateway, like DECNet-on-Ultrix, or run dual stacks on your DEC nodes, like you can with the Wollengong software. You aren't going to see anyone gluing lower layer TCP and DECNet together in any fashion. If you really want to see some fun with application gateways, look for the "transport-gateways" for gluing TCP/IP applications onto ISO applications. That should be fun to watch.
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 18:57:10 GMT From: roy@phri.UUCP (Roy Smith) To: comp.protocols.tcp-ip Subject: Question about route vs. routed
I'm sure this is a naive question, but could somebody give me a
quick rundown on what /etc/route and /etc/routed do on BSD unix? We're on
an ethernet with only one connection to the Internet. People have told me
that instead of running routed on each of my diskless workstations, all I
really have to do is run route from /etc/rc to set up a default route to a
gateway host. Will I see any difference in performance? What happens when
that default gateway host goes down? How will the machines know to switch
to another gateway.
I'm sure you can tell, from the level of the questions, that I'm
sort of new to this internetworking game. Maybe somebody could point me at
the appropriate reading material (RFCs, etc) to fill me in on all this
routing magic?
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 21 Feb 89 23:37:23 GMT From: postel@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
Ed Sale: It is "obviously" correct for a gateway to re-fragment a datagram fragment if it must be sent over a network with a still smaller MTU. --jon.
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 06:57:23 GMT From: hutton@s3sun (Thomas Hutton) To: comp.protocols.tcp-ip Subject: Re: Question about route vs. routed
Routed is the routing daemon which speaks RIP. This is used to pass routing information between hosts in a domain (eg company, campus, etc). This is called an "interior protocol" as it only is used within your domain. The information is used to route between systems and ethernets under your control. Since you state that you only have one connection to the internet, that is your gateway (and default route). In your rc file comment out the /etc/routed lines and add a line of the form /etc/route add 0 gatewayhost 2 where gateway host is your system that talks to the internet. Since this is your only path out, and you only have one ethernet, all your packets for off site destinations should go to that gateway. There is really no reason to want to run any interior routing in your case. Thomas Hutton hutton@scubed.com
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 07:40:51 GMT From: chedley@psu-cs.UUCP (Chedley A. Aouriri) To: comp.protocols.misc,comp.protocols.tcp-ip Subject: TCP-IP conformance testing
Seeking TCP-IP conformance test software ---------------------------------------- I am looking for test software from commercial vendors or in the public domain to validate an implementation of TCP-IP : ie. make sure it is conform to the official DoD recommendations. It seems that, starting June 1, 89, the DCA (Defense Communications Agency) will require any machine running TCP-IP to pass a not-yet specified battery of TCP-IP validation tests before its vendor can sell it to the DoD and/or its related agencies. Please E-mail and I'll summarize to the usenet. Thanks,.. ...CHEDLEY.. Tel. 503-696-4705 ....psueea!psu-cs!chedley
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 11:52:00 EDT From: <ddnmgr@adel01.army.mil> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: Need some help on info
I am interested in getting some information concerning TCP/IP capability for the IBM when the IBM has MVS for the operating system. The two products out there that I have looked into are ACCESS/MVS and IBM's TCP/IP (due to come out in June). The major difference that I can find between these products is that ACCESS gives the capability to use Berkeley sockets while IBM's product gives you the capability to use Wisconsin sockets. As a non-Unix person, this does not tell me anything. Is this an important difference? Any opinions on either of these two products? Our environment is an Ethernet environment going out to DDN through a gateway. We are mainly a Dec environment here with Suns, Convex, and a few Apollos. Thanks for any help! Catherine McDonald DDNMGR@ADEL01.ARMY.MIL 301-394-2659
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Wed, 22 Feb 89 19:21:59 -0600 From: Gurudatta Parulkar <guru@flora.wustl.edu> To: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) Cc: tcp-ip@sri-nic.ARPA Subject: Re: Re-fragmenting IP Datagrams
Fragmentation is addressed in RFC 791 section 2.4. All Internet
hosts must be able to accept, at a minimum, a 576 octet packet.
Re-fragmentation of an IP datagram is permitted as long as the
"don't fragment" flag is not set.
I believe the specifications also require all networks to be able to
forward a 576 octet datagram without fragmentation. I can understand
logic behing this requirement as part of IP specifications. But I
wonder what would happen when the first ATM network joins the internet
with packet size of about 64 bytes. Most of the high speed packet
switches being desinged plan to conform to the ATM standards. In such
a mixed environment, does it make sense for an internet layer to
require a minimum packet size of all component networks. Is the packet
size an attribute to be specified by an internet layer or left to
the underlying networks to decide. What are the performance
implications of doing it one way or the other ?
(Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
in the existing environment, but I am looking beyond.)
I would like to see some discussion on this issue. Note that I am
talking about an internet layer in a generic sense and not challenging
IP specifications.
-guru
Dr. Guru Parulkar
Asst Professor guru@flora.wustl.edu
Dept of Computer Science parulkar@udel.edu
Washington University wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899
(314) 889-4621
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: Wed, 22 Feb 89 15:55:32 EST From: "Barry Appelman" <BEAPPEL%YKTVMX.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.arpa Subject: Sockets on IBM's MVS TCP/IP
Both the VM and MVS TCP/IP from IBM have a Berkeley socket programming interface.
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 1989 19:37-EST From: CERF@A.ISI.EDU To: ingr!ed!sale@UUNET.UU.NET Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Re-fragmenting IP Datagrams
Unless I have completely misunderstood the situation, it is always technically permissible to re-fragment an already fragmented IP DG. That is how fragmentation was designed to work. Vint Cerf
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 15:52:00 GMT From: ddnmgr@ADEL01.ARMY.MIL To: comp.protocols.tcp-ip Subject: Need some help on info
I am interested in getting some information concerning TCP/IP capability for the IBM when the IBM has MVS for the operating system. The two products out there that I have looked into are ACCESS/MVS and IBM's TCP/IP (due to come out in June). The major difference that I can find between these products is that ACCESS gives the capability to use Berkeley sockets while IBM's product gives you the capability to use Wisconsin sockets. As a non-Unix person, this does not tell me anything. Is this an important difference? Any opinions on either of these two products? Our environment is an Ethernet environment going out to DDN through a gateway. We are mainly a Dec environment here with Suns, Convex, and a few Apollos. Thanks for any help! Catherine McDonald DDNMGR@ADEL01.ARMY.MIL 301-394-2659
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 16:28:36 GMT From: sale@ed.uucp (Ed Sale) To: comp.protocols.tcp-ip Subject: Re: Re-Fragmenting IP Datagrams
Thank you all for responding to my query regarding re-fragmentaion of IP datagrams. It is legal. Ed Sale ..!uunet!ingr!b11!sale or b11!ed!sale@ingr.com
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 19:24:24 GMT From: toppin@melpar.UUCP (Doug Toppin) To: comp.protocols.tcp-ip Subject: SOCK_SEQPACKET vs SOCK_STREAM
For TCP/IP: In our environment we have to pass a large number of small messages from a number of processors to a single processor. Due to max open socket limitations on the server the connections cannot be kept open for more than a single message. We are using IBM Xenix V on the AT with NRC Fusion TCP/IP. I am interested in using data grams but the unreliability problems in lost or duplicated messages are a concern. My Questions: * Is there a performance benefit in using the SOCK_SEQPACKET over the SOCK_STREAM options in the socket call (given known data sizes to be sent)? * How unreliable are data grams in a system without a gateway in the real world? (percentage of error) * What is the best approach in sending a large number of small messages where no losses or duplicates getting to the applications software can tolerated? * Is there software in the public domain that will provide a reliable data gram system and fit between applications software and the protocol software? Thanks in advance, reply via mail, useful replies will be posted. Doug Toppin uunet!melpar!toppin
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 19:36:35 GMT From: netcoor@NCS.DND.CA (DRENET Coordinator) To: comp.protocols.tcp-ip Subject: Odd FTP Problem
Has anyone seen, or can anyone explain this problem? We have users on network 128.43 who has reported trouble retreiving files from several hosts in the Internet. The FTP connection is opened and the user and password are exchanged and the login completed message is received. After this, problems occur for any command for which a data connection is to be opened. Other commands not needing the data connection (eg cd, ascii, binary) work as expected, but commands like get and dir fail. The usual message received is: < 425 Can't build data connection: Connection timed out although the message: < 425 Can't build data connection: Network is unreachable. is also common. After this, cd and other commands not needing data connections still work. This problem is variable in that sometimes it strikes and sometimes it doesn't. Sometimes it will interrupt an already started data transfer (the above messages don't apply in this case). Network 128.43 is gatewayed onto the ARPANET through a Butterfly gateway (10.1.0.15). I am on network 192.12.98, which is also gatewayed through the same Butterfly. I have yet to see the problem affect my host (Ultrix). The host affected on net 128.43 is a DEC 2065 running TOPS-20. What confuses me is that packets are being transferred between the two systems over the command connection throughout, yet any attempt to establish a new connection for data fails. Can anyone explain this? I would sure like to understand what is going on to create this situation, then I can try to do something about it. Thanks. Bob Bradford netcoor@ncs.dnd.ca DREnet Coordinator (613) 998-2520
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 20:01:59 GMT From: matthews@udel.EDU (John Matthews) To: comp.protocols.tcp-ip Subject: Anyone used SLIP with 19.2kbaud modems?
Has anyone out there used SLIP reliably with 19.2kbaud modems? Are you happy with the results? We're thinking about buying a couple of these fast modems to use here at Bell Labs as backup network links. We are not as concerned with the lower throughput as we are of being unreachable. If you have had reasonable success could you please let me know what kind of modem you are using and possibly what your best TCP/IP configuration was? By this I mean did you play with the window size or the mss to get higher throughput? Could you please respond to me at "matthews@udel.edu" or "matthews@research.att.com" just in case I don't get a chance to read this newsgroup again before the responses expire? Thanks in advance, John Matthews
-----------[000283][next][prev][last][first]----------------------------------------------------
Date: 22 Feb 89 20:55:32 GMT
From: BEAPPEL@YKTVMX.BITNET ("Barry Appelman")
To: comp.protocols.tcp-ip
Subject: Sockets on IBM's MVS TCP/IPBoth the VM and MVS TCP/IP from IBM have a Berkeley socket programming interface.
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 22 Feb 89 21:42:11 GMT From: desnoyer@Apple.COM (Peter Desnoyers) To: comp.protocols.tcp-ip Subject: Archives?
Is this newsgroup/mailing list archived on any Internet site accessible by anonymous FTP? Thanks Peter Desnoyers
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: Thu, 23 Feb 89 08:27:52 -0500 From: Craig Partridge <craig@SH.CS.NET> To: guru@flora.wustl.edu Cc: tcp-ip@sri-nic.arpa Subject: re: Re-fragmenting IP Datagrams
> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation. I can understand
> logic behing this requirement as part of IP specifications. But I
> wonder what would happen when the first ATM network joins the internet
> with packet size of about 64 bytes. Most of the high speed packet
> switches being desinged plan to conform to the ATM standards. In such
> a mixed environment, does it make sense for an internet layer to
> require a minimum packet size of all component networks. Is the packet
> size an attribute to be specified by an internet layer or left to
> the underlying networks to decide. What are the performance
> implications of doing it one way or the other ?
> (Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
> in the existing environment, but I am looking beyond.)
Guru:
My most recent reading of discussions of ATM (which if memory serves
were in the latest issue of IEEE Network) suggested that the ATM folks
had concluded that they needed some fragmentation/reassembly mechanism
layered on ATM if they were going to support large datagrams. That's
certainly consistent with the idea that ATM is simply a fancy way to
multiplex a gigabit speed line.
More generally, I think something is going to have to do this sort of
fragmentation and re-assembly before data on an ATM network reaches an
end-system (or maybe even an intermediate system). 64 octets implies
a capacity to deliver as many as 2 ** 21 datagrams per second to the
end system at one gigabit/second. That's about one datagram every 3
instructions right now (Using a 6 MIP SUN 4). If you naively
follow the rule of thumb that processors double in speed every two years,
that's still only 12 instructions in 1993! So even if the machine could
interrupt that fast, you haven't a hope of processing the data coming in
(parallel processors *might* help -- depends on how you design your
system). So I suspect someone will have to fragment and aggregate
somewhere in the ATM pipe.
So yes, I think it is perfectly fair to choose a minimum datagram
size (probably based on your minimum expectations of buffering in end-systems).
In a gigabit realm, I'd suggest that size might well be several kilobytes.
Craig
PS: Some people may wonder why I picked the SUN as a candidate end-system.
Many gigabit applications involve viewing graphics or data on graphics
workstations -- I figure SUNs are *a* reasonable prototype of the type
of machine (in cost/horsepower) that people will want to do these things
on in the early 1990s. If you disagree with me, that's fine, choose
your favorite machine architecture and berate me if your numbers are better.
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 00:37:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
Unless I have completely misunderstood the situation, it is always technically permissible to re-fragment an already fragmented IP DG. That is how fragmentation was designed to work. Vint Cerf
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 00:59:21 GMT From: jerry@olivey.olivetti.com (Jerry Aguirre) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
In article <603089521.0.KASHTAN@IU.AI.SRI.COM> KASHTAN@IU.AI.SRI.COM (David L. Kashtan) writes: >>If it's a matter of saving steps why not just build a DCL wrapper >>which does the job? Heck, Interlisp-D had what amounted to a very good >>NFS based on vanilla FTP, required no changes to the server (eg. UNIX >>or VMS) system as I remember. > This is a solution -- though not a pretty one. It loses on several > fronts: > 1) It doesn't address the issues of system management and disk > quotas. It is definitely not a selling point for the software > if you are required to have 2 times the disk space available > in order to transparently transfer the files I think there is a basic misunderstanding here brought about by the different philosophy of Unix and VMS users. The VMS users are assuming that they "backup" or whatever into a file, transfer the file, extract the files, and then cleanup the temporary files used to store the backup image. Thus the requirement for the extra space for the backup. (Don't they have the equivelent of a /tmp directory?) A Unix user implementing the same facility would assume that the data was being "piped" directly from the output of "tar" to the ftp transfer. No temporary file names or disk space would be needed and also no long delay creating the backup before the transfer can start. And of course the ftp output can also be piped into tar on the receiving end to achieve the same benifits. The common usage of pipes in Unix and the ability of tar and dump to use them make this an unspoken assumption.
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 01:19:39 GMT From: guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
Fragmentation is addressed in RFC 791 section 2.4. All Internet
hosts must be able to accept, at a minimum, a 576 octet packet.
Re-fragmentation of an IP datagram is permitted as long as the
"don't fragment" flag is not set.
I believe the specifications also require all networks to be able to
forward a 576 octet datagram without fragmentation. I can understand
logic behing this requirement as part of IP specifications. But I
wonder what would happen when the first ATM network joins the internet
with packet size of about 64 bytes. Most of the high speed packet
switches being desinged plan to conform to the ATM standards. In such
a mixed environment, does it make sense for an internet layer to
require a minimum packet size of all component networks. Is the packet
size an attribute to be specified by an internet layer or left to
the underlying networks to decide. What are the performance
implications of doing it one way or the other ?
(Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
in the existing environment, but I am looking beyond.)
I would like to see some discussion on this issue. Note that I am
talking about an internet layer in a generic sense and not challenging
IP specifications.
-guru
Dr. Guru Parulkar
Asst Professor guru@flora.wustl.edu
Dept of Computer Science parulkar@udel.edu
Washington University wucs1!guru@uunet.uu.net
Campus Box 1045, Bryan 509
One Brookings Drive
St. Louis MO 63130-4899
(314) 889-4621
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Thu, 23 Feb 89 09:57:49 PST From: braden@venera.isi.edu To: guru@flora.wustl.edu, mcc@etn-wlv.eaton.com Cc: tcp-ip@sri-nic.arpa Subject: Re: Re-fragmenting IP Datagrams
I believe the specifications also require all networks to be able to forward a 576 octet datagram without fragmentation. No, I don't think the specs say that. We certainly advise AGAINST networks with MTU's < 576 for performance reasons, but historically there have been several... Packet Radio Net and SATNET, if I remember correctly. If people implement the protocols correctly, communication should still function across a network with small MTU. Bob Braden
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 04:11:43 GMT From: philipp@PHYSICSA.MCGILL.CA (Philip Prindeville Comp Ctr) To: comp.protocols.tcp-ip Subject: Re: Archives?
Date: 22 Feb 89 21:42:11 GMT From: desnoyer@apple.com (Peter Desnoyers) Subject: Archives? To: tcp-ip@sri-nic.arpa Is this newsgroup/mailing list archived on any Internet site accessible by anonymous FTP? Thanks Peter Desnoyers Yes it is: sri-nic.arpa in the TCP-IP: directory. Or you can send mail to action@sri-nic.arpa for more help if you don't have FTP access. In any case, questions like this should *always* go to the list maintainer, not the readership. Next time, try: <tcp-ip-request@sri-nic.arpa>. This applies to most Internet mailing lists. -Philip
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 1989 14:32-PST From: Steve Deering <deering@pescadero.stanford.edu> To: guru@flora.wustl.edu Cc: tcp-ip@sri-nic.arpa, Craig Partridge <craig@SH.CS.NET> Subject: Re: Re-fragmenting IP Datagrams
> I believe the specifications also require all networks to be able to > forward a 576 octet datagram without fragmentation. That's incorrect, Guru. From page 25 of the IP spec (RFC 791): Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. Therefore, every network must be able to deliver 68 bytes of IP in one piece. This is still too long for the silly ATM stuff, but as Craig pointed out, transparent fragmentation and reassembly below the IP level is allowed by the IP architecture (and recommended for networks with ridiculously small MTUs). Steve
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 13:27:52 GMT From: craig@SH.CS.NET (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: Re-fragmenting IP Datagrams
> I believe the specifications also require all networks to be able to
> forward a 576 octet datagram without fragmentation. I can understand
> logic behing this requirement as part of IP specifications. But I
> wonder what would happen when the first ATM network joins the internet
> with packet size of about 64 bytes. Most of the high speed packet
> switches being desinged plan to conform to the ATM standards. In such
> a mixed environment, does it make sense for an internet layer to
> require a minimum packet size of all component networks. Is the packet
> size an attribute to be specified by an internet layer or left to
> the underlying networks to decide. What are the performance
> implications of doing it one way or the other ?
> (Jeff Mogul's paper in SIGCOMM'87 talks about some of the trade-offs
> in the existing environment, but I am looking beyond.)
Guru:
My most recent reading of discussions of ATM (which if memory serves
were in the latest issue of IEEE Network) suggested that the ATM folks
had concluded that they needed some fragmentation/reassembly mechanism
layered on ATM if they were going to support large datagrams. That's
certainly consistent with the idea that ATM is simply a fancy way to
multiplex a gigabit speed line.
More generally, I think something is going to have to do this sort of
fragmentation and re-assembly before data on an ATM network reaches an
end-system (or maybe even an intermediate system). 64 octets implies
a capacity to deliver as many as 2 ** 21 datagrams per second to the
end system at one gigabit/second. That's about one datagram every 3
instructions right now (Using a 6 MIP SUN 4). If you naively
follow the rule of thumb that processors double in speed every two years,
that's still only 12 instructions in 1993! So even if the machine could
interrupt that fast, you haven't a hope of processing the data coming in
(parallel processors *might* help -- depends on how you design your
system). So I suspect someone will have to fragment and aggregate
somewhere in the ATM pipe.
So yes, I think it is perfectly fair to choose a minimum datagram
size (probably based on your minimum expectations of buffering in end-systems).
In a gigabit realm, I'd suggest that size might well be several kilobytes.
Craig
PS: Some people may wonder why I picked the SUN as a candidate end-system.
Many gigabit applications involve viewing graphics or data on graphics
workstations -- I figure SUNs are *a* reasonable prototype of the type
of machine (in cost/horsepower) that people will want to do these things
on in the early 1990s. If you disagree with me, that's fine, choose
your favorite machine architecture and berate me if your numbers are better.
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 14:55:41 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
>I believe the specifications also require all networks to be able to
>forward a 576 octet datagram without fragmentation.
576 is not a lower limit on the size of a datagram fragment, but an
upper limit on what a destination is *required* to accept. The
sender/destination might agree to exchange larger datagrams, but any
such agreements are private to the communicating end points.
From RFC-791:
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
Thomas
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 15:55:02 GMT From: jas@proteon.com (John A. Shriver) To: comp.protocols.tcp-ip Subject: FTP "STRU VMS" extension
First, there is no /tmp in VMS. Face it, /tmp is an arcane leftover from when UNIX ran on machines that did not have virtual memory. There is nothing really like pipes in VMS, especially at the command level. The syntax of the BACKUP command is also very awkward and restrictive. ALso, a pipe would fail to solve the same basic VMS problem. Files are not just a sequence of bytes in VMS. They have a lot of attributes, attributes that must be preserved or the file is useless. (It is better than OS/360, since the system always keeps track of the attributes for you.) Thus, the output of BACKUP, when sent throught a pipe (or transferred via FTP) loses a key attribute: it's extraordinary block size. Also, as noted before, the output of the BACKUP program is not an efficient format. It has a very high degree of redundnacy. You can punch a 1/4" hole in a BACKUP tape and still restore from it. Overkill for what will be transferred over FTP, which we trust more than a tape drive. The VMS folks have a real problem. The binary abstraction of FTP just does not hack it for their files. You will find that they are not the only OS that has addresses this, I think the UCLA MVS TCP/IP FTP allows you to specify a bit of (moral) JCL before writing a file. Let's let them agree on something to solve this problem. Anything to make the VMS users less anti-TCP.
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 17:30:20 GMT From: frg@jfcl.dec.com (Fred R. Goldstein) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
In article <8902230119.AA22877@flora.wustl.edu> guru@FLORA.WUSTL.EDU (Gurudatta Parulkar) writes:
>
> Fragmentation is addressed in RFC 791 section 2.4. All Internet
> hosts must be able to accept, at a minimum, a 576 octet packet.
> Re-fragmentation of an IP datagram is permitted as long as the
> "don't fragment" flag is not set.
>
>I believe the specifications also require all networks to be able to
>forward a 576 octet datagram without fragmentation. I can understand
>logic behing this requirement as part of IP specifications. But I
>wonder what would happen when the first ATM network joins the internet
>with packet size of about 64 bytes. Most of the high speed packet
>switches being desinged plan to conform to the ATM standards.
There is a simple answer to that question. ATM operates within
the (OSIRM) Physical layer, while IP operates within the SNICP role
of the Network layer. As nonadjacent layers, they do not have to
get along.
ATM cells (not "packets") carry fragments of data link layer packets
((or "frames", but not really frames in this case). A segmentation
and reassembly function takes place atop ATM to allow large packets
to be carried. One such technique is proposed in the current 802.6
letter ballot. ANother, called the ATM Adaptation Layer (AAL), has
been bandied about the Broadband ISDN group. It is fatally flawed,
as currently proposed, but it does support long packets. Any number
of workable mechanisms (which would take the Data Link layer into
account) can be created for this purpose.
Or to look at it differently, T1 carrier with D4 channel banks
uses 1-byte fragments, position-interleaved. ATM uses 64-byte
fragments, labeled. But they're both down in mux-land, not in
the subnetwork role that IP has to contend with.
fred (T1S1 member)
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 18:47:52 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: SOCK_SEQPACKET vs SOCK_STREAM
Doug, WHAT YOU NEED IS... a tranaction transport protocol. I suggest you look into Dave Cheriton's VMTP, described in RFC-1045 (see also RFC-955). Bob Braden
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 19:58:20 GMT From: mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) To: comp.protocols.tcp-ip Subject: re: Odd FTP Problem
I've seen this problem in other forms. Apparently there are a lot of
"ICMP Destination Network Unreachable" messages getting sent in instances
where network connectivity is broken for only a brief duration (perhaps due
merely to congestion at a gateway).
Some versions of BSD Unix nuke the connection when this or "host
unreachable" occur; it is reputed that patching location _inetctlerrmap+8 in
the kernel from 0x3341 to 0x0 remedies this problem but I haven't been able to
verify it.
Since the "425 Can't build data connection" message is coming from the
remote server, it suggests that the problem is occuring when the remote server
tries to open a connection to the FTP client on the 128.43 TOPS-20 host.
Because of this, I'm inclined to absolve the TOSP-20 host of guilt
(particularly in the "Network is unreachable" case), and more likely to blame
network routing.
Question: could an ICMP Destination Network Unreachable happen when
something like an X.25 virtual circuit limitation is reached?
-------
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 21:18:47 GMT From: martinea@CRC.SKL.DND.CA (Mike Martineau) To: comp.protocols.tcp-ip Subject: Dial up slip
I remember seeing a number of messages regarding dial up slip in the past month. I suddenly have an urgent need to get more info re: dial up slip but, unfortunately, did not save any of the previous mail messages. Can someone point me in the right direction? Thanks, Michael Martineau Software Kinetics Ltd. martinea@crc.skl.dnd.ca (192.5.204.1)
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 22:32:00 GMT From: deering@PESCADERO.STANFORD.EDU (Steve Deering) To: comp.protocols.tcp-ip Subject: Re: Re-fragmenting IP Datagrams
> I believe the specifications also require all networks to be able to > forward a 576 octet datagram without fragmentation. That's incorrect, Guru. From page 25 of the IP spec (RFC 791): Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. Therefore, every network must be able to deliver 68 bytes of IP in one piece. This is still too long for the silly ATM stuff, but as Craig pointed out, transparent fragmentation and reassembly below the IP level is allowed by the IP architecture (and recommended for networks with ridiculously small MTUs). Steve
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 23 Feb 89 23:17:48 GMT From: davy@RIACS.EDU To: comp.protocols.tcp-ip Subject: Header Processing Times
One of the researchers here is looking for information about how long it takes to process a "network packet". For the type of stuff she needs, it really doesn't matter what "network packet" is, it could be TCP/IP, DECNET, XNS, whatever. TCP/IP or OSI would probably be best, though. Anyway, what she's looking for is stuff which answers questions like, "given a bunch of data to send, how long does it take to stick the headers on, increment the sequence number, compute the ckecksums, etc. before sticking the packet on the wire?" The timings can be for any arbitrary processor, although something "well known" like a Vax, Sun, or PC would be preferred. Hopefully the above is clear. If anyone has any data like this they'd be willing to let us have, or any pointers to published work on the above, please reply to me (not the list) via mail. If there's enough interest, I'll summarize my findings back to the list. Thanks, Dave Curry Research Institute for Advanced Computer Science davy@riacs.edu
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 00:40:47 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
does not hack it for their files. You will find that they are not the only OS that has addresses this, I think the UCLA MVS TCP/IP FTP allows you to specify a bit of (moral) JCL before writing a file. Yes, the UCLA MVS ACP implements the FTP SITE command with keyword parameters calculated to warm the heart of a JCL-lover -- BLKSIZE(), RECFM(), LRECL()... all that wonderful stuff! (yukh) Bob Braden
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 01:34:52 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: What seems to be a glitch in the TCP spec.
Consider the following situation: A TCP connection is carrying
intermittent, bidirectional traffic. Host A has just sent a burst
which filled host B's window. B has enough data for a small segment,
piggybacking the Ack and indicating a window of 0. A replies with an
Ack, just as B's application consumes the data and B sends a segment
to re-open the window. B's implementor has chosen to retransmit the
first segment of un-acked data (if any) with window updates and Acks
(B's cost/packet is much larger than the cost/byte). A's implementor
has exactly followed pg. 69 of RFC 793, which says to discard segments
with obsolete data before checking the Ack or Window values.
Host A Host B
1. <- Seq 100, Ack 200, Data 20, Window 0
2. Seq 200, Ack 120, Data 0, Window 4076 -> (crosses w/3)
3. <- Seq 100, Ack 200, Data 20, Window 4096 (Dropped per pg. 69)
4. Seq 200, Ack 120, Data 0, Window 4076 -> (ignored, pg. 72)
Segments 2 and 3 cross in transit, A drops 3 before checking either the
Ack or the window and sends 4, which B drops as a duplicate Ack. At
this point, A has more data to send, but B doesn't. Everyone has followed
the spec, but A didn't see B's window re-open, and the connection will
sit idle until A sends a window-probe segment. The user is unhappy,
because a TCP-based window system glitches.
I see four possible solutions:
1. Tell the user that he has found a glitch in the spec, and he should
be glad that heterogenous networking works at all. See Figure 1.
2. Amend the spec to warn that "window updates and acks may be ignored
if they accompany retransmitted data; therefore this should be avoided".
3. Amend the spec to require that the first window-probe segment be sent
when the window stays zero for two round-trip times. If the probe is
rejected, try again in a couple of minutes.
4. Amend the spec to require that, when a segment is about to be dropped
per pg. 69, if the segment is immediately to the left of the window (e.g.
(SEG.SEQ + SEG.LEN) == RCV.NXT), SEG.ACK should be checked, and if it
is valid (SEG.ACK >= SND.UNA), both the Ack and the Window should be
processed before the segment is discarded and the obligatory Ack sent.
Note that pg. 72 of the RFC has an error. As corrected in the upcoming
"Requirements for Internet Hosts" RFC, the send window should be updated
even when SEG.ACK == SND.UNA (otherwise TCP could not continue without
a window probe once the send window went to 0).
I don't like solution 1 (after all, I want the customer's money). I have
discussed this matter with some other TCP implementors, who don't like
solution 2, particularly when applied to Telnet connections. Solution
3 is partially implemented in some TCPs (the first probe occurs after
about 4 sec.), but there is still a glitch. I've fully implemented
solution 4, and have two years of experience with it (in a commercial
product). It seems to work, and the only objection I can think of is
a miniscule increase in the probability of the connection being reset
due to an old duplicate segment (the mechanism is "ack of unsent data",
not accepting bad data, and the odds of this are still way below those
of damaged data escaping detection by the TCP checksum).
Comments? In particular, have I missed something relevant in RFC 793?
Has someone else already addressed this issue in some publication other
than an RFC?
One TCP implementor I discussed this with asked: "Is there any particular
reason why we couldn't amend the spec to say 'check all acks, regardless
of the sequence field?'?" Any comments on this?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000303][next][prev][last][first]----------------------------------------------------
Date: 24 Feb 89 06:20:27 GMT
From: reschly@BRL.MIL ("Robert J. Reschly Jr.")
To: comp.protocols.tcp-ip
Subject: Re: Odd FTP Problem
Mark,
A couple of weeks ago BRL noted severe difficulties with
connectivity. We were able to trace this to ICMP Network Unreachables
(we're a BSD shop), which appeared to be the result of core route
"flopping". At the end of this message, I'll tack on the message I sent
to BBN on the subject. The raw data file mentioned in that message
is still available if anyone is masochisitic enough to want to look at
it.
When we spoke to BBN the afternoon before sending that message, they
told us they had identified a problem with routing, and a message
received the next afternoon confirmed that a fix to the problem alluded
to in the phone conversation would be fielded in the next few days. By
mid-week the following week, connectivity did indeed appear to be better
than previously.
Since this last change, we still see more routing variability than we
feel should be present though it does look better than before the
change. One curious thing, has anyone else noticed the EGP peers
bouncing in and out? We peer with BMILDCEC, BMILBBN, and BMILMTR in
that order (though we only exchange updates with one at any given time),
and we are continually having to re-acquire one or more of these
beasties (as I write this, the gateway is trying to acquire BMILMTR).
Have these gateways been bouncing up and down a lot? We have also
started looking at the EGP information we are getting a little more
closely, and have seen hopcounts as high as 62(!).
In the last few days, our PSN insufficient resource (type 4)
messages are haunting us again. We had earlier reported these and BBN
reconfigured our PSN with more space allocated to buffers to lessen the
severity of that problem. I suppose we'll have to complain about this
again.
Has anyone else noted any interesting behavior since the change?
Later,
Bob
--------
Phone: (301)278-6678 AV: 298-6678 FTS: 939-6678
Arpa: reschly@BRL.MIL (or BRL.ARPA) UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
U.S. Army Ballistic Research Laboratory
Systems Engineering and Concepts Analysis Division
Advanced Computer Systems Team
ATTN: SLCBR-SE (Reschly)
APG, MD 21005-5066 (Hey, *I* don't make 'em up!)
**** For a good time, call: (303) 499-7111. Seriously! ****
================
Date: Thu, 9 Feb 89 5:51:55 EST
From: "Robert J. Reschly Jr." <reschly@brl.mil>
To: meason@wash.bbn.com, amalis@bbn.com
cc: jcst@BRL.MIL
Subject: More Node 29 troubles.
Mike,
Here is a summary of our recent experience and a copy of Phil's message.
First, the incompletes are still with us though they appear to be at
the reduced level we noted after the PSN buffer configuration changes.
The only note here is that these messages are still coming in at a much
greater rate than before our switching to EGP peering with the
Buttergates. We are currently seeing these 5 to 10 (on average) times
an hour, rather than 5 to 10 times a day.
Second, as Phil notes in the enclosed message, we have been suffering
from what looks like significant routing instability since switching to
EGP peering with the Buttergates. The variability in numbers of reported
routes was noted as soon as we switched, but we did not notice any actual
reachability problems until a while later. A typical sequence would be:
Establish a connection (e.g. FTP, TELNET, rlogin); everything
appears fine, connectivity is good and round trip times are
reasonable.
After a few minutes of operation, suddenly the the connection
freezes. The connection usually closes at this time.
Attempt to restart the connection -- this usually fails
Wait a few minutes, then attempt to restart the connection.
This usually succeeds as if there was never any problem. At
this point the cycle repeats.
Running an experiment with ping shows that the loss of communication
coincides with the receipt of ICMP Network Unreachable messages. I ran
a ping experiment against louie.udel.edu to see if I could duplicate
and record the symptoms today. I'll include a summary from the first
part of that at the end of this message, and will put the raw data,
(roughly 1.3MB collected over 4 hours between 1800 EST and 2200 EST 8
Feb 1989) in the public FTP area of vgr.brl.mil. Note that since this
is a script of a terminal session, there are a few control characters
and escape sequences buried in this file. We currently EGP peer with
the buttergates at DCEC and CAMBRIDGE as our primary and fallback.
I have also made some changes to the gateway software to extract a
bit more information but have nothing to present at this time.
The raw data is the composite of a 15 second timestamp loop, the
ping, and the gateway console all smashed together and intertwingled.
The ping generates the "xx bytes" messages as well as the verbose dumps
of most other ICMP messages. Much of the gateway console output is
prepended by "<process_name>: ", though there are a few messages which
are different (e.g. "ICMP redirect" and "UPTIME" messages. The gateway
software is of local origin. If you have any questions about any of it,
get in touch with us and we will clarify.
Finally, you will find a number of "milr: msg with link 27 from
4/48" followed by an equal number of "milr: pack len <value1>, format 15,
illen <value2>" messages. The values range over a small set for each.
We only started noticing these today, but had not been closely watching
the gateway for the few days prior to today. The "link" parameter is
the link type from the IMP leader -- we are 1822 connected.
I hope this stuff helps.
Later,
Bob
--------
Phone: (301)278-6678 AV: 298-6678 FTS: 939-6678
Arpa: reschly@BRL.MIL (or BRL.ARPA) UUCP: ...!brl-smoke!reschly
Postal: Robert J. Reschly Jr.
U.S. Army Ballistic Research Laboratory
Systems Engineering and Concepts Analysis Division
Advanced Computer Systems Team
ATTN: SLCBR-SE (Reschly)
APG, MD 21005-5066 (Hey, *I* don't make 'em up!)
**** For a good time, call: (303) 499-7111. Seriously! ****
----- Forwarded message # 1:
Received: from smoke.brl.mil by SEM.BRL.MIL id aa07207; 2 Feb 89 7:56 EST
Received: from SMOKE.BRL.MIL by SMOKE.BRL.MIL id aa12789; 2 Feb 89 7:52 EST
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa12653; 2 Feb 89 7:45 EST
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Thu, 2 Feb 89 01:47:18 PST
Date: Thu, 2 Feb 89 4:41:04 EST
From: Phil Dykstra <phil@BRL.MIL>
To: tcp-ip@sri-nic.arpa
Subject: Instability in the Core
Message-ID: <8902020441.aa16937@VGR.BRL.MIL>
Tonight I was trying to talk to some machines on XEROX-NET (net 13), and
once again was hit with oscillating Net-Up/Net-Unreachable. This has been
happening to me for the past several days for net 13 as well as several
other nets (FYI, I'm 26.2.0.29).
We have been getting EGP info from the RESTON-DCEC Butterfly (26.21.0.104).
I started watching tonight to see why these routes kept appearing and
disappearing and found major unrest in the routing information we were
getting. Here are nine consecutive EGP routing updates (taken at three
minute intervals). They span 0400 EST.
Int Ext Routes (~A B C)
5 95 479
6 85 536
5 95 401
6 86 598 17 333 263
6 84 507 15 266 241
5 94 456 8 270 193
6 91 599 16 335 263
4 93 453 8 266 194
6 87 580 17 321 257
The fields are number of internal and external EGP gateways, total number
of routes, and the approximate number of class A, B, and C (approx because
this includes a few of our fixed routes). I have complete EGP dumps for
the last six updates if anyone wishes to study the changes.
It really bothers me that the number of class A networks could double/half
every three minutes! There is also a 10% to 50% change in the total number
of routes every three minutes. One wouldn't expect the number of internal
EGP gateways to change so fast either [thought the LSI-11's used to flop
like that too].
It is nearly impossible to get data through when the routes come and go
this fast. I realize that the Butterfly folks are probably working on
this, but I wasn't sure everyone was aware how bad things are right now
(I recall one other TCP-IP note about it). Is there anything we can do
to help diagnose this?
- Phil
<phil@brl.mil>
uunet!brl!phil
----- End of forwarded messages
================
Script started on Wed Feb 8 18:11:57 1989
PING louie.udel.edu (128.175.1.3): 56 data bytes
64 bytes from 128.175.1.3: icmp_seq=0 time=466 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=95 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=96 time=981 ms
Wed Feb 8 18:14:15 EST 1989
64 bytes from 128.175.1.3: icmp_seq=96 time=1948 ms <<<DUPLICATE!
64 bytes from 128.175.1.3: icmp_seq=97 time=1084 ms
64 bytes from 128.175.1.3: icmp_seq=98 time=451 ms
64 bytes from 128.175.1.3: icmp_seq=99 time=514 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=175 time=566 ms
Wed Feb 8 18:15:36 EST 1989
64 bytes from 128.175.1.3: icmp_seq=176 time=414 ms
64 bytes from 128.175.1.3: icmp_seq=177 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=178 time=414 ms
64 bytes from 128.175.1.3: icmp_seq=179 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=180 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=181 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=182 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=183 time=599 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a304 0 0000 fb 01 c3e4 c0051708 80af0103
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a30f 0 0000 fb 01 c3d9 c0051708 80af0103
... 21 more net unreachables deleted ...
egp: default of 26.1.0.49 with 293 routes <<<GATEWAY EGP UPDATE
egp: 87 gwys, 6 int, 81 ext (565 routes).
ip: 587 routes, 15 A, 306 B, 259 C, 7 S, 0 O.
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a3a4 0 0000 fb 01 c344 c0051708 80af0103
Wed Feb 8 18:16:09 EST 1989
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a3aa 0 0000 fb 01 c33e c0051708 80af0103
... 45 more net unreachables deleted ...
milr: msg with link 27 from 4/48 <<<FUNNY AFWL MESSAGES
milr: pack len 2352, format 15, illen 28681 <<<"4/48" IS PORT/NODE
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a4c1 0 0000 fb 01 c227 c0051708 80af0103
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a4c6 0 0000 fb 01 c222 c0051708 80af0103
Wed Feb 8 18:16:58 EST 1989
... 42 more net unreachables deleted ...
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a5f3 0 0000 fb 01 c0f5 c0051708 80af0103
64 bytes from 128.175.1.3: icmp_seq=300 time=633 ms <<< ONLY DROPPED 3PKTS
64 bytes from 128.175.1.3: icmp_seq=301 time=733 ms
Wed Feb 8 18:17:47 EST 1989
64 bytes from 128.175.1.3: icmp_seq=302 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=303 time=881 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a605 0 0000 fc 01 bfe3 c0051708 80af0103
64 bytes from 128.175.1.3: icmp_seq=304 time=1248 ms
64 bytes from 128.175.1.3: icmp_seq=306 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=307 time=748 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=331 time=1381 ms
Wed Feb 8 18:18:19 EST 1989
64 bytes from 128.175.1.3: icmp_seq=333 time=933 ms
milr: msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
64 bytes from 128.175.1.3: icmp_seq=334 time=1281 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=384 time=784 ms
64 bytes from 128.175.1.3: icmp_seq=386 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=387 time=651 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=410 time=766 ms
Wed Feb 8 18:19:40 EST 1989
64 bytes from 128.175.1.3: icmp_seq=411 time=833 ms
64 bytes from 128.175.1.3: icmp_seq=412 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=413 time=548 ms
64 bytes from 128.175.1.3: icmp_seq=414 time=766 ms
64 bytes from 128.175.1.3: icmp_seq=415 time=848 ms
64 bytes from 128.175.1.3: icmp_seq=416 time=633 ms
egp: default of 26.1.0.49 with 232 routes <<< GATEWAY EGP UPDATE
egp: 86 gwys, 6 int, 80 ext (434 routes).
ip: 456 routes, 14 A, 243 B, 192 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=417 time=848 ms <<< 1 MORE PACKET THEN
Wed Feb 8 18:19:56 EST 1989 <<< NOTHING UNTIL
Wed Feb 8 18:20:12 EST 1989
Wed Feb 8 18:20:28 EST 1989
milr: msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
Wed Feb 8 18:20:44 EST 1989
Wed Feb 8 18:21:00 EST 1989
milr: incomplete 15/115 3
Wed Feb 8 18:21:16 EST 1989
64 bytes from 128.175.1.3: icmp_seq=514 time=418 ms <<< HERE
... through ...
64 bytes from 128.175.1.3: icmp_seq=534 time=499 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a836 0 0000 fc 01 bdb2 c0051708 80af0103
64 bytes from 128.175.1.3: icmp_seq=536 time=514 ms
Wed Feb 8 18:21:49 EST 1989
64 bytes from 128.175.1.3: icmp_seq=537 time=533 ms
36 bytes from localhost (127.0.0.1): Destination Port Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 003d a842 0 0000 1e 11 0000 7f000001 7f000001
UDP: from port 53, to port 3500 (decimal)
64 bytes from 128.175.1.3: icmp_seq=538 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=539 time=448 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=546 time=448 ms
92 bytes from BRL.ARPA (26.2.0.29): Source Quench
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 a882 0 0000 fc 01 bd66 c0051708 80af0103
64 bytes from 128.175.1.3: icmp_seq=547 time=5048 ms <<< UNUSUAL DELAY
64 bytes from 128.175.1.3: icmp_seq=548 time=4181 ms
Wed Feb 8 18:22:05 EST 1989
64 bytes from 128.175.1.3: icmp_seq=552 time=2381 ms
64 bytes from 128.175.1.3: icmp_seq=553 time=2266 ms
64 bytes from 128.175.1.3: icmp_seq=554 time=2099 ms
64 bytes from 128.175.1.3: icmp_seq=555 time=1866 ms
64 bytes from 128.175.1.3: icmp_seq=556 time=1448 ms
64 bytes from 128.175.1.3: icmp_seq=557 time=999 ms
64 bytes from 128.175.1.3: icmp_seq=558 time=433 ms
64 bytes from 128.175.1.3: icmp_seq=559 time=533 ms
... through ...
Wed Feb 8 18:23:58 EST 1989
64 bytes from 128.175.1.3: icmp_seq=662 time=518 ms
64 bytes from 128.175.1.3: icmp_seq=663 time=518 ms
64 bytes from 128.175.1.3: icmp_seq=664 time=499 ms
64 bytes from 128.175.1.3: icmp_seq=665 time=551 ms
64 bytes from 128.175.1.3: icmp_seq=666 time=451 ms
64 bytes from 128.175.1.3: icmp_seq=667 time=418 ms
64 bytes from 128.175.1.3: icmp_seq=668 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=669 time=466 ms
64 bytes from 128.175.1.3: icmp_seq=670 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=671 time=633 ms
64 bytes from 128.175.1.3: icmp_seq=672 time=433 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 aa58 0 0000 fb 01 bc90 c0051708 80af0103
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 aa64 0 0000 fb 01 bc84 c0051708 80af0103
... 174 more net unreachables deleted ...
64 bytes from 128.175.1.3: icmp_seq=848 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=849 time=833 ms
Wed Feb 8 18:27:14 EST 1989
64 bytes from 128.175.1.3: icmp_seq=850 time=751 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=878 time=833 ms
egp: default of 26.1.0.49 with 318 routes
egp: 83 gwys, 6 int, 77 ext (569 routes).
ip: 591 routes, 15 A, 311 B, 258 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=879 time=918 ms
64 bytes from 128.175.1.3: icmp_seq=880 time=1051 ms
Wed Feb 8 18:27:46 EST 1989
64 bytes from 128.175.1.3: icmp_seq=881 time=818 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=895 time=551 ms
64 bytes from 128.175.1.3: icmp_seq=896 time=851 ms
Wed Feb 8 18:28:02 EST 1989
64 bytes from 128.175.1.3: icmp_seq=897 time=1151 ms
64 bytes from 128.175.1.3: icmp_seq=895 time=3833 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=898 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=899 time=933 ms
64 bytes from 128.175.1.3: icmp_seq=900 time=584 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=1039 time=566 ms
64 bytes from 128.175.1.3: icmp_seq=1039 time=766 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1040 time=748 ms
... though ...
64 bytes from 128.175.1.3: icmp_seq=1115 time=748 ms
64 bytes from 128.175.1.3: icmp_seq=1116 time=499 ms
Wed Feb 8 18:31:49 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1117 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=1118 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1119 time=533 ms
64 bytes from 128.175.1.3: icmp_seq=1120 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1121 time=533 ms
64 bytes from 128.175.1.3: icmp_seq=1121 time=781 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1122 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1124 time=981 ms <<< MISSING 1123
64 bytes from 128.175.1.3: icmp_seq=1125 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1126 time=548 ms
64 bytes from 128.175.1.3: icmp_seq=1127 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1128 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1129 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1130 time=666 ms
64 bytes from 128.175.1.3: icmp_seq=1131 time=681 ms
64 bytes from 128.175.1.3: icmp_seq=1132 time=681 ms
Wed Feb 8 18:32:06 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1133 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1134 time=514 ms
egp: default of 26.1.0.49 with 276 routes <<< GATEWAY EGP UPDATE
egp: 88 gwys, 6 int, 82 ext (492 routes).
ip: 514 routes, 16 A, 267 B, 224 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=1135 time=814 ms
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 b1ae 0 0000 fb 01 b53a c0051708 80af0103
36 bytes from RESTON-DCEC-MB.DDN.MIL (26.21.0.104): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 b1b3 0 0000 fb 01 b535 c0051708 80af0103
... 73 more net unreachables deleted ...
milr: msg with link 27 from 4/48 <<< ANOTHER LINK MESSAGE
milr: pack len 2370, format 15, illen 10
Wed Feb 8 18:33:29 EST 1989
milr: incomplete 3/13 4 <<< THESE SEEM MORE COMMON
milr: incomplete 3/13 4 <<< WHEN RESTON IS COMPLAINING
milr: incomplete 3/13 3
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
Wed Feb 8 18:33:45 EST 1989 <<< A BUNCH MORE MISSING
Wed Feb 8 18:34:01 EST 1989
milr: msg with link 27 from 4/48
milr: pack len 2352, format 15, illen 28681
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr: msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr: msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
milr: msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
Wed Feb 8 18:34:17 EST 1989
milr: msg with link 27 from 4/48
milr: pack len 2370, format 15, illen 10
milr: msg with link 27 from 4/48
milr: pack len 2378, format 15, illen 16394
Wed Feb 8 18:34:34 EST 1989
Wed Feb 8 18:34:50 EST 1989
Wed Feb 8 18:35:06 EST 1989
Wed Feb 8 18:35:22 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1330 time=581 ms
64 bytes from 128.175.1.3: icmp_seq=1331 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1332 time=614 ms
64 bytes from 128.175.1.3: icmp_seq=1333 time=481 ms
64 bytes from 128.175.1.3: icmp_seq=1334 time=748 ms
64 bytes from 128.175.1.3: icmp_seq=1335 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1336 time=599 ms
64 bytes from 128.175.1.3: icmp_seq=1337 time=448 ms
64 bytes from 128.175.1.3: icmp_seq=1338 time=499 ms
Wed Feb 8 18:35:38 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1339 time=566 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=1401 time=818 ms
Wed Feb 8 18:36:44 EST 1989
egp: default of 26.1.0.49 with 228 routes
egp: 88 gwys, 6 int, 82 ext (529 routes).
ip: 551 routes, 14 A, 299 B, 231 C, 7 S, 0 O.
64 bytes from 128.175.1.3: icmp_seq=1402 time=848 ms
64 bytes from 128.175.1.3: icmp_seq=1403 time=1199 ms
64 bytes from 128.175.1.3: icmp_seq=1404 time=681 ms
64 bytes from 128.175.1.3: icmp_seq=1404 time=699 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1404 time=1166 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1405 time=514 ms
64 bytes from 128.175.1.3: icmp_seq=1406 time=699 ms
64 bytes from 128.175.1.3: icmp_seq=1407 time=766 ms
64 bytes from 128.175.1.3: icmp_seq=1408 time=881 ms
64 bytes from 128.175.1.3: icmp_seq=1409 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1410 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1410 time=714 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1411 time=648 ms
64 bytes from 128.175.1.3: icmp_seq=1412 time=1248 ms
64 bytes from 128.175.1.3: icmp_seq=1413 time=1148 ms
64 bytes from 128.175.1.3: icmp_seq=1414 time=814 ms
64 bytes from 128.175.1.3: icmp_seq=1415 time=933 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=1493 time=884 ms
64 bytes from 128.175.1.3: icmp_seq=1494 time=866 ms
64 bytes from 128.175.1.3: icmp_seq=1494 time=1833 ms <<< DUPLICATE
64 bytes from 128.175.1.3: icmp_seq=1495 time=1051 ms
64 bytes from 128.175.1.3: icmp_seq=1496 time=799 ms
64 bytes from 128.175.1.3: icmp_seq=1497 time=866 ms
Wed Feb 8 18:38:23 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1498 time=618 ms
... through ...
64 bytes from 128.175.1.3: icmp_seq=1749 time=718 ms
Wed Feb 8 18:42:44 EST 1989
64 bytes from 128.175.1.3: icmp_seq=1750 time=818 ms
64 bytes from 128.175.1.3: icmp_seq=1751 time=1133 ms
64 bytes from 128.175.1.3: icmp_seq=1752 time=818 ms
64 bytes from 128.175.1.3: icmp_seq=1753 time=1318 ms
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 bba1 0 0000 fb 01 ab47 c0051708 80af0103
36 bytes from MCLEAN-MB.DDN.MIL (26.20.0.17): Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 0054 bba6 0 0000 fb 01 ab42 c0051708 80af0103
...and the data goes on for roughly three more hours ....
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: Fri, 24 Feb 89 14:20:19 EST From: Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU> To: Toerless Eckert <mcvax!unido!fauern!faui44!eckert@uunet.uu.net>, tcp-ip@sri-nic.arpa Subject: Re: Utilities for nameserver wanted
>I am looking for utilities that can help me with the internet nameserver. >I would like to have a program that queries the nameserver of different >zones and generates a /etc/hosts compatible file from the resource >records, for those hosts in our LAN that can not use the nameserver. >I am also interested in programs that help creating nameserver >database files, especially for the PTR records. I don't worry about the former - I just fetch the "hosts" format lists from several different domains I'm interested in, plus the NIC hosts list. I'm anxiously awaiting the day when all our systems will call domain service instead, though. I have a number of awk scripts and a small program that you might be interested in. I maintain data for my local domain in "hosts.txt" format, almost identical to that used by SRI-NIC. A couple of the awk scripts convert this format to the "/etc/hosts" and "named" formats. The program, "ndrev", takes the "named" format records and generates "PTR" entries for hosts in a given (sub-)network. If you are interested in any of these, take a look at the files in "src/hostmaint" on serv1.cl.msu.edu. Doug Nelson Michigan State University
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 15:49:06 GMT From: bzs@ENCORE.COM (Barry Shein) To: comp.protocols.tcp-ip Subject: FTP "STRU VMS" extension
From: jas@proteon.com (John A. Shriver) >The VMS folks have a real problem. The binary abstraction of FTP just >does not hack it for their files. You will find that they are not the >only OS that has addresses this, I think the UCLA MVS TCP/IP FTP >allows you to specify a bit of (moral) JCL before writing a file. > >Let's let them agree on something to solve this problem. Anything to >make the VMS users less anti-TCP. Ok, I can live with this but...VMS is a proprietary operating system managed by exactly one corporation. I hear DEC is supporting or soon to support TCP on VMS, do they have any proposals in this realm? If DECNET solves this problem then DECNET over IP might be a better way to deal with this issue as it simply provides a lower layer for transport and any changes in the file attributes etc by DEC can be punted to DECNET support, it can be the only layer aware of such things and as long as the DECNET packets flow all should be well. We *are* talking VMS<->VMS communications here, right? And at least one vendor already offers DECNET over IP, so the only real question is whether this combination already or could in the near future solve the problem. I could see an encapsulation standard (RFC) for DECNET/IP as a way to acheive this in a uniform manner among vendors. At least that model could lead to dealing with other proprietary systems and network protocols, as it has in the past (eg. RSCS over IP, CHAOS over IP, XNS over IP, etc.) -Barry Shein, ||Encore||
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 16:00:12 GMT From: hal@GATEWAY.MITRE.ORG (Hal Feinstein) To: comp.protocols.tcp-ip Subject: IP access control
Who knows if anything was/is/will be done to permit what DoD people call "discretionary" access control at the IP level. Forms include "filtering" based on host identity (address), host membership in a discretionary access control group, member of a subnet (perhaps via the IPSO and an RSA-like certificate). I'm told that the new thing for all sorts of access control problems is RSA-like certificates. Hope we can stand the overhead.
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 16:24:17 GMT From: jas@proteon.com (John A. Shriver) To: comp.protocols.tcp-ip Subject: Odd FTP Problem
Well Mark, that indeed sounds like a great way to improve the antisocial behaviour of 4.[23]bsd in the face of ICMP host and net unreachables. I looked at the source (ip_input.c, tcp_subr.c, protosw.h), and it certainly seems that will have the deisred result. The u_char array inetctlerrmap (in ip_input.c) maps the generic error types from protosw.h to error numbers from errno.h. Offsets 8 and 9 are (protosw.h): #define PRC_UNREACH_NET 8 /* no route to network */ #define PRC_UNREACH_HOST 9 /* no route to host */ which are mapped repsectively to (errno.h): #define ENETUNREACH 51 /* Network is unreachable */ #define EHOSTUNREACH 65 /* No route to host */ Entries in that array which are 0 do not cause user errors. Patching 8 & 9 to zero should do this. Here's an example. Be careful to use lower case `w'. # adb -w /vmunix /dev/kmem inetctlerrmap?w0 patches disk inetctlerrmap/w0 patches memory I have not tried this, no guaruntees. It looks like this works in 4.3bsd, Ultrix 2.2, and SunOS 3.5. It still is not the optimal solution, which would be to pass a warning to the user layer, so they could decide what to do. I suspect that is why there is a /* XXX */ at the end of tcp_ctlinput() in tcp_subr.c. (/* XXX */ is Berkeley shorthand for kludge, should be fixed.) There are no comments on the entire subroutine. Any 4.3bsd gurus out there like to verify this?
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 16:39:06 GMT From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) To: comp.protocols.tcp-ip Subject: updated sendmail on ucbarpa
We've found a few problems in some of the tcp mailer rulesets that were included in the recent sendmail distribution on ucbarpa. They have been fixed and the distribution updated. We've also included some additional documentation on the configuration files as well as some support routines and include files to make it easier to install under Sun OS and Ultrix. --keith
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 17:36:45 GMT From: campbell@hpbsla.HP.COM (gary campbell) To: comp.protocols.tcp-ip Subject: Need help with NCSA V2.2 problem
I am having some trouble with NCSA Telnet V2.2. I have a HP Vectra ES12 (AT compatible) with a 3COM 3C505B (EtherLink Plus) card and a 3C501 card. The 3C505B is used to talk to a 3 server 386, but I don't have the 3COM software loaded when I use the NCSA package. I had the same problem when the same cards were in a PC/XT. The problem: I can log in to a HP9000/S320 (hpbsla) on our LAN via Telnet once just fine. When I log off and try to log in again, Telnet says "Reading configuration file...", and then "Console messages", Trying to open TCP connection to: hpbsla Local host or gateway not responding Could not open new connection to: hpbsla and then ends up saying "entering server mode". When I press ESC, it exits to DOS normally. The hardware configuration of the Thinlan card is: IO Addr 310 IRQ 7 Shared Memory EC00 (card has bits 19-17,15,14 set, I shifted this value 4 bits to the right to derive the segment address.) I have a serial/parallel card on COM1 and LPT1 (don't know what IRQs). The 3C505B is set for shared memory the same except for bit 17 not set (segment adr CC00), IO addr 300, IRQ 3. ...But it gets worse!!! I removed the 505B to see if there was some kind of interaction. There must be, because now it says "Networked jammed, probable break in wire". Other computers on my LAN are working, and the cable looks like it's connected properly. Any ideas as to what is going on? What other info would be helpful? Is it likely that v2.2c would help? I would prefer to use only the 3C505B card for both systems. (They are both on the same cable.) Is there any way to make the NCSA package work with the 3C505B? Thank you. Gary Campbell Internet: campbell%hpbsla@hplabs.HP.COM UUCP: ....!hplabs!hpbsla!campbell
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 19:20:19 GMT From: 08071TCP@MSU.BITNET (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: Utilities for nameserver wanted
>I am looking for utilities that can help me with the internet nameserver. >I would like to have a program that queries the nameserver of different >zones and generates a /etc/hosts compatible file from the resource >records, for those hosts in our LAN that can not use the nameserver. >I am also interested in programs that help creating nameserver >database files, especially for the PTR records. I don't worry about the former - I just fetch the "hosts" format lists from several different domains I'm interested in, plus the NIC hosts list. I'm anxiously awaiting the day when all our systems will call domain service instead, though. I have a number of awk scripts and a small program that you might be interested in. I maintain data for my local domain in "hosts.txt" format, almost identical to that used by SRI-NIC. A couple of the awk scripts convert this format to the "/etc/hosts" and "named" formats. The program, "ndrev", takes the "named" format records and generates "PTR" entries for hosts in a given (sub-)network. If you are interested in any of these, take a look at the files in "src/hostmaint" on serv1.cl.msu.edu. Doug Nelson Michigan State University
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 20:15:40 GMT From: woody@SAIC.COM (Robert Allen Woodburn) To: comp.protocols.tcp-ip Subject: Public domain CMIS/CMIP/CMOT
I have heard that several groups are working on implementations of CMIS, CMIT, and/or CMOT. I am working for SAIC teamed with SPARTA to evaluate network management needs of DDN users and perhaps compile or even develop a toolbox of network management tools. I would be interested in public domain implementations of any ISO management protocols. Thanks Much.... wood y
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 21:13:15 GMT From: chas@sfc.Wichita.NCR.COM (Charles Binford) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Help using SUN as nameserver
I am trying to use a sun 3/160 for a nameserver on my local net.
I created an /etc/named.boot and /etc/named.db as the man page for
named(8) says, and edited /etc/rc to start /usr/etc/in.named. All
workes fine for my pc's and other unix boxes I configured to use
the name server. The problem is I can't get the sun to use itself!
I do not want to have to maintain the nameserver data base PLUS
/etc/hosts on the sun. The reason I want to use the nameserver is
so I don't have to maintain /etc/hosts.
The sun manuals all seem to assume you are in a network of suns and
are using yellow pages to maintain /etc/hosts. Of the 30 plus nodes
on our local net, only two are suns. However, only the suns have
the ability to be a nameserver, all of the other nodes just know how
to use one if it exists.
I tried creating the file /etc/resolv.conf, but it didn't help.
I would appreciate any information on setting up the sun as a
nameserver, and specifically how to tell it to use itself for
resolving host names.
Charles Binford, Automation Engineering, NCR E&M Wichita
<C.Binford@Wichita.NCR.COM>
<{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!c.binford>
<{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!c.binford>
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: 24 Feb 89 21:20:42 GMT From: bill@VLSI1.CS.CONCORDIA.CA (Bill Atwood) To: comp.protocols.tcp-ip Subject: 4.3 networking in SUNOS 3.5
I would like to rip out the networking software that comes with SUNOS 3.5 (for which I do not have source), and replace it with the networking software from 4.3 BSD (for which I do have source). Does anyone have experience with doing this? Are you willing to share with me how tough it was, and what problems you ran into, if any? Please reply directly to me; I will summarize if enough people express interest in seeing the result of this enquiry. Bill Atwood Concordia University, Montreal bill@vlsi1.cs.concordia.ca uunet!sunkisd!vlsi1.cs.concordia.ca!bill
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 00:05:45 GMT From: edb@fai.UUCP (Edward Bunch) To: comp.protocols.tcp-ip Subject: Re: Odd FTP Problem
In article <8902221936.AA10826@ncs.dnd.ca> netcoor@NCS.DND.CA (DRENET) writes:
>We have users on network 128.43 who has reported trouble retrieving
>files from several hosts in the Internet.
> < 425 Can't build data connection: Connection timed out
>Can anyone explain this? I would sure like to understand what is going on
>to create this situation, then I can try to do something about it.
>
>Bob Bradford netcoor@ncs.dnd.ca
I saw this same problem here on our WAN. The problem was this. We were trying
to talk to a ethernet interface that was on the other end of the machine.
This is a little difficult to explain. Picture a machine with two interfaces
that we wish to contact to ftp something off. When we start the FTP we
specify a host address of the interface on the far side. That is packets must
pass through the first interface and then through loop-back before arriving
at ftpd. When FTP trys to build the data connection the reverse way it fails.
ie. Loop-Back --> Other Interface --> Me.
I suppose FTPD wasn't smart enough to avoid the loop-back network on the return
trip.
Solution: Use the interface address on the near side.
--------------------------------------------------------------------------------
Edward A. Bunch UUCP: {uunet,amdahl,sun}!fai!edb
Fujitsu America, Inc. DOMAIN: edb@fai.com
Computer Support and Administation.
--------------------------------------------------------------------------------
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 02:06:10 GMT From: adelman@TGV.COM (Kenneth Adelman) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
> If DECNET solves this problem then DECNET over IP might be a better
> way to deal with this issue as it simply provides a lower layer for
> transport and any changes in the file attributes etc by DEC can be
> punted to DECNET support, it can be the only layer aware of such
> things and as long as the DECNET packets flow all should be well.
DECnet over IP isn't a replacement for STRU VMS in the Internet
environment. Phase IV DECnet is routing-braindead, limiting the size
of DECnet networks, and requiring great administrative pains to get
large networks to work.
> We *are* talking VMS<->VMS communications here, right? And at least
> one vendor already offers DECNET over IP, so the only real question is
> whether this combination already or could in the near future solve the
> problem. I could see an encapsulation standard (RFC) for DECNET/IP as
> a way to acheive this in a uniform manner among vendors.
After all the flames I've received about the proposed STRU VMS
extension to FTP, I'm not going to propose our DECnet over IP
encapsulation as a standard. However, I would be more than happy to
share the encapsulation specification with anyone interested in
developing complementary or competing products to MultiNet.
TGV does not believe that protocols of this nature are
trade-secrets, only the code and associated technology used to
implement them. This applies to STRU VMS, IP over DECnet, DECnet over
IP, and potentially others.
Kenneth Adelman
TGV, Incorporated
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 02:11:20 GMT From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan) To: comp.protocols.tcp-ip Subject: Re: FTP "STRU VMS" extension
>Ok, I can live with this but...VMS is a proprietary operating system >managed by exactly one corporation. I hear DEC is supporting or soon >to support TCP on VMS, do they have any proposals in this realm? My impression of things is that TCP is very low priority within DEC and that they have a long long way to go before they start worrying about this kind of problem. >If DECNET solves this problem then DECNET over IP might be a better >way to deal with this issue as it simply provides a lower layer for >transport and any changes in the file attributes etc by DEC can be >punted to DECNET support, it can be the only layer aware of such >things and as long as the DECNET packets flow all should be well. Yuck! Now to solve a very straightforward problem you need to ensure that all VMS TCP sites: 1) Buy DECNET (it is NOT cheap!) 2) Arrange to be connected (DECNET-wise) into a single accessable DECNET network (even if it IS using IP as the transport). Not to mention that the users (who might be transferring some files from UNIX workstations and some files from other VMS machines) will have to do 2 completely different things when they want to transfer VAX/VMS files with attributes intact vs moving files to/from hosts running any other O/S. >We *are* talking VMS<->VMS communications here, right? And at least >one vendor already offers DECNET over IP, so the only real question is >whether this combination already or could in the near future solve the >problem. I could see an encapsulation standard (RFC) for DECNET/IP as >a way to acheive this in a uniform manner among vendors. I think that an RFC for DECNET over IP (actually UDP) is a good idea, and since we are (as far as I can tell) the only ones who have implemented this I guess we should get an RFC out right away. Note that this DOES NOT solve the original problem -- extending FTP to transfer O/S-dependent files between cooperating systems in a way that still interoperates correctly with OTHER systems. To this end I think that extending the proposed STRU VMS to STRU OS xxx (i.e. STRU OS VMS is a particular instantiation) is a valuable contribution to the FTP spec. The SITE command might be more appropriate for this extension -- but the semantics entailed in this transfer mode most closely mesh with the semantics of the STRU command. >At least that model could lead to dealing with other proprietary >systems and network protocols, as it has in the past (eg. RSCS over >IP, CHAOS over IP, XNS over IP, etc.) Again -- tunneling through IP is a most worthwhile thing (and we do this quite a bit with our software) but it does NOT address the issue we are currently arguing. David Kashtan TGV Inc. -------
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 04:38:41 GMT From: rjh@cs.purdue.EDU (Bob Hathaway) To: comp.protocols.tcp-ip Subject: Re: Summary- FTP c callable functions
Does anyone know of a way to pipe command output? I'd like to do something simple like "ls | more", but nothing seems to work. Thanks, Bob Hathaway rjh@purdue.edu
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 1989 12:14-EST From: CERF@A.ISI.EDU To: jbvb@VAX.FTP.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: What seems to be a glitch in the TCP spec.
James, thanks for taking time to describe the "glitch" scenario carefully. The reasoning behind the advice to ignore the "old" packet is that it isn't clear how old the ACK and WINDOW information is. We were concerned about disorderly arrivals in which window information is delivered in reverse of the order sent (e.g. opening the window and then closing it again). If we follow your rule 4, is there a scenario in which disorderly arrival leaves A believing the window is closed when it isn't? Of course, in that case, the probe mechanism should provide more up to date information. In general, the probe is needed - I don;t think there is any debate on that point. The question is whether your slightly relaxed rules for processing ACKs and WINDOWs is a net gain or opens the door to new glitches. Intuition suggests that your "hack" [I don't mean this in any pejorative sense] probably does more good than harm, though I confess it feels slightly more pragmatic than my puritanical attitudes allow me to enjoy. Let's see what the reactions are from other practitioners. Vint Cerf
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 16:10:46 GMT From: Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-1-387-7050 ext.3695) To: comp.protocols.tcp-ip Subject: ARP for IP over X.25
Is there any dynamic way of learning the address resolution for IP over X.25? I would appreciate it if anyone could give me pointers for papers or information. Yuko Murayama Dept of Computer Science UCL
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: Sat, 25 Feb 89 16:10:46 +0000 From: Yuko Murayama (+44-1-387-7050 ext.3695) <Y.Murayama@Cs.Ucl.AC.UK> To: tcp-ip@sri-nic.arpa Cc: murayama@Cs.Ucl.AC.UK Subject: ARP for IP over X.25
Is there any dynamic way of learning the address resolution for IP over X.25? I would appreciate it if anyone could give me pointers for papers or information. Yuko Murayama Dept of Computer Science UCL
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 16:35:33 GMT From: chris@SALT.ACC.COM (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: Terminal servers and 3270 emulation
Morning all... Having just read Excelan's announcement for their new terminal server the thought once again crossed my mind that no one seems to see the need for these things to try and do TN3270. I get requests from customers every day for a product like this but it seems that no one has the bugs worked out yet. I threw this query out on the net almost a year ago, fully expecting a commercial product long before now. Does anyone know of a box that will do TN3270 for the dumb terminal user? PLease let me know if anyone has the inside scoop and I'll try and sumarize the responses to the net. THis might be some start-up's road to fame and fortune (:*) Chris VandenBerg ACC(chris@salt.acc.com) Standard disclaimer - My employer knows I can't do any REAL damage so they humorme.
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 17:14:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: What seems to be a glitch in the TCP spec.
James, thanks for taking time to describe the "glitch" scenario carefully. The reasoning behind the advice to ignore the "old" packet is that it isn't clear how old the ACK and WINDOW information is. We were concerned about disorderly arrivals in which window information is delivered in reverse of the order sent (e.g. opening the window and then closing it again). If we follow your rule 4, is there a scenario in which disorderly arrival leaves A believing the window is closed when it isn't? Of course, in that case, the probe mechanism should provide more up to date information. In general, the probe is needed - I don;t think there is any debate on that point. The question is whether your slightly relaxed rules for processing ACKs and WINDOWs is a net gain or opens the door to new glitches. Intuition suggests that your "hack" [I don't mean this in any pejorative sense] probably does more good than harm, though I confess it feels slightly more pragmatic than my puritanical attitudes allow me to enjoy. Let's see what the reactions are from other practitioners. Vint Cerf
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 18:55:57 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Odd FTP Problem (4.3 BSD kernel patches)
[ Stuff about using adb to xero out errors in inetctlerrmap ]
The suggested fix causes 4.3 to ignore ICMP unreachable errors in all
cases, something that one probably does not want to do. For instance,
I *much* prefer to have telnet attempts abort quickly with a "network
unreachable" than with a "connection timed out" some 60 seconds later.
On the other hand, once a connection has been established, I'd prefer
stray ICMP errors not break a connection. Moreover, nuking ICMP
unreachable errors weakens utilities like ping that understand such
messages. One of ping's useful features is the printing of ICMP
errors it receives.
The following patch (perhaps not pretty, but precise) treats ICMP
unreachable errors as before, except that they won't break established
connections.
Thomas
*** /tmp/,RCSt1025442 Sat Feb 25 13:46:58 1989
--- /tmp/,RCSt2025442 Sat Feb 25 13:46:59 1989
***************
*** 258,264 ****
tcp_notify(inp)
register struct inpcb *inp;
{
!
wakeup((caddr_t) &inp->inp_socket->so_timeo);
sorwakeup(inp->inp_socket);
sowwakeup(inp->inp_socket);
--- 258,271 ----
tcp_notify(inp)
register struct inpcb *inp;
{
! if (inp->inp_socket->so_state != SS_ISCONNECTING) {
! register int error = inp->inp_socket->so_error;
! if ((error == EHOSTUNREACH) || (error == ENETUNREACH)
! || (error == EHOSTDOWN)) {
! inp->inp_socket->so_error = 0; /* clear error */
! return;
! }
! }
wakeup((caddr_t) &inp->inp_socket->so_timeo);
sorwakeup(inp->inp_socket);
sowwakeup(inp->inp_socket);
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: 25 Feb 89 21:08:51 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: What seems to be a glitch in the TCP spec.
>Consider the following situation: A TCP connection is carrying >intermittent, bidirectional traffic. Host A has just sent a burst >which filled host B's window. B has enough data for a small segment, >piggybacking the Ack and indicating a window of 0. A replies with an >Ack, just as B's application consumes the data and B sends a segment >to re-open the window. B's implementor has chosen to retransmit the >first segment of un-acked data (if any) with window updates and Acks >(B's cost/packet is much larger than the cost/byte). A's implementor >has exactly followed pg. 69 of RFC 793, which says to discard segments >with obsolete data before checking the Ack or Window values. James: Did you stumble across this example in an actual case? It strikes me that it should not happen under "normal" conditions. The keyword is "retransmit". The above scenario has B piggybacking the window update on a retransmission. But this implies 1) B's retransmit timer has fired before the ACK for the first transmission has returned, or 2) B, aware that the cost per packet is higher than the cost per character, thinks it can get ahead by including some of the already transmitted data. Case 1 implies the retransmit timer is broken (in which case said scenario is the least of your worries) or that the transmission path is lossy (again, probably more serious than the described problem). Rather than a glitch in the spec, wouldn't this qualify as feature of case 2? Which RFCs suggest retransmitting the first segment of un-acked data (if present) when sending window updates and ACKs? Thomas
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: 26 Feb 89 05:24:44 GMT From: rdp@pbseps.UUCP (Richard Perlman) To: comp.protocols.tcp-ip Subject: tcp-ip 327x controller
I am looking for a 3270 terminal controller that can use a tcp/ip
ethernet as the local (controller to terminal) channel. I wish to
use IBM PCs and perhaps Macs (FastPath is in place) for the "3270"
terminals. Access to the VM host is Bisync.
Since I may not be completely correct on my IBM terminology I'll
restate my need another way. I would like to be able to access our
VM system from a PC or Mac on our local network and look like a 3270.
Tcp/ip on the VM is NOT a possibility (wish it were). A 9.6 bisync
line is the only option I have.
I have seen Tri-Data's Appletalk based controller, NET-1000 I think,
but it requires TOPS' Appletalk drivers for the PC and TOPS does not
(yet) support the WD8003E ethernet board, which we are using.
Responses by E-mail please.
--
Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602, San Francisco, CA 94105 |*| 1(415) 545-0233
-----------[000326][next][prev][last][first]----------------------------------------------------
Date: 26 Feb 89 13:12:00 GMT
From: jensen%hsr.uninett@NORUNIX.BITNET ("Tarjei T. Jensen")
To: comp.protocols.tcp-ip
Subject: FTP "STRU VMS"
If I were to solve something like this I would create something called
a fil description language. This would enable somebody at the other end to
reconstruct the original file or make a representation of it. It would be human
readable so that people without the facility would be able to find out what to
do. I don't care whether somebody would have to invent a cludge or something to
get this to work gracefully. All I want is for it to work. That means that ftp
probably should know about it (FTP "STRU FDL"?) through some sort of extended
hand-shake sequence. A language like this could probably be used to export and
import data into databases. Below I'll give an example of what I mean. I
suppose one would send the description first and then the file itself. In
certain cases there would have to be a facility to build a binary file from an
ascii representation. E.g. ISAM files. This would be appended to the
description file and fed to someting that would build the right file. I know
this could be a difficult task, but if the description is human readable we can
work something out. The point is to make the description logical, so when the
time is right somebody can make a program that will handle this in a reasonable
manner.
Examples (they do not show everything I would want in a description):
DESCRITPTION
QUOTE="
SEPARATOR=" "
REALNAME="A_NICE_FILE.BCK"
FILETYPE=VMSBACKUP ASCII8 NOPARITY ENCODED COMPACTED CRC=FILE
OPERATINGSYSTEM=VMS_4.7
CPU=VAX
COMPACTID=COMPRESS_6.4
ENCODEID=UUENCODE_1.4
CRC=4AC384D5
SPECIAL BCK
BCK_BACKUPTYPE=IMAGE
BCK_RECORDLENGTH=32768
ENDSPECIAL
REPRESENTATION=EXTERNAL
ENDDESCRIPTION
DESCRIPTION
QUOTE="
SEPARATOR=" "
REALNAME="A.FILE.ISAM"
FILETYPE=ISAM ASCII7 NOPARITY ENCODED COMPACTED CRC=FILE
OPERATINGSYSTEM=SINTRAN_III
CPU=ND110CX
COMPACTID=CPRS_92.4c
ENCODEID=BIGSECRET_MCLXIIV
CRC=32F798FD
SPECIAL ISAM
ISAM_DEFINERECORD_1 "clients"
ISAM_DEFINEFIELD_1 "client name" STRING 80 ASCII8
ISAM_DEFINEFIELD_1 "address" NESTED
ISAM_DEFINEFIELD_2 "address 1" STRING 60 ASCII8
ISAM_DEFINEFIELD_2 "address 2" STRING 60 ASCII8
ISAM_DEFINERECORD_END
ENDSPECIAL
REPRESENTATION=INLINE ATTENTION="ISAM_" ESCAPE="@"
ISAM_RECORD1 NO=1
ISAM_RECORD1 NO=SEQUENCE
ISAM_ENDREPRESENTATION
ENDDESCRITPTION
If you don't like it I understand, but try to find something more portable.
With a description like this it would be easy to import the file into a
database that know about FDL. We would have tools that would generate code to
access the file.
-----------[000327][next][prev][last][first]----------------------------------------------------
Date: 26 Feb 89 14:09:52 GMT
From: schoff@STONEWALL.NYSER.NET ("Marty Schoffstall")
To: comp.protocols.tcp-ip
Subject: Re: Terminal servers and 3270 emulation
Chris,
One of the problems here is mapping the 327X stream into a ascii/ansi terminal
of some type (where some type is one of at least a hundred). Carrying all
this "curses" (forgive me) information around in memory is very wasteful. A
standard protocol might help vendors (and definitely users). This protocol
upon identification of terminal type to the terminal server would ask some
server (who has disk storage) what is the curses defnition for this terminal
to be mapped into. Sounds like an IETF Working group.
Another place to possibly look is how ISO VTP with forms mode does this, knowing
them they probably have left it up to a vendor's agreement.
Marty
PS: I'm not suggesting you use curses it is only something generally known
--------------------------your message----------------------
Having just read Excelan's announcement for their new terminal server
the thought once again crossed my mind that no one seems to see the need
for these things to try and do TN3270. I get requests from customers every
day for a product like this but it seems that no one has the bugs worked ou
yet. I threw this query out on the net almost a year ago, fully expecting a
commercial product long before now. Does anyone know of a box that will do
TN3270 for the dumb terminal user? PLease let me know if anyone has the
inside scoop and I'll try and sumarize the responses to the net.
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 26 Feb 89 15:00:42 GMT From: hal@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: IP access control
> Who knows if anything was/is/will be done to permit what DoD people > call "discretionary" access control at the IP level. Forms include > "filtering" based on host identity (address), host membership in a > discretionary access control group, member of a subnet. I should have added "discretionary access control performed by the host IP server." A few well designed gateways have such filtering, some quite elaborate; however, what about host based software. The IP security option carries "labels", some of which can be used for access control and others which are "advisory." Does anyone know if any product will have a clean mechanism for passing these advisory labels up to an application which can make use of them?
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: 26 Feb 89 16:49:29 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: Re: What seems to be a glitch in the TCP spec.
Solution (4), honoring the ACK and window of a pkt rcvd just to the left of the receive window, seems to be the defacto standard. As I'm sure you know, BSD TCP does this. So do the TCPs developed locally. Philip Koch (Philip.Koch@Dartmouth.EDU) If this is the case, I wish that the Sun and HP TCP mungers hadn't chosen to change their bsd-derived code to exact conformance with pg. 69 of RFC 793. From: Thomas Narten <narten@purdue.edu> Did you stumble across this example in an actual case? It strikes me that it should not happen under "normal" conditions. The keyword is "retransmit". The above scenario has B piggybacking the window update on a retransmission. But this implies 1) B's retransmit timer has fired before the ACK for the first transmission has returned, or 2) B, aware that the cost per packet is higher than the cost per character, thinks it can get ahead by including some of the already transmitted data. My problem is indeed a real-world one, observable with an X-windows server running on the PC and communicating with HP-UX 9000/350 and Sun 3/50 X clients. The Sun is running 3.5, I don't know the HP release, I can obtain it if anyone (are support people listening?) is interested. Rather than a glitch in the spec, wouldn't this qualify as feature of case 2? Which RFCs suggest retransmitting the first segment of un-acked data (if present) when sending window updates and ACKs? Yes, it is a feature of case 2 (I am retransmitting the data before the timer fires). There are complicated reasons (most historical, relating to the PCIP ancestry of the TCP implementation) why it is much easier to do this, so we always have. I freely admit to doing something that wasn't proven (right or wrong) by anyone else, but 793 doesn't tell me not to, either. I am willing to accept "don't include window updates or acks with retransmits", (my solution (2)) if this is the consensus, but I have seen some significant support for checking the window and ack if the segment is only slightly obsolete, or even regardless of SEG.SEQ. Many implementers have faced this issue, but the answers they chose haven't been published. I want to air the issue because we have unhappy users, and the fact that 793 allows the glitch means that they won't be the last people bitten by it. We may well have to implement separate window update segments anyway, just because of relative company sizes... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: 26 Feb 89 17:09:00 GMT From: jbvb@VAX.FTP.COM (James Van Bokkelen) To: comp.protocols.tcp-ip Subject: What seems to be a glitch in the TCP spec.
From: CERF@A.ISI.EDU .... We were concerned about disorderly arrivals in which window information is delivered in reverse of the order sent (e.g. opening the window and then closing it again). If we follow your rule 4, is there a scenario in which disorderly arrival leaves A believing the window is closed when it isn't? Of course, in that case, the probe mechanism should provide more up to date information. As I see it, there have always been cases where disorderly arrival of window updates can leave one host believing the window is closed when it should't. Consider the unidirectional case: 1. Seq 100, Ack 200, Data 50, Window 4096 -> 2. <- Seq 200, Ack 150, Data 0, Window 0 3. <- Seq 200, Ack 150, Data 0, Window 50 If 3 arrives before 2, and the sender doesn't have more data ready to go before 2 shows up, the window looks closed. Of course, it shrank to get there, but there are enough TCPs that shrink the window that the sender will probably manage to deal with it. Probes will restart the data flow just fine, but with a glitch. Part of the problem is that X may be the first widely-used application to provide a fast, intermittent bi-directional load to TCP. The remainder is because PC interfaces have to offer 1-segment windows to survive when talking to faster hosts. When the window is 2*MSS or more, this is much less likely to happen. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 04:03:51 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Odd FTP Problem
Robert, The Fuzzball logs on net 128.4 and various other places near the NSFNET Bluebone are also showing unstable routes, sometimes intermittent ICMP unretchables and other times ICMP time exceededs. The problem has been growing slowly worse over the last few weeks. Seen from here one or more of the Fuzzball time servers drops off the Earth only to replanet a few minutes or hours later. Also, there is a rising tide of ICMP unmentionables coming from distant gateways, rather than nearby EGP gateways on ARPANET, so things are certainly unstable somewhere in space. Finally, the rate of ARPANET error messages, especially to a few gateways, is growing steadily worse. I conclude PSNs for those gateways may be sinking slowly in the muck. This report is certainly much less specific than yours; however, you may find whatever corroboration useful. Dave
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 09:48:28 GMT From: mcvax!hp4nl!targon!nixvia!mink@uunet.uu.net (Mink van der Zwan) To: tcp-ip@sri-nic.arpa Subject: TCP-IP zero checksum
On our Targon31 we use the Pyramid networking code. In tcp_output the following code is included : ti->th_sum = 0; if ((so->so_options&SO_NOCHKSUM) == 0) if((ti->th_sum = in_cksum(m, sizeof (struct tcphdr) + sizeof(struct ipovly) + (int)optlen + len)) == 0) ti->th_sum = -1; Can anyone tell me why the checksum in the TCP header isn't allowed to be zero ? I can't find it documented in any RFC. Also I can't find this conversion back in the tcp_input routine -------------------------------------------------------------------------------- Mink van der Zwan UUCP : mcvax!unido!nixpbe!mink.via Nixdorf Computer B.V. EG4 NERV : mink.via Mijlweg 9, 4124 PJ VIANEN voice : 31 3473 75154 Netherlands. telefax : 31 3473 76504 --------------------------------------------------------------------------------
-----------[000333][next][prev][last][first]----------------------------------------------------
Date: 27 Feb 89 12:32:00 GMT
From: Hampton@DOCKMASTER.ARPA ("David R. Hampton")
To: comp.protocols.tcp-ip
Subject: Re: Odd FTP Problem
Are the hosts that you are having problems with Berkeley 4.2
systems? There is a problem with the Berkeley 4.2 FTP server code.
When the 4.2 server opens a data connection, it should performs several
internal steps to get the data connection set up, and then announce the
port number to the client. In the distributed kernel, it actually
announces the data port before it performs the final step of setup. If
this final step fails, a 425 error is returned.
David Hampton
Hampton @ Dockmaster.ARPA
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 12:55:07 GMT From: tsuchiya@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: Re: IP access control
I haven't been particularly following this, but I know that Deborah Estrins Autonets Task Force has been thinking about this stuff. In particular, she has done some work on what she calls VISAs which are used to authenticate IP-level packets. PT
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 14:46:22 GMT From: barns@GATEWAY.MITRE.ORG (Bill Barns) To: comp.protocols.tcp-ip Subject: Re: ARP for IP over X.25
The prior discussion on IP and X.25 left me with the impression that
there is not any scheme now in use anywhere, for *dynamically* learning
an X.121 address corresponding to an IP address given that the source
and destination are both connected to some particular X.25 network. If
such a scheme does exist, I would be interested in learning about it.
Keith Mitchell suggested a scheme involving passing IP addresses in
the Call User Data field of the call request. I think he had a
rather different purpose in mind - for the originator to declare
its own IP address. However, I can imagine a variation of this which
uses an address server whose X.121 address is preconfigured in other
systems. You would connect to such a server and include the IP address
you want to resolve in the CUD, probably with some protocol identifier
prefix which signals that you are requesting this address resolution
service. There are probably three ways that could be used to pass back
the answer:
1) accept the call, send back the X.121 address as data, then clear.
2) perform the whole operation as a 'fast select' and use a clear with
data to send back the X.121 address.
3) use the new 1988 Call Deflection facility to route the call through
automatically to the right destination, and return a called line
address modification notification facility to the source for its
future reference. This allows the same VC to be used for address
resolution and for actually communicating. [According to the best
locally available rumor, Call Deflection seems to be like call
redirection, except that it works on a per-call basis.]
It can be argued that if servers are to be built, they should use ES-IS
protocol instead of an ad hoc approach like those above. This does not
entirely eliminate the need for preconfiguration of at least one
address, since the ES and IS can only communicate on an X.25 network
when one of them has called the other one, which it cannot do without
first having the appropriate X.121 address.
Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000336][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 15:25:50 GMT From: VAX1!greggt@tut.cis.ohio-state.edu (Gregg Thompson) To: tcp-ip@sri-nic.arpa Subject: TN3270 needed for Unisys running SYSV
Subject says it all. (tried to compile/hack tn3270 to compile, but once we got it to compile the final compilation and the compiler gave up) -- To live is to die, to die is to live forever; GRegg Thompson Where will you spend eternity? greggt@vax1.cc.uakron.edu
-----------[000337][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 15:41:21 GMT From: abe@mace.cc.purdue.edu (Vic Abell) To: comp.protocols.tcp-ip Subject: Re: Odd FTP Problem
There is another BSD ftpd problem in the very latest post-worm release that can cause data connection failure. The connection failure occurs when there are two, incoming ftpd calls from the same remote peer. If the two, receiving ftpd processes both try to open a data connection at the same time, one can fail with an EADDRINUSE error. We have fixed this problem locally by adding a retry loop in ftpd.c's getdatasock() function. The released ftpd lacks this loop. It also may be reporting the cause of data connection failures improperly when they result from an error in the bind() call within getdatasock(). There are several function calls between the bind() and the reply() call that can change the value of errno.
-----------[000338][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 18:34:45 GMT From: rick@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: Re: Terminal servers and 3270 emulation
This is off the original subject of availability of forms-oriented terminal servers, but I thought I'd agree with Marty about a terminal description server... You are correct about the exchange of curses-type information not being covered in the ISO VT standard. It's generally considered that this is only useful for the mapping of VT updates to a specific terminal type, and is therefor a "local" rather than a "peer to peer" protocol matter. The VT standard only defines communications between 2 peer VTs and doesn't have an idea of a terminal description server. I suppose in the ISO world the proper way to look at this may be to register the terminal information in the directory. (could a name domain record type be devised for this?) This may take care of the need for a protocol to distribute the info, but it definitely still requires standards for the format of the information. Maybe there needs to be more than one format for different terminal classes (possibly screen-oriented ala curses, forms-oriented, and graphics). This kind of information might be used by a variety of clients: 1. terminal servers, as you suggested 2. TELNET or ISO VT client programs. This would be to help them map either generic VT updates to a physical terminal, or one type of data stream (ie. 3270) to another (ie. async dumb terminal). 3. applications that want to control terminals directly. This, of course,contradicts the VT idea that anything being sent across a network to a terminal should be in a standard (device-independent) format. On the other hand it is exactly what happens when someone telnets to a remote unix box and fires up "vi". A well designed, standard representation (or set of representations) for the terminal capability data may just expand this approach beyond curses/termcap/terminfo. Wasn't there a project some years ago at Berkeley to define a termcap-like description for graphics terminals? Anybody know about it? By the way, it's not yet clear what method of supporting forms-oriented applications will be popular using ISO VTP. There is a FORMS VT profile defined by the NIST OSI workshop, but some favor the idea of sending 3270 data streams through a "transparent" VT (ala tn3270). Here at MITRE we have a prototype of a VT FORMS implementation and are looking for someone to test interoperability with. This implementation uses curses to map VT FORMS updates to async. terminals. -Rick Wilder (rick@gateway.mitre.org)
-----------[000339][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 19:53:39 GMT From: david@uhccux.uhcc.hawaii.edu (David Lassner) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Novell Net with Telnet & FTP
We're interested in putting together one or more Novell networks with PC and PS/2 type machines. And we want each machine to also be able to telnet and ftp out to our campus network (ProNet-80). We know that at least Excelan and U-B offer hardware/software solutions for this. Any other vendors we should be checking with? Any opinions or horror stories will be appreciated. We're a public university and are especially interested in site license deals that don't nickel and dime us on each workstation. Are there any cards that are supported for simultaneous use of the Novell network OS and NCSA Telnet or other free TCP/IP software? -- David Lassner, University of Hawaii Computing Center, 808/948-7351 INTERNET: david@uhccux.uhcc.hawaii.edu BITNET: david@uhccux
-----------[000340][next][prev][last][first]---------------------------------------------------- Date: 27 Feb 89 20:00:51 GMT From: haven!aplcen!aplcomm!trn%aplcomm.jhuapl.edu@ames.arc.nasa.gov (Tony Nardo) To: tcp-ip@sri-nic.arpa Subject: Re: Odd FTP Problem
In article <MS-C.604267100.377401575.mrc@SUMEX-AIM.Stanford.EDU> mrc@SUMEX-AIM.STANFORD.EDU (Mark Crispin) writes:
>
> I've seen this problem in other forms. Apparently there are a lot of
>"ICMP Destination Network Unreachable" messages getting sent in instances
>where network connectivity is broken for only a brief duration (perhaps due
>merely to congestion at a gateway).
Considering that I've seen this one crop up at 6:40am EST on a Monday, and at
other times even more unlikely to have high traffic (02:00 am EST on a Friday
night/Saturday morning), I'd doubt if gateway conjestion is the sole culprit.
> Some versions of BSD Unix nuke the connection when this or "host
>unreachable" occur; it is reputed that patching location _inetctlerrmap+8 in
>the kernel from 0x3341 to 0x0 remedies this problem but I haven't been able to
>verify it.
This might help cover up the problem, but it doesn't really solve it. What
can you do when the "host unreachable" condition persists for several minutes?
Several hours?
------- ---------------- -------
ARPA, trn@aplcomm.jhuapl.edu, UUCP: {backbone!}mimsy!aplcomm!trn
BITNET: trn@warper.jhuapl.edu
"Thank God I'm only watching the game, controlling it."
"One Night In Bangkok" (_Chess_)
-----------[000341][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 1989 04:56-EST From: CERF@A.ISI.EDU To: jbvb@VAX.FTP.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: What seems to be a glitch in the TCP spec.
James, thanks for the example - indeed, it is that sort of situation which led us to introduce probing behavior, among other things. What's your view of the proposed special case check? Vint
-----------[000342][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 89 10:57:55 GMT From: mcvax!kth!enea!maxim!prc@uunet.uu.net (Robert Claeson) To: tcp-ip@sri-nic.arpa Subject: Re: Terminal servers and 3270 emulation
In article <8902271834.AA01285@mars.mitre.org>, rick@GATEWAY.MITRE.ORG writes:
> A well designed, standard representation (or set of representations)
> for the terminal capability data may just expand this
> approach beyond curses/termcap/terminfo. Wasn't there a project some
> years ago at Berkeley to define a termcap-like description for
> graphics terminals? Anybody know about it?
Is it really possible to handle all kinds and types of terminals via
table descriptions? I suspect that an implementation based on drivers
for different terminal types would be able to make better use of the
terminal's capabilities.
--
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20
EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
-----------[000343][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 89 11:46:56 GMT From: efb@suned1.UUCP (Everett F. Batey II) To: comp.sys.hp,comp.protocols.tcp-ip Subject: HP3000 Enet MAU Choices and pinouts
For connecting HP3000s, (MPE V) to ethernet, has anyone found ANY DEC, TCL
or other MAUs which perform properly for getting to thich or thin lan ?
Can anyone tell us what the cable signals are? Appear NOT to JUST be RETN,
COLL, TXD, RXD, PWR for nine pins. Are signal condition to no signal
conditions different than for those of us used to common ethernet 802.3 as
offered by DEC, TCP, etc. ?
--
The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
Statements, Opinions ... MINE ... NOT those of my US Employer
-----------[000344][next][prev][last][first]---------------------------------------------------- Date: Tue, 28 Feb 89 21:45:54 PST From: Van Jacobson <van@helios.ee.lbl.gov> To: tcp-ip@sri-nic.arpa Subject: 4BSD routing diagnostic tool available for ftp
Traceroute, a Berkeley Unix (4.xBSD) tool that can help debug some network routing problems is available for anonymous ftp from host ftp.ee.lbl.gov (128.3.254.68), file traceroute.tar.Z (a compressed Unix tar file -- ftp it in binary mode). Unfortunately, you will have to hack your kernel slightly to use it (there's a README that gives a modified /sys/netinet/raw_ip.c:rip_output that's known to work on 4.[23]bsd and Sun OS [34].x.) If this sounds useful and you feel comfortable with the kernel hacking, help yourself. - Van
-----------[000345][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 89 15:16:42 GMT From: mailrus!sharkey!atanasoff!deimos.cis.ksu.edu!eecea!terry@tut.cis.ohio-state.edu (Terry Hull) To: tcp-ip@sri-nic.arpa Subject: Re: Novell Net with Telnet & FTP
In article <3343@uhccux.uhcc.hawaii.edu> david@uhccux.uhcc.hawaii.edu (David Lassner) writes:
>We're interested in putting together one or more Novell
>networks with PC and PS/2 type machines. And we want each
>machine to also be able to telnet and ftp out to our campus
>network (ProNet-80).
Micom has a gateway product based on their NP600 Ethernet board. I have
one connected to a Convergent Technologies S/640. The telnet feature works -
mostly. The only problem is the gateway occasionally hangs and the board must
be reset. While logged in on the Novell, you can ftp files from the
Convergent, but you cannot send files over 4K to the Convergent. All
of the "r-commands" rwho, rsh, ruptime do not work. The gateway has
SMTP capability, but I have not had the opportunity to test that yet.
(The Convergent came without a mailer capable of SMTP.) The last
problem is the board is very expensive at $4000.
I have the gateway installed and working in the net now, but I am
certainly not thrilled with the product.
--
Terry Hull Department of Electrical and Computer Engineering
Kansas State University
INTERNET: terry@eecea.eece.ksu.edu Manhattan, KS 66502
UUCP: rutgers!ksuvax1!eecea!terry
-----------[000346][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 89 18:58:00 GMT From: mentor.cc.purdue.edu!mace.cc.purdue.edu!abe@purdue.edu (Vic Abell) To: tcp-ip@sri-nic.arpa Subject: Re: Odd FTP Problem
There is another BSD ftpd problem in the very latest post-worm release that can cause data connection failure. It occurs when there are two, incoming ftpd calls from the same remote peer at nearly the same time. When the two receiving ftpd processes both try to open a data connection, one may fail with an EADDRINUSE error. I have fixed this problem locally by adding a retry loop in ftpd.c's getdatasock() and have reported it to Berkeley. The released ftpd may also report the cause of data connection failures improperly when they result from an error in the bind() call within getdatasock(). There are several function calls between the bind() and the reply() calls that can change the value of errno.
-----------[000347][next][prev][last][first]---------------------------------------------------- Date: 28 Feb 89 23:22:18 GMT From: leonard@cod.nosc.mil (Norman Leonard) To: tcp-ip@sri-nic.arpa Subject: ping info
I am a technician at NOSC SD and have recently become involved with ethernet installation and maintenance which I am learning as I go. I have a HP 4792A lan analyzer which I would like to use to ping various hosts on the net and monitor their response using the analyzer as the source. To this end I have captured a ping package between two unix hosts on the net and mod- ified the the source ethernet address to reflect the analyzer's address and at the same time have modified the source IP address to one given me by the unix administrator for the lan analyzer. At this point I have assumed I have made the necessary changes for the analyzer to act as the source for the ping package and that the unmodified destination host would respond to the analyzers ping package, but it has not. Am I incorrect in my modification of the ping package or is there some other area that I am overlooking? Any help or suggest- ions would be appreciated. I also would like any suggestions regarding sources for basic tcp/ip concepts and structure.
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |