|
|
ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for July 1990 (483 messages, 298621 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Sun, 1 Jul 90 16:22:42 GMT From: Mills@udel.edu To: "Daniel B. Davison" <zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!uhnix2!davison@tut.cis.ohio-state.edu> Cc: tcp-ip@nic.ddn.mil Subject: Re: IP addresses of timechimers needed
Daniel, See the file pub/ntp/clock.txt on louie.udel.edu. I thought a pointer to this file was included in the ntp and xntp distributions, but maybe not. I am the person who made rfc1119, rfc1128 and rfc1129 PostScript files and I will speak firmly right back for reasons you will understand upon reading them. If you need hardcopy, pass along your address. Dave
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 00:05:40 GMT From: cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!scslwide!wsgw!wsserva!onoe@tut.cis.ohio-state.edu (Atsushi Onoe) To: tcp-ip@nic.ddn.mil Subject: Re: parallel networks routing question
In article <7042@star.cs.vu.nl> sater@cs.vu.nl (Staveren van Hans) writes: > so two multihomed hosts connected with parallel networks. > Further suppose that network B is preferable to network A, because of > load, or because it is 10x as fast (FDDI vs Ethernet). > How would one set up addressing and routing for such a configuration? I think you can increase metric number for interface A. For example, ifconfig FDDI B.1 ... ifconfig ETHER A.1 .... metric 1 ^^^^^^^^ -- Atsushi Onoe <onoe@sm.sony.co.jp> Workstation Div., SuperMicro Group, Sony Corporation.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 00:44:19 GMT From: mcdchg!ddsw1!karl@rutgers.edu (Karl Denninger) To: tcp-ip@nic.ddn.mil Subject: MAC Email Services from Unix Systems
We're looking for a package (PD, Shareware or commercial is fine) that will give us Email connectivity with Unix machines. We have uShare loaded on a Sun workstation. It comes with a Mail desk accessory which, unfortunately, doesn't work at all (it gives System Bombs and fails to write or delete messages). This service DOES, however, permit printer and file services, and those aspects appear to work properly. We need email connectivity. Ideally the package would interact with the Unix system such that you could use Unix mailboxes, although I am willing to settle for a daemon that reads the Unix mailbox and re-writes in a Mac-style format somewhere else... or even something that is opened and runs in the background receiving via SMTP (we have Multifinder on our machines). Help! Commercial informaiton is fine, as are pointers to things or phone calls (even from salesmen!). We can FTP if needed as well. This is a high priority item; any and all help appreciated. Note that the reply address is NOT the same as where this message is being posted from (I'm at home right now and prefer to receive replies at work). Please email rather than post replies. Thanks! -- Karl Denninger (kdenning@ksun.naitc.com, <well-connected>!ddsw1!karl) AC Nielsen, Bannockburn, IL (708) 317-3285
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 03:29:12 GMT From: agate!shelby!lindy!ddaniel@apple.com (D. Daniel Sternbergh) To: tcp-ip@nic.ddn.mil Subject: Finding whois responders
Is there any way to find out which hosts respond to whois requests? I'm looking for a master list of hosts which handle whois, and the sites they serve. Does such a thing exist? Is there a way (short of sending whois requests to every host) of creating such a list? Please send e-mail, since I do not read this newsgroup. Many thanks, == Daniel == --------------------------- D. Daniel Sternbergh ddaniel@lindy.stanford.edu
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Jul 90 10:08:14 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) To: forster@cisco.com, idunno!princeton.edu!tengi@louie.udel.edu, ietf-rreq@jessica.standord.edu, tcp-ip@nic.ddn.mil Subject: Re: non-contiguous masks
|> |> he ya go, campers. anyone wish to rise up and define a good reason to keep |> non-contigious subnet bits, assuming we require the ability to have more |> than one address on an interface . . . . . . |> I beleive that there is a very good reason for keeping non-contiguous masks. It turns out that there is a very efficient and flexible method of assigning addresses that requires non-contiguous masks to work. It is something that I recently have proposed for ABOVE the network level (to address the issues of both scaling and address depletion), but it can work perfectly well below the network level. The idea is very simple, and it works for any number of hierarchy levels. Basicly, you assign addresses from the bottom up, as they are needed. Initially, when a subnet needs some addresses (when it is first created), you give it just enough address space to cover its needs (the first multiple of two above the actual number of addresses they need). In other words, they have a mask that has just enough zeros to cover all their hosts. Later, when a subnet needs new addresses, what you do is find a bit in their mask that 1) currently is a "1", and 2) can be changed to a "0" without stealing addresses from some other subnet. In other words, you double their allocation of address space by flipping a mask bit from a "1" to a "0". By doing this, none of the subnet's existing addresses are invalidated--they still match under the same routing entry. By only handing out addresses when they are needed, you use the address space very efficiently (like, possibly over 50% utilization). I will be talking about this at the UBC IETF meeting (plenary). I would love to come to router requirements and talk about it there specifically, or if anyone is interested, I have a postscript paper (draft) that talks about this stuff and some other interesting aspects of scaling. Oh, and by the way, patricia still works just fine with non-contiguous masks (at least the way I assign them). In fact, I think the use of non-contiguous masks speeds up patricia, because since you are packing the meaningful information into a smaller number of bits, patricia needs to sort through a fewer number of bits to get the right result. PT _________________________________________________________________ Paul F. Tsuchiya Bellcore tsuchiya@thumper.bellcore.com 435 South St. 201-829-4484 MRE 2L-281 201-267-9298 (FAX) Morristown, NJ 07960 _________________________________________________________________
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Jul 90 10:10:09 EDT From: jbvb@vax.ftp.com (James Van Bokkelen) To: CSYSMAS@OAC.UCLA.EDU Cc: tcp-ip@NIC.DDN.MIL Subject: Re: What Size IP on TR?
Date: Fri, 29 Jun 90 15:41 PDT From: Michael Stein <CSYSMAS@OAC.UCLA.EDU> An example is a RIF which says 2052 where there are routers to Ethernet (max IP packet size of 1500). Any IP packet larger than 1500 will get fragmented. Most modern TCP implementations have Maximum Segment Size option handling which attempts to avoid fragmentation when traversing routers. If the transport protocol you're concerned with is layered on UDP, you are likely to find that you must tweak things manually. At any rate, what I was saying was that there was a time when you *had* to say "2052" in your RIF, or some IBM TCP/IP implementations wouldn't talk to you at all. Thus, you are likely to find that as a widely-used default... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 10:43:44 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!umbc3!digennar@tut.cis.ohio-state.edu (Mr. Jerry DiGennaro) To: tcp-ip@nic.ddn.mil Subject: NCSA software and Novell Servers
At Loyola College, we would like to put the NCSA telnet and ftp packages on our Novell file servers so that users can get to the various servers. Is this legal? Will it work? Is the NCSA software "sharable" by many users from the server perspective? What is the current version of the software? Have I missed anything? Thanks in advance. Jerry DiGennaro digennar@umbc3.umbc.edu (301) 532-5129
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 11:09:35 GMT From: bu.edu!dartvax!litle!tom@uunet.uu.net (tom hampton) To: tcp-ip@nic.ddn.mil Subject: errno 77 on read of socket
We have been doing some high volume tests of ISC's latest release of
TCP/IP. Things look pretty good except for an occaisional (1/1000)
error generated on a read of a socket -- errno 77, bad data packet.
What does this error mean?
Where should we look to fix it?
--
===============================================================================
Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
603 643 1832
-------------------------------------------------------------------------------
Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com tom@litle.uucp {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Jul 90 01:49:42 -0400 From: ehj@psi.com (Eric Jensen) To: tcp-ip@nic.ddn.mil Subject: RATP (rfc916) - has anyone implemented it?
Greetings,
Can someone tell me:
1) What implementations of RATP exist?
2) What the experiance with those implementations has been?
3) Is there something "better"? (although rfc916 impresses me as
well thought out (well written too))
Thank you,
eric
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 Jul 90 23:32:57 EDT From: droms@hydra.bucknell.edu (Ralph E. Droms) To: tcp-ip@nic.ddn.mil Subject: Questions about TCP/IP protocol suite implementations
In connection with the work of the IETF Dynamic Host Confguration
working group, I'd like to conduct a small survey by asking the
following two questions:
1) Which router vendors implement BOOTP? Which implementations would
break if the BOOTP protocol were enhanced by, say, a new set of BOOTP
operations? Which implementations provide the forwarding function in
which broadcast BOOTP requests are retransmitted and the response(s)
returned by the router?
2) Which implementations of TCP/IP (either host or router or whatever)
would break if a new address class were introduced? Which would break
if network address 0 were used as a special purpose address; e.g., if
network address 0 were used for packets destined for hosts on the same
subnet and packets with destination network address 0 were
specifically not forwarded by routers?
Please reply directly to me...
- Ralph Droms Computer Science Department
droms@bucknell.edu 323 Dana Engineering
Bucknell University
(717) 524-1145 Lewisburg, PA 17837
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 19:37:07 GMT From: netwrx1!mindel@uunet.uu.net (Joshua L Mindel) To: tcp-ip@nic.ddn.mil Subject: Questionnaire: Does your FTP provide "open", "verbose", and "quote"?
I'd like to determine whether the following three user commands are provided by the vast majority of FTP client programs: OPEN -Establish a connection to the specified host FTP server. VERBOSE -Toggle verbose mode. Among other things, "on" displays FTP reply codes. Example reply codes visible with verbose mode on are: 220 Service ready 331 User name ready 230 User logged in 450 Access denied QUOTE -Send the arguments specified verbatim to the remote FTP server. Can you help me out and let me know whether or not the package(s) you know about provide these three functions? Please respond via email to me directly, indicating: 1. Name of the ftp software package 2. Operating system on which it runs. 3. Whether your implementation provides these functions, but uses different command names. Thank you. ------------------------------------------------------------------------------- Joshua L Mindel, Senior Analyst Internet: mindel%netwrx1@uunet.uu.net NetWorks One Usenet: uunet!netwrx1!mindel Vienna, Virginia USA Phone: (703) 827-7767 -- ------------------------------------------------------------------------------- Joshua L Mindel, Senior Analyst Internet: mindel%netwrx1@uunet.uu.net NetWorks One Usenet: uunet!netwrx1!mindel Vienna, Virginia USA Phone: (703) 827-7767
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 19:49:21 GMT From: usc!wuarchive!swbatl!uucigj@ucsd.edu (Greg Jensen - UCI - 5-3531) To: tcp-ip@nic.ddn.mil Subject: PC to Sun sparc via slip/modem
I would like to get a little clearer understanding about using a SL/IP
connection between a PC and a Sun using a 2400 baud modem. If I get
a version of ka9q for the PC and I use the sliplogin for the Sun will I
be able to make the connection and use say; ftp or telnet? Which
binary of ka9q for the PC do I need? (net.exe?). Is there a version of
slip available that allows dialout from the PC? Am I correct in the
understanding that to get ka9q to get connected to the Sun over the
2400 baud modem that I have to use another comm package to actually
dial the phone and get the connect, then back out of the comm package
without hanging up and startup the ka9q program? On the Sun side, I
have a program that can be used as the program to be started after
logging in named sliplogin. I have added the appropriate parameters to
the kernel and have successfully built a new vmunix. I tried the
example test situation according to the following:
stty -tostop
sliplogin 192.12.180.1 192.12.180.2 < /dev/ttya &
sliplogin 192.12.180.2 192.12.180.1 < /dev/ttyb &
with a short cable with the appropriate wires crossed. As soon as I
start one it finishes, which I thought was supposed to continue until
killed. Am I supposed to have something else running? Is this all
that I need to let my PC communicate (other than the modems)? Is there
a better PD slip package, for both PC and Sun?
To top this off is there a PD package available to accomplish an NFS
mount on the PC? I would like to find out if the PC-NFS is possible
over a serial line (via modem, not direct connect) and if it someone
has donated it to the Public Domain. Otherwise if this is possible
what is the cost of such a program?
Excuse these somewhat overpublished questions, but I have not been able
to see the answers to all of these questions in one place. The basic
question - what are the steps necessary to to accomplish this situation
(connecting PC to Sun via modem using slip)?
Gregg Jensen
----------------------------------------------------------------------
These opinions are my own and do not necessarily reflect my companies.
Southwestern Bell Telephone
Send E-MAIL to the following address...
...!uunet!swbatl!uucigj
- or you can try -
uucigj%gandalf.sbc.com@uunet.uu.net
----------------------------------------------------------------------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 Jul 90 21:29:58 GMT From: netcom!netcom.uucp!jbreeden@apple.com (John Breeden) To: tcp-ip@nic.ddn.mil Subject: New AT&T Ethernet SIA chip
AT&T is rumored to be developing a new Ethernet SIA chip. Supposedly, and this is third hand information, the chip has both 10BaseT and AUI outputs, and can be changed via software, on the fly, between them. Also, it doesn't appear that they have chosen a controller chip to mate with, but have some way of interfacing with controllers from Intel, AMD, OR National; ie: it works with all three. Can anyone shed any light on this? Does anyone have a phone number I can call? Thanx in advance;
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Tue, 3 Jul 90 10:04:47 -0700 From: chris@salt.acc.com (Chris VandenBerg) To: tcp-ip@nic.ddn.mil Subject: libc for SUN 4.0.3c
Good morning all, I'm trying to get a SPARC/1 running with the resolver and I was told that I have to substitute a shared libc that the resolver, in addition to adding the resolv.conf file. Does anyone have one of these or know if one for 4.0.3c? And, does anyone know how this is set up in SUNOS4.1? Please respond to me directly, I don't want to waste bandwidth on so trivial a request. Many thanks, Chris VandenBerg (chris@salt.acc.com)
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Tue, 03 Jul 90 08:55:12 PDT From: zsu@NISC.SRI.COM (Zaw-Sing Su) To: ora!minya!jc@BLOOM-BEACON.MIT.EDU (John Chambers) Cc: tcp-ip@nic.ddn.mil Subject: Re: Limited routing between IP networks.
John, If I understand your problem correctly, EGP does exactly what you need for the star configuration. Make your central set the "core". For an arbitrary configuration, BGP is intended to solve the problem. Talk to Guy Alms of IETF Interoperability Working Group. Zaw-Sing
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 02:36:55 GMT From: uc!cs.umn.edu!wagner@tut.cis.ohio-state.edu (Paul J. Wagner) To: tcp-ip@nic.ddn.mil Subject: network backups
I recently posted a request for information about the possibility of
backing up an Ultrix system to a VAX/VMS system over TCP/IP. I
received responses regarding two current products, and a third
response containing a past summary of information about network backups
generally, from which I distilled the third item included here.
Edited summaries of the information I received follows. - Paul
------------------------------------------------------------------------
1) From: nowicki@Legato.COM (Bill Nowicki)
You recently posted a note about network backups. Our company recently
released a product that does that. The first release is for SunOS, but
Ultrix is currently being tested, and VMS can be done on request.
Please contact us for more information, at 415-329-7880.
Thanks, Bill Nowicki
Legato Systems
---------------------------
Legato NetWorker: The Complete Backup and Recover Product
Legato NetWorker is a unique, easy-to-operate product that protects
files against loss, network-wide. At the same time, it speeds file
recovery so users never waste time re-creating valuable work.
Legato NetWorker easily adapts to your environment. It uses
industry-standard network protocols and no changes are made to the
operating system of any platform. And as your network and volume of
files expands, NetWorker has the capacity and performance to handle
the load.
...
Available now: Call your local Unix software distributor or Legato at
(415) 329-7880.
2) From: VANCE@TGV.COM (L. Stuart Vance)
Our MultiNet TCP/IP for VMS package supports an RMT (Remote MagTape) server,
allowing you to use the UNIX rdump and rrestore utilites to backup/restore
files from your ULTRIX box to your VMS system. Please drop me a note if you
would like any additional information/details.
... the server allows UNIX systems that support the rdump and rrestore
utilities and PCs that have FTP Software's package (which has a port
of rtar) to access the VMS tape drive over the network. Additionally
the RMT server allows you to rdump/rrestore to a VMS file (which you
can then copy to tape) if the rdump/rrestore directly to tape takes
longer than you'd like.
3) From: Alan Strassberg <plains!oetl1.SCF.LOCKHEED.COM!alan>
>From: tony@rata.vuw.ac.nz (Tony Martindale) - past summary re: network backups
From: Hans W. Barz, R.1032.3.34, CIBA-GEIGY, 4002 Basel, Switzerland
mail: whwb@cgch.uucp
... if you connect the systems
with NFS you can write the backup with standard system backups to the
central site. Retrieving a certain file for restore is awkward using
NFS since the most backup routines scan through the whole backup (assuming
it is a tape) to find the file. This delivers a high network load with a
low outcome.
There is one similar solution around on top of Hyperchannel (at least for
VAX'es and IBM's) named HYPERTAPE (contact: MultiStream Systems
Incorporated, Denise Yegge, P.O.Box 497, Excelsior, Minnesota 55331, USA).
They had the plan to run it also on top of TCP/IP. This information is from
Feb. 1988, you may check if it is still true.
*** note - I can find no entry for MultiStream Systems in the 1989-1990
Minneapolis, MN phone book - anyone know if this company still exists?
- PJW ***
--
* Paul J. Wagner Internet - wagner@cs.umn.edu *
* Computer Science Department UUCP - ...!rutgers!umn-cs!wagner *
* University of Minnesota or, 120 S. Michigan, Eau Claire, WI 54703 *
* "think globally, act lexically" *
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 02:38:38 GMT From: sunquest!gavron@uunet.uu.net (Ehud Gavron) To: tcp-ip@nic.ddn.mil Subject: Re: Major bug in TALK on WIN/TCP for VMS
In article <28296.2689c707@vaxb.acs.unt.edu>, billy@vaxb.acs.unt.edu writes: > Hi, > > In WIN/TCP for VMS 5.1, TALK does not handle userids with numeric characters > in them correctly. > > If anybody has any suggestions, please let me know. Install MultiNet. Its versions of TALK (as well as SMTP, FINGER, nameservice, R services, etcetera) all work as per the RFCs. > Billy Barron Bitnet : BILLY@UNTVAX > University of North Texas Internet : billy@vaxb.acs.unt.edu > > PS The ANONYMOUS account on TWG.COM gives a "User Authorization Failure" > message now. PS The ANONYMOUS account on TGV.COM (the developers of Multinet) is full of useful information. :-) Ehud -- | Ehud Gavron, Systems analyst | sunquest!gavron@cs.arizona.edu (uucp) | | Sunquest Information Systems | sunquest!gavron@uunet.uu.net (alternate) | | 930 N. Finance Center Drive | gavron@sunquest.com (domain) | | Tucson, Arizona, 85710 | (602)885-7700 x.2546 (AT&Tnet) |
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 03:28:19 GMT From: ora!minya!jc@BLOOM-BEACON.MIT.EDU (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Limited routing between IP networks.
Well, here I am again with Yet Another Dumb Question...
The puzzle this week, which TFM doesn't seem to help much, comes from
a client who has various sets of machines, normally each set being one
IP network or subnet, or maybe two. At times they want to interconnect
the sets via a SLIP link, and when this is done, we should set up routing
so that any machine in set A can talk to any machine in set B. Later,
and in generally overlapping, set B will be connected to set C, and any
machine in set B should talk to any machine in set C.
The tricky part that I can't answer is that they DON'T want the relation
to be transitive. In the above case, machines in set A should not be
able to communicate with those in set C. If they can, we don't get
the contract. The most important configuration will be essentially
a star, with one central set having lots of links out to other sets,
but in fact, an arbitrary graph is a better picture to plan on.
Part of the problem, of course, is that it pretty much needs to be
automated. If the solution requires any understanding of IP routing
on the part of the users, it won't work. Solutions that require a
network hacker going in as super-user on each machine and adjusting
routing tables by hand are totally outside the ballpark. We need
to provide a command of the form "Link host1 host2", which will
establish the link and set up the routing. Later on another command
may be used to shut down the link (or more likely they will just
turn the modem off and walk away ;-).
So can IP handle this? More specifically, can any of the common routing
tools (arp, routed, gated, whateverd) be used so as to get the desired
limited routing. If so, how might one do it?
I've been suggesting that they should pay me to rewrite routed and/or
gated to do the job the way they want. This would probably be fun and
profitable and all that, but I suspect that it might be a waste, since
I do sorta have this suspicion that existing tools might already be up
to the job, if I could decrypt the manuals. (Let's see, they appear to
be using mostly English words, and a syntax that is somewhat like that
of English; the cleartext is likely in an Indo-European language... ;-)
--
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: [I've gotta get a new one of these some day.]
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 04:01:15 GMT From: hayes.fai.alaska.edu!wisner@decwrl.dec.com (Bill Wisner) To: tcp-ip@nic.ddn.mil Subject: Re: Major bug in TALK on WIN/TCP for VMS
In article <4875@sunquest.UUCP> gavron@sunquest.UUCP (Ehud Gavron) writes: > Install MultiNet. Its versions of TALK (as well as SMTP, > FINGER, nameservice, R services, etcetera) all work as > per the RFCs. There is no RFC for talk. Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 /* you are not expected to understand this */
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 03 Jul 90 10:36:40 EDT From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu To: TCP/IP List <tcp-ip@nic.ddn.mil> Subject: What is tn3270?
What sort of animal is tn3270? Is it a standard protocol defined by an RFC? What are its origins? Thanks for you help. ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 08:36:20 GMT From: eru!luth!sunic!mcsun!hp4nl!star.cs.vu.nl!sater@bloom-beacon.mit.edu (Staveren van Hans) To: tcp-ip@nic.ddn.mil Subject: parallel networks problem
Recently I posted a question to these groups to which, to my surprise, I received no reactions at all. This seems strange since it addresses a problem that many of us are going to face. Now there is of course the possibility that this is so obvious that you were all embarrassed by the question, but I doubt it. Suppose part of a network looks like this --------------------------------------------------------- network A | | | ----------------- ----------------- ---------- | A.1 | | A.2 | | A.3 | | Host foo | | Host bar | |Host zot| | B.6 | | B.7 | | | ----------------- ----------------- ---------- | | --------------------------------------------------------- network B so two parallel networks with some multihomed and some singlehomed hosts. Further suppose that network B is preferable to network A, because of load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). How would one set up addressing and routing for such a configuration? Using the DNS address lookup you get two addresses for each machine, but most software doesn't understand that currently and only uses the first one. Now the documentation suggests that you can order the addresses so that certain preferred networks come in front, but looking at our bind source code shows that that is not implemented. So host foo looks up host bar, and gets the address set (A.2, B.7). Both addresses are on directly connected networks. How do you make sure that either it uses B.7, or it uses A.2 but still routes it over network B. Ideally this should be done by the routing layer of course, but current routing software will probably send a packet for A.2 onto network A, unless a host route for A.2 points to B.7. You can of course set up all these routes by hand, but if the network size increases this gets to be too much trouble. You could imagine that host bar propagates a host route for A.2 on network B, and all hosts are persuaded that network A is expensive by messing around with metrics, but that would lead to a proliferation of host routes floating around the network, and maybe even propagating to the rest of the Internet, which would be extremely undesirable. How do people solve this? Do people actually have situations like this already? Inquiring minds want to know. Hans van Staveren Vrije Universiteit Amsterdam, Holland
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Tue Jul 3 09:43:51 1990 From: cctal!andrew@relay.EU.net To: tcp-ip@nic.ddn.mil Subject: SLIP Info
From andrew Wed Jun 27 12:00:24 1990 To: ukc!nic.ddn.mil!tcp-ip-request Subject: SLIP Info Cc: andrew Date: Wed Jun 27 12:00:24 1990 Second call for SLIP info ========================= A couple of weeks ago, I posted to the net a request for people who were using SLIP or ppp to mail me info on where they got it, what they had to do to it to make it work and what they are using it for, so that I could do a summary and post it to the net. The number of requests for the info far exceeded the contributions to the information and I notice that more questions about SLIP are turning up on the net, so I am taking this occasion to post for a second time to ask if anyone who missed or did not reply to the first posting and who is making SLIP or ppp work for its living could please mail me with the details. I have more or less got the info on the location of info on and the code for SLIP and ppp (largely by my own researches) but I do need more on the implementation/management functions to make my report complete. Thanks if you contributed before and thanks if you are about to contribute. Andrew Hardie andrew@cctal.co.uk London, England
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 13:56:02 GMT From: sdd.hp.com!samsung!interlan.InterLan.COM!interlan.interlan.com!towfiq@ucsd.edu (Mark Towfigh) To: tcp-ip@nic.ddn.mil Subject: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
Note the followup group is comp.protocols.tcp-ip, as I don't read comp.unix.questions. In article <1990Jul3.040115.12000@hayes.fai.alaska.edu> wisner@hayes.fai.alaska.edu (Bill Wisner) writes: There is no RFC for talk. I know this is true -- it's a problem because there are incompatible versions of TALK out there. Specifically, it seems there was a change between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few questions: does the current TALK daemon support both the old and new versions? And what about the client? As far as I can make out, the new talkd can tell the difference between the two protocols, and when a remote user requests a connection, the local TALK daemon figures out whether they are TALKing 4.2-style or 4.3-style, and then tells the local user to run one of two programs, either /usr/ucb/talk or /usr/old/talk. All this aside, I have never seen this work with the 4.2 TALK, only the 4.3 flavor. Is there anyone out there running a system which can talk in both styles, and deal with incoming and outgoing TALK requests? -- Mark Towfigh, Racal InterLan, Inc. towfiq@interlan.Interlan.COM W: (508) 263-9929 H: (617) 488-2818 uunet!interlan!towfiq "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 14:36:40 GMT From: SSJACK@ECUVM1.BITNET To: comp.protocols.tcp-ip Subject: What is tn3270?
What sort of animal is tn3270? Is it a standard protocol defined by an RFC? What are its origins? Thanks for you help. ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 12:24:00 GMT+109:13 From: "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: Xerox 6085 and TCP/IP
Date sent: 3-JUL-1990 12:24:46 Hi, Is there a realistic alternative to the expense of TCP/IP for Xerox 6085's. File transfer requirements are not really regular, and it seems to incur that kind of expense is overkill. Thanks for any help, Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 15:53:26 GMT From: snorkelwacker!bu.edu!dartvax!litle!tom@apple.com (tom hampton) To: tcp-ip@nic.ddn.mil Subject: TCP/IP Networking -- how do you make it work?
We have been banging away trying to get heterogeneous networking
over TCP/IP going at our shop. We keep running into little snags,
we find problems and trudge on. So, I ask:
1) Who out there is doing heterogeneous networking using
Unix and other TCP/IP implemenations?
2) Is anyone having success doing networking on 386's? If so, whose
TCP/IP package are you using on the 386?
3) Do you have any specific advice on how we get this going faster? For
example, should we have a LAN analyzer (which one?) should we stick
with a certain box for development (Sun?)
4) Does anyone recommend building a TCP/IP module for general purpose
use -- something that hides some of the complexity of the Berkely
socket interface?
5) Do people hire consultants to do this sort of work?? Do you
recommend anyone in particular?
Your responses to these questions represents a valued resource to us,
thanks for your time.
--
===============================================================================
Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
603 643 1832
-------------------------------------------------------------------------------
Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com tom@litle.uucp {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 18:17:59 GMT From: jik@athena.mit.edu (Jonathan I. Kamens) To: tcp-ip@nic.ddn.mil Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
In article <TOWFIQ.90Jul3095602@interlan.Interlan.COM>, towfiq@interlan.Interlan.COM (Mark Towfigh) writes: |> I know this is true -- it's a problem because there are incompatible |> versions of TALK out there. Specifically, it seems there was a change |> between the 4.2BSD talk/talkd and the one in 4.3BSD. I have a few |> questions: does the current TALK daemon support both the old and new |> versions? No. You have to run two different versions of talkd, one on the port reserved for the old talk protocol, and one on the port reserved for the new talk protocol. On our system, old talk is 517 (with the service name "talk"), and new talk is 518 (with the service name "ntalk"). If you don't have the right daemons running on the right ports, then talk clients are going to have trouble conversing with your machine. |> And what about the client? Nope, the old talk client knows how to talk only to the old talk port, and the new talk client knows how to talk only to the new talk port. Or, at least, that's how things *should* work, but alas, we live in an imperfect world.... |> As far as I can make out, the |> new talkd can tell the difference between the two protocols, and when |> a remote user requests a connection, the local TALK daemon figures out |> whether they are TALKing 4.2-style or 4.3-style, and then tells the |> local user to run one of two programs, either /usr/ucb/talk or |> /usr/old/talk. No, this isn't how it works, or at least not how it appears to be set up in 4.3BSD. There are two different talkd programs (/etc/talkd and /etc/ntalkd is what we've got them named, but I don't know how universal that is). The hard-coded client name in the old talk daemon is /usr/ucb/talk.old or /usr/old/talk, and the hard-coded client name in the new talk daemon is /usr/ucb/talk. The new talk daemon and the old talk daemon don't know about each other, and don't know about each other's protocols. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 20:07:10 GMT From: brian@ucsd.edu (Brian Kantor) To: tcp-ip@nic.ddn.mil Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
There are two talk programs using two different protocols; the older one still found on Suns and such is architecture and compiler dependent and often won't work across heterogeneous hosts. The newer talk will work in such an environment but not everyone has it. Since it's part of the great Berkeley giveaway, you should get the newer talk and install it. It can coexist with the older talk because it lives on a different port and has a different name. 4.3-Tahoe-BSD comes with both. - Brian
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 20:10:00 GMT From: sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu (Mark Crispin) To: tcp-ip@nic.ddn.mil Subject: Re: parallel networks problem
In article <7050@star.cs.vu.nl> sater@cs.vu.nl (Staveren van Hans) writes: >Suppose part of a network looks like this > > --------------------------------------------------------- network A > | | | > ----------------- ----------------- ---------- > | A.1 | | A.2 | | A.3 | > | Host foo | | Host bar | |Host zot| > | B.6 | | B.7 | | | > ----------------- ----------------- ---------- > | | > --------------------------------------------------------- network B > >so two parallel networks with some multihomed and some singlehomed hosts. >Further suppose that network B is preferable to network A, because of >load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). >How would one set up addressing and routing for such a configuration? TOPS-20 had a concept (which I invented) called "preferred IP address" and "preferred network" which answered this question. There was, from the beginning, a "default IP address" which was used in IP datagrams where it was not obvious which local address of a multi-homed host was best to use as the source IP address. The problem was that very often network A would be a lower-speed backbone and network B a higher-speed stub network. The default mechanism would ensure that host foo would use its A.1 address in talking to host zot and host zowie on a network C (since the only way to reach the B.6 address from outside of network B would be to go through an A->B gateway, so you might as well use the A.1 address and save a hop). In talking to host bink which only had a B.8 address, host foo would use its B.6 address. The problem was which address to use for bar. Hence the "preferred" address and network, which would take precedence in any choice between a "preferred" and any other (including the default) address. Foo and bar would make network A be "default" and network B be "preferred." I'm surprised Unix hasn't picked up on this yet. _____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105 _|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!" |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?" --|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin." /|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 21:11:12 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@nic.ddn.mil Subject: Re: parallel networks problem
You haven't gotten an answer because there's no good answer. It depends upon the routing and domain technology that you use, and even then solutions tend to be kludges rather than general solutions. We prefer to keep all routing knowledge in our routers, so generally hosts do not run routing protocols. Our routers do proxy ARP, so we normally use default routes with a zero metric, i.e. route add default `hostname` 0 This causes all destinations to be treated as if they were on the local Ethernet. With more than one Ethernet address, I normally set things up to use the default on the "preferred" Ethernet, and hardwire routes for the specific subnets that I want on the other Ethernet. Typically it's just the connected subnet, which of course happens automatically. The problem with this is that you don't automatically change to take advantage of the secondary network if the primary one is down. However Ethernets so seldom go down that this isn't a concern for me. In general the Internet has not solved the problem of how hosts find routers, particularly with multiple Ethernets. There are lots of solutions known in principle, but the commonly used TCP/IP implementations don't have the right features to use the known solutions. 4.3 is a lot better than 4.2, but still doesn't really supply all the necessary features. The IETF hasn't helped, by failing to specify a gateway-finding mechanism, such as the proposed "ICMP wheres-my-gateway".
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 21:17:20 GMT From: umich!caen!math.lsa.umich.edu!math.lsa.umich.edu!emv@CS.YALE.EDU (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
a word as to actual usage of these two talks across the nsfnet backbone -- in the months where port-by-port statistics are kept on nis.nsf.net (the *PORTS files) talk+ntalk (517+518) is in about the 0.2% - 0.3% range, with the amounts varying quite substantially and talk generally having more traffic than ntalk. Must be lots of suns, I guess. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> comp.archives moderator
-----------[000031][next][prev][last][first]----------------------------------------------------
Date: 3 Jul 90 21:53:16 GMT
From: dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To: comp.protocols.tcp-ip
Subject: Xerox 6085 and TCP/IPDate sent: 3-JUL-1990 12:24:46 Hi, Is there a realistic alternative to the expense of TCP/IP for Xerox 6085's. File transfer requirements are not really regular, and it seems to incur that kind of expense is overkill. Thanks for any help, Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 22:06:13 GMT From: eru!luth!sunic!tut!kannel!kim@bloom-beacon.mit.edu (Kimmo Suominen) To: tcp-ip@nic.ddn.mil Subject: Remote Printer Protocol (BSD lpd) documentation needed
I know this has been asked before in some newsgroup and I'm sorry to repeat
the question. However I just ran into a problem which might be solved by this
RFC.
So - if anyone knows of a document describing the remote printer protocol also
known as lpd protocol (BSD lpd), would she/he be so kind and send me e-mail
telling where to get/access that document. If it is described in a RFC then
the number of that RFC would be greatly appreciated.
Thanks for your attention
--
Kim ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
"That's what ( Kimmo ! Lappeenranta U of Technology ! kim@lut.fi )
*I* think." ( Suominen ! Computing Centre * Finland ! KUULA::KIM )
''''''''''''''''''''''''''''''''''''''''''''''''''''''
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 22:07:13 GMT From: uswat!matthews@boulder.colorado.edu (John Matthews) To: tcp-ip@nic.ddn.mil Subject: Major Bug in QuickMail/MacTCP
We experienced a rather severe bug the other day with QuickMail.
We aren't sure why, but the Mac started broadcasting ~150 ARP
requests per second which put a tremendous load on every machine
attached to our ethernet. The machine it was ARPing for responded
to almost every request. The MAC appeared to ignore the responses
completely. We called StarNine and told them about it. They said
they had seen the problem before, but thought it only occurred if
you configured a default gateway and it went down. This wasn't the
case for us because we didn't have a default gateway configured.
The host it was ARPing for was the primary mail server not a default
gateway. They seemed to think it was a bug in MacTCP and not
QuickMail but weren't sure. Has anyone seen this bug before?
Thanks in advance,
John Matthews
matthews@uswat.uswest.com
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 00:08:32 GMT From: att!mcdchg!laidbak!obdient!bisnews!donl@ucbvax.Berkeley.EDU (Donald P Leaman @ bisnews.UUCP) To: tcp-ip@nic.ddn.mil Subject: PD uucpd wanted
HELP!!! We are looking for a PD product that will set up the NLS service as a valid uucp device. We have heard that there is a public- domain package named/called 'uucpd' that will accomplish this simple task for us. Otherwise, if anyone knows how we can get our uucp to start a TCP/IP connection, we would greatly appreciate any ideas or pointers in the right direction. I will be happy to post a summary of responses if the case dictates. We are running SCO UNIX 3.2 as I'm sure this information will (could) be helpful. Thanks in advance! PS Please email me directly, as I rarely read the news...... -- Donald P Leaman, Systems Engineer | "Facts are stupid things" Business Interactive Solutions, Inc. | -Ronald Reagan, 1988 Woodridge,IL [vox] (708)241-0010 |___________________________ E-mail:..clout!bisnews!donl (or) donl@bis.chi.il.us
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 04:21:23 GMT From: usc!samsung!munnari.oz.au!uniwa!aldetec!mawson@ucsd.edu (Graeme Mawson) To: tcp-ip@nic.ddn.mil Subject: Clients/servers with TCP/IP on SysV
We have been trying to create a connection between two Unix machines running SysV. On one we have a client program sending connection requests and on the other we have a server program listening for connection requests. The machines are connected via Ethernet using TCP/IP. We have had no success - with the client machine not receiving connection accepts from the server. One fundamental problem seems to be binding a suitable well-known address to the server. Has anyone had any success with a similar arrangement? Can anyone offer any advice/help? Thanks in advance... Graeme ........................................................................... : ___ : Graeme Mawson - Electronic Engineer, Aldetec Pty Ltd (Perth) : : \ / : Internet: mawson@aldetec.oz.au ACSnet: mawson@aldetec.oz : : -|- : ph. 61 +9 445-1888 x255 : : / \ : Legendary quote: "Sometimes a cigar is just a cigar" - Freud : :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 05:03:31 GMT From: netcom!bobb@apple.com (Bob Beaulieu) To: tcp-ip@nic.ddn.mil Subject: Printing with TCP-IP
We just got a pyramid M1E (mips) based system (sysv) at work and have it set up at work running informix 2.10.03K sql 4gl. It connected to a Plexus P/60 (m68000) (sysv) via ethernet tcp-ip. I am having no problem sending data to a printer on the Plexus in Informix using the following command (while on the pyramid):: report to pipe "cat |/usr/ucb/rsh <systemname> 'lp -d<printername>'" But, what I can't do it send OPTIONS to a printer on the Plexus side from the Pyramid? I've tried modifying/creating various interface script to handle #of copies and various printer control options (compress,etc.) and would appreciate any help ... I would like to end up with a script that can take an 'lp -d<printername>' command and send this, and any -o options on one system and send the command thru the ethernet to the <printername> on another system. Thanks for any help. Bob Beaulieu
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 09:08:22 GMT From: njin!uupsi!sunic!sics.se!brad@rutgers.edu (Brad Smith) To: tcp-ip@nic.ddn.mil Subject: Accessing Ethernet multicast in Unix.
I am working with some people who are doing some work where they would like to use Ethernet multicasts from Unix (SunOS 4.x in particular). How does one go about doing this. Some things I've read seem to indicate that the ethernet drivers need to be modified to support multicasting... is this true, and if so is their such a modified driver available? Thanks in advance, Brad Smith Swiss Federal Institute of Technology brad@imhfhp14.epfl.ch
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 04 Jul 90 16:24:17 -0400 From: "Martin Lee Schoffstall" <schoff@psi.com> To: mcdchg!ddsw1!karl@rutgers.edu (Karl Denninger) Cc: tcp-ip@nic.ddn.mil Subject: Re: MAC Email Services from Unix Systems
Cayman has a nice system called GatorMail which will provide this, they are located in Cambridge, MA and via email at cayman.com. Good Luck, Marty ------------ We're looking for a package (PD, Shareware or commercial is fine) that will give us Email connectivity with Unix machines. We have uShare loaded on a Sun workstation. It comes with a Mail desk accessory which, unfortunately, doesn't work at all (it gives System Bombs and fails to write or delete messages). This service DOES, however, permit printer and file services, and those aspects appear to work properly. We need email connectivity. Ideally the package would interact with the Unix system such that you could use Unix mailboxes, although I am willing to settle for a daemon that reads the Unix mailbox and re-writes in a Mac-style format somewhere else... or even something that is opened and runs in the background receiving via SMTP (we have Multifinder on our machines). Help! Commercial informaiton is fine, as are pointers to things or phone calls (even from salesmen!). We can FTP if needed as well. This is a high priority item; any and all help appreciated. Note that the reply address is NOT the same as where this message is being posted from (I'm at home right now and prefer to receive replies at work). Please email rather than post replies. Thanks! -- Karl Denninger (kdenning@ksun.naitc.com, <well-connected>!ddsw1!karl) AC Nielsen, Bannockburn, IL (708) 317-3285
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 04 Jul 90 14:49:41 EDT From: Caleb Strockbine <QOP%CORNELLA.BITNET@CORNELLC.cit.cornell.edu> To: TCP-IP@NIC.DDN.MIL Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP, for VMS)
Steve- I've got one version of talk running already... the daemon doesn't run all the time (some daemon, eh?) but instead it's called by the "master internet daemon" called inetd, which also calls a bunch of the other communication daemons, but only when they're necessary. As far as I know, we don't have ntalk, which seems to be the newer version of talk, so maybe I'll look for that so we'll be able to talk to anyone. I wondered about that message about Mac/Unix connectivity, and whether that wasn't the same thing we're trying to do. Maybe I'm beginning to get the hang of this! -Caleb.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 Jul 90 16:28:14 EDT From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: Ethernet - printer interfaces
There are a few companies that have parallel port to ethernet adapters. The one with which we have experience is from a company called XIRCOM. They can be reached at (818) 884-8755. Brian Kaye University of New Brunswick On Wed, 4 Jul 90 15:34:22 GMT Ricard Wolf <rochester!kodak!uupsi!sunic!lth.se!newsuser@RUTGERS.EDU> writes: > Hi out there! > > I'm looking for some sort of interface/protocol converter that enables > a generic parallel (Centronics-type) or serial (RS-232 etc) printer to > be hooked up to an ethernet network. The unit shuold be able to handle > a variety of protocols (ftp, telnet etc). > > Anyone know of anything? > > Please email any responses. > > Thanks in advance, > -- > --- > Ricard Wolf > > +--------------------------+-------------------------------------+ > | Ricard Wolf | Lund Institute of Technology | > | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | > +--------------------------+-------------------------------------+
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 15:34:22 GMT From: rochester!kodak!uupsi!sunic!lth.se!newsuser@rutgers.edu (Ricard Wolf) To: tcp-ip@nic.ddn.mil Subject: Ethernet - printer interfaces
Hi out there! I'm looking for some sort of interface/protocol converter that enables a generic parallel (Centronics-type) or serial (RS-232 etc) printer to be hooked up to an ethernet network. The unit shuold be able to handle a variety of protocols (ftp, telnet etc). Anyone know of anything? Please email any responses. Thanks in advance, -- --- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 18:04:53 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: parallel networks problem
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes: > Recently I posted a question ... > Further suppose that network B is preferable to network A, because of > load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). > How would one set up addressing and routing for such a configuration? > ... > Hans van Staveren > Vrije Universiteit > Amsterdam, Holland This problem exists within FDDI itself. FDDI is a dual ring of two 100Mbit counter rotating rings. 100Mbit/sec is only 10 times faster than 10MHz ethernet, and so is not considered "fast" by some of us. Notice that workstations today are 100 times faster than in the early 1980's when 10MHz ethernet became popular (i.e. 0.25-1.0 VUPS then and 5 to 200 VUPS now) (1 VUPS=1 "MIPS"=1 VAX 11/780). The birthday paradox ensures that either an FDDI ring will almost never be "wrapped" or it will be partitioned too much of the time. This means that dual attached, dual-MAC stations could at least in principle push more bytes than single-MAC stations. Unfortunately, the only currently publically demonstrated and known scheme for using both rings involves using two IP networks, one for each ring. This works, but is at best a clunky kludge. In the absense of some smarter routing, applications must somehow split their traffic between two IP hostnumbers. There are applications for which this is not a hardship, but it is in general far from satisfying. Proposals for combining both rings into a single IP network have been made, but to the best of my knowledge, there is no such single-IP network proposal that has had all of the holes, gotchas, and boundary cases covered. The single-network proposals involve varying but substantial amounts of complexity in the link layers, including extensions to ARP. As far as I know, the current draft standards (ie. IETF) suggest using a dual-IP-network until a single-IP-network scheme is completed and accepted. It would be really swell if someone could solve the FDDI-ethernet load balancing problem that at least two people have mentioned in recent months in this forum. It would make the trivial to implement dual-IP-network solution for FDDI tolerable, eliminating the need for the complicated ARP and other link layer extensions needed for the single-IP-network ideas. Vernon Schryver Silicon Graphics vjs@sgi.com
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 18:49:41 GMT From: QOP@CORNELLA.BITNET (Caleb Strockbine) To: comp.protocols.tcp-ip Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP, for VMS)
Steve- I've got one version of talk running already... the daemon doesn't run all the time (some daemon, eh?) but instead it's called by the "master internet daemon" called inetd, which also calls a bunch of the other communication daemons, but only when they're necessary. As far as I know, we don't have ntalk, which seems to be the newer version of talk, so maybe I'll look for that so we'll be able to talk to anyone. I wondered about that message about Mac/Unix connectivity, and whether that wasn't the same thing we're trying to do. Maybe I'm beginning to get the hang of this! -Caleb.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Thu, 5 Jul 90 09:24:27 -0500 From: konda@zeus.mgmt.purdue.edu (Suresh Konda) To: tcp-ip@nic.ddn.mil Subject: Unsubscribe
Please unsubscribe me from this list. Thanks.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Thursday, 5 July 1990 08:10-MDT From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL> To: SSJACK%ECUVM1.BITNET@NCSUVM.NCSU.EDU Cc: WANCHO@WSMR-SIMTEL20.ARMY.MIL Subject: Unix tar uncompression
Jack, The following files are available from this host via anonymous ftp or by formatted requests from LISTSERV@RPIECS or LISTSERV@NDSUVM1: PD1:<MSDOS.SQ-USQ> COMPRS16.ARC B 47101 880409 Unix-compatible compress/uncompress - 16 bit DECOMP2.ZIP B 17384 900430 Unix-compatible 16 bit uncompress, w/C source PD1:<MSDOS.FILUTL> PDTAR.ARC B 117152 880614 Read/write TAR files on PC TAR.ARC B 37392 871208 Read Unix TAR files on a PC PD1:<MSDOS.STARTER> PK361.EXE B 119598 880801 Fast file ARC make/extract PKPAK/PKUNPAK v3.61 PKZ110EU.EXE B 140116 900402 Katz's ZIP archive package v1.10, export vers. TARREAD.EXE B 14928 870820 Read Unix TAR files on a PC --Frank
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 02:57:17 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: Multiple versions of TALK? (was: Major bug in TALK on WIN/TCP for VMS)
In article <EMV.90Jul3171720@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >a word as to actual usage of these two talks across the nsfnet >backbone -- in the months where port-by-port statistics are kept on >nis.nsf.net (the *PORTS files) talk+ntalk (517+518) is in about the >0.2% - 0.3% range, with the amounts varying quite substantially and >talk generally having more traffic than ntalk. Must be >lots of suns, I guess. FYI, the talk/ntalk protocol is just used for connection setup. Once people agree to talk, both protocols contain "pointers" to TCP ports to carry the actual conversation on. In fact, these "pointers" are what caused the inability for "talk" to function in a heterogeneous environment (without all kinds of heuristic gyrations, that is). -- Warner Losh imp@Solbourne.COM
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Jul 90 07:51:06 EDT From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu To: TCP/IP List <tcp-ip@nic.ddn.mil> Subject: Unix tar uncompression
I need a means of uncompressing UNIX tar files for a PC. Is there a PC based utility available for this? ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Jul 90 10:48:49 EDT From: Jonathan Charles Cohn <jcohn@note2.nsf.gov> To: TCP-ip@NSF.GOV Subject: Re: parallel networks problem
OSPF does have some of the features required to put higher priority on certain networks. However, I do not know how it interfaces with hosts that are not multihomed. Jonathan Cohn
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Jul 90 14:16:41 EDT From: Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU> To: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu, TCP/IP List <tcp-ip@nic.ddn.mil> Subject: Re: Unix tar uncompression
>I need a means of uncompressing UNIX tar files for a PC. Is there a >PC based utility available for this? There may be others, but PC/tar is included in FTP Software's PC/TCP package. It will even use rsh or rexec to access a tar file on a Unix system directly, without a separate file transfer step. Note that tar does not compress/uncompress files. If you are referring to compressed tar files (*.tar.Z), you'll need to find a PC version of uncompress (or zcat) as well. Doug Nelson Michigan State University
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Jul 90 14:34:25 EDT From: Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU> To: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu, TCP/IP List <tcp-ip@nic.ddn.mil> Subject: Re: What is tn3270?
>What sort of animal is tn3270? Is it a standard protocol defined by >an RFC? What are its origins? TN3270 refers to an implementation of the Telnet protocol in which both parties agree to use the native 3270 byte stream to represent the host and terminal data. The agreement to use 3270 mode is done by standard Telnet option negotiations. A defacto standard exists for this option negotiation, but has never been defined in an RFC, although a proposed replacement has (see RFC 1041; don't know as it has been implemented). Doug Nelson Network Software Manager Michigan State University
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 11:51:06 GMT From: SSJACK@ECUVM1.BITNET To: comp.protocols.tcp-ip Subject: Unix tar uncompression
I need a means of uncompressing UNIX tar files for a PC. Is there a PC based utility available for this? ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 14:54:22 GMT From: samt19!hq!terry@PENTAGON-AI.ARMY.MIL (Terry Bernstein) To: tcp-ip@nic.ddn.mil Subject: Looking for Network Management Software
I am looking for a good network management software package. We manage an enterprise-wide LAN. It consists of a broadband backbone with numerous baseband segments. On the broadband we use 3-Com hardware. We use several Sun 3/260s to manage the LAN. We are looking for software to help us detect and isolate network faults. We currently use some in house developed software to 'ping' network devices, but don't use the 3-Com management statistics extensively. Sun-Net manager might fill our needs, but we aren't sure. Any comments on this software and other suggestions would be appreciated. -- terry --
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 16:13:09 GMT From: maytag!gamiddle@iuvax.cs.indiana.edu (Guy Middleton) To: tcp-ip@nic.ddn.mil Subject: Re: The history of net numbers
In article <57885@bbn.BBN.COM> mckenzie@labs-n.bbn.com (Alex McKenzie) writes: > Since there have been a number of questions about the history of network > number assignments, I've searched the "Assigned Numbers" RFCs to see > what light they could shed on the subject. Here's what I found: A related question: in which document is the network number for the Central University of Mars assigned?
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 Jul 90 20:52:26 EDT From: Harold Pritchett <HAROLD@uga.cc.uga.edu> To: TCP-IP@NIC.DDN.MIL Subject: Re: libc for SUN 4.0.3c
On Tue, 3 Jul 90 10:04:47 -0700 Chris VandenBerg said: >Good morning all, > I'm trying to get a SPARC/1 running with the resolver and I was told > that I have to substitute a shared libc that the resolver, in >addition to adding the resolv.conf file. Does >anyone have one of these or know if one for >4.0.3c? And, does anyone know how this is set up >in SUNOS4.1? Please respond to me directly, I >don't want to waste bandwidth on so trivial a >request. Hold on there a minute. If anyone can get the resolver to work with 4.1, please post it to the list. We have not been able to get it to work either, and so far we have not gotten any help from SUN as it appears they can't get it to work either. Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: harold@uga.cc.uga.edu The University of Georgia | uucp: gatech!ugacs!csun2!harold Athens, GA 30602 | fido: 1:370/60 (404) 542-3135 | Bbs: SYSOP at (404) 354-0817
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 18:10:57 GMT From: usc!sdd.hp.com!samsung!xylogics!bu.edu!dartvax!litle!tom@ucsd.edu (tom hampton) To: tcp-ip@nic.ddn.mil Subject: TCP/IP slowdown and window field of packet
We are having a slow-down problem between two TCP/IP programs.
Both programs do fine for a while, transferring some 50,000 bytes/sec,
until all of a sudden, they appear to hang and transfer no more than
1/100th of that. According to a crude packet monitor we have, the
problem seems to occur when the window field of the packet gets set
down (we don't know by whom) to 0.
1) Has anyone had this problem before? We fear it might have something
to do with an interacticion between Stratus (VOS) TCP/IP and ISC
2.2 Unix for the 386.
2) Are we right in thinking that it has something to do with the
window field?
3) Any suggestions on how might complete our diagnosis, or, better yet
treat the situation?
Thanks for your replies.
--
===============================================================================
Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
603 643 1832
-------------------------------------------------------------------------------
Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com tom@litle.uucp {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 18:16:41 GMT From: 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: Unix tar uncompression
>I need a means of uncompressing UNIX tar files for a PC. Is there a >PC based utility available for this? There may be others, but PC/tar is included in FTP Software's PC/TCP package. It will even use rsh or rexec to access a tar file on a Unix system directly, without a separate file transfer step. Note that tar does not compress/uncompress files. If you are referring to compressed tar files (*.tar.Z), you'll need to find a PC version of uncompress (or zcat) as well. Doug Nelson Michigan State University
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 18:34:25 GMT From: 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson) To: comp.protocols.tcp-ip Subject: Re: What is tn3270?
>What sort of animal is tn3270? Is it a standard protocol defined by >an RFC? What are its origins? TN3270 refers to an implementation of the Telnet protocol in which both parties agree to use the native 3270 byte stream to represent the host and terminal data. The agreement to use 3270 mode is done by standard Telnet option negotiations. A defacto standard exists for this option negotiation, but has never been defined in an RFC, although a proposed replacement has (see RFC 1041; don't know as it has been implemented). Doug Nelson Network Software Manager Michigan State University
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 20:16:04 GMT From: ingr!b11!griffin@uunet.uu.net (Tommy Griffin) To: tcp-ip@nic.ddn.mil Subject: telnet and pc's
We're experiencing some difficulty communicating between our workstations and PCs using Telnet over TCP/IP. The PCs are running Sun's PC/NFS product through the 3-Com Ethernet card. The problem occurs when a Telnet session has been established from a PC to a workstation, and the workstation is generating a continuous stream of output to be displayed by the PC. The PC begins to display the output, but instead of displaying a continuous stream of data, new data is displayed at intermittent intervals with 1-20 second delays between bursts of output. The delay usually ramps up to 20 seconds and stays there. The problem seems to be caused by the PC's inability to receive and/or process Ethernet/TCP frames which arrive within 5 milliseconds of each other. Our workstation sends output to the PC in TCP frames carrying 64 bytes of data. The 512 byte TCP window offered by the PC's TCP allows us to send up to 8 frames inside one window, so these frames can arrive with very little inter-frame spacing. When the PC drops a frame, we have to retransmit the data that was lost. The Jacobson algorithm in our implementation of TCP causes us to *DOUBLE* our retransmission timer each time we have to retransmit data. We eventually increase the retransmission timer to its maximum value, 20 seconds, which explains why we're seeing bursts of data every 20 seconds. We have some Sun workstations here, and a few PCs running Sun's PC/NFS, and when we Telnet from the PCs to the Suns we don't see any delay on continuous output from the Suns to the PCs. So, we got out our Ethernet Sniffer to figure out what the Suns are doing that we aren't. It seems that the Sun workstations somehow determine that they're communicating with Sun PC/NFS on a 3-Com card, because they only allow one TCP frame to be transmitted to the PC at a time. They send a frame, and wait for an acknowledgement (or a retransmission timeout), then send another frame, and so on. This occurs even if the frame contains less data than the offered window size. When we Telnet between Suns, or from Suns to our workstations, the Suns transmit many small TCP frames containing data in the offered TCP window before waiting for an acknowledgement. We would like to communicate effectively between our workstations and PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller. What we would like to know is how does the Sun workstation TCP implementation determine that it is talking to 3-Com PC/NFS? Does it look at the Ethernet address to determine that the board came from 3-Com? Is there something special in the TCP SYN packets that they key on? Any light that can be shed upon this matter would be greatly appreciated. Tom Griffin griffin@ingr.com -- ______________________________________________________________________________ Tommy Griffin
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 20:59:59 GMT From: noose.ecn.purdue.edu!mentor.cc.purdue.edu!mace.cc.purdue.edu!du4@iuvax.cs.indiana.edu (Ted Goldstein) To: tcp-ip@nic.ddn.mil Subject: Throughput of IBM TCP/IP router
I am investigating a proposal to connect a token ring backbone in
our building with a campus wide ethernet backbone through a dedicated
PC running IBM's tcp/ip router program.
I understand that this PC could become a data bottleneck, but
have been unable to get a good feel for just how much traffic will
cause things to really slow down. We are looking at using an old dual
floppy IBM PC with a 16 Mbs token ring card and Ungerman bass ethernet
card as the router, and initial usage would propably be mostly FTP
transfers and maybe a few telnet sessions. As usage grew we would
upgrade the PC to an AT , to a 386 and so on.
Does anyone out there with experience with this type of setup have
any insight as to whether we will be able to get adequate throughput?
Any ideas as to how one calculates the ablilty of a router to handle
a given load? Any information or pointer would be greatly appreciated.
--
Ted Goldstein E-mail: du4@mace.cc.purdue.edu
Network and Systems Admninistrator Phone : (317) 494-9070
Purdue University School of Technology Office: Knoy Hall, Rm G009
-Life is like a merry-go-round . . . they both have horses.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 22:10:45 GMT From: usc!samsung!munnari.oz.au!goanna!minyos!chudich!rcora@ucsd.edu (Robert Alessio) To: tcp-ip@nic.ddn.mil Subject: Dialin access to a TCP/IP network using Basic Rate ISDN & SLIP - experinces?
Has anyone had any experience in using Basic Rate ISDN so to allow dialin access for a remote IBM PC at 64kb/s. This is to allow remote access to a TCP/IP network for the tranferring of compressed document images which are about 40kbytes per page. We intend to use a Basic Rate ISDN Terminal Adapter card which will appear to the IBM PC as a COM port. My first guess would be to use the SLIP protocol over the 64kb/s link. (Note, I have ever setup a SLIP link.) Which SLIP package would one recommend (PC/TCP plus)? Are there alternative protocols? How would you allocated an IP address for remote IBM PCs which could connect to a different SLIP gateway everytime they dialin? P.S Does any know about the availability of Group IV ISDN Fax Servers or cards for IBM PCs ? Thanks inadvance Robert Alessio ACSnet: rcora@chudich.co.rmit.OZ.AU Professional Officer ARPA: rcora%chudich.co.rmit.OZ.AU@uunet.UU.NET Department of Communication and Electrical Engineering Royal Melbourne Institute of Technology 124 LaTrobe Street UUCP: ...!uunet!munnari!chudich.co.rmit.OZ.AU!rcora Melbourne, 3000 BITNET: rcora%chudich.co.rmit.OZ.AU@CSNET-RELAY Victoria, Australia Telephone: +61 3 660 2593 Fax: +61 3 662 1060
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Jul 90 23:14:52 GMT From: cek@wsc-sun.boeing.com (Conrad Kimball) To: comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: NETBIOS and TCP/IP on a DOS PC?
Hello, We have an ethernet connecting several DOS PC's (286 & 386) with a Tandem host computer. The PC's run a program that communicates with a package on the Tandem using NETBIOS/XNS protocols. My task is to integrate a Unix-based optical disk file server (such as an Epoch-1) into this network. Of course, the Unix-based file server speaks TCP/IP rather than NETBIOS/XNS. My requirement is only this: to be able to suspend the PC's PC-to-Tandem session, perform an FTP transfer or two to/from the Unix-based file server, and to resume the PC-to-Tandem session. I hope this can be done using only the existing Ungermann-Bass PC3020 NIU card in each PC. Now, I know what TCP/IP, FTP, and NFS are all about (I come from the Unix world), but I am woefully ignorant of PC LAN software (just what *is* NETBIOS, anyway?). I am aware of PC-based products such as PC-NFS and various FTP packages, but not how they work inside. One idea is that since the existing PC-to-Tandem link is at the NETBIOS level, using XNS as a transport mechanism, perhaps TCP/IP could be a substitute transport mechanism in place of XNS. Assuming that this is possible, and that such products exist, my hope is that this would leave intact the current NETBIOS PC-to-Tandem functionality, and also open the door to using FTP over the single ethernet card. If I can't arrange for NETBIOS and FTP to coexist on a single ethernet card, perhaps I can put 2 cards in each PC and run NETBIOS and FTP side- by-side? Any help will be most appreciated. Please reply by e-mail. If there is sufficient interest I will post a summary in a week or two. -- Conrad Kimball Boeing Computer Services (206) 865-6410 Email: cek@wsc-sun.boeing.com or cek%wsc-sun@atc.boeing.com UUCP: uw-beaver!bcsaic!wsc-sun!cek DISCLAIMER: The opinions expressed are my personal views and do not necessarily reflect those of The Boeing Company.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 00:52:26 GMT From: HAROLD@UGA.CC.UGA.EDU (Harold Pritchett) To: comp.protocols.tcp-ip Subject: Re: libc for SUN 4.0.3c
On Tue, 3 Jul 90 10:04:47 -0700 Chris VandenBerg said: >Good morning all, > I'm trying to get a SPARC/1 running with the resolver and I was told > that I have to substitute a shared libc that the resolver, in >addition to adding the resolv.conf file. Does >anyone have one of these or know if one for >4.0.3c? And, does anyone know how this is set up >in SUNOS4.1? Please respond to me directly, I >don't want to waste bandwidth on so trivial a >request. Hold on there a minute. If anyone can get the resolver to work with 4.1, please post it to the list. We have not been able to get it to work either, and so far we have not gotten any help from SUN as it appears they can't get it to work either. Harold C Pritchett | BITNET: HAROLD@UGA BITNET TechRep | ARPA: harold@uga.cc.uga.edu The University of Georgia | uucp: gatech!ugacs!csun2!harold Athens, GA 30602 | fido: 1:370/60 (404) 542-3135 | Bbs: SYSOP at (404) 354-0817
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 02:36:48 GMT From: swrinde!zaphod.mps.ohio-state.edu!mips!synoptics!sblair@ucsd.edu (Steven C. Blair) To: tcp-ip@nic.ddn.mil Subject: bizarre PC/NFS <-> UNIX <-> PVCS problem encountered
We use a rather straightforward Source Code Control System here
for the PC based developers. They use PVCS from some company in
the USA, with PC/NFS from Sun onto our Sun servers.
I.E. Their setup looks like this:
--------------------Ethernet-----------------------------------------
| |
| |
|===============| |
| | |
| | Sun 4/390 |
| | 7053 Controller |
| | 2x 892Mb hitachi's |
| | SUNOS 4.0.3 |
| | Heavy NFS Traffic |
| | |
| | |
|===============| |
|===============|
| |
| |
|===============|
ComPaq 386/33 PC DOS PC/NFS 3.0.1
****>PVCS Source Code Control System<****
****>used on each local node<****
Tonight, I'm sitting here waiting for the exabyte to finish seeking out to
the 10th record on the tape so I can restore their files, which somehow
"mysteriously" are now corrupted.
Things I know are fine:
=======================
1) network has no errors or crc problems on the Sun's for many days now(+21).
2) PC users flagrantly warm reboot their PC's for no good reasons(or few sometimes).
3) dmesg, fsck, etc, show no errors on the Sun's disks. Including a slow reboot to
do a second pass of fsck -p's( first was with fsck, followed by fsck -b 32).
4) Sometimes I've observered developers checking out whole trees, and getting frustrated
in the middle which leads them to #2. This can and has probably caused me to be doing
a level -0- restore(every night onto 8mm for s/w development to save my time).
The Software manager is convinced "beyond reasonable doubt" that the Sun's, PC/NFS or
the network is to blame. I'm not quite so sure to make that assessment/assumption yet.
I thought that I'd inquire onto the net before I'm convinced that anything other might
be at fault here(including human error). Since I use RCS for my code development, and
not the PC based tool, a call to the manufacturer was futile. The vendor said "We have
no problems in our code --**Your Network Is At Fault**". Yeah right, PVCS is obviously
staffed by rocket scientists from goverenment agencies.
Does anyone else have stories with PVCS, or the combination of it with some type of
"networked" disk service(s) that have had these type of problems??
If so, please contact me via the email addr below
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 03:38:15 GMT From: ora!minya!jc@bloom-beacon.mit.edu (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP reliability
In article <30819@cup.portal.com>, thinman@cup.portal.com (Lance C Norskog) writes:
> 2) If your SL/IP tosses packets when the hardware gives framing
> or lost-byte errors, SL/IP should be very reliable. If you run SL/IP over
> modems, be sure to use MNP or some other error-corrected protocol. These
> modems are so cheap that it's pointless running on a raw one.
Be careful here. Where I work, we've been running SLIP over some modems
that do MNP, and we use raw mode. The reason is that the MNP comes with
software flow control, which means that any packet with a ^S causes the
link to die. It usually doesn't take too long for such a packet to come
along.
I spent of bunch of time on the phone with Customer Support people at
the manufacturer (Codex), trying to figure out how to correctly configure
the modems, and all I got from them was "Of course you want flow control;
you'll lose data without it." They couldn't conceive of an application
that didn't care about lost data. If there's a way to do MNP that lets
*all* 8-bit values pass, they wouldn't or couldn't tell me how to do it.
If anyone out there knows how to do it, I wouldn't mind getting some
email on the subject...
--
Typos and silly ideas Copyright (C) 1990 by:
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Jul 90 08:44 EDT From: HWeiss@DOCKMASTER.NCSC.MIL To: tcp-ip@NIC.DDN.MIL Subject: Re: TCP/IP slowdown and window field packet
Sounds just like silly window syndrome! Looks like one end of the connection has exhausted all its buffers and has closed its incoming packet window. The other end keeps probing the zero window sending a little bit more data and the zero window machine is still out of buffers. Usually what happens in this situation is that if you leave the connection alone for a period of time, the buffer congestion will go away, a bunch more packets will get delivered, the buffers will get congested again, and you go around in circles. There was a RFC written a number of years ago by Dave Clark commenting on how to avoid this kind of situation. Howard Weiss Sparta, Inc.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Jul 90 09:08:26 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu Cc: TCP/IP List <tcp-ip@nic.ddn.mil> Subject: Re: Unix tar uncompression
>I need a means of uncompressing UNIX tar files for a PC. Is there a >PC based utility available for this? Our PC/TCP product has a TAR.EXE which can assemble and disassemble Unix-compatible tar files either locally or over the network. Sun's PC_NFS also has a network TAR. If you want to "uncompress" a Unix .tar.Z file (made by piping 'tar' into 'compress'), you'll have to use 'uncompress' on the Unix system first. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Jul 90 11:56:01 -0400 From: John.Curran@VEC.IMS.ABB.COM To: tcp-ip@nic.ddn.mil Subject: Re: Parallel network problem
Hmm.. Dual-ring FDDI certainly makes clear the long standing problem of multiple interfaces. I didn't see this as an FDDI-specific problem, since numerous sites have run into the same thing with dual-ported ethernet hosts. I presumed that this would be solved (eventually) with some of the policy-based routing work going on... Is load-balancing actually a lower-layer activity? --- John Curran Asea Brown Boveri Information Management Services (203) 285-6520 jcurran@vec.ims.abb.com
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 06:32:42 GMT From: njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu (Murray Andrews) To: tcp-ip@nic.ddn.mil Subject: Can subnets be separated by another net?
I have a basic question about subnet routing that has probably been asked
many times but I can't locate an answer in any article sitting around
here so ....
Is it possible to route between subnets of a class B address when the
subnets are separated by another network?
For example, given the following topology:
+---------+
| Host C1 |
+---------+ 192.9.200.5
|
--------+-----+----- Net 192.9.200 ----------+---------
| |
+----------+ 192.9.200.1 +----------+ 192.9.200.2
| Gate GB1 | | Gate GB2 |
+----------+ 137.147.1.10 +----------+ 137.147.2.20
| |
------+------+------- --------+---+------
| |
+----------+ 137.147.1.11 +----------+ 137.147.2.21
| Host B11 | | Host B21 |
+----------+ +----------+
^ Subnet 1 of 137.147 ^ ^ Subnet 2 of 137.147 ^
|____________________________| |_______________________________|
Host C1, and gateways GB1 and GB2 all connect to the one network - in this
example a class C network with number 192.9.200 (don't worry - we are not
actually using this number).
Gateways GB1 and GB2 are gateways to 2 subnets of the the class B
network 137.147 with subnet mask 255.255.255.0. There is no connection
between the two subnets except via 192.9.200.
The question is does this work?
Can hosts on either subnet route to hosts on the other (e.g. B11 <-> B21)?
Can hosts on either subnet route to host C1?
Can C1 route correctly to both B11 and B21?
Can other networks gatewayed onto 192.9.200 successfully route to hosts
on the 137.147 subnets?
If it works is there anything special I have to do to the gateways?
If this works a *lot* of IP addresses can be saved. If this doesn't work
the only alternative appears to be to get a class B address for each
subnet (since they have up to 1000-2000 PC's each).
Any help would be much appreciated.
--------------
Murray Andrews
Telecom Australia Research Labs. (m.andrews@trl.oz.au)
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 Jul 90 14:38:44 EDT From: Bob Stewart <stewart@xyplex.com> To: ietf@venera.isi.edu, snmp@nisc.nyser.net, snmp-wg@nisc.nyser.net, trans-wg@nisc.nyser.net, tcp-ip@nic.ddn.mil Subject: Forming a new IETF Working Group for an SNMP Terminal MIB
Hi,
This is to attempt the creation of an IETF working group (WG) to define an
experimental MIB for character-oriented terminal devices. See the attached
proposed, preliminary WG charter for more information. It contains a very
aggressive schedule to be kicked off with an organizational meeting in
Vancouver.
The mailing list is new and may not be in working order until Monday, so go
easy on our helpful friends at Digital.
Bob Stewart
Proposed Chair, IETF Character MIB WG
--------
Character MIB Working Group
Chairman:
Bob Stewart/Xyplex rlstewart@eng.xyplex.com
First Meeting:
August, 1990
Mailing Lists:
General discussion: char-mib@decwrl.dec.com
To subscribe: char-mib-request@decwrl.dec.com
Description of Working Group:
The Character MIB working group is chartered to define an experimental
MIB for character stream ports that attach to such devices as terminals and
printers.
The working group must first decide what it covers and what terminology to
use. The initial thought was to handle terminals for terminal servers. This
directly generalizes to terminals on any host. From there, it is a relatively
close step to include printers, both serial and parallel. It also seems
reasonable to go beyond ASCII terminals and include others, such as 3270. All
of this results in the suggestion that the topic is character stream ports.
An important model to define is how character ports relate to network
interfaces. Some (a minority) terminal ports can easily become network
interfaces by running SLIP, and may slip between those states.
Given the basic models, the group must select a set of common objects of
interest and use to a network manager responsible for character devices
Since the goal is an experimental MIB, it may be possible to agree on a
document in 3 to 9 months. Most of the group's business can be conducted over
the Internet through email.
Goals and Milestones:
1. July 1990: mailing list discussion of charter and collection of concerns.
2. August 1990: First IETF Meeting: discussion and final approval of charter;
discussion and agreement on models and terminology. Make writing
assignments.
3. November 1990: First draft document, discussion, additional drafts,
special meeting?
4. December 1990: Second IETF Meeting: review latest draft and if OK,
give to IESG for publication as RFC.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 14:45:07 GMT From: mintaka!snorkelwacker!bu.edu!orc!inews!iwarp.intel.com!psueea!parsely!twiki!dalew@CS.YALE.EDU (Dale A. Weber) To: tcp-ip@nic.ddn.mil Subject: ka9q via archive server?
Is the _current_ version of the ka9q package (generic) available
anywhere via archive server? I don't have ftp access but might be able to
get a friend to grab it for me. Thanks in advance, E-Mail appreciated.
--
Internet: dalew@pdx.com OR dalew@twiki.pdx.com # AS/400 Specialists
UUCP: ..!{sun!nosun, tektronix}!tessi!twiki!dalew #
WORK: A-38 Specialists Consulting Group, Inc. # Voice: +1(503)226-1662
P.O. Box 42157, Portland, OR 97242-0157 USA # FAX: +1(503)774-6348
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 15:11:31 GMT From: snorkelwacker!usc!elroy.jpl.nasa.gov!zardoz.cpd.com!durin!frankh@tut.cis.ohio-state.edu (Frank Halsema) To: tcp-ip@nic.ddn.mil Subject: PC POP and PC to Unix Printing
I have a set of P.C.'s that it is time to bring into the LAN world. I would like to intergate them into our E-Mail and printer network. However the P.C.'s belong to the business office which never has any money. My E-mail is currently Quickmail for Mac, PCNFS for P.C., and Unix SMTP for Sun et. al. The B.O. has told me they can not afford PCNFS for there machines. So to help them out I am looking for a public domain solution. I have heard of POP and would like to try it but don't know where it is. I would also like a printing server for P.C's if anyone has one. I also have recently lost my Internet connection but still have uucp and I am connected to UUNET. Thanks!! -- Frank Halsema UUCP: durin!frankh SPARTA, Inc. Internet: frankh%durin@uunet.uu.net 23041 de la Carlota, Suite 400 Laguna Hills Ca, 92653 (714) 768-8161 EXT 339 (714)583-9114 FAX
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 15:25:10 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ntvaxb!billy@ucsd.edu To: tcp-ip@nic.ddn.mil Subject: Resolution to WIN/TCP TALK problems
Hi,
About a week ago I posted a message about the WIN/TCP 5.1 for VMS TALK
program having problems with numeric userids, Wollongong has supplied me
with a new version of TALK that corrects the problem. Anybody else out
there who has been experiencing this problem may want to contact Wollongong
about getting the corrected version.
================================================================================
Billy Barron Bitnet : BILLY@UNTVAX
VAX system manager THENET : NTVAX::BILLY
University of North Texas Internet : billy@vaxb.acs.unt.edu
SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 16:58:47 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!bionet!synoptics!sblair@tut.cis.ohio-state.edu (Steven C. Blair) To: tcp-ip@nic.ddn.mil Subject: Re: libc for SUN 4.0.3c
The routines for libc.so.1.3.1 for Sun 3's & Sun4's are located in
the sun directories on uunet.uu.net.
If you're going down the lloonngg road to sunos4.1, you have to
build the libc routines. Here's the information to do it from
the sun-managers email list:
The following instructions were issued a few weeks ago from Greg Earle@sun:
===========================================================================
As it appears that SunOS 4.1 is now reaching our users in reasonable
quantities, we offer the following announcement for our Internet customers:
Background:
As you may know, the normal /usr/lib/libc.so.* that ships with SunOS 4.x
contains the library routines gethostbyname(3) and gethostbyaddr(3) to do
host name and address resolution. These routines normally reference the
`hosts' NIS (nee YP) map first, and then fall back to looking in the
/etc/hosts file. By changing the NIS Makefile to invoke `makedbm' with the
`-b' option, one can arrange things so that NIS does lookups first to a DNS
(Domain Name Service) name server, via the resolver routines. This is the
Sun supported way of doing things.
But many of Sun's Internet customers want to be able to use resolver-based
lookups without having to run NIS/YP. In order to fill this void under
SunOS
4.0.x, Sun created `libc_resolv.so' versions of the shared C library with
the
gethostbyname()/gethostbyaddr() routines replaced by the equivalent
functions
from the BIND nameserver distribution's resolver library (plus supporting
functions). These were made available via anonymous FTP on the host
`uunet.UU.NET', in the `sun-fixes' directory.
Now SunOS 4.1 has arrived, but there is no equivalent `libc_resolv.so'
available via this mechanism (anonymous FTP from `uunet.UU.NET'). This
message
addresses this situation.
Fortunately, 2 things in SunOS 4.1 have come to the rescue:
(1) There is a selectable software category in the 4.1 Full Install called
`Shlib Custom' that enables one to build custom shared libraries.
This software gets installed in /usr/lib/shlib.etc, with a README file
containing instructions on how to build your own custom shared C
library.
If you wish to build a version of libc.so with the resolver routines,
make sure to select this category when installing SunOS 4.1.
(2) The version of /usr/lib/libresolv.a in 4.1 has been compiled with
`cc -pic', thus producing position-independant code.
Thus, what follows is an additional set of comments that can be *directly*
*appended* (i.e., `cat <remainder-of-this-message> >> README') to the file
`/usr/lib/shlib.etc/README' which provides instructions on how to build a
libc.so.X.NN.1 that will use the resolver for hostname/hostaddr resolution.
Sun can make no guarantees on this, but this method has been in use on
Internet hosts running SunOS 4.1FCS for 3 weeks now, doing telnet, rlogin,
ftp, etc. to hosts that are not in the hosts table (on hosts that do not
run NIS/YP), and it works without any known problems.
One final note: the method described below applies to Sun's supported SunOS
4.1
version of the resolver library (libresolv.a), which is based on BIND 4.8.
As many of you are aware, there are `post-4.8' versions of BIND floating
around
out there. We are aware of versions from UC Berkeley, University of
Toronto,
and University of Michigan, among others. Although these versions cannot be
supported, it is our opinion that if the code for these customized versions
of
the resolver library adheres to proper shared library conventions, then if
the modules in these libraries are compiled with `cc -pic', the resulting
object modules should be usable in the manner described below for the
shipped
/usr/lib/libresolv.a. A simple test will confirm whether this will work:
% mkdir tmp ; cd tmp ; ar xv /path/to/your/custom/libresolv.a
% ld -assert pure-text *.o
If there are non-PIC constructs in these objects, the assertion would tell
you
about them. For more information about position-independant code and shared
libraries, please read Chapter 1 in the "Programming Utilities and
Libraries"
manual that is included in the SunOS 4.1 documentation set. It is contained
in the binder labelled "Programmer's Overview - Utilities and Libraries" on
the spine.
Without further ado, here it is. As mentioned, cut off below the line,
save to a file, and then append that file to /usr/lib/shlib.etc/README.
Supplemental instructions for building a shared libc.so that uses the
resolver
for hostname/addr resolution:
10. Extract the contents of libc_pic.a and /usr/lib/libresolv.a into the
tmp directory:
% cd tmp
% ar x ../libc_pic.a
% ar x /usr/lib/libresolv.a
The libresolv.a (apparently) contains object modules that are position
independant, so they can be added to the libc_pic modules without fear.
11. Remove the old routine to do the hostname/addr resolution:
% rm gethostent.o
12. Remove the libresolv module that contains `strncasecmp' (which is now
in the main C library, so it is redundant):
% rm strcasecmp.o
13. As mentioned in step 5 above, edit the file `lorder-sparc' in the ..
directory. Remove the reference to `gethostent.o' and add the
references to the resolver library routines by applying this patch:
% diff -rc2 lorder-sparc.orig lorder-sparc
*** lorder-sparc.orig Thu Feb 8 05:27:46 1990
--- lorder-sparc Mon Apr 9 12:58:59 1990
***************
*** 150,154 ****
getwd.o
getnetgrent.o
! gethostent.o
ypxdr.o
ttyname.o
--- 150,161 ----
getwd.o
getnetgrent.o
! gethostnamadr.o
! sethostent.o
! res_query.o
! res_mkquery.o
! res_send.o
! res_debug.o
! res_comp.o
! res_init.o
ypxdr.o
ttyname.o
14. Continue as above, from steps 6 to 9.
------------
Steven C. Blair Network Operations Center
SynOptics Communications Inc. Mountain View, California
INTERNET: sblair@synoptics.com sblair@nevdull.synoptics.com
PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 17:21:48 GMT From: zaphod.mps.ohio-state.edu!samsung!interlan.InterLan.COM!interlan.interlan.com!solensky@tut.cis.ohio-state.edu (Frank Solensky) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP slowdown and window field of packet
In article <499@litle.litle.com> tom@litle.litle.com (tom hampton) writes:
We are having a slow-down problem between two TCP/IP programs.
Both programs do fine for a while, transferring some 50,000 bytes/sec,
until all of a sudden, they appear to hang and transfer no more than
1/100th of that. According to a crude packet monitor we have, the
problem seems to occur when the window field of the packet gets set
down (we don't know by whom) to 0.
Two things come to mind that might explain what you're seeing --
a) a "zero window" problem:
When the receiver of the data has no space left in its receive window,
the sender stops transmitting, waiting for some indication that it is safe to
resume. See if the packet trace indicates that:
1) the receiver sends out another ACK out with a non-zero window size
shortly after some space opens up in the receive window (does your packet
monitor display time intervals between the packets?).
and/or
2) if the sender sends a "zero-window" probe packet. The sender should be
allowing for the possiblity that the above ACK is lost and sends a single
byte into what it believes to be a full window, expecting that the
receiver will respond with an ACK with a non-zero receive window. This
should occur in about a single retransmit timer interval (see Host
Requirements for Communications Layers [RFC 1122], section 4.2.2.17 --
about halfway down page 92).
b) a variant of the "silly window" problem [which I'll refer to as the
"weird window syndrome"].
This will show up on your packet monitor as a significant number of "odd"
sized packets. Once the receive window has opened up a bit, the window
size announced back to the sender is some non-intuitve value (eg: not a
multiple of some power of 2 [or, in the true "silly window" case, some value
that is very small relative to the receive window size]). The sender
transmits enough to fill up the receive window again, and allows the
transmitting process to unblock until it tries to send at least this amount
of data again. This is illustrated below: "W" is the TCP window size,
"A" is the ack number, "L" is the length of the packet, "S" is the sequence
number.
sender receiver
----- ------
<-- W=0, A=5000000
<-- W=2048, A=5000000 say that a zero-window has just reopened.
--> send(1024) S=5006144 is put near end of an 8 KB send window
L=1024,S=5000000 -->
--> send(1024) S=5007168, filling send queue again.
L=1024,S=5001024 -->
<-- W=0, A=5002048
<-- W=1662 (??), A=5002048
L=1024,S=5002048 -->
L= 638,S=5003072 --> the first part of a queued 1 KB buffer is sent
<-- W=3092, A=5003710
User's send window is now opened only to 1662 bytes.
L= 386,S=5003710 --> the end of 2nd buffer is sent but not yet acked.
--> send(1024) New requests from host application allow 1024-byte and
--> send(1024) 638-byte buffer to be pulled into send queue. The tail
of the buffer is pulled down after some space opens up
again in the send window.
. . .
L=1024 -->
L=1024,S=5006144 --> first send() from above
L= 638,S=5007168 --> second send()
L= 386,S=5007806 --> the remainder of second, once sender was
unblocked.
Soon afterwards, the system falls into a self-perpetuating cycle of
filling its send window with a weird-sized packet, transmitting and getting
an ACK back that might not correspond to the boundary of yet another buffer.
The sender's performace suffers as a result of trying to keep packets in synch
with both the announced window sizes and the implied boundaries between each
send() request in the transmitting application program (since the boundaries
of each entry on the send queue closely resemble the send requests of the
initiating process).
I've seen packet traces a few months ago where this occurs with one of
the vendors you mentioned, but don't recall offhand what rev of software was
being used at the time. The lower bound of the performance degredation was
approximately where "silly window" conditions were matched -- about 35% of
the receive window. I had brought their announced window size to their
attention at the time, so maybe the problem will be fixed Real Soon Now
(though, obviously, I'm not in a position to announce what their plans are).
The way we worked around this is that when some but not all of
the data in the send queue is acknowledged, reduce the bytes-acked count
in tcp's input so that a queued buffer isn't "partially" acknowledged. This
forces the send routine to hold off pulling weird-sized packets into memory
in the first place: here, the second 638-byte packet shouldn't occur, since
the space in the send window won't be released until the rest of the data in
the first "fragmented" packet packet is acknowledged, thereby preventing the
send() request that had created the perpetuating fragment from starting.
Hope this helps..
--
-- Frank Solensky / Racal InterLan
Red Sox magic number: 80
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 18:53:43 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) To: tcp-ip@nic.ddn.mil Subject: PC PPP?
Does there exist a PC PPP (RFC1134) packet driver for use under NCSA Telnet? Whence might one acquire such a beast?
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 20:17:06 GMT From: logicon.com!tots!tep@nosc.mil (Tom Perrine) To: tcp-ip@nic.ddn.mil Subject: Re: Unix tar uncompression
In article <9007061308.AA11078@vax.ftp.com> jbvb@vax.ftp.com writes: >>I need a means of uncompressing UNIX tar files for a PC. Is there a >>PC based utility available for this? > >Our PC/TCP product has a TAR.EXE which can assemble and disassemble >Unix-compatible tar files either locally or over the network. Sun's >PC_NFS also has a network TAR. If you want to "uncompress" a Unix >.tar.Z file (made by piping 'tar' into 'compress'), you'll have to >use 'uncompress' on the Unix system first. > >James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 >FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 Implmentations of the (originally UNIX) utility "compress" are available for several micro systems. I personally know of one for the Amiga and one for the Mac. There should be one for PCs. Try comp.sys.ibm.pc... Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: nosc!hamachi!tots!tep Tactical and Training Systems Division |-or- sun!suntan!tots!tep San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 21:09:20 GMT From: mephisto!prism!gs26@handies.ucar.edu (Glenn R. Stone) To: tcp-ip@nic.ddn.mil Subject: Re: Unix tar uncompression
In <9007061308.AA11078@vax.ftp.com> jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes: >>I need a means of uncompressing UNIX tar files for a PC. Is there a >>PC based utility available for this? >Our PC/TCP product has a TAR.EXE which can assemble and disassemble >Unix-compatible tar files either locally or over the network. >.... If you want to "uncompress" a Unix >.tar.Z file (made by piping 'tar' into 'compress'), you'll have to >use 'uncompress' on the Unix system first. If you happen to have a c compiler for the pc, you can get compress.c off most any news archive site.... you can then uncompress large on the pc without having to wait for uncompressed files to download. Microsoft Quick-C can be had for peanuts..... if time is money, it's worth it. -- Glenn R. Stone gs26@prism.gatech.edu
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 22:07:43 GMT From: silver!sweeny@iuvax.cs.indiana.edu (Brent Sweeny) To: tcp-ip@nic.ddn.mil Subject: Re: Netmasks
SSJACK@ECUVM1.BITNET writes: >Which RFC(s) explains the interpretation and usage of netmasks? it's RFC950, "Internet Standard Subnetting Procedure", August 1985. -------------------- Brent Sweeny Indiana University sweeny@indiana.edu
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 22:28:23 GMT From: wuarchive!texbell!nuchat!abbadon@uunet.uu.net (David Neal) To: tcp-ip@nic.ddn.mil Subject: Novell to tcp/ip gateways
Hello, I am looking for information on linking Novell networks
running netware into a tcp/ip based network of suns.
I want the pc users to be able to telnet into the ip network.
Mail and nfs mounting of disks is less important but would be useful.
David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{texbell,bcm,rice,uunet}
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 23:37:51 GMT From: usc!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu (Mark Crispin) To: tcp-ip@nic.ddn.mil Subject: Re: MAC Email Services from Unix Systems
Consider MacMS from Stanford University. Contact person is Bill Yeager, e-mail address yeager@sumex-aim.stanford.edu. It uses the IMAP protocol (RFC-1064) to access mail with a Unix system as the central mail agent. It's a neat package! Unlike most POP-based systems it scales well for large mailboxes and on lower-speed networks (e.g. cross-country or international). Of course, it also works quite well on high-speed networks. One of the best features is a unique message searching capability. I have a compatible package for the NeXT computer: MailManager and the novice-oriented EasyMail. _____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105 _|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!" |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?" --|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin." /|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 90 03:45:11 GMT From: agate!bionet!uwm.edu!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!tmsoft!mshiels@ucbvax.Berkeley.EDU (Michael A. Shiels) To: tcp-ip@nic.ddn.mil Subject: BSD 4.x networking code.
Where is the "definitive" place to grab a copy of the BSD 4.x networking code from?
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 90 04:08:48 GMT From: fluke!gtisqr!stu@beaver.cs.washington.edu (Stu Donaldson) To: tcp-ip@nic.ddn.mil Subject: Re: errno 77 on read of socket
In article <496@litle.litle.com> tom@litle.litle.com (tom hampton) writes:
>We have been doing some high volume tests of ISC's latest release of
>TCP/IP. Things look pretty good except for an occaisional (1/1000)
>error generated on a read of a socket -- errno 77, bad data packet.
I had the same problem with the 2.0.2 distribution and ftp to a non-ISC
host. Mainly to our PC's running NCSA_Telnet, and Excelan's FTP software.
I never had it between other systems, only when ftp'ing to the 386/ix
systems. Interractive was very helpful and responded on the net once
with a suggestion, and then later via email requested some more info
on the problem. Then no response or resolution from ISC. I have just
learned to live with it. People have to watch their FTP transfers here
and rerun it if something failed.
I was hoping that it was fixed in the 2.2 distribution. (Oh, by the
way, I could not duplicate the problem between two ISC systems)
--
Stu Donaldson UUCP: {smart-host}!gtisqr!stu
Engineering Manager ARPA: gtisqr!stu@yang.cpac.washington.edu
Global Technology Bell: (206) 742-9111
Mukilteo, Washington.
--
Stu Donaldson UUCP: {smart-host}!gtisqr!stu
Engineering Manager ARPA: gtisqr!stu@yang.cpac.washington.edu
Global Technology Bell: (206) 742-9111
Mukilteo, Washington.
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Sat, 7 Jul 90 22:03:32 PDT From: earle@poseur.jpl.nasa.gov (Greg Earle - Sun JPL on-site Software Support) To: sblair@synoptics.COM, comp.protocols.tcp-ip Cc: chris@salt.ACC.COM, TCP-IP@nic.DDN.MIL Subject: Re: libc for SUN 4.0.3c
In TCP-IP/comp.protocols.tcp-ip article <21705@mvis1.com> you wrote: >If you're going down the lloonngg road to sunos4.1, you have to >build the libc routines. Here's the information to do it from >the sun-managers email list: > >The following instructions were issued a few weeks ago from Greg Earle@sun: >=========================================================================== > ... [My original posting deleted] Please note that my original posting has undergone two revisions since then. The main reason was to insert the instructions into the mainline README file from the /usr/lib/shlib.etc directory; the other reasons were to correct minor oversights and to provide extra information. If anyone reading this wants to get the latest version of the file in question (/usr/lib/shlib.etc/README), they can contact me at the following addresses. -- Greg Earle Sun Microsystems, Inc. - JPL on-site Software Support Engineer earle@poseur.JPL.NASA.GOV (Direct) earle@Sun.COM (Indirect)
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 7 Jul 90 22:46:53 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: Parallel network problem
In article <5A07060B131D020F-MTAABB*John.Curran@VEC.IMS.ABB.COM>, John.Curran@VEC.IMS.ABB.COM writes: > > ... Is load-balancing actually a lower-layer activity? That would seem to depend on whom you ask. Notice that many people in X3T9.5 think all of network management belongs in the link layer, including all necessary tools such as reliable circuits that can pass tens of thousands of bytes between management agents. (Yes, there are those in X3T.5, the ANSI committee doing FDDI, who have been publically very much not dismayed by the prospect of SMT (FDDI Station MangemenT) information exceding the FDDI frame size.) There are others who think that SMT is overly complicated, that none of the optional frames will ever be implemented by enough vendors to be usable even by those who favor link-layer network management, that the absense of authentication and authorization for remote actions dooms any hope of using remote acting SMT frames in any customer site where users are not trusted (e.g. any university or large company) and so at almost any site that really needs remote FDDI ring management, and that the last change that made SRF's mandatory was unfortunate. I think load-balancing belongs above the link layer somewhere closer to the machinery that bangs windows and such, but then I'm contrary. Vernon Schryver vjs@sgi.com
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Sat Jul 7 20:56:34 1990 From: sys320!svr%shiva@shakti.ernet.in To: uunet!nic.ddn.mil!tcp-ip@uunet.UU.NET Subject: Pl remove me
Please remove my name from the mailing list
uunet!shakti!shiva!raghavan
########################################################################
note from the postmaster@host.ernet.in
1] Users outside India are advised not to use E-mail address
of the form name%host@shakti.uu.net from the 25-MAY-1990.
Please use instead address of the form
name%host@ncst.ernet.in
2] Addresses of the form host!host!host ... !host!name will
however continue to work for sometime.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: Sat, 07 Jul 90 23:05:35 +0100 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> To: zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford) Cc: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
In article <1867@trlluna.trl.oz>, m.andrews@trl.oz.au (Murray Andrews) writ es: > I have a basic question about subnet routing that has probably been asked > many times but I can't locate an answer in any article sitting around > here so .... > > Is it possible to route between subnets of a class B address when the > subnets are separated by another network? The short answer is no. Well, that's not quite right. This depends on your routing protocol and how your routers actually forward packets. > For example, given the following topology: > > +---------+ > | Host C1 | > +---------+ 192.9.200.5 > | > --------+-----+----- Net 192.9.200 ----------+--------- > | | > +----------+ 192.9.200.1 +----------+ 192.9.200.2 > | Gate GB1 | | Gate GB2 | > +----------+ 137.147.1.10 +----------+ 137.147.2.20 > | | > ------+------+------- --------+---+------ > | | > +----------+ 137.147.1.11 +----------+ 137.147.2. 21 > | Host B11 | | Host B21 | > +----------+ +----------+ > > > ^ Subnet 1 of 137.147 ^ ^ Subnet 2 of 137.147 ^ > |____________________________| |______________________________ _| > > Host C1, and gateways GB1 and GB2 all connect to the one network - in thi s > example a class C network with number 192.9.200 (don't worry - we are not > actually using this number). > > Gateways GB1 and GB2 are gateways to 2 subnets of the the class B > network 137.147 with subnet mask 255.255.255.0. There is no connection > between the two subnets except via 192.9.200. > > The question is does this work? No. The reasons is that the Gateways will only advertise a route to 137.147 .0.0 (not to a particular subnet of that network) over the 192.9.200.0 subnet th ey are connected too. Again, this depends on the routing protocol and routers. It is certainly easy enough to configure the OSPF protocol to make this work. In fact, the NASA Science Internet network (built of Proteon p4200 routers) does exactly this. We have 2 NSI routers seperated by a class C network, and both routers can deal with parts of 128.161 on both "sides" of the class C net. This is a consequence of variable length subnet support, and how OSPF areas are configured. . . . The only way it *might* work is to give the interfaces that connect the two gateways a second IP address (in this case from another subnet of 137.147) and use a bit of static routing in the hosts. Two subnets (from different n et numbers would then share the same physical network). cisco routers support secondary interface addresses but will never generate an IP packet with the secondary IP address - which is why you might have to us e some static routing. I've done something like this at Macquarie University to support CSIRO's links into that campus, but at that site it's a case of two networks on the same cable, not a partititioned subnets (which is illegal according to the RFC), This is a real kludge, and any hosts on the net in the middle may cause problems because of improper handling of broadcast packets. As I said, with the right routing protocol, this situation can work. We actually discovered this accidentally one day, when we configured things in such a way that this behavior resulted, and then decided that it wasn't supposed to work! After thinking things through however, it was clear this was a topology the system could support. Now, I wouldn't go off recommending this approach to people, but it certainly can be useful at times, especially during transitions, and for other reasons too. So, Murray, the answer to your question is yes, given you have OSPF routers involved. Otherwise, I think the kludges you need would be pretty ugly and not work well. OSPF is brought to you by the IETF, and is documented in RFC 1131. Expect to see a multivendor demo at InterOp this fall. Ask for it by name, accept no substitutes! Thanks, Milo
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 90 08:32:35 GMT From: zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford) To: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
In article <1867@trlluna.trl.oz>, m.andrews@trl.oz.au (Murray Andrews) writes: > I have a basic question about subnet routing that has probably been asked > many times but I can't locate an answer in any article sitting around > here so .... > > Is it possible to route between subnets of a class B address when the > subnets are separated by another network? The short answer is no. > For example, given the following topology: > > +---------+ > | Host C1 | > +---------+ 192.9.200.5 > | > --------+-----+----- Net 192.9.200 ----------+--------- > | | > +----------+ 192.9.200.1 +----------+ 192.9.200.2 > | Gate GB1 | | Gate GB2 | > +----------+ 137.147.1.10 +----------+ 137.147.2.20 > | | > ------+------+------- --------+---+------ > | | > +----------+ 137.147.1.11 +----------+ 137.147.2.21 > | Host B11 | | Host B21 | > +----------+ +----------+ > > > ^ Subnet 1 of 137.147 ^ ^ Subnet 2 of 137.147 ^ > |____________________________| |_______________________________| > > Host C1, and gateways GB1 and GB2 all connect to the one network - in this > example a class C network with number 192.9.200 (don't worry - we are not > actually using this number). > > Gateways GB1 and GB2 are gateways to 2 subnets of the the class B > network 137.147 with subnet mask 255.255.255.0. There is no connection > between the two subnets except via 192.9.200. > > The question is does this work? No. The reasons is that the Gateways will only advertise a route to 137.147.0.0 (not to a particular subnet of that network) over the 192.9.200.0 subnet they are connected too. > Can hosts on either subnet route to hosts on the other (e.g. B11 <-> B21)? > > Can hosts on either subnet route to host C1? > > Can C1 route correctly to both B11 and B21? > > Can other networks gatewayed onto 192.9.200 successfully route to hosts > on the 137.147 subnets? > > If it works is there anything special I have to do to the gateways? The only way it *might* work is to give the interfaces that connect the two gateways a second IP address (in this case from another subnet of 137.147) and use a bit of static routing in the hosts. Two subnets (from different net numbers would then share the same physical network). cisco routers support secondary interface addresses but will never generate an IP packet with the secondary IP address - which is why you might have to use some static routing. I've done something like this at Macquarie University to support CSIRO's links into that campus, but at that site it's a case of two networks on the same cable, not a partititioned subnets (which is illegal according to the RFC), Peter Elford, AARNet
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 90 13:28:14 GMT From: ora!minya!jc@uunet.uu.net (John Chambers) To: tcp-ip@nic.ddn.mil Subject: Re: Limited routing between IP networks.
From mail Wed Jul 4 01:45 EDT 1990
>From hp-ses.sde.hp.com!wunder Wed Jul 4 01:45:06 1990 remote from mit-eddie
Received: by minya.uucp (smail2.5)
id AA01293; 4 Jul 90 01:45:06 EDT (Wed)
Received: from HPLABS.HPL.HP.COM by EDDIE.MIT.EDU with SMTP (5.61/25-eef)
id AA25341; Tue, 3 Jul 90 11:59:31 EST
Received: from hp-ses.sde.hp.com by hplabs.hpl.hp.com with SMTP
(15.11.1.3/15.5+IOS 3.14) id AA16068; Tue, 3 Jul 90 09:59:40 pdt
Received: by hp-ses.sde.hp.com
(15.11/15.5+IOS 3.21) id AA02795; Tue, 3 Jul 90 09:59:36 pdt
Date: Tue, 3 Jul 90 09:59:36 pdt
From: Walter Underwood <mit-eddie!hp-ses.sde.hp.com!wunder>
Message-Id: <9007031659.AA02795@hp-ses.sde.hp.com>
To: minya!jc@eddie.mit.edu
Subject: Re: Limited routing between IP networks.
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: article <416@minya.UUCP> of Tue, 3 Jul 1990 03:28:19 GMT
| You may get into silliness with making mail work, since the
| destination may not be reachable. I'm sure that HP would be glad to
| consult on this. Maybe not for free, but we make it work for a 20,000
| node network ...
Actually, we have some Cisco gateways at work. As near as I can tell,
they only work with LANs, and aren't set up to work across phone lines.
The configurations we need have set (subnets) that are geographically
quite remote from each other, and we are using (transient) SLIP links
across the phone system to establish connectivity. If Cisco can do
this, I'd be interested in finding out how (or where to look in the
manuals or who to call to order any add-on stuff to make it work).
--
Typos and silly ideas Copyright (C) 1990 by:
Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 90 16:48:40 GMT From: sun-barr!newstop!texsun!texbell!nominil!linimon@apple.com (Mark Linimon) To: tcp-ip@nic.ddn.mil Subject: Re: Signal-to-noise degradation on comp.protocols.tcp-ip
A discussion recently arose in comp.protocols.tcp-ip about its decreased
technical content. I have some specific proposals to address this issue from
the Usenet side.
1. Create a periodic posting to refresh/establish Usenet community memory that:
- states the purpose of comp.protocols.tcp-ip.
- states the fact that the newsgroup/mailing list gateway exists.
- suggests topics relevant to comp.protocols.tcp-ip.
- points to appropriate sources for information about SLIP, Novell, and
other networking technologies.
- states how to get the RFCs.
- points to the status, conditions, and location of sources from Berkeley,
Phil Karn, Clarkson, and so on.
- briefly points to the Usenet guidelines for posting and newgroup creation.
[Yes, I'll volunteer to create this posting; I'll need assistance in
gathering some of the information. Email me directly.]
2. Create a Usenet-side newsgroup comp.protocols.slip. I intend to issue
the call for discussion in news.groups/news.announce.newgroups this week.
3. Call for discussion on splitting out other topics that do not _specifically_
have to do with protocol implementation. Two come to mind:
- network set-up, interconection, and administration (comp.admin.tcp-ip?
comp.protocols.tcp-ip.admin?)
- meta-issues about the Internet proper (comp.internet?)
Summary: even though I am not a technical contributor to this list/group, I do
find it educational, and would rather not see it continue to become less
useable to the community of networking implementors.
Note that followups are directed to the Usenet group news.groups. Interested
Internet-side readers should email to me and I'll summarize.
--
Mark Linimon / Lonesome Dove Computing Services / Southlake, Texas
{mic, texbell}!nominil!linimon || "I said, welcome,
linimon@nominil.lonestar.org || to the real world, kid"
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: Mon, 9 Jul 90 02:39:49 PDT From: Tony Staw - REO2-G/G9 830-3908 09-Jul-1990 1037 <staw@marvin.enet.dec.com> To: njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu, tcp-ip@nic.ddn.mil Subject: RE:Can subnets be separated by another net?
This topology would also be supported by dual IS-IS routing, which like OSPF supports variable-length subnet masks. Tony
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Sun, 08 Jul 90 18:16:23 +0100 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> To: zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford) Cc: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
Peter, I expect about 5-6 implementations there, though Proteon's is the only real vendor shipping today. I certainly don't want to speak for the vendors on this; I'm sure they'll do it themselves. This is just my best guess of course, based on meetings at IETF and such. Note that it's a little tricky to implement variable length mask support unless the IP forwarder is designed to support it. Most of the vendor's I know who are supporting OSPF have or are rewriting their forwarder code, and this is a major change in the way their routers work, so it takes more than just OSPF itself if your forwarder doesn't support this functionality already. Thanks, Milo
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 8 Jul 90 22:46:15 GMT From: zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu (Peter Elford) To: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
In article <9007080605.AA00749@cincsac.arc.nasa.gov>, medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
> > Is it possible to route between subnets of a class B address when the
> > subnets are separated by another network?
>
> The short answer is no.
>
> Well, that's not quite right. This depends on your routing protocol and how your
> routers actually forward packets.
.. diagram deleted ...
> No. The reasons is that the Gateways will only advertise a route to 137.147
> .0.0
> (not to a particular subnet of that network) over the 192.9.200.0 subnet th
> ey
> are connected too.
>
> Again, this depends on the routing protocol and routers. It is certainly easy
> enough to configure the OSPF protocol to make this work. In fact, the NASA
> Science Internet network (built of Proteon p4200 routers) does exactly this.
> We have 2 NSI routers seperated by a class C network, and both routers can
> deal with parts of 128.161 on both "sides" of the class C net. This is
> a consequence of variable length subnet support, and how OSPF areas
> are configured.
We are still just exploding out of the stone age Internet wise down here, so
it was pretty safe to assume RIP and normal (ie. fixed length) subnet masks.
> The only way it *might* work is to give the interfaces that connect the two
> gateways a second IP address (in this case from another subnet of 137.147)
> and use a bit of static routing in the hosts. Two subnets (from different n
> et
> numbers would then share the same physical network).
>
> cisco routers support secondary interface addresses but will never generate
> an
> IP packet with the secondary IP address - which is why you might have to us
> e
> some static routing. I've done something like this at Macquarie University
> to
> support CSIRO's links into that campus, but at that site it's a case of two
> networks on the same cable, not a partititioned subnets (which is illegal
> according to the RFC),
>
> This is a real kludge, and any hosts on the net in the middle may cause problems
> because of improper handling of broadcast packets. As I said, with the right
> routing protocol, this situation can work.
I wasn't recommending the kludge; just using it as an example of what the
problems associated with partitioning subnets (of the RFC950 flavour).
> Now, I wouldn't go off recommending this approach to people, but it certainly can
> be useful at times, especially during transitions, and for other reasons too.
>
> So, Murray, the answer to your question is yes, given you have OSPF routers
> involved. Otherwise, I think the kludges you need would be pretty ugly and
> not work well.
I think Milo is saying that unless you are keen enough to dive into OSPF
then the answer is no !
> OSPF is brought to you by the IETF, and is documented in RFC 1131. Expect to
> see a multivendor demo at InterOp this fall. Ask for it by name, accept no
> substitutes!
How many vendors do you expect to see Milo ? (genuine interest, no sarcasm)
Regards,
Peter Elford,
AARNet
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Mon, 9 Jul 90 12:40:38 PDT From: adelman@TGV.COM (Kenneth Adelman) To: lumsdon@dtoa1.dt.navy.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: Wollongong TCP/IP ping question, VMS
> Under VMS (version 5.2), what privileges does PING require?
> Tech Support at Wollongong told me it was cmkrnl, but, when ping image
> is installed with that privilege, this message appears when trying to
> use ping (from regular user account; works fine from system account):
> $ ping _node_
> ping: socket: Permission denied
>
> I've played with it, and, will ping work when installed with only the
> sysprv privilege?
Both WINS/TCP and MultiNet use 'SYSPRV' as the equivalent of the
UNIX 'root' user, so SYSPRV is required to create the raw socket
required by PING. I'd be careful about installing arbitrary programs
with SYSPRV, as you may breach system-security by allowing someone to
use that program to overwrite system files.
MultiNet's PING is installed with SYSPRV by default, and in order
not to cause a security breach, PING disables it on startup and
enables it only to create the socket.
Kenneth Adelman
TGV, Inc.
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Mon, 9 Jul 90 09:56:30 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: ingr!b11!griffin@uunet.uu.net (Tommy Griffin) Cc: tcp-ip@nic.ddn.mil Subject: Re: telnet and pc's
Two points: 1. The "retransmit increases steadily toward a limit, even when data is eventually getting acknowleged" is a TCP bug that at least a couple of "Van Jacobsen" TCPs can be provoked into demonstrating. With the two I'm familiar with (SunOS 4.0.1, Ultrix 3.0) it normally has to do with which ahead-of-sequence segment the receiver drops first if buffers are tight (earliest sequence vs. latest). In my opinion, it would be worth the effort to fix it in the workstation. 2. Read the TCP section of RFC 1122 - it has somewhat to say about the use of Nagle's algorithm to collect data into larger segments. The gateway vendors (and the regional networks) won't be awfully happy about bursts of back-to-back 64-byte packets. Even if the traffic is time sensitive, like X, a larger packet every 10ms would suffice. I can't really blame PC-NFS in this case - my TCP probably wouldn't do much better under that kind of abuse. A receiving TCP is rather limited in what it can do to prevent overrun, or sender retransmit escalation. To answer your original question, I hope the Sun Unix TCP isn't looking at the 3Com manufacturer code in the destination Ethernet address and slowing down (this would fail through routers, or if they were talking to software which sets its own Ethernet address). I think what you're seeing is mostly the effect of code which attempts to send as much data as possible in each segment... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Mon, 09 Jul 90 17:05:41 EDT From: bjp@mbunix.mitre.org To: tcp-ip@nic.ddn.mil Cc: bjp@mbunix.mitre.org Subject: Source for TCP/IP
We are considering porting TCP/IP to a CMC FDDI card that will sit
in a single board VME box so that we can put a customized image storage
and retrieval system on an FDDI network. Since many implementations of
TCP/IP already exist, I am interested in obtaining source for these
protocols, where the source represents an implementation known to be very
good for large volume throughput. I am under the impression that most
implementations are in C. Please correct me if I am wrong.
I'd also like some input from implementors as to what bottle necks
have been found that have down graded performance in various TCP/IP
implementations. Since I read the tcp-ip mailing list from a bulletin
board where archiving is under the controll of b-board administrators,
I would like all responses sent to:
bjp@mbunix.mitre.org
Thanks for your time. Anything you send will be a big help.
Sincerely
bj Pease
MITRE Corp.
Bedford, MA
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 13:23:34 GMT From: dino!ux1.cso.uiuc.edu!herodotus.cs.uiuc.edu!morrison@uunet.uu.net (Vance Morrison) To: tcp-ip@nic.ddn.mil Subject: Beta version of PCroute with packet driver support available
Hello, There is a beta version of PCroute with packet driver support available on accvuax.nwu.edu (129.105.49.1) in pub/pcroute/exp. In this directory you will find two files 'packpack.exe' and 'packslip.exe'. These files are compiled versions of pcroute the first configured to be used with two packet drivers, and the second configured for one packet driver and one slip line. In addition the pub/pcroute/exp directory is the standard PCroute documentation modfied to include packet driver details, as well as a file 'packet.txt' which is a sample installtion of the packpack.exe code. So if you have wanted to use PCroute, but didn't have WD8003E cards here is your chance to try it out. If you do try out the code, please send me a note saying so (so I can know if anyone really cares), and also send any comments/bugs of interest. The code will not be nearly as speedy as the native driver, but I am not sure how much (I estimate about 1/3 the speed). Any comments/measurments on the speed would also be appreciated. At present the source for the additional code is not available because it is easer for me to wait until I have had some feedback and then simply integrate it into the standard release. Vance
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: Mon, 09 Jul 90 11:56:12 +0100 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> To: Tony Staw - REO2-G/G9 830-3908 09-Jul-1990 1037 <staw@marvin.enet.dec.com> Cc: njin!munnari.oz.au!bruce!trlluna!ilium!andrews@rutgers.edu, tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
Tony, you are of course right. All the modern IGP designers learned from the mistakes of the past and do/will support variable length masks. I was just differentiating OSPF's support for this sample topology in comparison to "old style" IGP's like RIP, IGRP, etc, which do not carry around mask information with the route information. But to be fair to them, the routers IP forwarders didn't support variable length masks either, with the possible exception of fuzzballs, which were trailblazers for many of the concepts now common in the Internet. Thanks, Milo PS The "old style" protocols are still adequate for many people's topologies, and are still widely used. It's just that these days, people want a lot more from their IGP's, like variable length mask support, authentication, multicast updates, rapid convergence, route tagging, low overhead, etc... OSPF was built with all these goals in mind, whereas the others didn't have nearly as full of a plate requirements wise when they were built... Of course, that's why the IETF formed a working group to build such a protocol. And Dual IS-IS should also be able to do those things as well...
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 15:23:31 GMT From: cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!geac!maccs!beame@tut.cis.ohio-state.edu (Carl Beame) To: tcp-ip@nic.ddn.mil Subject: Re: telnet and pc's
In article <8285@b11.ingr.com> griffin@b11.ingr.com (Tommy Griffin) writes: > >We're experiencing some difficulty communicating between our >workstations and PCs using Telnet over TCP/IP. The PCs are running >Sun's PC/NFS product through the 3-Com Ethernet card. > >The problem occurs when a Telnet session has been established from a >PC to a workstation, and the workstation is generating a continuous >stream of output to be displayed by the PC. The PC begins to display >the output, but instead of displaying a continuous stream of data, new >data is displayed at intermittent intervals with 1-20 second delays >between bursts of output. The delay usually ramps up to 20 seconds >and stays there. > >The problem seems to be caused by the PC's inability to receive and/or >process Ethernet/TCP frames which arrive within 5 milliseconds of each >other. Our workstation sends output to the PC in TCP frames carrying >64 bytes of data. The 512 byte TCP window offered by the PC's TCP >allows us to send up to 8 frames inside one window, so these frames >can arrive with very little inter-frame spacing. When the PC drops a >frame, we have to retransmit the data that was lost. The Jacobson >algorithm in our implementation of TCP causes us to *DOUBLE* our >retransmission timer each time we have to retransmit data. We >eventually increase the retransmission timer to its maximum value, 20 >seconds, which explains why we're seeing bursts of data every 20 >seconds. > >Any light that can be shed upon this matter would be greatly >appreciated. > > >Tom Griffin >griffin@ingr.com At McMaster University they are running CS/100s to the IBM 7171 and IVECS cards in the Vaxen. They had the same problem (originaly the IVECS cards had a 16 second retry time). What I did was allow the Telnet window size to be changed. The CS/100s and IVECs cards buffer up to 82 bytes per packet. By setting the window size to 82, everything works and you can get reasonable through-put with telnet. Carl Beame Beame & Whiteside Software Ltd. Beame@McMaster.CA
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 17:03:26 GMT From: nems!dtoa1!lumsdon@mimsy.umd.edu (Lumsdon) To: tcp-ip@nic.ddn.mil Subject: Wollongong TCP/IP ping question, VMS
Under VMS (version 5.2), what privileges does PING require? Tech Support at Wollongong told me it was cmkrnl, but, when ping image is installed with that privilege, this message appears when trying to use ping (from regular user account; works fine from system account): $ ping _node_ ping: socket: Permission denied I've played with it, and, will ping work when installed with only the sysprv privilege? Thanks for any help. -------------------------- Esther Lumsdon -------------------------------- lumsdon@dtoa1.dt.navy.mil lumsdon@dtrc.dt.navy.mil lumsdon%dtrc.navy.mil@uunet.uu.net "Wherever you go, there you are" -Buckaroo Bonzai
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 18:04:11 GMT From: wang!ice@uunet.uu.net (Fredrik Nyman) To: tcp-ip@nic.ddn.mil Subject: Looking for PC TCP/IP ...
I'm looking for PC TCP/IP development packages to run under DOS (Windows). Ideally it should support BSD sockets, SysV streams and its library functions (listen(), accept(), socket() ...) should run fine under Windows. What products are out there? I know of SUN's PC-NFS and FTP Software's PC/FTP exist, but do they match my requirements? I'd be most grateful for any information. -- Disclaimer: Wang doesn't care about my opinions, so why should you? Internet: <ice@wang.COM> <ice@emil.csd.uu.se> BITNET: <ice@DRYCAS> <ice@SEARN> <ice@SEQZ51> (in order of preference) USnail: Wang Labs, Inc., M/S 019-490, One Industrial Ave., Lowell, MA 01851
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 21:06:37 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: Wollongong TCP/IP ping question, VMS
In article <2509@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther Lumsdon) writes: >Under VMS (version 5.2), what privileges does PING require? It requires CMKRNL and SYSPRV on all version of VMS and all version of WIN/TCP for VMS through at least 5.1. >Tech Support at Wollongong told me it was cmkrnl, but, when ping image >is installed with that privilege, this message appears when trying to >use ping (from regular user account; works fine from system account): > $ ping _node_ > ping: socket: Permission denied > >I've played with it, and, will ping work when installed with only the >sysprv privilege? The problem is that Technical support gave you incomplete information. WIN/TCP PING requires that you have both CMKRNL and SYSPRV in order for certain calls that it makes to succeed. If you don't have both of these privs enabled, then you will get the error message that you see above. The good news is that as of release 5.1 you are supposed to be able to install ping with privs. Everything should work OK if you install the ping image with CMKRNL and SYSPRV. -- Warner Losh imp@Solbourne.COM Boycott Lotus. #include <std/disclaimer>
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 9 Jul 90 23:49:08 GMT From: mentor.cc.purdue.edu!nelson@purdue.edu (J. Nelson Howell) To: tcp-ip@nic.ddn.mil Subject: Re: Novell to tcp/ip gateways
In article <25539@nuchat.UUCP> abbadon@nuchat.UUCP (David Neal) writes:
>
>Hello, I am looking for information on linking Novell networks
>running netware into a tcp/ip based network of suns.
>
>I want the pc users to be able to telnet into the ip network.
I also am looking for similar information.
Any pointers would be appreciated. Thanks.
J. Nelson Howell | System Programmer
nelson@midas.mgmt.purdue.edu Internet | Krannert Graduate School of Management
NELSON@PURCCVM BITNET | Purdue University
| West Lafayette, IN
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 00:36:28 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
In all our pride about how OSPF will allow you to build a network that contains discontiguous subnets, lets not forget to explain to the new people that this is not recommended, precisely because the earlier and most widely available routing protocols do not deal well with such a case. Disjoint subnets can only be expected to work if all interconnections between the disjoint subnets are under the same administration and is running a routing protocol that passes the mask. The normal way to implement the topology that was asked about, would be to have the connecting network (C1 in the example) be anotehr class-C sized subnet of the same class B network as the disjoint segments. The most common case where clients ask about disjoint subnets, is where an enterprise is geographically disjoint (say offices in Los Angeles, Denver and Boston) and wants to attach each office separately to the Internet, while assigning all host addresses out of the same class B network number. This of course is utterly undesirable (would OSPF allow it to be set up at all ?) and contravenes all the intentions for which subnets were invented. Thus, for "commercial use" the simple, practical and almost true answer is that disjoint subnets are not allowed. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Jul 90 10:10 EST From: Bob Stine <0004219666@mcimail.com> To: Scott Ginsburg <usc!samsung!ginsburg@ucsd.edu> Cc: "tcp-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil> Subject: RE: IP routing and gateways
> My questions are: > 1.) Is it the case that I need to provide a default gateway > address for IP packets that aren't destined for someone > within my subnet? Only if you want them to get there :-). Seriously, you'll need some sort of route table entry or entries for the networks that you reach by gateway. > 2.) Do I need to implement an IGP like RIP ... > ... (even though this device only has one network > interface) ... I wouldn't. > ... or is it OK to go to the same > gateway (default) every time? Not really, but see below. > 3.) If the answer to 2 is that it's not smart to go to the > same gateway every time, then is something like RIP (which > should be available on most Unix networks because of > routed) the way to go, or does the ICMP redirect take care > of it. Bingo! If you have a decent IP implementation, then it will populate its local routing table when it gets ICMP redirects. BSD 4.3 does this. Probably alot of other IPs do, too. - Bob Stine
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Jul 90 10:22:26 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) To: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
> .............. > The most common case where clients ask about disjoint subnets, is where > an enterprise is geographically disjoint (say offices in Los Angeles, > Denver and Boston) and wants to attach each office separately to the > Internet, while assigning all host addresses out of the same class B > network number. This of course is utterly undesirable (would OSPF allow > it to be set up at all ?) and contravenes all the intentions for which > subnets were invented. > > Thus, for "commercial use" the simple, practical and almost true answer > is that disjoint subnets are not allowed. > -- > / Lars Poulsen, SMTS Software Engineer > CMC Rockwell lars@CMC.COM > Hmmm. Why is it <of course> utterly undesirable that one organization in locations separated by the Internet not split up a Class B address? The only reason I can think of is that Internet routers are incapable of looking at subnet parts of the address--in other words, our Internet routers (or routing protocols) are inadequate. The thing just simply wouldn't work. However, I don't necessarily see something inherently bad about this. I mean, given today's address structure (net.subnet.host), what are the alternatives? First, the organization could have multiple class C addresses? However, this puts a load equal to subnetted class B addresses on the Internet. Each router must maintain one routing table entry for each location. But, it is highly unlikely that a single class C address will suffice for a location, so the organization probably needs a different class B address for every location. We still haven't decreased the load on the internet (one routing table entry for each location), but we have managed to make bad use of our address space. In other words, by not having protocols that allow the Internet routers to look into the subnet, we have NOT decreased the amount of routing overhead, but we HAVE used our limited address space poorly. Does BGP have masks? If so, it could look at the subnet part. This would at least allow use to use addresses a little more efficiently. However, a more general, multi-level hierarchical address scheme coupled with an efficient address assignment scheme is what's needed. Hear my ideas on this at the UCB IETF, or if you can't be there, ask me and I'll send you a paper on the topic. PT
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Jul 1990 07:07:31 MEST From: Jochen Kornitzky <korni@sietec1.sietec.de> To: tcp-ip@nic.ddn.mil Subject: Telnet in MS-Windows ?
Does someone on the net knows a telnet (client) that works under Microsoft-Windows ? (In a real window, with terminal emulation, not dumb mode switching !) Best thing would be if the product works with PC/NFS (Sun) but also others would be interesting. Thanks, korni -- +--Jochen Kornitzky-------+---------------------------------------+-----------+ | | | . | | SMAIL: | EMAIL: | . | | | | . | | Sietec GmbH & Co. OHG | korni@sietec1.sietec.de | . | | Nonnendammallee 101 | ...!uunet!unido!sietec1!korni | | | D-1000 Berlin 13 | Postmaster for *.sietec.de | . . | | | | | +-------------------------+---------------------------------------+-----------+
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Jul 90 17:00:49 CDT From: darrel beach <beach@ddnuvax.af.mil> To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil Subject: GOSIP from the grape vine
Now that implementation of GOSIP are appearing, or at are claimed, on certain vendor's shelves, I have a question or two maybe someone can answer. We've finally reached a point in tcp/ip where most (not all by any means) can support DNS and host tables are fading away. Now comes GOSIP (with its 3 versions thus far). It looks like at least for the near future, the mapping between OR (originator/recipient) addresses to some particular NSAP address is table driven, at least until directory services is fully implemented by all. Is this true, or have I missed something?? There also seems to be the beginning of a plethora of so called gateways to get from smtp based mail systems to X.400 based systems, and might add full suite GOSIP x.400. Now just how the heck you map some particular X.400 address to some particular user@host internet address seems a little dicey. From what I've seen, it looks like another big table to do the mapping. Has anybody implemented one of these beasts and knows the definitive answer?? ciao, Darrel Beach
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 12:46:30 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ark1!nems!dtoa1!lumsdon@ucsd.edu (Lumsdon) To: tcp-ip@nic.ddn.mil Subject: Re: Wollongong TCP/IP ping question, VMS
In article <1990Jul9.210637.4761@Solbourne.COM> imp@dancer.Solbourne.COM (Warner Losh) writes: >In article <2509@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther >Lumsdon) writes: >>Under VMS (version 5.2), what privileges does PING require? > >It requires CMKRNL and SYSPRV on all version of VMS and all version of >WIN/TCP for VMS through at least 5.1. > >The problem is that Technical support gave you incomplete information. >WIN/TCP PING requires that you have both CMKRNL and SYSPRV in order >for certain calls that it makes to succeed. If you don't have both of Actually, in playing with it before I posted, it worked from my account (not the system account) when I didn't install it, and gave myself only the SYSPRV privilege above normal privs (tmpmbx, etc.). The problem is that Wollongong Tech Support gave me just plain incorrect information. Is it safe to install PING with SYSPRV privilege? Will it compromise my system security? Does Wollongong's PING do anything other than sending ping at target? Is Wollongong's PING code written such that it uses SYSPRV carefully? I'll call Wollongong and ask these questions, and post answers to the net in a week or so. -------------------------- Esther Lumsdon -------------------------------- lumsdon@dtoa1.dt.navy.mil lumsdon@dtrc.dt.navy.mil lumsdon%dtrc.navy.mil@uunet.uu.net "Wherever you go, there you are" -Buckaroo Bonzai
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: Tue, 10 Jul 90 11:15:10 +0100 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov> To: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) Cc: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
Lars, you are quite correct that use of non-contiguous subnets should be with good reason. In many cases, you can do something architecturally pure, and avoid kludging, which is always a good idea. But, there are valid cases to do non-contiguous subnets as well. As usual, the reason you need really smart people is to tell the difference between the cases. I don't think that the issue of older protocols not supporting such a configuration is an issue. Time moves on, and progress gets made. In my environment, new capabilities are eagerly received, and put to good use right away, because we tend to operate close to the edge of the envelope anyway. And of course, at that point, the market tends to demand these new capabilities, and people implement them to be competitive. Your case about the business with the disjoint offices all wanting their own Internet interconnects while still using a single class B won't work, but not because of OSPF, but because that organization's connections to the various regional or brand X networks and those net`s connections to each other typically use EGP, which does not allow the passing of subnet data. If everyone was glued together by one supernetwork, all running an IGP like OSPF, then yes, it could work. But that's not likely to be the way people's connections would work in any case. Thanks, Milo
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 12:59:27 GMT From: mintaka!snorkelwacker!bu.edu!orc!inews!iwarp.intel.com!psueea!parsely!twiki!dalew@CS.YALE.EDU (Dale A. Weber) To: tcp-ip@nic.ddn.mil Subject: Re: Unix tar uncompression
jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes:
> >I need a means of uncompressing UNIX tar files for a PC. Is there a
> >PC based utility available for this?
>
> PC_NFS also has a network TAR. If you want to "uncompress" a Unix
> .tar.Z file (made by piping 'tar' into 'compress'), you'll have to
> use 'uncompress' on the Unix system first.
There is a very good 16 bit [de]compress utility for MS/PC-DOS. I use it
all the time when dealing with compressed files from *NIX. It came without
documentation so I tested it carefully before installing it on my BBS, but
it works great and now my system can handle 12 bit _and_ 16 bit compressed
files, all on my MS-DOS machine. I have no idea where this program is from
or who the author is though.
--
Internet: dalew@pdx.com OR dalew@twiki.pdx.com # The AS/400 Specialists
UUCP: ..!{sun!nosun, tektronix}!tessi!twiki!dalew #
WORK: A-38 Specialists Consulting Group, Inc. # Voice: +1(503)226-1662
P.O. Box 42157, Portland, OR 97242-0157 USA # FAX: +1(503)774-6348
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 13:58:56 GMT From: usc!samsung!ginsburg@ucsd.edu (Scott Ginsburg) To: tcp-ip@nic.ddn.mil Subject: IP routing and gateways
I'm trying to get a handle on IP routing and gateway visibility for a device (not necessarily running Unix) on an Ethernet. This device is part of a class C network, has a single Ethernet interface, and there will probably be more than one IP gateway to either the outside world (T1, etc) or another class C network within the same installation on a different Ethernet backbone. My questions are: 1.) Is it the case that I need to provide a default gateway address for IP packets that aren't destined for someone within my subnet? 2.) Do I need to implement an IGP like RIP and maintain routing tables (even though this device only has one network interface) so that I choose the correct gateway to route my outgoing packets to, or is it OK to go to the same gateway (default) every time? 3.) If the answer to 2 is that it's not smart to go to the same gateway every time, then is something like RIP (which should be available on most Unix networks because of routed) the way to go, or does the ICMP redirect take care of letting me know that one internal gateway is better than another for an outgoing packet? Thanks in advance, Scott -- ------------------------------------------------------------------------- Scott Ginsburg WA2CJT Voice: 508-685-7200 FAX: 508-685-4940 Samsung Software America Internet: ginsburg@samsung.com Andover, MA
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 14:42:09 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!tut!jh@ucsd.edu (Juha Heinanen) To: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
In article <1990Jul10.003628.5859@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: Thus, for "commercial use" the simple, practical and almost true answer is that disjoint subnets are not allowed. Depends what you mean by "commercial use". If an organization that previously has had its own IP backbone decides to become a user of a commercial IP backbone then the situation is excatly such that would call for connecting geographically separate subnets over another network. If this can't be done then the commercial backbone operator is not likely to get the customer. In Finland, for example, the commercial DataNet IP backbone will certainly switch from IGRP to OSPF for this very reason alone if it really can solve the acute problem. In the ISO world of NSAP addresses each organization can have several so called routing domains which could be assigned one for each separate network component. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 15:10:00 GMT From: 0004219666@MCIMAIL.COM (Bob Stine) To: comp.protocols.tcp-ip Subject: RE: IP routing and gateways
> My questions are: > 1.) Is it the case that I need to provide a default gateway > address for IP packets that aren't destined for someone > within my subnet? Only if you want them to get there :-). Seriously, you'll need some sort of route table entry or entries for the networks that you reach by gateway. > 2.) Do I need to implement an IGP like RIP ... > ... (even though this device only has one network > interface) ... I wouldn't. > ... or is it OK to go to the same > gateway (default) every time? Not really, but see below. > 3.) If the answer to 2 is that it's not smart to go to the > same gateway every time, then is something like RIP (which > should be available on most Unix networks because of > routed) the way to go, or does the ICMP redirect take care > of it. Bingo! If you have a decent IP implementation, then it will populate its local routing table when it gets ICMP redirects. BSD 4.3 does this. Probably alot of other IPs do, too. - Bob Stine
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 15:58:39 GMT From: manta!gutman@nosc.mil (Lewis M. Gutman) To: tcp-ip@nic.ddn.mil Subject: TCPIP PD network management?
I have a Macintosh II with an Excelan EtherPort II N card running NCSA Telnet 2.3 for the Macintosh. I'm looking for various network management utilities that will run from my Macintosh that will provide the same functionality as ping, nslookup, traceroute, netwatch, and any other management utilities for TCP/IP over Ethernet. Public domain is preferred. Does anyone have any information on such utilities? Thanks. Lew Gutman
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 16:47:38 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!jsivier@tut.cis.ohio-state.edu (Jonathon Sivier ) To: tcp-ip@nic.ddn.mil Subject: Programming editor needed
HELP!!!!
I need a text editor which I can actually use. I need an editor which has
as a minimum all the functunality of vi, including named buffers, fence matching
and macros. If it has additional features that would be fine, but crippled
versions of vi like stevie do me no good. I need an editor which will run, with
minimal differences, on a variety of machines and operating systems. I
currently am using; a VAXStation running VMS, an SGI IRIS running UNIX, PC
clones running MS-DOS and a Commodore Amiga running AmigaDOS. Since it needs to
run on a VAX it would be best if it didn't require an escape key since the
VAX keyboard has no escape. Does Emacs use the escape key? If so is there a
way around it? Does Emacs do fence matching for C programing? Is there a
version of vi for the VAX which allows you to remap the escape key to another
key? Is there anything out there anywhere? Please respond if you know of
something which fit's these ridiculous requirements be it freeware, shareware
or commercial.
Thanks for your assistance.
Jonathan
--
Jonathan Sivier
jsivier@ux1.cso.uiuc.edu
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 17:24:40 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: Wollongong TCP/IP ping question, VMS
In article <2521@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther Lumsdon) writes: > [PING requires SYSPRV] >Is it safe to install PING with SYSPRV privilege? >Will it compromise my system security? A matter of definition :-) :-) If you install PING with privilege, anybody can use PING. This is useful, but do you want them to ? (I.e. you may not want to pay for that essentially useless traffic). (But pings from OTHER sites are probably more disruptive than outgoing pings). >Does Wollongong's PING do anything other than sending ping at target? You mean, are there trojan horses in commercial code ? Of course you should be suspicious of anything for which you don't receive source code. If you are REALLY worried, you could write your own PING instead of using TWG's. >Is Wollongong's PING code written such that it uses SYSPRV carefully? Why would you be more suspicious of PING than of say the FTP daemon ? The reason PING requires privilege, is that it connects to a "raw" socket; i.e. it interfaces at a level of the network package where you can send *anything you like*. To prevent user programs from forging authentic looking datagrams that pretend to be from somewhere else, the network kernel has been made to insist that only privileged programs do these things. >I'll call Wollongong and ask these questions, and >post answers to the net in a week or so. > >-------------------------- Esther Lumsdon -------------------------------- >lumsdon@dtoa1.dt.navy.mil lumsdon@dtrc.dt.navy.mil >lumsdon%dtrc.navy.mil@uunet.uu.net >"Wherever you go, there you are" -Buckaroo Bonzai -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 19:00:40 GMT From: att!watmath!watserv1!utgpu!cunews!bcars8!bnrgate!bcars85!jsparkes@ucbvax.Berkeley.EDU (Jeff Sparkes) To: tcp-ip@nic.ddn.mil Subject: DUP and FM in tn3270 4.1.1
The following diffs make the DUP and Field Mark keys work properly under tn3270 4.1.1. Apply in tn3270/api. *** /tmp/,RCSt1a29408 Tue Jul 10 14:58:50 1990 --- asc_ebc.c Tue Jul 10 13:11:13 1990 *************** *** 30,36 **** /* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 08 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 10 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! /* 18 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 20 */ 0x40, 0x5A, 0x7F, 0x7B, 0x5B, 0x6C, 0x50, 0x7D, /* 28 */ 0x4D, 0x5D, 0x5C, 0x4E, 0x6B, 0x60, 0x4B, 0x61, /* 30 */ 0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, --- 30,36 ---- /* 00 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 08 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 10 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! /* 18 */ 0x00, 0x00, 0x00, 0x00, 0x1C, 0x00, 0x1E, 0x00, /* 20 */ 0x40, 0x5A, 0x7F, 0x7B, 0x5B, 0x6C, 0x50, 0x7D, /* 28 */ 0x4D, 0x5D, 0x5C, 0x4E, 0x6B, 0x60, 0x4B, 0x61, /* 30 */ 0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7, *** /tmp/,RCSt1a29408 Tue Jul 10 14:58:51 1990 --- ebc_disp.c Tue Jul 10 13:51:38 1990 *************** *** 27,33 **** /*00*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*08*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*10*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! /*18*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*20*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*28*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*30*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, --- 27,33 ---- /*00*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*08*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*10*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! /*18*/ 0x00, 0x00, 0x00, 0x00, 0x9f, 0x00, 0x9e, 0x00, /*20*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*28*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /*30*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, *************** *** 82,88 **** /*80*/ 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, /*88*/ 0x89, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, /*90*/ 0x98, 0x99, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, ! /*98*/ 0xa8, 0xa9, 0xe1, 0xea, 0xeb, 0xec, 0xef, 0xfe, /*A0*/ 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, /*A8*/ 0xc9, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, /*B0*/ 0xd8, 0xd9, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, --- 82,88 ---- /*80*/ 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, /*88*/ 0x89, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, /*90*/ 0x98, 0x99, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, ! /*98*/ 0xa8, 0xa9, 0xe1, 0xea, 0xeb, 0xec, 0x1e, 0x1c, /*A0*/ 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, /*A8*/ 0xc9, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, /*B0*/ 0xd8, 0xd9, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, -- Jeff Sparkes jsparkes@bnr.ca Another feature is that the seats float, so that the airline can recover them if the plane crashes into the ocean. -- Dave Barry
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 19:18:36 GMT From: hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
I wrote:
> The most common case where clients ask about disjoint subnets, is where
> an enterprise is geographically disjoint (say offices in Los Angeles,
> Denver and Boston) and wants to attach each office separately to the
> Internet, while assigning all host addresses out of the same class B
> network number. This of course is utterly undesirable (would OSPF allow
> it to be set up at all ?) and contravenes all the intentions for which
> subnets were invented.
Paul Tsuchiya <tsuchiya@THUMPER.BELLCORE.COM> replied:
PT>Hmmm. Why is it <of course> utterly undesirable that one organization
PT>in locations separated by the Internet not split up a Class B address?
PT>The only reason I can think of is that Internet routers are incapable of
PT>looking at subnet parts of the address--in other words, our Internet
PT>routers (or routing protocols) are inadequate. The thing just simply
PT>wouldn't work.
Indeed. The intent of IP is to route based on the network number, and
for most low-level routers not to have to know very many routes. Subnets
were invented to allow an organization to have multiple routes
internally while presenting only one logical point of entry to the
outside world.
PT>However, I don't necessarily see something inherently bad about this.
PT>I mean, given today's address structure (net.subnet.host), what are the
PT>alternatives?
PT>First, the organization could have multiple class C addresses? However,
PT>this puts a load equal to subnetted class B addresses on the Internet.
PT>Each router must maintain one routing table entry for each location.
The organization could be made to connect the disjoint subnets
internally; in the worst case, this could be done by tunnelling in the
routers. This is not too unlike the old ARPA/MIL/NSF geographical
overlay. Each backbone router will route packets to the multi-site
organization to the closest point of entry, and that router will get it
to where it needs to get to, either directly, or wrapped in an envelope
with the backbone address of the entrypoint router on the other end.
PT>... However, a more general, multi-level hierarchical address scheme
PT>coupled with an efficient address assignment scheme is what's needed.
The ultimate in general, multilevel hierachical address schemes is
ISO-IP, with its address format codes etc. IMHO, that way leads to utter
madness.
PT>Hear my ideas on this at the UCB IETF, or if you can't be there,
PT>ask me and I'll send you a paper on the topic.
Yes, I would like to see the paper.
-------
Similarly, Milo S. Medin (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
says:
MM>I don't think that the issue of older protocols not supporting such a
MM>configuration is an issue. Time moves on, and progress gets made.
but at the same time:
MM>Your case about the business with the disjoint offices ... won't
MM>work, ... because that organization's connections
MM>to the various regional or brand X networks and those net`s connections to
MM>each other typically use EGP, which does not allow the passing of
MM>subnet data. If everyone was glued together by one supernetwork, all
MM>running an IGP like OSPF, then yes, it could work. But that's not
MM>likely to be the way people's connections would work in any case.
- which was exactly my point. The "real" commercial networks are always
years behind the state of the "art".
Don't get me wrong: I think OSPF is great, and we should move to deploy
it instead of EGP as quickly as we can, from the core out. But so long
as not even the regionals are up to that level of sophistication, EGP is
the commercial reality, and those of us whose job is to "get me
connected NOW" have to find ways to live within those constraints.
--
/ Lars Poulsen, SMTS Software Engineer
CMC Rockwell lars@CMC.COM
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 20:13:52 GMT From: ulysses!atti07!althea!eddjp@ucbvax.Berkeley.EDU (Dewey Paciaffi) To: tcp-ip@nic.ddn.mil Subject: TCP/IP Over SNA Networks
If you have done TCP/IP communications over an SNA network, I'd like to hear from you. My company is buying two rs/6000s and we would like them to do TCP over our corporate SNA network. I'd like to know what it took hardware and software-wise to make it work, as well as how well it actually does work. -- Dewey Paciaffi eddjp@althea.UUCP
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Jul 90 10:05:26 -0700 From: "Philip Almquist" <almquist@jessica.stanford.edu> To: usc!zaphod.mps.ohio-state.edu!mips!wyse!vsi1!altos!altos86!mickey@ucsd.edu (Michael Thompson) Cc: tcp-ip@nic.ddn.mil Subject: Re: How to limit broadcasts between expensively connected networks?
Michael, > My question is: is there any way to (at the gateways) limit broadcast traffic > over expensive connections? In general, broadcasts on one of your nets will not be forwarded across the SLIP line to the other net. The only exception that I know of is that cisco routers can be configured (using "helper-address" or whatever they call it now). If you are using a routing protocol, it can (depending upon the protocol and the rest of your topology) generate a fair amount of traffic across the SLIP link. By clever configuration or by using static routing you can minimize eliminate this traffic. If I were you, I would try to diagnose the problem more fully. I don't know what kind of routers you are using, but most include the facility to trace packets going through them. Although that is hardly recommended for regular use (since it slows the routers to a crawl), such a facility is very useful for diagnosing the sort of problem you are seeing. Philip
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 00:22:39 GMT From: usc!zaphod.mps.ohio-state.edu!mips!wyse!vsi1!altos!altos86!mickey@ucsd.edu (Michael Thompson) To: tcp-ip@nic.ddn.mil Subject: How to limit broadcasts between expensively connected networks?
I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)
gateway-A gateway-B
144.1 --------------- X.25(slip) ---------------- 192.68.19
(ethernet) | 200.2.10.1 |<<----------->>| 200.2.10.2 | (ethernet)
<<---------->>| 144.1.10.98 | | 192.68.19.42 |<<--------->>
--------------- ----------------
gateway to 200.2.10 gateway to 200.2.10
gateway to 192.68.19 gateway to 144.1
When the gateways are configured as above, I can ping any machine on the
192.68.19 network from anywhere on the the 144.1 network (and vice versa).
However, I notice a lot of traffic across the X.25 line that I am guessing are
broadcasts (maybe from rwhod and/or timed??). These broadcasts seem to
originate from machines other than the gateways since if I don't make
them appear as gateways between 144.1 and 192.68.19 the traffic is eliminated.
My question is: is there any way to (at the gateways) limit broadcast traffic
over expensive connections?
Thanks,
-Michael
mickey@altos.Altos.COM
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 00:32:23 GMT From: excelan!manoj@ames.arc.nasa.gov (manoj @ Prod Mktg) To: tcp-ip@nic.ddn.mil Subject: Re: Novell to tcp/ip gateways
In article <25539@nuchat.UUCP>, abbadon@nuchat.UUCP (David Neal) writes:
>
> Hello, I am looking for information on linking Novell networks
> running netware into a tcp/ip based network of suns.
> I want the pc users to be able to telnet into the ip network.
Novell has a family of prodcts for DOS, OS/2 and Macintosh that allows you
concurrent access to both TCP hosts (telnet, ftp etc..) and also NetWare systems
call them for literature on LAN WORKPLACE they are not gateways in NetWare
but direct connect from the client desktop itself..
manoj goel, 0 0
Product Marketing ^
Novell/Excelan Inc., San Jose, CA \_/
(408) 473-8369 (voice) / 433-0775 (fax) Internet: manoj@novell.com
___________________________________________________________________________
"For every vision, there is an equal but opposite revision"
manoj goel, 0 0
Product Marketing ^
Novell/Excelan Inc., San Jose, CA \_/
(408) 473-8369 (voice) / 433-0775 (fax) Internet: manoj@novell.com
___________________________________________________________________________
"For every vision, there is an equal but opposite revision"
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Jul 90 09:21:43 EDT From: hung@eniac.seas.upenn.edu ( Han Hung) To: beach@ddnuvax.af.mil, tcp-ip@nic.ddn.mil Subject: Re: GOSIP from the grape vine
t~?
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 05:51:11 GMT From: usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!kwang@ucsd.edu (Kwang Sung) To: tcp-ip@nic.ddn.mil Subject: Questions on SNMP
Hi... SNMP folks, Since I don't have any experiences on Network Management, I might be asking pretty dumb questions. But I am curious, so please help me to understand. 1. How much did they define standard mechanisms for the archival, retrieval and remote retrieval of management data so far ?? 2. How much has been done for monitoring and management across administrative boundaries ?? 3. How can a proxy daemon be used to shield the agents from redundant network management request and respond using cached info ?? How can SNMP proxy be used to shield network elements from elaborate access control polices ?? 4. Since I am working at the Database company, I always have the question in my mind. We have a powerful distributed database product on the network. But, there is NO WAY to monitor each node's database activities from the remote site. Can we apply SNMP/CMOT/CMIP technology to allow to do that ?? Thanks. Kwang Sung Informix Software, Inc. 4100 Bohannon Dr. Menlo Park, CA 94025 415 / 926 - 6758 (O) UUCP: ...!uunet!infmx!kwang
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 06:27:09 GMT From: news!cartan!ndmath!nstar!comcon!tim@iuvax.cs.indiana.edu (Tim Brown) To: tcp-ip@nic.ddn.mil Subject: Re: Unix tar uncompression
In article <9007061308.AA11078@vax.ftp.com>, jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes: > >I need a means of uncompressing UNIX tar files for a PC. Is there a > >PC based utility available for this? > > Our PC/TCP product has a TAR.EXE which can assemble and disassemble > Unix-compatible tar files either locally or over the network. Sun's > PC_NFS also has a network TAR. If you want to "uncompress" a Unix > .tar.Z file (made by piping 'tar' into 'compress'), you'll have to > use 'uncompress' on the Unix system first. > The 16 bit compress distributed with BNEWS compiles fine on DOS. And works the same. Tim Brown nstar!comcon!tim
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 Jul 90 16:15:22 -0400 From: tmallory@BBN.COM To: Peter Elford <zaphod.mps.ohio-state.edu!know!samsung!munnari.oz.au!csc!pte900@tut.cis.ohio-state.edu> Cc: tcp-ip@nic.ddn.mil, tmallory@BBN.COM Subject: Re: Can subnets be separated by another net?
OSPF is not the only routing protocol with "advanced" subnet support: BBN has extended the SPF-based routing protocol used by the BBN T/20 Internet Router and the RIG(developed for DARPA and RADC) to use arbitrary hierarchical subnet masks, in which the mask bits need not be contiguous. It will handle the separated subnet scenario with no problems. Tracy Mallory BBN
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 10:10:45 GMT From: eru!luth!sunic!mcsun!cernvax!chx400!poole@BLOOM-BEACON.MIT.EDU (Simon Poole) To: tcp-ip@nic.ddn.mil Subject: Re: GOSIP from the grape vine
In article <CMM.0.88.647647249.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes: ..... > >There also seems to be the beginning of a plethora of so called >gateways to get from smtp based mail systems to X.400 based systems, >and might add full suite GOSIP x.400. Now just how the heck you map >some particular X.400 address to some particular user@host internet >address seems a little dicey. From what I've seen, it looks like >another big table to do the mapping. Has anybody implemented one >of these beasts and knows the definitive answer?? There are quite a few RFC987/1148 gateways out there (RFC987/1148 describe the mapping of X.400(84)/(88) to RFC822 and vice versa). Currently the tables which control the address mapping have around 600 entries. The main problem with them is not so much the size*, but the fact that changes to the tables and installation of them has to be globally coordinated. For example: in the RARE MHS project, installation of new tables happens every two months. *if you have a reasonable mapping strategy you can keep the number of entries per country to a sensible number, we have five (plus mappings for RFC822 top level domains: edu etc.), Germany ~180. -- ------------------------------------------------------------------------ Simon Poole poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole ------------------------------------------------------------------------
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 09:38:00 GMT+109:13 From: "VAXA::DBURKE" <dburke%vaxa.decnet@nusc-npt.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: Where is XEROX
Date sent: 11-JUL-1990 09:39:03 Hi folks, After spending more than 2 hours chasing down various telephone numbers given to me by "XEROX", I still haven't found what I'm looking for. If anyone knows a telephone number for purchasing "GATEWAY" services that runs on a XEROX 8090 fileserver, (part of the 6085 workstation network) please point me to it. Please, no COMPUTERLAND telephone numbers!!!!! (HOW CAN I ORDER WHAT I CAN'T FIND???) Thanks Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 15:18:46 GMT From: vixie!asylum!sharon@decwrl.dec.com (Sharon Fisher) To: tcp-ip@nic.ddn.mil Subject: Re: GOSIP from the grape vine
In article <CMM.0.88.647647249.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes: >Now that implementation of GOSIP are appearing, or at are claimed, on >certain vendor's shelves, I have a question or two maybe someone can >answer. Really? Who?
-----------[000130][next][prev][last][first]----------------------------------------------------
Date: 11 Jul 90 15:44:53 GMT
From: dburke%vaxa.decnet@NUSC-NPT.NAVY.MIL ("VAXA::DBURKE")
To: comp.protocols.tcp-ip
Subject: Where is XEROXDate sent: 11-JUL-1990 09:39:03 Hi folks, After spending more than 2 hours chasing down various telephone numbers given to me by "XEROX", I still haven't found what I'm looking for. If anyone knows a telephone number for purchasing "GATEWAY" services that runs on a XEROX 8090 fileserver, (part of the 6085 workstation network) please point me to it. Please, no COMPUTERLAND telephone numbers!!!!! (HOW CAN I ORDER WHAT I CAN'T FIND???) Thanks Dave ================================================================================ Dave Burke || ___________ Aquidneck Data Corporation || // || || 170 Enterprise Center || // || || Middletown, R.I. 02840 || // || || dburke%vaxb.decnet@nusc-npt.navy.mil || //-----|| || (401) 847-7260 || // || || (This line left intentionally blank) || // ||_____|| ================================================================================
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 20:15:22 GMT From: tmallory@BBN.COM To: comp.protocols.tcp-ip Subject: Re: Can subnets be separated by another net?
OSPF is not the only routing protocol with "advanced" subnet support: BBN has extended the SPF-based routing protocol used by the BBN T/20 Internet Router and the RIG(developed for DARPA and RADC) to use arbitrary hierarchical subnet masks, in which the mask bits need not be contiguous. It will handle the separated subnet scenario with no problems. Tracy Mallory BBN
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 20:20:06 GMT From: lll-crg.llnl.gov!booloo@lll-winken.llnl.gov (Mark Boolootian) To: tcp-ip@nic.ddn.mil Subject: Re: IP routing and gateways
In article <10900710151001.0004219666NB4EM@mcimail.com> 0004219666@MCIMAIL.COM (Bob Stine) writes: > >> 3.) If the answer to 2 is that it's not smart to go to the >> same gateway every time, then is something like RIP (which >> should be available on most Unix networks because of >> routed) the way to go, or does the ICMP redirect take care >> of it. > >Bingo! If you have a decent IP implementation, then it will populate >its local routing table when it gets ICMP redirects. BSD 4.3 does this. >Probably alot of other IPs do, too. > >- Bob Stine The down side to this is that you (potentially) get lots of entries in your routing table. And if you lose the gateway to which you have been redirected, you may not be able to get back to the original gateway (although it is possible that a routing redirect might be removed if the moon is just right...). Just more food for thought. mb food for line eater . . .
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 20:41:59 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) To: tcp-ip@nic.ddn.mil Subject: Re: How to limit broadcasts between expensively connected networks?
I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)
gateway-A gateway-B
144.1 --------------- X.25(slip) ---------------- 192.68.19
(ethernet) | 200.2.10.1 |<<----------->>| 200.2.10.2 | (ethernet)
<<---------->>| 144.1.10.98 | | 192.68.19.42 |<<--------->>
--------------- ----------------
gateway to 200.2.10 gateway to 200.2.10
gateway to 192.68.19 gateway to 144.1
$Begin Response$
Well, correct me if I am wrong (I'm sure someone will ;-), but
the ONLY *IP* broadcasts that should be going across the gateways
should be directed IP broadcasts. a 144.1.255.255 bcast should not be
forwarded from 144.1 to 192.68.19...
Are your gateways configured to be brouters? That would be the likely
way I can think of where broadcasts - ARPs and other non-IP - might be
passed from gateway to gateway? Rwho, and timed, being IP based,
should not be propagating across the gateways/routers. If they are
indeed brouters, you might try digging deep into the back of the
manuals to find-out how to set-up filtering for the 'bridged' packets
of the brouter.
___ _ ___
|__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer
| \_/ \_/ Hewlett-Packard Co. | Honest! It is TCP/IP! ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 22:30:05 GMT From: usc!cs.utexas.edu!chinacat!chip@ucsd.edu (Chip Rosenthal) To: tcp-ip@nic.ddn.mil Subject: Re: Novell to tcp/ip gateways
{{{ followups directed out of tcp-ip }}}
In article <1524@excelan.COM> manoj@excelan.COM (manoj @ Prod Mktg) writes:
>call them for literature on LAN WORKPLACE
Ha! This is pretty funny. Mr. Goel, why don't *you* try calling them
for literature. I did a couple of weeks back. The closest I ever got
was your voice mail system, and a few days later, a good round of telephone
tag with a sales critter. I shudder to think that if it's this tough to
get sales help, what's it going to be like to get applications support?
Never did get to talk to anybody. Needless to say, the client will not
be using Novell products for this project.
--
Chip Rosenthal | You aren't some icon carved out
chip@chinacat.Unicom.COM | of soap, sent down here to clean
Unicom Systems Development, 512-482-8260 | up my reputation. -John Hiatt
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 11 Jul 90 23:50:01 GMT From: usc!hacgate!ladcgw.ladc.bull.com!melb.bull.oz.au!sun0!sjg@ucsd.edu (Simon J. Gerraty) To: tcp-ip@nic.ddn.mil Subject: Re: telnet and pc's
In article <8285@b11.ingr.com> griffin@b11.ingr.com (Tommy Griffin) writes:
> We're experiencing some difficulty communicating between our
> workstations and PCs using Telnet over TCP/IP. The PCs are running
> Sun's PC/NFS product through the 3-Com Ethernet card.
> [...]
> The problem seems to be caused by the PC's inability to receive and/or
> process Ethernet/TCP frames which arrive within 5 milliseconds of each
> other. Our workstation sends output to the PC in TCP frames carrying
> 64 bytes of data. The 512 byte TCP window offered by the PC's TCP
> allows us to send up to 8 frames inside one window, so these frames
> can arrive with very little inter-frame spacing. When the PC drops a
> frame, we have to retransmit the data that was lost. The Jacobson
> algorithm in our implementation of TCP causes us to *DOUBLE* our
> retransmission timer each time we have to retransmit data. We
> eventually increase the retransmission timer to its maximum value, 20
> seconds, which explains why we're seeing bursts of data every 20
> seconds.
I found very similar problems when trying to get various PC
telnets to communicate with a Pyramid 9810 (I think the model is
correct). I was actually there to get a telnet that I had
written working with the Pyramid. Other telnets in use at the
site were NCSA, and PC/NFS. We had similar performance to what
you describe only worse. The Pyramid would echo key-strokes to
the PC's within 5ms and in most cases the PC's would miss the
echo. This resulted in very sporadic response appearing on the
user's screen.
The PC's involved were mostly 25MHz 386's using 16bit WD
Ethernet cards. Interestingly, using an 8bit 3Com card on an
8MHz 286, got better performance!
My conclusion was that the faster PC/adapters were able to get
them selves ready to send another frame, just as the echo
arrived (and thus miss it), whereas the slower PC/adapter was
more often in a state where it could accept the echo.
In all cases however we usually got to a point where lots of
retries were occuring and apparent performance was poor.
Cutting the window size and segment size to a minimum helped but
did not solve the problem.
> [...]
> It seems that the Sun workstations somehow determine that they're
> communicating with Sun PC/NFS on a 3-Com card, because they only allow
> one TCP frame to be transmitted to the PC at a time. They send a
> frame, and wait for an acknowledgement (or a retransmission timeout),
> then send another frame, and so on. This occurs even if the frame
> contains less data than the offered window size.
The PC/NFS telnet does terminal type negotiation and declares
itself as type "SUN". This may or may not be the flag the sun
notices, since in other respects the telnet connection seems
straight forward.
Mind you my telnet negotiates a type of VT220, and had no
problems with talking to Sun's (using WD or 3Com cards) so I may
be wrong.
> When we Telnet between Suns, or from Suns to our workstations, the
> Suns transmit many small TCP frames containing data in the offered TCP
> window before waiting for an acknowledgement.
>
> We would like to communicate effectively between our workstations and
> PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller.
As I indicated above, it isn't just PC/NFS you need to worry
about, nor is it just 3Com cards.
The suggestion I made to the Pyramid Tech rep. was (may be a bad
idea but here goes :-)
Modify the IP implementation so that a frame is not transmitted
to an address from which a frame was most recently received or
to which a frame was most recently sent.
The assumption here is of course that on a host there will
always be IP datagrams waiting to be sent to multiple
destinations. By ensuring that no destination is sent two
frames in a row, or that a frame is not sent to a destination
that we just received from, we effectively increase the delay
between frames to each destination without affecting the overall
throughput of the host.
This approach may be too simplistic, and something better might
be needed, but the simple fact is that even fast 386 PC's with
fast ethernet adapters cannot keep pace with many UNIX hosts.
Any UNIX vendor that wants their host to appear to perform well
when using PC's as telnet terminals, needs to pace its output to
each PC.
Sorry if this is all old hat...
--
Simon J. Gerraty
sjg@sun0.melb.bull.oz.au - NET
..!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!sun0.melb.bull.oz.au!sjg - UUCP
#include <disclaimer> /* imagine something *very* witty here */
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Jul 90 09:32:23 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) To: hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
Lars Poulsen writes: > The ultimate in general, multilevel hierachical address schemes is > ISO-IP, with its address format codes etc. IMHO, that way leads to utter > madness. What is IMHO? Also, ISO-IP addresses are the ultimate in administratively hierarchical address assignment, but have a long ways to go still in having a topologically meaningful hierarchical address. But I'm working on them too. PT
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 05:34:43 GMT From: arizona.edu!leonard@arizona.edu To: tcp-ip@nic.ddn.mil Subject: new telnet client swallows CRLF's?
We have seen a problem with recent implementations of telnet client talking to VMS/MultiNet. What happens is that, in some cases, output lines echo terminated by <cr> rather than with <cr><lf> - in other words, multiple lines overwrite one on top of the other. We have experienced the problem running telnet from a VAX running the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet V2.1 and 2.2. This problem did not manifest in prior releases of the Mt Xinu software, nor does it appear in telnets from the Mt Xinu machine into other systems. Telnet FROM MultiNet into Mt Xinu works fine, as does rlogin from Mt Xinu into MultiNet. Disconcertingly, the most recent software release from Sequent is also seen to manifest the problem (Dynix V3.0.12[?].) (That is, its telnet client behaves the same as Mt Xinu's does.) I infer from this that the problem has crept into the most recent BSD "standard" telnet, and is now appearing in vendors' products. It appears that what happens is this: the MultiNet side issues a <cr><lf><cr> sequence at the end of the line. While this is clearly not optimal (TGV says that this is a problem with the VMS terminal driver), one would think that the second <cr> should be an esthetic noop. The new telnet clients, however, output the line modulo the CRLF, so that such lines echo with only the CR. This seems wrong to me, and is painful to our users. Can anyone verify or rebut my analysis, or offer a workaround?
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 06:45:10 GMT From: qualcom!jwn2@ucsd.edu (John Noerenberg) To: tcp-ip@nic.ddn.mil Subject: WIN/TCP for VMS 5.1 NTYDRIVER bug
When users paste long segments of text from one Mac application into a Telnet window open to a VAX, the VAX regularly loses portions of the text. I traced this to improper coordination between NTYDRIVER and TTDRIVER in VMS, and reported the problem to Wollongong. TTDRIVER tries to xoff NTYDRIVER, but NTYDRIVER ignores the request, throwing down characters while TTDRIVER catches its breath. When I called Wollongong's technical support, the guy I talked to mumbled something about "oh that problem...review committee...mumble-mumble-mum..", but that was 6 months ago. Does anyone know if a patch exists for this? I apologize if I'm bringing up old news, but I've still got the bug, and I'm not getting any younger... Thanks from this poor, stranded luser in VMS-land!
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Jul 90 11:00:06 EDT From: Bob Stewart <stewart@xyplex.com> To: tsuchiya@thumper.bellcore.com Cc: tcp-ip@nic.ddn.mil Subject: Can subnets be separated by another net?
Paul Tsuchiya writes: >Also, ISO-IP addresses are the ultimate in administratively hierarchical >address assignment, but have a long ways to go still in having a >topologically meaningful hierarchical address. But I'm working on them >too. Seems to me that imbedding topological meaning in an address is not necessarily a good idea. That implies that as I move my portable around the network (from hotel to hotel, or, worse yet, on a cross country trip with a mobile phone), its address has to change. We have that problem now with SLIP connections. A name service could track the change so you could always reach me by name, but the more I move the more I have to change the name mapping, and such mappings usually don't appreciate being changed very much. *I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address assignment works nicely, such as with Domain Name Service or Ethernet global addresses, but should really be independent of routing. Of course, flat addresses don't offer any built-in efficiencies for finding the right neighborhood, like IP addresses do now... Tradeoffs, tradeoffs, always tradeoffs. Why can't there just be a right answer? Bob ----------- Bob Stewart (rlstewart@eng.xyplex.com) Xyplex, Boxborough, Massachusetts (508) 264-9900
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: Thu, 12 Jul 90 11:40:41 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) To: stewart@xyplex.com, tsuchiya@thumper.bellcore.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Can subnets be separated by another net?
From Bob Stewart: > > Seems to me that imbedding topological meaning in an address is not > necessarily a good idea. That implies that as I move my portable around the > network (from hotel to hotel, or, worse yet, on a cross country trip with a > mobile phone), its address has to change. We have that problem now with SLIP > connections. A name service could track the change so you could always reach > me by name, but the more I move the more I have to change the name mapping, > and such mappings usually don't appreciate being changed very much. > > *I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address > assignment works nicely, such as with Domain Name Service or Ethernet global > addresses, but should really be independent of routing. Of course, flat > addresses don't offer any built-in efficiencies for finding the right > neighborhood, like IP addresses do now... > > Tradeoffs, tradeoffs, always tradeoffs. Why can't there just be a right > answer? > Yes, tradoffs. In my latest work, I have proposed 1) hierarchical addresses reflecting the topological hierarchy, and 2) institutionalizing multiple addresses to reflect, for instance, those cases where a system is connected into the network in multiple places. This latter thing means that when you go to directory service or DNS, you get back MULTIPLE ADDRESSES. You pick one for your TCP connection (or whatever) based on policy. In other words, each address essentially represents a different path, which you choose by picking an address. I even think that the list of valid addresses should be conveyed to the destination by a TCP option in the call setup, and the destination can send back in the call accept the list, possibly pruned by its policy choices. Well, I'm getting ahead of myself. Anyway, what I have found is, from a system's perspective, shoving part of the routing problem into DNS is a GOOD tradeoff. In general, I think we have concentrated too much on automatic routing, and not enough on automatic address management. Our architecture and protocols do not take advantage of the significant degree of freedom afforded by letting addresses be more flexible--having multiple of them, changing them during a transport connection, stuff like that. Anyway, as I have said, read my paper. It covers a lot of stuff. Also, plan on getting sick and tired of my new-found religious perspective. It's been a while since I've had a soapbox to shout from. PT ps. IMHO. I like that.
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 18:06:07 GMT From: venus!yalevm!maine!shanley@CS.YALE.EDU To: tcp-ip@nic.ddn.mil Subject: Can't telnet to myself
Machine: 3B2-400
Wollongong TCP/IP WIN*/3B Rel 3.0.1
Unix V 3.1
Problem: I can telnet out from the machine, but I can't telnet
into the machine.
example: telnet me or telnet umofm.umeofm.maine.edu
neither works
I can ftp in and out of the machine just fine.
Any help is appreciated.
Thanks!
Kevin Shanley
shanley@maine.caps.maine.edu
shanley@umofm.umeofm.maine.edu
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Jul 90 00:34:39 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: usc!samsung!ginsburg@ucsd.edu (Scott Ginsburg) Cc: tcp-ip@nic.ddn.mil Subject: Re: IP routing and gateways
The Host Requirements RFC (lower layers, RFC 1122) has quite a bit to say about this: 1.) Is it the case that I need to provide a default gateway address for IP packets that aren't destined for someone within my subnet? Yes. Allowing several would be better than only one. 2.) Do I need to implement an IGP like RIP and maintain routing tables (even though this device only has one network interface) so that I choose the correct gateway to route my outgoing packets to, or is it OK to go to the same gateway (default) every time? It is quite acceptable to go to the first choice until you fail-over to another in the default list based on upper-layer advice or failure to reply to ARP, etc. ICMP Redirect was designed to supplement the default gateway with real-time advice about which gateway of all those Oactive on the net at any given time is "best". The intent was to allow hosts to avoid hacking routing protocols... 3.) If the answer to 2 is that it's not smart to go to the same gateway every time, then is something like RIP (which should be available on most Unix networks because of routed) the way to go, or does the ICMP redirect take care of letting me know that one internal gateway is better than another for an outgoing packet? The problem with implementing one routing protocol is that you'll have to do them all (RIP, IGRP, OSPF, IS-IS....) before you have real interoperability. In particular, there are many people awaiting their chance to be RIP's pallbearers (at least at their local sites). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 21:08:53 GMT From: logicon.com!tots!tep@nosc.mil (Tom Perrine) To: tcp-ip@nic.ddn.mil Subject: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <9007121800.AA01850@xap> stewart@xyplex.com (Bob Stewart) writes: >Paul Tsuchiya writes: >Seems to me that imbedding topological meaning in an address is not >necessarily a good idea. That implies that as I move my portable around the >network (from hotel to hotel, or, worse yet, on a cross country trip with a >mobile phone), its address has to change. We have that problem now with SLIP >connections. A name service could track the change so you could always reach >me by name, but the more I move the more I have to change the name mapping, >and such mappings usually don't appreciate being changed very much. > >*I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address >assignment works nicely, such as with Domain Name Service or Ethernet global >addresses, but should really be independent of routing. Of course, flat >addresses don't offer any built-in efficiencies for finding the right >neighborhood, like IP addresses do now... > >Tradeoffs, tradeoffs, always tradeoffs. Why can't there just be a right >answer? > > Bob But there is a right answer! Everyone will now use PPP over... cellular telephone dial-ups!! :-) I hate to admit it, but the cell-phone (phone system) model of addressing does have many advantages for the *user*. No matter where you go, your logical address (phone number) follows you. Of course, this puts all of the burden on the switching system, and the routing can often be far from optimal for a roaming cell phone user. I imagine that the main reason that this works for cell phones is that there is enough "excess" capacity in the switching system to handle the (hopefully) relatively rare, inefficient cases of roaming cell phones, which are a very small part of the switching load. Is there anything that we can learn (read "steal") from this example? Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: nosc!hamachi!tots!tep Tactical and Training Systems Division |-or- sun!suntan!tots!tep San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 02:16:14 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) To: tcp-ip@nic.ddn.mil Subject: Re: new telnet client swallows CRLF's?
In article <1990Jul11.223443.1@arizona.edu>, leonard@arizona.edu writes: | We have seen a problem with recent implementations of telnet client | talking to VMS/MultiNet. What happens is that, in some cases, output | lines echo terminated by <cr> rather than with <cr><lf> - in other | words, multiple lines overwrite one on top of the other. | | We have experienced the problem running telnet from a VAX running | the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet | V2.1 and 2.2. This problem did not manifest in prior releases of | the Mt Xinu software, nor does it appear in telnets from the Mt | Xinu machine into other systems. Telnet FROM MultiNet into Mt | Xinu works fine, as does rlogin from Mt Xinu into MultiNet. | | Disconcertingly, the most recent software release from Sequent is | also seen to manifest the problem (Dynix V3.0.12[?].) | (That is, its telnet client behaves the same as Mt Xinu's does.) | I infer from this that the problem has crept into the most recent | BSD "standard" telnet, and is now appearing in vendors' products. | | It appears that what happens is this: the MultiNet side issues a | <cr><lf><cr> sequence at the end of the line. While this is clearly | not optimal (TGV says that this is a problem with the VMS terminal | driver), one would think that the second <cr> should be an esthetic | noop. The new telnet clients, however, output the line modulo the CRLF, | so that such lines echo with only the CR. This seems wrong to me, and is | painful to our users. | | Can anyone verify or rebut my analysis, or offer a workaround? I believe that you are seeing a bug that was introduced in the "tahoe" release and later "fixed" in the 4.3 networking distribution. (I say "fixed" rather than fixed because the code still doesn't do what it appears to have been intended to do but in fact seems to do nothing at all.) The following is mostly from memory, so check the sources carefully... In the tahoe telnet, look for the "case TS_CR" in the receiver state machine. Observe that the else clause can discard a newline when it shouldn't. Worse, note that the behavior will depend on how much data was available when the last read of the network connection was done! That is, had the newline been in the same buffer as the CR, it would not have been dropped and state TS_CR would not have been entered. Now examine the same case in the 4.3 networking distribution. Note that the else clause has been changed such that if the character is a newline and a few other things are true, the character is added to the output queue. On the other hand, if the character is not a newline or any of the other things are not true, the character is *still* added to the output queue as we fall through to the TS_DATA state. Dan Lanciani ddl@harvard.*
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: Fri, 13 Jul 90 13:37:50 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) Cc: tcp-ip@nic.ddn.mil Subject: Re: How to limit broadcasts between expensively connected networks?
If the routers in use are actually 4bsd Unix systems, all the ones I've ever seen forward both RIP and RWHO packets out all their interfaces (SLIP included) by default. I don't recall anything in the manual pages which indicate that either broadcast can be restricted to a subset of the attached interfaces, but my memory isn't quite perfect, and I havn't read the source... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 15:21:00 EST From: "Murl McRae" <mcrae@mk6vms.nwscc.sea06.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: WIN/TCP Window Size
I need to change the TCP window size in WIN/TCP 3.2. Can anyone tell me
if it can be changed and if so, how? Thanks.
Murl McRae Naval Weapons Support Center
Crane, Indiana
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 12:47:27 GMT From: eru!luth!sunic!mcsun!hp4nl!philapd!idcapd!cssnl!eric%cssoff.syssup.tds.philips.nl@bloom-beacon.mit.edu (Eric van Rheenen) To: tcp-ip@nic.ddn.mil Subject: XID broadcast problems
Hello tcpip experts, This is my second posting of this question, but I didn't get any response. This is probably caused by a problem we had discovered by the machine that supplies us with the news. I have a problem with a network containing SUN's, ICL's and Motorola Delta series 8000 computers using the tcpip protocol. We have discovered that the SUN machines are sending XID broadcasts in this tcpip environment. This resulted in a havy netload from the motorola machine, because the response was wrong. We have fixed this problem, it doesn't respond anymore to this braodcasts :-). The customer now wants the Motorola machine to respond to this XID broadcasts in a proper way (for him). In our opinion, the XID protocol and associated frames are not part of the tcp/ip protocol. They are part of the OSI LLC protocol. Also the MAC layer doesn't have an OSI stack to handle the messages for processing. Thus ignoring the broadcasts is the best solution. Question: - Does anybody know why SUN has implemented XID broadcasts in a tcpip environment. Eric van Rheenen Philips Informatie Systemen Nederland B.V. Tel : +31 (0)55 - 43 3372 | UUCP: uunet!hp4nl!philapd!cssnl!eric Fax : +31 (0)55 - 43 3487 | NET : eric@syssup.tds.philips.nl
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 15:55:26 GMT From: nuchat!abbadon@uunet.uu.net (David Neal) To: tcp-ip@nic.ddn.mil Subject: novell<->tcp/ip
I posted a message a few days ago about novell<-> gateways.
Since then, I have gotten several informational messages and quite
a few "Me too's!".
So, I am going to post two summary messages. One that is strictly
informational, i.e. I will pass along all the information for
vendors and ftp sites I have received.
The second will be more subjective, and will include my experiences
with testing the various solutions.
The first summary should be next Wednesday or so; I want to make sure
everyone who is going to reply has a chance to do so.
The next summary is probably a month away, because I work for a government
contractor and it takes five levels of signatures just to get a P.O.
to order test software. sigh.
--
David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{rice, bcm, texbell, uunet}
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 17:39:45 GMT From: usc!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mephisto!uflorida!novavax!rm1!schunich@ucsd.edu (Geoffery Schunicht) To: tcp-ip@nic.ddn.mil Subject: SIGPIPE not received until second write
I'm working on a project that needs to communicate over sockets to
other machines. In doing initial testing of possible errors
encountered while using sockets I found that the SIGPIPE signal seemed
to be delayed by one write call when the server was killed off. The
sockets are set up in the AF_INET address format, using the tcp
protocol and the type is SOCK_STREAM. The client and server are in the
connected state, sending messages successfully. If I kill off the
server, the client will make one write successfully (no errors at
all), but the second will cause the SIGPIPE signal to occur. We do
want to be able to handle the error and continue processing all other
incoming/outgoing data to those processes still up. This will occur
on all the BSD systems we are running, SUN4's, SUN3's, DEC3100, 5400,
etc.
If has anyone seen this before, or know if there is some initial
set up for the socket or entire network that is missing please email
the solution. I can get around the problem by doing a second write of
zero bytes right after the first, but this is wasting a system call.
Thanks in advance.
Geoff Schunicht
--
uucp: ...novavax!rm1!schunich
schunich@rm1
Work: 305-846-6907
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 17:41:23 GMT From: intercon!news@uunet.uu.net (Amanda Walker) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes: > I hate to admit it, but the cell-phone (phone system) model of > addressing does have many advantages for the *user*. No matter where > you go, your logical address (phone number) follows you. In all of the cellular systems I've used so far, roaming is only half automatic. In particular, to place a call to a roamer, you have to dial the roamer access number for the area where they are, and then dial their phone number. This amounts to source routing, which is even more of a pain for mobile destinations than it is for "static" ones. Bleah. Maybe Motorola's proposed satellite-based cellular system will be better. That's it! We put the core gateways into geosynchronous orbit... :-) -- Amanda Walker <amanda@intercon.com> Postmaster With An Attitude InterCon Systems Corporation
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 19:29:18 GMT From: shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com To: tcp-ip@nic.ddn.mil Subject: How to get RFC documents dealing with TCP-IP
I am sorta new to all of this. Can anyone give me a pointer to on-line
copies of the RFC (Request For Comments) documents. I am especially
interested in the ones that describe BOOTP and IP/UDP.
thanks!
{ Rich Brunner / Digital Equipment Corporation / brunner@eagle1.enet.dec.com }
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 19:58:16 GMT From: miorelli@pwa-b.uucp (BoB Miorelli) To: comp.protocols.tcp-ip,comp.os.vms Subject: Request comments on VMS TCP/IP products
Our company currently has two non-communicating networks running on
a common Ethernet. Our workstations and Unix boxes use TCP/IP and
our VMS systems use DECnet. We would like to have the VMS machines
become part of the TCP/IP world.
I am soliciting recommendations from people actually doing this.
I know of several products, but need to hear the good points and
horror stories about each one. We will be using the standard
stuff such as telnet, rlogin, ftp, as well as some local code
using udp and unix sockets for communication.
Thanks for your input.
--
-->BoB Miorelli, Pratt & Whitney Aircraft
also, H & R Block tax preparer and Instructor
pwa-b!miorelli
-----------[000153][next][prev][last][first]----------------------------------------------------
Date: 13 Jul 90 20:21:00 GMT
From: mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae")
To: comp.protocols.tcp-ip
Subject: WIN/TCP Window Size
I need to change the TCP window size in WIN/TCP 3.2. Can anyone tell me
if it can be changed and if so, how? Thanks.
Murl McRae Naval Weapons Support Center
Crane, Indiana
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 20:58:33 GMT From: phri!news@nyu.edu (Roy Smith) To: tcp-ip@nic.ddn.mil Subject: Why does a wrong broadcast address cause arp-havoc?
By watching with tcpdump, I can see that when an occassional IP
object gets configured with the wrong broadcast address, each time it sends
a broadcast packet, a flurry of arp requests are generated by various
machines on the network. I sort of understand what is going on, but not
exactly. We use a hostpart of .0.0 for broadcasts, but once in a while a
misconfigured box pops up with .255.255, which other machines then try to
arp for.
What I don't understand is 1) why they bother to arp at all and 2)
why only some machines do it? As I understand it, when a machine wants to
send an IP packet, it has to arp to find out what link-level address to put
in the ethernet dst field. But why should a machine try to do an IP->ether
address resolution just because it receives an rwho packet sent to the
wrong IP broadcast address? An rwho requires no response, so there really
isn't any reason to need to know where it came from. As for the second
question, what is it about some machines that makes them arp for bad
broadcasts and others not? In our particular case, we have a bunch of
Sun-3's, all running SunOS-3.5.2. One of them runs a generic kernel, and
that's the only one that arps in response to .255.255 packets. All our
other Suns run customized kernels, but the only customizations are to
delete device drivers they don't need; nothing (that I know of) has been
changed in the networking code, yet they don't arp .255.255's. Why not?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 22:59:54 GMT From: ssc-vax!bcsaic!carroll@beaver.cs.washington.edu (Jeff Carroll) To: tcp-ip@nic.ddn.mil Subject: porting Berkeley lpd code to sys V R3.2
I would very much like to hear from anyone who has experience porting BSD code to system V/386. I'm trying to get lpd, lpr, lpq, et al. to run on our Intel 301s, which run Intel (Lachman) TCP/IP. The larger goal is to enable our Vax running WIN/TCP or MultiNet to act as a print server for the 301s. Do I have to get *all* the BSD libraries and what not, or is there an easier way to map the bsd system calls into the sys V and Lachman libraries? How big a job is this? Jeff Carroll carroll@atc.boeing.com
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 90 00:22:06 GMT From: bellcore-2!envy!karn@bellcore.com (Phil R. Karn) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <269E07C3.604D@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: |> Maybe Motorola's proposed satellite-based cellular system will be better. |> |> That's it! We put the core gateways into geosynchronous orbit... :-) The satellites in Motorola's proposed "Iridium" system would NOT be in geosynchronous orbit, they would be in low altitude polar orbits. As such, the system is much more like the Multiple Satellite System (MSS) that DARPA looked at a few years ago. Dave Mills was one of the investigators. Satellites in low altitude orbits move quite rapidly, so this will present a very interesting problem in routing. On the other hand, orbits are quite predictable, so at least you can compute your connectivity matrix at any desired time in the future. Back in the early days of communications satellites, it was not yet clear that geostationary was the way to go at that time. Many paper proposals for fleets of satellites in low earth orbit were made, but they never went very far because of the limits of the ground station technology in those days. Phil
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 14 Jul 90 10:02:03 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Why does a wrong broadcast address cause arp-havoc?
broadcasts cause arp storms because of a combination of over friendliness and confusion. Suppose you've got a system that things the broadcast address is 128.6.0.0 (an old 4.2 system). Now you have a system that sends using the correct broadcast address, which for my local subnet is 128.6.4.255. The old system will see this packet, since it's a broadcast. The IP input code will look, not recognize it as a broadcast, and assume that 128.6.4.255 is a host. Since most IP code is capable of acting as a gateway, it will assume somebody is trying to use it as a gateway, and thus try to forward the packet to 128.6.4.255. This will cause it to send an ARP request for 128.6.4.255. Another scenario is that you send a broadcast for 255.255.255.255 (the correct generic local broadcast). An old host may not recognize this as a broadcast. It will think this is a packet destined for network 255. Since it doesn't have a route to network 255, it may try to send back an ICMP unreachable. This will cause it to ARP the original sender. There are all sort of scenarios like this. They are complicated by various bugs. E.g. one implementation ended up sending ICMP errors to a broadcast address. What's really amusing is if somebody answer an ARP for 128.6.4.255 with a response giving Ethernet address ff.ff.ff.ff.ff.ff. In some sense this is right. However this can result in all sorts of mischief.
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 90 00:57:09 GMT From: usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!gopnbg!tmpmbx!einoed!utopia!scuzzy!src@ucsd.edu (Heiko Blume) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP reliability / little flow control primer
jc@minya.UUCP (John Chambers) writes:
>Be careful here. Where I work, we've been running SLIP over some modems
>that do MNP, and we use raw mode. The reason is that the MNP comes with
>software flow control, which means that any packet with a ^S causes the
>link to die. It usually doesn't take too long for such a packet to come
>along.
that's not correct. the modem to modem link should be settable to
100% transparent. mnp doesnt care about what data is sent over the line.
(at least if your modems are worth anything at all). your problem is
the flow control between the modems and the serial ports. you *should* use
hardware flow control (cts/rts). to do that your serial drivers must be
capable to do that. some unix implementations and especially many multiport
cards don't support that. it might be possible that some SL/IP implementations
support XON/XOFF flow control, but i wouldn't try that anyway. however
if you really want to use XON/XOFF your SL/IP must support it. (see below too).
>I spent of bunch of time on the phone with Customer Support people at
>the manufacturer (Codex), trying to figure out how to correctly configure
>the modems, and all I got from them was "Of course you want flow control;
>you'll lose data without it." They couldn't conceive of an application
>that didn't care about lost data. If there's a way to do MNP that lets
>*all* 8-bit values pass, they wouldn't or couldn't tell me how to do it.
i've never heard of codex, but anyway: i assume that these are fast modems
that use MNP class 5 or higher to yield speeds of 4800 bps or higher.
i'll go into some depths now as far as i know about my hardware.
however i think that good modems should work like this.
i use US Robotics Courier HST modems that implement MNP 5 to achieve 14000 bps.
to implement flow control HSTs offer a *lot* of options:
- transmit data flow control can be set to
- flow control disabled
- hardware (cts) flow control
- software flow control (XON/XOFF)
- hardware AND software flow control.
- received data (modem/other_host to host) software flow control can be
- disabled
- XON/XOFF to modem AND remote host
- XON/XOFF to local modem only
- HP protocol (ACK/NAK)
- received data hardware flow control can be
- disabled
- pass received data on rts high
remember that these are the options for *each* host/modem pair.
all these can be set in any combination to yield lots of funny results.
especially the XON/XOFF to modem AND remote host is dangerous, not to speak
of using hardware and software flow control simultaneously....
therefore i strongly recommend using rts/cts on both sides. otherwise
you'll have to do some serious planning/configuring.
have a look at your modems manual. if they don't support hardware flow control,
i'd buy other modems.
good luck!
--
Heiko Blume c/o Diakite blume@scuzzy.mbx.sub.org FAX (+49 30) 882 50 65
Kottbusser Damm 28 blume@netmbx.UUCP VOICE (+49 30) 691 88 93
D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d
"Have you bugged your source today?"
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 15 Jul 90 22:16:36 GMT From: usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: Still Looking: Access to Internet
In article <71@nic.cerf.net> pushp@nic.cerf.net (Pushpendra Mohta) writes: A copy of CERFNet's acceptable use policy can be obtained by anonymous ftp to nic.cerf.net from the cerfnet/cerfnet_info directory in the file cerfnet-accept-use-policy.txt. A copy of a number of acceptable use policies can currently be had from ftp.math.lsa.umich.edu:/pub/emv/acceptable-use/* . I'm collecting more as I find them. They are labelled according to the site they were ftp'd from, in order to make it easier to track down the original source. Currently the collection looks like: stag /s/ftp/pub/emv/acceptable-use % ls cren nic.cerf.net nic.near.net um.cc.umich.edu farnet nic.mr.net nis.nsf.net I'm sure there are more out there. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> comp.archives moderator
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 09:02:00 CST From: "22950::NMS" <nms%22950.decnet@mdc.com> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: tcp over hyperchannel
Does anyone have any experience using tcp over hyperchannel, in particular from IBM to non IBM computers?
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 03:29:36 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu (Peter Clark) To: tcp-ip@nic.ddn.mil Subject: Beginner's info TCP & UDP
Quick question: Under what conditions would a programmer want to use a UDP connection over a TCP connection? What does UDP give you that TCP doesn't, that makes it worth losing (or implementing yourself) a reliable, guaranteed delivery layer? Pete Clark Honeywell SRC Minneapolis MN
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Jul 90 8:47:07 CDT From: darrel beach <beach@ddnuvax.af.mil> To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil Subject: GOSIP and X.25
Thanks to everyone who responded to my last inquiry on GOSIP. I'm still not very knowledgeable about the OSI suite. I have a couple more simple (I hope) questions. The first one has to do with X.25. Is it possible or practical to run both TCP/IP and the GOSIP suite over a single X.25 interface into a network?? and ditto for ethernets?? I suppose ether is easy relative to X.25. I'm most familiar with the milnet (standard) brand of TCP/IP over X.25, where CC is the first byte of call user data in call request packets, and where datagrams are sent as complete packet sequences, etc. It would seem that in order to support BOTH suites over a single X.25 interface, then it would be necessary ti parse which protocol is being used, IP or ISO8473, after the PDU is received. That doesn't seem too practical. Would a host now have to maintain a virtual circuit table that includes info on what kinds of PDUs can be sent on that vc (IP or 8473). This assumes the X.121 addresses for a dual protocol hosts is the same regardless of which suite is being called. In the case of Milnet, does anybody know how to address OSI suite hosts? Right now it looks like I just build a table of X.121 addresses. Will there ever be an algorithmic derivation to get the X.121 addresses?? Seems to be a knotty little topic, but maybe its easier than it seems. Darrel Beach
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 06:11:58 GMT From: snorkelwacker!ira.uka.de!fauern!tumuc!lan!charly.bl.physik.tu-muenchen.de!k2@tut.cis.ohio-state.edu (Klaus Steinberger) To: tcp-ip@nic.ddn.mil Subject: Re: Why does a wrong broadcast address cause arp-havoc?
roy@alanine.phri.nyu.edu (Roy Smith) writes: > By watching with tcpdump, I can see that when an occassional IP >object gets configured with the wrong broadcast address, each time it sends >a broadcast packet, a flurry of arp requests are generated by various >machines on the network. I sort of understand what is going on, but not >exactly. We use a hostpart of .0.0 for broadcasts, but once in a while a >misconfigured box pops up with .255.255, which other machines then try to >arp for. At first: Not the .255.255 boxes are misconfigured, all of youre other stuff is misconfigured. The official broadcast address is a host-part of all ones! There was an bug in Berkeley 4.2 networking code, which led to those all zero addresses! > What I don't understand is 1) why they bother to arp at all and 2) >why only some machines do it? As I understand it, when a machine wants to >send an IP packet, it has to arp to find out what link-level address to put >in the ethernet dst field. But why should a machine try to do an IP->ether >address resolution just because it receives an rwho packet sent to the >wrong IP broadcast address? An rwho requires no response, so there really It's because IP-forwarding is normally enabled in the kernel. And some machines think, if they are configured to all zeros broadcast, and they see a all ones broadcast, that they must forward it. So they try to arp' the address. >isn't any reason to need to know where it came from. As for the second >question, what is it about some machines that makes them arp for bad >broadcasts and others not? In our particular case, we have a bunch of >Sun-3's, all running SunOS-3.5.2. One of them runs a generic kernel, and >that's the only one that arps in response to .255.255 packets. All our >other Suns run customized kernels, but the only customizations are to >delete device drivers they don't need; nothing (that I know of) has been >changed in the networking code, yet they don't arp .255.255's. Why not? Maybe, you have disabled IP-forwarding in the customized kernels. I think you should have a close look to all your equipment, if it's able to use the .255.255 broadcast, and then you should switch to it. It's hard to do, because you have to change all configurations in one shot, but you will not run into trouble, if new machines are installed. Most networking software is derived from Bsd 4.3, so the broadcast will be configurable, but all defaults to .255.255. Sincerely, Klaus Steinberger Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende, D-8046 Garching, West Germany BITNET: K2@DGABLG5P Internet: k2@charly.bl.physik.tu-muenchen.de
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 07:12:10 GMT From: eru!luth!sunic!liuida!prodix!martin@bloom-beacon.mit.edu (Martin Wendel) To: tcp-ip@nic.ddn.mil Subject: Mailbox servers
I am interested in setting up mailbox servers on UNIX workstations/servers. I have looked at IMAP2 and it seems quite capable. However, after reading the docs on IMAP2 I learned that every mailbox must be connected to a defined user on one of the mailbox servers. I regard this as a security threat. It seems that IMAP2 was built to work on small sites consisting mainly of workstations and not on larger sites with servers, workstations and lots of small computers. Is there anyone out there who has experience of mailbox servers in large sites (I am talking ten or more subnets and tenthousand mailboxes). Thanks in advance Martin.Wendel@UDAC.UU.SE
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Jul 90 13:02:14 EDT From: Caleb Strockbine <QOP%CORNELLA.BITNET@ricevm1.rice.edu> To: TCP-IP%NIC.DDN.MIL@ricevm1.rice.edu Subject: Re: How to get RFC documents dealing with TCP-IP
>I am sorta new to all of this. Can anyone give me a pointer to on-line >copies of the RFC (Request For Comments) documents. I am especially >interested in the ones that describe BOOTP and IP/UDP. You can get RFCs by anonymous FTP from nic.mil.ddn (formerly sri-nic.arpa). CD to the RFC: (the colon is necessary) directory. Then get all the RFCs your heart desires. There's an index file that's pretty useful, especially since you can use grep to find pretty much anything (assuming you're a Unix type). Good luck. Caleb Strockbine qop@cornella.cit.cornell.edu
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: Mon, 16 Jul 90 17:04:21 -0400 From: Andy Malis <malis@BBN.COM> To: darrel beach <beach@ddnuvax.af.mil> Cc: tcp-ip@nic.ddn.mil, malis@BBN.COM Subject: Re: GOSIP and X.25
Darrel, > Thanks to everyone who responded to my last inquiry on GOSIP. I'm > still not very knowledgeable about the OSI suite. I have a couple more > simple (I hope) questions. I think I can help. > The first one has to do with X.25. Is it possible or practical to > run both TCP/IP and the GOSIP suite over a single X.25 interface into a > network?? and ditto for ethernets?? I suppose ether is easy relative > to X.25. X.25 is actually easy, at least on the DDN. I can't speak for ether. > I'm most familiar with the milnet (standard) brand of TCP/IP > over X.25, where CC is the first byte of call user data in call request > packets, and where datagrams are sent as complete packet sequences, > etc. It would seem that in order to support BOTH suites over a single > X.25 interface, then it would be necessary to parse which protocol is > being used, IP or ISO8473, after the PDU is received. That doesn't > seem too practical. You're right, that's not the best way to do it. If you check RFC 1060, p. 48 (X.25 type numbers), you'll see that ISO IP has its own protocol ID (first byte of CUD in Call Request packets), CD. So, to use ISO-IP, you just open an X.25 VC to another consenting host using the ISO IP protocol ID. You can even run IP and ISO-IP in parallel between two hosts, over separate VCs of course. I have the impression that on the Milnet, ISO-IP usually runs over Basic X.25, rather than Standard X.25, since there is no need to interoperate with AHIP (1822) hosts, but either should work as long as the two hosts agree. > Would a host now have to maintain a virtual > circuit table that includes info on what kinds of PDUs can be sent on > that vc (IP or 8473). This assumes the X.121 addresses for a > dual protocol hosts is the same regardless of which suite is being > called. Yes, you should keep a VC table that lists the X.121 address on the other end of the VC, and the protocol being used on the VC. But you really have to do that anyway. Yes, on the DDN (Milnet), at least, the X.121 address is independent of the protocol, since the PSNs don't care what protocol you're running above X.25; they just need the address to get the data to the right place. The physical address is the same. > In the case of Milnet, does anybody know how to address OSI suite > hosts? Right now it looks like I just build a table of X.121 > addresses. Will there ever be an algorithmic derivation to get the > X.121 addresses?? Seems to be a knotty little topic, but maybe its > easier than it seems. If I understand your question correctly, I think the answer lies in RFC 1069, which defines ISO-IP addresses for use in the Internet. Figure 3, on p. 7, shows the regular IP address residing in octets 16-19 of the ISO-IP address. Once you have the regular IP address, you can use the regular algorithmic derivation to get the Milnet X.121 address. Andy Malis BBN Communications
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 16:59:59 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: parallel networks problem
In article <7050@star.cs.vu.nl>, sater@cs.vu.nl (Staveren van Hans) writes: > Recently I posted a question to these groups to which, to my surprise, > I received no reactions at all. This seems strange since it addresses a > problem that many of us are going to face. Now there is of course the > possibility that this is so obvious that you were all embarrassed by > the question, but I doubt it. > > Suppose part of a network looks like this > > --------------------------------------------------------- network A > | | | > ----------------- ----------------- ---------- > | A.1 | | A.2 | | A.3 | > | Host foo | | Host bar | |Host zot| > | B.6 | | B.7 | | | > ----------------- ----------------- ---------- > | | > --------------------------------------------------------- network B > > so two parallel networks with some multihomed and some singlehomed hosts. > Further suppose that network B is preferable to network A, because of > load, politics or because it is 10x as fast (hint: FDDI vs Ethernet). > How would one set up addressing and routing for such a configuration? > What is the Internet Protocol supposed to do? In the TCP/IP frame of reference, IP was designed to route internet datagrams from source address to destination address. IP understands interfaces. But applications understand hosts/servers/service-entities. How does one tie an "entity" to a "set of addresses" as one moves down the protocol stack? How does one deal with so-called multi-homed hosts? The answer is, IP does not deal with the issue. Should it? Good philosophical question... and can of worms. Let us assume that IP should not deal with entities, only interfaces (addresses). Can the applications (or some other level in the stack) deal with the translation of entity name to "ordered set of addresses"? I think they can. I would suggest that the place to attack this problem is in the resolver. I recall discussions in times past about whether the name servers should be able to do this based on source address, but it seemed to me at that time that that was impossible for the name servers to do, since the source entity could be multi-homed. The resolver will need to be able to get some kind of routing or preference metric from the network layer. Many options. I would also suggest that there are many places in the protocol stack where a domain name would work better than an ip- address. Of course, machines may have many names, but at least we have the concept of canonical name. We also have the concept of multicast (implying groups of servers that are in some sense equivalent). So we are torn in search of the correct paradigm and are tied to others' past decisions in the history of TCP/IP. More grist for the philosophers... --Kent
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 17:02:14 GMT From: QOP@CORNELLA.BITNET (Caleb Strockbine) To: comp.protocols.tcp-ip Subject: Re: How to get RFC documents dealing with TCP-IP
>I am sorta new to all of this. Can anyone give me a pointer to on-line >copies of the RFC (Request For Comments) documents. I am especially >interested in the ones that describe BOOTP and IP/UDP. You can get RFCs by anonymous FTP from nic.mil.ddn (formerly sri-nic.arpa). CD to the RFC: (the colon is necessary) directory. Then get all the RFCs your heart desires. There's an index file that's pretty useful, especially since you can use grep to find pretty much anything (assuming you're a Unix type). Good luck. Caleb Strockbine qop@cornella.cit.cornell.edu
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: Tue 17 Jul 90 01:57:15-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: mcrae@mk6vms.nwscc.sea06.navy.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: WIN/TCP Window Size
Mumble. Someone has to ask... Just WHY do you want to change the window size (and which one). The window sizes offered by (and to) a system can be carefully thought out by the implementors, and can have serious non-linear effects on performance, thoughput, and even reliability of they are changed very much. There are better ways to solve most problems than changing the window sizes... BillW -------
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 19:17:11 GMT From: pollux!ccruss@ucdavis.ucdavis.edu (Russ Hobby) To: tcp-ip@nic.ddn.mil Subject: Network FAX Working Group
Due to the interest in being able to transmit FAX over TCP/IP networks,
the Internet Engineering Task Force has formed a new Working Group to
evaluate the needs and to come up with methods and protocols to accomplish
this task.
The WG charter has been included below and includes information on how
to be added to the WG maillist. For more information contact the WG Chair.
Russ Hobby INTERNET: rdhobby@ucdavis.edu
IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS
UUCP: ...!ucbvax!ucdavis!rdhobby
-----------------------------------------------------------
Network Fax Working Group
Chairman:
Mark H Needleman/University of California-DLA
(mhn@stubbs.ucop.edu)
Mailing Lists:
General Discussion: netfax@stubbs.ucop.edu
To Subscribe: netfax-request@stubbs.ucop.edu
Anonymous FTP:
/pub/netfax@stubbs.ucop.edu
Description of the Working Group:
The Network Fax Working group is chartered to explore
issues involved with the transmission and receipt of
facsimile across TCP/IP networks and to develop recommended
standards for facsimile transmission across the Internet.
The group is also intended to serve as a coordinating forum
for people doing experimentation in this area to attempt to
maximise the possibity for interoperability among network
fax projects.
Among the issues that need to be resolved are what
actual protocol or protocols will be used to do the actual
data transmission between hosts, architectural models for
the integration of fax machines into the existing internet,
what types of data encoding should be supported, how IP
host address to phone number conversion should be done and
associated issues of routing, and develeopment of a gateway
system that will allow existing Group 3 and Group 4 fax
machines to operate in a network enviornment.
It is expected that the output of the working group
will be one or more RFC's documenting recommended solutions
to the above questions and possibly also describing some
actual implementations. The life of the working group is
expected to be 18-24 months.
It is also hoped th at some fax vendors, as well as
the networking community and fax gateway developers, will
be brought into the effort.
Goals and Milestones:
1). August 1990: First IETF Meeting: review and approve
charter making any changes deemed necessary. Refine
definition of scope of work to be accomplished and
intial set of RFC's to be developed. Begin working on
framework for solution.
2). August - March 1991: Continue work on definition of
issues and protocols. Work to be conducted on mailing
list.
3) March - August 1991: First draft of RFC to be
completed. To be discussed at IETF meeting and revised
as necessary. Make document and Internet draft.
4) August - December 1991: Continue revisions based on
comments received and if ok give to IESG for
publication as RFC.
5) January - March 1992: Overlapping with activities
listed above may be implementations based on ideas and
work done by the working group. If so revise RFC to
include knowledge gained from such implementations.
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 20:32:22 GMT From: wotk!root@uunet.uu.net (Superuser) To: tcp-ip@nic.ddn.mil Subject: UDP checksums
Does anyone know how to enable UDP checksums on a Sun 360.
Thanks.
Nick Hennenfent
Computone Products
1100 Northmeadow Parkway
Suite 150
Roswell, GA 30076
Voice 404 475-2725 FAX 404 343-9735 email ...!uunet!wotk!{root,nickh}
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 21:04:21 GMT From: malis@BBN.COM (Andy Malis) To: comp.protocols.tcp-ip Subject: Re: GOSIP and X.25
Darrel, > Thanks to everyone who responded to my last inquiry on GOSIP. I'm > still not very knowledgeable about the OSI suite. I have a couple more > simple (I hope) questions. I think I can help. > The first one has to do with X.25. Is it possible or practical to > run both TCP/IP and the GOSIP suite over a single X.25 interface into a > network?? and ditto for ethernets?? I suppose ether is easy relative > to X.25. X.25 is actually easy, at least on the DDN. I can't speak for ether. > I'm most familiar with the milnet (standard) brand of TCP/IP > over X.25, where CC is the first byte of call user data in call request > packets, and where datagrams are sent as complete packet sequences, > etc. It would seem that in order to support BOTH suites over a single > X.25 interface, then it would be necessary to parse which protocol is > being used, IP or ISO8473, after the PDU is received. That doesn't > seem too practical. You're right, that's not the best way to do it. If you check RFC 1060, p. 48 (X.25 type numbers), you'll see that ISO IP has its own protocol ID (first byte of CUD in Call Request packets), CD. So, to use ISO-IP, you just open an X.25 VC to another consenting host using the ISO IP protocol ID. You can even run IP and ISO-IP in parallel between two hosts, over separate VCs of course. I have the impression that on the Milnet, ISO-IP usually runs over Basic X.25, rather than Standard X.25, since there is no need to interoperate with AHIP (1822) hosts, but either should work as long as the two hosts agree. > Would a host now have to maintain a virtual > circuit table that includes info on what kinds of PDUs can be sent on > that vc (IP or 8473). This assumes the X.121 addresses for a > dual protocol hosts is the same regardless of which suite is being > called. Yes, you should keep a VC table that lists the X.121 address on the other end of the VC, and the protocol being used on the VC. But you really have to do that anyway. Yes, on the DDN (Milnet), at least, the X.121 address is independent of the protocol, since the PSNs don't care what protocol you're running above X.25; they just need the address to get the data to the right place. The physical address is the same. > In the case of Milnet, does anybody know how to address OSI suite > hosts? Right now it looks like I just build a table of X.121 > addresses. Will there ever be an algorithmic derivation to get the > X.121 addresses?? Seems to be a knotty little topic, but maybe its > easier than it seems. If I understand your question correctly, I think the answer lies in RFC 1069, which defines ISO-IP addresses for use in the Internet. Figure 3, on p. 7, shows the regular IP address residing in octets 16-19 of the ISO-IP address. Once you have the regular IP address, you can use the regular algorithmic derivation to get the Milnet X.121 address. Andy Malis BBN Communications
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 21:33:26 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ark1!nems!dtoa1!lumsdon@tut.cis.ohio-state.edu (Lumsdon) To: tcp-ip@nic.ddn.mil Subject: Re: Wollongong TCP/IP ping question, VMS
In article <1990Jul10.172440.15458@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: >In article <2521@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil > (Esther Lumsdon) writes: >> [PING requires SYSPRV] >>Is it safe to install PING with SYSPRV privilege? [....] >The reason PING requires privilege, is that it connects to a "raw" >socket; i.e. it interfaces at a level of the network package where you >can send *anything you like*. To prevent user programs from forging >authentic looking datagrams that pretend to be from somewhere else, the >network kernel has been made to insist that only privileged programs do >these things. Thank you for pointing this out. Thanks for all responses. It has become a moot point. NCSA's tcp/ip for MS-DOS requires (inexplicably) that the VAX PING the PC in order to get communications to work after both machines have rebooted. We are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited this strange behavior. -------------------------- Esther Lumsdon -------------------------------- lumsdon@dtoa1.dt.navy.mil lumsdon@dtrc.dt.navy.mil lumsdon%dtrc.navy.mil@uunet.uu.net "Wherever you go, there you are" -Buckaroo Bonzai
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 16 Jul 90 23:44:52 GMT From: comp.vuw.ac.nz!newbery@uunet.uu.net (Michael Newbery) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >In all of the cellular systems I've used so far, roaming is only half >automatic. In particular, to place a call to a roamer, you have to dial >the roamer access number for the area where they are, and then dial their Not in New Zealand. Cell phones have their own area code which covers the country. All cell calls cost the same per minute regardless of distance (which is cheaper than the most expensive 'normal' toll step.) As part of testing they placed a call, got in a plane and flew the length of the country, keeping the circuit up during the entire journey. (OK, so NZ is small, but it is bigger in area than the U.K. which does require area access numbers). -- Michael Newbery<newbery@rata.vuw.ac.nz> Q: What do you do with a wombat? A: Play wom with it!
-----------[000175][next][prev][last][first]----------------------------------------------------
Date: 17 Jul 90 00:32:42 GMT
From: swrinde!zaphod.mps.ohio-state.edu!mips!ultra!beau@ucsd.edu (Beau James {Manager - SW Development - Ultra Networks})
To: tcp-ip@nic.ddn.mil
Subject: Re: UDP checksums
In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes:
>Does anyone know how to enable UDP checksums on a Sun 360.
# adb -k /vmunix /dev/mem
...
udp_cksum/W 1 ; Enables UDP checksums on the running kernel
udp_cksum?W 1 ; Enables whenever this kernel is booted
UDP checksums must be enabled on both sending and receiving
machines before the software will compute and verify the
checksum.
Beau James beau@Ultra.COM
Ultra Network Technologies {sun,ames}!ultra.com!beau
--
Beau James beau@Ultra.COM
Ultra Network Technologies {sun,ames}!ultra.com!beau
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 01:02:34 GMT From: agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU (RL "Bob" Morgan) To: tcp-ip@nic.ddn.mil Subject: Zero manufacturer code in SNAP?
Here's a question about SNAP that might be answered if I could ever actually see the spec for it. Then again, maybe not. The 40-bit SNAP extension to IEEE 802.2 specifies a 24-bit "organizationally unique identifier" that is apparently supposed to be the same 24 bits that a manufacturer uses to form the upper part of a 48-bit unique IEEE 802 MAC address. The other 16 bits are assigned by the organization in any way it sees fit. Now, IP on 802.2, as specified in RFC 1042, uses 24 bits of zeros to fill this field. The remaining 16 bits are filled with the same 16 bits used for the Ethernet type field (for IP and ARP frames). The question is, has the all-zeros SNAP id been assigned by IEEE to DoD, or the IAB, or some IP authority, to be administered by that authority? Or is the all-zeros id just a general purpose format for translating Ethernet frames to 802.2/SNAP, to be used by anyone? Those of you familiar with AppleTalk Phase II may get a glimmer of why I'm asking. Thanks, - RL "Bob" Morgan Networking Systems Stanford
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 01:14:17 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) To: tcp-ip@nic.ddn.mil Subject: Re: Beginner's info TCP & UDP
People tend to use UDP where (1) they plan to be making isolated queries, such that the overhead packets used to set up and close a connection would form most of the traffic (2) they need more performance than they think they can get from TCP. The domain system is an example of the first category. You send a one-packet query and get back a one-packet response. If you don't get a response, just try again. NFS is an example of the second category. The folks at Sun apparently believed that they couldn't get good enough performance out of TCP to use it for swapping. In most cases I recommend using TCP. If you use UDP, you end up having to build retransmission algorithms into your application. In most cases you'll get better performance by using TCP, whose algorithms have been well tuned (at least if you are using a recent Berkeley TCP), rather than rolling your own.
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 01:14:40 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu (Mark Crispin) To: tcp-ip@nic.ddn.mil Subject: Re: Mailbox servers
In article <161@prodix.liu.se> martin@prodix.liu.se (Martin Wendel) writes: >I am interested in setting up mailbox servers on UNIX >workstations/servers. I have looked at IMAP2 and it >seems quite capable. However, after reading the docs >on IMAP2 I learned that every mailbox must be connected >to a defined user on one of the mailbox servers. I regard >this as a security threat. It seems that IMAP2 was built >to work on small sites consisting mainly of workstations >and not on larger sites with servers, workstations and >lots of small computers. > >Is there anyone out there who has experience of mailbox >servers in large sites (I am talking ten or more subnets >and tenthousand mailboxes). There is nothing in IMAP2 per se that requires that "every mailbox must be connected to a defined user on one of the mailbox servers." It is true that the current Unix IMAP2 server (and the DEC-20 one) implement access authentication as defined users on the server. If by "security threat" you are worried about these credentials flowing on the network, the way you address this is Kerberos. There's no reason why Kerberizing IMAPware should be any more difficult than Kerberizing FTP (a solved problem). If by "security threat" you are worried about people with mailboxes being able to log in on the server as a timesharing user, there is already a perfectly good mechanism to prevent this in Unix. In any case, since the IMAP2 sources are available, there is no reason why you cannot implement your own authentication mechanism. Nothing in the protocol forces defined users; there are merely two authentication tokens commonly referred to as "user" and "password". Please contact me if you have any specific questions. IMAP2 was specifically designed to scale in the way you suggest. It certainly scales for larger sites better than more traditional protocols. I use IMAP2 on 8 different servers, including a server in a foreign country. _____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105 _|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!" |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?" --|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin." /|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 03:04:22 GMT From: nic.cerf.net!pushp@ucsd.edu (Pushpendra Mohta) To: tcp-ip@nic.ddn.mil Subject: DIAL n CERF (Was Re: Still Looking: Access to Internet)
> > In article <68@nic.cerf.net> of comp.dcom.modems I, pushp@nic.cerf.net (Pushpendra Mohta) wrote: > >If you wish to consider dial up access for internet connectivity > >I believe CERFNet can provide all of what you want at sites > >at UCLA, CALTECH, UCI , San Diego and Oakland. > > > > > >--pushpendra > >CERFNet In article <1990Jul14.154305.14154@uu.psi.com>of comp.dcom.modems , schoff@uu.psi.com (Martin Schoffstall) writes: > Pushpendra: > Could you describe the permission procedure that CERFNET goes through > to provide Internet access to individuals? > Could you describe contract requirements > (if any) for those individuals, especially in the area of NSFNet limitations, > etc... Could you describe the costs? > Just Curious. > Marty > --------------- CERFNet has an approval procedure consistent with it's Acceptable Use Policy (AUP) . This policy is the same as the NSFNet AUP. All applications are reviewed by the Chairperson or his/her designees on a case-by-case. All accepted applicants are bound by the contract to abide by the AUP. Quotes and Negotiations are unique to each individual/organization All interested in the dial up offering : DIAL n' CERF should contact CERFNet at help@cerf.net or at (619) 534-5087 A complete description of costs and requirements will soon appear in comp.newprod . Mean while those curious may obtain a copy of the DIAL n' CERF user agreement (contract) by anonymous ftp from nic.cerf.net:cerfnet/cerfnet_info/dial-n-cerf-agreement.txt. This document includes a copy of the CERFNet AUP. --pushpendra CERFNet (619) 534-5056
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 10:05:26 PDT From: postel@venera.isi.edu To: brunner@eagle1.enet.dec.com, shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com Cc: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents dealing with TCP-IP
Hi.
RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login
with FTP, username ANONYMOUS and password GUEST.
The NIC also provides an automatic mail service for those sites
which cannot use FTP. Address the request to SERVICE@NIC.DDN.MIL
and in the subject field of the message indicate the RFC number,
as in "Subject: RFC nnnn".
RFCs can also be obtained via FTP from NIS.NSF.NET. Using FTP, login
with username ANONYMOUS and password GUEST; then connect to the RFC
directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1
(where "nnnn" refers to the number of the RFC).
The NIS also provides an automatic mail service for those sites which
cannot use FTP. Address the request to NIS-INFO@NIS.NSF.NET and leave
the subject field of the message blank. The first line of the text of
the message mist be "SEND RFCnnnn.TXT-1", where nnnn is replaced by
the RFC number.
--jon.
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 10:07:31 pdt From: Walter Underwood <wunder@hp-ses.sde.hp.com> To: tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip Subject: Re: Beginner's info TCP & UDP
Hedrick's and Warnock's explanations are interesting, but I sent Pete a rather different explanation for UDP's existance. UDP is for protocols that don't want or need byte streams. It is for protocols that need pure datagrams, often for request/response, and it is for building custom protocols, like NTP. TIME and DAYTIME are the classic request/response examples -- if the reply is lost, TCP would retransmit the old timestamp after a timeout, but with UDP, the requestor times out, asks again, and gets a new timestamp. A transaction protocol that supports idempotent requests would satisfy a lot of the current users of UDP, but it would not obsolete UDP. wunder
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 10:08:21 PDT From: jkrey@venera.isi.edu To: tcp-ip@nic.ddn.mil Cc: jkrey@venera.isi.edu, shlump.nac.dec.com!eagle1.enet.dec.com!brunner@decuac.dec.com Subject: re: How to get RFC documents dealing with TCP-IP
BOOTP (Bootstrap Protocol) RFCs 951,1048,1084
UDP (User Datagram Protocol) RFC 768
IP (Internet Protocol) RFC 791
======================================================================
RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login
with FTP, username ANONYMOUS and password GUEST. The NIC also
provides an automatic mail service for those sites which cannot use
FTP. Address the request to SERVICE@NIC.DDN.MIL and in the subject
field of the message indicate the RFC number, as in "Subject: RFC
nnnn".
RFCs can also be obtained via FTP from NIS.NSF.NET. Using FTP, login
with username ANONYMOUS and password GUEST; then connect to the RFC
directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1
(where "nnnn" refers to the number of the RFC).
The NIS also provides an automatic mail service for those sites which
cannot use FTP. Address the request to NIS-INFO@NIS.NSF.NET and leave
the subject field of the message blank. The first line of the text of
the message mist be "SEND RFCnnnn.TXT-1", where nnnn is replaced by
the RFC number.
Joyce K. Reynolds
USC/Information Sciences Institute
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 03:22:48 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: +--------------- | In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes: | > I hate to admit it, but the cell-phone (phone system) model of | > addressing does have many advantages for the *user*. No matter where | > you go, your logical address (phone number) follows you. | | In all of the cellular systems I've used so far, roaming is only half | automatic. In particular, to place a call to a roamer, you have to dial | the roamer access number for the area where they are, and then dial their | phone number. This amounts to source routing, which is even more of a | pain for mobile destinations than it is for "static" ones. Bleah. +--------------- In fact, most of the current cellular romaing systems are 3/4-automatic... ;-} Automatic for the roamer dialing out; that's half. But now many (most?) cellular companies offer a hack such that if you dial a person's cellular number in their home area *and* they're currently known to be roaming somewhere (they've placed a roming call within the last 24 hours), the home area system will give you an intercept recording which tells you they're out of area... *and* gives you the roamer access number where they are. Sort of an ICMP Redirect... ;-} ;-} -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 03:41:27 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Beginner's info TCP & UDP
In answering a beginner's question, hedrick@athos.rutgers.edu
(Charles Hedrick) writes:
+---------------
| People tend to use UDP where (1) they plan to be making isolated
| queries, such that the overhead packets used to set up and close a
| connection would form most of the traffic (2) they need more
| performance than they think they can get from TCP....
+---------------
I would add:
...(3) there are a very large number of clients accessing a single
server, such that the cost of holding a connection open for each
active client would be excessive. [The definition of "excessive"
is system- and application-dependent.]
In some sense this is the same as Hedrick's #1, except that #1 refers
to conserving dynamic network bandwidth, and #3 to conserving quasi-
static server system resources "wired-down" by connections (sockets,
open-file slots, processes, etc.).
-Rob
-----
Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com
Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94039-7311
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 04:44:17 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: ARP described, for newcomers
In article <2604@nems.dt.navy.mil> lumsdon@dtoa1.dt.navy.mil (Esther Lumsdon) writes: > ... NCSA's tcp/ip >for MS-DOS requires (inexplicably) that the VAX PING the PC in order >to get communications to work after both machines have rebooted. ... Sounds like an ARP problem. Probably a configuration error. (I have never used NCSA telnet, nor do I have an MS-DOS machine). In order for an IP datagram to travel from one system on an ethernet to another, it must contain the receiver's ethernet address (a unique 6-byte number). The upper level protocols do not know ethernet addresses; when the datagram makes it to the ehernet device driver, it looks in a special table to see if the ethernet address for the receiver's IP address has been discovered. If not, it THROWS AWAY the datagram, and instead sends a broadcast that means "I'm looking for IP address 1.2.3.4" and expects to get back a response that says "I'm 1.2.3.4 and my ethernet address is aa:bb:cc:dd:ee:ff". This information is now used to fill in the table. So when the higher level protocol (TCP) retransmits the lost segment, the table has been filled in. It is just barely possible that the NCSA program doesn't "do" ARPs, but fills in the table from information in received IP datagrams, such as the above mentioned PING. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 05:03:16 GMT From: grw@sun.com (Gregory Whitehead) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <64290@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com >(Amanda Walker) writes: >+--------------- >| In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes: >| > I hate to admit it, but the cell-phone (phone system) model of >| > addressing does have many advantages for the *user*. No matter where >| > you go, your logical address (phone number) follows you. >| >| In all of the cellular systems I've used so far, roaming is only half >| automatic. In particular, to place a call to a roamer, you have to dial >| the roamer access number for the area where they are, and then dial their >| phone number. This amounts to source routing, which is even more of a >| pain for mobile destinations than it is for "static" ones. Bleah. >+--------------- > >In fact, most of the current cellular romaing systems are 3/4-automatic... ;-} >Automatic for the roamer dialing out; that's half. But now many (most?) >cellular companies offer a hack such that if you dial a person's cellular >number in their home area *and* they're currently known to be roaming >somewhere (they've placed a roming call within the last 24 hours), the >home area system will give you an intercept recording which tells you >they're out of area... *and* gives you the roamer access number where >they are. Sort of an ICMP Redirect... ;-} ;-} Actually, GTE offers "Follow Me" Roaming in many foreign areas now. The roamer simply registers in the foreign area (by dialing *18) and all calls are forwarded automagically. It's pretty neat, but it sure can surprise your friends... ;-) -Greg
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 12:28:55 EDT From: perry@MCL.Unisys.COM (Dennis Perry) To: intercon!news@uunet.uu.net, tcp-ip@nic.ddn.mil Cc: perry@mcl.unisys.com Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
Date: 13 Jul 90 17:41:23 GMT From: intercon!news@uunet.uu.net (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA . . In all of the cellular systems I've used so far, roaming is only half automatic. In particular, to place a call to a roamer, you have to dial the roamer access number for the area where they are, and then dial their phone number. This amounts to source routing, which is even more of a pain for mobile destinations than it is for "static" ones. Bleah. Maybe Motorola's proposed satellite-based cellular system will be better. That's it! We put the core gateways into geosynchronous orbit... :-) -- Amanda Walker <amanda@intercon.com> Postmaster With An Attitude InterCon Systems Corporation _________________ Actually, thought along this line exist, i.e. put the gateways in the satellite. We thought of doing this at DARPA when I was there and we also explored such issues with the Multiple Satellite Program, an upto 200 node packet switched global communications network. With the demise of MILSTAR perhaps the light satellite concept will gain momentum. dennis
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 10:21:55 GMT From: hsi!stevens@uunet.uu.net (Richard Stevens) To: tcp-ip@nic.ddn.mil Subject: Re: UDP checksums
In article <1990Jul17.003242.1556@ultra.com> beau@ultra.com (Beau James writes:
>
>UDP checksums must be enabled on both sending and receiving
>machines before the software will compute and verify the
>checksum.
Newer systems should start conforming to the Host Requirements RFC (1122),
meaning the receiver has to honor a checksum that was set by the sender:
4.1.3.4 UDP Checksums
A host MUST implement the facility to generate and validate
UDP checksums. An application MAY optionally be able to
control whether a UDP checksum will be generated, but it
MUST default to checksumming on.
If a UDP datagram is received with a checksum that is non-
zero and invalid, UDP MUST silently discard the datagram.
An application MAY optionally be able to control whether UDP
datagrams without checksums should be discarded or passed to
the application.
/Richard Stevens
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 15:16:26 EDT From: lazear@gateway.mitre.org To: tcp-ip@nic.ddn.mil Cc: smcleod@mwunix.mitre.org Subject: IP Multicasting questions
In looking at IP multicasting (RFC 1112) and its potential use in a project of ours, a couple of questions came to mind: Is there a "reference" implementation? For SunOS or 4.3BSD? How can we obtain a copy? Is there any interest or work in progress to extend the registration protocol to allow 3rd party joins? That is, to convey the IP address of a system to be added to a multicast address. We are thinking of a coordinating system that would best know which slave systems should be in which groups and would register and deregister them appropriately. Thanks in advance for any help. Walt Lazear MITRE Corp.
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 14:52:53 GMT From: hpcc01!hpcuhb!hpsqf!hpopd!ian@hplabs.hpl.hp.com (Ian Watson) To: tcp-ip@nic.ddn.mil Subject: TCP Port state FIN_WAIT_1 : what's that ?
I sometimes get a hang for a long while (say an hour) when I have a client close a sockets connection. The server (SCO Unix 3.2) shows the TCP port state according to 'netstat -i' as being FIN_WAIT_1 before the connection eventually dies completely. The server program has gone away at the time the connection close was requested by the client, so I guess it's just at the TCP level that the connection is almost closed but not quite. Anyone any ideas ? Ian Watson ian@hpopd.HP.COM hplabs!hpopd!ian
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 16:22:37 GMT From: obrien@aeroaero.org (Michael O'Brien) To: comp.protocols.tcp-ip Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <139016@sun.Eng.Sun.COM>, grw@cabernet.Eng.Sun.COM (Gregory Whitehead) writes: |> In article <64290@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: |> >In article <269E07C3.604D@intercon.com> amanda@mermaid.intercon.com |> >(Amanda Walker) writes: |> >+--------------- |> >| In article <153@tots.UUCP>, tep@tots.UUCP (Tom Perrine) writes: |> >| > I hate to admit it, but the cell-phone (phone system) model of |> >| > addressing does have many advantages for the *user*. No matter where |> >| > you go, your logical address (phone number) follows you. |> >Automatic for the roamer dialing out; that's half. But now many (most?) |> >cellular companies offer a hack such that if you dial a person's cellular |> >number in their home area *and* they're currently known to be roaming |> >somewhere (they've placed a roming call within the last 24 hours), the |> >home area system will give you an intercept recording which tells you |> >they're out of area... *and* gives you the roamer access number where |> >they are. Sort of an ICMP Redirect... ;-} ;-} |> |> Actually, GTE offers "Follow Me" Roaming in many foreign areas now. |> The roamer simply registers in the foreign area (by dialing *18) and |> all calls are forwarded automagically. The non-wireline services in California have recently banded together to permit this in an even easier fashion, as I recall. As best I can figure out, they must all send any roamers who've acquired the system in to a central clearinghouse all the time; anyone who calls your number back in your home area gets forwarded to you ALL THE TIME, unless you SPECFICALLY send a code that turns the service OFF. The manual warns that you'd better cancel this (or it self-cancels at midnight) when you return home or you won't get any calls THERE, either. Now THAT'S an ICMP redirect. -- Mike O'Brien obrien@aerospace.aero.org
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 16:39:49 GMT From: davel@vision.UUCP (Dave Lockwood) To: comp.protocols.tcp-ip Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <1990Jul16.234452.29721@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >Not in New Zealand. Cell phones have their own area code which covers the >country. All cell calls cost the same per minute regardless of distance >(which is cheaper than the most expensive 'normal' toll step.) >As part of testing they placed a call, got in a plane and flew the length >of the country, keeping the circuit up during the entire journey. >(OK, so NZ is small, but it is bigger in area than the U.K. which does >require area access numbers). Sorry, the UK does _NOT_ require area access numbers on celluar! As far as I know there are three "area" codes - 0860 (which is for phones on the Cellnet network) and 0836/0831 which are for phones on the Vodafone network. I have one of the latter, and can be called anywhere in the UK (where there is service) by dialling the _same_ code+number. This "network" code is often confused as an "area" code...it isn't. -- -------------------- I'm totally incommunicado, except for --------------------- Dave Lockwood ...!uunet!mcsun!ukc!vision!davel davel@vision.uucp Technical Consultant ...!uunet!bulus3!bungia!vware!davel davel@vware.MN.ORG VisionWare Ltd, G4CLI@GB7YHF.194.GBR.EU dave@g4cli.ampr.org 57 Cardigan Lane, D.LOCKWOOD@ICLX davel@vision.co.uk Leeds, LS4 2LE, +44-532-788858 +44-831-494088 United Kingdom +44-532-304676 "Hey, You!" ----------------------- VISIONWARE DOS/UNIX INTEGRATION ------------------------
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 16:55:40 GMT From: manoj@xlnvax.novell.com (manoj @ Prod Mktg) To: news.groups,comp.os.os2,comp.protocols.tcp-ip,news.announce.newgroups,comp.protocols.iso,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.dcom.lans,comp.protocols.ibm,comp.protocols.pcnet Subject: SECOND CALL FOR VOTES comp.sys.novell
[This group did not follow creation guidelines because there was no
call for discussion for comp.sys.novell in news.announce.newgroups.
There also currently exists a trial newsgroup named
trial.comp.sys.novell.-eliot]
*** PLEASE READ THIS ENTIRE MESSAGE BEFORE REPLYING ***
This is the second call for votes for creation of a new group
comp.sys.novell
This group will be self-moderated. This basically means that flamers and
obnixious people will be ignored by the rest of us.
The voting period will last until 11:59 PM on Aug 10, 1990.
Charter for comp.sys.novell
---------------------------
A forum to discuss technical and non-technical issues specific to
the Novell's Netware family of Local Area and Wide Area Networking products.
These include ELS NetWare, Netware286, Netware386, Portable Netware,
Communication products, Database products, Development API's,
LAN WorkPlace family (TCP/IP) etc. etc. thus reducing the amount of time and
multiple postings on multiple groups on protocols, lans, dcom, ibmpc, tcp-ip etc
Examples of topics to be discussed in this newsgroup include:
"What are the networking cards, _____, certified for NetWare 386"
"What's wrong with this ___ code?,
"What toolkit calls, ______ are available?"
"Has anyone managed to hook up a ___ successfully?"
"What is the official, Novell-sanctioned method of doing ___?"
"What are the specs for ___ file format?"
"What applications are compatible on a _____ NetWare System?"
Examples of topics NOT to be discussed in this newsgroup include:
"For sale: ___"
"New product announcement: ___"
"Novell's financial situation is ___"
-----------------------------------------------------------------------------
HOW TO VOTE
-----------
To cast a vote, send a mail message to manoj@novell.com with either of
the following subject lines:
TO VOTE YES:
Subject: comp.sys.novell = YES
TO VOTE NO:
Subject: comp.sys.novell = NO
THE BODY OF THE MESSAGE WILL BE IGNORED. Nothing placed in the body will
be used in counting votes.
No vote with an incorrect subject line will be counted!
ONLY votes MAILED to manoj@novell.com will count. Votes posted to the net
for any reason (including inability to get mail to manoj@novell.com) and
proxy votes (such as having a mailing list maintainer claim a vote for
each member of the list) will not be counted.
_______________________________________________________________________
+---+
manoj goel, | +-+-+
Product Marketing +-+-+ |
Excelan/Novell, San Jose, CA +---+
(408) 473-8369 (voice) / 433-0775 (fax) / manoj@novell.com
___________________________________________________________________________
>From manoj@excelan.COM Thu Dec 21 08:37:17 1989
Path: excelan!ames!ncar!announce-moderator
From: manoj@excelan.COM (manoj @ Prod Mktg)
Newsgroups: news.announce.newgroups,news.groups,comp.protocols.ibm,comp.protocols.nfs,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix,comp.dcom.lans,comp.os.os2,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix
Subject: CALL FOR DISCUSSION ' comp.sys.netware'
###################
CALL FOR DISCUSSION
###################################
comp.sys.netware
###################################
Why add a new group?
A forum to discuss technical and non-technical issues specific to
the Novell's Netware family of Local Area and Wide Area Networking products.
These include Netware286, Netware386, Portable Netware, Communication products,
Database products, Excelan LAN WorkPlace family (TCP/IP) etc. etc.
The creation of this forum will allow the Novell Netware enthusiasts
at USENET their own forum to discuss items of a non-technical nature
(how to use software packages, what networking card to buy, etc)
and items of a technical nature (what's wrong with this code?, how do I use
this toolkit call?, etc.), thus reducing the amount of time spent sorting
through multiple groups on protocols, lans, ibmpc, tcp-ip.
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 17:07:28 GMT From: murthy@la.excelan.com (M.D. Srinivas Murthy) To: comp.protocols.tcp-ip Subject: Re: Beginner's info TCP & UDP
One important reason to use UDP is when broadcasting is needed. You cannot send a broadcast packet with TCP. (One example: rwho) Further if an application is designed as a state-less machine (like NFS) one has to use UDP. -murthy
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 17:17:19 GMT From: sgi!shinobu!odin!ajit@ucbvax.Berkeley.EDU (Ajit Mayya) To: tcp-ip@nic.ddn.mil Subject: Re: ARP described, for newcomers
In article <1990Jul17.044417.17807@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>number). The upper level protocols do not know ethernet addresses; when
>the datagram makes it to the ehernet device driver, it looks in a
>special table to see if the ethernet address for the receiver's IP
>address has been discovered. If not, it THROWS AWAY the datagram,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
No it doesn't. Atleast BSD based systems have a slot for hanging
on to atleast one packet in the arp table entry. When the entry
gets resolved, the packet is sent. Ofcourse, if it looks like there
is going to be no incoming reply (after 3 retransmissions or whatever)
the packet if freed up. Typically ARP resolution takes at most the
order of milliseconds, and the packet is on its way without waiting
for any retransmissions etc.
If two packets are sent to the same unresolved IP destintation,
the first one will be queued. When the second one comes along, the
first is dropped and the second is queued and so on and so forth.
I haven't looked at the Host Requirements Document lately, but I
think it requires implementations to hang on to atleast one packet.
-----------------------------------------------------------------------------
Ajit Mayya Silicon Graphics Inc., Advanced Systems Division
ajit@asd.sgi.com Any opinions expressed above are mine, not SGI's
-----------------------------------------------------------------------------
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 00:17:25 EDT From: Bruce Crabill <BRUCE@UMDD.UMD.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: RFC1168
I'd hate to be the first to drag out the PostScript RFC soap box again, but
RFC1168 uses LaserWriter specific non-standard PostScript features (the
now infamous "letter" command). I can't print it on our LPS40 printer.
Bruce
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 08:34:38 -0700 From: mmeadows@qualcomm.com (Mike Meadows) To: tcp-ip@nic.ddn.mil Subject: POP3 Client for the PC.
I am looking for a client for the PC that uses the POP3 protocol. I have read about the existence of such programs, but I have been unable to locate one. Any help would be greatly appreciated. Michael Meadows Qualcomm Inc. mmeadows@qualcomm.com
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 22:18:45 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.protocols.tcp-ip Subject: Re: Beginner's info TCP & UDP
In article <Jul.16.21.14.16.1990.26321@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >People tend to use UDP where (1) they plan to be making isolated >queries... (2) they need more >performance than they think they can get from TCP... Doesn't it also get some use for things like packet voice, where timely unreliable delivery is better than unpredictably-delayed reliable delivery? Agreed that the basic answer is "use TCP unless you have a very good reason for UDP". If nothing else, it's much easier to get a high-quality implementation by using a pre-built one than by building it yourself. -- NFS: all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology and its performance and security too. | henry@zoo.toronto.edu utzoo!henry
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: Tue, 17 Jul 90 23:38:24 GMT From: Mills@udel To: bellcore-2!envy!karn@bellcore.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
Phil, MSS was to put up 240 satellites in 800-km orbits by flinging them from the Shuttle at odd moments. They were to have steerable antennas and operate at Etherspeeds. Assuming random (!) orbit inclinations, a ground station would see about five satellites at a time and a satellite would see about 35 other satellites at a time. The average crosslink between the satellites would be about ten minutes. For homework tonight, you get to design the crosslink acquisition and routing algorithm. You also get to figure out how a new satellite not knowing the orbit elements or ephemeris of the other satellites finds its friends with a 5-degree beamwidth antenna. There will be a test in the morning. Open book. Oh, I forgot. The system is power-limited. The best routing may be achieved with minimum-power routing, rather than minimum-distance. In other words, take the usual linear metric (like hop count or delay) and square it. Then construct the minimum path. Surprising things happen, like this can result in the MAX number of hops, rather than the usual MIN. I worked on the project for a short while, but have not seen the final report. However, my simulations showed that the degree of connectivity quickly blows away SPF algorithms and blows everything away with min-power routing. Iridium is a rare metal probably ill used to build satellites with. You may remember the ill-fated XTEN network that could be described as an Ethernet radio operating at 10 GHz for metro-area coverage. Are we now seeing XTENs in the sky? Dave
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 00:38:52 GMT From: fanj@remb6489.wpd.sgi.com (Fan Jiao) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Info on Telnet 3270 needed
Does somebody know there are companies that ported Telnet 3270 into Apollo's, DEC's, HP's, Sun's workstation, or MS-DOS machines? If so I'd appreciate any information on the product. Thanks much in advance. -- - Fan Jiao
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 09:53:11 -0400 From: barns@gateway.mitre.org To: dscott@gateway.mitre.org Cc: tcp-ip@nic.ddn.mil, barns@gateway.mitre.org Subject: Re: GOSIP and X.25
You probably saw Darrel B's message - What do you think of this set of
answers? /Bill
-------------------------------------------------------------------------
Guess I'll take a shot at this set of questions.
1. Is it possible or practical to run both TCP/IP and GOSIP protocols
over a single X.25 interface? Over a single Ethernet interface?
It is possible and practical if the implementor/vendor goes about it
properly. This is very simple to do once one has gotten a firm grip
on the idea that it ought to be done. There has been at least one
case of a vendor creating TCP/IP and OSI products that discombobulate
each other's X.25 interface, but I'm told that they know better now.
Separate virtual calls/circuits should be used for IP and OSI-CLNS
PDUs. In the (normal) case of switched virtual calls, the called end
distinguishes calls on the basis of the protocol identifier as
described by CCITT X.244 and ISO TR 9577. The OSI Network layer
protocols have distinct protocol identifiers embedded in the PDUs
(first octet) and further break-out of protocols within the family of
CLNS protocols is supposed to be done on the basis of those protocol
identifiers. So, if for example the traffic between points A and B
consists of (DOD) IP, (OSI) CLNP, and (OSI) ES-IS, there should be
one or more distinct VCs carrying DOD IP, and one or more other VCs
carrying CLNP and ES-IS. Yes, CLNP and ES-IS can be mixed on a
single VC, according to standards. There is an issue with this relating
to military encryption gear which I'll discuss separately. If there
were also OSI CONS communications going on, these would use one or more
VCs of their own also.
The Ethernet situation is convoluted to describe because of the variants
of link frame formats ("Ethernet" vs "802.3") but the principle is the
same. For full interoperation, both frame formats must be recognized,
following which the protocol identification can be found in the right
places.
Since the VCs are "typed" to a higher-layer protocol (or family of them),
it isn't necessary to parse the PDUs to tell DOD IP from OSI. The OSI
implementation has to do the right thing about parsing the NPDU and
processing it as CLNP, ES-IS, or whatever.
Yes, a host using X.25 has to have some kind of VC data structure with
upper-layer context information. This was needed anyway for a valid
IP-over-X.25 implementation; it had to keep track of which VCs were
connected to which destinations, and it was supposed to also keep track
of the precedence level, and match up traffic accordingly. Adding one
more matching criterion (protocol family) isn't a big deal in principle.
Re military E3: There is a problem with ES-IS in an MLS environment
because it doesn't carry a label. Therefore it isn't considered
legitimate to put it on a "multilevel VC" to coin a phrase. Therefore
the multiplexing rules in an MLS device must be different. Therefore
the MLS crypto box has to know which set of rules you are playing by
at a given moment. Therefore it is necessary to have a different
protocol ID for the two cases if a single crypto box is to handle both
kinds of attached device. After considerable discussion, it was
concluded that the standard protocol ID for OSI CLNS should be used for
the case where the normal OSI CLNS rules apply, and a different one to
signal the case where non-labeled PDUs won't be passed. Hex 81=Normal,
Hex CD=MLS. Phase I BFE supports neither, Phase II will support CD,
Phase III will support both. (All BFEs support DOD IP using Hex CC.)
I suspect there are still some issues to be sorted out with MLS routing
in general.
2. MILNET addressing for OSI hosts
There are really two questions here - NSAP addresses and NSAP/SNPA
mapping. I don't think there has been a public pronouncement on
NSAP address assignment but the general drift of the most recent
discussions I know of was essentially a straight GOSIP Version 2
addressing situation. Regarding mapping, GOSIP requires that you
be able to configure static routes based on left subsets of NSAPs.
ES-IS is required to be available in the implementation, so you can
presumably find or set up some IS with the right information and
use that as a routing server for some set of ES's. OSI routing
protocols are still not in concrete, but DP 10589 is probably a
fairly safe bet for intra-domain routing.
3. Will there be an algorithmic derivation for X.121 addresses?
This is subnetwork dependent. I don't think there is any expectation
that MILNET will ever be based on that type of scheme for OSI purposes
(unlike the IP case). I believe that you should plan on using OSI
routing protocols to the extent available, and static mappings of
left subsets of NSAPs otherwise.
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 10:17:30 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) Cc: tcp-ip@nic.ddn.mil Subject: Re: ARP described, for newcomers
Not all ARP implementations "throw away" the IP datagram that initiates the ARP broadcast request; ours (and other PCIP derived DOS TCP/IPs) certainly don't. Saving the IP datagram is a SHOULD in RFC 1122. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 10:17:31 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: morgan@jessica.stanford.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
From: agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU (RL "Bob" Morgan)
Subject: Zero manufacturer code in SNAP?
The 40-bit SNAP extension to IEEE 802.2 specifies a 24-bit
"organizationally unique identifier" that is apparently supposed to be
the same 24 bits that a manufacturer uses to form the upper part of a
48-bit unique IEEE 802 MAC address. The other 16 bits are assigned by
the organization in any way it sees fit.
The IEEE 802.2 document actually specifies the SNAP extension header as
the 3-byte OIU only. RFC 1042 is where the extra two bytes come from,
and the authors chose to put a DIX Ethertype there. They could have put
the beginning of an IP packet there instead, or their initials...
The question is, has the all-zeros SNAP id been assigned by IEEE to
DoD, or the IAB, or some IP authority, to be administered by that
authority? Or is the all-zeros id just a general purpose format for
translating Ethernet frames to 802.2/SNAP, to be used by anyone?
They way I've heard it (I hope I'm right enough that Jon is saved a
post) the "all zeroes" OUI was owned by Xerox from the beginning.
When RFC 1042 was being worked out, the SNAP header was the only way
to run IP on 802.2 networks, because of our inability to obtain a SAP
value for ARP (one has been assigned for IP). So, the authors went
looking for an OUI, and Xerox was forthcoming.
Yes, you can put Ethertype 809b into those two bytes and Appletalk away.
You might want to look at a paper by Roger Pfister, "Bridging Ethernet
Frames - Which OUI?", which can be found as pub/msb_vs_lsb/661-062.txt
on vax.ftp.com.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: Wed, 18 Jul 90 10:17:38 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: hedrick@athos.rutgers.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Why does a wrong broadcast address cause arp-havoc?
RFC 1122 says that 1) machines with only one IP address shall not act as routers by default, 2) nobody shall forward or issue ICMP error messages in response to packets that arrive via an IP or MAC level broadcast, and 3) that everyone must be cognizant of the old 4bsd IP broadcast address as well as the correct (RFC 950) one. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 08:02:20 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
morgan@jessica.stanford.edu (RL "Bob" Morgan) writes: +--------------- | The question is, has the all-zeros SNAP id been assigned by IEEE to DoD, | or the IAB, or some IP authority, to be administered by that authority? +--------------- My understanding, which has no more authority in this case than "urban legend" (and should probably be taken with the same degree of confidence), is that the 24-bit "organization" identifier was not originally intended to be identical with the upper 24 (well, 23) bits of some assigned MAC address, but was to be a separate space assigned/managed by IEEE. (The obvious hack of making it be the same as a manufacturer's 23-bit unique MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns them?] After all, it *is* possible that a manufacturer could make more than 2^24 network interfaces and need some more addresses, so why mix SNAP IDs with MAC addresses?) So organizations had to request/register SNAP "organization IDs", and Xerox Corporation [who at Xerox?] asked for(?) / was assigned(?) [by whom?] the zero code. Xerox then said to the world, "We hereby state that we're going to use the Xerox-registered Ethernet types..." [remember that Xerox still has the registry for *Ethernet* type codes] "...in the 16-bit reserved-for-org- anization field of SNAP organization code #0 (== Xerox), and we invite any and all to do likewise". And so at an after-dinner session at the Monterey TCP/IP Conference [the First, or maybe Zero-th, Interop Conference], the "TCP/IP community" [the people in that room, at least] agreed to cease using the LSAP code that had been assigned by IEEE for IP, and agreed to use SNAP Org. Code 0 + EtherType on 802.2 links and FDDI, in order to have not only IP but ARP and BOOTP and RARP, etc. [The term "SNAPpy Xerox" was sometimes used as an irreverant handle for this encoding, until RFC-1042 came out.] Anyway, that's the way I heard it. I invite correction/historical_revision by any who have more authoritative sources/memories. [Won't take much to be more authoritative than the above... ;-} ] -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 14:47:13 GMT From: glratt@rice.edu (Glenn Forbes Larrett) To: tcp-ip@nic.ddn.mil Subject: Re: Info on Telnet 3270 needed
As far as MS-DOS machines go, NCSA has FTP Software
a PD 3270 emulator out and FTP Software's -->26 Princess Street
PC/TCP package has one as well. Wakefield, MA 01880
(617)-246-0900
Glenn Larratt glratt@uncle-bens.rice.edu
Computing Resource Center OCIS, Rice University
Glenn Larratt glratt@uncle-bens.rice.edu
Computing Resource Center OCIS, Rice University
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 14:52:15 GMT From: mcsun!cernvax!chx400!ethz!flog@uunet.uu.net (Florian Gutzwiller) To: tcp-ip@nic.ddn.mil Subject: SL/IP ?
Who has experience with SL/IP on CONVEXes and Stardent Titan ? I will summarize upon request. Florian A. Gutzwiller phone: +41 1 256 3542 Communication Systems Department fax: +41 1 261 5389 Swiss Federal Institute of Technology inet: flog@ks.id.ethz.ch Zurich, Switzerland uucp: flog@ethz.UUCP
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 15:11:56 GMT From: usc!sdd.hp.com!samsung!cs.utexas.edu!texbell!nuchat!abbadon@ucsd.edu (David Neal) To: tcp-ip@nic.ddn.mil Subject: FDDI - a call for sources
Hello,
I'm looking for any and all information regarding FDDI.
Technical specs, hardware vendors, etc etc.
We want to implement an FDDI backbone with 10 megabit drops
to building backbones. Optimally, the FDDI ring would be
on microwave instead of fiber between NASA and us, as
they are across the highway. Literally.
Thanks.
--
David Neal
abbadon@nuchat.uucp
abbadon%nuchat@{rice, bcm, texbell, uunet}
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 16:00:33 GMT From: usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@ucsd.edu (Peter Murray) To: tcp-ip@nic.ddn.mil Subject: Network routing to/from a SLIP connection
I have what appears to be a network routing problem. If not, please point me in the right direction. We just hooked up a SLIP connection between an IBM PC running KA9Q (the release is a couple of months old, I'm not sure of the version number) and a MicroVAX II running Ultrix 3.1. Believe it or not, the connection from the PC to the MicroVAX works! (It took many long weeks to get there.) :-) This is the problem: packets sent from the PC to anywhere but the MicroVAX do not appear to be forwarded to the ethernet network. Packets from the network do not appear to be forwarded to the PC. It seems like the connection is only valid for the PC and the MicroVAX. The setup: we have a Class B network with a broadcast of 134.53.3.255 and a subnet mask of 255.255.255.0. The Ultrix box is the domain name server for the subnet, but the PC's address is not in the tables. I've been using it's IP address to test the connections. We are running 'routed' (this was suggested by someone here as a possible problem). Solutions already tried: A friend of mine suggested that there was a problem with the SLIP protocol that was fixed if the SLIP machine was on a subnet by itself. I changed the IP address of the SLIP connection so that it was in a different (unused) subnet, but this did not help. I also looked for RFCs, but the only one I found dealing with SLIP (RFC 1055; "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP") was of no help. DEC does not support SLIP, so the Ultrix manuals haven't been very good. I would very much like to hear how this has been solved at other sites. SLIP seems to be a popular problem, and I will post a step-by-step method of how I did it when (IF?) I can solve this one last problem. Thanks in advance for your help... Peter -- Peter Murray Neat UNIX Stunts #4: pemurray@miavx1.bitnet 215 Foxfire Dr #308 csh> \(- murrayp@apsvax.aps.muohio.edu Oxford, OH 45056 NeXT Mail: pmurray@next4.acs.muohio.edu 513/523-5994
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 16:54:57 GMT From: joymrmn!root@uunet.uu.net (Marcel D. Mongeon) To: tcp-ip@nic.ddn.mil Subject: Excelan Lan Workplace and Packet Drivers?
I have an Excelan 205T board in an SCO Xenix 386 machine supporting the Lan Workplace software. The board is hooked up to a thinwire ethernet. I have been trying (without any success) to get some DOS based machines talking to this board using other vendor's boards driven by appropriate packet drivers. I try both NETBIOS and FTP style calls to the Excelan board and it doesn't respond. The Excelan board is receiveing the packets because any of the appropriate stat commands done before and after an attempted link indicates that the excelan received packets -- it just didn't do anything with them! I think that I am probably screwing up the IP and Ethernet addresses. Any suggestions? -- ||| Marcel D. Mongeon ||| e-mail: ... (uunet, maccs)!joymrmn!root or ||| joymrmn!marcelm
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 17:58:27 GMT From: venus!yalevm!maine!shanley@CS.YALE.EDU To: tcp-ip@nic.ddn.mil Subject: Telnetd daemon doesn't get started
Equipment: AT&T 3B2-400
Unix V 3.1
Wollongong TCP/IP WIN*/3B Interface Rel 3.0.1
Problem: Can telnet out of the machine but can't telnet in.
ie. telnet me and telnet umofm.umeofm.maine.edu
doesn't work.
ftp and ping are fine and telnet out of umofm is fine.
My senerio: It seems that the telnetd daemon/server is not getting
started. I have played with the nlsadmin command with
the following results:
nlsadmin -x tcp INACTIVE
nlsadmin -i net_spec already initializied
nlsadmin -s addresses not initializied for tcp
I reloaded the software and I get the following error
upon starting the network software:
nlsadmin: addresses not initializied for tcp
Any and all help would be appreciated. Thanks!
Kevin Shanley
System Administrator
Office of Facilities Management
University of Maine
Orono, Maine
shanley@umofm.umeofm.maine.edu
shanley@maine.caps.maine.edu
207-581-2681
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 01:24:12 PDT (Thu) From: root@asylum.sf.ca.us (Super user) To: knowledge!pclark@genbank.bio.net Cc: tcp-ip@nic.ddn.mil Subject: Beginner's info TCP & UDP
UDP has a lot less overhead than TCP. For simple transaction-based protocols (request-response) that don't carry much data, UDP is much simpler to use. TCP would have the additional overhead of setting up and tearing down its connection, whereas UDP sends the request and response and doesn't care about the ret. In request-response protocols based on UDP, you have to worry about three main things: what happens if a packet gets lost (solution: set a timer and retransmit), what happens if you resend the request and its action gets duplicated (solution: be careful about your protocol design, or put sequence numbers in the packets), and what happens if your data doesn't all fit in one packet (solution: IP fragmentation, or split it across packets, or you lose). Splitting data across UDP packets is often a good reason to start using TCP, since it already has a lot of mechanism in it for dealing with this issue. Not many applications use UDP for transferring lots of data. Those applications are normally TCP-based. However, UDP is very convenient for applications wishing to use a bulk data transport protocol with different behaviour from TCP. This kind of work would be mostly experimental, though. SNMP, the main network management protocol for the Internet, is layered on top of UDP. One advantage to this is that it allows those vendors that might provide SNMP in their products that would otherwise have no (IP) protocol stack (like an ethernet hub) to include SNMP without having to implement a full TCP. While getting a TCP implementation running today is easier than it was several years ago, UDP is orders of magnitude simpler. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "There is no loyalty except loyalty to the party. There is no love except love of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 19:54:15 GMT From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!hagan@ucsd.edu (John Dotts Hagan) To: tcp-ip@nic.ddn.mil Subject: IBM VM TCP/IP GDDMXI
test --Kid.
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 19:58:38 GMT From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!hagan@ucsd.edu (John Dotts Hagan) To: tcp-ip@nic.ddn.mil Subject: IBM VM TCP/IP GDDMXI
We are trying to run GDDMXI under IBM VM TCP/IP FAL 1.2.2. Has anyone gotten it to work? I cannot get the demos to run (ex, GXDEMO1). The problem we have is the remote X server (a DECstation 3100 running Ultrix 3.1D and the DEC X server), cannot find the default font that the GDDMXI is trying to use, ROM20.500. When I edit the X DEFAULTS file on the VM system, as instructed, and configure it to use a font on my DECstation: gddmx*Hwdfont: fixed I get the same error about the ROM20.500 font! I don't think it is reading the X DEFAULTS file at all! If you have it working, and are willing to help, please send me mail and include a phone number so we could compare our system with yours to find out what we have wrong on our end! Thanks! --Kid. (215) 898-9192
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 20:06:13 GMT From: brian@ucsd.edu (Brian Kantor) To: tcp-ip@nic.ddn.mil Subject: Unix POP3 mail client?
Any pointers to source for a BSD Unix POP3 mail client? I've found several servers, but no clients. - Brian
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 20:29:04 GMT From: van-bc!sl@ucbvax.Berkeley.EDU (Stuart Lynne) To: tcp-ip@nic.ddn.mil Subject: Streams buffers under TCP/IP
We're just installed BIND 4.7 under SCO Xenix TCP/IP. All is running well except that we are getting the occasional message from the kernel indicating we need to allocate more streams buffers. Does anyone know how to list the high water marks for streams buffer usage? I'm sure there is a program to do it, I remember doing it last year. But can't find the program. (That's the wonderful thing about Unix, there is a program for everything.. if you can remember where the bloody thing is..) I've looked the all my FM's but can't find anything. For anyone out there running a Xenix site hooked up to the internet you will probably want to get the new bind running. It works a lot better than the stock version. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 21:10:10 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu (Mark Crispin) To: tcp-ip@nic.ddn.mil Subject: Re: Unix POP3 mail client?
In article <15720@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: >Any pointers to source for a BSD Unix POP3 mail client? I've found several >servers, but no clients. - Brian I don't know about POP3 clients, but there is a Unix IMAP client and server on FTPHOST.CAC.WASHINGTON.EDU as pub/imap.tar.Z. _____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105 _|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!" |_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?" --|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin." /|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou" / | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 21:45:52 GMT From: daffy!gumby.cs.wisc.edu!upl@speedy.wisc.edu (Undergrad Projects Lab) To: tcp-ip@nic.ddn.mil Subject: Looking for POP2 server source
Hi all! I'm interested in finding a pop2 (Post Office Protocol - version 2) server. I have found a pop3 server and I have it working -- This is good. However I have an application that is a pop2 client that I don't want to re-write. Any information on an FTP location of said software would be greatly appreciated. Thanks, - Mark P.S. PLEASE PLEASE PLEASE do NOT respond to the account from which this article is being posted. Instead, use the following account: mark.horn@mail.admin.wisc.edu -or- harier!sparkie@cs.wisc.edu Thanks, again
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 18 Jul 90 23:08:44 GMT From: van-bc!sl@ucbvax.Berkeley.EDU (Stuart Lynne) To: tcp-ip@nic.ddn.mil Subject: sw (was Re: Streams buffers under TCP/IP)
In article <918@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes: >Does anyone know how to list the high water marks for streams buffer usage? >I'm sure there is a program to do it, I remember doing it last year. But >can't find the program. (That's the wonderful thing about Unix, there is a >program for everything.. if you can remember where the bloody thing is..) >I've looked the all my FM's but can't find anything. My aged synapses finally came through... it's called "sw" which presumably stands for stream watch. Now the 64k$ question is does anyone have any detailed information on what sw does? I've got my problem fixed (up'd the number of 128 and 256 byte buffers) but while I'm looking it would be interesting to figure out what the other things that sw is telling us about *really* mean. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Jul 90 2:54:58 GMT From: Mills@udel To: jbvb@vax.ftp.com Cc: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: ARP described, for newcomers
James, Harrumpth. I'm glad for you and add fuzzballs to the list of ARP-keepers. There is at least one protocol (NTP) that ratchets poll interval up to 17 minutes. There is at least one vendor (*) that caches-out ARP entries every 14 minutes. There is at least one sucker who spent some days chasing that bog down. Read your SHOULD as REALLY, REALLY SHOULD. Dave
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 07:06:00 EDT From: "RANDY CATOE" <randy@TWG.COM> To: "qualcom!jwn2" <qualcom!jwn2@ucsd.edu> Cc: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: RE: WIN/TCP for VMS 5.1 NTYDRIVER bug
Date sent: 19-JUL-1990 07:03:30 >From: ECOVAX::WINS%"<qualcom!jwn2@ucsd.edu>" 18-JUL-1990 07:47:52.83 >To: RANDY >CC: >Subj: WIN/TCP for VMS 5.1 NTYDRIVER bug >Date: 12 Jul 90 06:45:10 GMT >Subject: WIN/TCP for VMS 5.1 NTYDRIVER bug >Message-Id: <2706@qualcom.qualcomm.com> > >When users paste long segments of text from one Mac application into a Telnet >window open to a VAX, the VAX regularly loses portions of the text. I traced >this to improper coordination between NTYDRIVER and TTDRIVER in VMS, and >reported the problem to Wollongong. TTDRIVER tries to xoff NTYDRIVER, but >NTYDRIVER ignores the request, throwing down characters while TTDRIVER catches >its breath. > >When I called Wollongong's technical support, the guy I talked to mumbled >something about "oh that problem...review committee...mumble-mumble-mum..", >but that was 6 months ago. > >Does anyone know if a patch exists for this? I apologize if I'm bringing up >old news, but I've still got the bug, and I'm not getting any younger... > >Thanks from this poor, stranded luser in VMS-land! We do indeed have a fix for this problem.I have arranged for it to be sent to you immediately. Please accept my apology for any delay that we may have caused in responding to you. Randy Catoe The Wollongong Group, Inc.
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Jul 90 08:11:13 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> To: tcp-ip@nic.ddn.mil Subject: VAX ping & NCSA Telnet
>Thanks for all responses. It has become a moot point. NCSA's tcp/ip
>for MS-DOS requires (inexplicably) that the VAX PING the PC in order
>to get communications to work after both machines have rebooted. We
>are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited
>this strange behavior.
I would sure like to see an explanation of this. We use NCSA here on all
our connected PCs and we DO NOT have ping enabled on the VAX.NCSA doesn't
do anything different here than any other host on the network. I can't
imagine why ping would be necessary on the VAX.
Can you elucidate???
bill gunshannon
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Jul 90 11:42:51 CDT From: stanley@visual1.tamu.edu (Stanley Guan) To: tcp-ip@nic.ddn.mil Subject: remove me from this list
Please remove me from this list! Thank you!
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 06:46:38 GMT From: barmar@think.com (Barry Margolin) To: tcp-ip@nic.ddn.mil Subject: Re: UDP checksums
In article <1812@hsi86.hsi.UUCP> stevens@hsi.com (Richard Stevens) writes:
>In article <1990Jul17.003242.1556@ultra.com> beau@ultra.com (Beau James writes:
>>UDP checksums must be enabled on both sending and receiving
>Newer systems should start conforming to the Host Requirements RFC (1122),
>meaning the receiver has to honor a checksum that was set by the sender:
The question was specifically about enabling checksums in current BSD
systems, in which case the caveat is correct. Is this bug fixed in 4.4bsd?
Also, if the systems were conforming to the HR RFC it wouldn't be necessary
to turn on UDP checksums. I believe the RFC also specifies that they MUST
be enabled by default, and SHOULD provide the ability for the application
or system administrator to disable them.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 12:17:00 EST From: "Murl McRae" <mcrae@mk6vms.nwscc.sea06.navy.mil> To: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: RE: WIN/TCP Window Size
As requested by BILLW@mathom.cisco.com on 19-JUL-1990 08:31, here is
more information on my WIN/TCP window size question:
The reason I wanted to change the window size was to see if that
would improve our Internet performance. We have a very slow Internet link.
The average roundtrip time is around 1.5 seconds. Our FTP transfer rate is
only about 9.6K bits/sec. With the long roundtrip time we thought a larger
window might help increase FTP throughput so we wanted to change the window
(both send and receive) and run some tests.
Since I posted the orginal message I have found out how to change the
window sizes. I changed the sizes from 4096 to 8192 and we tried a few
transfers. The results were inconclusive. I don't think the performance
changed. I did notice that all of the other hosts in the test had receive
windows around 4K (obviously I am rather green at this stuff), so if we did
get any improvement it would be in one direction only. So it looks to me
like I ought to return the window sizes to 4096 and leave them alone.
Any other sugguestions on improving performance on a slow link would
be appreciated. Our current link into MILNET is via sattelite. We are
working on getting a land line, but that may take a while. Thanks.
Murl McRae Naval Weapons Support Center
Crane, Indiana
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Jul 90 15:14:19 -0400 From: George Williams <gwilliam@SH.CS.NET> To: Ian Watson <hpcc01!hpcuhb!hpsqf!hpopd!ian@hplabs.hpl.hp.com> Cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: TCP Port state FIN_WAIT_1 : what's that ?
Hello,
The close sequence in TCP is a symetrical exchange. That is the side issuing
close generates the following protocol exchange:
close initiator TCP close receipient
----------------- ------------------
CLOSE REQ =======>
--------------------->
fin(1)
<-------------------
fin(1) ack
must insure now data
in pipe.
usually notification
event
<======= CLOSE REQ
<--------------------
fin(2)
-------------------->
event notification fin(2) ack
The above is a full duplex close operation on a socket/port pair.
There are wait states associated with the above that I ommitted. But I think
it should be noted:
() THe close sequence ideally operates on TCP socket pairs.
It was designed to allow for the draining of data in transit
or in the pipeline. The sender of close can not send data but
is resposible for all data the other side has in transient.
This minimizes loss of data during close between two non-cooperative
or non-peer applications. It allows even for simultaneous close
operations since TCP queues the fin/acks until deliverable. That
is the wait you probally are seeing.
() You can be left with half open connections if this is not
implemented a spec'd. The RFC goes into details in this area.
And there are implemetation tips.
() Depending on the OS interface to TCP one might be able to get away
with exiting without fully closing a connection, i.e. waiting for
notification that the other side has closed. I would do this unless
I wrote both side or am talking to peer applications that have a common
higher level protocol.
Some workarounds for violations of the above I have seen have included
the Os generating an abort/close when a process exits, and timers on
TCP wait states to mention a few.
It used to be one of the most bug infested areas of TCP we ever ran across
depending on the vendor and the application/os interface.
If you a programming for multiple connections or concurrency this really is
a problem depending on whose TCP you use.
Additionally, that last 'fin ack' has no ack so it is a 'hole' in the protocol.
So if it get dropped ( have seen this happen) via routers or bad bridge
connections there is no recovery. So most vendors put in the timer ( 2 min
or 5 min etc. ) as a backup.
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 10:10:09 GMT From: eru!luth!sunic!nuug!hod!tommy@bloom-beacon.mit.edu (Tommy Johansen) To: tcp-ip@nic.ddn.mil Subject: TCP/IP on Packet Radio
We are currently working with TCP/IP on Packet Radio. Our goal is to run
TCP/IP from one Ethernet to another with as high speed as possible. At the
moment we are able to communicate at 2400 baud. My questions are as follow:
Is it possible to run at 64 kb speed?
What kind of experience has bin ganed from simulare work?
Who delivers HW and SW?
Is there anybody out there doing the same thing?
I'm interesting in anything witch has to do with TCP/IP on Packet Radio.
--
| Tommy Johansen | E-mail: tommy@tommy.uit.no |
| University of Tromsoe, | FAX : +47 83 55418 |
| N-9000 Tromsoe | Tlf. work: +47 83 55419 |
| NORWAY | Tlf. priv: +47 83 73958 |
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: Thu, 19 Jul 90 16:09:58 EDT From: lazear@gateway.mitre.org To: protocols@rutgers.edu, tcp-ip@nic.ddn.mil Subject: RPC experience
I'm interested in finding out people's experiences in using Sun's RPC with existing applications. That is, how they fared inserting RPC into an application that was already written. Please contact me directly. I'd also be interested in articles discussing the issues people have dealt with when inserting RPC into applications. Walt Lazear MITRE Corp. 703/883-6515 lazear@gateway.mitre.org
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 13:11:13 GMT From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) To: comp.protocols.tcp-ip Subject: VAX ping & NCSA Telnet
>Thanks for all responses. It has become a moot point. NCSA's tcp/ip
>for MS-DOS requires (inexplicably) that the VAX PING the PC in order
>to get communications to work after both machines have rebooted. We
>are now using FTP Software's tcp/ip for MS-DOS, which has not exhibited
>this strange behavior.
I would sure like to see an explanation of this. We use NCSA here on all
our connected PCs and we DO NOT have ping enabled on the VAX.NCSA doesn't
do anything different here than any other host on the network. I can't
imagine why ping would be necessary on the VAX.
Can you elucidate???
bill gunshannon
bill gunshannon
702WFG@SCRVMSYS.BITNET
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 13:32:48 GMT From: garrett%oscar.ccm.udel.edu@louie.udel.edu To: tcp-ip@nic.ddn.mil Subject: Problems with WIN/TCP v5.1...
Greetings, all... We have just had the latest version of WIN/TCP (v5.1)
installed here at our site and I finally decided to sit down and learn how to
use the library/system call interface for VAXC...
Before I get into the details, we have the software installed on a 785 running
VMS v4.7 and VAXC v2.4
I have been following the examples in the WIN/TCP Programming Guide...
I found example source code in the directory TWG$TCP:[NETDIST.TUTORIAL.EXAMPLE]
(SERV.C, and CLIENT.C)
When I tried compiling these programs, I found that evidently some #include
files appeared to be missing from their correct locations. Among these files
were:
twg$tcp:[netdist.include.sys]types.h
twg$tcp:[netdist.include.sys]errno.h
twg$tcp:[netdist.include.sys]netdb.h
I looked all through the [netdist...] directory tree for these files and could
not find them. I took a look on the directory tree of an older version of
WIN/TCP (v3.2) and found files with the same name (sys/types2.h in v3.2 was
identical to the same file in v5.1, so I assumed the rest would be the same.
Is this a bad assumption) so I copied them to the appropriate location in the
v5.1 directory tree.
After copying these files, I was able to compile CLIENT.C and SERV.C, but got
the following warning in the process:
typedef long size_t;
%CC-W-DUPDEFINITION, Duplicate definition of "size_t".
At line number 41 in TWG$TCP:[NETDIST.INCLUDE.SYS]TYPES.H;1.
Is this a bad thing?
Now, on to the linkage part...
As was suggested in the "Compiling, Linking and Running Network Code" section
of the manual, I added the following definitions to my login.com file to
make the link steps a little easier:
$ define lnk$library sys$library:vaxcrtl.olb
$ define lnk$library_1 tcp:[netdist.lib]libnet.olb
$ define lnk$library_2 tcp:[netdist.lib]libnetacc.olb
and then linked the two programs:
$ link serv
$ link client
When I linked CLIENT, though I was informed of some undefined symbols:
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, _$EMUL
%LINK-I-UDFSYM, _$MOVE
These symbols seem to be referenced extensively by modules SELECT, SEND,
RECEIVE, and WRITEV in LIBNETACC...
In fact, when you run the CLIENT program, it dies with an access violation in
the 1st library call (gethostbyname) in the program.
The SERV program is silent. (I did a $run/det serv, as instructed by the
Programming Guide) The process it is in is still soundly sleeping, no real way
to know whether or not it is working until I can get the client part going.
Does anyone have any suggestions for me? Is the problem because I copied the
OLD include files? Maybe there's some special instructions for linking the
new stuff under VMS v4.7? Maybe it's something else? Thanks in advance for
any help y'all might be able to lend me here... All I want to do is get some
experience with writing client/server applications, and I can't even get
started yet... Grrr... Take care, all...
+-------------------------------------+--------------------------------------+
| Joel J. Garrett, Research Associate | Phone: (302)-451-2332 |
| Center for Composite Materials | inet: garrett@oscar.ccm.udel.edu |
| University of Delaware | - or - |
| Newark, Delaware 19716 | garrett@udel.edu |
+-------------------------------------+--------------------------------------+
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 15:10:55 GMT From: sun-barr!newstop!texsun!csccat!camdev!sscott@apple.com (Steve Scott) To: tcp-ip@nic.ddn.mil Subject: IBM/HP-UX FTP session hangs on PORT command
Hello, HP-UX fans!
The following is an excerpted note from one of my Big Blue Buddies with
all company proprietary info deleted ;-)
I am not sure whether or not this is an HP or an IBM problem (although
my friend does not mention this sort of a failure on other vendor's
hardware/software).
Maybe someone from within the HP labs can help here???
--------------- Excerpted mail begins --------------------------
Subject: FTP PORT command failure from HP nodes
Steve, we have seen a problem for a long time where FTP sessions from IBM
TCPIP to an HP node would fail when the FTP application issued a PORT command.
By testing the PORT command manually, I find that HP nodes are not accepting
port arguments where the first decimal portion of the port address is 3 or
less (ie PORT 192,25,80,1,3,200). I found nothing in the RFC indicating a
limit or restriction.
Is there some HP documentation about FTP PORT command limits or someone we can
call to resolve this? (A remote site) has this problem too.
History:
FTWENG is an IBM 43xx machine at IP address 192.25.80.1 via an
8232 Ethernet interface box
CAMDEV is an HP370 at IP address 192.25.80.50 running HP-UX 7.0
To see the problem, FTP from FTWENG to an HP node (CAMDEV) and issue
QUOTE PORT 192,25,80,1,3,200
(this will fail)
QUOTE PORT 192,25,80,1,4,200
(this will work)
------------------ Excerpted mail ends -------------------------------
Any ideas out there?
--
Steve Scott UUCP: {texbell|texsun}!csccat!camdev!sscott
Motorola, Inc. Internet : sscott@mot.com Telephone : 1-817-232-6317
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 16:24:35 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!tarpit!ucf-cs!eola!goldfarb@ucsd.edu (Benjamin I. Goldfarb) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP reliability / little flow control primer
src@scuzzy.uucp (Heiko Blume) writes:
>i've never heard of codex, but anyway: i assume that these are fast modems
^^^^^
Codex modems are made by Motorola.
--
------------------------------------------------------------------------------
Ben Goldfarb uucp: {decvax,uflorida}!ucf-cs!goldfarb
University of Central Florida Internet: goldfarb@eola.ucf.edu
Department of Computer Science BITNET: goldfarb@ucf1vm.BITNET
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 16:25:37 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: Problems with WIN/TCP v5.1...
In article <25049@nigel.udel.EDU> garrett@oscar.ccm.udel.edu writes: >I have been following the examples in the WIN/TCP Programming >Guide... The programming guide doesn't match reality in all cases. The thing that you need to know to get programs to link is there is only one library called TWGLIB. It replaces LIBNET and LIBNETACC. These libraries are for use only by Euncie. There should have been stuff in the release notes about this, but my memory here is a bit faded. >After copying these files, I was able to compile CLIENT.C and SERV.C, but got >the following warning in the process: > > typedef long size_t; >%CC-W-DUPDEFINITION, Duplicate definition of "size_t". > At line number 41 in TWG$TCP:[NETDIST.INCLUDE.SYS]TYPES.H;1. > >Is this a bad thing? No. size_t gets redefined from an unsigned int to a signed int (since VAX-C has int == long). Unless you are dealing with very large objects, this shouldn't be a problem. The original definition is in something like SYS$LIBRARY:TYPES.H or some other include VAX-C include file. If you remove it from [NETDIST.INCLUDE.SYS]TYPES.H, then the error will go away. You can also change it to "typedef unsigned int size_t". Also, you should be using the types.h file from twg$tcp:[netdist.include.sys] off the 5.1 tape. It is not in the VMS 4.x installation saveset due to an oversite. You can get it out of the "B" saveset (fullname WIN_TCP051.B I think). >As was suggested in the "Compiling, Linking and Running Network Code" section >of the manual, I added the following definitions to my login.com file to >make the link steps a little easier: This section is wrong. The libraries that you use have changed in release 5.1. You should add the following to your login.com $ define LNK$LIBRARY SYS$LIBRARY:VAXCRTL.OLB $ define LNK$LIBRARY TWG$TCP:[NETDIST.LIB]TWGLIB.OLB >%LINK-W-NUDFSYMS, 2 undefined symbols: >%LINK-I-UDFSYM, _$EMUL >%LINK-I-UDFSYM, _$MOVE These routines are found in LIBNET, so if you list that after the LIBNETACC (for a second time), you shouldn't get errors. However, you will be better off in the long run by using TWGLIB. Try these suggestions. They should help. All of the above is from memory, since I no longer work for TWG. -- Warner Losh imp@Solbourne.COM Boycott Lotus. #include <std/disclaimer>
-----------[000234][next][prev][last][first]----------------------------------------------------
Date: 19 Jul 90 17:17:00 GMT
From: mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae")
To: comp.protocols.tcp-ip
Subject: RE: WIN/TCP Window Size
As requested by BILLW@mathom.cisco.com on 19-JUL-1990 08:31, here is
more information on my WIN/TCP window size question:
The reason I wanted to change the window size was to see if that
would improve our Internet performance. We have a very slow Internet link.
The average roundtrip time is around 1.5 seconds. Our FTP transfer rate is
only about 9.6K bits/sec. With the long roundtrip time we thought a larger
window might help increase FTP throughput so we wanted to change the window
(both send and receive) and run some tests.
Since I posted the orginal message I have found out how to change the
window sizes. I changed the sizes from 4096 to 8192 and we tried a few
transfers. The results were inconclusive. I don't think the performance
changed. I did notice that all of the other hosts in the test had receive
windows around 4K (obviously I am rather green at this stuff), so if we did
get any improvement it would be in one direction only. So it looks to me
like I ought to return the window sizes to 4096 and leave them alone.
Any other sugguestions on improving performance on a slow link would
be appreciated. Our current link into MILNET is via sattelite. We are
working on getting a land line, but that may take a while. Thanks.
Murl McRae Naval Weapons Support Center
Crane, Indiana
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 18:28:32 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!crdgw1!sunne!brownpc@ucsd.edu (Paul C Brown) To: tcp-ip@nic.ddn.mil Subject: SLIP for Sun's
I am looking for a SLIP implementation that will allow two Sun-3's to communicate via a serial link. Sun tells me that the SLIP server provided with PC-NFS will not do the trick, since the PC end of the link encodes routing data in the packets that a normal sun would not. They mentioned that there is a "gated" deamon from Clarkson that replaces the "routd" supplied by Sun that does the trick. Anyone know where I can find this? I will summarize responses upon request. Thanks in advance! Paul C. Brown brownpc@crd.ge.com GE Corporate Research & Development Schenectady, New York
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 18:48:01 GMT From: amazon.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents dealing with TCP-IP
In article <9007171705.AA12869@bel.isi.edu>, postel@VENERA.ISI.EDU writes: > > RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname > RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login > with FTP, username ANONYMOUS and password GUEST. Jon! For anonymous logins, one should follow the printed instructions and enter their username on their local system, not guest. While I doubt anyone at the NIC ever looks at it, I do look at my anonymous logs and frequently contact people having problems with the VMS syntax my system uses. If they just type GUEST, as many do, I'm helpless. I know the system, but not the user. Please be polite and enter your real ID if that's what is asked for. (And it almost always is.) R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 18:59:22 GMT From: abvax!icd.ab.com!ejp@tut.cis.ohio-state.edu (Ed Prochak) To: tcp-ip@nic.ddn.mil Subject: Re: Beginner's info TCP & UDP
In article <64291@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
> In answering a beginner's question, hedrick@athos.rutgers.edu
> (Charles Hedrick) writes:
> +---------------
> | People tend to use UDP where (1) they plan to be making isolated
> | queries, such that the overhead packets used to set up and close a
> | connection would form most of the traffic (2) they need more
> | performance than they think they can get from TCP....
> +---------------
>
> I would add:
> ...(3) there are a very large number of clients accessing a single
> server, such that the cost of holding a connection open for each
> active client would be excessive. [The definition of "excessive"
> is system- and application-dependent.]
>
> In some sense this is the same as Hedrick's #1, except that #1 refers
> to conserving dynamic network bandwidth, and #3 to conserving quasi-
> static server system resources "wired-down" by connections (sockets,
> open-file slots, processes, etc.).
I think Rob's condition is important in some cases.
(at least that and the following was the justification
I used for an application using UDP).
In addition:
...(4) preservation of record boundaries. TCP provides the data
to the reciever as it is available. This means messages may
be fragmented and it is up to the application to parse out
record boundaries. There are some applications that prefer
to receive messages intact, making UDP the protocol of choice,
in this case.
As usual, the case is one of
no single right answer.
It all depends on the situation.
(I hope someone summaries this thread.)
ed
Edward J. Prochak Voice: work-(216)646-4663 home-(216)349-1821
Email: {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com
USmail: Allen-Bradley, 747 Alpha Drive, Highland Heights,OH 44143
As defined by a civil engineer named Wellington, ENGINEERING is
"the ability to do for one dollar, what any damn fool can do for two."
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 19:14:19 GMT From: gwilliam@SH.CS.NET (George Williams) To: comp.protocols.tcp-ip Subject: Re: TCP Port state FIN_WAIT_1 : what's that ?
Hello,
The close sequence in TCP is a symetrical exchange. That is the side issuing
close generates the following protocol exchange:
close initiator TCP close receipient
----------------- ------------------
CLOSE REQ =======>
--------------------->
fin(1)
<-------------------
fin(1) ack
must insure now data
in pipe.
usually notification
event
<======= CLOSE REQ
<--------------------
fin(2)
-------------------->
event notification fin(2) ack
The above is a full duplex close operation on a socket/port pair.
There are wait states associated with the above that I ommitted. But I think
it should be noted:
() THe close sequence ideally operates on TCP socket pairs.
It was designed to allow for the draining of data in transit
or in the pipeline. The sender of close can not send data but
is resposible for all data the other side has in transient.
This minimizes loss of data during close between two non-cooperative
or non-peer applications. It allows even for simultaneous close
operations since TCP queues the fin/acks until deliverable. That
is the wait you probally are seeing.
() You can be left with half open connections if this is not
implemented a spec'd. The RFC goes into details in this area.
And there are implemetation tips.
() Depending on the OS interface to TCP one might be able to get away
with exiting without fully closing a connection, i.e. waiting for
notification that the other side has closed. I would do this unless
I wrote both side or am talking to peer applications that have a common
higher level protocol.
Some workarounds for violations of the above I have seen have included
the Os generating an abort/close when a process exits, and timers on
TCP wait states to mention a few.
It used to be one of the most bug infested areas of TCP we ever ran across
depending on the vendor and the application/os interface.
If you a programming for multiple connections or concurrency this really is
a problem depending on whose TCP you use.
Additionally, that last 'fin ack' has no ack so it is a 'hole' in the protocol.
So if it get dropped ( have seen this happen) via routers or bad bridge
connections there is no recovery. So most vendors put in the timer ( 2 min
or 5 min etc. ) as a backup.
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 20:22:28 GMT From: ssc-vax!bcsaic!carroll@beaver.cs.washington.edu (Jeff Carroll) To: tcp-ip@nic.ddn.mil Subject: SUMMARY: porting Berkeley lpd code to sys V R3.2
In article <27966@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes:
>
> I would very much like to hear from anyone who has experience
>porting BSD code to system V/386. I'm trying to get lpd, lpr, lpq, et
>al. to run on our Intel 301s, which run Intel (Lachman) TCP/IP...
In addition to the responses summarized below, I had someone
point me to the NCSA Telnet sources on tacky.cs.olemiss.edu. I'm not
going to try that port yet...
As indicated below, source for "System V-ized" lpr is allegedly
available for anonymous ftp on acm.rpi.edu, though I haven't been able
to reach the ftp server on this machine. If anyone knows where else this
code can be found, I'd love to know about it.
I don't have a working solution yet, but I am just now getting
around to answering all the email I elicited. Thanks to all who
responded!
Jeff Carroll
carroll@atc.boeing.com
_____________________________________________________________________________
From skl@wimsey.bc.ca Sun Jul 15 03:13:17 1990
I have done some porting of the BSD TCP/IP code to Xenix/V 386,
which "claims" to be System V compatible.
From: Arthur L. Martin <uw-beaver!rutgers!pawl.rpi.edu!night>
> How big a job is this?
I rather big one. I made a couple of attempts at it and gave up.
However, I did run across a SysV port of lpr on an anonymous ftp
site. I don't remember the site offhand, but I still have the
package lying around. I can make it available for anonymous ftp
if you like.
--
--
Trip Martin
night@pawl.rpi.edu
From: uw-beaver!ames!daver.bungi.com!dlr (Dave Rand)
I have done this for 386/ix. If you would like the diffs, please let
me know!
--
Dave Rand
{pyramid|mips|sun|vsi1}!daver!dlr Internet: dlr@daver.bungi.com
From: Paul Nulsen (some horrible bang-path addr that I accidentally
deleted)
A port has been done. It was announced recently by dlr@daver.bungi.com (Dave
Rand). I have copies of the diff files he provided.
Regards,
Paul Nulsen
pejn@wolfen.cc.uow.edu.au
From: hitachi!jon@uunet.UU.NET (Jon Ryshpan)
...
> The larger goal is to enable our Vax running WIN/TCP or MultiNet
>to act as a print server for the 301s.
...
We do it with the this kluge. The following shell script is the
"interface" in the SysV spooler system. You also have to create a file
to be the printer for the spooler destination; /dev/null doesn't seem
to work, so we have a file called DUMMY in a convenient location.
Actually the file is /usr/spool/lp/DUMMY. The only problem is that
each user who wants to print has to have an account on the vax. Here
is the script:
#
# lp interface for submission to the vax for reprinting.
#
copies=$4
shift; shift; shift; shift; shift
files="$*"
i=1
while [ $i -le $copies ]
do
for file in $files
do cat "$1" | /usr/ucb/rsh vax lpr -P lsiNTX
done
i=`expr $i + 1`
done
exit 0
--
Many Thanks:
Jonathan Ryshpan <...!uunet!hitachi!jon>
M/S 420 (415) 244-7369
Hitachi America Ltd.
2000 Sierra Pt. Pkwy.
Brisbane CA 94005-1819
From: night@pawl.rpi.edu (Trip Martin)
Okay, I've made lpr available on clotho.acm.rpi.edu (128.113.10.204) in
~ftp/pub/lpr.tar.Z. Enjoy!
--
--
Trip Martin
night@pawl.rpi.edu
(NOTE: I have been unable to raise this host via FTP. Anybody know more
about this code? jkc)
From: uw-beaver!rutgers!leonardo.intel.com!davidl (David D. Levine)
If you can wait a while for System V Release 4, there's a REAL easy way...
BSD compatibility and the BSD lp* utilities are BUILT INTO Release 4...
Contact your local Intel salesthing for details.
- David D. Levine, Intel IMSO Tech Pubs
davidl@leonardo.intel.com
"Think of it as evolution in action."
From: Stan Stead <stan@anes.ucla.edu>
I have ported the lp* BSD code to a SysV Stardent computer. It was
greatly facilitated by porting the BSD libraries. I have not tried to do
the port to an SCO SysV/386 but I assume that without the libraries,
it would be EXTREMELY difficult.
Stan
From: David Fetrow <fetrow@milton.u.washington.edu>
I don't know but, around here where we have similar problems, they bit the
bullet and wrote printer code for everything. All the systems can use "prt"
and the files are printer from VMS printer demons. The code, is howvere, a
tad bit ugly.
I think most of it is available via anonymous FTP.
--
-dave fetrow- fetrow@bones.biostat.washington.edu
dfetrow@uwalocke (bitnet) {uunet}!uw-beaver!uw-entropy!fetrow
I am looking for a port of the BSD lpd code for a ATT UNIX 386 PC. I was
wondering if you had any answers about this?? I figure somebody must have
done it by now.
Thanks,
Sonya
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Canstar UUCP: {utai,utzoo,ncrcan}!canstar!sonya
3900 Victoria Park Ave. other: sonya%canstar@utai.toronto.edu
North York, ON L3T 3T3 Phone: (416) 756-4100 x258
Canada Fax: (416) 756-3990
From: scocan!larryp@uunet.uu.net
I did it a while ago. However, I could not overcome the inertia of
the company, and the Systems department never installed it. As such
it has not been heavily tested, in particular, I do not guarantee that
all commands even work (I gave up to early), but I was able to submit
jobs over the net. I also never got to the stage of investigating what
filters I needed, or how to set them up. You are welcome to the code
if you want it.
I was porting to ISC 386/ix 1.0.6, using ISC's version of TCP. You can
be sure some of the include files will be in different places, although
things should indeed work.
I defined a compat.h and a compat.c. Lots of defines, and where necessary
I snaged BSD subroutines and stuffed them in compat.c. I also wrote SYSV
emulations of flock, truncate and the like.
---
Larry Philps, SCO Canada, Inc (Formerly: HCR Corporation)
Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5
InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net
UUCP: {uunet,utcsri,sco}!scocan!larryp
Phone: (416) 922-1937
Fax: (416) 922-8397
From: uw-beaver!harvard!uunet.UU.NET!munnari!ipso.rss.ips.oz.au!craigb (Craig Bevins)
It has already been done. I have the patches and I can send them to you
if you haven't already found a solution.
Craig.
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 08:58:11 -0700 From: jqj@rt-jqj.Stanford.EDU To: apple.com!veizades@apple.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
Transparent bridging of common protocols between FDDI and Ethernet is currently impossible due to a conflict between various "standards" (notably RFC1103 and draft successor, IEEE 802.d, and AppleTalk Phase II). We were the people whom John Veizades refers to that verified that AppleTalk II doesn't work across DEC FDDI-Ethernet "transparent" bridges. At least one other transparent FDDI to Ethernet bridge vendor currently has the same implementation. John suggests that bridges should have a small table indexed by EtherType indicating whether packets should be translated from RFC1042-style 802.2/SNAP to Ethernet format when going from FDDI to Ethernet. Unfortunately, this does not solve the problem. Suppose my FDDI to Ethernet bridge knows that AARP packets should go out on the coax as 802.3 so that AppleTalk II nodes can understand them. That means that my bridge is not transparent to AppleTalk I. So it's not an feasible solution. I believe that if Apple wants to play in the heterogenous bridging world, they need to modify AppleTalk II specs in one of the following ways: 1/ an AT II node on 802.3+Ethernet media must listen to *both* RFC1042-style 802.2/SNAP/AARP *and* to Ethernet/AARP packets sent to the Appletalk multicast address. This corresponds to the requirement for IP hosts that appears in RFC1122 and states that any 802.3/802.2/IP speaker must also understand Ethernet encapsulation. OR 2/ the AT II spec must be modified so that AARP generates and expects the Apple OUI the same way AT II/DDP does. Both proposals break currently fielded AppleTalk II implementations, so I can see that Apple may be reluctant to adopt them. But I think that at this point it is unlikely that the IP-on-FDDI working group will radically change their encapsulation requirements just to satisfy Apple, and I see no way for bridge manufacturers to satisfy everyone's requirements simultaneously. The alternative is a modification of both the definition of "transparent" bridging and the IP-in-FDDI spec. To reiterate, John is correct that, by the current de facto standard, "transparent" 802.3->FDDI->802.3 bridges are not transparent to 802.3 packets in RFC1042 format. This is not a problem for IP, because of the specific requirement that all receivers of RFC1042 format on an 802.3 medium also understand Ethernet encapsulation. JQ Johnson voice: 415-723-3078 Manager, Special Projects Internet: jqj@jessica.stanford.edu Networking and Communications Systems Pine Hall Rm 125-A Stanford University Stanford, CA 94305-4122
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 21:58:44 GMT From: hayes.fai.alaska.edu!wisner@decwrl.dec.com (Bill Wisner) To: tcp-ip@nic.ddn.mil Subject: Changing inet MTU in 4.3bsd
The question, simply put, is how do I do it? We've had some problems with the campus network here that experience indicates might be solved if we lower the MTU from 1500. So...? Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 /* you are not expected to understand this */
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 23:02:12 GMT From: apple.com!veizades@apple.com (John Veizades) To: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
The all-zeros Rorganizational unique identifierS (OUI) was not specifically intended to be used for translating Ethernet frames to 802.2/SNAP. Its original intention was (and is) not completely clear; all that was generally agreed upon was: (1) The low-order 16 bits of the SNAP protocol discriminator indicated an Ethernet protocol type; and (2) The format of the data part of the SNAP packet was the same as the format of the data part of the Ethernet packet of this protocol type. This Rgeneral agreement,S as far as I know, was never written down. AppleTalk Phase 2 and TCP/IP both adopted this convention. The unfortunate difference is that, on an Ethernet/802.3 data link, AppleTalk Phase 2 runs on top of 802.3 (and 802.2) and TCP/IP runs on top of Ethernet. Thus for a TCP/IP Ethernet node to communicate with a TCP/IP 802.2 node (on token ring or FDDI, say), some type of packet translation must be performed, whereas for an AppleTalk Phase 2 Ethernet node to communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet, token ring or FDDI) no such translation need occur (in fact, such translation MUST NOT occur). This makes it somewhat difficult to build a bridge that RtransparentlyS allows both forms of communication. However all that really has to be done is for the bridge to contain a small table of Ethernet protocol types that either should, or shouldnUt be translated in this manner. Obviously the smaller the table, and the less translation done, the better the overall performance. Any bridge between Ethernet and an 802 media which does not translate any OUI zero packets will prevent TCP/IP nodes (and any others using the same OUI convention) from communicating between the two media. Any bridge between Ethernet and an 802 media which translates all OUI zero packets will prevent AppleTalk nodes (and any others with an OUI of zero who donUt expect translation) from communicating between the two media. In both cases, routers can of course be set up to accomplish the communication. A somewhat equivalent problem could exist if two bridges are used to connect two Ethernet/802.3 data links across an 802 backbone (say FDDI). In this case, some type of translation/encapsulation of Ethernet (non-802.3) packets must be performed to allow them to be passed across the 802 backbone. There are many ways to do this, one of which seems to be translating all Ethernet packets to OUI zero packets, shipping them across the backbone, and then converting them back. This however does not work for any OUI zero packets which start out on the Ethernet/802.3 data link. Such packets will not be translated on the way into the backbone, but will be incorrectly translated before being delivered on the destination Ethernet. Such packets should be forwared entirely without translation. In terms of actual product implementations, unfortunately DEC is already beta-siting an Ethernet-to-FDDI bridge which translates all OUI zero packets, and thus does not work with AppleTalk Phase 2. They are aware of this issue. At the recent 802 meetings in Denver, it became clear that this type of translation is not part of th 802.1d (Mac Bridging) standard, but is something that many bridge manufacturers wish to include as a non-802-standard option with their products. Most have said they will have some type of translation (or non-translation) table to insure it is possible to work with all known protocols. John Veizades and Alan Oppenheimer Apple Computer, Inc.
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 23:26:25 GMT From: mtxinu!rtech!wrs!daahoud!hwajin@ucbvax.Berkeley.EDU (Hwa Jin Bae) To: tcp-ip@nic.ddn.mil Subject: Re: UDP checksums
beau@ultra.com (Beau James {Manager - SW Development - Ultra Networks}) writes:
>In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes:
>>Does anyone know how to enable UDP checksums on a Sun 360.
> # adb -k /vmunix /dev/mem
> ...
> udp_cksum/W 1 ; Enables UDP checksums on the running kernel
> udp_cksum?W 1 ; Enables whenever this kernel is booted
udpcksum not udp_cksum
hwajin@daahoud.wrs.com
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 19 Jul 90 23:58:01 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: re: How to get RFC documents dealing with TCP-IPREAD/NEW/FOLLOWUP
In article <9007171708.AA04346@akamai.isi.edu>, jkrey@VENERA.ISI.EDU writes:
>
> RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
> RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login
> with FTP, username ANONYMOUS and password GUEST. The NIC also
> provides an automatic mail service for those sites which cannot use
> FTP. Address the request to SERVICE@NIC.DDN.MIL and in the subject
> field of the message indicate the RFC number, as in "Subject: RFC
> nnnn".
>
> RFCs can also be obtained via FTP from NIS.NSF.NET. Using FTP, login
> with username ANONYMOUS and password GUEST; then connect to the RFC
> directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1
> (where "nnnn" refers to the number of the RFC).
Boy! Where do I get off complaining about postings from Jon P. and Joyce R.?
But this one is simply wrong. The NIC is a DECsystem 20 or some such and the
"cd RFC" drops you into the RFC subdirectory of the PS: device. And that's not
where you need to go.
The correct command is "cd RFC:". This gets you to the full RFC list. I'm not
too sure just what PS:<RFC> is. It has one RFC in it (RFC1005 and a README that
I have not read.
I also restate my request to use your real ident, not GUEST when using
anonymous logins. Some systems do look at the log and I consider it good
manners! A few systems really want guest, but they don't ask for your real
ident.
R. Kevin Oberman
Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov
(415) 422-6955
Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 01:43:19 GMT From: mogul@wrl.dec.com (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: Re: WIN/TCP Window Size
In article <12606340619.9.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes:
>Mumble. Someone has to ask... Just WHY do you want to change the window
>size (and which one). The window sizes offered by (and to) a system can
>be carefully thought out by the implementors, and can have serious non-linear
>effects on performance, thoughput, and even reliability of they are changed
>very much. There are better ways to solve most problems than changing the
>window sizes...
One reason to change the window size is if the segment size changes,
perhaps as a result of Path MTU Discovery. Van Jacobson has pointed out
that the flow-control window size had better be an exact multiple
of the segment size, or performance will suffer.
I've drafted a few paragraphs on this topic for inclusion in the
forthcoming RFC on Path MTU Discovery. In fact, I invite people
to comment on their wording.
(The rest of the document is draft-ietf-mtudisc-pathmtu-01.txt at
the usual place.)
Thanks
-Jeff
(To be inserted at the end of section 6.4, "TCP layer actions"):
Modern TCP implementations incorporate ``congestion advoidance''
and ``slow-start'' algorithms to improve performance@cite[Jacobson1988].
Unlike a retransmission caused by a TCP retransmission timeout, a
retransmission caused by a Datagram Too Big message should not
change the congestion window. It should, however, trigger the
slow-start mechanism (i.e., only one segment should be retransmitted
until acknowledgements begin to arrive again).
TCP performance can be reduced if the sender's maximum window size
is not an exact multiple of the segment size in use (this is not
the congestion window size, which is always a multiple of the
segment size). In many system (such as those derived from 4.2BSD),
the segment size is often set to 1024 octets, and the maximum
window size (the ``send space'') is usually a multiple of 1024
octets, so the proper relationship holds by default. If PMTU
Discovery is used, however, the segment size may not be a
submultiple of the send space, and it may change during a
connection; this means that the TCP layer may need to change the
transmission window size when PMTU Discovery changes the PMTU
value. The maximum window size should be set to the greatest
multiple of the segment size (PMTU - 40) that is less than or equal
to the sender's buffer space size.
PMTU Discovery does not affect the value sent in the TCP MSS option,
because that value is used by the other end of the connection,
which may be using an unrelated PMTU value.
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 02:38:52 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) To: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
It should be noted in passing that following is in the Host Requirements standard, RFC-1122: ] 2.3.3 Ethernet and IEEE 802 Encapsulation ] ] The IP encapsulation for Ethernets is described in RFC-894 ] [LINK:3], while RFC-1042 [LINK:4] describes the IP ] encapsulation for IEEE 802 networks. RFC-1042 elaborates and ] replaces the discussion in Section 3.4 of [INTRO:2]. ] ] Every Internet host connected to a 10Mbps Ethernet cable: ] ] o MUST be able to send and receive packets using RFC-894 ] encapsulation; ] ] o SHOULD be able to receive RFC-1042 packets, intermixed ] with RFC-894 packets; and ] ] o MAY be able to send packets using RFC-1042 encapsulation. ] ] ] An Internet host that implements sending both the RFC-894 and ] the RFC-1042 encapsulations MUST provide a configuration switch ] to select which is sent, and this switch MUST default to RFC- ] 894. Consider the implications. Every vendor must offer ethernet TCP/IP encapsulation, and that must be the default. Adding support for 802.3 (RFC-1042) is not required, and does not increase the number of compliant machines with which an implementation can interoperate. Historically, there were very few machines that used only RFC-1042. (I think HP used SAP, but that BICC (?) in the U.K. used RFC-1042.) Supporting both RFC-894 and RFC-1042 does not make an implementation faster, but code is not bad. The reduction of the MTU in RFC-1042 is about 1%, which should translate into around 10KBytes/second of lost through-put for machines that are currenting get 1MByte/sec with user-process-to-user-process TCP/IP/Ethernet. Thus, there are no (or very few and exceptional) business reasons for a vendor to offer RFC-1042 support, or even to continue existing RFC-1042 support. RFC-1103 and its pending successor are a different story. Vernon Schryver Silicon Graphics vjs@sgi.com
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 03:16:11 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: re: How to get RFC documents dealing with TCP-IP
In article <1990Jul19.165801.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes:
> In article <9007171708.AA04346@akamai.isi.edu>, jkrey@VENERA.ISI.EDU writes:
>>
>> RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname
>> RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login
As several people have pointed out, I should learn to read before posting. The
posting was absolutely correct. I was confusing nic.ddn.mil with nis.nsf.net.
My humblest apologies to all involved.
R. Kevin Oberman
Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov
(415) 422-6955
Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 15:18:25 -0700 From: "Philip Almquist" <almquist@jessica.stanford.edu> To: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Cc: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
Vernon, > Every vendor must offer ethernet TCP/IP encapsulation, and that must be > the default. Adding support for 802.3 (RFC-1042) is not required, and > does not increase the number of compliant machines with which an > implementation can interoperate. Historically, there were very few > machines that used only RFC-1042. > ... > Thus, there are no (or very few and exceptional) business reasons for a > vendor to offer RFC-1042 support, or even to continue existing RFC-1042 > support. This is not ENTIRELY true. A host which supports RFC-894 must be able to receive RFC-1042 packets if it wants to be unconditionally compliant with the Host Requirements RFCs. Only the ability to send RFC-1042 packets is truly optional. This topic was debated at some length by the authors of Host Requirements. The requirements were rather carefully chosen to allow for a transition to RFC-1042 in the long run without breaking everything in the short run. Philip
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 15:50:17 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: tcp-ip@nic.ddn.mil Subject: Routing Loop
Is anyone familiar with the following nodes: 192.80.214.1 and 192.80.214.254? An nslookup PTR query returns a non-existent domain error. The nodes appear to be between the College Park Md NSF backbone node and SURANET. As of 1400 PDT the nodes were involved in a routing loop. A traceroute from our site to wraith.wtp.contel.com, issm.iss.contel.com, or sccgate.scc.com our Rightist brethren would reach College Park and then bounce back and forth between the two nodes. Any information would be appreciated. Merton
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 06:49:40 GMT From: mcsun!unido!gtc!pemstgt!tb@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: Re: Excelan Lan Workplace and Packet Drivers?
root@joymrmn.UUCP (Marcel D. Mongeon) writes: >I have an Excelan 205T board in an SCO Xenix 386 machine >supporting the Lan Workplace software. The board is hooked >up to a thinwire ethernet. I have been trying (without >any success) to get some DOS based machines talking to this >board using other vendor's boards driven by appropriate >packet drivers. I try both NETBIOS and FTP style calls to >the Excelan board and it doesn't respond. We have installed 205T and 3C503 in DOS,UNIX and XENIX-Systems All is working. On DOS we HAVE PC NFS and LAN WORKPLACE, on XENIX LAN-WORKPLACE and SCO XENIX NET, on UNIX SCO TCP/IP and SCO NFS. As I know, you can't do NETBIOS-calls form DOS without a NETBIOS emulation on XENIX. This is a part of XENIX NET. >The Excelan board is receiveing the packets because any of >the appropriate stat commands done before and after an >attempted link indicates that the excelan received packets -- >it just didn't do anything with them! Do have edited the proper files: /etc/hosts on DOS and XENIX What products do have installed on DOS. If you can mail me some more information, i will try to answer you question in a better way. best regards Tillmann -- Dipl.Ing. Tillmann Basien Programmentwicklung fuer Microcomputer Vaihinger Str.49, PostBox 810165 +49-711-713047 FAX 7000 Stuttgart 80- West Germany +49-711-713045 PHONE
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 14:04:33 -0400 From: bzs@world.std.com (Barry Shein) To: zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu Cc: tcp-ip@nic.ddn.mil Subject: Beginner's info TCP & UDP
>Quick question:
> Under what conditions would a programmer want to use a UDP connection
> over a TCP connection? What does UDP give you that TCP doesn't, that
> makes it worth losing (or implementing yourself) a reliable,
> guaranteed delivery layer?
>
> Pete Clark
I assume you mean UDP over IP, not over TCP, otherwise it's not a
quick question, it's a strange question and needs some clarification.
Consider the following situations:
1. I have designed an application which embeds ECC integers and
sequencing into its packets. It's mostly a one-way protocol (on
request blasts a lot of data), so asynchrony is not particularly
useful. The ECC allows the remote end to detect and correct one or two
bit errors without resend. I have determined (?) that 99.99% of all
errors are one or two bit (of course, sequence errors might require
entire resends, but I can handle that.)
Why would I want TCP to also check every packet and silently resend
when most of the time I can correct without resend?
2. I am sending an animation which consists of 1Kx1Kx8 bit frames over
the network. I do some rudimentary checking (sequencing etc.) but,
more importantly, need to (usually) keep up with 30-frames/second.
A few bits in error might mean the image on the screen is "smudged" in
some tiny area for 1/30th of a second (this assumes a network
connection with few errors, tho not zero errors.)
Is it worth waiting and having TCP resend those packets? Or just let
the screen update on the next 30th of a second which will probably fix
the image (that is, would anyone notice a few small xmit errors?)
3. I am blasting data similarly to (2) over ethernet. Ethernet
hardware does a CRC on the data although, again, doesn't guarantee
sequencing (packets might be lost entirely, but if they get there
they're correct.)
4. Finally, UDP/IP can be implemented on a machine with raw access to
a network device in a (longish) afternoon. I've done it (the 3B2/HP
UDP/IP/TFTP source that floats around was written by me from scratch
and put into production over a weekend.)
There is value in getting a few bits across as a bootstrap.
Caveat: It is a fallacy that because UDP is much simpler and lower
overhead that it is therefore inherently faster. For example, the
lockstep protocol of TFTP/UDP is usually much, much slower (an order
of magnitude) than a decent FTP/TCP. Asynchrony is much more important
than mere CPU cycles. Ask the right questions!
(note that in the examples above I haven't excluded asynchrony.)
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: Friday, 20 July 1990 1:08pm ET From: "Bill.Simpson" <09998WAS%MSU@pucc.PRINCETON.EDU> To: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents
R Kevin Oberman writes: > Please be polite and enter your real ID if that's what is asked for. I can't speak about NIC.DDN.MIL, but the other site Jon mentioned, NIS.NSF.NET, *requires* the use of guest as a password for anonymous. Otherwise, it won't let you on. This is quite disconcerting for those of us who may type ahead the anonymous login sequence. Presumably the IBM they use has !@#$% software that is not configurable. It certainly has a *terrible* implementation of TCP/IP. Bill Simpson 09998was@ibm.cl.msu.edu
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 12:26:58 GMT From: usc!samsung!munnari.oz.au!mel.dit.csiro.au!smart@ucsd.edu (Robert Smart) To: tcp-ip@nic.ddn.mil Subject: Come on guys, we've got to improve e-mail
Some time in the later 70s I installed a mail system from NIH on a
DECsystem-10. It included all sorts of wonderful things: you could
tell if mail you had sent had been read, and you could recall mail
if it hadn't been read. It had the advantage of being a standalone
system mail package. [My boss got me to rip it out: electronic mail
was not a suitable activity for computers!]. The fact is that we
haven't made a lot of progress.
Before the flood starts again on the desirability of the sender
knowing if the recipient has read a message: When a mail message
goes through a gateway to a mail system that does not support
read-receipt a message will go back to the sender saying "mail
has parsed to an MTA or UA that will not give a read receipt".
If the user chooses to configure his user agent to not give
read receipts then the sender will get the same message. You
can conceal your activities as much as you like.
To make mail work properly there has to be a User Agent to User
Agent protocol. The user should be able to look at the mail he
has sent and see which items have been read. We are trying to
use mail to build protocols between people and the picture
currently looks like this:
human - - - - - - - human
| |
user-agent user-agent
| |
MTA - - - - - - - - MTA
| |
etc
The lack of a user-agent to user-agent protocol limits the sort
of protocols that humans can build with this tool. The options
are protocols of the "I hope you get this (but don't much care)"
type and ones where the humans have to try to do by hand things
that the UA could do for them (e.g. say "Please let me know when
you've read this").
Mail can disappear for a variety of reasons: disk crashes, software
problems or because the recipient doesn't check his mail box. The
effect of this is twofold: some rely on e-mail to a dangerous
extent; and most look for other mechanisms for important communication.
The second thing we need to do is allow mail messages to contain
non-text information: graphics and sound in a standard form; and
attached files which will only be meaningful to the sender and
recipient systems but which intermediate systems will allow to pass.
Minor things that would be nice include encryption and unforgeable
signatures.
There are two ways to go:
1) Get X.400 working.
2) Upgrade the RFC standards.
There are problems with X.400. Does it cover the ground? Does it in
fact allow me to send my Macwrite document to another Mac? The
protocol has so many options that the chances of frequent interoperability
seem slight. Also X.400 is just the bones of a mail system. I have
yet to see a convincing description of how it will be administered.
Even when it works it seems almost impossible to make it user friendly.
And when it goes wrong it is a major headache. I have configured a
few X.400 systems but none recently. Perhaps all this is changing?
Conversely I really like RFC822 and SMTP. When things go wrong you
can poke you head in and have a look and easily understand what is
going on. It is really not hard to extend the RFCs to make a
proper mail system. As George Michaelson pointed out a while ago: all
we need is a few extra optional headers, allow lines starting with
a "." in the body of the text to introduce sections of binary data in
btoa format:
.sound
...junky looking stuff...
.end sound
Or something like that.
SMTP can handle the Telnet equivalent of will/won't do/don't by just
issuing new commands and seeing if the receiver understands them.
MAIL From:<x@y.z>
250 x@y.z ok
RWRA To:<a@b.c>
[RWRA means RCPT with Read Acknowledge]
500 Command unrecognized
RCPT To:<a@b.c>
250 a@b.c ok
DATA
...etc
Since the receiving MTA didn't know about read-return requirements
the sending MTA can no longer guarantee that a read-return will come
back, and so will send back a neutral acknowledgement at this point.
Though the final user agent may actually obey the Read-acknowledge:
header in the message.
-------------------------------------------------------------------
So what should we do, 1 or 2? Well, this is the age of competition
(ask Mikhail Gorbachev) so lets do both, and may the best solution
win. Since X.400 is out of the control of sensible people, it is
important that the extensions to SMTP/RFC822 be done in such a way
as to maximize interoperability with X.400. We want gateways where
sound and pictures and attached files if possible will go across.
Alternatively if we are definitely going X.400 then I would like to
see a description of how we are going to administer the monster.
Bob Smart <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz.au!smart>
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 12:38:43 GMT From: usc!samsung!umich!pmsmam!wwm@ucsd.edu (Bill Meahan) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP on Packet Radio
In article <1990Jul19.101009.5902@hod.uit.no> tommy@sfd.uit.no (Tommy Johansen) writes: >We are currently working with TCP/IP on Packet Radio. Our goal is to run >TCP/IP from one Ethernet to another with as high speed as possible. At the >moment we are able to communicate at 2400 baud. My questions are as follow: > > Is it possible to run at 64 kb speed? > What kind of experience has bin ganed from simulare work? > Who delivers HW and SW? > Is there anybody out there doing the same thing? > >I'm interesting in anything witch has to do with TCP/IP on Packet Radio. >-- >| Tommy Johansen | E-mail: tommy@tommy.uit.no | >| University of Tromsoe, | FAX : +47 83 55418 | >| N-9000 Tromsoe | Tlf. work: +47 83 55419 | >| NORWAY | Tlf. priv: +47 83 73958 | Try checking into rec.ham-radio.packet. There is much discussion of various high-speed transmission schemes. Currently, there are good, working 56KB speed schemes. Some enterprising types have gotten 2Mb on microwave. Our local Packet interest group is developing 9600b units based on available FAX modems. You might also contact bdale@col.hp.com - he REALLY has his finger on the pulse of Packet hardware! -- Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwm I don't speak for Ford - the PR department does that! Any attempt at wit is liable to offend _somebody_!
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 14:19:16 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Network Temperature Protocol
Background. As you may know, the UK has been undergoing nothing but a heatwave the last few days. Motivation. As part of a distributed computing experiment, we are considering setting up a Sun workstation, with a bi-metallic strip and small coil tempearture device, and providing a network wide reading, combined with time of day service and cartesian location data. Deliverable. The intent is to deploy such a service across the Internet as a way of detecting optimal vacation sites over the coming years of weather disruption whilst conventional forecast techniques may not suffice. An rfc (request for centigrade) may be forthcoming shortly. jon (but seriously ... :-)
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 20:25:27 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) To: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents
> the IBM they use has !@#$% software that is not configurable. It certainly > has a *terrible* implementation of TCP/IP. I haven't any kind words for them either. It might be disconcerting for you. It just plain pisses me off! I go to the trouble of identifying myself and !@#$%. Geez!, what's the use. Oh well, the Internet is on the way out, OSI is on the way in. I'll be dead. pHil
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 15:45:33 GMT From: phri!roy@nyu.edu (Roy Smith) To: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents dealing with TCP-IP
In <1990Jul19.114801.1@amazon.llnl.gov> oberman@amazon.llnl.gov writes:
> For anonymous logins, one should follow the printed instructions and enter
> their username on their local system, not guest. [...] be polite and
> enter your real ID if that's what is asked for. (And it almost always is.)
My experience is that you don't get prompted for your real ID until
after it is too late. Maybe it's just my ftp implementation (SunOS-3.5.2
and MtXinu 4.3BSD systems) but I get prompted for the username (i.e.
anonymous) and then the password, and only then do I get the line which
requests that I "send ident as password". For example:
----------------
Script started on Fri Jul 20 11:37:58 1990
alanine> ftp uunet.uu.net
Connected to uunet.uu.net.
220 uunet FTP server (Version 5.99 Wed May 23 14:40:19 EDT 1990) ready.
Name (uunet.uu.net:(null)): anonymous
Password (uunet.uu.net:anonymous): <<I typed "guest" here>>
331 Guest login ok, send ident as password.
230 Guest login ok, access restrictions apply.
ftp> quit
221 Goodbye.
alanine> ^Dexit
script done on Fri Jul 20 11:38:16 1990
----------------
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 15:19:16 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: tcp-ip@nic.ddn.mil Cc: discussion@cs.ucl.ac.uk Subject: Network Temperature Protocol
Background. As you may know, the UK has been undergoing nothing but a heatwave the last few days. Motivation. As part of a distributed computing experiment, we are considering setting up a Sun workstation, with a bi-metallic strip and small coil tempearture device, and providing a network wide reading, combined with time of day service and cartesian location data. Deliverable. The intent is to deploy such a service across the Internet as a way of detecting optimal vacation sites over the coming years of weather disruption whilst conventional forecast techniques may not suffice. An rfc (request for centigrade) may be forthcoming shortly. jon (but seriously ... :-)
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Fri, 20 Jul 90 21:43:15 EDT From: louie@sayshell.umd.edu (Louis A. Mamakos) To: tcp-ip@nic.ddn.mil Cc: Subject: Re: Network Temperature Protocol
In article <9007210040.AA28109@ucbvax.Berkeley.EDU> you write: >As part of a distributed computing experiment, we are considering >setting up a Sun workstation, with a bi-metallic strip and small coil >tempearture device, and providing a network wide reading, combined >with time of day service and cartesian location data. Actually, the facilities for doing most of this are already available on the internet. If you run NTP (network TIME protocol) on a host, you can certainly provide the time of day service. To determine the temperature, you need only look at the drift rate of the clock relative to the a reference clock which corrolates rather nicely to the temperature of the crystal in the clock of your computer. You'll find that its trivial to see day/night variations of the clock and hot vs. cold days. All you need do now is calibrate the drift rate to the temperature. I'm sure Dave Mill can describe the use of NTP as an earthquake predictor in another message. This would be another important factor in picking a location for a holiday. louie
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 17:49:16 GMT From: logicon.com!Makey@nosc.mil (Jeff Makey) To: tcp-ip@nic.ddn.mil Subject: Re: Come on guys, we've got to improve e-mail
In article <1990Jul20.122658.23729@mel.dit.csiro.au> smart@manta.mel.dit.csiro.au (Robert Smart) writes:
> 2) Upgrade the RFC standards.
A user agent with the desired features can easily and properly be
implemented as a layer on top of RFC822/SMTP. There is no need to
change that which is not broken.
:: Jeff Makey
Department of Tautological Pleonasms and Superfluous Redundancies Department
Disclaimer: All opinions are strictly those of the author.
Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 18:05:30 GMT From: tep@tots.UUCP (Tom Perrine) To: comp.protocols.tcp-ip Subject: Re: Come on guys, we've got to improve e-mail
I couldn't agree more about the lack of progress in SMTP protocol enhancements to handle such things as return-receipt, multi-media mail, etc. I used Multics systems in the mid 70s which had the return-receipt feature, which could of course be disabled by the recipient. Encryption standards and multi-media standards are appearing. I know of RFC1040 (Privacy Enhancements for Internet Electronic Mail) and RFC1049 (A Content-type header field for Internet Messages), but I know of *no* fielded systems that support either. I agree that there is no "official" UA <-> UA protocol, other than, perhaps, that information which is encoded in the header fields. You might want to check out any of the following newsgroups: comp.mail.headers Gatewayed from the Internet header-people list. comp.mail.mh The UCI version of the Rand Message Handling system. comp.mail.misc General discussions about computer mail. comp.mail.multi-media Multimedia Mail. comp.protocols.iso.x400 X400 mail protocol discussions. (Moderated) comp.protocols.iso.x400.gateway X400 mail gateway discussions. (Moderated) I worked on designing some extenstions to SMTP for use over dial-lines, but never took it any further. I like the "RWRA" SMTP extension, but I think most limitiations for multi-media are in the UA side of things. Perhaps we need to take this discussion to one of the above newsgroups, or start a new mailing list, perhaps mail-modernization or somesuch? Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: nosc!hamachi!tots!tep Tactical and Training Systems Division |-or- sun!suntan!tots!tep San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 18:31:49 GMT From: agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan@ucbvax.Berkeley.EDU (RL "Bob" Morgan) To: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
Ah, well, now we're getting somewhere. John and Alan write: > The all-zeros "organizational unique identifier" (OUI) was not > specifically intended to be used for translating Ethernet frames to > 802.2/SNAP. Its original intention was (and is) not completely clear; > all that was generally agreed upon was: > > (1) The low-order 16 bits of the SNAP protocol discriminator indicated an > Ethernet protocol type; and > > (2) The format of the data part of the SNAP packet was the same as the > format of the data part of the Ethernet packet of this protocol type. > > This "general agreement," as far as I know, was never written down. > AppleTalk Phase 2 and TCP/IP both adopted this convention. Well, not exactly. Normal AppleTalk Phase 2 (AT2) DDP datagrams are encapsulated using an OUI of 080007, which I assume has been assigned to Apple. Only AT2 ARP frames use an OUI of zero. (Both use the Ethertype for the last two bytes.) I'm sure there's a good explanation for this, but I'll admit it puzzles me. So, as we've observed, AT2 DDP frames travel across a pair of Ethernet-to-FDDI bridges just fine, and are received properly by AT2 devices on the second Ethernet. This works because the bridge sees the non-zero OUI and simply leaves the frame untouched. AT2 AARP frames fail, however. Because the bridge assumes that any zero-OUI frame on the FDDI was originally an Ethernet-format frame that was translated to 802.2/SNAP, it retranslates such a frame back to Ethernet format when it forwards it onto the Ethernet. An AT2 station ignores an Ethernet-encapsulated AARP, since it's only looking for 802.2/SNAP. Now, as Vernon points out: > It should be noted in passing that following is in the Host Requirements > standard, RFC-1122: > > ] 2.3.3 Ethernet and IEEE 802 Encapsulation > ] ... > ] Every Internet host connected to a 10Mbps Ethernet cable: > ] > ] o MUST be able to send and receive packets using RFC-894 > ] encapsulation; > ] > ] o SHOULD be able to receive RFC-1042 packets, intermixed > ] with RFC-894 packets; and > ] > ] o MAY be able to send packets using RFC-1042 encapsulation. This ensures that IP stations, even if they prefer RFC-1042 (SNAP with zero OUI) format, will properly receive Ethernet format. Of course, as Vernon notes, it effectively prevents RFC-1042 from ever being the preferred format. John and Alan continue: > Thus for a TCP/IP Ethernet node to communicate with a TCP/IP 802.2 > node (on token ring or FDDI, say), some type of packet translation > must be performed, whereas for an AppleTalk Phase 2 Ethernet node to > communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet, > token ring or FDDI) no such translation need occur (in fact, such > translation MUST NOT occur). This makes it somewhat difficult to > build a bridge that "transparently" allows both forms of > communication. However all that really has to be done is for the > bridge to contain a small table of Ethernet protocol types that either > should, or shouldnUt be translated in this manner. Obviously the > smaller the table, and the less translation done, the better the > overall performance. The combination of AppleTalks Phase 1 and 2, however, presents a sticky situation for a such a bridge, where even the translation-table method won't work. After translation into 802.2/SNAP, an AT1 AARP frame is identical to an AT2 AARP frame (except for destination MAC address). If the bridge, while forwarding from the 802 medium to Ethernet/802.3, translates a zero-OUI, Ethertype 80F3 frame to Ethernet encapsulation, AT2 breaks. If it leaves it unchanged, AT1 breaks. The bridge could dig even further, of course, to determine whether the destination MAC address is broadcast (AT1) or multicast (AT2). Apple could solve the problem by fiddling with AT2 to either: 1) make AT2 stations receive Ethernet-encapsulated AARPs, or 2) use the Apple OUI for AARPs as well as DDPs. Or we could all resign ourselves to using routers to connect between heterogeneous LANs, which is probably the moral of this whole story. - RL "Bob" Morgan Networking Systems Stanford
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 21:06:36 GMT From: ladcgw.ladc.bull.com!hermes!fmayhar@uunet.uu.net (Frank Mayhar) To: tcp-ip@nic.ddn.mil Subject: Documentation for the BSD lpd protocol?
Does anyone know if this exists, and where it can be found? We've tried the
RFCs and it's not there. We have to source to lpr/lpd, but it would be nice if
we could get documentation for the protocol itself, since we want to support
it on a non-Unix platform.
Thanks in advance.
--
Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
Bull HN Information Systems Inc. Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 21:33:35 GMT From: usc!snorkelwacker!spdcc!eli@ucsd.edu (Steve Elias) To: tcp-ip@nic.ddn.mil Subject: call fo discussion: comp.dcom.fax
this is a call for discussion for a newsgroup called "comp.dcom.fax", or just comp.fax. there is currently an "alt.fax" newsgroup, but it's my humble homey opinion that fax technology is real enough and interesting enough to warrant a "real" technical newsgroup. fax technology involves modems, graphics, printing, bus interfaces, serial port interfaces, email, and "fax over internet". etcetera. i think that comp.fax might be a better idea than comp.dcom.fax, since there are some fax issues which have zero to do with datacomm, such as graphics-ish stuff like dithering, and tcp-ish stuff like email2fax and fax2email. perhaps these issues can be discussed individually in the "most relevant" newsgroup for each area listed above. and perhaps the alt.fax group does have enough "propagation" such that it will do the job. but if a comp.fax group would include more people in the discussions, i think it's worth considering. what do you think? please follow up to news.groups. also, feel free to send junk (or funk) faxes to 508 294 0101 or 508 294 7447. -- /eli eli@spdcc.com
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Jul 90 03:45:10 EDT From: R17G000 <R17G@UNB.CA> To: <TCP-IP@NIC.DDN.MIL> Cc: Aziz Zoman <R17G@UNB.CA> Subject: Unix POP3 mail client?
> Any pointers to source for a BSD Unix POP3 mail client? I've found several
> servers, but no clients. - Brian
Clemson university has developed a POP3 server and client. The POP3
client implementation is for MS-DOS. They are available at:
eng.clemson.edu
---------------------------------------------------------------+
Abdulaziz Al-Zoman | R17G@UNB |
School of Computer Science | -or- |
University of New Brunswick | r17g@unb.ca |
F'ton, N.B | -or- |
CANADA E3B 5A3 | r17g@unb.bitnet |
---------------------------------------------------------------+
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 20 Jul 90 23:59:37 GMT From: oliveb!orc!inews!cadev5!swilhel@apple.com (Spence Wilhelm) To: tcp-ip@nic.ddn.mil Subject: Multinet TCP/IP
Has anyone had experience with Multinet TCP/IP for VAX VMS? I would appreciate any information you have regarding their support and service. Spence Wilhelm Intel Corporation swilhel@cadev4.intel.com Chandler, Arizona KB5CYX (602)554-5050 "Possibly the horror that Zaphod experienced at the prospect of being reunited with his deceased relatives led on to the thought that they might just feel the same way about him..."
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 90 00:25:32 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: Documentation for the BSD lpd protocol?
In article <1990Jul20.210636.14924@ladc.bull.com> fmayhar@hermes.ladc.bull.com (Frank Mayhar) writes: Does anyone know if this exists, and where it can be found? We've tried the RFCs and it's not there. We have to source to lpr/lpd, but it would be nice if we could get documentation for the protocol itself, since we want to support it on a non-Unix platform. sun.soe.clarkson.edu:/pub/ka9q/lprspec.txt -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 In Communism's central planning, citizens are told "you will make widgets". In Capitalism's advertising, citizens are told "you will buy widgets".
-----------[000268][next][prev][last][first]----------------------------------------------------
Date: 21 Jul 90 02:15:25 GMT
From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
To: comp.protocols.tcp-ip
Subject: Re: How to get RFC documentsR Kevin Oberman writes: > Please be polite and enter your real ID if that's what is asked for. I can't speak about NIC.DDN.MIL, but the other site Jon mentioned, NIS.NSF.NET, *requires* the use of guest as a password for anonymous. Otherwise, it won't let you on. This is quite disconcerting for those of us who may type ahead the anonymous login sequence. Presumably the IBM they use has !@#$% software that is not configurable. It certainly has a *terrible* implementation of TCP/IP. Bill Simpson 09998was@ibm.cl.msu.edu
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 90 03:52:21 GMT From: ss01!jsm@princeton.edu (John Scott McCauley Jr.) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <9007210040.AA28109@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: > >As part of a distributed computing experiment, we are considering >setting up a Sun workstation, with a bi-metallic strip and small coil >tempearture device, and providing a network wide reading, combined >with time of day service and cartesian location data. > What ever happened to 'finger weather@hermes.ai.mit.edu'? This reported the wind speed and temperature at the top of Tech^2, at MIT. There was also 'finger coke@a.cmu.edu' which reported the status of a coke machine at CMU. Scott P.S. Don't come here -- some things here are hotter than 30 keV.
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Jul 1990 08:39-EDT From: Alessandro.Forin@SPICE.CS.CMU.EDU To: tcp-ip@nic.ddn.mil Cc: Eddie.Caplan@CS.CMU.EDU Subject: Re: interesting uses of networking
The old 'coke' program that once ran in our department has been
resurvived and extended. Its major lack in functionality is now
covered, and the program appropriately renamed "jf" (junk food).
The man pages for jf and xmnm are included.
Enquiries about this important progress of the Computer Science
field should be directed to eddie.
sandro-
-----------------------------------------------------------------------------
JF(6/22/90) UNIX Programmer's Manual JF(6/22/90)
NAME
jf - Inquire about availability of junk foods in CMU CS
vending machines.
SYNOPSIS
jf [coke | mnm | mm ] [-reset]
DESCRIPTION
jf inquires about the availability of Coke/Diet-Coke and
M&Ms in the CMU CS vending area to save addicts an abortive
trip from their distant offices.
With no argument or with single argument coke jf gives the
status of the buttons of 16oz bottles in the CMU CS Coke
machine. With argument mnm or mm it will give an estimate
of the number of servings of M&Ms left in the vending
machine.
Providing an argument to identify the machine and the argu-
ment -reset allows the vending machine fillers to inform the
server when the machines have been refilled. This is
currently applicable only to the M&M machine because the
Coke interface is essentially self-monitoring. Proper
credentials are requested before a reset may be performed.
BUGS
As of 22-June-90, only the M&M interface is working. The
Coke interface is still being prepared.
SEE ALSO
xmnm(1)
HISTORY
22-Jun-90 eddie caplan (egc) at Carnegie Mellon University
Updated man entry to reflect the new Coke machine con-
figuration. Added BUGS section while the Coke inter-
face is down.
29-Oct-85 Ivor Durham (id) at Carnegie Mellon University
Created man entry. Client and server software by David
Nichols with contributions from Ivor Durham. Coke
machine interface by John Zsarnay and M&M machine
interface by Mark Zaremsky.
-----------------------------------------------------------------------------
XMNM(6/22/90) UNIX Programmer's Manual XMNM(6/22/90)
NAME
xmnm - X11 program to monitor the availability of M&Ms.
SYNOPSIS
xmnm [-update <rate>] [-shape | -noshape] [X11 switches]
DESCRIPTION
Using an X11 window, xmnm graphically and continuously
inquires about the availability of M&Ms in the CMU CS vend-
ing area to save addicts an abortive trip from their distant
offices.
With no -update argument xmnm will check the status of the
M&M machine every 1200 seconds (20 minutes). By providing
the -update argument, users can cause the status to be
checked less or more frequently. To keep the junk food
server from becoming flooded with status requests, xmnm
enforces a minimum sleeptime of 60 seconds.
The -shape and -noshape arguments indicate whether the X
window should take on the form of the M&M machine. By
default, shaping will not be done.
COMMANDS
Clicking any of the mouse buttons in the M&M window will
cause an update to occur. That is, the junk food server
will be queried.
BUGS
Shaping just doesn't work sometimes, even though the
software thinks it can be done. Different window managers,
mismatched versions of X, etc. can all contribute to the
problem.
SEE ALSO
jf(1), X(1)
HISTORY
9-Jul-90 eddie caplan (egc) at Carnegie Mellon University
Created man entry.
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Sat, 21 Jul 90 13:20:14 PDT From: earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) To: beau@Ultra.COM, comp.protocols.tcp-ip Cc: tcp-ip@nic.DDN.MIL Subject: Re: UDP checksums
In comp.protocols.tcp-ip article <1990Jul17.003242.1556@ultra.com> you write: >In <5@wotk.UUCP> root@wotk.UUCP (Superuser) writes: >>Does anyone know how to enable UDP checksums on a Sun 360. > > # adb -k /vmunix /dev/mem > ... > udp_cksum/W 1 ; Enables UDP checksums on the running kernel > udp_cksum?W 1 ; Enables whenever this kernel is booted Careful Beau. This is true for SunOS 4.1, but for SunOS 4.0.3 and earlier SunOS releases, the variable is "udpcksum" (no helpful underscore (^: ) Also, you need to say "adb -w -k /vmunix /dev/mem" or else your attempts to write the new values will be somewhat futile ... (^: -- -- Greg Earle | "This is Kraft. It uses a blue box. Sun Microsystems, Inc. | This is Stouffer's. It uses red. earle@poseur.JPL.NASA.GOV | The choice is yours." earle@Sun.COM | Pretty damn convincing argument, eh?
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 90 12:39:00 GMT From: Alessandro.Forin@SPICE.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: interesting uses of networking
The old 'coke' program that once ran in our department has been
resurvived and extended. Its major lack in functionality is now
covered, and the program appropriately renamed "jf" (junk food).
The man pages for jf and xmnm are included.
Enquiries about this important progress of the Computer Science
field should be directed to eddie.
sandro-
-----------------------------------------------------------------------------
JF(6/22/90) UNIX Programmer's Manual JF(6/22/90)
NAME
jf - Inquire about availability of junk foods in CMU CS
vending machines.
SYNOPSIS
jf [coke | mnm | mm ] [-reset]
DESCRIPTION
jf inquires about the availability of Coke/Diet-Coke and
M&Ms in the CMU CS vending area to save addicts an abortive
trip from their distant offices.
With no argument or with single argument coke jf gives the
status of the buttons of 16oz bottles in the CMU CS Coke
machine. With argument mnm or mm it will give an estimate
of the number of servings of M&Ms left in the vending
machine.
Providing an argument to identify the machine and the argu-
ment -reset allows the vending machine fillers to inform the
server when the machines have been refilled. This is
currently applicable only to the M&M machine because the
Coke interface is essentially self-monitoring. Proper
credentials are requested before a reset may be performed.
BUGS
As of 22-June-90, only the M&M interface is working. The
Coke interface is still being prepared.
SEE ALSO
xmnm(1)
HISTORY
22-Jun-90 eddie caplan (egc) at Carnegie Mellon University
Updated man entry to reflect the new Coke machine con-
figuration. Added BUGS section while the Coke inter-
face is down.
29-Oct-85 Ivor Durham (id) at Carnegie Mellon University
Created man entry. Client and server software by David
Nichols with contributions from Ivor Durham. Coke
machine interface by John Zsarnay and M&M machine
interface by Mark Zaremsky.
-----------------------------------------------------------------------------
XMNM(6/22/90) UNIX Programmer's Manual XMNM(6/22/90)
NAME
xmnm - X11 program to monitor the availability of M&Ms.
SYNOPSIS
xmnm [-update <rate>] [-shape | -noshape] [X11 switches]
DESCRIPTION
Using an X11 window, xmnm graphically and continuously
inquires about the availability of M&Ms in the CMU CS vend-
ing area to save addicts an abortive trip from their distant
offices.
With no -update argument xmnm will check the status of the
M&M machine every 1200 seconds (20 minutes). By providing
the -update argument, users can cause the status to be
checked less or more frequently. To keep the junk food
server from becoming flooded with status requests, xmnm
enforces a minimum sleeptime of 60 seconds.
The -shape and -noshape arguments indicate whether the X
window should take on the form of the M&M machine. By
default, shaping will not be done.
COMMANDS
Clicking any of the mouse buttons in the M&M window will
cause an update to occur. That is, the junk food server
will be queried.
BUGS
Shaping just doesn't work sometimes, even though the
software thinks it can be done. Different window managers,
mismatched versions of X, etc. can all contribute to the
problem.
SEE ALSO
jf(1), X(1)
HISTORY
9-Jul-90 eddie caplan (egc) at Carnegie Mellon University
Created man entry.
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 90 17:33:33 GMT From: auspex!guy@uunet.uu.net (Guy Harris) To: tcp-ip@nic.ddn.mil Subject: Re: How to get RFC documents dealing with TCP-IP
> My experience is that you don't get prompted for your real ID until >after it is too late. Maybe it's just my ftp implementation (SunOS-3.5.2 >and MtXinu 4.3BSD systems) I think it is. I don't know where the problem exists, but I seem to remember seeing this start working more correctly, perhaps correlated with a switch from a 4.2BSD-flavored implementation to a 4.3BSD-flavored implementation. Of course, if the implementations are reasonably vanilla 4.xBSD ones, they don't do anything with the identification anyway....
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 21 Jul 90 18:38:44 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Routing Loop
In article <9007202250.AA03920@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: > Is anyone familiar with the following nodes: 192.80.214.1 and 192.80.214.254? > An nslookup PTR query returns a non-existent domain error. The nodes appear > to be between the College Park Md NSF backbone node and SURANET. > > As of 1400 PDT the nodes were involved in a routing loop. A traceroute from > our site to wraith.wtp.contel.com, issm.iss.contel.com, or sccgate.scc.com > our Rightist brethren would reach College Park and then bounce back and forth > between the two nodes. Somebody should be a bit embarassed by this. 192.80.214 is a class-c network at FIX-East, the government "meeting the the nets" at SURANET offices near UMD. I can't speak for the cause of the loop, but it explains some problems I've been seeing of late in getting to some SE US sites. And the lack of inverse name entries is inexcusable unless there is some technical reason which I can't fathom. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Jul 90 06:21:15 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: tcp-ip@nic.ddn.mil, ucrmath!spahn!stebbins@ucsd.edu Cc: stebbins@137.67.5.1 Subject: Re: Possible routing problem.
John: It appears that the Sun system (ucrmath.ucr.edu) requires you to provide a <CR> or two before it provides the login in prompt. At least its required when connecting from a 4.3BSD system. Merton
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 90 01:33:08 GMT From: ucrmath!spahn!stebbins@ucsd.edu (john stebbins) To: tcp-ip@nic.ddn.mil Subject: Possible routing problem.
I just installed WIN/TCP 5.1 and am having a problem getting to one
particular node on the inet. I've tried several other nodes and have
been successful on all of them. Here's the particulars. Our node accesses
the outside world through a gateway. I have run route:
route add default <gateway> 1
That seems to get me everywhere but where I want to go. I'm trying to
reach ucrmath.ucr.edu (192.31.146.1). It uses a gateway at ucsd.edu
(128.54.16.1). What I get when I try to telnet in is:
Connected to 192.31.146.1
escape sequence is ^]
Then no login prompt. It just sits there until my end times out.
I believe that the ucrmath end of things is functioning properly
because other people I know say that they have had no problem using
it. If it is a routing problem, the next question is, is there
some list of routes available somewhere so that I can do this once
and be done with it forever? Is there some other piece of software
I should be running that takes care of this problem for me?
The extent of my knowledge is only what I've been able to cram into
my head in the last 3 days, so assume I'm a novice and explain things
carefully if you respond to this. Thanks in advance.
John Stebbins
stebbins@ucrmath.ucr.edu (school)
stebbins@137.67.5.1 (work {this is where I am most of the time})
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 90 06:43:37 GMT From: pacbell.com!tandem!moe!kevinr@ucsd.edu (Kevin J. Rowett) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP on Packet Radio
In article <1990Jul20.123843.11703@pmsmam.uucp>, wwm@pmsmam.uucp (Bill Meahan) writes: |> speed schemes. Some enterprising types have gotten 2Mb on microwave. Someone Ring? N6RCE
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Jul 90 13:09:10 GMT From: Mills@udel.edu To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> Cc: tcp-ip@nic.ddn.mil, discussion@cs.ucl.ac.uk Subject: Re: Network Temperature Protocol
jon, You don't need the bimetallic strip, just use the frequency-compensation variable maintained by the Network Termperature Protocol. Of course, you will need to calibrate your individual workstation quartz oscillator against temperature, which you should insist be included in the specifications of the workstation. With the local-clock model defined in N Time P Version 3, the coefficient of temperature shoulc be in the order of 2500 per degree C. Dennis Ferguson has already calibrated his workstation, which apparently is not environmentally controlled. That gives you Ontario. You will need other volunteers who agree to chime NTP and operate their workstation in ambient environmental conditions. We should expect objections and very little data from McMurdo Station. Heck, you can expect objections from Delaware. Dave
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: Sun, 22 Jul 90 17:59:36 GMT From: Mills@udel.edu To: louie@sayshell.umd.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Folks, Louie refers to an incident where an NTP primary time server, perched almost atop the Loma Pietra fault, mysteriously abandonded chime a couple of minutes BEFORE the recent quake. We were tempted to investigate application of NTP as earthquake predictor, until we learned that a fortuitous power failure within BARRNET happened to quench its chime. Now, we are concentrating on the nature of that precipitous failure as a possible earthwuake predictor. Meanwhile, on the night of the quake, NTP turned out to be a useful monitoring tool and provided much comfort that at least computers in the area, much less people, were safe and that circuits out the Pacific were still operation. Actually, what that was doing was confirming that the NASA Ames massive single point of failure was still up. A UPS failure there later in the evening conked out the entire Pacific. Dave
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 90 18:23:43 GMT From: ucrmath!gibson!stebbins@ucsd.edu (john stebbins) To: tcp-ip@nic.ddn.mil Subject: Re: Possible routing problem.
In article <9007221321.AA06463@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: |> John: |> |> It appears that the Sun system (ucrmath.ucr.edu) requires you to provide a |> <CR> or two before it provides the login in prompt. At least its required |> when connecting from a 4.3BSD system. |> |> Merton I tried the above and still got no response. I did try this before, but I thought I'd recheck since someone else thought of it too. Thanks for the effort. John stebbins stebbins@ucrmath.ucr.edu (school) stebbins@137.67.5.1 (work)
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 90 20:17:45 GMT From: rothstein@NUTMEG.Enet.DEC.com (Lee Rothstein, 603-884-0039) To: alt.fax,comp.protocols.tcp-ip Subject: Re: fax relaying protocols
In article <3410@ursa-major.SPDCC.COM>, eli@spdcc.COM (Steve
Elias) writes...
> sam@ucbvax.BERKELEY.EDU (Sam Leffler) writes:
>>Are there any standards (ad hoc or otherwise) for the protocols that
>>vendors use to implement relaying? By relaying, I mean the ability
>>to transmit a fax to a machine that then resends it to one or more
>>destinations. This is done to cut down on phone costs; i.e. make one
>>long distance phone call to a machine that then relays the document
>>with local calls.
..
>i'm not even sure which parts of fax gatewaying or fax "repeating"
>would warrant standardization. perhaps IETF ought to discuss this issue...
At the risk of revealing that I haven't understood much prior
discussion both in alt.fax and elsewhere in the industry, I
believe that the entire point of Group IV facsimile is to allow
the use of store and forward computer networks. Now, this may
not be exactly what Sam Leffler had in mind, but it's a starting
point.
Recently there has been another copntribution to store and
forward facsimile. The X.400 Application Programming Interface
Association (XAPIA) has issued standards for gateway interfaces
for both Group III and Group IV facsimile devices. A gateway
interface spec implies interfacing facsimile devices to the MTA
(message transport agent). XAPIA is supported by most of the
major email vendors: Digital, Retix, AT&T, Telemail ... X/OPEN
has also agreed to mutually support the XAPIA standards.
More recently, I read a paper by a Japanese company (Fujitsu?)
in which they deal with facsimile devices as yet another type of
desktop device requiring interface to the UA (user agent) of an
X.400 MHS (message handling system).
The TCP/IP folk, as evidenced by recent disdcussion in alt.fax,
are also working on a standrad for interface of fax to email.
+---------------------------------------------------------+
| Lee Rothstein * UUCP: {purdue,ucbvax,hplabs,labrea,sun, |
| pyramid,gryphon,angelo}!decwrl!nutmeg.dec.com!rothstein|
| * Arpa/Domain Address: rothstein@nutmeg.enet.dec.com |
+---------------------------------------------------------+
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 22 Jul 90 20:55:06 GMT From: dino!cs.iastate.edu!hascall@uunet.uu.net (John Hascall) To: tcp-ip@nic.ddn.mil Subject: Telnet options XDISPLOC & NAWS (& #34)
SYN:
I've just finished adding support for the TELNET options XDISPLOC
(X Display Location - RFC1096) and NAWS (Window Size - RFC 1073) to our
telnet/telnetd (for DECstations/Ultrix 3.1) and was wondering if anyone
else implements these options (there seem to be no examples on campus).
Also, I couldn't find any mention of what telnet option #34 is, was
this number just skipped or what?
Also, I was curious about just which options *are* common?
Binary, echo, and sga? Ttype? Others?
John Hascall
john@iastate.edu | hascall@atanasoff.cs.iastate.edu
FIN
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 04:55:40 EDT From: oleary@umd5.umd.edu (dave o'leary) To: tcp-ip@nic.ddn.mil Subject: Status of FIX-East/SURAnet move/Contel routing loop, etc.
Hi everybody. Here's the scoop on the reported problems. I think it is fixed, if it isn't please let me know by dropping a note to ops@noc.sura.net or calling us at our new network operations center, (301)982-3214. Our move is basically completed now. It didn't go as smoothly as we had hoped, but it is almost over now anyway. Sorry about any problems that were encountered during the last two weeks due to the move. If you want to know the status of FIX East drop me a note. ## From: oberman@rogue.llnl.gov ## Subject: Re: Routing Loop ## Date: 21 Jul 90 18:38:44 GMT ## Sender: usenet@lll-winken.LLNL.GOV ## Organization: Lawrence Livermore National Laboratory ## ## In article <9007202250.AA03920@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM ## (Merton Campbell Crockett) writes: ## > Is anyone familiar with the following nodes: 192.80.214.1 and ## > 192.80.214.254? Familiar? Well, I know what machines answer those addresses anyway. 192.80.214.254 is the new address of the NSS on the FIX ethernet. 192.80.214.1 is a Proteon P4200 connecting into SURAnet. ## > An nslookup PTR query returns a non-existent domain error. The nodes ## > appear to be between the College Park Md NSF backbone node and SURANET. ## > ## > As of 1400 PDT the nodes were involved in a routing loop. A traceroute ## > from our site to wraith.wtp.contel.com, issm.iss.contel.com, or ## > sccgate.scc.com our Rightist brethren would reach College Park and then ## > bounce back and forth between the two nodes. The T1 from our NOC to Contel was cutover to the new site Friday afternoon, and there were lots-o-bit errors. It took a while to get it cleaned up but it should be working and stable since early this morning our time. I expect the route was flapping quite a bit, and slow EGP time outs, and default routing, and all that stuff...well, routing loops happen. Many thanks to Bob Enger and Mike Powell at Contel for their help and patience Friday night. ## ## Somebody should be a bit embarassed by this. 192.80.214 is a class-c ## network at FIX-East, the government "meeting the the nets" at SURANET ## offices near UMD. ## ## I can't speak for the cause of the loop, but it explains some problems I've ## been seeing of late in getting to some SE US sites. And the lack of inverse ## name entries is inexcusable unless there is some technical reason which I ## can't fathom. The lack of reverse DNS was, pure and simply due to my lack of applying for the domain. Ths oversight has been corrected and the servers should be working Real Soon Now. Again, we are very sorry to those individuals who were inconvenienced during our move. ## R. Kevin Oberman ## Lawrence Livermore National Laboratory ## Internet: oberman@icdc.llnl.gov ## (415) 422-6955 ## ## Disclaimer: Don't take this too seriously. I just like to improve my typing ## and probably don't really know anything useful about anything. Something that distressed me during the cutover was watching the FIX ethernet and seeing some hard core pinging going on - hundreds and thousands of pings to nodes that were unreachable (no echo replies...) from all over the place. Throughout much of last week during the cutover we were suffering from severe congestion on links between our old and new offices. To these irresponsible pingers (probably not Kevin or MCC): I'm sure SURAnet's customers appreciated your "troubleshooting" of our network during this time of scarce bandwidth. Please be considerate in the future. Run abusive throughput tests only at night, if at all. Thanks, dave o'leary SURAnet NOC Manager
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 02:33:26 GMT From: rbn@umd5.umd.edu (Ron Natalie) To: tcp-ip@nic.ddn.mil Subject: Re: Possible routing problem.
This is probably one of those implementations that insists on looking up you IP address and resolving it to a name before going any farther. You're new machine probably is not in the IN-ADDR domain tree or the servers are placed such that the name is not easily resolvable. It just wastes time trying to figure it out. -Ron
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 09:21:18 -0400 From: bdr@ifs.umich.edu To: tcp-ip@nic.ddn.mil Subject: unsubscribe
please remove me from this list. thanks
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 10:03:31 PDT From: postel@venera.isi.edu To: dino!cs.iastate.edu!hascall@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: Telnet options XDISPLOC & NAWS (& #34)
See page 51 of rfc-1060. --jon.
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 11:19:57 -0400 (EDT) From: Craig_Everhart@transarc.com To: tcp-ip@nic.ddn.mil, smart@mel.dit.csiro.au (Robert Smart) Cc: nsb@thumper.bellcore.com Subject: Re: Come on guys, we've got to improve e-mail
For years I've been using an RFC{821,822}-compliant Internet mail system
that does almost all of what you suggest.
Check out RFC 1049 and its commentators.
Get yourself an Andrew source distribution from the X.V11R4
distribution. There's a mail system that supports automatic
confirmation requests from users, among other things. Its design
sidesteps privacy issues, since return-receipt notices go out only after
explicit confirmation with the receiving human user, and it's understood
that you don't get a NAK from any transport agent.
The Andrew mail stuff uses altered content-type information to embed any
ATK (Andrew ToolKit) object, presently including raster and line
graphics, line animations, styled and marked-up text, simple other-file
references, and so forth.
Soapbox aside, I think there's a lot of current work on improving e-mail
services (PEM, for example) that you're simply ignoring.
Craig
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 08:42:42 EDT From: Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET> To: J.Crowcroft@CS.UCL.AC.UK, Mills@LOUIE.UDEL.EDU Cc: discussion@CS.UCL.AC.UK, tcp-ip@NIC.DDN.MIL Subject: Re: Network Temperature Protocol
> From tcp-ip-RELAY@NIC.DDN.MIL Mon Jul 23 07:55:00 1990 > From: Mills@udel.edu > To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> > Cc: tcp-ip@nic.ddn.mil, discussion@cs.ucl.ac.uk > Subject: Re: Network Temperature Protocol > > jon, > <stuff deleted> > > You will need other > volunteers who agree to chime NTP and operate their workstation in ambient > environmental conditions. > > We should expect objections and very little data from McMurdo Station. Heck, > you can expect objections from Delaware. > > Dave > Dave, I'm afraid that your scheme probably won't work in New England (about 20 Miles West of Boston) in the summer. The machines would need to be sealed against humidity and other gunk in the "Ambient Environment" (I wonder what ozone, water, and various unburned and partially burned hydrocarbons would do to the insides of a Sparcstation?:-(. You would then have to pump cooled air into the machine so that it doesn't melt from the heat, defeating the whole purpose of the scheme. Of course, even if the machine could stand the outside, I doubt that the person sitting at the keyboard could - unless s/he is a chain-smoking sauna freak. Air Conditioning-ly Yours Frank Kastenholz Racal Interlan
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 12:08:48 PDT From: postel@venera.isi.edu To: CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu Cc: TCP-IP@nic.ddn.mil Subject: Is underscore legal in the local-part of an address?
Hi. You are right, he is wrong. --jon. ----- Begin Included Message ----- Date: Mon, 23 Jul 90 10:38 CDT From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu> Subject: Is underscore legal in the local-part of an address? To: TCP-IP@NIC.DDN.MIL Sorry about posting here, feel free to aim me at a better list... At least one of the INTERBIT (Internet-to-BITNET) gateways is rejecting addresses which contain an underscore. The postmaster at the gateway says that this is because his software correctly implements RFC821 which restricts addresses to letters, numbers, and hyphens. I have checked the RFC and it seems to be a little less restrictive than that. Have I missed something? Thanks for any help/pointers, Mike Califf (POSTMAST[ER]) Communications Software Coord Internet: califfm@baylor.edu Baylor University C.C.I.S. Bitnet: CALIFFM@BAYLOR ----- End Included Message -----
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 10:38 CDT From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu> To: TCP-IP@NIC.DDN.MIL Subject: Is underscore legal in the local-part of an address?
Sorry about posting here, feel free to aim me at a better list... At least one of the INTERBIT (Internet-to-BITNET) gateways is rejecting addresses which contain an underscore. The postmaster at the gateway says that this is because his software correctly implements RFC821 which restricts addresses to letters, numbers, and hyphens. I have checked the RFC and it seems to be a little less restrictive than that. Have I missed something? Thanks for any help/pointers, Mike Califf (POSTMAST[ER]) Communications Software Coord Internet: califfm@baylor.edu Baylor University C.C.I.S. Bitnet: CALIFFM@BAYLOR
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 09:55:14 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: bzs@world.std.com (Barry Shein) Cc: tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu Subject: Re: Beginner's info TCP & UDP
One point I would add, Barry: You (or another ranking net.guru) would be quite capable of recognizing a special case of the sort you posit, and using UDP appropriately. However, you might miss the telltale glint in your customer's eyes when you told him "alternative X can be done in half the time, but it restricts the product to single Ethernets". The consequences of trying to hack a 'one-cable' design into a 'coast-to-coast' application are painful to the whole network. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 13:02:07 PDT From: postel@venera.isi.edu To: CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Is underscore legal in the local-part of an address?
Oh. In that case, you are wrong, and he is right. --jon. ----- Begin Included Message ----- Date: Mon, 23 Jul 90 11:19 CDT From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu> Subject: Re: Is underscore legal in the local-part of an address? To: TCP-IP@NIC.DDN.MIL Don't Panic - It turns out that the INTERBIT site which was rejecting the messages is rejecting them based on the (illegal) underscore in the domain part of the address, NOT the (legal) underscore in the local-part. I am taking measures locally to remove/replace the underscores from the offending node names. That'll teach me to O.K. node names before fully parsing the RFC's :-) Sorry about that, Mike Califf (POSTMAST[ER]) Communications Software Coord Internet: califfm@baylor.edu Baylor University C.C.I.S. Bitnet: CALIFFM@BAYLOR ----- End Included Message -----
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 11:19 CDT From: Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu> To: TCP-IP@NIC.DDN.MIL Subject: Re: Is underscore legal in the local-part of an address?
Don't Panic - It turns out that the INTERBIT site which was rejecting the messages is rejecting them based on the (illegal) underscore in the domain part of the address, NOT the (legal) underscore in the local-part. I am taking measures locally to remove/replace the underscores from the offending node names. That'll teach me to O.K. node names before fully parsing the RFC's :-) Sorry about that, Mike Califf (POSTMAST[ER]) Communications Software Coord Internet: califfm@baylor.edu Baylor University C.C.I.S. Bitnet: CALIFFM@BAYLOR
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 14:10:47 -0400 From: bzs@world.std.com (Barry Shein) To: jbvb@vax.ftp.com Cc: tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uwm.edu!srcsip!knowledge!pclark@tut.cis.ohio-state.edu Subject: Beginner's info TCP & UDP
From: jbvb@vax.ftp.com (James B. Van Bokkelen)
>One point I would add, Barry: You (or another ranking net.guru) would
>be quite capable of recognizing a special case of the sort you posit,
>and using UDP appropriately. However, you might miss the telltale
>glint in your customer's eyes when you told him "alternative X can be
>done in half the time, but it restricts the product to single
>Ethernets". The consequences of trying to hack a 'one-cable' design
>into a 'coast-to-coast' application are painful to the whole network.
The penalty for stupidity is death. Glints in the eye merely carry
heavy fines.
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 20:36:21 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: postel@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Jon: The major problem with the TQP specification are in the examples at the end of the RFC. The +22 is excesively warm--the -3 is more appropriate of the two examples. There is enough medical evidence to suggest that +22 is not conducive to mental activity. MCC
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 08:59:58 GMT From: eru!luth!sunic!mcsun!cernvax!chx400!unizh!unizh.ifi.unizh.ch!zhou@bloom-beacon.mit.edu ( ass bei richter) To: tcp-ip@nic.ddn.mil Subject: RPC Server
I have run into difficulties in implementing a distributed algorthm using rpc(socket) in a sunstation network. My problems are: 1. How could I set up SERVERS among suns. Is it enough to set up one server among serveral related machines? How? (My algorithm needs to send packets to serveral suns.) 2. In a RPC manual, there is an example which said a server is needed to be able to run properly. But I tried to run it without server, it did works too. Is a server necessary for all socket(lower) level applications? 3. Could I get some real application source code from you? Any comments any pointers are greatly appreciated!!
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 17:48:54 PDT From: postel@venera.isi.edu To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Network Working Group J. Postel
Request for Comments: XXXX ISI
July 1990
Temperature Quote Protocol
Status of this Memo
This RFC suggests an Experimental Protocol for the Internet community.
Hosts on the Internet that choose to implement a Temperature Quote
Protocol are encouraged to experiment with this protocol.
Introduction
A useful debugging and measurement tool is a temperature quote
service. A temperature quote service simply sends a short message
(the temperature) without regard to the input.
TCP Based Temperature Quote Service
One temperature quote service is defined as a connection based
application on TCP. A server listens for TCP connections on TCP port
16. Once a connection is established a short message (the
temperature) is sent out the connection (and any data received is
thrown away). The service closes the connection after sending the
quote.
UDP Based Temperature Quote Service
Another temperature quote service is defined as a datagram based
application on UDP. A server listens for UDP datagrams on UDP port
16. When a datagram is received, an answering datagram is sent
containing the temperature (the data in the received datagram is
ignored).
Temperature Syntax and Semantics
The temperature quote is the current temperature at the location of
the server reported in degrees Celsius (or centigrade).
It is transmitted as decimal digits represented as ASCII printing
characters, preceded with a plus or a minus sign.
Examples:
+22 ; a pleasant temperature for people
-3 ; a bit on the cool side
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 13:21:18 GMT From: bdr@IFS.UMICH.EDU To: comp.protocols.tcp-ip Subject: unsubscribe
please remove me from this list. thanks
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: Mon, 23 Jul 90 10:17:56 I From: ken-ichiro murakami <MURAKAMI%ntt-20.ntt.jp@RELAY.CS.NET> To: ucrmath!gibson!stebbins@UCSD.EDU Cc: tcp-ip@NIC.DDN.MIL Subject: Re: Possible routing problem.
John, TELNET negotiation failure may cause such problem. If your TELNET client(WIN?) has TELNET negotiation debug option, you could see what's going on. Hope this helps. -Ken Ken-ichiro Murakami NTT Laboratories Tokyo, Japan -------
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 20:19:37 GMT From: bacchus.pa.dec.com!kmeyer@decwrl.dec.com (Kraig Meyer) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: ||As part of a distributed computing experiment, we are considering ||setting up a Sun workstation, with a bi-metallic strip and small coil ||tempearture device, and providing a network wide reading, combined ||with time of day service and cartesian location data. The idea of being able to find out about a network node's environment has some good network management potential. Back when I was at Merit helping build the original Merit nodes, we started to design a module which would sense temperatures in and and nearby the processor cabinet. The idea was that an alarm in the NOC would sound when the temperature was outside of an appropriate range, and the NOC could call a human to either turn up the A/C, plug in a fan, or turn the node off. (A fair number of our original campus backbone nodes were in poorly cooled phone closets, broom closets, *steam tunnels*, etc. at the Univ. of Michigan). We also toyed with the idea of hooking up a computerized weather station to the RS-232 ports on some of our upstate nodes--we had found an extremely high correlation between certain DDS lines going out and thunderstorms on the western edge of the state. Might give us enough time to warn users :-) Neither project ever came to fruition, but I seem to remember that there were a couple sources for RS-232 interfaced weather stations (Edmund Scientific, perhaps?) And a simple temperature gauge is easy and relatively inexpensive to build--all that is needed is the appropriate thermistor, a basic analog-digital converter and some random electronics. If I remember correctly, you could hook the appropriate thermistor directly to the game paddle port on an Apple II and get relatively accurate temperature readings (and you could, of course, locate the thermistor any place you wanted). ***************************************************************************** Kraig Meyer kmeyer@wrl.dec.com On parole from the University of Southern California. All views expressed are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 21:00:56 GMT From: logicon.com!tots!tep@nosc.mil (Tom Perrine) To: tcp-ip@nic.ddn.mil Subject: Re: Come on guys, we've got to improve e-mail
In article <QaelKR30BwwOAC9N19@transarc.com> Craig_Everhart@TRANSARC.COM writes:
>For years I've been using an RFC{821,822}-compliant Internet mail system
>that does almost all of what you suggest.
>
>Check out RFC 1049 and its commentators.
>
>Get yourself an Andrew source distribution from the X.V11R4
>distribution. There's a mail system that supports automatic
>confirmation requests from users, among other things. Its design
>sidesteps privacy issues, since return-receipt notices go out only after
>explicit confirmation with the receiving human user, and it's understood
>that you don't get a NAK from any transport agent.
>
>The Andrew mail stuff uses altered content-type information to embed any
>ATK (Andrew ToolKit) object, presently including raster and line
>graphics, line animations, styled and marked-up text, simple other-file
>references, and so forth.
>
>Soapbox aside, I think there's a lot of current work on improving e-mail
>services (PEM, for example) that you're simply ignoring.
>
> Craig
Well, its a little tough for some of us to track every system out
there :-) Are any of the Andrew "extensions" documented in RFCs? What
I'm getting at is that the Andrew mail system, even though it may be
widely/freely available, may not be an *interoperable* mail system,
until the extensions and conventions it uses are documented in some
place other than the source code (or accompanying system
documentation).
Don't get me wrong! It sounds *wonderful*, but I can't run Andrew
here, but I *would* like to hack some extensions into Emacs RMAIL and
mail modes. Specifically I would like to generate (and parse) the
headers(?) that I need for return-receipt and any other non-graphical
functionality I can find.
Sorry to carrty on with this here, but I think that this point goes
beyond just mail issues.
Tom Perrine (tep) |Internet: tep@tots.Logicon.COM
Logicon |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division |-or- sun!suntan!tots!tep
San Diego CA |GENIE: T.PERRINE
"Harried: with preschoolers" |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 21:53:59 GMT From: gauss.llnl.gov@lll-winken.llnl.gov (Casey Leedom) To: tcp-ip@nic.ddn.mil Subject: Looking for a few good terminal servers ...
We have a rack of eight (8) high speed modems (Telebit T2500s). We're
looking for a high performance terminal server to hang these guys off
of.
I'd appreciate any input anyone, vendor or user, may have on terminal
servers you think would satisfy our needs (or should be avoided at all
costs.) Thanks in advance. Please send email directly to
casey@gauss.llnl.gov. I will summarize all responses. (If you ask not
to be included in the summary I will respect your wishes.)
Casey
-----
ABSOLUTE MUSTS:
1. There shall be a minimum of eight (8) EIA232 serial interfaces
and one (1) Ethernet interface.
2. Serial interfaces shall handle at least 38.4K bits/second on all
lines. If two terminal servers are equivalent in other features,
the one with the highest throughput (serial and Ethernet) will be
selected.
3. Serial interfaces shall support hardware modem control (DTR/CD)
and hardware flow control (RTS/CTS) simultaneously. (I.e don't
even bother talking to me about the Xylogics Annex I or Annex
II. The upcoming Annex IIe does fulfill this requirement
according to their marketing blurbs.)
4. Shall be able to set up completely transparent 8-bit clean
connections. Yes, I realize that once such a connection is set
up the user wouldn't be able to escape out to other sessions.
Tough. Some of our applications need a clear channel.
5. Shall support TCP/IP telnet protocol. Shall support BSD rlogin
protocol.
6. Shall support passworded logins.
7. Shall use BIND for host name lookup.
8. Shall listen to RIP for routing information.
9. Shall respect ICMP redirects.
10. Shall incorporate Van Jacobson/Michael Karels TCP/IP
improvements: Slow start, retransmit timing, round trip timer,
etc.
DESIRED FEATURES:
11. SLIP (RFC1055). It would be nice to be able to dial in and set
up a SLIP connection. Preferably this should be implemented
either with subnetting (which means the terminal server will
have to participate in RIP) or by the terminal server proxy ARPing
for the remotely connected SLIP host.
12. SLIP with header prediction (RFC1144). More performance for the
above ...
13. SNMP monitoring/setup. It's the wave of the future. If SNMP
setup is provided for, it shall be possible to restrict such
SNMP access to a restricted list of authorized hosts.
14. Respond to ICMP ECHO requests. Useful for determining if the
terminal server is up, etc.
15. AppleTalk/EtherTalk gateway capabilities. We have a lot of
people with Macintoshes at home who would like to dial in and
simply become part of the AppleTalk community for file sharing,
printing, etc. If such a facility is offered, it shall use
AppleTalk Phase II. (And no, I don't want to hear about Shiva
modems. We already have one high speed modem pool I don't see
any point at all in fragmenting our resources. If we need more
modems, I just want to toss them on the already existing GENERAL
PURPOSE modem pool.)
16. More than eight (8) EIA232 serial interfaces. We might want to
expand the modem pool in the future.
17. Greater than 38.4K bits/second. Not likely, but with V.32bis
(probably coming within a year) and V.42bis modem standards,
we're looking at the possibility of achieving bursts of up to
57.6K bits/second over the phone lines. It sure would be nice to
be able to get at that bandwidth ...
18. Dialback capabilities. Since all modems tend to use at least
slightly different commands, etc. I don't hold out any hope
at all for this, but it would be nice.
19. LAT. We don't have any LAT users, but every once in a while we
run into one. We won't cry for a second if this isn't available.
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 21:59:36 GMT From: maytag!gamiddleton%watmath@iuvax.cs.indiana.edu (Guy Middleton) To: tcp-ip@nic.ddn.mil Subject: Re: Is underscore legal in the local-part of an address?
Mike Califf writes: > At least one of the INTERBIT (Internet-to-BITNET) gateways is > rejecting addresses which contain an underscore. The postmaster > at the gateway says that this is because his software correctly > implements RFC821 which restricts addresses to letters, numbers, > and hyphens. I think he may be a bit confused. The elements of the hostname should be letter-digit-hyphen, but the local-part (anything left of the @) may be anything at all, but, if it contains any special characters from the set <>()[]\.,;:@" or control characters, they must be escaped by a \, or else the whole local-part must be enclosed in quotes.
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 0:17:37 GMT From: Mills@udel.edu To: bacchus.pa.dec.com!kmeyer@decwrl.dec.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Kraig, You don't need an external transducer and don't want one. You want the ambient environment of the CPU circuit board, which is reliably reported by the quartz crystal resonant frequency, assuming it is calibrated. For this appliation you want to maximize the temperature coefficient, rather than minimize it, which is the usual practice. As for knocking about in the steam tunnels, rewind history to circa late fifties, when some of us installed miles of surplus field-telephone wire in the steam tunnels between the student dorms, along with broadcast carrier transmitters. That 40-watt monster under Alice Lloyd was my contribution. Dave
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 13:37:13 -0700 From: Doug Faunt N6TQS 415-688-8269 <faunt@cisco.com> To: LVARIAN@pucc.PRINCETON.EDU Cc: TCP-IP@NIC.DDN.MIL Subject: Network Temperature Protocol
From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
Merton, I think your Celsius to Farenheit converter may be overheated.
+22 C = +72 F (fairly comfortable). BTW, the temperature in Phoenix
reached +50 C = +122 F about two weeks ago -- now that is hot!
Lee Varian
Princeton University
There was a comment in the military mailing list that it hit 62 C in
Australia not too long back. THAT'S HOT!!
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 16:21:16 -0700 From: jqj@rt-jqj.Stanford.EDU (JQ Johnson) To: mailrus!uflorida!mlb.semi.harris.com!rtpvv1!rlb@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil Subject: RE: Network Temperature Protocol
I'm afraid we're getting too serious about this "Temperature Quote Protocol" stuff. If anyone is tempted to get serious about it, they should write an experimental MIB and offer temperature/humidity/... as SNMP variables, not using yet another protocol. The above in response to Bob's query: >Is there already such a beast in the RFC's? I do NOT believe there is an appropriate MIB yet.
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 10:07:49 EDT From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: Network Temperature Protocol
On Mon, 23 Jul 90 20:36:21 -0700 Merton Campbell Crockett said: >The major problem with the TQP specification are in the examples at the end of >the RFC. The +22 is excesively warm--the -3 is more appropriate of the two >examples. There is enough medical evidence to suggest that +22 is not >conducive >to mental activity. Merton, I think your Celsius to Farenheit converter may be overheated. +22 C = +72 F (fairly comfortable). BTW, the temperature in Phoenix reached +50 C = +122 F about two weeks ago -- now that is hot! Lee Varian Princeton University
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 13:37:35 PDT From: jkrey@venera.isi.edu To: mark.horn@mail.admin.wisc.edu Cc: jkrey@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: Re: Looking for POP2 server source
Mark, To FTP the POP2 sources, do anonymous login to host venera.isi.edu. Retrieve: ~ftp/pub/pop.c (4.2bsd client program) ~ftp/pub/popd2.c (4.2+bsd server program) Joyce K. Reynolds
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 08:57:55 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
In article <9007171938.aa18804@huey.udel.edu> Mills@udel writes: +--------------- | You may remember the ill-fated XTEN network that could be described as | an Ethernet radio operating at 10 GHz for metro-area coverage. Are we | now seeing XTENs in the sky? +--------------- Not exactly. The 10 GHz local radio was not so much an Ethernet as a whole bunch of Localtalks... ;-} ;-} XTEN was [supposed to be] closer to a "non-mobile digital cellular radio". While the carrier frequency used for local distribution was indeed 10 GHz, the data rate was a paltry 256 Kbits/sec, shared among all stations located in a "cell", a 6-mile (max.) radius quarter-circle from a "local node" (that is, an area of about 28 sq. mi.). [Cells could, of course, be smaller than that, with careful power budgeting and re-use planning, just like today's mobile cellular systems. But there were only four frequencies available for re-use planning.] The traffic from the four cells of each local node was to be gathered and sent to a "city node" (central office), via point-to-point links not part of the allocation at 10 GHz. City traffic was then to be TDMA'd via one or more satellite transponders at geo-sync. Thus, nothing moved around. The routers would have been virtually identical to today's IP routers, except maybe simpler since the physical plant was so much more hierarchically laid out -- everything not local to a city went up to a satellite and back. The total "peak-busy-hour" traffic for New York City in 1992 was estimated [in 1979] to be less than one FDDI's worth. And today a lot of people think FDDI is slow. (SONET, here we come! ;-} ) The only historically safe guess is that we'll continue to underestimate our networking bandwidth appetites... -Rob (p.s. Fall of 1979, my job at Xerox/XTEN was designing/evaluating multi-access protocols for the 10 GHz local radio...) ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 15:14:23 EDT From: hal@gateway.mitre.org (Hal Feinstein) To: tcp-ip@nic.ddn.mil Subject: FTP grade of service
Is there a knwon extension to FTP that allows a reqestor to request a dispatching priority level from the target host. For example, transfering very large files at night. A trickle-across mode is useful so as not to interfer with other users. If such a service doesn't now exist it might be suitable as an additional parameter setup during session initialization. Has this been considered before?
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: Tue 24 Jul 90 15:20:09-EDT From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU> To: postel@venera.isi.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Jon--
Since you did request comments, after all, I'd observe that it would be
more appropriate to offer Fahrenheit readings via TCP and UDP, reserving
Celsigrade/Centius for TP4 and CLNP whenever X.500 can furnish the necessary
SAPpiness. (Perhaps Kelvin should be furnished via TP0.) I mean, every
time we try to be international about things it only leads to difficulty,
as witness the subsequent messages re what 22C is....
Or should we be spec-ing a CF "gateway", to be contemporary?
Other than that, though, it seems to be one of the better protocols to come
along in some time, except for one technical omission, I believe. Unless,
of course, the Host Requirements RFC specifies that UDP checksums will be
used for all protocols that don't say not to use 'em, since if one cares
enough about the temperature to ask, one presumably cares enough to want to
get it right.
So I urge the IAB not to progress the TQS to DIS [*] status without changing
it to Fahrenheit for both TCP and UDP, and explicitly requiring UDP checksums
(except for the UNIXtm "man" page, naturally, where total recall of all
remotely relevant context is always assumed).
cheers, map
[*] Draft Internet Silliness
(not to be confused with Draft International Sanctimoniousness)
-------
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 13:59:47 GMT From: sci34hub!eng3!joe@uunet.uu.net (Joe LaRocque) To: tcp-ip@nic.ddn.mil Subject: How do you get a ENet Addr?
I have been given a 'chance to excell' by my boss. Simply put, how do we go about getting a base EtherNet Address assigned to us? I seem to recall that PARC is still in charge of these numbers. But, I know that they have moved to San Diego and I no longer have a name or telephone number for an individual that I can talk to about this request. Before I forget....I know that we could get a set of proms from a mfg who would take care of the problem for us. Our problem is that the new system we are building requires as few surface mount structures as possible, so we will be assigning the EtherNet Address via software. Thanks for your assist! Joe
-----------[000313][next][prev][last][first]----------------------------------------------------
Date: 24 Jul 90 14:07:49 GMT
From: LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To: comp.protocols.tcp-ip
Subject: Re: Network Temperature ProtocolOn Mon, 23 Jul 90 20:36:21 -0700 Merton Campbell Crockett said: >The major problem with the TQP specification are in the examples at the end of >the RFC. The +22 is excesively warm--the -3 is more appropriate of the two >examples. There is enough medical evidence to suggest that +22 is not >conducive >to mental activity. Merton, I think your Celsius to Farenheit converter may be overheated. +22 C = +72 F (fairly comfortable). BTW, the temperature in Phoenix reached +50 C = +122 F about two weeks ago -- now that is hot! Lee Varian Princeton University
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 14:41:30 GMT From: bacchus.pa.dec.com!shlump.nac.dec.com!koning.enet.dec.com!koning@decwrl.dec.com (Paul Koning) To: tcp-ip@nic.ddn.mil Subject: Re: Zero manufacturer code in SNAP?
::... :: :: My understanding, which has no more authority in this case than "urban legend" :: (and should probably be taken with the same degree of confidence), is that the :: 24-bit "organization" identifier was not originally intended to be identical :: with the upper 24 (well, 23) bits of some assigned MAC address, but was to be :: a separate space assigned/managed by IEEE. :: :: (The obvious hack of making it be the same as a manufacturer's 23-bit unique :: MAC-address prefix came later, if at all. [*Is* that the way the IEEE assigns :: them?] After all, it *is* possible that a manufacturer could make more than :: 2^24 network interfaces and need some more addresses, so why mix SNAP IDs with :: MAC addresses?) I don't know about the "original intent". However, the final result, as described in IEEE standard 802.1A, is that the OUI (the SAME one) is used to create individual MAC addresses, multicast addresses, and Protocol IDs. There is only a single registry, and it is used for all of these purposes. paul koning
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: Tue, 24 Jul 90 18:57:38 EDT From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU> To: TCP-IP@NIC.DDN.MIL Subject: Re: Network Temperature Protocol
On Tue, 24 Jul 90 15:22:37 GMT Boyd, Bob said: >This would make it feasible for monitor manufacturers to make their >equipment more accessible by having a standard protocol for reporting >environmental conditions. Is there already such a beast in the RFC's? Bob, Isn't this just another MIB for SNMP to deal with? Lee Varian Princeton University
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 15:22:37 GMT From: mailrus!uflorida!mlb.semi.harris.com!rtpvv1!rlb@tut.cis.ohio-state.edu (Boyd,Bob) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <9007240048.AA00668@bel.isi.edu>, postel@VENERA.ISI.EDU writes...
>
>
>Network Working Group J. Postel
>Request for Comments: XXXX ISI
> July 1990
>
> Temperature Quote Protocol
>
>Status of this Memo
>
>This RFC suggests an Experimental Protocol for the Internet community.
>Hosts on the Internet that choose to implement a Temperature Quote
>Protocol are encouraged to experiment with this protocol.
>
>Introduction
>
>A useful debugging and measurement tool is a temperature quote
>service. A temperature quote service simply sends a short message
>(the temperature) without regard to the input.
>
>TCP Based Temperature Quote Service
..
>
>Temperature Syntax and Semantics
>
>The temperature quote is the current temperature at the location of
>the server reported in degrees Celsius (or centigrade).
>
>It is transmitted as decimal digits represented as ASCII printing
>characters, preceded with a plus or a minus sign.
>
>Examples:
>
> +22 ; a pleasant temperature for people
> -3 ; a bit on the cool side
It seems to me that it would be more useful to establish this as a more general
environmental protocol rather than just temperature. I would suggest
that the quote consist of a string of information separated by delimiters
such as "," or ";". This way humidity and other more esoteric environmental
parameters could be checked -- such as "on emergency power", "particle count",
etc....
This would make it feasible for monitor manufacturers to make their
equipment more accessible by having a standard protocol for reporting
environmental conditions. Is there already such a beast in the RFC's?
Bob
-----------------------------------------------------------------
Bob Boyd Voice: (919)549-3627
Harris Semiconductor Microelectronics Center
E-Mail Address: rlb@rtpark.rtp.semi.harris.com
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 15:43:26 GMT From: dino!hascall@uunet.uu.net (John Hascall) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In some article, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: }The major problem with the TQP specification are in the examples at the end of }the RFC. The +22 is excesively warm-- ... Huh? ((22 * 1.8) + 32) = 71.6 John Hascall
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 16:33:50 GMT From: noose.ecn.purdue.edu!molecules.ecn.purdue.edu!kelley@iuvax.cs.indiana.edu (Stephen Kelley) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Temperature should be in Kelvins. Steve Helpful
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 19:12:35 GMT From: sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!swbatl!texbell!cpsolv!rhg@ucsd.edu (Richard H. Gumpertz) To: tcp-ip@nic.ddn.mil Subject: NAMED needs more consistency checks
It appears that we have finally tracked down a problem with the domain CPS.COM sometimes showing up with an MX and sometimes not. It was a misconfigured secondary NS for CPS.COM: due to miscommunication, named at that site wasn't configured with a "secondary" line telling it that it was an authoritative NS for CPS.COM. Therefore, it never fetched the zone information from the primary server and instead responded to inquiries by just returning whatever happened to be in its cache (usually just the NS records obtained from a root DNS server and not the MX records which it was supposed to have obtained by zone transfer from the primary NS). This brings up an interesting point: maybe "named" and other DNS servers should complain to a local administrator if they see an NS record go by pointing at the local site when the local site hasn't loaded any authoritative records for the zone. Thanks to all who helped me track down the problem; it appears to be fixed as of today. -- ========================================================================== | Richard H. Gumpertz rhg@CPS.COM (913) 642-1777 or (816) 891-3561 | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 19:37:52 GMT From: sci34hub!eng3!joe@uunet.uu.net (Joe LaRocque) To: tcp-ip@nic.ddn.mil Subject: NDIS Document
Could someone Email a copy of the NDIS Document to me? Thanks for the assist. Joe
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 20:37:13 GMT From: faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) To: comp.protocols.tcp-ip Subject: Network Temperature Protocol
From: "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
Merton, I think your Celsius to Farenheit converter may be overheated.
+22 C = +72 F (fairly comfortable). BTW, the temperature in Phoenix
reached +50 C = +122 F about two weeks ago -- now that is hot!
Lee Varian
Princeton University
There was a comment in the military mailing list that it hit 62 C in
Australia not too long back. THAT'S HOT!!
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 21:00:30 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
one the subject of temperature quotes... One person has mentioned that the temperature of the system's environment might be a good piece of *management* information... Why not make it an extension to the system variables of the MIB and let SNMP do the querry-response stuff rather than create a new protocol? While this discussion may have started-out as an arcane excercise ;-) it seems as though arcane items like this might be quite useful. (perhaps not as *fun* as the CMU coke machine ;-). Maybe the folks at Leibert (sp) would like to put SNMP into their PDU's and air conditioners and put them on the local LANs? rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer | \_/ \_/ Hewlett-Packard Co. | But it IS TCP/IP - Honest! ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 21:03:44 GMT From: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin) To: tcp-ip@nic.ddn.mil Subject: FNS routing
We're running the Fusion Network System package on a VAX with two ethernet boards and are attempting to make it act as a router between our subnet and the campus backbone. Can anyone experienced in setting up FNS help us out? One ethernet board has an IP address of 128.171.1.99 and attaches to the campus backbone. The other board is 128.171.11.2 and we have only one PC running KA9Q on that side of the net. (Other hosts on that side of the net are running DECnet/LAT). We want to pass packets through the VAX. Here's the contents of our net.db file: name:exists:state:route:hops:delay:maxpkt:options:comment veva0:1:nrc$veva0:[ETHER]AA0004009A60::2000::DEVICE=XQB0:DELQA-VAXS3600-2 veva0:1:nrc$veva0:[INET]128.171.1.99::2000::GWY: UHNET veva1:1:nrc$veva1:[ETHER]AA0004009A60::2000::DEVICE=XQA0:DELQA-VAXS3600-1 veva1:1:nrc$veva1:[INET]128.171.11.2::2000::GWY;SUBNET=255.255.255.0: Physics subnet veva0:1:nrc$veva0:[INET]->128.171.1.100::2000:::ZEUS IS THE ROUTER On our VAX we can ping both boards and any machine on either side of the VAX. We can even ping off-campus through our router 128.171.1.100. On our PC which has an IP address of 128.171.11.16 we can ping 128.171.11.2 but cannot ping 128.171.1.99 nor anything else on that side of the VAX. While I can force a route in KA9Q to the VAX via a 'route add', the VAX just gobbles up the packets and doesn't seem to do anything with them as far as we can tell. It seems that if FNS is smart enough to know which board to use to ping a particular address it ought to know how to pass packets it receives to the right side of the network. Are we missing something here and doing something wrong or is FNS just brain-dead when it comes to routing? We have the latest version of the FNS package. Any help would be appreciated. Thanks! Antonio Querubin, Jr. querubin@uhccux.uhcc.hawaii.edu antonio_querubin-manoa@uhplato (BITNET)
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 21:03:59 GMT From: logicon.com!Makey@nosc.mil (Jeff Makey) To: tcp-ip@nic.ddn.mil Subject: Re: Temperature Quote Protocol
Rather than require the TQP server to ignore any data received, it
would be nice to allow some specification of which temperature(s)
(e.g., CPU box, disk drive, outside, operator) is desired. This would
make it possible to have more than 1 temperature sensor per IP
address.
Similarly, the temperature quote returned should identify the
temperature(s) reported.
:: Jeff Makey
Department of Tautological Pleonasms and Superfluous Redundancies Department
Disclaimer: All opinions are strictly those of the author.
Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000325][next][prev][last][first]----------------------------------------------------
Date: 24 Jul 90 22:57:38 GMT
From: LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To: comp.protocols.tcp-ip
Subject: Re: Network Temperature ProtocolOn Tue, 24 Jul 90 15:22:37 GMT Boyd, Bob said: >This would make it feasible for monitor manufacturers to make their >equipment more accessible by having a standard protocol for reporting >environmental conditions. Is there already such a beast in the RFC's? Bob, Isn't this just another MIB for SNMP to deal with? Lee Varian Princeton University
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: 24 Jul 90 23:22:21 GMT From: groucho!davis@handies.ucar.edu (Glenn P. Davis) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In <9007240048.AA00668@bel.isi.edu> postel@VENERA.ISI.EDU writes: >Network Working Group J. Postel >Request for Comments: XXXX ISI > July 1990 > Temperature Quote Protocol >Status of this Memo >This RFC suggests an Experimental Protocol for the Internet community. >Hosts on the Internet that choose to implement a Temperature Quote >Protocol are encouraged to experiment with this protocol. ...and so on You probably don't want to hear this, but there are a number of protocols and formats for weather info defined by the "World Meterological Organization" (WMO). See, for example, WMO publication number 386, "Manual on the Global Telecommunication System, Volume 1, Global Aspects, Part II" for the protocols. Of more relevance to this discussion is the specification of a synoptic report (a weather report from a ground station). This is contained in the WMO "Manual on Codes", publication No. 306. The synoptic codes are code form "FM 12-VIII Ext." . Here is an example: ^A^M^M 727 ^M^M SMBZ4 SBBR 241200^M^M AAXX 24124 ^M^M 83827 21225 80000 10110 20101 39900 40190 53012 7104/ 886// 333 ^M^M 20082 69974=^M^M^M ^M^M ^C This is a report from "SBBR" (Brazilia) at 12:00 UTC on July 24. "Control" characters are indicated using "^X", etc. The actual report begins at line AAXX ... I can't decode it, but somewhere we have some software that can :-). Things like temperature, wind speed and direction, rel humidity, barometric pressure, cloud cover, etc are all in that line. They devised these things in the days of 300 baud teletypes == expensive bandwidth. Cheers. Glenn P. Davis UCAR / Unidata PO Box 3000 1685 38th St. Boulder, CO 80307-3000 Boulder, CO 80301 (303) 497 8643
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 00:51:39 GMT From: wang!fitz@uunet.uu.net (Tom Fitzgerald) To: tcp-ip@nic.ddn.mil Subject: Re: Is underscore legal in the local-part of an address?
[I know the original discussion is moot by this time, but anyway...] gamiddleton@watmath.waterloo.edu (Guy Middleton) writes: > The elements of the hostname should be > letter-digit-hyphen, but the local-part (anything left of the @) may be > anything at all, but, if it contains any special characters from the set > <>()[]\.,;:@" or control characters, they must be escaped by a \, or else the > whole local-part must be enclosed in quotes. Periods are legal according to RFC 822. Is this generally true in implementations, or is this considered one of the glitches of RFC 822 that nobody really pays attention to any more? This actually makes a difference to us. A programmer here wrote an e-mail gateway strictly following RFC 822, in the belief that all other mailer implementations in the world followed it strictly as well. This has caused a few problems already... --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 01:39:11 GMT From: excelan!bbaker@ames.arc.nasa.gov (Brad Baker) To: tcp-ip@nic.ddn.mil Subject: Internetting Netbios Agent NBA (sources 1of1)
Sources for NBA (OS2 and Unix)
Netbios Broadcast Agent
Effectively internets the Netbios Name service.
This program is useful for effectively combining netbios
networks that are separated on the internet.
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface. It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes.
Included are the four files needed to build it:
makefile (os2)
name.h (os2,unix)
nba.h (os2,unix)
nba.c (os2,unix)
See the documentation header in nba.c for more extensive info.
Cut, uudecode, then uncompress.
--- BEGIN cut here ---
begin 666 nba.Z
M'YV0(Q2, $&P((@V8=:4,9.&31D09M[( >%$2!"($D$\F?)"!@B! D%,*?.P
M"14B69P$<4'DR1",$]M(?$BF#)TP#>> >.,&!!TT:73.J2-&39DQ=$#*K,FF
M!QLS=4*F<3.&39V:(."$^:FS!8@Z<QZVJ<.&3IH6/^64"4,&Q-2J5Q\R=#@'
M)!8F3J $H8*D!Q<\;-QPH?/F#9LU:9)26?(EB9,A3'J00'$W[UXD*;B\M5I3
M@6/(58@4Z=$BB0L0I2<O;OR820K42;BTF3.F1@S-5#F7D9TTX$ V:<1HY0IB
M#IHW9-N*>1B6CMN>/Q\R22($1!DW=M+(X=GFNO,Y=.1,/6,7[W0A4WJ(F4.&
MQ@P7P,6 &".'3GSXP14TF7(^/9DWM(7!!AMSX">& D$PP<07_4E&F7G43?':
M9/OUEP)( XWQ1AMP-"07&V&<45= 0QC!1!!'I$?0"V. \$(0DRU5!ANOO? $
M'BYJ 9R+1\SAT0M$$*&@BT$6(4051Q"YT8]7S #"9)\Q$5H1%_H& G!NK $1
MB"*"Q(2)**KXPA!/N.C$$T2XV$004)CY1!(*3.?$$D,T082#7YZ8XH0JJ #"
M"B#\%=A@A1V6&!< RA ?%_31408>9;CP1E$LD !$I2JX@! <E:*0X((6*B"J
M"V-(6I0."AAD4%5/HE"BGA(^F6F+/LCJ0AERR"&J&V*$8:H:.B3 JZ]C"-NK
M"VB (&P8W2$KZ@C00@L"$U-IJ6$;"+E!AD[11KMKKSHH.^RO"B2 I9:3R4FG
MG2GL4"Y"<B@$*0A7.-;2%60VH1<5((S[:!G/@E"$$VD^800(:RY1A!%),%&$
MJ"^HH$ +%%=L\<489ZSQQAQWS+&HJA8TQ!MPY"'>&6@XY^IK,>20 PP4O6''
MC&RP $(25+E0;JHA@T %4$*]808==X2AUD%AY '"<A"I-:/2&G981EMA: L"
M&4&%%UP=CI)A,QS;95=36]%]U#,(88@A\T-1FYP&RLZY\8998SP4U'-PC7U:
M$LXAI+3<SC$]AV%>/P?"'<<YQ'/(&4V5E=%TV'Q'8L=Q[1,:#X&=1D9WB$>'
MHSUIZ$98;C@G=,PS#V@SSJ6*ZO'KL,<N.\:B)J!2$T6X@$0"(&#.%JX0>0A3
MO\>.(:H*+SQ;$T-NE)% $E!\0<014@31Q!=3:)% #3?8(-#R4SD/_1=($"$%
M]MK+ ,/W"X6?0&C1EW]^]@G@P#[S#V7_Q9%&&%&$% E P?BF5[WK90\U-XN?
M^="'0/B1;X'9JQ+XFI< _:T)"U!8PDGV$H3M=2\!$4,:'M(PEC9<;2MA,%P*
MM3(&A3@'>1#KDPQG2,,:VO"&.,RA#G68*C\184,XZ8D3F/40*(2AA38! 1':
MYX;$;&YT/=RA%*=(Q2K.,'G*8Z+SG' ]*13A"%_P8A02 ,\R" ',5C?"":X
MQ2X680H)(",>V((#-;+1=M>+@A2R$,<RPB &:;R?^[CX!3UF(8QOE",.:@ #
M.VJ1(GG<(R*G$ -%UJ".@J3@F42#/2KLI0I30.08_?A'1^+/=F@J0B<_&4HO
M3@$$9<0!#1J9R39^X0E6.)\8Y2@#' 1RC5K$8QB9T,HBC!(/,RAE+4&002I\
M83]+Z",>S$ &,\ A'YJ0ACFH*73B2$Q.@'+U(;'0A?Z) ]PB!0(8 A,_(%
M"F3B)#3EV$@8F &;"-MF-\VP-'!^)2QMB<A$Y* AK,!0 1'K83ZY"0(["*@.
M9=")0"'Y!3"EZ#0_B^A#'&J5B/I$+5NYG%S2,*-ML4"A3X!"/(M@,T):= HV
MJUI;X)E*M.F$)P^Y@T3:@H(8V*"?=)A#"G2V3BRV<Y"A%((4GA $(@PA"%.@
M CT;&8-:VJZ84Y""%8A025+"0 96=0)6M4H$&4P5!C0(:RL[>%;['563K22"
M---(R[=N,914&((TU==(?(:G#E39RA.!6E2U?B$(;"WC+&F)4#_A:CL3*:A'
M)TI3T02OI(8K9Q)]5Y.)'-2N"3""2;[P/P"6L9(AQ!E'TT &-BC-"!)!R.?&
M*84RQ &BX"DL:+-J!=)*P;1FQ.=(Y#"SB1@!)U8Y&COOF 1]^1:X-,!G%497
M!SC 02)=>Z=M<?O"Y(%6"D8(96GE6 -\UO8,69.#8'FB7:C,04"ZO6,0AN#,
M\9;1!O@, E+2,#/KY.H-9;"9&XCHEIO>H7G*45K5YH:YB<BM)J=9;C!+5-_?
MRO$&^!QB=PIL.-&9 3A(*6QCSYG.AC[4HY^]HU@/*\U27C.U;6(+&=0R!YW\
M-K[!7+%86]Q(LX90P_G#57'?*04<GU+'0N"Q^O!YA.O@"KY %HF0TU W(AL9
MJ5^H2%3W,E49H-9/3G@#5J9P$SJ Q<H2/G(HG5 %!?$8!F'(<)N98&6OA.4A
M5YCO$J[&1">R-\WAHT@H'?/F&*S(3SASE!R:YYRJ;%,G!PTA1W$[O(I45$^7
M94-;''=C,J!0Q'85]!>H]X0J0$&1]63R=JH+ B$DQF:&[D$/0'"$5<.!(C;Y
M)H H0F! -T_43=AD$>2X6%,&>L50$#8OZ[G,%9OO"'-E=JA7+ 1E>]78OU[Q
M$)Q@A!;7$=L/6?%\I4K/Q38[E%"00A-:S-<8(HV;$LV(I2V:Z4WW9, ;]O1-
MK%,Z.2@MQ8]<,:E-/4\_Q#+5(:PU<FX=92-PZ<K9#N43G$"%@M\7X7YZPH&!
M%V:L4 &=#_%UN$.Y92H4P>)XB $9^OIC I-Y*P]Q=5!%W%@KVOSF.)?8.D$0
M!>X.=B3[96]XD(NK<('M*%,;IQ@4/)\-';W&XW1"KC>G$WP#;)TYS[K6;XA%
M\,BA#B&^;43I\(6A>V@B>UC<5T;W-@07YSCU(7$9W&40P,ZA[>,T#G;G Z(:
MNZL/.W"1GVBPM#PX2B=LX,D91!RQK3O^\0JM[>#J0-"'U%9#<B";>L]N=+74
M;6R%1UO3.41C@.*:#KJN.A%M%I$!O>$.4U/HTD7O4/&DS2$GW'=8@NZ&*#[^
M]SCO^E]#G*NR;]XA:%>[W?'>%KW'7>YT+\CRS^!VYSN'[X^./D&F[_;$NV'Q
MGV.#]M=^=^KG'>[7=\CW?_+WP(<PC84__)44+V*O@]TYQ9]*1$"0=H/8G_AR
M8'Q$)P<)8';(-W[<=WY[%S(?%B)S,'[>MWAQ1#PR)@?M)W@@X%/QYU$16'_#
M%S<<L@9DAP8SQG_*QW;FUWSHUR]M4':LM0-^I5ZC<T1FP5ZL55AUAX+5MX+@
ML15@ 8,A1#*2Q7I<,@<VHQ9FMFA-9U#)DX/EMX-[%P=DH"& 10= Z"=N4 =M
ML!P3<3IB!QZ#Y1WB@6)-*'TZJ(!Q5S546#I7V"]:R(4[P4]5,P>P-U!'L5.0
M5H;;=X8JN'>CLX96B$]9N(7 <SIAP#5PEQA*XWEXB(-F^(1HZ!Q& XAM.(AP
M:(AD@#4U.&!L *,F'EYJ " AX$QX!%+)W\=>%#_%S=$! <B:(+^]X$LZ(HC
M6(*<A2LP>(*0V!9C@ 9&XXEW"(I;H#_\XS]%9F=IH =E(#0HL(JS*()?0()R
MD )=T'Y9=&36HTI3\#]6D 1#H$H.! 5/( 52%0,S< .--3&SLX[LV(XM #(]
M,S(E<S(I P(KDX$N S-AECHU<S,YLS-G\S-W,SA#4S1'XS=+(Q=.XUI-)S54
M8S58XW5;TS5?$S:L-4YEHW8&D39KTY!N S?],C=49C<ZL1EQ009[TS=)$Y*!
MPQR$8S..@SB&<74]TS@]H17U(3F4@QS.43::PSF> SI--SK>$8>H0S.K\X_J
MZ(Y,V90:4SL481&Z4Q"W.!%S(1<9,2[&HP"19D,@( )M-Q,B<#D#:69FP$\U
MY%UI8 ;:LA @8 1$@#U%0 5A)01"P$<X$$<A9(F%R$_?-'..DT*G&'+)DU [
M-Q(.$6+BI!-_^6YK<%/\=)5\1AOB 0>$(0<EV1,16" *E5%A@33TL6O9D@9P
M0!8P5QQ@ERR-R1 EI1,H4#97.0=Y !YE8$(($9KA])F]:#1"151^ I=R2053
MD 1:4 1(HS1,PT8))E+_A"LV(P:64S;+<XAET3NX<G5^HG?)D9 @X .S=B8,
MXS#VB)/,@BQ#U4-JR9;+$UIQN8W"29P/ UK Z9[#69P), -@-0+7@35F("IT
M '++,W_?EP#4] 4(P4WN,FUP*01)()P!='?*R(P%>J!K\!I@9I=9D +X])<Z
MD4XQH4^ZM99MR4_'<0?9D@=65:(GB@)X8#-YH*$H$*-XD (K$*,OV@(QD (I
M\ (H\*)5LI]K>8WN,Y]SB0)N\#4PB@)PD (MX /4- =?P*%;8*0[RFU$P*#"
MV04@P >SUE,@P ,\8(]4"@(E0!$+VJ 2HJ-6!9R0(05&BJ0!I*1,ZJ3;$J7@
M-*5N4*5GFJ4@8 *SY@=>"J9BFJ=D:J97BJ8Z*D'!!)Q), 7N^:99D:1+VJ1/
M:J=!A:=Z>JA\:@+V:&B"&J.$6J96BJ5IJJCN!)S%N51RF@!BH(S;$:.[Z5DI
M(*<V Z'+: 8HH )RJJ;ZJ2U!VGA3!(SP!1YU<)8)F7AW8)W*5458Y)\ ZI;*
MDH!]&'=Q!$I(,(Y4X"[_F4X!&JU\**"+IRSOPP03=P3:^JS\Y*V[**YQ) 1/
M\ 1,X"Y6E0!4( 55,&QQE*]5!5JAE2#;R*Y])*2_%D<5$01?< 6,(8[D2!#Y
MFDR-5!!ZZ2=5LW:/QGQ9L7<B)ZX6$07UB:_Z^K#+U*YLHD'3X3\&D:\U<#8%
M$4*:Y1S 80:$.:_Z\QC5EHWYF@ ^%;(5Y!)+T%3FT[$,&T>VRHS..#@M5(%?
M,!6F&FAQA"(#XTRWHTH.XP3B"D@?$6IQ%)ZJ%+4,,C!!6T<?X6X641QE=F:2
M%8I8FP 6(9<$<[-DI+-KZT50P 19 +#[RD8::["E-8YNBZ,"^Q $BU7/!%71
ME*\'QW)^0J'#4S9B!8QS<%U$25A=.93%=7?L=9O;$8KX)#K%%3<VH5/QLA.9
M!SP=2!C]\KD2T4VC.Q'6!W& :SM,0!ABQ:(:FJ\IPQ-S$*/6BJTI4#IO@ 9L
M0+NO42XAQ+FXXKE$D[JBVUEOMW>FRVB@J[K,FXK>A;>!*[M,0+LW>[MN$+PH
MT&;EVKN$@0:Y.Z,7H@#.V"O1N!;,FW;C6JX0VX-F]H W6[P;DBV\*&:3E1%C
M&R+>H;G@ZP30QK!FT1TP6+]^4L#,<1,<0DY'9$Z/TB'JM8F%];X"+"Y0:A9D
M<, 1VR\$%A;$-9(?-8<T.%@W"$,6G"2L&@8NN,$(W&H7X;^E,\(SR'MNT18H
M',!)HBS' 1Y?4($<'$+]>P9%68$1!<#D>L$)4!4D53H_G(D6V,&-R\1%#,5'
M7! YG,0J3,5.?%WU<< _]DI<[!Q>W%UP&P1(4 1-]3\=FZ]#BZOIR\)5>2&
M)RIQ_ 6T:(()X(PKO+Z_,Q&]4I7NLL>RN"S=D<<$876TF*#6J[8C^Y[VZ<;)
M>*O-*(OJ.\=_(A):L#]5T#__(XKRFHY+Z92D[)3P&#+R^)'U>(\M\S)'J3K^
MV#H)H)$%(9!!4Y!&(Q8KR31FL)!00S(D]9!M$9%: YT4F146"7H9>38<V5]M
M0X]Q(Y)5=C<FJ3<WHY)_,S?<.3B:!I,](9.*<S8V^3@Y>3@[&9V8@\R;,Q&=
MDQA"*3JD8SK\M(](&<LZ,\JEG,_L>,JJ4K N\!*GEWJMMAUL,0;;Y!Q!0,0S
M7!"S-]!LT6H)@2NU8\L<-@76,[?&.7F5MX0!1A%/P"\I1,\#@LQB=G\V0\L$
M(5/F/-* L\W55<9*IS1EXRB]V$0&W8D]:*RG(])L<,\)(!I3, 12 #U4D 03
MARKE0M%@\P9GH%XFM-1BXU$3^RC, @>X=SHEZA-O !,&V1965QQ35C<\PZH$
M/84'K1.FJQ8RX2BGBWI4U];1JQ.BTSQ(,4[9D4)G '-%,YNB6RZKIF@Z@3A4
MEBS_P9+_5 <"PI "U=6HV8N/@T1!=1K7S&$UL8OE8KI,\W4]X3AE0#G ,UQ#
M)B.B"P()790RHC-Q!-K (]IJ<5O:X5$_$5(_<3=+W=3,8H\%^QJ9#5@[ 1WI
MG'@W72[0F[HI"8QUPU\>Q6@"_=5BYV]+4]8ZN*;]@T0.GE4:O(5-^7096
M35*!33FBU]R+&%&0^YF5[(-S8-UXL$B-E (PR4]E(]X>O&':G0!3H6B,AC96
M7&/\%AY*<S<1 5CVQIS7&E6O=)62'6; :-5*T[+E,I!%N9;,^=5WT](!;C6.
M4S8%+IS!XQ"HG0"E/<.B/15V8!@SHQ.:W43?U]OA-K9"]]MO<--M'5-6@U.]
M?=GIK-9S\Q##'2^2G5'S)^,%:]R=?>+/_08%?=:]S9S +2#"C;KQ4JMA8.0>
M:A;-,\,M^QP")5N#-12.O4U\U\22N-]&6"YE;#-#5\,4G 1$8#,V42K>+'JB
M$QZ&L33 K24H,,<_CCEF_L!)=#?1<9-JD4YMV1:3\Q/,.>152>-D@SD]L=A&
MH\QO@.,/H>-L[<\$<06.[A;.<3>>5^13@^8Y7IL['I47(9%P )G]68#IO.C%
M,>4>A0+7(7:X]1IEX^HJ'>C,*1%O,Q5.'D UT0+78="I;II=\QK*_=99?C=B
M -T'O>1E8^D\#N5K@-J:?AW,*>VF3N3(+7J#[EKOC3:2",NF6S;-CN1F#1XG
MQ>H/495:'EOKM=DZ41.TKG3;-$XO_A S+8/O9<,W*#24ON ,V;)[3A-CY^L4
M;,0U]C78Q>@^\>_PS>?*\NT-[N>=CM:;WAQ:S9PH,,:O,6D>!1XS,>#142[T
M#E$0U1:*SK[ D^NC/A1E,1Z/;4X0/L,H@#6>=^Q+\\"7O=4SG<YC'))8(=B.
MC1!843:\CEZ<>.1)#AX?3M&0GGDR?SKF[NRYI=(4/_,V882&LQ PBQ3K?M^X
MPF@8S^,?'-:14CO^\TFN] +3T00-NA=&+59(G0 J8#MC>S?M/%O0L=5,4UP-
MCEVWITZ3/3DCK=E+;@-UA =X4"[,;#53@),M,EUI@".W"13-HQ-@#GLC#>9U
MU$LV\ (S@ ,_M22@B?E2K2WELL>5HVG<N19W-_#8A9%;W1)3X--WK]3;8=NV
M&=$Z\2B@<W?])4Y&J>$;P>$(OOI%T&_>?1!@X1R/DC7#HU1,Y510104V0ZY/
MQ00;'E.!33.K#^95\S=$A.+;I1TRGT(T5MXYM>DI+O-#/A6K#\*AK;^2G03\
M-!1BP&A6OGC4W!/$+]_!M=2U^LH&]6LJ3R6JZ+<9<\6H7CK;<O3B"KB +) %
M7$ 9.4L6<)KP$[^Q^EI:]%IR@V/#H(<T04*L6FWR#O&N0! $G$&6Y-J]0QN]
M)XZ$ >NR'33':=)_^>W<-;TQQP#YFW9R?4Q#G*"DU7?JB$(.M'H\L/3T#C '
MFV(+4E-95T "8@$L, $KH!;0 @4!<5PG?J8JHJ +F((@8-:4C1ZG)<K88%%X
M=4%E%80K& :94P\C8]CE#)(Y>Y38P!H=N!!JD"!0P#8X45+(@\DIX"V%X, D
MHKA.QP4< Z(N** T-<A&RMY7L"[ XZ=PJ.*7S@:336%.@S IY,&080;92S-*
M(N4NG65"$]-1LIO5*!O(2J)M0E5ABOP)"E ;B*XY9+<.!3DH8;L#$'"P/CR1
M>Z:RJ!J'< CA0E6,0L4U:P[A(ER%B8S:J8IBN-YD0 :< 3G@&")#'9CN3$=/
M&(6Q!I8TPV>8 S(@#+@!&? LU8Z[QP)W"O!(:[QMR"FIO6..;L!K8"^4#T>T
MMCKPVN; 'JLNN*(%B).)H#FR W @8A\AC@"Y,D8*(4KSVDX\@2$QC=WT?<8)
M&: \,N_P]#]&-_]:']5@ WN-,3V$=G@)9UM)<H3P8[XQ![1WL>H#[NL9UZXG
MO+\5%_^NH9!9;?K+S3$_CY+ATMF&.W >PO'UC!^H'.P& (2$D>7>X3X05Q8J
M!\J @6A#H6$S;M=?AES+DBC;P82,/S=$B'1%'#D=VF[(R;"@ I.<@^'K1 E1
M:40]Y8 $T=I6LW'2;O5I1:5X_WH"@P$>H,ND(,4A]Q4-V]T9"V6A:BPCL*#8
M)$)7"W]:KR=M-;QH%DP@,%IK+2X(G 5Z#. QGR86$SCB%R+[F8<8MKJ6XF+
MAS"2)MQ3L!8CM(-Q,BZ_H0#VPI]@EEH0<4<$]0F5U;<6'-OI('K)HBY^NFY'
M#:,;5UP:EF,L,J>GJ-567VF\3C-,VVW%.? "R"!G*A<# PD$@<=P<I[6%*A[
M=@\$# %?U!"9$ZV3>=V!(08%$V*Z4HA,.!ID( _@&RK#XDY#$' .TO!L/)VB
M%-]0'DD2/?*+/!H-]9('/EPVB6@MD*3Q/D_$V\0?G[D)O6B<++6ZL?!\1E:Q
M&1)AK/$.9M($T(9U 3'QSIPANHE5 L/&.-F'ST'1F($CDO;BB)^ LD,*TV$
MLC$4K,O>.1V:T3 *1Z6H^>9=1*$/P6&<R+\)Q)S>7MPK:A/GE>R>A*<V9H9/
M.Q(-(TU0@7=%3*#CDJ@=],HQUC:G=CC ''1J",X!+,"_M3$@/",3F%A7('59
M-0XY/#9"1[!'(Q $T 7, /F7XQS(4+%9NR'EU #7$ :49.OY%R @#;Y1UR
ME[$9XHANU:N)PTP,0QY " H!!%B!]Q #?-K[< )) L@R9<P&<].[0"23"!-
M.(:H8J_HR]Q[CDAR'KZV@.(A-)]:"(9:2< <"S0@8(@(LK 9@+)].(31Z"/.
M5QP!+)6O5HR!%J&55E^BJ!6ID@+5#E#BM*#CL !6V +M RH*6"90L( UU@
M#Y"F"M0'BJ6PA /)LHPU2V I+.] LKP#TK(+= &=F "TX-&P;UH!BK7!LI%H
MQEX2"0)ST %6.E)WZ<96B*,#'TYE$42"( ;3&4$4@L/CJ]$_$9;F^MTFXDPT
M$AD2A"6R(<G"Q<M Y\@>A<0H ]I$&!3 +A<B8(:,.[ &"&*]? @B@/-UHC4@
M-PY,2:0#8PE?3I2"M?H$9D'HER4,=YT&@DF=#J;#6A\24U4,RV6H1,H =%H\
M#>@,2+8E<C,/@OY29Z5#)W2'&N._S.+JRU<J*ZJ(AM]B*'VA"9P#T-$'#(O+
M:'<,1^PK2O0/)M8$AA=WVB&2E)J] C60 :HY.@Q'3>B963,FQ,2/B3#1T>H#
MFRED9AY+<P0#7 CL9MN,@:DK!8 !_@*S&@!=X"1T)(XHMDR4U(T;3\3!4P4
MB3@>W!O;])LM96P11,$) ]8=@?*+D4[FU48E%PK7)6(\G#,LI*!!A%DW[V:;
M!"1M4E1P):-2S1X"#P /6.,-( L?(!!:YY=28+.S=N:&N/"ED +(R9TCP':^
MSMGT K951 &>PE,V$4>CY4*0Y^[$"CR T80/.O "IH+SS!NND]&0 3%P/77#
MEWHL<J-[\L[7V78$A/C$"B+ ZB +$: [L>=7&A=H@'T&3VKBEHYD\'R>KG,]
MM(?W@ 9H9Z_B3W9,%C%/I.4XF&<;W -!P BPAKE4QXK6F22@/4$,V,8#FD 7
M*!5HH +T@4*QI/7HHB(%5:".@8&Z"V>DR%Y1OWA<(FB$6C(6ALAVWB)#7RO4
MCS&O0,;R+! ,_3HAYI+5T)T7MN$L9*'KOKCYX-BFDQ3=W!2EC8J@V9NQ1"2H42080A>/1L] H-
M5DAAR2%=:'E0_;3!-Z8XHR(71:2;\&S6@<5C2!4 ,LV#Y6>+_M+KDP>I">OQ
M-.XB5FW"-B >B<@6\"E!5)OFP;>X:+PI.'47[@I>;4)Q$HUPX1>03+/&"/BK
M(N N"I3&4UG,LSG(*X0P%5" T3@#B!!MR($S8 <BYC-UHP-U# PR<7HV^L0_
MM0/NPGTQU(;Z@!X<,%6#;N#";3"+2DW58'.@,0C2,G$4>;7'RF?P&DY'P#'P
MBQ""4I& J2DJ(*!6O0TNNL=R3;&J9/^!:]@,&$!3FP-T@F-TH+/(@9U*4P4;
M[D$!%..?T@I8TJ<X5:Y: 2O@H:: +0 #M)2L 0$GH 6<@-?@OO98&WRH5%5+
M 8H8,,CVV*%S;+E*J.BQ)?8"3P 9. &H(E\I4V::@<HJ@=(<I0.H"E6;(0+F
M*K\9?&2 "[@!$4!3XTBS6PMKH*Q&MX=P N 7#V:K70KO($T@ *@JE"QJX<U
M(2C6MGH''FN^8J665-Q-ULJZ B[KT<RLB77U+5:L&@8>Z_Q<3T<R7^G1)#)K
MIF<5):VF5;:&RQ)46QG-%R"#S:BP@LL*U :Y5^YJ1NCG-=31&2-<WRAQ[5++
M=2((*I_R&OB 6X #>_1HAI#I^5ROJ(&*:%ITMD:.Z-HN" (*ZV#.55SV5B@*
MQ5Q * $L[K6*'C#SZEUF1%@XFNF5MWI7+6I9N>C_#%+Y"K66U>ED,.-J'#$#
M>)4.Z-7'PE?!@O\*%R6@ZH1-8TDLJ>6Q3);1=5H:2VBY![*EA;66>P!;8I=F
MV04$JPB(*0/5#H15X1K]Z$!/*:Q]H%S$V ?'3U! ",BOTVCUL5,P"D]]AKVB
MI[4CA! QEQ7CX L9?'=R@,O]F>1AWVKLD'V#5@<%<%.K(U,C%*Z:LD3D-7B%
M',555Y^'@BPH('V""Q#P9'%AE$T!A+6LMM@7.\AB;).U1W,U8MY5\9!7<2J#
M?9]C%LMNF%D384TLJNRFW8&F2KA*)@?4CY0%M&7@-=0*O=EE#VR"7;"Y@J\.
MBW#A%;X:8=AJ$<C$%M8UFZ/:;+EX@VVPS(*'I1-E]6RB'62#]@TV6E;5-O(<
M+FQ2:*"*VHR.YXMD59\"HQ7(9KQ!6/L%U,\9^ DTM0]8!P+Q$+KJEY4(87;2
MDEF;\ 9)+1'9HH%BL&[:$>)B.ZV,K1V#-LZN/@1+9Q6LG8VT7PG7BDL0H /*
M2 E@ WC S_:+\16\Q"US%;0UUJ^: *>*8]64H^VVD':H?B4<2V[-+;I5M[X+
M>/E3I5A%=11)%;))9'/F%NA!VN8@"@.ULT;4HAY$&V85+LB$M_9(U:Y5"4HR
M\H"K!0^\-M?:(VVJ EZ#"4"C/DSD[EH?$&M]+;!ML\/V,QG;QX)LQ6P8"!<2
MU]EV!VBK:=4LM66SU[9<C $[X&)-;;OH8,8K[IBNEP8\5NM!P2=#%@8JAT$*
M'\]D$IDHR6[7Z$N2B,(&K>)L"[.&>=H$3P%"G<!<LAE3@&=)#^IA/8CJ:PA3
M/'6M'ELYD&S'K-AUL6AVVB8&H)L W"SS= %WAXFV4N.Z#NM#3SV3@)>*5J#X
M"E]#27>% >*'QMJC;Z(MOJ[-, ',L\I2,N:IH[X4+%FU<[?NWMQ^4GGSKL_=
MN]:V[Q(O/Q%U51KEI1K%P>HZASZH%)EBS'JS,8J:I)"P*WO)K@5%NVJ7@+3=
MS_MV/Z_<I;ETU^:&B[N[1=,L:_RYJ=?O(M[ B\="*^$%K89WD/U=ZKMXWZL;
MB*_=U=W:4-S[>K]N&+B\F;<X3#*B=28[+]P%O<A7](:+\FMZGR_J#;:KEZ01
M2,TWTH0 $M0NZ03F3 048!%,H<IS.201!8B5U\ ;49A1?0@O=JVBJO_Q!%
MYCV3LK"L$BDJ8'G[5#ZU"85U YM?](N!07!9#2%%(S$,CQ7RBMB+C5.7/D&G
MQ%[(IKEPKY'2J,-T1AP%%XN?2' +:0XM9<X$804QA%U#\8V[734!A%[E"]82
M$]YUOOF*T\+8U1=")&*ET9&R=PG.NT]S7@<MHW)41<J:>N 2? =7K1+>#OOW
MM^:NH\NRT/ 5:UP-F,FJW@YFA2?*V+J[6CCWI) N7&._\*/2O3[X,8%@,SP@
MCUB4"@/2%)\48OXF.2U>#7:S,;8/O+"P>5#2T<Y9Q%"J5T!;KX")\<:&D'E#
MK"@]1?0D*C#Q(=ZB"L!]'=0\:C-Z43P+9?@$I#0ZEP39*IC7[16+U%:U0<]C
M!WK9AAC!?0H7BR#+N2#]S_H%JDITY^$Q$>0X*V>?\L5MX/*J'_=K?&?N?TF^
MRI870^/FJW>K+?[%O7%VK7+;^Y9O^2H?H!C;KIF@!GU&,7KNMGVTWU;?B@#K
MJHOII38L >EVL#K27#S)"NLXKK.P\\[.8[9IC\UM/CZQZ_9WY2YHG'@%+\3T
MQ_ X((/;@4Q<"S(>.+<'6<"PVV*Z(1IR%66\W]?Q0C&#^X[Q;3PVQ^RX8[CC
M.1Q"-!ZK*1M;\>$)L_E '0&B3WI%&JR""6-X24/_F M07SEYUG"OX 55=REK
MF5&#;">[@!(*+ZO24FY!09DBQ*XW,+N4<D_N+#^9A6DP+II_9YU[=(,[U $#
MA:/:*V:=!=[)G==] 9Y\%4(4 G?[*'E YE6AAM#8]B\=M$Y_[&CR#L>"!R18
M1+%06 2?Z,97B 1MG;VT>!NOR76B_(;"MB\5';R$8704WCNH?:>OXFVOWA?\
MJM>E81OE*[:ML;0VGN5@;4$8.O#)?:3PDBG/VOOV&EXA:F:DDPR!6(0TML:D
M0,=JQL1855S@%@)\AT#/"A*V&3Y18R3L9>,O$R8=9* TU]\X(H4]+3BVF<M4
MSOYC;RN1Y;$/N,X##=U-4(.\@<QB GB8]:'<7F0<T7!GC'C&R'[V:+IB[Z"1
M%7(SLLP.V?"V9X'KF)EH]_T"C;?@<F51],),,25N5H;)3YABR:QE]>\5>PN?
M>,5MW1!694:QB!G0:S@5<]15F 9:,?GR#MHWAKH[%0 'I!$L#B&R&!-FX:X+
MFA4I)(W-LT8;1T73K)15\]$4AL>8T Y1IHR;GW%4E,;783C#WVLL?XU;+U[1
MRSD!-.=KBT\DG,7E-\0.YITFQO5*LIQ*0\X;+Q3/,!)MCT* D1I?N:M%MR(1
MA"QJ*. M6VJ54ZT85S*XIL 22,M4.#LAAEM3];3SLY-P*MB@;1AHG!__8 7#
MO0R9^V)F_!R2PV@($,KNM )UV:.9;:'S&3##<Y8<G^2O=(Z]@MFE @QJ(S 3
M#;*.G=)*SE?3N1PS:O6KC,3H> :X*)3LV"KAFJ@!<E 5R-:UE1ID@(NE.7(;
M\,AEC"3?K$R]J"GR9O:W&3DA"]P\?9EG#$C6S._6KI9JZGRJ)[)US<F>&A^S
M:O>LI0\9EW;*;@ JLQ99C:DC<K&6Q\<:Y"3K7!UPLS1J7LI;NBE[:>HF5$@U
MK:[.*#DE9XQ+/8<CUHOV$Q(.]@C42@=85)S_<XG$16MF#C?,WVYR4D":?D(Q
MNY9W+8=Q[XYUIU<)4:\_GD &>FV1#5ZGF1:!:V=-F?4R$J(\;L"NNMD.YI+9
M="4, QNZ8%]E7$$J@(-W@*.\VC[OZ?P<10,LR/;28ZSZQIWO1&:H<O9*V3*[
M8KMLIRQ^BVN@MJ.G]67[Y-'1PMJ@6,%>KEEB,^4N/;2E-1G@RFQ98@!L9,;=
M]M-N1,PHP'$T:^[&C"5DLBAY4WMD6\4)=%Y9;<>%5;5VG9A<L3UK2>[:1LTV
M8S:KL:5YFTDJQ[;:/@DQ=\Z=$!TF0DPNV_4Y9Q?7R)R[L"]EQB=C*V/2#!#
M,5_/8&6;@!L^?^3,+)+U*XYM0U(Z"5XQ@U")92MH7L\S+.SNI](LAB/V,+9'
MK-D>F6A1'9L!A=RNS;=YIQ+CF+F;UT!O_LT_2S@?842]A)4M<E;.4#@*0U_A
MNK&?\\V4L_=64:/KKW2=:\5(F&'<>3!Y9_!,!\XS>4:7YAE7IV>W!;HCAZ[.
M78$[5L_GX!6X[S/+'LE3F"5C(6TFF)#@:6 "A6$-L)J:^!#J7:U*(JPFZ^4Q
M"8>#49A]+;:KKU ?[[4ZK#7U/$;'CSI2OQ)U7,K8];F^UN:84S\$9JBL]?$)
MY<?*2+@^\+VZJ57UI[;@W=I5P^J';%<W.*I>@!.!@O];$+Z1<;;Y[M."6H-;
M:PX^D)$U!>?6K7IK2VQH[;2I=0&OU=FZQ-SP94V^DC:77MI.F5S[<!-NK-7U
MNI:V975CAY"35P8,8J\P/0(P6A=M/ERE73.]4\ UVPED+QW^K+VT%M_*EQ<M
MHVGMZB=HS&72=_82)Y\PD?VMD;@9=]I&>RI7Y6\MMI=R!IO6=AN?0.F\78OW
MMK8+>I&[A8SPF2V59=<4,.(\66ACY9@=J^UJ^5[9,'PS6V5)3K)C=A0EU)_[
M0H=NL$::WP"+KN/A6L"$:MBLC&2W7B[&!*%VWVZ?%9R+DXXFX$K8./ONT6W*
M@S1S'MX:&Y3#64.-O'_X\A8!S5O*0._QW)VUVG?&+M:;(&!O.7">5_B)?>7=
M>SZ#;\DMOG4U^9;<+QQ83Z/T'8G[,[^&4F6S$@?HG3?K$(A7KN(/(86,+:<,
MC)+0Z @7,$/">3F[?!ZIMFANC_"\P"@4-?#\D.)\7$E8K89RIL*"2!5 678#
M<2#/U="(><<VM""3T/;MHN;1099+>X85"K("&D14F5NW0T5G3ZA-EDEIR+J^
MO"E?0Y.C8"ALHF1M,1IXTH#G_:'PJ:9#U56KP"RPSK;!SL$K!-(MD :Z@ M0
M8(H6AC63DD4E"#C'+1EH^Q>57+S<6=IVVI[JI[F'%O6XC<;F-AL3SI@U#&AU
MHZ[ QJ4L)2$+K*J!Y3]VIQ/ Q59"*("G1O&@:[RC<TE6WA#\*TU!+,!SOC)4
M&! NP!UO-WO>J;CHC%WGO8+>(1 J;A %$R<'9/>N+; 7>2[WTL1;O^=,59^#
M'7ZN"04TC6&/Z:S><1B"?O5ZPD%7&@G]CRUT&-+0$[MM>4VL1==.]'+1T4.&
M!LO0R5B'LO4C6D,CZH3>A&F H\]1E?71\V]8F$3)8J*X.Z!\@V1++XJ(Z2PG
MQ_2,,-,-J5NXZ4& 8^5TM[#3UVI/-P$_O26O:>94$QX:3JG!7C>H\U"B3M;1
M>O&U"$L]"?@/,SQHAWI1S\I%^ZIN95S^U#TNK97JK\'5_7=;F]79.U>GS70;
MK%MLFX"Q[9%</YH;&Q)_YF%^O.^ZJ:;A>QT$(($=:N&0@[8([%"\=ESVPOYW
M5.<Z'[KJ/>DZAR:0$K+1QF.Z0?&^BA@4WXP(2L2<J#U#!<P!@N+;,WI'W>BU
M0Z;;=.MNT\.4US&T.WX,E-<TT-V[ZJ -"@*B0R/B),_>[:W0(BCL?5PN' ]5
MX\= E?>T^7<N=*)#IYI 1)8(1>5"IM?T+S5K]*9.7P%RELH7]39X K!JB;?$
MV>EM() G!%^H8VL9#Z08?;T-5)QV7FO]G )@98_%N,03%K[NX:T* *(,F%__
M"J16W9">L7C^:HP.&< K$(B*5R*-R])NM01NU%Z)U0GT9\XJ;ITA%Y9(2
MNFE;#:J 5/^XVI!E&I%;+840@5#?:Y@LC@\9*H!7P %;'QXV7@K10);PIYI&
M$>.^I!5-_D4$X2@/,F?/4!W"T)CVWXJA0K.#*[5W3@J9C*4GZDP=K4M@[H:
MR(@@ #\U\PA4J[::O#9HFJDPP ''YR?Z8/" %%1#)E0A[P>N.F(ZFPI.!+ZX
M7-5D>-XC-R%-W(K>!V:93NOA %2%262@E\* P).U([[GG5E#H&;ACB4?\1\^
M\7#X<'ZM6GOGT*5FO2*%J@CD!"C&MQNF:$!9A69M,%<U?)3O%53^5BVKP5XX
MM,&1G\FV_;65Q%&;WPPS52\&H*TZUSE82 S( %KOZ7E"YZ((<TF!B\2-M^M?
MB>+4#KG%(:0.)*V_GK9(#/2\8NE+9F%O,QK^C8_U*LODUWI%7.R[8[HW104?
MU)OZ7@_KH7W:%_;$'M>+'F0?]Y4]\#@HS3[;HWUI7RZH/=H?^=A^76G[MY$R
M2*J0M_C6O>+CB#"%\34^E:CI'7\%N'J//_-#?E=5^[>FY O[[E0K:,!K !0V
M'^>35K,?\W/^K>%4?L0,G'ZLJA@]+=#O8%:;UG/ZH@^833S2=UR0JV$K9@22
M>-Z EF U%,ZWW4+IUN'BN=58V*?0YX5VB.+<@M3.T:B^"8M ?^'_L(U4J*;H
MLH@IKY/5[=OKOA7%J/O/G-J (+K$T#YQ1^G?] :P_U^O*E1 +QKVY<(9%1\#
M]/?Y__C5_P&(_K'5J "(*JET9T-E(CJE #H?JO>ZM:D?")R$:]@=4!M+9G6
MX+'I.\>'S/.X<$BN218RTB@:;0#"8S?<016,3'?_M4$2(!%1T[T7;("4EZO<
M?^75_;?3#3+V'QH0^OE2$][-0\Q9>,0:#8<$X$(2A?!0_*T!^M"M<3IP 2)
MGS66 %SI7Z#%[2U;/4DZ,SK1:;<.$-C\53 0%Q38;%%<*: 3F -J7$Y>O+4#
M5FLFV3$WS5TQ.!@^=Y%9<[-;P!6\Z"JI2(#W:K%<^IG=YO_%? "@ ')VJ&UB
MBMMVP;TB@,+JQLH]!%Z!Z5=6.8 LU[@&I@UNN(L"%DD<$JY$884(.F52""!"
MTW5 H1JLY:6I(1X>R=<[$&Y\5P%R?.1#/D#XP0A*9JF7*#B -"D#WRF8N]@
MA94 B ?*(OE'1C4 VCJCX/B5T44$E$H1<@G&$0)@DS(L;&9N8*Z" L2!1!3(
M10<*:G9;2X:WO3SL3V T>3TPMH[TQS:8;%.:'.9U68*B6RG7@:UNLYM!( CJ
M8H ",94'"H %&@T0#L(2EQ<TIGD1+1G4T8*^[6X$7._&'BQ?O!PW9E<-:7'$
MQB; V75D(%Y'PR5SSYMS$+T5?-,;-,>=E6?4G/:FC^EE@(@V)\)17]U<,>C"
M87+B'$DF8\5<Q58'DW-17*_!AN0AX##:H!A8X06$%YY =@;R-QV>@ /B06&1
#F*@
end
--- END cut here ---
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 2:48:26 GMT From: Mills@udel.edu To: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.berkeley.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Mobile TCP/IP (was Re: Can subnets be separated by another net?)
Rob, Thanks for the interesting info. The primary reason my antenna was up at the time you guys were fiddling was that I suspected you eventually would intend to lay paw on the juicy amatuer radio allocation 10.0-10.5 GHz. Fortunately, that push never came to shove. Now, about 220-222 MHz... Dave
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 02:59:35 GMT From: elroy.jpl.nasa.gov!aero!obrien@decwrl.dec.com (Michael O'Brien) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Now, I may be going silly in my old age, but didn't SAIL used to have a port number you could Telnet to that would give you the inside (machine room) and outside temperatures through some digitally interfaced silliness? Surely, SAIL being the premier computer science installation that it is (was), there MUST have been a protocol number duly assigned to this service... -- Mike O'Brien obrien@aerospace.aero.org
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 11:34:29 -0400 From: phone-book@NNSC.NSF.NET To: tcp-ip@nic.ddn.mil Subject: Internet Managers' Phone Book
Hi, The NSF Network Service Center (NNSC) is in the process of compiling a phone book for network managers. The phone book will list the technical contacts for all domains and IP addresses, along with indexes. Our plan is to publish the phone book in late August and distribute it, free of charge, to the technical contacts listed in it (others can buy a copy at cost). The phone book attempts to list the *technical* contacts for every IP network and every DNS domain to at least the primary organization level (i.e. foo.edu, but not necessarily cs.foo.edu). If you are such a contact, by the time you see this note you should have received an e-mail note from us, asking you to confirm the information we have on you. If you have not received such a letter please fill out the template below and send it to us. Note we've also listed some domains and IP network numbers for which we lack an e-mail address to request contact names from. (In some cases it is because we couldn't reach DNS servers at the time we were accumulating information -- it doesn't necessarily). If you see your domain or IP address in the list, please let us know. Thanks! The NNSC Phone-Book Project (phone-book@nnsc.nsf.net) NAME: ADDRESS: PHONE: FAX: E-MAIL: I am responsible for the following domains: I am responsible for the following IP network numbers: ****************************** Domains/Network for which we lack e-mail addresses of contacts: 128.172 128.191 128.192 128.202 128.207 128.209 128.225 128.23 128.232 128.251 128.254 128.37 128.82 128.88 128.9 128.90 128.94 128.97 129.136 129.163 129.164 129.165 129.166 129.167 129.168 129.17 129.182 129.183 129.184 129.185 129.200 129.212 129.228 129.230 129.231 129.235 129.239 129.249 129.251 129.253 129.27 129.45 129.50 129.58 129.80 129.9 129.90 130.1-130.10 130.105 130.114 130.115 130.118 130.120 130.13 130.131 130.148 130.156 130.16 130.162 130.181 130.188 130.19 130.190 130.196 130.201 130.204 130.211 130.212 130.214 130.218 130.22 130.36 130.40 130.47 130.48 130.51 130.52 130.57 130.66 130.76 130.77 130.79 130.80 130.96 130.98 131.101 131.102 131.11 131.117 131.126 131.127 131.129 131.143 131.147 131.148 131.149 131.150 131.153 131.157 131.16 131.160 131.163 131.168 131.17 131.177 131.184 131.189 131.190 131.191 131.197 131.20 131.201 131.213 131.214 131.219 131.221 131.223 131.233 131.237 131.238 131.240 131.241 131.242 131.244 131.245 131.253 131.40 131.47 131.52 131.57 131.58 131.64 131.65 131.66 131.67 131.68 131.69 131.70 131.71 131.72 131.73 131.75 131.76 131.77 131.79 131.80 131.81 131.82 131.83 131.84 131.85 131.86 131.87 131.88 131.89-131.90 131.97 132.10 132.12 132.13 132.145 132.148 132.149 132.150 132.153 132.155 132.158 132.159 132.16 132.164 132.165 132.168 132.169 132.171 132.172 132.179 132.182 132.185 132.189 132.201 132.228 132.229 132.23 132.232 132.233 132.244 132.27 132.31 132.33 132.40 132.48 132.5 132.6 132.79-132.143 132.9 134.113 134.115 134.116 134.119 134.120 134.122 134.125 134.128 134.137 134.142-134.146 134.150 134.154 134.156 134.158 134.168 134.170 134.171 134.176 134.178 134.179 134.180 134.183 134.186 134.187 134.189 134.200 134.201 134.204 134.206 134.209 134.210 134.213 134.214 134.215 134.216 134.217 134.224 134.229 134.230 134.238 134.239 134.243 134.244 134.247 134.249 134.25 134.254 134.26 134.27 134.33 134.35 134.37-134.46 134.47 134.5 134.57 134.59 134.6 134.62 134.63 134.64 134.7 134.71 134.77 134.8 134.81 134.85 134.97 136.141 136.143 136.146 136.147 136.157 136.158 136.163 136.164 136.166 136.171 136.173 136.174 136.179 136.180 136.181 136.183 136.184 136.185 136.186 136.198 136.208 136.213 136.220 136.225 136.226 136.228 136.230-136.239 136.245 136.249-136.254 137.105 137.114 137.115 137.116 137.117 137.118 137.119 137.126 137.129 137.130 137.133 137.135 137.15 137.156 137.158 137.16 137.160 137.168 137.169 137.170 137.171 137.172 137.173 137.174 137.176-137.185 137.188 137.19 137.199 137.20 137.201 137.202 137.207 137.217 137.218 137.221 137.227 137.25-137.27 137.31 137.32 137.33 137.34 137.40 137.42 137.47 137.70 137.71 137.72 137.74 137.83 137.91 137.93 137.96 137.97 138.10 138.12 138.14 138.19 138.22 138.30 138.31 138.32 138.33 138.37 138.39 138.46 138.6 138.62 138.63 138.64 138.66 138.69 138.7 138.76 138.8 138.81 138.82 138.83 138.84 138.85 138.86 139.102 139.105-139.120 139.122 139.123 139.125 139.126 139.131 139.134 139.143 139.144 139.145 139.149 139.150 139.164 139.166 139.168 139.68 139.69 139.71 139.72 139.73 139.74 139.76 139.78 139.81 139.85 139.96 139.98 19 190.55 192.12.101 192.12.121 192.12.122 192.12.129 192.12.13 192.12.131 192.12.14 192.12.155-192.12.170 192.12.172 192.12.217 192.12.218 192.12.219 192.12.236 192.12.251 192.12.28 192.12.6 192.12.7 192.12.89 192.12.90 192.12.93 192.12.99 192.16.152 192.16.172 192.16.174 192.16.175 192.16.177 192.16.183 192.16.185-192.16-192.16.190 192.16.192-192.16.200 192.19.0-192.19.255 192.21.0-192.21.255 192.22.0-192.22.255 192.23.0-192.23.255 192.24.0-192.24.255 192.25.0-192.25.255 192.26.0 192.26.149 192.26.150 192.26.151 192.26.20 192.26.25 192.26.50-192.26.82 192.26.90 192.26.91 192.26.96 192.26.97 192.26.98 192.28.0-192.28.99 192.30.0-192.30.255 192.31.1 192.31.105 192.31.108 192.31.110 192.31.113 192.31.114 192.31.115 192.31.148 192.31.149 192.31.150 192.31.166 192.31.167 192.31.168 192.31.169 192.31.17 192.31.170 192.31.171 192.31.174 192.31.209 192.31.211 192.31.22 192.31.229 192.31.233 192.31.238 192.31.24 192.31.240 192.31.245 192.31.247 192.31.248 192.31.25 192.31.27 192.31.29 192.31.37 192.31.38 192.31.44 192.31.77 192.31.78 192.31.79 192.31.83 192.31.84 192.31.91 192.31.95 192.32.0-192.32.255 192.33.128 192.33.14 192.33.187 192.33.19 192.33.190 192.33.2 192.33.240 192.33.37-192.33.86 192.34.0-192.34.255 192.35.102 192.35.108 192.35.109-192.35.126 192.35.141 192.35.60 192.35.62 192.35.83 192.35.87 192.41.148 192.41.172 192.41.198 192.41.199 192.41.210 192.41.212 192.41.224 192.41.239 192.41.240 192.41.241 192.41.242 192.41.243 192.41.246 192.41.250-192.41.255 192.42.1 192.42.101 192.42.102 192.42.133 192.42.134 192.42.135 192.42.136 192.42.138 192.42.139 192.42.148 192.42.149 192.42.150 192.42.153 192.42.154 192.42.158 192.42.202 192.42.203 192.42.204 192.42.205 192.42.206 192.42.238 192.42.240 192.42.243 192.42.252 192.42.253 192.42.4 192.42.52 192.42.53 192.42.54 192.42.65 192.42.90 192.42.94 192.42.99 192.43.1-192.43.150 192.43.161 192.43.200 192.43.213 192.43.218 192.43.219 192.43.220 192.43.221 192.43.222 192.43.224 192.43.237 192.43.248 192.43.253 192.43.254 192.44.252 192.44.91-192.44.215 192.46.0-192.46.255 192.48.101 192.48.104 192.48.109 192.48.110 192.48.123 192.48.124 192.48.125 192.48.127-192.48.129 192.48.130-192.48.132 192.48.133 192.48.137 192.48.141 192.48.142 192.48.143 192.48.145 192.48.211 192.48.221 192.48.225 192.48.235 192.48.239 192.48.240 192.48.241 192.48.242 192.48.243 192.48.244 192.48.245 192.48.247 192.48.248 192.48.251 192.48.252 192.48.253 192.48.254 192.48.31 192.48.32 192.48.35-192.48.36 192.48.37 192.48.38-192.48.77 192.48.92 192.48.94 192.48.97 192.5.103 192.5.106 192.5.142 192.5.147 192.5.149 192.5.150 192.5.164 192.5.209 192.5.213 192.5.218 192.5.223 192.5.242 192.5.243 192.5.244 192.5.245 192.5.246 192.5.247 192.5.248 192.5.249 192.5.250 192.5.251 192.5.252 192.5.253 192.5.3 192.5.4 192.5.41 192.5.5 192.5.6 192.5.63 192.5.7 192.5.8 192.5.83 192.5.94 192.5.95 192.52.108 192.52.113 192.52.116 192.52.151 192.52.152 192.52.153 192.52.154 192.52.170 192.52.177 192.52.181 192.52.184 192.52.196 192.52.197 192.52.229 192.52.230 192.52.231 192.52.238 192.52.239 192.52.240 192.52.244 192.52.246 192.52.250 192.52.253 192.52.254 192.52.51-192.52.60 192.52.67 192.52.68 192.52.74 192.53.0-192.53.255 192.54.110 192.54.121 192.54.122 192.54.124 192.54.129 192.54.132 192.54.133 192.54.134 192.54.138 192.54.225 192.54.228 192.54.238 192.54.245 192.54.246 192.54.82 192.54.83 192.54.84 192.54.85 192.54.86 192.54.87 192.54.88 192.54.89 192.54.90 192.54.91 192.55.1-192.55.21 192.55.101 192.55.102 192.55.110 192.55.111 192.55.115 192.55.121 192.55.131 192.55.134 192.55.136 192.55.137-192.55.186 192.55.189 192.55.193 192.55.195 192.55.196 192.55.197 192.55.198 192.55.199 192.55.201 192.55.202 192.55.203 192.55.206 192.55.209 192.55.216 192.55.218 192.55.22-192.55.31 192.55.220 192.55.224 192.55.225 192.55.227 192.55.229 192.55.236 192.55.243 192.55.244 192.55.245 192.55.246 192.55.249 192.55.83 192.55.88 192.56.0-192.56.255 192.58.1 192.58.102 192.58.105 192.58.106 192.58.121 192.58.122 192.58.123 192.58.149 192.58.151-192.58.154 192.58.155 192.58.156-192.58.179 192.58.181 192.58.183-192.58.192 192.58.19-192.58.27 192.58.193 192.58.195 192.58.197 192.58.199 192.58.2 192.58.200-192.58.203 192.58.211 192.58.215 192.58.216 192.58.217 192.58.230 192.58.232-192.58.241 192.58.244 192.58.245 192.58.246 192.58.249 192.58.250 192.58.251 192.58.253 192.58.254 192.58.28-192.58.35 192.58.3 192.58.37-192.58.40 192.59.0-192.63.255 192.6.0-192.6.148 192.6.150-192.6.200 192.6.202-192.6.255 192.64.0-192.64.255 192.65.1-192.65.49 192.65.132 192.65.135 192.65.136 192.65.148 192.65.149 192.65.150 192.65.151 192.65.152 192.65.154-192.54.170 192.65.173 192.65.174 192.65.178 192.65.179 192.65.180 192.65.204-192.65.210 192.65.211 192.65.212 192.65.213 192.65.214 192.65.215 192.65.217 192.65.245 192.65.246 192.65.249 192.65.250 192.65.251 192.65.252 192.65.253 192.65.254 192.65.50 192.65.72 192.65.75 192.65.76 192.65.79 192.65.98 192.67.1 192.67.10 192.67.107-192.67.126 192.67.127 192.67.130 192.67.134 192.67.135 192.67.136-192.67.155 192.67.15 192.67.156 192.67.157 192.67.158 192.67.16 192.67.166 192.67.168 192.67.17 192.67.174 192.67.175 192.67.176 192.67.177 192.67.178 192.67.179 192.67.18 192.67.180 192.67.181 192.67.182 192.67.183 192.67.19 192.67.2 192.67.209 192.67.210 192.67.211 192.67.212 192.67.213 192.67.214 192.67.215 192.67.216 192.67.219 192.67.22 192.67.220 192.67.221 192.67.224 192.67.228 192.67.23 192.67.24 192.67.248 192.67.253 192.67.254 192.67.3 192.67.4 192.67.44 192.67.46 192.67.51 192.67.52 192.67.55 192.67.56 192.67.57 192.67.60 192.67.73 192.67.80 192.67.84 192.67.85 192.67.86 192.67.87 192.67.90 192.67.91 192.67.93 192.67.94 192.67.95 192.68.109 192.68.112 192.68.113 192.68.114 192.68.115 192.68.116 192.68.118-192.68.125 192.68.134 192.68.135 192.68.136 192.68.137 192.68.138 192.68.139 192.68.140 192.68.141 192.68.146 192.68.147 192.68.148 192.68.154 192.68.155 192.68.157 192.68.161 192.68.175 192.68.177 192.68.180 192.68.182 192.68.183 192.68.184 192.68.187 192.68.20 192.68.21 192.68.22 192.68.23 192.68.75 192.68.76-192.68.107 192.69.0-192.69.255 195.5.68 20 13.130.in-addr.arpa 14.33.192.in-addr.arpa 143.48.192.in-addr.arpa 152.16.192.in-addr.arpa 154.134.in-addr.arpa 158.132.in-addr.arpa 161.68.192.in-addr.arpa 172.128.in-addr.arpa 177.131.in-addr.arpa 181.130.in-addr.arpa 188.130.in-addr.arpa 188.16.192.in-addr.arpa 19.33.192.in-addr.arpa 192.128.in-addr.arpa 195.58.192.in-addr.arpa 201.132.in-addr.arpa 204.130.in-addr.arpa 212.130.in-addr.arpa 214.131.in-addr.arpa 235.129.in-addr.arpa 239.129.in-addr.arpa 24.31.192.in-addr.arpa 246.58.192.in-addr.arpa 27.31.192.in-addr.arpa 5.5.192.in-addr.arpa 50.65.192.in-addr.arpa 6.5.192.in-addr.arpa 64.131.in-addr.arpa 65.131.in-addr.arpa 66.131.in-addr.arpa 67.131.in-addr.arpa 68.131.in-addr.arpa 69.131.in-addr.arpa 7.12.192.in-addr.arpa 7.134.in-addr.arpa 70.131.in-addr.arpa 71.131.in-addr.arpa 72.131.in-addr.arpa 73.131.in-addr.arpa 75.131.in-addr.arpa 76.131.in-addr.arpa 77.131.in-addr.arpa 79.131.in-addr.arpa 8.5.192.in-addr.arpa 80.131.in-addr.arpa 80.67.192.in-addr.arpa 81.131.in-addr.arpa 82.128.in-addr.arpa 82.131.in-addr.arpa 83.131.in-addr.arpa 84.131.in-addr.arpa 85.131.in-addr.arpa 86.131.in-addr.arpa 87.131.in-addr.arpa 88.131.in-addr.arpa 9.128.in-addr.arpa 93.67.192.in-addr.arpa 97.128.in-addr.arpa 105.130.in-addr.arpa 115.134.in-addr.arpa 118.130.in-addr.arpa 121.12.192.in-addr.arpa 122.12.192.in-addr.arpa 125.48.192.in-addr.arpa ALLIANT.COM ALLIED.COM AMOCO.COM AlphaCDC.COM BRS.COM CAS.ORG CSUHAYWARD.EDU DSC.COM GEORGETOWN.EDU INTERLAN.COM IPTECH.COM KESMAI.COM MALONE.EDU MENTOR.COM NM.ORG NYNEXST.COM PEREGRINE.COM POLYGEN.COM SCO.COM SERI.GOV StPaul.GOV USI.COM VSE.COM
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 04:56:01 GMT From: brian@ucsd.edu (Brian Kantor) To: tcp-ip@nic.ddn.mil Subject: Re: Temperature Quote Protocol
SIO Pier Weather: Tue Jul 24 21:00:00 1990
Air Temperature: 18.2 DegC (64.8 DegF)
Wind: 004.9 Mi/Hr From 179.9 Degrees
Barometer: 29.89 Inches
Water Temperature:
Surface = 22.4 DegC (72.3 DegF)
Bottom = 22.3 DegC (72.1 DegF)
Tide Gauge: 05.58 Ft.
Last Wave Data Record: Tue Jul 24 19:14
Sig Ht: 54.8 Cm Period: 7 Sec
-----------[000333][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 09:21:32 EDT From: Bob Stewart <stewart@xyplex.com> To: sci34hub!eng3!joe@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: How do you get a ENet Addr?
Joe (and anyone else who's interested), The most recent communication I had from Xerox got me some protocol types. As of March 1990, the address was: Xerox Corporation Xerox Systems Institute 475 Oakmead Parkway Sunnyvale, CA 94086 (408) 737-4652 The letter was signed by Fonda Lix Pallone, Customer Administration. That should get you to the right neighborhood. Bob ----------- Bob Stewart (rlstewart@eng.xyplex.com) Xyplex, Boxborough, Massachusetts (508) 264-9900
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 09:42:21 EDT From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu To: TCP/IP List <tcp-ip@nic.ddn.mil> Subject: NCSA KA9Q
Can someone elaborate on the acronyms (?) NCSA & KA9Q used when discussing tn3270? ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 13:48:20 PDT From: postel@venera.isi.edu To: sci34hub!eng3!joe@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
Hi. Ethernet Address blocks are now assigned by the IEEE (212-705-7092). Ethernet Types are still assigned by Xerox (408-737-4652). --jon.
-----------[000336][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 06:59:11 GMT From: zaphod.mps.ohio-state.edu!samsung!emory!km@tut.cis.ohio-state.edu (Ken Mandelberg) To: tcp-ip@nic.ddn.mil Subject: CSLIP problem on SunOS 4.1
I just brought up the beta cslip code for SunOS 4.0 on SunOS 4.1. on a
SS1. I changed nothing, it all slipped into the 4.1 kernel without
change.
When I test it doubled back on itself (null modem from ttya to ttyb),
all seems well until I try a telnet and cat a long file to he
terminal. The output pauses on many multiples of around 250 bytes,
sometimes for several seconds. An "rsh cat" of the same file runs at
the baudrate with no hesitation, as do ftp's.
I also have a SunOS 4.0.x system (as it happens a 386i) running the
same cslip code. When I connect it to the 4.1 system, the telnet
problem only shows in one direction. If the output is generated on 4.1
the pauses occur. If I telnet from 4.1 to 4.0 and do the cat on 4.0,
there are no pauses.
I don't have an easy way to run a 4.0 kernel on the SS1 right now, so I
can't be completely sure that its not a sparc specific problem rather
than an OS interaction.
Any ideas.
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963
-----------[000337][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 07:02:59 GMT From: eru!luth!sunic!mcsun!ukc!slxsys!jpp@BLOOM-BEACON.MIT.EDU (John Pettitt) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
postel@VENERA.ISI.EDU writes: >Network Working Group J. Postel >Request for Comments: XXXX ISI > July 1990 >Temperature Syntax and Semantics >The temperature quote is the current temperature at the location of >the server reported in degrees Celsius (or centigrade). >It is transmitted as decimal digits represented as ASCII printing >characters, preceded with a plus or a minus sign. How about an international option: For the UK it could say `Phew what a scorcher' if the temp is over 68 F and `Brass Monkeys' if it is below. This does assume that JNT will allow some nasty American protocol on their network ... (world == rutherford.ac.uk) -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !
-----------[000338][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 07:17:36 GMT From: uhccux!virtue!comp.vuw.ac.nz!munnari.oz.au!mel.dit.csiro.au!smart@ames.arc.nasa.gov (Robert Smart) To: tcp-ip@nic.ddn.mil Subject: Re: Come on guys, we've got to improve e-mail
In article <159@tots.UUCP> tep@tots.Logicon.COM (Tom Perrine) writes: > >Perhaps we need to take this discussion to one of the above >newsgroups, or start a new mailing list, perhaps mail-modernization or >somesuch? > Comp.mail seems to be unused. It would be nice if people working on the problem would let us hoi polloi know where we are headed. This is such a complicated and multi-faceted problem that it can only be solved correctly on the basis of wide public discussion. Three or ten or even thirty experts in a back room are not going to understand all the ramifications. I would like to see wide discussion before we get to draft RFCs. I apologise for being sexist. Come on gals as well. I apologise for suggesting that X.400 designers are not sensible. I meant that they weeren't sensible to the need for backward compatibility with existing Internet mail systems. Even this is not true. Jacob Palme is the only one that posts descriptions of X.400 meetings to the network and those postings show a lot of common sense and good will. I apologise for posting to the wrong newsgroup. Followups are directed to comp.mail. Mail is important to the general workings of a TCP/IP network and I am concerned that the people who care about the TCP/IP suite have written SMTP/RFC822 off prematurely. I think that enhancing SMTP will improve interoperability with X.400 mail and simultaneously provide a backstop in case X.400 is not as successful as many obviously expect. I apologise for ignoring RFC1049 which is a relevant attempt to move things in the right direction. Bob Smart <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz!smart>
-----------[000339][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 07:30:09 GMT From: eru!luth!sunic!mcsun!ukc!slxsys!iann@bloom-beacon.mit.edu (Ian Nandhra) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
postel@VENERA.ISI.EDU writes:
>Network Working Group J. Postel
>Request for Comments: XXXX ISI
> July 1990
> Temperature Quote Protocol
>Status of this Memo
>This RFC suggests an Experimental Protocol for the Internet community.
>Hosts on the Internet that choose to implement a Temperature Quote
> [ lots of stuff deleted, best get the real RFC....]
Now were getting somewhere. However TQP should be regarded as
a stepping stone to the more worthwhile Temperature Syncronisation Protocol
or TSP. There would obviously have to be a few regional variations
to cope with localised concentrations (outbreaks??) of SPARC stations, etc
but these could be agreed with a little give-and-take. Prehaps a
temperature standard of 19C would be acceptable to all.
If sucessfully implemented, such a protocol would also contribute
towards reducing Global Warming.
Ian.
--
Ian Nandhra, Specialix, 3 Wintersells Road, Byfleet, Surrey, KT14 7LF, UK
{backbone}!mcsun!ukc!slxsys!iann iann@specialix.co.uk
Tel: +44 (0) 9323 54254 Fax: +44 (0) 9323 52781 Telex: 918110 SPECIX G
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-----------[000340][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 11:53:00 EDT From: <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca> To: tcp-ip@NIC.DDN.MIL Subject: BSMTP description wanted
Can someone direct me to a document that defines the BSMTP protocol, or at least describes the differences between it and SMTP? Thanks in advance. ________________________ Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN Computer Services Centre, BIX: bfillmore Energy, Mines, & Resources Canada Voice: (613) 992-2832 588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
-----------[000341][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 15:17:59 -0400 From: vcerf@NRI.Reston.VA.US To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Cc: iab@venera.isi.edu, iesg@NRI.Reston.VA.US Subject: RARE Networkshop Announcement
===============================================
Call for Papers and Conference Announcement.
2nd Joint European Networking Conference
Blois, France
May 13-16, 1991
Organized by RARE (Reseaux Associes pour la Recherche Europeenne)
in cooperation with :
o EARN
o EUnet (EUUG),
o Internet Activities Board,
o Nordunet,
o Ministere de la Recherche et de la Technologie (France)
Goals
This conference is a successor to the conference organized by EARN and RARE
in May 1990 at Killarney, providing a forum for the presentation and dis-
cussion of technical and strategic topics related to the provision of net-
working services in research and higher education, as well as corresponding
research and development activities.
The conference addresses mainly technical and managerial staff from local,
national and transnational service provision organizations, but will also
be of high interest to the research engineer, specialised users and members
of funding authorities.
Topics
The conference will cover a wide range of topics of actual interest to aca-
demic network service provision. As a key issue it will concentrate on
"THE CHALLENGE OF THE WORKSTATION TO NETWORKING" :
user aspects of a distributed workstation environment,
requirements on the local and wide-area infrastructure and related
services, impacts on management and service provision strategies.
Much emphasis will be placed on continuing and enhancing the discus-
sion between members of different networking communities, building on the
positive experience of Killarney.
Conference Venue
The event will take place in the historic region of the "Chateaux de la Loire"
at Blois, France. The conference itself will be organized in the
ancient building of the "Halle aux Grains", converted into a modern conference
center with ample space for small meetings in the margin of the conference.
The conference aims at an attendance of not more than 400 participants. A
first invitation with information on how to register will be distributed
in December. Places will be allocated on a first come - first served basis.
Please contact the RARE Secretariat if you wish to ensure that you will
receive an invitation.
Call for Papers, Proceedings.
As for RARE conferences in the past, the programme will be a combination of
sollicited and submitted papers. 1-page summaries of proposed papers should
arrive at the programme chair not later than Oct. 29. It is intended to
produce proceedings of the conference.
Topics for submitted papers: all papers fitting in the general outline of
the conference, in particular:
- Emerging services and new applications
- Information services
- Distributed communications
- The role of network service provision in a workstation environment:
operations, management, security, user support
- Workstations and the LAN/MAN/WAN infrastructure
- Workstations and distributed applications/services
- High performance technology and networking
- OSI application layer services, transition
- Access to services : from the national to the intercontinental level
(fat pipes, backbones, service coordination)
- TCP/IP and European connectivity
- TCP/IP - OSI interworking
- Standards, coordination and harmonization of protocols
- User support strategies and facilities
- Improving the efficiency of end-user services through coordination
- Cosine progress
- Network management:technology, operational issues
- Security and privacy
- The new situation in Europe: the impact on networking services
- Policy issues and financial aspects
For further information contact:
Programme chair:
RARE Secretariat Prof. Juergen Harms
Postbus 41882 CUI
NL 1009 DB Amsterdam 12 rue du Lac
CH-1207 Geneve
tel +31 20 592 5078 tel +41 22 787 6580, 6581
fax +31 20 592 5043 fax +41 22 735 3905
email raresec@nikhef.nl email harms@cui.unige.ch
Programme committee:
Vint Cerf Juergen Harms Christian Michau Sven Tafvelin
Robert Cooper Dennis Jennings Claus Sattler Paul Van Binst
Marieke Dekker Sylvain Langlois Peter Stone
-----------[000342][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 13:42:21 GMT From: SSJACK@ECUVM1.BITNET To: comp.protocols.tcp-ip Subject: NCSA KA9Q
Can someone elaborate on the acronyms (?) NCSA & KA9Q used when discussing tn3270? ======================================================================== Jack E. McCoy SSJACK@ECUVM1.BITNET Systems Programmer (919) 757 - 6401 East Carolina University Greenville, NC 27858 ========================================================================
-----------[000343][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 13:58:21 GMT From: smb@ulysses.att.com (Steven Bellovin) To: comp.protocols.tcp-ip Subject: Re: Network Temperature Protocol
In article <8078@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes: > You probably don't want to hear this, but there are a number of > protocols and formats for weather info defined by the > "World Meterological Organization" (WMO). I hope we don't have to use ASN.1 to encode them....
-----------[000344][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 14:39:23 GMT From: Craig_Everhart@TRANSARC.COM To: comp.protocols.tcp-ip Subject: Re: Is underscore legal in the local-part of an address?
RFC822 says that periods are legal but somewhat restricted in local-parts. You can't legally have two periods following each other, and you can't have the local-part begin or end with a period. Thus, joe.blow@toaster.com is legal, while joe..blow@toaster.com jane.smith.jr.@toaster.com are not. (The local-part is made up of a sequence of period-separated ``word''s, and an unquoted ``word'' may not contain a period.) As to the ``phrase'' that precedes a route-addr, the syntax is slightly different (a space-separated sequence of ``word''s), and a period anywhere in it needs to be quoted. This is traditionally done by quoting the entire phrase text. Thus, Joe Blow <joe@toaster.com> "Jane Smith Jr." <jane@toaster.com> are legal, but Jane X. Smith <jane@toaster.com> is not. Then again, your programmer who believed that all other mailer implementations strictly follow RFC 822 was a bit naive. ``Liberal in what you accept, conservative in what you generate.'' Craig
-----------[000345][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 15:34:29 GMT From: phone-book@NNSC.NSF.NET To: comp.protocols.tcp-ip Subject: Internet Managers' Phone Book
Hi, The NSF Network Service Center (NNSC) is in the process of compiling a phone book for network managers. The phone book will list the technical contacts for all domains and IP addresses, along with indexes. Our plan is to publish the phone book in late August and distribute it, free of charge, to the technical contacts listed in it (others can buy a copy at cost). The phone book attempts to list the *technical* contacts for every IP network and every DNS domain to at least the primary organization level (i.e. foo.edu, but not necessarily cs.foo.edu). If you are such a contact, by the time you see this note you should have received an e-mail note from us, asking you to confirm the information we have on you. If you have not received such a letter please fill out the template below and send it to us. Note we've also listed some domains and IP network numbers for which we lack an e-mail address to request contact names from. (In some cases it is because we couldn't reach DNS servers at the time we were accumulating information -- it doesn't necessarily). If you see your domain or IP address in the list, please let us know. Thanks! The NNSC Phone-Book Project (phone-book@nnsc.nsf.net) NAME: ADDRESS: PHONE: FAX: E-MAIL: I am responsible for the following domains: I am responsible for the following IP network numbers: ****************************** Domains/Network for which we lack e-mail addresses of contacts: 128.172 128.191 128.192 128.202 128.207 128.209 128.225 128.23 128.232 128.251 128.254 128.37 128.82 128.88 128.9 128.90 128.94 128.97 129.136 129.163 129.164 129.165 129.166 129.167 129.168 129.17 129.182 129.183 129.184 129.185 129.200 129.212 129.228 129.230 129.231 129.235 129.239 129.249 129.251 129.253 129.27 129.45 129.50 129.58 129.80 129.9 129.90 130.1-130.10 130.105 130.114 130.115 130.118 130.120 130.13 130.131 130.148 130.156 130.16 130.162 130.181 130.188 130.19 130.190 130.196 130.201 130.204 130.211 130.212 130.214 130.218 130.22 130.36 130.40 130.47 130.48 130.51 130.52 130.57 130.66 130.76 130.77 130.79 130.80 130.96 130.98 131.101 131.102 131.11 131.117 131.126 131.127 131.129 131.143 131.147 131.148 131.149 131.150 131.153 131.157 131.16 131.160 131.163 131.168 131.17 131.177 131.184 131.189 131.190 131.191 131.197 131.20 131.201 131.213 131.214 131.219 131.221 131.223 131.233 131.237 131.238 131.240 131.241 131.242 131.244 131.245 131.253 131.40 131.47 131.52 131.57 131.58 131.64 131.65 131.66 131.67 131.68 131.69 131.70 131.71 131.72 131.73 131.75 131.76 131.77 131.79 131.80 131.81 131.82 131.83 131.84 131.85 131.86 131.87 131.88 131.89-131.90 131.97 132.10 132.12 132.13 132.145 132.148 132.149 132.150 132.153 132.155 132.158 132.159 132.16 132.164 132.165 132.168 132.169 132.171 132.172 132.179 132.182 132.185 132.189 132.201 132.228 132.229 132.23 132.232 132.233 132.244 132.27 132.31 132.33 132.40 132.48 132.5 132.6 132.79-132.143 132.9 134.113 134.115 134.116 134.119 134.120 134.122 134.125 134.128 134.137 134.142-134.146 134.150 134.154 134.156 134.158 134.168 134.170 134.171 134.176 134.178 134.179 134.180 134.183 134.186 134.187 134.189 134.200 134.201 134.204 134.206 134.209 134.210 134.213 134.214 134.215 134.216 134.217 134.224 134.229 134.230 134.238 134.239 134.243 134.244 134.247 134.249 134.25 134.254 134.26 134.27 134.33 134.35 134.37-134.46 134.47 134.5 134.57 134.59 134.6 134.62 134.63 134.64 134.7 134.71 134.77 134.8 134.81 134.85 134.97 136.141 136.143 136.146 136.147 136.157 136.158 136.163 136.164 136.166 136.171 136.173 136.174 136.179 136.180 136.181 136.183 136.184 136.185 136.186 136.198 136.208 136.213 136.220 136.225 136.226 136.228 136.230-136.239 136.245 136.249-136.254 137.105 137.114 137.115 137.116 137.117 137.118 137.119 137.126 137.129 137.130 137.133 137.135 137.15 137.156 137.158 137.16 137.160 137.168 137.169 137.170 137.171 137.172 137.173 137.174 137.176-137.185 137.188 137.19 137.199 137.20 137.201 137.202 137.207 137.217 137.218 137.221 137.227 137.25-137.27 137.31 137.32 137.33 137.34 137.40 137.42 137.47 137.70 137.71 137.72 137.74 137.83 137.91 137.93 137.96 137.97 138.10 138.12 138.14 138.19 138.22 138.30 138.31 138.32 138.33 138.37 138.39 138.46 138.6 138.62 138.63 138.64 138.66 138.69 138.7 138.76 138.8 138.81 138.82 138.83 138.84 138.85 138.86 139.102 139.105-139.120 139.122 139.123 139.125 139.126 139.131 139.134 139.143 139.144 139.145 139.149 139.150 139.164 139.166 139.168 139.68 139.69 139.71 139.72 139.73 139.74 139.76 139.78 139.81 139.85 139.96 139.98 19 190.55 192.12.101 192.12.121 192.12.122 192.12.129 192.12.13 192.12.131 192.12.14 192.12.155-192.12.170 192.12.172 192.12.217 192.12.218 192.12.219 192.12.236 192.12.251 192.12.28 192.12.6 192.12.7 192.12.89 192.12.90 192.12.93 192.12.99 192.16.152 192.16.172 192.16.174 192.16.175 192.16.177 192.16.183 192.16.185-192.16-192.16.190 192.16.192-192.16.200 192.19.0-192.19.255 192.21.0-192.21.255 192.22.0-192.22.255 192.23.0-192.23.255 192.24.0-192.24.255 192.25.0-192.25.255 192.26.0 192.26.149 192.26.150 192.26.151 192.26.20 192.26.25 192.26.50-192.26.82 192.26.90 192.26.91 192.26.96 192.26.97 192.26.98 192.28.0-192.28.99 192.30.0-192.30.255 192.31.1 192.31.105 192.31.108 192.31.110 192.31.113 192.31.114 192.31.115 192.31.148 192.31.149 192.31.150 192.31.166 192.31.167 192.31.168 192.31.169 192.31.17 192.31.170 192.31.171 192.31.174 192.31.209 192.31.211 192.31.22 192.31.229 192.31.233 192.31.238 192.31.24 192.31.240 192.31.245 192.31.247 192.31.248 192.31.25 192.31.27 192.31.29 192.31.37 192.31.38 192.31.44 192.31.77 192.31.78 192.31.79 192.31.83 192.31.84 192.31.91 192.31.95 192.32.0-192.32.255 192.33.128 192.33.14 192.33.187 192.33.19 192.33.190 192.33.2 192.33.240 192.33.37-192.33.86 192.34.0-192.34.255 192.35.102 192.35.108 192.35.109-192.35.126 192.35.141 192.35.60 192.35.62 192.35.83 192.35.87 192.41.148 192.41.172 192.41.198 192.41.199 192.41.210 192.41.212 192.41.224 192.41.239 192.41.240 192.41.241 192.41.242 192.41.243 192.41.246 192.41.250-192.41.255 192.42.1 192.42.101 192.42.102 192.42.133 192.42.134 192.42.135 192.42.136 192.42.138 192.42.139 192.42.148 192.42.149 192.42.150 192.42.153 192.42.154 192.42.158 192.42.202 192.42.203 192.42.204 192.42.205 192.42.206 192.42.238 192.42.240 192.42.243 192.42.252 192.42.253 192.42.4 192.42.52 192.42.53 192.42.54 192.42.65 192.42.90 192.42.94 192.42.99 192.43.1-192.43.150 192.43.161 192.43.200 192.43.213 192.43.218 192.43.219 192.43.220 192.43.221 192.43.222 192.43.224 192.43.237 192.43.248 192.43.253 192.43.254 192.44.252 192.44.91-192.44.215 192.46.0-192.46.255 192.48.101 192.48.104 192.48.109 192.48.110 192.48.123 192.48.124 192.48.125 192.48.127-192.48.129 192.48.130-192.48.132 192.48.133 192.48.137 192.48.141 192.48.142 192.48.143 192.48.145 192.48.211 192.48.221 192.48.225 192.48.235 192.48.239 192.48.240 192.48.241 192.48.242 192.48.243 192.48.244 192.48.245 192.48.247 192.48.248 192.48.251 192.48.252 192.48.253 192.48.254 192.48.31 192.48.32 192.48.35-192.48.36 192.48.37 192.48.38-192.48.77 192.48.92 192.48.94 192.48.97 192.5.103 192.5.106 192.5.142 192.5.147 192.5.149 192.5.150 192.5.164 192.5.209 192.5.213 192.5.218 192.5.223 192.5.242 192.5.243 192.5.244 192.5.245 192.5.246 192.5.247 192.5.248 192.5.249 192.5.250 192.5.251 192.5.252 192.5.253 192.5.3 192.5.4 192.5.41 192.5.5 192.5.6 192.5.63 192.5.7 192.5.8 192.5.83 192.5.94 192.5.95 192.52.108 192.52.113 192.52.116 192.52.151 192.52.152 192.52.153 192.52.154 192.52.170 192.52.177 192.52.181 192.52.184 192.52.196 192.52.197 192.52.229 192.52.230 192.52.231 192.52.238 192.52.239 192.52.240 192.52.244 192.52.246 192.52.250 192.52.253 192.52.254 192.52.51-192.52.60 192.52.67 192.52.68 192.52.74 192.53.0-192.53.255 192.54.110 192.54.121 192.54.122 192.54.124 192.54.129 192.54.132 192.54.133 192.54.134 192.54.138 192.54.225 192.54.228 192.54.238 192.54.245 192.54.246 192.54.82 192.54.83 192.54.84 192.54.85 192.54.86 192.54.87 192.54.88 192.54.89 192.54.90 192.54.91 192.55.1-192.55.21 192.55.101 192.55.102 192.55.110 192.55.111 192.55.115 192.55.121 192.55.131 192.55.134 192.55.136 192.55.137-192.55.186 192.55.189 192.55.193 192.55.195 192.55.196 192.55.197 192.55.198 192.55.199 192.55.201 192.55.202 192.55.203 192.55.206 192.55.209 192.55.216 192.55.218 192.55.22-192.55.31 192.55.220 192.55.224 192.55.225 192.55.227 192.55.229 192.55.236 192.55.243 192.55.244 192.55.245 192.55.246 192.55.249 192.55.83 192.55.88 192.56.0-192.56.255 192.58.1 192.58.102 192.58.105 192.58.106 192.58.121 192.58.122 192.58.123 192.58.149 192.58.151-192.58.154 192.58.155 192.58.156-192.58.179 192.58.181 192.58.183-192.58.192 192.58.19-192.58.27 192.58.193 192.58.195 192.58.197 192.58.199 192.58.2 192.58.200-192.58.203 192.58.211 192.58.215 192.58.216 192.58.217 192.58.230 192.58.232-192.58.241 192.58.244 192.58.245 192.58.246 192.58.249 192.58.250 192.58.251 192.58.253 192.58.254 192.58.28-192.58.35 192.58.3 192.58.37-192.58.40 192.59.0-192.63.255 192.6.0-192.6.148 192.6.150-192.6.200 192.6.202-192.6.255 192.64.0-192.64.255 192.65.1-192.65.49 192.65.132 192.65.135 192.65.136 192.65.148 192.65.149 192.65.150 192.65.151 192.65.152 192.65.154-192.54.170 192.65.173 192.65.174 192.65.178 192.65.179 192.65.180 192.65.204-192.65.210 192.65.211 192.65.212 192.65.213 192.65.214 192.65.215 192.65.217 192.65.245 192.65.246 192.65.249 192.65.250 192.65.251 192.65.252 192.65.253 192.65.254 192.65.50 192.65.72 192.65.75 192.65.76 192.65.79 192.65.98 192.67.1 192.67.10 192.67.107-192.67.126 192.67.127 192.67.130 192.67.134 192.67.135 192.67.136-192.67.155 192.67.15 192.67.156 192.67.157 192.67.158 192.67.16 192.67.166 192.67.168 192.67.17 192.67.174 192.67.175 192.67.176 192.67.177 192.67.178 192.67.179 192.67.18 192.67.180 192.67.181 192.67.182 192.67.183 192.67.19 192.67.2 192.67.209 192.67.210 192.67.211 192.67.212 192.67.213 192.67.214 192.67.215 192.67.216 192.67.219 192.67.22 192.67.220 192.67.221 192.67.224 192.67.228 192.67.23 192.67.24 192.67.248 192.67.253 192.67.254 192.67.3 192.67.4 192.67.44 192.67.46 192.67.51 192.67.52 192.67.55 192.67.56 192.67.57 192.67.60 192.67.73 192.67.80 192.67.84 192.67.85 192.67.86 192.67.87 192.67.90 192.67.91 192.67.93 192.67.94 192.67.95 192.68.109 192.68.112 192.68.113 192.68.114 192.68.115 192.68.116 192.68.118-192.68.125 192.68.134 192.68.135 192.68.136 192.68.137 192.68.138 192.68.139 192.68.140 192.68.141 192.68.146 192.68.147 192.68.148 192.68.154 192.68.155 192.68.157 192.68.161 192.68.175 192.68.177 192.68.180 192.68.182 192.68.183 192.68.184 192.68.187 192.68.20 192.68.21 192.68.22 192.68.23 192.68.75 192.68.76-192.68.107 192.69.0-192.69.255 195.5.68 20 13.130.in-addr.arpa 14.33.192.in-addr.arpa 143.48.192.in-addr.arpa 152.16.192.in-addr.arpa 154.134.in-addr.arpa 158.132.in-addr.arpa 161.68.192.in-addr.arpa 172.128.in-addr.arpa 177.131.in-addr.arpa 181.130.in-addr.arpa 188.130.in-addr.arpa 188.16.192.in-addr.arpa 19.33.192.in-addr.arpa 192.128.in-addr.arpa 195.58.192.in-addr.arpa 201.132.in-addr.arpa 204.130.in-addr.arpa 212.130.in-addr.arpa 214.131.in-addr.arpa 235.129.in-addr.arpa 239.129.in-addr.arpa 24.31.192.in-addr.arpa 246.58.192.in-addr.arpa 27.31.192.in-addr.arpa 5.5.192.in-addr.arpa 50.65.192.in-addr.arpa 6.5.192.in-addr.arpa 64.131.in-addr.arpa 65.131.in-addr.arpa 66.131.in-addr.arpa 67.131.in-addr.arpa 68.131.in-addr.arpa 69.131.in-addr.arpa 7.12.192.in-addr.arpa 7.134.in-addr.arpa 70.131.in-addr.arpa 71.131.in-addr.arpa 72.131.in-addr.arpa 73.131.in-addr.arpa 75.131.in-addr.arpa 76.131.in-addr.arpa 77.131.in-addr.arpa 79.131.in-addr.arpa 8.5.192.in-addr.arpa 80.131.in-addr.arpa 80.67.192.in-addr.arpa 81.131.in-addr.arpa 82.128.in-addr.arpa 82.131.in-addr.arpa 83.131.in-addr.arpa 84.131.in-addr.arpa 85.131.in-addr.arpa 86.131.in-addr.arpa 87.131.in-addr.arpa 88.131.in-addr.arpa 9.128.in-addr.arpa 93.67.192.in-addr.arpa 97.128.in-addr.arpa 105.130.in-addr.arpa 115.134.in-addr.arpa 118.130.in-addr.arpa 121.12.192.in-addr.arpa 122.12.192.in-addr.arpa 125.48.192.in-addr.arpa ALLIANT.COM ALLIED.COM AMOCO.COM AlphaCDC.COM BRS.COM CAS.ORG CSUHAYWARD.EDU DSC.COM GEORGETOWN.EDU INTERLAN.COM IPTECH.COM KESMAI.COM MALONE.EDU MENTOR.COM NM.ORG NYNEXST.COM PEREGRINE.COM POLYGEN.COM SCO.COM SERI.GOV StPaul.GOV USI.COM VSE.COM
-----------[000346][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 16:02:03 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <488@eng3.UUCP>, joe@eng3.UUCP (Joe LaRocque) writes: > I have been given a 'chance to excell' by my boss. Simply put, how do > we go about getting a base EtherNet Address assigned to us? I seem to > recall that PARC is still in charge of these numbers. But, I know that > they have moved to San Diego and I no longer have a name or telephone > number for an individual that I can talk to about this request. > > Before I forget....I know that we could get a set of proms from a mfg > who would take care of the problem for us. Our problem is that the new > system we are building requires as few surface mount structures as > possible, so we will be assigning the EtherNet Address via software. > I believe that the IEEE now hand out these numbers, although Xerox still does the actual work. But I am concerned with the idea that you are planning on putting out a device which gets it's Ethernet address from software. I don't have the Ethernet or 802.3 spec handy, but I believe that this is NOT legal. And, even if it is, it's dangerous. It is critical that all Ethernet devices have globally unique addresses. The hardware assignment of these ainsures that there can NEVER be two the same. The portion of the spec allowing software to reset this address is something I've always objected to, but it is there. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000347][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 16:15:24 GMT From: mcsun!inria!cnca!scarpell@uunet.uu.net (Claude Scarpelli) To: tcp-ip@nic.ddn.mil Subject: Re: NDIS Document
In article <492@eng3.UUCP> joe@eng3.UUCP (Joe LaRocque) writes: >Could someone Email a copy of the NDIS Document to me? >Thanks for the assist. > > Joe [Can't mail to you joe : eng3.UUCP appears to be an unregistered site in the french backbone (inria.fr)] I got this file from anonymous ftp at vax.ftp.com (~/pub/ndis-mac.v201.txt) If you can't get it, email me and I'll send you my own copy (over 200 Kb) claude
-----------[000348][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 16:36:40 GMT From: Mills@udel.edu To: groucho!davis@handies.ucar.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Glenn, As you know, the WMO has a bunch of weather forecasting and reporting formats used in the aviation and marine communities. For some years venerable Miami short-wave station WBR70 broadcasted continuous data on various frequencies receivable over significant portions of the globe. While this station has since shut down, Halifax Radio CHU presently broadcasts 75-baud radioteletype messages (along with facsimile maps) on several frequencies. A little known fact is that for some years anybody could TELNET to a magic port on one of my machines (dcn6) and watch the weather flow (translated to ASCII, of course). While I can't guarantee to continue that for my friends, due to shortage of equipment, it sure would be interesting and maybe even useful if some site or other could splice the weather wire and in effect resurrect WBR70. Dave
-----------[000349][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 16:45:56 GMT From: brunix!rws@uunet.uu.net (Central Scrutinizer) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
>Temperature should be in Kelvins. >Steve Helpful Well, then I guess the sign bit would be kind of useless... :-} rick s. <rws@cs.brown.edu>
-----------[000350][next][prev][last][first]---------------------------------------------------- Date: Wed, 25 Jul 90 16:49:04 GMT From: Mills@udel.edu To: brian@ucsd.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Temperature Quote Protocol
jon Postel, If you will assign a port number, I will assign a thermocouple. Dave
-----------[000351][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 18:40:17 GMT From: pacbell.com!tandem!moe!kevinr@ucsd.edu (Kevin J. Rowett) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <1990Jul25.090203.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes: |> In article <488@eng3.UUCP>, joe@eng3.UUCP (Joe LaRocque) writes: |> |> I don't have the Ethernet or 802.3 spec handy, but I believe that this is NOT |> legal. And, even if it is, it's dangerous. It is critical that all Ethernet |> devices have globally unique addresses. The hardware assignment of these |> ainsures that there can NEVER be two the same. The portion of the spec allowing |> software to reset this address is something I've always objected to, but it is |> there. The IEEE spec makes a distintion between globally admin'ed 802.3 addresses and locally admin'ed address. It's actually a bit in the address field. The caveat is that you can have some assurance global admin'ed addresses won't conflict between vendors, but all bets are off if the address is locally admin'ed. In products we build, we give the board a default globally admin'ed address. We still allow the end user to change the current address, but the software will never let him pick a globally assigned style address. Unfortunetly, that aprt of the S/W hasn't been popular with our customers. kevinr@Tandem.com
-----------[000352][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 18:50:18 GMT From: bywater!dagobah!mis@uunet.uu.net (Mark Seiden) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
kmeyer@wrl.dec.com (Kraig Meyer) writes: >In article <> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >||As part of a distributed computing experiment, we are considering >||setting up a Sun workstation, with a bi-metallic strip and small coil >||tempearture device, and providing a network wide reading, combined >||with time of day service and cartesian location data. >The idea of being able to find out about a network node's environment >has some good network management potential. Back when I was at Merit >helping build the original Merit nodes, we started to design a module >which would sense temperatures in and and nearby the processor cabinet. >The idea was that an alarm in the NOC would sound when the temperature >was outside of an appropriate range, and the NOC could call a human to >either turn up the A/C, plug in a fan, or turn the node off. whether you want the temperature of your cpu board or the room temp is open to debate. i believe that large disks with motors and big power supplies are the things which generate the most heat today. anyway you can place the sensor within a reasonable distance of the gadget (20 ft) using an ordinary radio-shack type extension cable... anyway such a gadget is commercially available... Subject: /dev/thermometer want to monitor the temperature in your machine room? run a shell script if a certain temperature is exceeded, or a particular rate of temperature increase is exceeded? there is now such a gadget .. wiztemp-1. -40 C through 88 C with .5 degree C resolution (that's 8 bits...) chart recording software (c and postscript) furnished in source. out of range conditions reported in a user-configurable fashion. small package, connects to serial port (of sun, mac, pc, many unix systems) -- velcro it to the side of your machine... costs $250 including software. avoiding one meltdown could easily justify the cost... 2 yr mfrs warranty, 30 day money back guarantee. available from Seiden and Associates, Inc 16 Woods End Rd Stamford, CT 06905-2727 203 329 2722 mis@seiden.com -- mark seiden, mis@seiden.com, 1-(203) 329 2722 (voice), 1-(203) 322 1566 (fax)
-----------[000353][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 19:06:45 GMT From: ns-mx!jay.weeg.uiowa.edu!jnford@uunet.uu.net (Jay Ford) To: tcp-ip@nic.ddn.mil Subject: multiple subnet masks on same net
We currently have a class-B number (128.255) with 8-bit subnetting (mask 255.255.255.0). Some folks on our campus net have an interest in subdividing a subnet into a bunch of 11-bit sub-subnets (mask 255.255.255.224). The sub-subnets will each contain a small number of systems (< 32), so full 8-bit subnets would be sparsely used. This probably requires a router which has interfaces with different masks, one with 255.255.255.0 and one with 255.255.255.224. We'd like to use a BSD system as a router. I don't think routed (the BSD RIP implementation) will deal with the inconsistent masks, and it doesn't seem that gated likes them very well either. I'd appreciate some advice from anyone who's done this sort of thing. It seems like a fairly reasonable way to better utilize the address space, but the standard software doesn't appear to support it. Thanks. Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242 jnford@jay.weeg.uiowa.edu or jnfordpb@uiamvs.bitnet, 319-335-5555
-----------[000354][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 19:42:17 GMT From: messy!mo@bellcore.com (Michael O'Dell) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA KA9Q
In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes: >Can someone elaborate on the acronyms (?) NCSA & KA9Q used when >discussing tn3270? > >======================================================================== >Jack E. McCoy SSJACK@ECUVM1.BITNET >Systems Programmer (919) 757 - 6401 >East Carolina University Greenville, NC 27858 >======================================================================== NCSA - No, i Can't Simulate Ascii (referring to the EBCDIC nature of the 3270) KA9Q - Key Another 9 Queries (referring to a benchmark used in evaluating remote 3270 performance. -Mike
-----------[000355][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 20:07:17 GMT From: oliveb!tymix!cirrusl!sunstorm!dhesi@apple.com (Rahul Dhesi) To: tcp-ip@nic.ddn.mil Subject: Re: Documentation for the BSD lpd protocol?
There is an amazing book out there that I haven't seen mentioned on Usenet. It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS. It is published by PRENTICE HALL and its ISBN is 0-13-949876-1. At the $41 price I paid, this book is a terrific 772-page gold-mine of information. This book includes comprehensive descriptions of BSD sockets, Xerox XNS, and AT&T's System V Transport Layer interface. There are chapters TFTP, BSD lpd protocol, BSD rsh/rlogin protocol, BSD rmt (remote tape drive) protocol, and a few miscellaneous topics such as remote procedure calls, network performance, Internet/inetd services, and security (including a pretty clear description of Kerberos). If you have any interest at all in networking in a BSD environment, you will probably want to get a copy of your own right away. Tons of real source code is included. This isn't a commercial announcement, since I'm just a happy buyer of this book. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
-----------[000356][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 20:54:47 GMT From: ucrmath!gibson!stebbins@ucsd.edu (john stebbins) To: tcp-ip@nic.ddn.mil Subject: Routing problem solved. Thanks.
Thankyou everyone who responded to my question about the problem I had reaching ucrmath. The problem seems to be with the way ucrmath responds to the connection request. Since my site doesn't exist on any name servers anywhere, ucrmath hangs while waiting for a name resolution. I fixed the problem by having the system administrator at ucr put a dummy name into their hosts file for our site. I also could have registered our site with a name server somewhere. I probably will still do that, as soon as I have time and I figure out how its done. John Stebbins stebbins@ucrmath.ucr.edu or stebbins@137.67.5.1
-----------[000357][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 00:58:00 EDT From: "Roger Fajman" <RAF@CU.NIH.GOV> To: FILLMORE%EMRCAN.BITNET@CU.NIH.GOV Cc: tcp-ip@SRI-NIC.ARPA.NIC.DDN.MIL Subject: Re: BSMTP description wanted
> Can someone direct me to a document that defines the BSMTP protocol, > or at least describes the differences between it and SMTP? > Thanks in advance. See the file CUVMB BSMTP, available from LISTSERV@BITNIC on BITNET. It's somewhat out of date, but is pretty close to the truth.
-----------[000358][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 21:49:31 GMT From: glratt@rice.edu (Glenn Forbes Larrett) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA KA9Q
In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes: >Can someone elaborate on the acronyms (?) NCSA & KA9Q used when >discussing tn3270? NCSA refers to the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. KA9Q - no clue Glenn Larratt glratt@uncle-bens.rice.edu Computing Resource Center OCIS, Rice University, Houston, Texas
-----------[000359][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 21:58:55 GMT From: silver!hughes@iuvax.cs.indiana.edu (larry hughes) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <9007240048.AA00668@bel.isi.edu> postel@VENERA.ISI.EDU writes: > > >Network Working Group J. Postel >Request for Comments: XXXX ISI > July 1990 I'd like to see the daemon take ntpd's lead, and modify the temperature when it gets too hot or cold. ;-) //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
-----------[000360][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 21:59:33 GMT From: ncrlnk!ncrstp!npdiss1!montague@uunet.uu.net (John Montague) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <488@eng3.UUCP> joe@eng3.UUCPJoe LaRocque writes: >I have been given a 'chance to excell' by my boss. Simply put, how do >we go about getting a base EtherNet Address assigned to us? I seem to By this request I believe you mean "How does one obtain an assignment of a block of Universal LAN addresses?" These addresses are assigned by the IEEE Standards Office, 445 Hoes Lane, Piscataway, NJ 08854-4150; there is a nominal fee ($1000). >Before I forget....I know that we could get a set of proms from a mfg >who would take care of the problem for us. Our problem is that the new >system we are building requires as few surface mount structures as >possible, so we will be assigning the EtherNet Address via software. Universally administered addresses must be uniquely assigned to a single LAN node. This normally accomplished by making a permanent address assignment to a physical assembly in a non-volitile register (NOT battery backed-up RAM). If you wish to assign addresses through software you should use "locally administered addresses" which you may choose to be similar to the address you have permanaently assigned to the hardware, differing only in the "Address Administration" bit (the second most significant bit in the 48 bit address: 0= universally administered, 1= locally administered). Extreem care must be taken to ensure that duplicate addresses NEVER occur on the network. John Montague W0RUE Manager, Standards & Architecture NCR, Network Products Division, St. Paul, MN john.montague@stpaul.NCR.COM
-----------[000361][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 22:37:53 GMT From: usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: multiple subnet masks on same net
In article <1951@ns-mx.uiowa.edu>, jnford@jay.weeg.uiowa.edu (Jay Ford) writes: > We currently have a class-B number (128.255) with 8-bit subnetting (mask > 255.255.255.0). Some folks on our campus net have an interest in subdividing a > subnet into a bunch of 11-bit sub-subnets (mask 255.255.255.224). The > sub-subnets will each contain a small number of systems (< 32), so full 8-bit > subnets would be sparsely used. > > This probably requires a router which has interfaces with different masks, one > with 255.255.255.0 and one with 255.255.255.224. We'd like to use a BSD system > as a router. I don't think routed (the BSD RIP implementation) will deal with > the inconsistent masks, and it doesn't seem that gated likes them very well > either. > > I'd appreciate some advice from anyone who's done this sort of thing. It seems > like a fairly reasonable way to better utilize the address space, but the > standard software doesn't appear to support it. > Most routing protocols don't carry the subnet mask along with the routes in the update messages. They assume that there is one consistent subnet mask throughout the entire subnetted net. RIP is like that. OSPF does understand variable length subnet masks and OSPF is in the process of being implemented in parts of the Internet, so you have some help and guidance from Milo Medin at NASA Ames and Dave O'Leary of SURAnet to name two I know. I've designed a variable length subnet mask approach for OSPF, but I haven't implemented it. I think it can be managed in a relatively straightforward way, if you can explain the proper configurations to your user community. Otherwise, rely on trusty proxy ARP. :-) The gated people are working on OSPF for gated, so if you can wait a little you can have a protocol that will run on a BSD system. If your friends were trying to make bigger, not smaller, subnets then you could use the trick of layering several 8-bit subnets onto one interface. cisco calls their configuration "secondary interface", for example. It's wise to tell all hosts on layered subnets that their mask is 255.255.0.0 and rely on proxy ARP. Otherwise, suffer an extra hop thru the local router. I doubt you would want to change your default subnet mask to 11 bits and do a lot of layering to get 8 bit subnets. This sort of trick is nice if you don't want to go to OSPF or if you are migrating from a bridged to mixed environment. AppleTalk DDP-IP gateways like the FastPath and the GatorBox can use transparent subnetting, where a group of addresses are assigned to the gateway for the LocalTalk network. I don't know a way to exploit that for you. --Kent
-----------[000362][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 23:01:06 GMT From: bellcore-2!envy!karn@rutgers.edu (Phil R. Karn) To: tcp-ip@nic.ddn.mil Subject: RE: Network Temperature Protocol
In article <9007242321.AA21214@rt-jqj.Stanford.EDU>, jqj@RT-JQJ.STANFORD.EDU (JQ Johnson) writes: |> I'm afraid we're getting too serious about this "Temperature Quote Protocol" |> stuff. If anyone is tempted to get serious about it, they should write |> an experimental MIB and offer temperature/humidity/... as SNMP variables, |> not using yet another protocol. I can't wait to see how you'll implement SNMP's SET operation, especially for outdoor temperatures. Think of the applications... :-) Phil
-----------[000363][next][prev][last][first]---------------------------------------------------- Date: 25 Jul 90 23:22:02 GMT From: bellcore-2!envy!karn@rutgers.edu (Phil R. Karn) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA KA9Q
In article <25700@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael
O'Dell) writes:
|> KA9Q - Key Another 9 Queries (referring to a benchmark used in
|> evaluating remote 3270 performance.
Ah hem....
"KA9Q" is my FCC-assigned Amateur Radio callsign. From those globally-
unique four alphanumerics one can determine by inspection that it
belongs to the amateur radio service, that it was issued by the United
States government, that I initially obtained it while living in either
Illinois, Indiana or Wisconsin (I was in northern Illinois at the
time), and I hold an Extra Class license. And with a copy of the
(public) database it yields my full name, mailing address, station
address, date of birth and date of license expiration. How's that for
a compact personal address assignment scheme? :-)
Of course, Mike knew better since he's N4NLN ("Not Four New Lan Networks!"
- referring to Mike's views on IEEE 802 subgroup proliferation...)
--Phil
-----------[000364][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 11:21:58 -0700 From: "Philip Almquist" <almquist@jessica.stanford.edu> To: uhccux!querubin@ames.arc.nasa.gov (Antonio Querubin) Cc: tcp-ip@nic.ddn.mil Subject: Re: FNS routing
Antonio,
> It seems that if FNS is smart enough to know which board to use to ping a
> particular address it ought to know how to pass packets it receives to the
> right side of the network. Are we missing something here and doing something
> wrong or is FNS just brain-dead when it comes to routing?
I have never used the Fusion software, but I did observe that
nothing in the command file you included looked like a command telling
Fusion that it was permitted to act as a router. To quote from RFC-1122:
The host software MUST NOT automatically move into gateway
mode if the host has more than one interface, as the
operator of the machine may neither want to provide that
service nor be competent to do so.
Philip
-----------[000365][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 01:16:43 GMT From: usc!samsung!umich!pmsmam!wwm@ucsd.edu (Bill Meahan) To: tcp-ip@nic.ddn.mil Subject: Re: NCSA KA9Q
In article <10229@brazos.Rice.edu> glratt@uncle-bens.rice.edu (Glenn Forbes Larrett) writes: >In article <9007251721.AA16622@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes: >>Can someone elaborate on the acronyms (?) NCSA & KA9Q used when >>discussing tn3270? > >KA9Q - no clue > KA9Q is the amateur radio callsign of Phil Karn (of Bellcore) who has written a TERRIFIC implementation of the IP protocol suite for the PC (since adapted by others to UNIX and the Atari ST). Phil's program (the original version known as NET or NET.EXE or just KA9Q - and the latest called NOS) was developed for amateur radio packet radio operations. Others have found additional uses. -- Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwm I don't speak for Ford - the PR department does that! Any attempt at wit is liable to offend _somebody_!
-----------[000366][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 08:11:37 -0400 From: craig@NNSC.NSF.NET To: mills@udel.edu, tcp-ip@nic.ddn.mil Subject: re: Network Temperature Protocol
> A little known fact is that
> for some years anybody could TELNET to a magic port on one of my
> machines (dcn6) and watch the weather flow (translated to ASCII, of course).
Dave:
I've had this fantasy for about two years now that I'd someday convince
someone to take this sort of weather info (or perhaps satellite weather data
which some sites make available) and combine it with the MERIT geography
server, and allow me, on my bitmapped workstation, to pull up the current
weather map for some part of the country on my workstation screen.
Thus:
csh% weather Princeton
would cause a weather map for the Princeton NJ area to appear on my screen
(and would have allowed me to diagnose that JvNC was down on Tuesday due
to thunderstorms causing power problems).
I mean, what are all this nifty data and these bitmap displays for except
drawing useful pictures?
Craig
-----------[000367][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 02:54:57 GMT From: news-server.csri.toronto.edu!utgpu!molnar@rutgers.edu (Tom Molnar) To: tcp-ip@nic.ddn.mil Subject: tcpdump on 4.3 Reno?
I'd like to make use of tcpdump on the CA*net NSSes (IBM RTs running a modified 4.3BSD similar to NSFnet). The README of the March '90 release of tcpdump said: "Sat Mar 3 04:45:39 PST 1990 This directory file contains yet another beta release of the source for tcpdump. We are still in the middle of replacing the Sun NIT interface with an enhanced version of the CMU/Stanford packet filter that was distributed with 4.3bsd. We hope that the next version of tcpdump will run an any 4bsd system, not just Suns. Our intent is to include the new version with the 4.4bsd distribution. ..." I don't yet have access to the 4.3 Reno distribution. Could someone please tell me if the new tcpdump is available yet? Thanks in advance, Tom -- Tom Molnar Unix Systems Group, University of Toronto Computing Services.
-----------[000368][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 09:45:51 -0400 From: heker@nisc.jvnc.net (Sergio F. Heker) To: craig@NNSC.NSF.NET, mills@udel.edu, tcp-ip@nic.ddn.mil Cc: heker@nisc.jvnc.net Subject: re: Network Temperature Protocol
Craig, I think that would be a neat idea indeed (of course the archaic way of calling our NOC would have also worked :-) ). -- Sergio ___________________________________________________________________________ Sergio Heker Voice: (609)520-2000 (until 8/15) Director, JvNCnet Voice: (609)258-2400 (after 8/15) E-mail: "heker@nisc.jvnc.net" __________________________________________________________________________
-----------[000369][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 08:24:00 EDT From: woody@sparta.com (Robert "Woody" Woodburn) To: phone-book@NNSC.NSF.NET Cc: tcp-ip@nic.ddn.mil Subject: Internet Managers' Phone Book
NAME: Robert A. Woodburn ADDRESS: SAIC-CSEIC, 8619 Westwood Center Drive, Vienna, VA 22182 PHONE: (703) 448-0210 FAX: (703) 734-3323 E-MAIL: woody@sparta.com I think I already mentioned this, but I administer 192.48.111 and 192.5.8 Thanks wood y
-----------[000370][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 04:34:08 GMT From: pacbell.com!tandem!moe!kevinr@ucsd.edu (Kevin J. Rowett) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <146@npdiss1.StPaul.NCR.COM>, montague@npdiss1.StPaul.NCR.COM (John Montague) writes: |> |> Universally administered addresses must be uniquely assigned to a single Gosh the "I" in IEEE sure has grown. I = institue ( as in it ain't a std till I say so) I = International ( as in globally admin addresses) I = Interplanetary ( as in universal) Anyone got the MAC address of the HST? kevinr@tandem.com N6RCE
-----------[000371][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 10:33 EST From: Paul Jones (919) 962-6501 <ULTIMA%UNC.BITNET@ncsuvm.ncsu.edu> To: TCP-IP@NIC.DDN.MIL Subject: Re: Re: NCSA KA9Q
NCSA - National Center for Supercomputing Applications
at University of Ill. Champlain-Urbana
KA9Q - Shortwave radio handle for it's developer. tcp/ip over packet
radio (and a few other handy things too) from Phil Karns.
-----------[000372][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 11:25:38 EDT From: Mike Muuss <mike@BRL.MIL> To: TCP-IP@nic.ddn.mil Subject: Serious Routing Problems
This is one of the most painful trips from Maryland to Boston I have ever seen! -Mike From: Phil Dykstra <phil@BRL.MIL> For ha ha's check this out: traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets 1 ext328 (128.63.4.22) 21 ms 21 ms 26 ms 2 MOFFETT-FLD-MB.DDN.MIL (26.20.0.16) 586 ms 632 ms 272 ms 3 Palo_Alto.CA.NSS.NSF.NET (192.52.195.254) 238 ms * 200 ms 4 Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13) 426 ms 497 ms 261 ms 5 Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15) 275 ms 263 ms 367 ms 6 Princeton.NJ.NSS.NSF.NET (129.140.72.17) 303 ms 257 ms 248 ms 7 zaphod-gateway.jvnc.net (192.12.211.65) 271 ms 294 ms 250 ms 8 hotblack-gateway.jvnc.net (130.94.0.67) 271 ms 384 ms 287 ms 9 capital1-gateway.jvnc.net (130.94.1.9) 556 ms 472 ms 300 ms 10 cheesesteak2-gateway.jvnc.net (130.94.33.250) 459 ms 294 ms 666 ms 11 * * cheesesteak1-gateway.jvnc.net (130.94.32.1) 306 ms 12 * beantown2-gateway.jvnc.net (130.94.27.250) 335 ms 311 ms 13 near-gateway.jvnc.net (130.94.27.10) 335 ms 328 ms 385 ms 14 ihtfp.mit.edu (192.54.222.1) 774 ms * 353 ms 15 SEWAGE.MIT.EDU (18.68.0.8) 576 ms * 303 ms 16 * MOSS.LCS.MIT.EDU (18.10.0.11) 344 ms 365 ms The MILNET throws it as far away as it possibly can, NSFNET spends four (nice orderly) hops getting it to Princeton, and then JVNC spends 7(!) hops getting it to Boston. - Phil
-----------[000373][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 11:51:00 EDT From: <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca> To: tcp-ip@NIC.DDN.MIL Subject: Re: BSMTP information
Thanks very much to everyone who replied with BSMTP information.
The file CUVMB BSMTP at NETSERVE@BITNIC documents the protocol.
I also found a program which implements the protocol:
bsmtp in mod.sources at sh.cs.net
Thanks again for the help!
________________________
Bob Fillmore, Systems Software & Communications BITNET: FILLMORE@EMRCAN
Computer Services Centre, BIX: bfillmore
Energy, Mines, & Resources Canada Voice: (613) 992-2832
588 Booth St., Ottawa, Ontario, Canada K1A 0E4 FAX: (613) 996-2953
-----------[000374][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 07:58:06 GMT From: aruit@idca.tds.PHILIPS.nl (A. de Ruiter) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.pcnet,comp.protocols.misc Subject: Remote File Access via NFS or SMB technologie
Hello World,
I am investigating the possibilities to intergrate remote file access in our
software implementation. Our PC programs are communicating via NetBIOS and
TCP/IP with servers on UNIX systems. On these UNIX systems we have besides
our own servers also a Name Server (NS), Server Message Block (SMB) and
Network File System (NFS) servers. Currently the PC software calls the NS
with a logical document name and gets back with the UNIX system name and
the directory path on that UNIX system where that document is located.
After the location of the document is known it will be copied from that
UNIX system to the PC, to do all kind of actions on that document.
In the new implementation of this PC software we do not want to copy this
document, but do all the actions remotely. To do this we need a PC-NFS or
PC-SMB version which can communicate via NetBIOS and/or TCP/IP with our
UNIX NFS or SMB servers. Another requirement is that the "mount" and
"umount" of the remote file systems/directories must be possible to do
dynamically out of a C program. We can do nothing with a PC-NFS or PC-SMB
versions which use "static" configuration files in which the UNIX system
names and directory paths are described. In our PC applications users are
asking for different documents on different file systems on different
UNIX systems, so at runtime we need to find out where that document is
located and have to "mount" it to a PC drive.
I am searching for a redirector based on NFS or SMB technology to implement
remote file access through an existing private communication. For example
the Microsoft MS-NET redirector does work correctly. It is possible to
"mount" via function 5F subfunction 03 and "umount" via 5F subfunction 04.
If anybody know PC-NFS, PC-SMB or other applications which can do this,
or if you have suggestions to implement remote file access in another way,
please inform me.
--------------------------------------------------------------------------------
|Philips Information Systems
_ __ |Optical Filing Systems, Anton de Ruiter
/_| __ /_ _ __ __/_ /__) ./_ _ _|Post Office Box 245, V2-B2
/ |/ /(_ (_)/ / (_/(-' / \ (_//(_ (-'/ |7300 AE Apeldoorn, The Netherlands
__ ____ ___ |---------------------------------------
/__)/_ ./ ._ _ / /___ |Internet: aruit@idca.tds.philips.nl
/ / //(_ //_)/_) __/_ ___/ |UUCP : ..!mcsun!philapd!aruit
/ |Phone : +31 55 433514
|Fax : +31 55 433488
--------------------------------------------------------------------------------
-----------[000375][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 15:14:21 EDT From: oravax!diomedes.UUCP!li@wrath.cs.cornell.edu (Li Gong) To: tcp-ip@nic.ddn.mil Subject: Re: request to join the Internet mailing list
NIC Operations writes: > Your address looks like it is aways from us. I'd suggest that you > check to see if you have a feed from comp.protocols.tcp-ip. If not > send another message to tcp-ip-request and we'll add you to our list. > > fmc > ------- We don't have a local feed (at least not in the near future). Please add me to the list: cornell!oravax!li or oravax!li@cu-arpa.cs.cornell.edu Thanks! Li
-----------[000376][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 12:11:37 GMT From: craig@NNSC.NSF.NET To: comp.protocols.tcp-ip Subject: re: Network Temperature Protocol
> A little known fact is that
> for some years anybody could TELNET to a magic port on one of my
> machines (dcn6) and watch the weather flow (translated to ASCII, of course).
Dave:
I've had this fantasy for about two years now that I'd someday convince
someone to take this sort of weather info (or perhaps satellite weather data
which some sites make available) and combine it with the MERIT geography
server, and allow me, on my bitmapped workstation, to pull up the current
weather map for some part of the country on my workstation screen.
Thus:
csh% weather Princeton
would cause a weather map for the Princeton NJ area to appear on my screen
(and would have allowed me to diagnose that JvNC was down on Tuesday due
to thunderstorms causing power problems).
I mean, what are all this nifty data and these bitmap displays for except
drawing useful pictures?
Craig
-----------[000377][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 12:43:06 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Network Temperature Protocol
> csh% weather Princeton >I mean, what are all this nifty data and these bitmap displays for except >drawing useful pictures? Craig, joking aside, it would be a very low cost excerise for doing some seriously accurate stats for global warming detection - this was at the back of my mind when originally jesting... joking not aside, i thought only the English took the weather this seriously; i mean sea shells and weather; i ask you:-) jon
-----------[000378][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 14:44:06 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!kline@ucsd.edu (Charley Kline) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
craig@NNSC.NSF.NET writes: >I've had this fantasy for about two years now that I'd someday convince >someone to take this sort of weather info (or perhaps satellite weather data >which some sites make available) and combine it with the MERIT geography >server, and allow me, on my bitmapped workstation, to pull up the current >weather map for some part of the country on my workstation screen. Here at the U of I I can run "wxmap" and then tell it I want a map centered on Champaign and a current conditions map will appear on my X display, complete with weather watch boxes and severe weather risk areas. Radar data is coming soon. The code was homegrown here in the cornfields. The weather data comes from Alden Electronics, a reseller of government weather data. It all comes out in the WMO format, with which I struggle every day. Is this what you mean? _____________________________________________________________________________ Charley Kline, KB9FFK/KT, PP-ASEL c-kline@uiuc.edu University of Illinois Computing Services (217) 333-3339
-----------[000379][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 14:55:23 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: was: the BSD lpd protocol? Stevens' Book
>There is an amazing book out there that I haven't seen mentioned on >Usenet. It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS. It >is published by PRENTICE HALL and its ISBN is 0-13-949876-1. At the >$41 price I paid, this book is a terrific 772-page gold-mine of >information. i second this - it is extremely complete, so far as a 1 hour scan could tell, v. well written and excellent value - i wish there could be an equivalent text for kernel hackery for bsd, svid and, say, mach. then lots of people could stop paying out megabucks to go on commercial courses... the structure is very similar to a course i teach on comms. software, and i think i'm gonna recommend it as a base text.... jon
-----------[000380][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 15:22:09 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bbn.com!craig@ucsd.edu (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <1990Jul26.144406.19495@ux1.cso.uiuc.edu> kline@ux1.cso.uiuc.edu (Charley Kline) writes:
>Here at the U of I I can run "wxmap" and then tell it I want a map centered
>on Champaign and a current conditions map will appear on my X display,
>complete with weather watch boxes and severe weather risk areas. Radar data
>is coming soon.
Charley:
This is precisely the sort of thing I think would be a fun (and useful)
application to have generally available on the Internet.
Craig
-----------[000381][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 13:43:06 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: craig@nnsc.nsf.net Cc: mills@louie.udel.edu, tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
> csh% weather Princeton >I mean, what are all this nifty data and these bitmap displays for except >drawing useful pictures? Craig, joking aside, it would be a very low cost excerise for doing some seriously accurate stats for global warming detection - this was at the back of my mind when originally jesting... joking not aside, i thought only the English took the weather this seriously; i mean sea shells and weather; i ask you:-) jon
-----------[000382][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 15:33:00 GMT From: ULTIMA@UNC.BITNET (Paul Jones 962-6501, 919) To: comp.protocols.tcp-ip Subject: Re: Re: NCSA KA9Q
NCSA - National Center for Supercomputing Applications
at University of Ill. Champlain-Urbana
KA9Q - Shortwave radio handle for it's developer. tcp/ip over packet
radio (and a few other handy things too) from Phil Karns.
-----------[000383][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 16:46:10 GMT From: Mills@udel.edu To: bellcore-2!envy!karn@rutgers.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: NCSA KA9Q
Phil, Not quite your perfect personal identifier, your callsign, since historically the mapping has changed. I hold W3HCF, which does not divulge my Extra Class, formerly held K2GUP, W8EJQ, GM5AWF and F0BCX in various countries and states. In addition, lots of countries have gone out of business and new ones have taken their places and callsigns. You can, however, assume the callsign assignment is globally unique as long as you keep your history books up to date. Dave
-----------[000384][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 17:02:09 GMT From: Mills@udel.edu To: craig@nnsc.nsf.net Cc: mills@udel.edu, tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Craig, I've had this fantasy, too. Problem is our government wants to get out of the distribution business leaving the commercial sector to make a buck. There are, of course, various weather feeds, but it seems they are really intended for for-profit distribution and then not in raw form, but various "value added" forms. I pine for the old raw, ubiquitous broadcasts. At least CHU continues to broadcast, even if it is specialized to the North Atlantic and Ice Patrol. Dave
-----------[000385][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 17:03:51 GMT From: excelan!bbaker@ames.arc.nasa.gov (Brad Baker) To: tcp-ip@nic.ddn.mil Subject: REPOST: NBA Netbios Broadcast Agent (1of2)
REPOST: In straight ascii file 1of2 (make+headers)
Sources for NBA (OS2 and Unix)
Netbios Broadcast Agent
Effectively internets the Netbios Name service.
This program is useful for effectively combining netbios
networks that are separated on the internet.
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface. It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes.
Necessary files are:
makefile (os2)
name.h (os2,unix)
nba.h (os2,unix)
nba.c (os2,unix)
See the documentation header in nba.c for more extensive info.
#
# makefile for OS/2 NBA
#
#-----------------------------------------------
# Definitions for MSC 5.1 Compiler
# /c -- compile only (suppress linking)
# /A$(model) -- Specifies memory model
# /Gs2 -- Disable stack probes, use 286 instructions
# /Zl -- Remove default library info
# /DOS2 -- OS/2 environment
# /DDDL -- use of DDL
# /W3 -- Maximum warning level
#-----------------------------------------------
#
# model can be = lfu - large code, far data, SS != DS
# lnu - large code, near data, SS != DS
# sfu - small code, far data, SS != DS
# snu - small code, near data, SS != DS
#
# See MTDYNA.DOC for more details on this subject
#
model=lfu
#
# include paths - use multi-thread include files
#
XLNPATH=\xln\toolkit
TK_INCL=$(XLNPATH)\include
INCLUDE=-I. -I$(TK_INCL) -I\msc51\include\mt
#
# libpaths should be set in the LIB environment string
#
XLNLIBS=bsd43.lib crtlib.lib
MSLIBS=doscalls.lib
ALL_LIBS=$(XLNLIBS) $(MSLIBS)
#
# compile flags
#
CFLAGS= /c /A$(model) /Ox /Zli /Gs2 /DDLL /DDEBUG /DOS2 /W3 $(INCLUDE)
#
# link flags
#
LFLAGS= /CO /NOD /MAP /NOI
LINKCMD=$(LFLAGS) $** + \xln\toolkit\os2lib\crtexe.obj,$@,$*.map,$(ALL_LIBS)
.c.obj:
cl $(CFLAGS) $*.c > $*.err
nba.obj: nba.c nba.h name.h
##### Link commands ######
nba: nba.obj
link $(LINKCMD);
markexe WINDOWCOMPAT nba.exe
/*
----------------------------------------------------------------------------
Copyright (C) 1990 Novell, Inc.
This software may be freely copied and distributed, provided the
above copyright notice is included. It may not be sold, in whole
or in part, without the prior written consent of Novell, Inc.
----------------------------------------------------------------------------
NAME.H header file for nba.c
*/
#define IP_DGRAM_SZ 576
#define IP_HDR_SZ 20
#define UDP_HDR_SZ 8
#define SZ_BUFFER (IP_DGRAM_SZ - IP_HDR_SZ - UDP_HDR_SZ)
#define SZ_MAXPKTDATA 576 /* maximum data in a packet */
/****************************************************************************
* Domain Name Packet Definitions
***************************************************************************/
#define NM_REG_REQ 0x2910
#define NM_RES 0xad80
#define NM_QRY 0x0110
#define NM_QRY_RES 0x8500
#define NM_QRY_RES1 0x8580
#define NODE_STATUS_REQ 0x0010
#define NODE_STATUS_RES 0x8400
#define NM_OVR_REQ 0x2810
#define NM_RLS_REQ 0x3010
#define PKT_MSK 0xfdf0 /* Mask of bits used for packet type. */
#define RCODE_MSK 0x000f /* Mask of bits used for rcode */
/*
* Mask values for NM_FLAGS. These values treat the fields,
* OPCODE, NM_FLAGS, and RCODE as one word (16 bits).
*/
#define NS_BROADCAST 0x0001
#define NS_RESRVD1 0x0002
#define NS_RESRVD2 0x0004
#define NS_RA 0x0008
#define NS_RD 0x1000
#define NS_TC 0x2000 /* truncation bit */
#define NS_AA 0x4000
/* error codes for RCODE field in packet header */
#define FMT_ERR 0x1 /* Invalidly Formatted Request */
#define SRV_ERR 0x2 /* Server Failure */
#define IMP_ERR 0x4 /* Unsupported Request */
#define RFS_ERR 0x5 /* Registration Refusal */
#define ACT_ERR 0x6 /* Active erroe, name is owned by another node. */
#define CFT_ERR 0x7 /* Name is in conflict */
/* type values */
#define NS_A 0x0100 /* IP address RR */
#define NS_NS 0x0002 /* Name Server RR */
#define NS_NB 0x0020 /* General Name Service RR */
#define NS_NBSTAT 0x0021 /* Node Status RR */
#define NS_NULL 0x000a /* NULL RR - see WACK definition */
#define NS_IN 0x0001 /* Internet class */
/* values for NB_FLAG field in RR data */
#define NS_GROUP 0x8000 /* Group Bit, 1 == Group Netbios Name */
#define NS_MNODE 0x4000
#define NS_PNODE 0x2000
#define NS_DRG 0x1000
#define NS_BNODE 0x0000
#define NS_CNF 0x0800
#define NS_ACT 0x0400
#define NS_PRM 0x0200
/* masks for NB_FLAG field in name data entry */
#define NS_GROUPMSK ~0x8000 /* Group Name Flag */
#define NS_ONTMSK ~0x6000 /* Owner Node Type */
#define NS_STATEMSK ~0x1d00 /* Name State Bits */
/****************************************************************************
* Question Section trailer: preceded by a compressed Netbios name
***************************************************************************/
struct quest_trailer {
unsigned short type;
unsigned short class;
}; /* 4 bytes long */
/****************************************************************************
* Resource Record trailer: preceded by a compressed Netbios name, followed
* by a variable data section
***************************************************************************/
struct rr_trailer {
unsigned short type;
unsigned short class;
unsigned long ttl;
unsigned short length;
}; /* 10 bytes long */
struct rr_info {
struct rr_trailer trailer;
unsigned short flags;
long nbaddr;
}; /* 16 bytes long */
struct nmpkt_hdr {
unsigned short nm_tid; /* transaction id */
unsigned short status; /* opcode, flags, return code */
unsigned short qdcount; /* number of question entries */
unsigned short ancount; /* number of answer records */
unsigned short nscount; /* number of authority records */
unsigned short arcount; /* number of additional records */
}; /* 12 bytes long */
struct namepkt {
struct nmpkt_hdr header;
unsigned char records[SZ_BUFFER - sizeof(struct nmpkt_hdr)];
};
#define NAME_SERVICE_UDP_PORT 137
/*
----------------------------------------------------------------------------
Copyright (C) 1990 Novell, Inc.
This software may be freely copied and distributed, provided the
above copyright notice is included. It may not be sold, in whole
or in part, without the prior written consent of Novell, Inc.
----------------------------------------------------------------------------
NBA.H header file for nba.c
*/
/******* "ignore" this stuff ******/
#ifndef FD_SET
#define NBBY 8 /* number of bits in a byte */
/*
* Select uses bit masks of file descriptors in longs.
* These macros manipulate such bit fields (the filesystem macros use chars).
* FD_SETSIZE may be defined by the user, but the default here
* should be >= NOFILE (param.h).
*/
#ifndef FD_SETSIZE
#define FD_SETSIZE 32
#endif
typedef long fd_mask;
#define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */
#ifndef howmany
#define howmany(x, y) (((x)+((y)-1))/(y))
#endif
#define FD_SET(n, p) ((p)->fds_bits[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
#define FD_CLR(n, p) ((p)->fds_bits[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS)))
#define FD_ISSET(n, p) ((p)->fds_bits[(n)/NFDBITS] & (1 << ((n) % NFDBITS)))
#define FD_ZERO(p) bzero((char *)(p), sizeof(*(p)))
#endif
/**************** real stuff below here *****************/
typedef unsigned short USHORT;
typedef unsigned long ULONG;
typedef unsigned BOOL;
#define TRUE 1
#define FALSE 0
#define NBA_WK_PORT 3000 /* an unassigned port */
#define BAQSIZE 100
#define BAPKTLIFE 5 /* packet life */
#define SZ_NCBNAME 16
#define SOCKADDRSIZE sizeof(struct sockaddr_in)
#define AGENT_NAME_LEN 11
#define FILE_NAME_LEN 80
/* BA status codes */
#define BA_SEND 0
#define BA_REPLY 1
#define BA_ERROR -1
#define NS_RES_MASK 0x8000 /* mask for the NS response bit */
/* conversion macros */
/* convert network order long to network order short */
#define NLtoNS(x) htons((USHORT)ntohl(x))
/* convert network order short to network order long */
#define NStoNL(x) htonl((ULONG)ntohs(x))
struct ba_header {
ULONG status; /* command codes for BA agents */
ULONG time; /* time stamp for packet expiration */
ULONG ns_tid; /* name service transaction id */
ULONG ba_tid; /* BA agent transaction id */
ULONG host_addr; /* BA agent address */
ULONG client_addr; /* NS client address */
ULONG client_port; /* NS client port */
#define BAHEADERSIZE sizeof(struct ba_header)
};
struct ba_pkt {
struct ba_header baheader;
struct namepkt namepkt;
#define BAPKTSIZE sizeof(struct ba_header) + SZ_BUFFER
};
-----------[000386][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 17:08:48 GMT From: excelan!bbaker@ames.arc.nasa.gov (Brad Baker) To: tcp-ip@nic.ddn.mil Subject: REPOST: NBA Netbios Broadcast Agent (2of2)
REPOST: In straight ascii file 2of2 (source)
Sources for NBA (OS2 and Unix)
Netbios Broadcast Agent
Effectively internets the Netbios Name service.
This program is useful for effectively combining netbios
networks that are separated on the internet.
It could also be used to connect to a remote Unix SMB server
allowing for file and print services across the internet.
Written to the BSD 4.3 sockets interface. It has been compiled
and run on 68XXX and SPARC Unix machines, as well as OS/2, with
no code changes.
The necessary files are:
makefile (os2)
name.h (os2,unix)
nba.h (os2,unix)
nba.c (os2,unix)
See the documentation header in nba.c for more extensive info.
/*
----------------------------------------------------------------------------
Copyright (C) 1990 Novell, Inc.
This software may be freely copied and distributed, provided the
above copyright notice is included. It may not be sold, in whole
or in part, without the prior written consent of Novell, Inc.
----------------------------------------------------------------------------
NBA.C Netbios Broadcast Agent by Brad Baker
This is SAMPLE source code, NOT a Novell product,
and will not be supported by the technical staff of Novell.
DESCRIPTION:
This program provides an example of how to forward name service
broadcasts to remote netbios networks connected via gateways or
routers which do not usually forward such packets. It is designed
to be run in either Server mode or Agent mode.
Server mode requires that this program (NBA) be run on the local
network. It receives netbios name query broadcasts (status=0x110) and
replies with a query response (status=0x8500), if the query name and
internet address entry is found in the HOSTS file. No reply packet
is sent if the name is not found in the HOSTS file.
Agent mode involves running one NBA on the local net, and one on
the remote network. The local NBA receives broadcasts on the local
network, saves pertinent packet information such as client address,
port, transaction ID, etc., in a control block (header). The
packet is then prepended with the NBA header, and then forwarded to
the remote NBA. When it is received, the remote NBA strips off
the header, saves (enqueues) the header, and then the original
(de-encapsulated) netbios packet is broadcast on the remote network.
When the remote NBA receive a reply, if at all, to the broadcast,
the header information is dequeued based on the the transaction id of
the reply packet. The destination address, port, and tid of the
reply packet is then set to the (client) values stored in the
dequeued NBA header and the resulting packet is sent (directed) back
to the the client node which made the original broadcast.
This forwarding of the broadcast and reply packets, in effect,
internets the name service.
FEATURES/LIMITATIONS:
* NBA is written to be very portable. It will run on 680xx
and Sparc Unix machines as well as 80286/386 OS2 machines and
should be easily ported to DOS.
* This program makes extensive use of the HOSTS file.
Entries must exist for BROADCAST, LOCALHOST, as well
as any names requiring a response when running NBA in
server mode. If subnetting is in use on the network
the BROADCAST address of the form WW.YY.0xff.0xff may
not work on some BSD implementations. In this case an
appropriate subnet broadcast address should be used.
A subnet broadcast address has the form:
WW.XX.YY.ZZ where
WW.XX = the network portion address
ZZ = the host portion address (all set)
YY = for a node with a subnet mask of 0xfc, this
defines the upper 6 bits of the byte as the subnet
portion (set to the subnet value) and the lower
2 bits (both set) as part of the host portion.
example: subnet mask = 0xfc
network = 0x82.0x39
broadcast on subnet 1 = 0x82.0x39.0x07.0xff
* In order to run NBA (port 137) on Unix requires super-user privilige
The port value should only be changed during testing, and
should always be 137 as this is the UDP name service port.
* When running NBA in server mode, entries in the HOSTS file
should be in upper case.
* Although an agent may receive NBA packets from any number
of remote NBA agents, it will only forward broadcasts to one remote
NBA agent. In other words, an NBA will not simultaneously forward
a packet to multiple remote NBA's. This can be accomplished by
running multiple NBA's on the local net (on different machines)
each of which will receive broadcasts, but forward the packets to
different remote agents/networks.
ENHANCEMENTS:
* Change the queuing mechanism to a more dynamic one. At
present the queue is a static array.
* Make this program run as a detached process, TSR, or
PM application with an improved user interface.
* Provide for the support of multiple remote agents as described in
the LIMITATIONS section above.
BUILD TOOLS:
OS2
This program was built using Novell's Lan Workplace for OS/2 (BSD 4.3
sockets), MSC 5.10, MS link 5.01.21, POLYTRON Polymake V3.1.
UNIX
C compiler
BUILD INSTRUCTIONS:
required files are: nba.c, nba.h, name.h, makefile(os2)
unix> cc nba.c
os2> make nba
USAGE:
nba [[-d] [[-a]{ipaddr}] [[-p]{port}] [[-w]{wport}]]
where ipaddr = the Internet Address of the remote NBA Agent.
port = the port used for name service transactions.
Default is 137 (UDP Name Service Port)
wkport = the "well known port" used for NBA
transactions. Default is 3000
-d = Debug flag. Debug mode prints messages to
STDERR.
examples:
>nba
runs in silent server mode, port 137
>nba -d
runs in debug server mode, port 137
>nba -d -a130.50.5.115 -p2000 -w5000
runs in agent mode (for testing), port 2000, NBA port 5000,
forwarding broadcasts to the remote agent at address 130.50.5.115.
*/
#include <stdio.h>
#include <time.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <errno.h>
#include <signal.h>
#include "name.h"
#include "nba.h"
#ifdef OS2
#include <bsd43.h>
#endif
struct sockaddr_in sock = {AF_INET};
struct sockaddr_in bcast = {AF_INET};
struct sockaddr_in from = {AF_INET};
struct namepkt nspkt;
struct ba_pkt bapkt;
struct ba_header baheader;
struct ba_header baq[BAQSIZE];
struct hostent *host;
struct in_addr inetaddr;
struct in_addr inet_makeaddr();
ULONG host_addr = 0L;
ULONG bcast_addr = 0L;
ULONG agent_addr = 0L;
ULONG ipaddr;
ULONG ipnet;
USHORT baqindex = 0;
int nspkt_size, bapkt_size;
USHORT port = NAME_SERVICE_UDP_PORT; /* the ns listen port */
USHORT wkport = NBA_WK_PORT; /* the ba listen port */
ULONG batidx = 0;
int len = sizeof(from);
int debug = 0;
int sig();
int fd, fda;
char myname[16];
char othername[16];
BOOL use_host_file = FALSE;
fd_set sockset;
main(argc, argv)
int argc;
char **argv;
{
char *s;
int nfound;
int setres, optval;
signal(SIGINT /* SIGHUP */ , sig);
setbuf(stdout, 0);
setbuf(stderr, 0);
while (--argc > 0 && (*++argv)[0] == '-') {
s = argv[0] + 1;
switch (*s) {
case 'd':
debug = 1;
fprintf(stderr, "debug enabled\n");
break;
case 'p':
port = atoi(++s);
break;
case 'w':
wkport = atoi(++s);
break;
case 'a':
#ifdef OS2
ipnet = inet_addr(++s);
ipaddr = inet_network(s);
ipaddr = htons((short) ipaddr);
agent_addr = (ipaddr << 16) | ipnet;
/* inetaddr = inet_makeaddr(ipnet,ipaddr); */
/* agent_addr = inetaddr.S_un.S_addr; */
#else
agent_addr = inet_addr(++s);
#endif
break;
default:
fprintf(stderr, "usage: %s nba [[-d] [[-a]{ipaddr}] [[-p]{port}] [[-w]{wport}]]\n", argv[0]);
exit(1);
}
}
if (!agent_addr)
use_host_file = TRUE;
/* get local network information */
if (gethostname(myname, sizeof(myname) - 1)) {
perror("nba: gethostname()");
exit(1);
}
if (debug)
fprintf(stderr, "nba: myname = %s\n", myname);
if (strlen(myname) > 15) {
fprintf(stderr, "nba: - name too long\n");
exit(1);
}
host = gethostbyname(myname);
if (host) {
bcopy(host->h_addr, (char *) &host_addr, host->h_length);
} else {
perror("nba: gethostbyname() \n");
exit(1);
}
if (debug)
fprintf(stderr, "host_addr :0x%lx\n", ntohl(host_addr));
if (debug && (agent_addr))
fprintf(stderr, "agent_addr :0x%lx\n", ntohl(agent_addr));
/* get broadcast IP Address */
host = gethostbyname("broadcast");
if (host) {
bcopy(host->h_addr, (char *) &bcast_addr, host->h_length);
} else {
perror("nba: gethostbyname() \n");
exit(1);
}
cvt(myname); /* convert to upper case */
/* get and bind a socket for netbios name service */
if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("nba: socket()");
exit(1);
}
sock.sin_port = htons(port);
sock.sin_addr.S_un.S_addr = 0l;
if (bind(fd, &sock, sizeof(sock)) < 0) {
perror("nba: bind()");
exit(1);
}
/* get and bind a socket for agent receive */
if ((fda = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("nba: socket()");
exit(1);
}
sock.sin_port = htons(wkport);
sock.sin_addr.S_un.S_addr = host_addr;
if (bind(fda, &sock, sizeof(sock)) < 0) {
perror("nba: bind()");
exit(1);
}
/* process all Broadcast Repeater (BA) and Name Service (NS) packets */
while (1) {
FD_ZERO(&sockset);
FD_SET(fd, &sockset);
FD_SET(fda, &sockset);
/* wait for a pkt on one of the two sockets */
if ((nfound = select(32, &sockset, NULL, NULL, NULL)) < 0) {
perror("nba: select()");
exit(1);
}
/* test for NS socket has data */
if (FD_ISSET(fd, &sockset)) {
process_ns(); /* process NS packets */
}
/* test for BA socket has data */
if (FD_ISSET(fda, &sockset)) {
process_ba(); /* process BA packets */
}
}
} /* ba */
/*
* process_ba() - process incoming BA agent packets
*/
process_ba()
{
int i, chsent;
/* read the socket */
if ((bapkt_size = recvfrom(fda, &bapkt,
sizeof(struct ba_pkt), 0, &from, &len)) < 0) {
perror("nba: recvfrom()");
exit(1);
}
if (debug) {
fprintf(stderr, "|-- NBA PKT -------------------------------\n");
fprintf(stderr, "| size = 0x%x\n", bapkt_size);
fprintf(stderr, "| port = 0x%x\n", ntohs(from.sin_port));
fprintf(stderr, "| addr = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
fprintf(stderr, "|----------------------------------------\n");
}
/* set up the agent tid and change the pkt tid */
bapkt.baheader.ba_tid = htonl(++batidx);
bapkt.namepkt.header.nm_tid = NLtoNS(bapkt.baheader.ba_tid);
/* enqueue the header */
while (baenq(&bapkt)) {
}; /* keep trying until success (a header
* expires) */
/* forward (broadcast) the packet to local net */
sock.sin_port = htons(port);
sock.sin_addr.S_un.S_addr = bcast_addr;
if ((chsent = sendto(fd, &bapkt.namepkt, (int) (bapkt_size - BAHEADERSIZE), 0,
&sock, SOCKADDRSIZE)) < 0) {
perror("nba: sendto()");
exit(1);
}
if (debug)
fprintf(stderr, ">>> Broadcast 0x%x bytes to Port:0x%x Addr:0x%lx\n",
chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));
} /* process_ba */
/*
* process_ns() - process incoming name service packets
*/
process_ns()
{
int i, chsent;
struct ba_header *phdr;
/* read the socket */
if ((nspkt_size = recvfrom(fd, &bapkt.namepkt,
sizeof(struct namepkt), 0, &from, &len)) < 0) {
perror("nba: recvfrom()");
exit(1);
}
/* if broadcast encapsulate the NS packet and send to BA agent */
if (!(ntohs(bapkt.namepkt.header.status) & NS_RES_MASK)) {
/* skip the broadcast if it came from this node */
if (from.sin_addr.S_un.S_addr != host_addr) {
if (debug) {
fprintf(stderr, "|-- NETBIOS PKT --------------------------\n");
fprintf(stderr, "| size = 0x%x\n", nspkt_size);
fprintf(stderr, "| port = 0x%x\n", ntohs(from.sin_port));
fprintf(stderr, "| addr = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
fprintf(stderr, "| tid = 0x%x\n", ntohs(bapkt.namepkt.header.nm_tid));
fprintf(stderr, "| type = 0x%x\n", ntohs(bapkt.namepkt.header.status));
fprintf(stderr, "|--------------------------------------\n");
}
/*
* if we are running in server mode process the pkt
* locally
*/
if (use_host_file) {
respond_local(&bapkt.namepkt);
return;
}
/* set up the baheader */
baheader.client_addr = from.sin_addr.S_un.S_addr;
baheader.client_port = NStoNL(from.sin_port);
baheader.host_addr = host_addr;
baheader.ns_tid = NStoNL(bapkt.namepkt.header.nm_tid);
/*
* prepend the packet (in bapkt.namepkt) with the
* baheader
*/
bcopy((char *) &baheader, (char *) &bapkt, BAHEADERSIZE);
/* send the packet to the other agent */
sock.sin_port = htons(wkport); /* BA "well known" port */
sock.sin_addr.S_un.S_addr = agent_addr; /* BA agent address */
if ((chsent = sendto(fd, &bapkt, (int) (nspkt_size + BAHEADERSIZE), 0,
&sock, SOCKADDRSIZE)) < 0) {
perror("nba: sendto()");
exit(1);
}
if (debug)
fprintf(stderr, ">>> Sent 0x%x bytes to Port:0x%x Addr:0x%lx\n",
chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));
}
}
/* not a broadcast. Lookup in the queue, set up reply pkt if found */
else {
if (debug) {
fprintf(stderr, "|-- NETBIOS PKT --------------------------\n");
fprintf(stderr, "| size = 0x%x\n", nspkt_size);
fprintf(stderr, "| port = 0x%x\n", ntohs(from.sin_port));
fprintf(stderr, "| addr = 0x%lx\n", ntohl(from.sin_addr.S_un.S_addr));
fprintf(stderr, "| tid = 0x%x\n", ntohs(bapkt.namepkt.header.nm_tid));
fprintf(stderr, "| type = 0x%x\n", ntohs(bapkt.namepkt.header.status));
fprintf(stderr, "|--------------------------------------\n");
}
/* dequeue based on the nm_tid */
if (!(badeq(NStoNL(bapkt.namepkt.header.nm_tid), &bapkt))) {
/* restore the pkt tid */
bapkt.namepkt.header.nm_tid = NLtoNS(bapkt.baheader.ns_tid);
/* send the packet to the remote client */
sock.sin_port = NLtoNS(bapkt.baheader.client_port);
sock.sin_addr.S_un.S_addr = bapkt.baheader.client_addr;
if ((chsent = sendto(fd, &bapkt.namepkt, nspkt_size, 0,
&sock, SOCKADDRSIZE)) < 0) {
perror("nba: sendto()");
exit(1);
}
if (debug)
fprintf(stderr, ">>> Sent 0x%x bytes to Port:0x%x Addr:0x%lx\n",
chsent, ntohs(sock.sin_port), ntohl(sock.sin_addr.S_un.S_addr));
}
}
} /* process_ns */
/*
* baenq - enqueue a BA header. returns: 0 if success At present the queue is
* just an array of headers.
*/
int
baenq(header)
struct ba_header *header;
{
int i;
ULONG t;
/* place the header at an empty (expired) location */
for (i = 0; i < BAQSIZE; i++) {
time(&t);
if ((t - baq[i].time) > BAPKTLIFE) {
bcopy((char *) header, (char *) &baq[i], BAHEADERSIZE);
baq[i].time = t; /* time stamp the header */
return (0);
}
}
if (debug)
fprintf(stderr, "XXX Queue full.\n");
return (1);
}
/*
* badeq - dequeue a baheader based on a BATID returns: 0 if success At
* present the queue is just an array of headers.
*/
int
badeq(tid, header)
ULONG tid;
struct ba_header *header;
{
int i;
ULONG t;
/* search for header ba_tid matching the tid */
for (i = 0; i < BAQSIZE; i++) {
time(&t);
/* skip the dead ones */
if ((t - baq[i].time) < BAPKTLIFE) {
if (baq[i].ba_tid == tid) {
bcopy((char *) header, (char *) &baq[i], BAHEADERSIZE);
return (0);
}
}
}
if (debug)
fprintf(stderr, "XXX Header not found.\n");
return (1);
}
/*
* cvt - convert MYNAME to upper case
*/
cvt(src)
char *src;
{
int i;
for (i = 0; i < strlen(src); i++) {
if (isalpha(src[i]))
src[i] = toupper(src[i]);
}
/* fill with blanks */
for (; i <= 15; i++)
src[i] = ' ';
}
/*
* sig - signal handling
*/
sig()
{
#ifdef OS2
soclose(fd);
soclose(fda);
#endif
exit(1);
}
/*
* dns2nb - convert DNS name to NETBIOS name
*/
dns2nb(dnsp, nbp)
char *dnsp; /* ptr to a DNS name */
char *nbp; /* ptr to a 16 byte buffer */
{
unsigned char idx;
unsigned char left;
unsigned char right;
/*
* a compressed Netbios name is always 32 bytes long, so we can loop
* for a fixed amount, as long as the initial length byte is skipped
*/
for (dnsp++, idx = 0; (idx < SZ_NCBNAME); idx++, nbp++) {
left = (*dnsp++ - 'A') << 4;
right = (*dnsp++ - 'A');
*nbp = left + right;
}
} /* end dns2nb() */
/*
* nb2dns - convert NETBIOS name to DNS (first level encoded) name
*/
nb2dns(nbp, dnsp)
char *dnsp; /* ptr to a 32 byte DNS name */
char *nbp; /* ptr to a 16 byte buffer */
{
unsigned char idx;
unsigned char left;
unsigned char right;
for (idx = 0; (idx < SZ_NCBNAME); idx++, nbp++, dnsp++) {
*dnsp = (*nbp >> 4) + 'A';
*(++dnsp) = (*nbp & 0x0f) + 'A';
}
} /* end dns2nb() */
/*
* respond_local - look up name in the hosts file and respond to the query if
* found.
*/
respond_local(nspkt)
struct namepkt *nspkt;
{
char nbname[16];
char temp[17];
char *chp;
struct rr_trailer *trailer;
struct rr_info *info;
int count;
dns2nb(nspkt->records, nbname);
/* strip the trailing spaces (null terminate it) */
for (chp = nbname; isalpha(*chp); chp++);
*chp = 0;
if (debug)
fprintf(stderr, "Hosts file look-up of \"%s\" \n", nbname);
/* get the address from the hosts file */
host = gethostbyname(nbname);
if (host) {
if (debug)
fprintf(stderr, "Address found : 0x%lx\n",
ntohl(*(long *) host->h_addr));
trailer = (struct rr_trailer *) ((char *) nspkt + nspkt_size - 4);
nspkt->header.status = htons(NM_QRY_RES);
nspkt->header.qdcount = 0;
nspkt->header.ancount = htons(1);
trailer->ttl = htons(1);
trailer->length = htons(6);
info = (struct rr_info *) trailer;
info->flags = 0;
info->nbaddr = ntohl(*(long *) host->h_addr);
/* send the response packet (back) to the client */
if ((count = sendto(fd, nspkt,
nspkt_size + sizeof(struct rr_info) - 4,
0, &from, sizeof(struct sockaddr))) < 0) {
perror("nsd: sendto()");
exit(1);
}
if (debug)
fprintf(stderr, ">>> Sent 0x%x bytes to Port:0x%x Addr:0x%lx\n",
count, ntohs(from.sin_port), ntohl(from.sin_addr.S_un.S_addr));
} else { /* gethostbyname() failed */
if (debug)
fprintf(stderr, "Address not found.\n");
}
}
-----------[000387][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 17:23:46 GMT From: helios.ee.lbl.gov!horse.ee.lbl.gov!mccanne@ucsd.edu (Steven McCanne) To: tcp-ip@nic.ddn.mil Subject: Re: tcpdump on 4.3 Reno?
In article <1990Jul26.025457.11527@gpu.utcs.utoronto.ca> molnar@gpu.utcs.utoronto.ca (Tom Molnar) writes: >I don't yet have access to the 4.3 Reno distribution. Could someone >please tell me if the new tcpdump is available yet? The new packet filter is not in the Reno distribution, but will definitely make it into 4.4. I currently have it up on our hp's running BSD Tahoe. We'll include the filter with the next release of tcpdump, which should be fairly soon... Steve
-----------[000388][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 15:55:23 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: Rahul Dhesi <oliveb!tymix!cirrusl!sunstorm!dhesi@apple.com> Cc: tcp-ip@nic.ddn.mil Subject: was: the BSD lpd protocol? Stevens' Book
>There is an amazing book out there that I haven't seen mentioned on >Usenet. It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS. It >is published by PRENTICE HALL and its ISBN is 0-13-949876-1. At the >$41 price I paid, this book is a terrific 772-page gold-mine of >information. i second this - it is extremely complete, so far as a 1 hour scan could tell, v. well written and excellent value - i wish there could be an equivalent text for kernel hackery for bsd, svid and, say, mach. then lots of people could stop paying out megabucks to go on commercial courses... the structure is very similar to a course i teach on comms. software, and i think i'm gonna recommend it as a base text.... jon
-----------[000389][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 20:23:39 GMT From: bellcore-2!envy!karn@rutgers.edu (Phil R. Karn) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <1990Jul26.144406.19495@ux1.cso.uiuc.edu>, kline@ux1.cso.uiuc.edu (Charley Kline) writes: |> Here at the U of I I can run "wxmap" and then tell it I want a map centered |> on Champaign and a current conditions map will appear on my X display, |> complete with weather watch boxes and severe weather risk areas. Radar data |> is coming soon. |> |> The code was homegrown here in the cornfields. The weather data comes |> from Alden Electronics, a reseller of government weather data. It all |> comes out in the WMO format, with which I struggle every day. We also have one of the VSAT dishes on the roof, and one of my colleagues has also been experimenting with displaying it on bitmap screens. It's especially interesting to watch the radar maps when thunderstorms roll through the area. Unfortunately, even though the weather data comes from the government the commercial resellers claim proprietary rights to it, so I'm not sure it could be made freely available over the net. It's like RSA claiming private patent rights to an invention developed with public funds, but don't get me started on that... Phil
-----------[000390][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 20:59:11 GMT From: rochester!spot!sma@rutgers.edu (Susie Armstrong) To: tcp-ip@nic.ddn.mil Subject: Re: Temperature Quote Protocol
Here at WRC we've built a networked weather service which has been extremely
popular. It consists of a weather station on the roof with a thermometer,
windcups, tipping bucket for rainfall, etc. The station continuously feeds
information down a coax cable to a PC which exports the "weather service".
We have a couple of clients tools for various platforms (Xerox workstations
and Suns), which use a simple datagram-based protocol to periodically query
the PC "weather server".
Turns out there are lots of interesting things you can do with a packet worth
of snapshot data from such a weather server. Client tools report obvious
things like current temperature, windspeed, etc and can also be smart enough
to manipulate the data to draw conclusions like how hard it is raining, wind
gusts, etc. (especially important to lunchtime runners in Rochester).
We have weather stations (and their corresponding PC servers) currently in
Webster and Tarrytown NY, Pasadena, Toronto, Dallas, and Atlanta, with El
Segundo and Cambridge, England in the process of installing one. The project
originally started primarily because of one (JWright.wbst128@xerox.com)
person's interest in weather and remote instrumentation - it is now so popular
within Xerox that we've had to work hard with backoff algorithms and ways
of limiting the traffic. Monitoring the traffic indicates the weather service
has at least 1000 users (most continuously polling the server).
There's a lot of weather junkies out there!
Cheers,
Susie Armstrong
System Sciences Lab
Xerox Webster Research Center
armstrong.wbst128@xerox.com
-----------[000391][next][prev][last][first]---------------------------------------------------- Date: Thu, 26 Jul 90 22:10:31 GMT From: Mills@udel.edu To: Charley Kline <swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!kline@ucsd.edu> Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Charlie, With all that horsepower you still struggle with WMO format? Zillions of five-digit encoded obscurities? Surely a wee finite-state autonmaton such as tinkered by one of my students can relieve that tension. Taking this issue seriously, I personally eyeballed a PDP11/40 at Heathrow Airport near London which tapped those digits from the weather wire and produced a quite respectable English rendition suitable for automatic broadcast by regions throughout the country. One of my radios has a feature that announces its frequency in English. Strongly Japanese-accented English. Dave
-----------[000392][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 23:07:30 GMT From: helios.ee.lbl.gov!ncis.tis.llnl.gov!lance.tis.llnl.gov!guerra@ucsd.edu (Frank Guerra) To: tcp-ip@nic.ddn.mil Subject: Basic SLIP questions
I'm hoping that the collective knowledge of the net.readers can shed some
light on my first real networking task. I've been reading the protocols groups
for a couple of weeks now and know that most of this is well known and fairly
trivial, but I'd appreciate any insights.
My first task has been to set up a SLIP connection. Machine A is a PC
running Unix, machine B is a PC running bridge software (Emerging Technologies
ET/Bridge), machine C is a PC with Telnet software, and Machine X is a Sun.
This is what it looks like:
----------------------------------------------------------------------------
Ethernet Backbone
----------------------------------------------------------------------------
|| ||
|| ethernet || ethernet
|| ||
------ ------
| | | |
| | | |
------ ------
_________ _________
[Machine A] [Machine X]
|
| async modem
|
[SLIP interface A]
^
|
------ |/| ------
| | | async modem | |
| | | | |
------ [SLIP interface B] ------
_________ | _________
[Machine B]=============== ethernet ===[Machine C]
The goal is this : Machine B establishes a SLIP connection to Machine A. With
that established, Machine C is then able to telnet to Machine X.
The static routing information for Machine A has three entries :
default <gateway machine> 1
Machine B SLIP interface A 0
Machine C SLIP interface A 0
The route table on Machine B has the single entry :
default SLIP interface B
since Machine B's only interface out is via SLIP interface B.
All of these machines are on the same network, 128.115.26.0.
The questions I have are this :
- Is this legal? Or is it more the case with a SLIP connection that it
requires it's own network in order to hang stuff other stuff off of the
connection? It's been suggested that a new network number would need
to be requested from the NIC. I contend that only a subnet would need
to be requested locally if at all.
- What needs to be in the routing table for SLIP interface B (Machine B)?
It seems that it needs a default address to get out, but is there any more?
- The route table on Machine A has a network entry 128.115.0.0 that routes to
Machine A below the default route and above the entries for Machine B and
Machine C. Hence it seems, that nothing will ever reach, and hasn't yet
reached, either PC if it is being put on the ethernet instead.
- If another sub-net is required for the SLIP connection, how will the rest of
the rest of the network know about it? Will some other machine have to
create proxy ARPs for it, or is this taken care of by the SLIP daemon on the
SLIP host?
- If anyone has had any experience or is using ET/Bridge, I'd appreciate any
comments.
Thanks for any assistance.
Frank M. Guerra
guerra@lance.tis.llnl.gov
-----------[000393][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 23:22:28 GMT From: ssc-vax!bcsaic!carroll@beaver.cs.washington.edu (Jeff Carroll) To: tcp-ip@nic.ddn.mil Subject: WIN/TCP 5.1 error...
I am getting a mystifying error (mystifying because there's nothing in the docs about it) from WIN/TCP on my uVAX II. %LPDSMB-F-FILEREAD, What is happening? What should I check? Jeff Carroll carroll@atc.boeing.com
-----------[000394][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 00:18:36 GMT From: hpcc01!walasek@hplabs.hpl.hp.com (Arthur Walasek) To: tcp-ip@nic.ddn.mil Subject: Re: IBM/HP-UX FTP session hangs on PORT command
>/ hpcc01:comp.protocols.tcp-ip / sscott@camdev.UUCP (Steve Scott) / 8:10 am Jul 19, 1990 / > > >Steve, we have seen a problem for a long time where FTP sessions from IBM >TCPIP to an HP node would fail when the FTP application issued a PORT command. > >Any ideas out there? Well Steve, Here is what we have found out. IBM starts using port address for normal communications starting at port 1000 and working its way up. HP reserves up to port 1024 or system utilities and makes available ports after 1024. Therefore, when you first bring up the IBM and try to start ftp sessions, you have to error on the first 24 protected ports before any data will actually go across. I believe that the standard is to start at 1024, and therefore it is possibly an IBM problem.... We have this problem too, and we set up the IBM to 25 transfers that will error, when TCP/IP comes up.... (really poor fix). If you need anymore information, or if I was too unclear, please mail me.... Arthur Walasek Hewlett Packard ------------------------------ Ideas expressed are my own and are no way the expressions of Hewlett Packard.
-----------[000395][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 00:19:27 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: POP Protocol
In article <270@nih-csl.nih.gov> tpersky@suntory.dcrt.nih.gov (Ted Persky) writes: Would anyone know which of the many mail packages out there implement the Post Office Protocol, POP? This is easily one of the most frequently asked questions on these groups. You should rummage through the comp.archives archives (kept on cs.toronto.edu) for some recent announcements. I'd like to see a newsgroup at some point to cover IMAP, POP, and related protocols. --Ed Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> comp.archives moderator
-----------[000396][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 08:20:09 -0400 From: heker@nisc.jvnc.net (Sergio F. Heker) To: TCP-IP@nic.ddn.mil, mike@BRL.MIL Cc: heker@nisc.jvnc.net, net@nisc.jvnc.net Subject: Re: Serious Routing Problems
Phil, While the number of hops is large over JvNCnet (don't forget that the network extends over eight states) I don't see a "serious routing loop" on your trace, in fact I don't see any routing loop. For your information, the JvNCnet network is a ring of T1s connecting backbone nodes colocated at the phone company point of presence with two cisco routers at each point of presence to add capacity and for reliability purposes. The backbone nodes are located at Trenton NJ, Newark, NJ, New York City, New Haven, CT, Providence, RI, Boston, Mass and Philadelphia, PA. On a test performed just now and attached below, 5 packets were lost of 1000 with an average round trip of 51 ms on the path from one of our hosts at the new JvNCnet headquarters at Princeton University and MIT. This is quite reasonable. We have been monitoring access to NEARnet due to the importance of NEARnet as a whole and specially since the last three weeks we have experienced excellent performance. This was also observed by the NSFNET NOC. Previously we were affected by a limitation to the amount of traffic carried by the JvNCnet together with the routing table size (of about 300 networks) which accounted for memory limitations. Two major changes took place three weeks ago on the JvNCnet cisco routers, the first one was an upgrade of all firmware (400 PROMS) to cisco 8.1 which improved the way cisco 7.1 handled changes of routing information. The second change was a reduction of the cisco image running on the routers. We are very happy with the results and the cooperation of cisco and the JvNCnet members as well as RCI our long distance provider to make these changes expedioustly. In anticipation of the installation of the new NSS for NEARnet, JvNCnet will work with NEARnet in the installation of a temporary direct access T1 line connecting NEARnet and JvNCnet directly at the JvNCnet NSS in Princeton. The JvNCnet and NEARnet NOCs are working together to make this new NSS transition become transparent to the users. We always welcome comments on the network, however you should probably send them to a list more dedicated to this purpose than "tcp-ip". If you do see a loop or a performance problem could you please send a message to our NOC. We can be reached at "noc@nisc.jvnc.net". Thank you very much. -- Sergio -- begin forwarded message -- From owner-tcp-ip Thu Jul 26 18:24:56 1990 Received: by nisc.jvnc.net (5.61/1.34) id AA01801; Thu, 26 Jul 90 18:24:54 -0400 Received: from jvncb.csc.org by nisc.jvnc.net (5.61/1.34) id AA01797; Thu, 26 Jul 90 18:24:52 -0400 Received: from NIC.DDN.MIL by jvncb.csc.org (5.61/1.34) id AA02895; Thu, 26 Jul 90 18:29:44 -0400 Received: from WOLF.BRL.MIL by NIC.DDN.MIL with TCP; Thu, 26 Jul 90 08:42:22 PDT Received: by WOLF.BRL.MIL id aa14006; 26 Jul 90 11:33 EDT Date: Thu, 26 Jul 90 11:25:38 EDT From: Mike Muuss <mike@BRL.MIL> To: TCP-IP@nic.ddn.mil Subject: Serious Routing Problems Message-Id: <9007261125.aa13838@WOLF.BRL.MIL> Status: RO This is one of the most painful trips from Maryland to Boston I have ever seen! -Mike From: Phil Dykstra <phil@BRL.MIL> For ha ha's check this out: traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets 1 ext328 (128.63.4.22) 21 ms 21 ms 26 ms 2 MOFFETT-FLD-MB.DDN.MIL (26.20.0.16) 586 ms 632 ms 272 ms 3 Palo_Alto.CA.NSS.NSF.NET (192.52.195.254) 238 ms * 200 ms 4 Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.13) 426 ms 497 ms 261 ms 5 Ann_Arbor.MI.NSS.NSF.NET (129.140.81.15) 275 ms 263 ms 367 ms 6 Princeton.NJ.NSS.NSF.NET (129.140.72.17) 303 ms 257 ms 248 ms 7 zaphod-gateway.jvnc.net (192.12.211.65) 271 ms 294 ms 250 ms 8 hotblack-gateway.jvnc.net (130.94.0.67) 271 ms 384 ms 287 ms 9 capital1-gateway.jvnc.net (130.94.1.9) 556 ms 472 ms 300 ms 10 cheesesteak2-gateway.jvnc.net (130.94.33.250) 459 ms 294 ms 666 ms 11 * * cheesesteak1-gateway.jvnc.net (130.94.32.1) 306 ms 12 * beantown2-gateway.jvnc.net (130.94.27.250) 335 ms 311 ms 13 near-gateway.jvnc.net (130.94.27.10) 335 ms 328 ms 385 ms 14 ihtfp.mit.edu (192.54.222.1) 774 ms * 353 ms 15 SEWAGE.MIT.EDU (18.68.0.8) 576 ms * 303 ms 16 * MOSS.LCS.MIT.EDU (18.10.0.11) 344 ms 365 ms The MILNET throws it as far away as it possibly can, NSFNET spends four (nice orderly) hops getting it to Princeton, and then JVNC spends 7(!) hops getting it to Boston. From "picasso.jvnc.net" to 18.10.0.11, 7/27/90 8:00am EST ..... 18 bytes from 18.10.0.11: icmp_seq=997. time=29. ms 18 bytes from 18.10.0.11: icmp_seq=998. time=31. ms 18 bytes from 18.10.0.11: icmp_seq=999. time=27. ms ----18.10.0.11 PING Statistics---- 1000 packets transmitted, 995 packets received, 0% packet loss round-trip (ms) min/avg/max = 26/51/932 ______________________________________________________________________________ Sergio Heker Phone # (609)520-2000 (until 8/18) Director, JvNCnet Phone # (609)258-2400 (after 8/18) Email "heker@nisc.jvnc.net" ______________________________________________________________________________
-----------[000397][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 1990 07:01 EST From: KONDA@VM.CC.PURDUE.EDU To: tcp-ip@nic.ddn.mil Subject: Please unsubscribe me from this list.
Thanks.
-----------[000398][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 09:03:30 EDT From: hsw@sparta.com (Howard Weiss) To: TCP-IP@nic.ddn.mil, mike@BRL.MIL Subject: Re: Serious Routing Problems
Here is another very strange route from sparta.com (137.39.6.2) connected to Alternet/UUnet to brl.mil (McLean, Va. to Aberdeen, Md - roughly under 100 miles). This path (Houston, San Diego, Palo Alto, and then back across the county) seems to be the "normal" path taken for traffic from Alternet via Suranet destined for the Milnet! Howie ------------------------------------------------------------ 1 annex.UU.NET (137.39.6.1) 340 ms 360 ms 300 ms 2 janus.UU.NET (192.48.96.1) 300 ms 360 ms 360 ms 3 sura6.sura.net (128.167.59.1) 360 ms 360 ms 360 ms 4 192.80.214.254 (192.80.214.254) 360 ms 360 ms 360 ms 5 Houston.TX.NSS.NSF.NET (129.140.75.9) 420 ms 420 ms 420 ms 6 San_Diego.CA.NSS.NSF.NET (129.140.70.11) 480 ms 480 ms 420 ms 7 Palo_Alto.CA.NSS.NSF.NET (129.140.77.6) 480 ms 480 ms 480 ms 8 Palo_Alto.CA.NSS.NSF.NET (129.140.13.130) 480 ms 540 ms 480 ms 9 BRL.MIL (26.2.0.29) 900 ms 1000 ms 1260 ms
-----------[000399][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 09:45:38 EDT From: jbvb@vax.ftp.com (James B. Van Bokkelen) To: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) Cc: tcp-ip@nic.ddn.mil Subject: Re: POP Protocol
Apropos of this, I am currently trying to: 1) Locate commercially supported PCMAIL, POP or IMAP servers (I know of IBM's and Sun's, both intended for use with the vendor's DOS POP2 client, and the source-form POP server supplied by InterCon) 2) Jawbone big-system vendors into supporting servers for PCMAIL (two supported OS/2 clients, a DOS due in a short while) or either version of POP (several supported OS/2 and DOS clients, but I think they're all POP2). If you know of vendors I don't, send me e-mail. I'll summarize. If you are a potential server vendor/supporter, you're welcome to get in touch as well. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000400][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 05:58:24 GMT From: usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: whois Database
In article <90.207.20:58:20@ira.uka.de> nipper@iramu1.ira.uka.de (Arnold Nipper) writes: From: nipper@iramu1.ira.uka.de (Arnold Nipper) Organization: University of Karlsuhe, West-Germany [Rough translation from the original German. If you want a feed of dnet.inet or any of the other German groups let me know.] Now there's a new "whois" database. It includes (among other things) the information in NETWORK-CONTACTS.TXT.1 from nic.ddn.mil. That includes all of the assigned network numbers as of about a week ago. Access the database remotely with whois -h iramu1.ira.uka.de <key> or interactively as telnet iramu1.ira.uka.de [129.13.10.92] login: whois Instead of "whois -h iramu1.ira.uka.de" you could also say "telnet 129.13.10.92 43", this command connects you to the whois port. Doing it this way only lets you make one query. (Only interesting for sites without name servers or corresponding entries in /etc/hosts file.) ******************************************************************************* Arnold Nipper ** Universitaet Karlsruhe, Am Fasanengarten 5 * nipper@ira.uka.de XLINK, Inst. fuer Betr.- und Dialogsysteme, D-7500 Karlsruhe * +49 721 608 4331 ******************************************************************************* -- [translation by] Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu> comp.archives moderator
-----------[000401][next][prev][last][first]---------------------------------------------------- Date: Fri 27 Jul 90 11:15:16-CDT From: Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL> To: emv@math.lsa.umich.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: whois Database
This posting from Germany brings up an interesting question: Has anyone else created whois databases? What machines? Any on unix platforms? Thanks in advance to any responses. -Matt -------
-----------[000402][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 12:20:35 CDT From: darrel beach <beach@ddnuvax.af.mil> To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil, afddn.cmd@gunter-adam.af.mil Subject: Those Milnet Mailbridges (clarification needed)
Here's a query for the well informed GATEr on the internet. It has to
Mail Bridges and the IGP they use, and how they use EGP. First the drawing:
The addresses are of course bogus and I'm hoping the picture is worth a
thousand words because I'm not gonna describe it in detail:
+----------------------------------+
| |
Mailbridge | | Mailbridge
MB1 -------+ Milnet +------ MB2
26.10.0.100 | 26.0.0.0 | 26.2.0.2
| |
| |
Router G1 | | Router G2
to -------+ +------to 192.50.50.0
192.25.25.0 on | | on 26.1.0.50
26.1.0.25 +-----+-----------------------+----+
| |
| |
| |
Router R1 Router R2
Gateway to Gateway to
131.2.0.0 128.5.0.0 on
26.2.0.131 26.5.0.128
First let's assume the following:
R1 has only MB1 as an EGP neighbor
G1 has only MB1 as an EGP neighbor
R2 has only MB2 as an EGP neighbor
G2 has only MB2 as an EGP neighbor
MB1 and MB2 are using the IGP currently being used by the
Milnet Mailbridges.
The questions:
1. Is the following correct?
Its my understanding that MB1 does not provide the direct Milnet
address for EGP neighbors in its IGP exchange to MB2. This would
result in the following routing table for R1:
192.25.25.0 via 26.1.0.25 at 2 hops;
128.5.0.0 via 26.2.0.2 at 3 hops;
192.50.50.0 via 26.2.0.2 at 3 hops;
If my understanding of what's in the IGP packets is correct, then
the effect is obvious and leads to Mailbridge bashing when a direct
route is available.
2. The real question is yet to come and is moot if I'm wrong about 1.
Let's change the neighboring of R1 to use both MB1 and MB2. Let's
also say that R1 use a 10 minute poll and one mailbridge is polled
every 5 minutes, i.e. the polling is 180 degrees out of phase, wit
MB1 getting polled first. After the first update R1's routing
table would be as follows:
192.25.25.0 via 26.1.0.25 at 1 hops;
128.5.0.0 via 26.2.0.2 at 2 hops;
192.50.50.0 via 26.2.0.2 at 2 hops;
When the update from MB2 was received, it would include the
following infomation:
192.25.25.0 via 26.1.0.25 at 1 hops;
128.5.0.0 via 26.5.0.128 at 1 hops;
192.50.50.0 via 26.1.0.50 at 1 hops;
So, would R1 now overwrite the existing routes with the new ones,
or maintain both routes and use the lowest hopcount??
And the real question is what do various implementations do under
such conditions??? If the routes get overwritten, which seems
logical to me, then you have a table that changes with every
update. If you keep old routes when they're better than new ones,
you could never be sure the better route was still available. I
guess there are several philosophies for handling this situation,
and I'd really like to know which is implemented by whom.
It must be apparent that the real question is what I describe in 1
the real scoop, or real poop. I think it would be very dumb if
true, but I was actually told be someone (who shall now and always
remain nameless) I usually believe that 1 is the real scoop. I was
also told, however, that it would soon change such that the IGP
exchanges would carry the info necessary to preclude 1 and let
everyone have direct routes where possible.
As usual, any info is appreciated, including flames IF THEY INCLUDE USEFUL
INFO.
Darrel Beach
....still only an egg after all this time
-----------[000403][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 13:41 EST From: Electronic Mail Association <0002544290@mcimail.com> To: "tco-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil> Subject: test
this is a test
-----------[000404][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 12:52:24 EDT From: kate@tecnet1.jcte.jcs.mil To: tcp-ip@nic.ddn.mil Subject: novell, tcp, mac, suns, pcs
I am helping put together a mis plan that implements the machines in the title. The sun will be running Sybase applications that the PCs and macs need to get to. The sun is to act as a server of a sort. They are talking about having a novell net also and the users need to be able to go between tcp and novell easily. Actually, everything isn't in stone yet. Something is needed to alow the pcs, macs and sun to be linked. Tops comes to mind but the sun stuff isn't quite right yet. Does anyone out there have any suggestions? The system has to be user friendly. Printers need to be hung somehow so everyone can print. Does anyone know of a print server that can be hooked to the network(not novell, just ethernet) or any other thoughts? Thanks in advance. If you could mail to my mailbox, it would be easier. The news I can read is tedious. Kathi Samec Kate@tecnet1.jcte.jcs.mil
-----------[000405][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 10:54:59 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes: +--------------- | In products we build, we give the board a default globally admin'ed | address. We still allow the end user to change the current address, | but the software will never let him pick a globally assigned | style address. +--------------- Notice that if are are running the Xerox NS (XNS) protocols on a multi-homed host or gateway, you need to be able to set the physical address of all Ethernet interfaces in the host to the same value, as XNS uses that address as the host address. That is, in XNS the globally-unique "host address" is a property of the *host*, not of the interface(s) as in TCP/IP. [Reference: "Internet Transport Protocols", Xerox System Integration Standard XSIS-028112, page 16] What is often to simplify assignment of the "host address" is to use the physical (globally administered) address off the "primary" network interface, or if there is no reasonable notion of "primary", all the physical addresses are read at boot time and the smallest/largest/one_in_slot#0/etc. is chosen as "the" host address, and then that value is written back into *all* of the network interfaces. Clearly, your software restriction would prevent this. +--------------- | Unfortunately, that part of the S/W hasn't been popular with our customers. +--------------- I wonder why... ;-} -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
-----------[000406][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 11:05:13 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: tcpdump on 4.3 Reno?
>I don't yet have access to the 4.3 Reno distribution. Could someone >please tell me if the new tcpdump is available yet? btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno' naming scheme - is't simply placenames? thanks jon
-----------[000407][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 11:07:58 GMT From: eru!luth!sunic!mcsun!unido!ms@BLOOM-BEACON.MIT.EDU (Marc Sheldon) To: tcp-ip@nic.ddn.mil Subject: Socket emulation library for TLI
Some time ago somebody posted the adress for a ftp-site where one could have gotten a socket emulation library for TLI. I don't have that article anymore. Would somebody be so kind and point me in the right direction ? As i need this library for a test on monday i would really appreciate any answers before that time. Oh yes, could you please mail me the replies, i'll post a summary if there is any interest. Thanks, Marc Marc R. Sheldon e-mail : ms@Uni-Dortmund.DE University of Dortmund, CS-Department BITNET : ms@UNIDO.bitnet P.O.Box 500500 voice : +49 231 7552444 D-4600 Dortmund 50, (West)-Germany FAX : +49 231 7552386
-----------[000408][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 11:45:57 GMT From: mailrus!bbn.com!craig@tut.cis.ohio-state.edu (Craig Partridge) To: tcp-ip@nic.ddn.mil Subject: geography server
After mentioning the geography server I've gotten a number of queries
about it.
There's a section on it in the Internet Resource Guide, which can be
FTPed from nnsc.nsf.net. The Geographic Name Server is part of Chapter
M (for Miscellaneous), section 3, so ftp the file:
resource-guide/chapter.M/sectionM-3.ps
or
resource-guide/chapter.M/sectionM-3.txt
where ps and txt get you the postscript and ascii versions respectively.
Craig
-----------[000409][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 15:56:08 EDT From: root@popsrv.mail.cornell.edu (The Super-user) To: TCP-IP%NIC.DDN.MIL@ricevm1.rice.edu Subject: Re: IBM/HP-UX FTP session hangs on PORT command
q
-----------[000410][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 12:01:00 GMT From: KONDA@VM.CC.PURDUE.EDU To: comp.protocols.tcp-ip Subject: Please unsubscribe me from this list.
Thanks.
-----------[000411][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 12:23:11 GMT From: abvax!sgtech!adnan@tut.cis.ohio-state.edu (Adnan Yaqub) To: tcp-ip@nic.ddn.mil Subject: Where Have the On-line RFCs Gone?
I recently FTPed into nic.ddn.mil to grab an RFC only to find that there where none there to be had. This is the first time I have tried to get an RFC via FTP. Did I goof? Have they been removed? Have they moved? -- Adnan Yaqub (adnan@sgtech.uucp) Star Gate Technologies 29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
-----------[000412][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 12:26:40 GMT From: orc!bbn.com!mckenzie@decwrl.dec.com (Alex McKenzie) To: tcp-ip@nic.ddn.mil Subject: BBN/Slate(TM) Academic Institution Discount Plan
Bolt Beranek and Newman, Inc. is pleased to announce an Academic Institution Discount Plan for the BBN/Slate(TM) multimedia document communications system. The Plan is intended to foster the understanding of BBN/Slate within the academic community. For this purpose BBN is offering the software at a substantially reduced price of $100 per "active user" copy, to cover the cost of distribution. BBN/Slate software helps you create, edit, communicate, print and manage multimedia documents. A BBN/Slate document may contain a number of powerful media types, including: Text, Geometric Graphics, Color Images, Scanned Black & White Images, Voice, Spreadsheets, Business Charts and Enclosures. You may print and file these documents as well as use electronic mail and real-time document conferencing to share these documents with others. BBN/Slate currently runs on five different types of workstations: Sun 3, Sun 386i, Sun 4/SPARC under the SunView and X11 window systems, the IBM RISC System/6000 and the DEC VAXstation/Ultrix under the DECWindows window system. To find out more information about BBN/Slate and the Academic Institution Discount Plan either write to: BBN Software Products 10 Fawcett St. Cambridge, MA 02138 Attn: BBN/Slate Academic Discount Program or send electronic mail requests for information to: slate-academic@bbn.com Please include your name and return surface mail postal address in either type of request.
-----------[000413][next][prev][last][first]---------------------------------------------------- Date: Fri, 27 Jul 90 12:05:13 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: tcp-ip@nic.ddn.mil Subject: Re: tcpdump on 4.3 Reno?
>I don't yet have access to the 4.3 Reno distribution. Could someone >please tell me if the new tcpdump is available yet? btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno' naming scheme - is't simply placenames? thanks jon
-----------[000414][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 15:12:19 GMT From: gore!jacob@boulder.colorado.edu (Jacob Gore) To: tcp-ip@nic.ddn.mil Subject: Re: BBN/Slate(TM) Academic Institution Discount Plan
/ comp.protocols.tcp-ip / mckenzie@bbn.com (Alex McKenzie) / Jul 27, 1990 / > $100 per "active user" copy, to cover the cost of distribution. This really isn't any of my business, but I can't help but wonder what you guys use for distribution medium. Sounds like gold-particle magnetic tape :-) Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
-----------[000415][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 15:34:41 GMT From: usc!wuarchive!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!kline@ucsd.edu (Charley Kline) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Mills@udel.edu writes: >With all that horsepower you still struggle with WMO format? Zillions of >five-digit encoded obscurities? Surely a wee finite-state autonmaton such >as tinkered by one of my students can relieve that tension. Oh lord no. I meant I struggled with the various categorization of products by their WMO headers, some of which encapsulate an entire product, others signify a set of products to follow, each of which to be separated by ASCII RS characters, some have several products separated by "zone codes" which seem to differ in syntax depending on who is typing them in, and so on. The kinds of things I parse are the SA observations, which I tried writing a yacc grammar for but it was so full of ambiguities it wasn't funny. My student wrote a chunk of code to convert them into little data structures, which works fairly nicely. I also decode the Weather Watch announcements, which are fixed-format enough that a perl program can take a stab at pattern-matching them down to something useful. >Taking this >issue seriously, I personally eyeballed a PDP11/40 at Heathrow Airport >near London which tapped those digits from the weather wire and produced >a quite respectable English rendition suitable for automatic broadcast >by regions throughout the country. One of my radios has a feature that >announces its frequency in English. Strongly Japanese-accented English. I'm trying to talk management here into a DECtalk box. Although the geewhiz of talking computers has kind of lost its appeal these days; everyone wants to see, not hear. Another argument for the no-code license, I guess. Personal for Dave: What kind of radio is this? My latest acquisition is an Icom IC-24AT, which doesn't speak but has that strongly Japanese flavor nonetheless. For example in the manual. I love it for its size, but the damn puts out five watts on high power, which is enough to get the combination heat sink/belt clip hot enough to burn my hip. _____________________________________________________________________________ Charley Kline, KB9FFK/KT, PP-ASEL c-kline@uiuc.edu University of Illinois Computing Services (217) 333-3339
-----------[000416][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 23:21:18 PDT (Fri) From: romkey@asylum.sf.ca.us (John Romkey) To: Will@cup.portal.com Cc: tcp-ip@nic.ddn.mil Subject: re: Are Commercial TCPs Berkeley Code Or Custom?
FTP Software's code isn't based on Berkeley's. It's based on MIT's PC/IP, some of the primary authors of which (including me) founded FTP. Internally, it bears little resemblance to PC/IP these days, having been pretty heavily rewritten. As for porting the Berkeley code, I find that people who don't know it well take perhaps 4 months to bring up a port of it - it really wants to live inside a UNIX kernel. They still find that this is cheaper and faster than writing a TCP implementation from scratch. One of the reasons is that the Berkeley code is a *very* good protocol engine with a lot of time in the field. There are a lot of tricks to bringing up a TCP implementation from scratch, some of which are decoding the RFC's sufficiently well to get something "right", figuring out the stuff that's not in the RFC's (one of the reasons behind writing the Host Requirements RFC's, which represent "the wisdom of the ages"), and testing against the great many other TCP's out there. Now, yes, many of them are ports of the Berkeley code, but there have been several versions of the Berkeley code with varying levels of protocol compliance and bugginess, and many vendors manage to introduce their own bugs in their ports because they don't really have a deep understanding of what they're doing. A few years ago, it was possible to have two different people go and sit in different rooms and write TCP/IP implementations from scratch and not have them interoperate at all, or have them interoperate poorly and slowly. I believe this is largely still the case now - a TCP written in a vacuum isn't worth much. There are a lot of issues involved in getting this byte-oriented, sliding window protocol to work over network media spanning less than 300 bps to over 100Mbps from extremely noisy network links to perfect network transmission media, with a variety of latencies and having to interoperate in a world of many perhaps less than bug-free or well-tuned implementations. And then you want it to work well. The Berkeley code represents a lot of experience rolled into one piece of software. The edges that have to be glued into the system you roll it into are pretty rough; it's not really designed for that, but what you get is worth a lot, especially when real network wizards are expensive and hard to find (and many have better things to do than write "another" TCP implementation). Likewise, FTP Software has spent a lot of time getting that experience into its code. A lot of FTP's support time is dealing with *other* vendor's problems. A lot of development work has gone into making code that's bulletproof (or at least resistant) in the face of erratic behaviour on the part of its network peers. I think you'll find there are very few individual TCP's out there. The vast majority are ports of the Berkeley code. Before 4.2BSD, there was a 4.1 TCP from BB&N, which was rewritten (as I recall) into 4.2's code, and for a while 4.2 shipped with both until only Berkeley's was included. MIT's PC/IP was developed based on some code Dave Clark wrote while on sabbatical in England and brought back to MIT with him; this spawned a different line of UNIX TCP's, and a number of vendors implementations are based on PC/IP. Most of these vendors have probably put a lot of work into rewriting the TCP module, though, because the one MIT provided was inappropriate and inadequate for general purpose use. Phil Karn rolled his own in KA9Q (he'll correct me if I'm wrong). I believe the NCSA telenet TCP is probably independent, though I've never read the source code for it. Then there are TCP's for other operating systems, like MIT's ITS (on a PDP-10), the several varieties of Lisp Machines, Multics, and TOPS-20, all of which are independent strains. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com King Kong died for your sins.
-----------[000417][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 17:57:33 GMT From: portal!cup.portal.com!Will@apple.com (Will E Estes) To: tcp-ip@nic.ddn.mil Subject: Are Commercial TCPs Berkeley Code Or Custom?
Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, and FTP software written from scratch, or is the code basically just modified Berkeley code? Why is it so difficult to write a good TCP/IP? I am amazed that there are companies whose entire R&D seems to center around writing the TCP/IP protocol and supporting applications. Is it really that difficult? You would think that if you started with the Berkeley stuff it wouldn't be that difficult to improve it, or do legal restrictions prevent you from using the Berkeley stuff as a base? (You would think that it would be pretty easy to license the Berkeley code from the owner if it isn't public domain already....) Will Estes (sun!portal!cup.portal.com!Will)
-----------[000418][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 18:31:15 GMT From: swrinde!cs.utexas.edu!uwm.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Serious Routing Problems
In article <9007261125.aa13838@WOLF.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: > > From: Phil Dykstra <phil@BRL.MIL> > > For ha ha's check this out: > > traceroute to expo.lcs.mit.edu (18.30.0.212), 30 hops max, 40 byte packets > 1 ext328 (128.63.4.22) 21 ms 21 ms 26 ms > ... > 16 * MOSS.LCS.MIT.EDU (18.10.0.11) 344 ms 365 ms > > The MILNET throws it as far away as it possibly can, In defense of MILnet/NSFnet, it is extremely difficult to make East/West routing work well. This is not as bad as it seems in context. In other words, have a heart. :-) > NSFNET spends > four (nice orderly) hops getting it to Princeton, Well, at least that part is working great. Those Merit folk do a good job. > and then JVNC > spends 7(!) hops getting it to Boston. > There is some history behind all this. Might as well discuss this here, since tcp-ip seems to be the catchall network management list. :-) Where to begin? Way back when, NEARnet was but a gleam in the eye, but those of us involved in the early stages of NEARnet had confidence that it was the right thing to do. +50 members and a year and a half later, I'd say we were right. :-) But Internet access for this new network has been a tough nut and a chronic problem. Would that there had been a supercomputer center in Boston or that the backbone expansion could have been expedited. Spilt milk. We joined JvNCnet's Phase II backbone and have lived on that for about a year, during a time of explosive traffic growth. The traffic growth, criticality of the connection, and the large hopcount have resulted in less than ideal connectivity. I admit that this has gone on too long, but I cannot recount for you all the things that have been attempted and accomplished to remedy this situation. At least the traceroute terminated successfully. That is an improvement. While we anxiously await an NSS in Boston, we have discussed the matter most urgently with those in charge of JvNCnet and we have come up with some changes to improve our connectivity and reduce hopcount. You should see results from this redesign "soon". JvNCnet deserves our thanks for being a good neighbor and trying their best to deal with a difficult situation, during a period that has been difficult for them in dealing with their own changes. I think we have a plan that will work for the interim, but we can't really relax until the NEARnet NSS is up and running. And we don't know when that will be, but we are patient. :-) But you still expect to get X distributions from MIT, no matter what, eh? :-) I understand. --Kent
-----------[000419][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 18:33:51 GMT From: eplrx7!cristy@louie.udel.edu (John Cristy) To: tcp-ip@nic.ddn.mil Subject: ARCNET <=> TCP/IP on UNIX
Does anyone know about an ARCNET driver and card that can be attached to a UNIX system? ARCNET is one of the cards/drivers that Novell uses in their LANS. Untimately, I would like to attach an ARCNET LAN (IPX) to a LAN running ethernet (TCP/IP) and do the protocol conversion on the UNIX box. -- The UUCP Mailer
-----------[000420][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 18:41:00 GMT From: 0002544290@MCIMAIL.COM (Electronic Mail Association) To: comp.protocols.tcp-ip Subject: test
this is a test
-----------[000421][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 19:16:56 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Where Have the On-line RFCs Gone?
In article <40@sgtech.UUCP>, adnan@sgtech.uucp (Adnan Yaqub) writes: > I recently FTPed into nic.ddn.mil to grab an RFC only to find that > there where none there to be had. This is the first time I have tried > to get an RFC via FTP. Did I goof? Have they been removed? Have > they moved? Just looked and they are still there. ftp nic.ddn.mil login anonymous your-name cd rfc: ls R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000422][next][prev][last][first]---------------------------------------------------- Date: Sat 28 Jul 90 03:13:33-PDT From: William "Chops" Westfield <BILLW@mathom.cisco.com> To: portal!cup.portal.com!Will@apple.com Cc: tcp-ip@nic.ddn.mil Subject: Re: Are Commercial TCPs Berkeley Code Or Custom?
Are most of the commercial TCP/IPs sold by companies like Wollongong,
Excelan, and FTP software written from scratch, or is the code
basically just modified Berkeley code?
I would expect that most of the "large computer" commercial tcps are based
on some version of the Berkeley code. Most of the PC TCPs are probably
based on the MIT PC/IP code, although these have mutated more.
Why is it so difficult to write a good TCP/IP?
It's not. But it isn't easy either. Read the Host Requirements RFC
sometime. It's much easier to copy code from someone who has it almost
right than to start from scratch. I once made a bunch of improvemets to
the TCP for top20, but I reached the point where it would be easier to
port berkeley code than to start from scratch to implement some new
useful features. (Even though it would have meant figuring out a way
to integrate C into an all assembler OS. Fortunately, I got a different
job about then... :-)
I am amazed that there are companies whose entire R&D seems to center
around writing the TCP/IP protocol and supporting applications. Is it
really that difficult?
Well, entire companies have been know to support applications that DON'T
involve a network. It is clearly more difficult if there is a network too.
People want their applications (and their networks) without having to
understand anything about the underlying technology. Making the network
invisible is very hard. I wish more comercial companies put effort into
it. (There ought to be a mail system easier to install than sendmail...)
You would think that if you started with the Berkeley stuff it
wouldn't be that difficult to improve it, or do legal restrictions
prevent you from using the Berkeley stuff as a base?
Berkeley TCP/IP was (is?) developed under government contract, which makes
it pretty much available. The problem used to be the pieces of unix that
it contained. Of course, porting the code to a non-unix environment presents
opportunities for numerous bugs to creep in. And keeping up with the rate
of change the tcp code goes through is pretty tough too. And if you're
talking about improvements to the applications, you have to remember that
"improvement" is in the eye of the beholder...
BillW
-------
-----------[000423][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 20:23:46 GMT From: ibmsupt.uucp!bullhead!brunner@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: Marketing on tcp-ip (was Re: BBN/Slate(TM) ...)
In article <58504@bbn.BBN.COM> mckenzie@labs-n.bbn.com (Alex McKenzie) writes: > (announces BBN's marketing for a multimedia product, deleted) Alex, this posting _really is_ using the list and gatewayed newsgroup(s) for commercial purposes. Eric Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.
-----------[000424][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 22:01:03 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!lindh@ucsd.edu (Andrew Lindh) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <1990Jul25.090203.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes > ....... > putting out a device which gets it's Ethernet address from software. > > I don't have the Ethernet or 802.3 spec handy, but I believe that this is NOT > legal. And, even if it is, it's dangerous. It is critical that all Ethernet > devices have globally unique addresses. The hardware assignment of these > ainsures that there can NEVER be two the same.The portion of the spec allowing > software to reset this address is something I've always objected to, but it is > there. Every DEC computer uses a software address!!! If you want to run DECnet you have to change your address with software. I do not know if DEC computers also have a hardware address. In this environment it is very simple to have two computers with the same address...it drives our bridges crazy! -- Andrew Lindh, a student at the University of Hartford -- Computer Science INTERNET: lindh@uhasun.hartford.edu | NOTE: All views here are MINE!!! BITNET: lindh@hartford.bitnet | Not the school's or those of anyone else! UUCP: lindh@uhasun.uucp | ---- When will I graduate??? "SYNFU!"
-----------[000425][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 22:11:31 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: Are Commercial TCPs Berkeley Code Or Custom?
: Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, : and FTP software written from scratch, or is the code basically just modified : Berkeley code? WIN/TCP for VMS version 5.1 is based on BSD 4.3 Mutlinet (by TGV, sometimes sold by Excelan) is based on BSD 4.3 Tahoe Excelan? Don't know for sure. Fusion: They wrote their own, then ported it to VMS WIN/TCP for DOS version 4.1 is based on a very old version of IP/TCP written at MIT. Most of the original code is gone now, but the copyright notices remain. FTP software is also based on the MIT IP/TCP, but I don't know how much they have changed it. Based on what I've seen from them at trade shows and on the net, I would guess that this is quite alot. I also got the impression that is president had a great deal to do with the original IP/TCP implemetation. The large number of people that use BSD is a reflection of its unrestrictive licensing requirements. Warner -- Warner Losh imp@Solbourne.COM Boycott Lotus. #include <std/disclaimer>
-----------[000426][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 22:13:59 GMT From: maverick.ksu.ksu.edu!herkimer.cis.ksu.edu!harv@rutgers.edu (Harvard Townsend) To: tcp-ip@nic.ddn.mil Subject: Subnet/routing problems on SPARCstation
We are trying to implement a subnet in our department and are running into
problems. It seems like it should be so easy .... Our campus has a class B
network address, but no dept's have implemented any subnets with gateways up
to this point. We want to subnet a number of X terminals on thin enet using a
Sun SPARCstation 1 with two enet interfaces as a gateway. Interface le0
is conneceted to the dept. backbone -- 129.130.10 -- and le1 is the X
terminal subnet -- 129.130.11. Since there are no other subnets on campus,
all other systems just use 255.255.0.0 as the netmask. We can change all of
our systems (DEC, Harris, Sun, AT&T) to use 255.255.255.0, but have no
control over the other hosts on campus. Really, what we want is to have
all traffic for 129.130.11 to go through le1, and all OTHER traffic to go
out le0. We have not hit on the right way to take care of the route
tables, however.
We have assigned an IP address for each interface according to the net
they are connected to. When we bring the the gateway up in single user mode,`
without starting routed, the route table lists le0 as the gateway for
129.130.10 and le1 as the gateway for 129.130.11:
Routing tables
Destination Gateway ... Interface
localhost localhost ... lo0
129.130.10 orion le0
129.130.11 orion-x le1
At this point, with a netmask of 255.255.255.0, any other network is not
reachable. What we need now is to specify orion again (le0) as the gateway to
our campus net (ksunet -- 129.130) and then add the Proteon (campus gateway
to off-campus sites via Midnet) as the default gateway for all other nets.
Also, when we bring it up to multi-user mode, the above subnet destinations
are replaced by ksunet (129.130) and nothing can get to the X term subnet:
Routing tables
Destination Gateway ... Interface
localhost localhost ... lo0
129.130 orion le0
129.130 orion-x le1
Here's the diagram:
X term Dept. backbone -- 129.130.10
------ ================================ --> to campus net
| | | (129.130) and
| | | beyond
------ -----------
| | le0 |
| 129.130.11 subnet | | le0 == 129.130.10.83 (orion)
---------------------------| le1 | le1 == 129.130.11.1 (orion-x)
| | |
------- -----------
| | SPARCstation
| |
-------
X term
So, any ideas? Thanks in advance,
______________________________________
Harvard Townsend, Systems Manager
Dept. of Computing & Information Sciences
Kansas State University, Manhattan, KS 66506 (913)532-6350
Internet: harv@herkimer.cis.ksu.edu
UUCP: {rutgers, texbell}!ksuvax1!harv
AT&T Mail: attmail!htownsend
-----------[000427][next][prev][last][first]---------------------------------------------------- Date: Sat, 28 Jul 90 03:06:55 EDT From: oleary@noc.sura.net (dave o'leary) To: tcp-ip@nic.ddn.mil Subject: routing to net 26
Currently there is no mailbridge connection at FIX East, and therefore we do not inject routing information about Milnet networks into the NSFnet here. We are working with DCA and the staff at Mitre to bring back the connection to the Mitre Mailbridge as an interim solution. Further down the road (possibly September) there will be a mailbridge connected directly to the FIX East ethernet here in our machine room. This explains why packets to *any* host with Milnet-only connectivity will traverse the NSFnet backbone to the NSS in Palo Alto (BARRnet), where the Milnet routes are being advertised to the NSFnet. Even when the East Coast FIX node is peering directly with the NSS, the NSS here accepts a route to net 26 only as a secondary (at least this is my understanding of the situation). The East Coast mailbridge node will be primary for those nets in the Eastern US, and the West coast node primary for the networks in the Western US. However, net 26 is accepted as a primary advertisement at the BARRnet NSS, so as long as that peering is working, packets addressed to hosts on net 26 will go via the BARRnet NSS and Moffett Field Mailbridge, regardless of the geographic location of beginning and end points. The situation is explained in more detail in RFC1133. Thanks, dave o'leary SURAnet oleary@noc.sura.net (301)982-3214
-----------[000428][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 23:15:11 GMT From: brian@ucsd.edu (Brian Kantor) To: tcp-ip@nic.ddn.mil Subject: Re: tcpdump on 4.3 Reno?
In article <9007271758.AA13923@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno' >naming scheme - is't simply placenames? "Tahoe' was the model name of the CCI system that they had to port the 4.3 system to, which had previously been almost exclusively a Vax-based system. Because of hardware architectural differences, they had to make a bunch of changes so that it would run on the Tahoe, thus the name of the release. I'm told that the newer one is called 'Reno' because running it is taking a real gamble. Snicker. - Brian
-----------[000429][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 23:27:50 GMT From: pacbell.com!tandem!moe!kevinr@ucsd.edu (Kevin J. Rowett) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <65311@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: |> In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes: |> | address. We still allow the end user to change the current address, |> | but the software will never let him pick a globally assigned |> | style address. |> +--------------- |> as "the" host address, and then that value is written back into *all* of the |> network interfaces. |> |> Clearly, your software restriction would prevent this. Not really, as the customer can set ther MAC address to any locally admin'ed address they choose. kevinr@Tandem.com
-----------[000430][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 00:49:27 GMT From: van-bc!mplex!fff@ucbvax.Berkeley.EDU (Fred Fierling) To: tcp-ip@nic.ddn.mil Subject: SCO TCP/IP
We are running SCO Xenix 386 TCP/IP v1.0.1h (well, trying too!) and have noticed a little 4 byte packet prepended to every full size packet on our SLIP link. A datascope connected to the SLIP port shows this being transmitted (hex): c0 00 00 08 00 c0 45 00 00 2D ... The second packet (starts with "45") fully conforms to RFC 791, but what is that little runt doing there? -- Fred Fierling fff@eng.mplex.bc.ca Tel: 604 875-1461 Fax: 604 875-9029 Microplex Systems Ltd 265 East 1st Avenue Vancouver, BC V5T 1A7, Canada
-----------[000431][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 02:53:36 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) To: tcp-ip@nic.ddn.mil Subject: Re: How do you get a ENet Addr?
In article <1990Jul27.232750.22472@tandem.com> kevinr@Tandem.COM writes: +--------------- | In article <65311@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: | |> In article <1990Jul25.184017.192@tandem.com> kevinr@Tandem.COM writes: | |> | address. We still allow the end user to change the current address, | |> | but the software will never let him pick a globally assigned | |> | style address. | |> +--------------- | |> as "the" host address, and that value is written back into *all* of the | |> network interfaces. | |> Clearly, your software restriction would prevent this. | Not really, as the customer can set ther MAC address to any locally admin'ed | address they choose. +--------------- But that completely negates all of the advantages of the known-unique globally-administered addresses which come "for free" on each network interface! If you allow setting network physical addresses to any value [which, by the way, nearly all of the hardware interfaces do], no customer ever has to assign/hand_out/dis-ambiguate XNS addresses. All of the addresses on all of the network boards on all of the hosts in his internet are globally unique, and the "host addresses" that get used are merely a subset of the globally-unique numbers available on each host. [Single-interface hosts will default to the GU MAC address of their single interface, as usual.] In what you propose, all of a sudden the *customer* is responsible for not assigning any duplicate addresses ANYWHERE IN HIS/HER INTERNET, which may span half the world and, which is worse, many different administrative boundaries within the curtomer's own organization. To me, this is a *major* loss of convenience and reliability, simply because someone in your company decided that "customers [really, customer's network software] can't be trusted to do it right." PLEASE! We don't need any more "well-meaning" paternalism! -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
-----------[000432][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 04:18:01 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: first alpha release 7.x of packet drivers
Hi. The first alpha release 7.x of the Clarkson collection of PC packet drivers is now available. You can FTP it from sun.soe.clarkson.edu, in pub/ka9q, as alpha.arc (you can also fetch it by mail from archive-server). Please note that this is an alpha test release, and so should be kept far, far away from novice users. The two big improvements as of this release are delayed initialization (lets you continue booting from a Novell drive using the boot rom's driver), and Ethernet/802.3 conversion (lets you avoid econfiging your Novell server). We now have four new drivers, the Tiara LANCARD driver, a Localtalk driver, NTI 16-bit driver and a Ungermann-Bass PC/NIC driver. See readme.1st and read.me for more details... Please test these and report your experiences back to me, both good and bad. I'm pulling a Larry Wall -- I'm off on a week's vacation as of tomorrow. So, have lots of fun (I will!) and don't forget to mail me a report. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 In Communism's central planning, citizens are told "you will make widgets". In Capitalism's advertising, citizens are told "you will buy widgets".
-----------[000433][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 10:56:00 GMT From: bu.edu!transfer!crackers!cpoint!frog!msg!news@uunet.uu.net (Alex Brown) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
If you're dead serious about it, you might think about CMOT. -- Alex Brown uunet!msg!alex alex%msg.uucp@uunet.uu.net
-----------[000434][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 11:19:00 GMT From: bu.edu!transfer!crackers!cpoint!frog!msg!news@uunet.uu.net (Alex Brown) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Steven Bellovin writes: > Glenn P. Davis writes: > > You probably don't want to hear this, but there are a number of > > protocols and formats for weather info defined by the > > "World Meterological Organization" (WMO). > > I hope we don't have to use ASN.1 to encode them.... These codes were established for manual encoding of weather measurements reported by TTY; most of them are now IA5 (ASCII) strings. They aren't easy to generate because many of the measurements are conditions such as "partly cloudy" which are based on observer judgement. The FAA is developing a network of "Automated Weather Observation Systems" that establish uniform reporting algorithms. Although the WMO messages aren't record- oriented, other equivalent messages used internally in FAA systems are. Haven't had to describe them with ASN.1 yet, but the day may come, because the FAA is well underway in developing an ISO-stack real-time network for air traffic information, weather, and other aviation data. BTW, this NTP is an example of how useless a toy protocol for automated data collection can be. If we're really serious about automated status or ambient condition reporting, it should be done right, with Common Management Over TCP (CMOT) which should eventually line up with ISO Common Management Info Svc and Protocol (CMIS/CMIP). Sorry to have to say it here in the TCP lobby, but this is the sort of thing that made real-world users nervous looking at RFCs, leading to calls for the GOSIP mandates that many of you loathe. -- Alex Brown uunet!msg!alex alex%msg.uucp@uunet.uu.net
-----------[000435][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 14:27:41 GMT From: usc!wuarchive!rex!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!peiffer@ucsd.edu (Tim Peiffer (The Net Guy)) To: tcp-ip@nic.ddn.mil Subject: Re: Basic SLIP questions
In article <910@ncis.tis.llnl.gov> guerra@lance.tis.llnl.gov (Frank Guerra) writes: >The questions I have are this : > - Is this legal? Or is it more the case with a SLIP connection that it > requires it's own network in order to hang stuff other stuff off of the > connection? It's been suggested that a new network number would need This is legal. The answer is different depending upon what type of net you are running. From the net address 128.115.26.0, lll-labnet (128.115), you need only pick up a new *sub* network 128.115.27 ?? from your local net administrator. This is because your particular network is a class B net. If your particular lab is to be isolated to 128.115.26, you could experiment with a different subnet mask, say 255.255.255.127. If you chose this method, the 8th bit of the host address would determine whether you are on the slip network or not. Example: 128.115.26.10 local ethernet 128.115.26.137 Slip ethernet (127+10) >- What needs to be in the routing table for SLIP interface B (Machine B)? > It seems that it needs a default address to get out, but is there any more? As far as I can tell, you should have everything correct. > Machine C. Hence it seems, that nothing will ever reach, and hasn't yet > reached, either PC if it is being put on the ethernet instead. Correct. >- If another sub-net is required for the SLIP connection, how will the rest of > the rest of the network know about it? Will some other machine have to > create proxy ARPs for it, or is this taken care of by the SLIP daemon on the > SLIP host? As far as I can tell, this should be it. You could think of doing proxy arps as an alternate. Either method (subnet vs proxy arp) should work. Personally, I think the subnet mask is a much more efficient method of doing things. Tim Peiffer ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota MPLS MN 55455 -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
-----------[000436][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 17:25:18 GMT From: auspex!guy@uunet.uu.net (Guy Harris) To: tcp-ip@nic.ddn.mil Subject: Re: tcpdump on 4.3 Reno?
>"Tahoe' was the model name of the CCI system Code name, actually - CCI machines were code-named after lakes (except for one which was named after a pond).
-----------[000437][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 18:08:26 GMT From: swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu (Edward Vielmetti) To: tcp-ip@nic.ddn.mil Subject: Re: whois Database
In article <12609041797.18.AFDDN.JONSON@GUNTER-ADAM.AF.MIL> AFDDN.JONSON@GUNTER-ADAM.AF.MIL (Matt Jonson) writes: This posting from Germany brings up an interesting question: Has anyone else created whois databases? What machines? Any on unix platforms? #!/bin/sh whois -h iramu1.ira.uka.de $* # german dnet whois -h garcon.cso.uiuc.edu $* # illinois, ph/qi nameserver whois -h nic.ddn.mil $* # ddn nic, tops-20 whois -h sh.cs.net $* # csnet, csnet nameserver I'm sure there are more..
-----------[000438][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 20:18:11 GMT From: mcdchg!laidbak!stevea@rutgers.edu (Steve Alexander) To: tcp-ip@nic.ddn.mil Subject: Re: SCO TCP/IP
In article <5@mplex.UUCP> fff@mplex.UUCP (Fred Fierling) writes:
>We are running SCO Xenix 386 TCP/IP v1.0.1h (well, trying too!) and have
>noticed a little 4 byte packet prepended to every full size packet
>on our SLIP link.
SCO TCP/IP is derived from System V STREAMS TCP, which was originally
delivered to Lachman Associates (now a part of INTERACTIVE) by Convergent
Technologies in early 1987. The 4-byte "runt" is a SAP identifier packet
which was added by Convergent to support running non-IP protocols over the
SLIP frame encapsulation. It notifies the receiver that the next frame
is destined for the client bound to specified LSAP. This code has never
been used by Lachman for anything, but it survives in the SLIP driver to
this day. Obviously, it would only work between cooperating implementations.
I don't know if Convergent uses this for anything useful.
The 00 00 08 00 is 800 hex, which conveniently happens to be the Ethernet
packet type for IP. The idea was that network drivers would bind to SLIP
using the same SAP as they do for Ethernet.
I would expect that this "feature" will go away at some point, now that
we are committed to PPP.
Hope this clears up the mystery.
--
Steve Alexander, Software Technologies Group | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000439][next][prev][last][first]---------------------------------------------------- Date: 28 Jul 90 22:57:05 GMT From: news@psuvax1.cs.psu.edu (Scott Schwartz) To: tcp-ip@nic.ddn.mil Subject: Re: Are Commercial TCPs Berkeley Code Or Custom?
In article <12609238094.10.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: There ought to be a mail system easier to install than sendmail... There is. Rayan Zachariassen's Zmailer, even in alpha test, is easier to use and more reliable than sendmail.
-----------[000440][next][prev][last][first]---------------------------------------------------- Date: Sun, 29 Jul 90 11:12:42 -0400 From: Hans-Werner Braun <hwb@merit.edu> To: TCP-IP@nic.ddn.mil Subject: Re: Serious Routing Problems
Any packet injected into the NSFNET backbone and destined towards MILNET
is currently only going via the only remaining NSFNET/DDN connection
at NASA Ames (FIX-West). This is in result of the FIX-East move at the
east coast two weeks or so ago and the MILNET connectivity there has not
been restored yet. It should be restored soon, I hope. To my knowledge
the regional networks as well as other agencies were aware of this. You
should really talk to the people who are responsible for your network
connectivity. I only quickly scan TCP-IP mailing stuff and am only seeing
these things by chance. Talking to your direct network provider should yield
faster and reliable responses.
-- Hans-Werner
PS: To my knowledge, as soon as DCA signs off on their T1 link beween FIX-East
and the Mailbridge site we can activate the east coast NSFNET/DDN
connection again. DCA is very cooperative here and is also keeping
NSFNET staff well informed about the progress. Give it a few more days...
-----------[000441][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jul 90 3:39:51 EDT From: Phil Dykstra <phil@BRL.MIL> To: TCP-IP@nic.ddn.mil Subject: Re: Serious Routing Problems
My original note was sent to an internal list; I didn't expect to see it here. Nonetheless, it has led to some interesting discussion. To Sergio, note that no one used the term "loop". Mike called it a "problem" which I agree is debatable. JvNC did get the packets there, which one comes to appreciate when they are stuck behind a Buttergate. Thanks for the informative reply. I am somewhat aware of JvNCnet's design. Given the number of hops, I have to wonder how well the Cisco routing protocol is doing, but then I don't know the net topology. [Is an on-line map available? I would very much like to see one.] Thanks to Dave and Hans-Werner for the update on the FIX-East connection. It will be nice when that is back on line. And yes, every route I have traced through the NSFNET Backbone has taken a very logical route. The Merit folks are doing a good job. As of late last week up to now, the route from MOFFET-FLD to MIT has started going via FEBA-WEST over WIDEBAND to BBN to MIT - a few less hops. This is perhaps even better than a direct Princeton to NEARnet link, for the west coast, but that new link will be nice. From my perspective (the MILNET), the number one problem is with the Mailbridges (the "M" word). Routes still flop around, and when they do, you can get temporary net unreachables (which of course break connections). Some routes are hard to keep open for even ten minutes. We have had numerous complaints from our own users and people comming in from "outside". We used to complain about this periodically last Fall (to DCA or the folks at BBN), and while we grew tired of complaining, the problem remains. Looking forward to switching over to our ASNET connection to the world. - Phil
-----------[000442][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jul 90 13:40:30 -0500 From: John S. Quarterman <jsq@tic.com> To: TCP-IP@NIC.DDN.MIL Cc: jsq@tic.com Subject: Re: was: the BSD lpd protocol? Stevens' Book
> >There is an amazing book out there that I haven't seen mentioned on > >Usenet. It is, "UNIX NETWORK PROGRAMMING" by W. RICHARD STEVENS. It > >is published by PRENTICE HALL and its ISBN is 0-13-949876-1. At the > >$41 price I paid, this book is a terrific 772-page gold-mine of > >information. > >i second this - it is extremely complete, so far as a 1 hour scan could >tell, v. well written and excellent value See also the review in a recent issue of ConneXions. > - i wish there could be an equivalent text for kernel hackery for bsd, Leffler, Samuel J., McKusick, Marshall Kirk, Karels, Michael J., and Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1. > svid Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall, Englewood Cliffs, NJ, 1986. > and, say, mach. Rumor has it that such is in progress. > then lots of people could stop paying out megabucks to go on commercial >courses... Actually, the existence of such books tends to increase the number of people who take such courses. >the structure is very similar to a course i teach on comms. software, >and i think i'm gonna recommend it as a base text.... Case in point.... John -- John S. Quarterman Texas Internet Consulting jsq@tic.com tel: +1-512-320-9031 701 Brazos, Suite 500 uunet!longway!jsq fax: +1-512-320-5821 Austin, TX 78701
-----------[000443][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jul 90 09:38:14 EDT From: DBARTON@IBM.COM To: tcp-ip@nic.ddn.mil
Date: Monday, 30 Jul 1990 09:37:25 EST From: Daniel Barton <DBARTON@IBM.COM> To: <TCP-IP@NIC.DDN.MIL> Subject: Re: IBM/HP-UX FTP session hangs on PORT command TCP/IP Version 2 for VM will start allocating ports at port number 1024, to prevent this problem with the Hewlett Packard product. Ports 1000-1023 are not restricted, and I am surprised that Hewlett Packard does not have problems interoperating with other TCP/IP products than VM. A more graceful solution to the problem with the current VM code is to reserve ports 1000-1023 using the PORT statement in the PROFILE TCPIP configuration file. This will prevent TCPIP from allocating the ports, and prevent you from having to issue 24 errors to use up those ports. Daniel Barton (Internet: dbarton@ibm.com) TCP/IP Development (Bitnet: dbarton@yktvmv.bitnet) IBM Research Triangle Park, NC
-----------[000444][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 09:47:00 EDT From: "RANDY CATOE" <randy@TWG.COM> To: "qualcom!jwn2" <qualcom!jwn2@ucsd.edu> Cc: "tcp-ip" <tcp-ip@nic.ddn.mil> Subject: RE: WIN/TCP for VMS 5.3
Date sent: 30-JUL-1990 09:42:52
>From: ECOVAX::WINS%"<qualcom!jwn2@ucsd.edu>" 30-JUL-1990 09:33:42.03
>To: RANDY
>CC:
>Subj: WIN/TCP for VMS 5.3
>
>From: John Noerenberg <qualcom!jwn2@ucsd.edu>
>Subject: WIN/TCP for VMS 5.3
>Message-Id: <2843@qualcom.qualcomm.com>
>Sender: tcp-ip-relay@nic.ddn.mil
>To: tcp-ip@nic.ddn.mil
>
>Week before last, I asked for help with Wollongong's NTYDriver for VMS
>and with NCSA Telnet. Several offered advice and suggestions for which
>I'm very grateful.
>
>But, fool that I am, I'm pushing on from VMS 5.1-1 to 5.3-2...or rather
>I'd like to. I upgraded to 5.3-2 and tried to rebuild the Wollongong
>drivers. Unfortunately, it was a bust. Inetload tried to recalculate
>a new PTE offset. This appeared to succeed, but when trying to load
>INDRIVER in SYSGEN, the status value returned by f$getdvi didn't agree
>with expectations.
>
>Has anybody gotten WIN/TCP to run under VMS 5.3? Am I missing something
>obvious? (Like an upgrade for Wollongong?)
>
In order to install WIN/TCP after version 5.1-1b of VMS, WIN/TCP version
5.02 or later is required; in that release DECwindows began to use the
name "INDRIVER", which collided with the name of the WIN/TCP driver.
The latest version of WIN/TCP is 5.1, which works with VMS at least to
version 5.3.
Randy
................................................................................
. J.R. Catoe -- ---- ----
. The Wollongong Group, Inc. -- -- -- --
. 7799 Leesburg Pike -- -- -- --
. Suite 1100 North Tower -- -- ---- --
. Falls Church VA 22043 -- -- -- -- --
-- -- -- ----
................................................................................
-----------[000445][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 08:49:48 GMT From: qualcom!jwn2@ucsd.edu (John Noerenberg) To: tcp-ip@nic.ddn.mil Subject: WIN/TCP for VMS 5.3
Week before last, I asked for help with Wollongong's NTYDriver for VMS and with NCSA Telnet. Several offered advice and suggestions for which I'm very grateful. But, fool that I am, I'm pushing on from VMS 5.1-1 to 5.3-2...or rather I'd like to. I upgraded to 5.3-2 and tried to rebuild the Wollongong drivers. Unfortunately, it was a bust. Inetload tried to recalculate a new PTE offset. This appeared to succeed, but when trying to load INDRIVER in SYSGEN, the status value returned by f$getdvi didn't agree with expectations. Has anybody gotten WIN/TCP to run under VMS 5.3? Am I missing something obvious? (Like an upgrade for Wollongong?) Thanks for your advice and sympathy! jwn2
-----------[000446][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jul 90 16:19 EST From: Electronic Mail Association <0002544290@mcimail.com> To: "tcp-ip@nic.ddn.mil" <tcp-ip@nic.ddn.mil> Subject: ELECTRONIC MESSAGING '90
Marshall Rose suggested I send this to you for posting to all users.
I hope this is of general interest to the group. Thank you!
* * * * * * *
ELECTRONIC MESSAGING '90:
BEYOND INTERPERSONAL CORRESPONDENCE
WHEN: October 22-24, 1990
WHERE: The Fairmont Hotel, San Francisco, Ca.
SPONSORED BY: The Electronic Mail Association
The Electronic Mail Association's annual conference expands to three days
for 1990. An exciting program that includes more than twice as many
speakers as ever before will examine such diverse topics as:
o Corporate Messaging Strategies
o End-User Training
o Messaging Integration With EDI & FAX
o X.500 Directories
o CCITT Update
o LAN User Issues
o Gateways & Connectivity
o Groupware
o Portable Messaging
o Global Trends
John A. Young, President & Chief Executive Officer of Hewlett-Packard,
will deliver the keynote address.
Special new features at "Electronic Messaging '90: Beyond Interpersonal
Correspondence" include a focused user/vendor discussion of upcoming
industry trends, led by EMA chairman Rich Miller, and a Sunday night
pre-conference user-to-user briefing on messaging terminology
for those new to the industry.
*** CONFERENCE SPEAKERS ***
Below is a partial list of confirmed speakers for Electronic Messaging '90:
John A. Young, President & CEO, Hewlett-Packard
Hellene S. Runtagh, President, GE Information Services
Jose A. Collazo, Chairman & President, Infonet
Richard H. Miller, President, Rapport Communication, Inc. & Chairman, EMA
Peter W. Donaghy, Customer Service & Support Manager, Hughes Aircraft Co.
Michael D. Zisman, President, Soft Switch, Inc.
Donald M. Gilbert, Information Services Director, American Petroleum Institute
Kenneth Hutcheson, EDI Director, E.I. DuPont de Nemours & Chairman, X12
Richard Norris, Practice Leader for Logistics, Arthur D. Little, Inc.
Jeanne P. Bracken, Message Handling Systems Director, Pacific Bell
Donald Ryan, Vice President of ICS, BIS CAP International
Robert Johansen, Senior Research Fellow, Institute for the Future
Gursharan Sidhu, Technical Director, Apple Computer, Inc.
*** SCHEDULE OF EVENTS ***
MONDAY, OCTOBER 22
Plenary Panel Sessions:
Industry Trends & Perspectives
Business Case for Corporate Messaging Strategies
Luncheon
EDI & Messaging Integration Trends
User Perspectives on Messaging Trends
TUESDAY, OCTOBER 23
Keynote Address by John A. Young
Concurrent Panel Sessions:
Marketing Electronic Mail Inside the Corporation
Directories
End-User Training & Support
CCITT Update
Luncheon
Concurrent Panel Sessions:
IBM Messaging Update
Integration & Applied Messaging
Groupware
DEC Messaging Update
Integrating Information Services & Messaging
Portable Messaging
WEDNESDAY, OCTOBER 24
Concurrent Panel Sessions:
LAN Messaging Trends
Privacy & Security
Gateways & Connectivity
LAN User Issues
Legal Issues in Messaging & EDI
Global Trends
Policy & Regulatory Issues
User/Vendor Industry Discussion
Adjourn
1 p.m.
*** REGISTRATION INFORMATION ***
Conference Fees
Regular Conference Fee
$695 (If received by 8/31 ... $645)
Special EMA Member Fee
$495 (If received by 8/31 ... $445)
Pre-registration is required.
The special member fee applies to all employees of member organizations
attending Electronic Messaging '90, so your membership may pay for itself
through the conference fee discounts. Contact the association for more
information about joining EMA.
Early Bird Discount
Registrants who pay the conference fee in full by August 31 may deduct
$50 from the conference fee.
Cancellations
All cancellations will be subject to a $50 processing fee. The balance of the
conference fee will be refunded provided written notice of cancellation is
received by EMA no later than October 15.
Hotel Accommodations
Electronic Messaging '90 will be held at The Fairmont Hotel, San Francisco, Ca.
Rooms are available at the special conference rate of $135 single/$155 double
(Main Bldg. Interior), $155 single/$180 double (Main Bldg. Exterior),
$205 single/$225 double (Tower City View), $245 single/$265 double
(Tower Bay View). Register with the hotel directly at 415/772-5000 before
September 21, 1990 to guarantee the above rates and availability. Please note
that you are with the Electronic Mail Association room block.
Airline Reservations
American Airlines is the official airline for Electronic Messaging '90. For the
convention rate, please contact (or have your travel agent contact) the
American Airlines convention desk at 1-800-433-1750 and ask for star
file number S04O04E.
TO REGISTER OR TO RECEIVE FURTHER INFORMATION
Electronic mail is the easiest way to register! Please message, fax or mail
registration information to EMA at the address below. Information should
include:
Name (Full, Middle Initial, Last)
Title
Company
Address
City, State, Zip
Telephone Number
Fax Number
Electronic Mail Address
Method of Conference Fee Payment (Member or Nonmember)
Electronic Mail Association
1555 Wilson Boulevard
Suite 555
Arlington, VA 22209-2405
Tel: 703/522-7111
Fax: 703/528-4251
AT&T Mail: !EMA
CompuServe: 70007,2377
Dialcom: 63:PRD003
EasyLink: 62886257
Envoy 100: EMA
GEnie: EMA
INET: ema.association
MCI Mail: EMA/2544290
SprintMail: [ema/associates]
mail/usa
FOR A COMPLETE LIST OF SPEAKERS, CONTACT EMA ELECTRONICALLY.
* * * * *
Please let me know if there will be any problem posting this. Thanks again!
Amy Louviere
Director, Marketing
EMA
.
-----------[000447][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 12:42:10 GMT From: mcsun!hp4nl!charon!piet@uunet.uu.net (Piet Beertema) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
If sucessfully implemented, such a protocol would also contribute
towards reducing Global Warming.
Wonder if it would help reducing temperature in more
exotic places too, like those mentioned below:
============================================================================
Some consolation
----------------
I wish to clear up the old question: "Which is hotter, heaven or hell?"
Verse 26 of Chapter 30 of Isaiah defines the energy radiated heavenward
by the sun and the moon in terms of the amount received by the earth:
"Moreover the light from the moon shall be sevenfold, as the light from
seven days". Thus, heaven receives from the moon as much energy as the
earth does from the sun. If we add to that 49 times ("seven times seven")
the earth's solar radiation falling on heaven, we have a total of 50 times
the energy we receive from the sun. Using a known absolute temperature
of the earth and the Stefan-Boltzmann fourth-power law, we arrive at the
determined temperature of heaven: a less than paradisiacal 525 degrC.
And the temperature of hell?
Revelation 21:8 says: "The fearful shall have part in the lake which burns
of fire and brimstone". Since brimstone (sulfur) has a boiling point of
445 degrC, hell must be several degrees cooler. If it were not, it would
be a vapor, not a lake.
Therefore, heaven is hotter than hell by at least 80 degrC.
============================================================================
(Actually this story is a couple of years old already;
can't remember where I ever got it from).
--
Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
-----------[000448][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 13:38:14 GMT From: DBARTON@IBM.COM To: comp.protocols.tcp-ip Subject: (none)
Date: Monday, 30 Jul 1990 09:37:25 EST From: Daniel Barton <DBARTON@IBM.COM> To: <TCP-IP@NIC.DDN.MIL> Subject: Re: IBM/HP-UX FTP session hangs on PORT command TCP/IP Version 2 for VM will start allocating ports at port number 1024, to prevent this problem with the Hewlett Packard product. Ports 1000-1023 are not restricted, and I am surprised that Hewlett Packard does not have problems interoperating with other TCP/IP products than VM. A more graceful solution to the problem with the current VM code is to reserve ports 1000-1023 using the PORT statement in the PROFILE TCPIP configuration file. This will prevent TCPIP from allocating the ports, and prevent you from having to issue 24 errors to use up those ports. Daniel Barton (Internet: dbarton@ibm.com) TCP/IP Development (Bitnet: dbarton@yktvmv.bitnet) IBM Research Triangle Park, NC
-----------[000449][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 14:46:37 GMT From: dino!hascall@uunet.uu.net (John Hascall) To: tcp-ip@nic.ddn.mil Subject: Re: Are Commercial TCPs Berkeley Code Or Custom?
In article <32140@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: }Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, }and FTP software written from scratch, or is the code basically just modified }Berkeley code? Why is it so difficult to write a good TCP/IP? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Try it sometime!! It has taken me over a year of evenings (as many as my wife will stand for :-) to put together a good solid ARP,IP,ICMP,UDP,TCP,DNS under VAX/VMS (working entirely in assembly doesn't help!). And that still leaves all the "user" stuff (Telnet, FTP, etc...). [And since the arrival of 300+ DECstations, VAXes look to be dead here soon, sigh.] A big part of the difficulty is all those RFCs -- if you have a working implementation and a new "good thing" comes out, it is usually not that hard to add it (unless of course your code looks nothing at all like BSD's :-( but to try to get all of those things working while more are being thought-up every day is rather a losing battle. By my estimation, most (at least half) of the difficulty is in TCP. The other half was reverse-engineering DEC's "backdoor" into the ethernet driver. Leaving the rest as the third half. John Hascall / john@iastate.edu / hascall@atanasoff.cs.iastate.edu
-----------[000450][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 14:47:29 GMT From: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bcarh342!mleech@ucsd.edu (Marcus Leech) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
In article <9007251236.aa03466@huey.udel.edu>, Mills@udel.edu writes: > > globe. While this station has since shut down, Halifax Radio CHU > presently broadcasts 75-baud radioteletype messages (along with CHU is a station operated by our National Research Council to propagate time-of-day information, and NOTHING ELSE. It's also located in Ottawa, Ontario--not Halifax, Nova Scotia. Canada does operate a number of shortwave services--you probably just got the callsign wrong, Dave. There could, of course, be another CHU that I'm unaware of, but having two stations with the same callsign and completely different purposes would be too strange... ----------------- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs
-----------[000451][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 16:01:16 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!masscomp!simon@ucsd.edu (Simon Rosenthal) To: tcp-ip@nic.ddn.mil Subject: Availability of SNMP MIB for X.25
Hi: Can anyone out there point me to a SNMP MIB for an X.25 interface, if such a creature exists. Thanks in advance .. - Simon _______________________________________________________________________________ Simon Rosenthal: ___________ Concurrent Computer Corporation / _________/_ Westford, MA 01886 /_/________/ / Internet: simon@westford.ccur.com
-----------[000452][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 16:40:55 GMT From: mcsun!ukc!tcdcs!swift.cs.tcd.ie!ul.ie!bourkej@uunet.uu.net (John Bourke) To: tcp-ip@nic.ddn.mil Subject: Spare some advice for an old ex-lepper
Hi, We are trying to come to grips with the TCP/IP protocols before people come screaming to us looking for services and advice. At the moment we have CMU on the Vax and PC's running 3COM TCP/IP. We have no UNIX hosts, no subnets, no gateways, no connection to the internet; no nothing. Can anyone offer some words of wisdom from their expereinces, or, if you were to start from scratch, what would you do different ? John Bourke O-O <bourkej@ul.ie> | Information Technology Department, # _ # University Of Limerick, Ireland. ###
-----------[000453][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 17:29:52 GMT From: artemis.ll.mit.edu!olsen@XN.LL.MIT.EDU (Jim Olsen) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
>>In article <9007251236.aa03466@huey.udel.edu>, Mills@udel.edu writes: >> Halifax Radio CHU presently broadcasts 75-baud radioteletype messages... Marcus Leech writes: > CHU is a station operated by our National Research Council to propagate > time-of-day information, and NOTHING ELSE. The Canadian Forces Halifax station is CFH. It does indeed broadcast radioteletype and facsimile weather reports and forecasts on a number of HF frequencies. For those interested, I have appended some frequency information and a FAX schedule (perhaps out of date). At least here in New England, the CFH signals are quite strong and easily received. ------ CFH Radioteletype frequencies (some part-time): 75-baud radioteletype, 850-Hz shift: 4271, 6330, 6338, & 10536 kHz FEC radioteletype: 13351 kHz ------ Forwarded from rec.radio.shortwave: From: roskos@IDA.ORG (Eric Roskos) Subject: New CFH Fax Schedule Date: 29 Jan 90 00:50:20 GMT Organization: IDA, Alexandria, VA A few mornings ago I happened to be up at 5AM when CFH sends its Fax schedule, and thus recorded the current schedule. According to a note at the bottom, this is a new schedule as of 1/15/90, so here is the current schedule. (This was sent via Fax and is hand-transcribed below, so any errors are probably mine.) Note that while some of these charts are local to Nova Scotia in their coverage, others, such as the surface analysis, cover the entire east coast of the US. The Surface Analysis is the old-fashioned hand-drawn kind with the graphical symbols, rather than the digitally-produced NOAA kind with the nearly (if not entirely) illegible small numbers -- it's especially good if you're using a PK232 or other low-resolution device, since the large lines and lettering make it easy to read by comparsion to the NOAA charts. Canadian Forces Metoc Centre Halifax FMO Halifax, Nova Scotia B3K 2X0 Canada CFH Facsimile Broadcast Schedule Transmitting On LF: 122.5 KHz / HF: 4.271-6.330-10.536-13.510 MHz No. Trans Time Chart Description Valid Time ================================================================ WHF01 0001-0014Z Significant Weather Depiction 1200Z ----- 0015-0037Z Ice Chart Latest CFH01 0101-0114Z 850 MB Forecast Wind/Temp/Height 18Z/00Z CFH04 0301-0312Z 500 MB Analysis 0000Z CFH03 0312-0331Z Surface Analysis North 0000Z CFH03 0331-0338Z Surface Analysis South 0000Z WHF02 0401-0414Z Wave Analysis 0000Z WHF03 0414-0427Z 12 Hr Significant Wave Prognosis 1200Z CFH02 0427-0438Z 850 MB Analysis 0000Z CFH05 0501-0514Z 24 Hr Isobaric Prognosis 0000Z WHF04 0514-0527Z 24 Hr Significant Wave Prognosis 0000Z WHF05 0601-0614Z Significant Weather Depiction 1800Z WHF06 0614-0627Z 36 HR Significant Wave Prognosis 1200Z CFH06 0701-0714Z 850 MB Forecast Wind/Temp/Height 18Z/00Z CFH07 0801-0814Z 36HR Isobaric Prognosis 1200Z CFH08 0814-0833Z NFLD SST -Wed-Sat- (NS OFA -Tue-) Latest NS SST -Sun-Thu- (NFLD OFA -Mon-Fri-) CFH09 0901-0920Z Surface Analysis North 0600Z CFH09 0920-0927Z Surface Analysis South 0600Z CFH07 1000-1014Z 36 Hr Isobaric Prognosis (Repeat) 1200Z ----- 1014-1026Z CFH Test Chart -Tue-Thu-Sat- ----- ----- 1014-1026Z CFH Fleet Broadcast Schedule ----- ----- 1101-1123Z Ice Chart Latest WHF08 1201-1214Z Significant Weather Depiction 0000Z ----- 1301-1323Z Ice Chart Latest ----- 1401-1423Z Ice Chart Latest CFH10 1423-1438Z 850 MB Forecast Wind/Temp/Height 06Z/12Z CFH14 1501-1512Z 500 MB Analysis 1200Z CFH13 1512-1531Z Surface Analysis North 1200Z CFH13 1531-1536Z Surface Analysis South 1200Z WHF09 1601-1614Z Wave Analysis 1200Z WHF10 1614-1627Z 12 Hr Significant Wave Prognosis 0000Z CFH11 1627-1638Z 850 MB Analysis 1200Z CFH15 1701-1714Z 24 Hr Isobaric Prognosis 1200Z WHF11 1714-1727Z 24 Hr Significant Wave Prognosis 1200Z WHF13 1801-1814Z Significant Weather Depiction 0600Z WHF12 1814-1827Z 36 Hr Significant Wave Prognosis 0000Z CFH16 1901-1914Z 36 Hr Isobaric Prognosis 0000Z CFH17 2000-2014Z 850 MB Forecast Wind/Temp/Height 06Z/12Z WHF14 2014-2033Z NS SST (NFLD SST -Mon-Wed-Sat-) Latest WHF14 2101-2120Z NS OFA (NFLD OFA -Mon-Wed-Sat-) Latest CFH18 2120-2139Z Surface Analysis North 1800Z CFH18 2139-2146Z Surface Analysis South 1800Z ----- 2201-2223Z Ice Chart Latest ----- 2301-2323Z Ice Chart Latest -- Eric Roskos (roskos@IDA.ORG or Roskos@DOCKMASTER.NCSC.MIL)
-----------[000454][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 17:47:32 GMT From: usc!zaphod.mps.ohio-state.edu!mips!ultra!rajiv@ucsd.edu (Rajiv Dhingra) To: tcp-ip@nic.ddn.mil Subject: ARP hardware address space values
Can someone tell me who assigns values for the field 'hardware address space' which is present in ARP packets. I am interested in getting a couple of values assigned for us, Ultra. Thanks, Rajiv Dhingra Ultra Network Technologies domain: rajiv@Ultra.COM 101 Daggett Drive Internet: ultra!rajiv@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!rajiv 408-922-0100
-----------[000455][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 18:08:00 GMT From: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu (Henry Spencer) To: tcp-ip@nic.ddn.mil Subject: Re: BBN/Slate(TM) Academic Institution Discount Plan
In article <670007@gore.com> jacob@gore.com (Jacob Gore) writes: >> $100 per "active user" copy, to cover the cost of distribution. > >This really isn't any of my business, but I can't help but wonder what you >guys use for distribution medium... The cost of distribution is mostly people time, not media cost. Only if you have actually done distribution (I have) do you have any idea how much time and frustration is involved. -- The 486 is to a modern CPU as a Jules | Henry Spencer at U of Toronto Zoology Verne reprint is to a modern SF novel. | henry@zoo.toronto.edu utzoo!henry
-----------[000456][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 18:50:50 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Serious Routing Problems
In article <9007300339.aa00505@SPARK.BRL.MIL>, phil@BRL.MIL (Phil Dykstra) writes: > ... Given the number of hops, I have to wonder how well the Cisco > routing protocol is doing, but then I don't know the net topology. Not too well in my opinion. Chuck Hedrick from Rutgers posted some very informative material in comp.dcom.sys.cisco about setting timers in IGRP to speed convergence. The timers are now settable in cisco configs. When lines flap for whatever reason, routes in IGRP go away and get held down for many minutes, breaking TCP connections. While caution must be used, in many cases, shortening up the IGRP reaction times will prevent line flaps from turning into big route lossage. It all depends on how you have your net set up. In my opinion, this will become a thing of the past with link state protocols. I'm anxious to see results from the OSPF early deployments in NASA and SURAnet. Milo, Dave; How does OPSF do when you have routes flapping? Instant convergence? --Kent
-----------[000457][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 18:52:31 GMT From: wotk!root@uunet.uu.net (Superuser) To: tcp-ip@nic.ddn.mil Subject: Internet Access
Can someone tell me how my company can get connected to the Internet? Is it even possible? I need details. Thanks. Nick Hennenfent Voice 404 475-2725 Computone Products FAX 404 343-9735 1100 Northmeadow Parkway Usenet ...!uunet!wotk!nickh Suite 150 Roswell, GA 30076
-----------[000458][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 20:31:06 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: WIN/TCP 5.1 error...
In article <28900@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes:
>I am getting a mystifying error (mystifying because there's nothing in
>the docs about it) from WIN/TCP on my uVAX II.
>
>%LPDSMB-F-FILEREAD,
>
>What is happening? What should I check?
Decoding the message identifier according to normal rules says that
a component called LPDSMB (probably a print symbiont which is a client
for the Berkeley Line Printer Daemon; i.e. talking to a remote print
queue over the network) had a FILEREAD error.
Sounds to me like
(1) You have a print queue connected to a printer on another system
(2) A file was submitted to this print spooler, and probably deleted
while it was sitting in the queue (was the print server down for
quite a while ?)
I would expect that you are getting this message on the console.
Does it say which file it had trouble reading ?
Is the file really gone ?
Does it say what kind of error it got when trying to read it ?
--
/ Lars Poulsen, SMTS Software Engineer
CMC Rockwell lars@CMC.COM
-----------[000459][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 21:19:00 GMT From: 0002544290@MCIMAIL.COM (Electronic Mail Association) To: comp.protocols.tcp-ip Subject: ELECTRONIC MESSAGING '90
Marshall Rose suggested I send this to you for posting to all users.
I hope this is of general interest to the group. Thank you!
* * * * * * *
ELECTRONIC MESSAGING '90:
BEYOND INTERPERSONAL CORRESPONDENCE
WHEN: October 22-24, 1990
WHERE: The Fairmont Hotel, San Francisco, Ca.
SPONSORED BY: The Electronic Mail Association
The Electronic Mail Association's annual conference expands to three days
for 1990. An exciting program that includes more than twice as many
speakers as ever before will examine such diverse topics as:
o Corporate Messaging Strategies
o End-User Training
o Messaging Integration With EDI & FAX
o X.500 Directories
o CCITT Update
o LAN User Issues
o Gateways & Connectivity
o Groupware
o Portable Messaging
o Global Trends
John A. Young, President & Chief Executive Officer of Hewlett-Packard,
will deliver the keynote address.
Special new features at "Electronic Messaging '90: Beyond Interpersonal
Correspondence" include a focused user/vendor discussion of upcoming
industry trends, led by EMA chairman Rich Miller, and a Sunday night
pre-conference user-to-user briefing on messaging terminology
for those new to the industry.
*** CONFERENCE SPEAKERS ***
Below is a partial list of confirmed speakers for Electronic Messaging '90:
John A. Young, President & CEO, Hewlett-Packard
Hellene S. Runtagh, President, GE Information Services
Jose A. Collazo, Chairman & President, Infonet
Richard H. Miller, President, Rapport Communication, Inc. & Chairman, EMA
Peter W. Donaghy, Customer Service & Support Manager, Hughes Aircraft Co.
Michael D. Zisman, President, Soft Switch, Inc.
Donald M. Gilbert, Information Services Director, American Petroleum Institute
Kenneth Hutcheson, EDI Director, E.I. DuPont de Nemours & Chairman, X12
Richard Norris, Practice Leader for Logistics, Arthur D. Little, Inc.
Jeanne P. Bracken, Message Handling Systems Director, Pacific Bell
Donald Ryan, Vice President of ICS, BIS CAP International
Robert Johansen, Senior Research Fellow, Institute for the Future
Gursharan Sidhu, Technical Director, Apple Computer, Inc.
*** SCHEDULE OF EVENTS ***
MONDAY, OCTOBER 22
Plenary Panel Sessions:
Industry Trends & Perspectives
Business Case for Corporate Messaging Strategies
Luncheon
EDI & Messaging Integration Trends
User Perspectives on Messaging Trends
TUESDAY, OCTOBER 23
Keynote Address by John A. Young
Concurrent Panel Sessions:
Marketing Electronic Mail Inside the Corporation
Directories
End-User Training & Support
CCITT Update
Luncheon
Concurrent Panel Sessions:
IBM Messaging Update
Integration & Applied Messaging
Groupware
DEC Messaging Update
Integrating Information Services & Messaging
Portable Messaging
WEDNESDAY, OCTOBER 24
Concurrent Panel Sessions:
LAN Messaging Trends
Privacy & Security
Gateways & Connectivity
LAN User Issues
Legal Issues in Messaging & EDI
Global Trends
Policy & Regulatory Issues
User/Vendor Industry Discussion
Adjourn
1 p.m.
*** REGISTRATION INFORMATION ***
Conference Fees
Regular Conference Fee
$695 (If received by 8/31 ... $645)
Special EMA Member Fee
$495 (If received by 8/31 ... $445)
Pre-registration is required.
The special member fee applies to all employees of member organizations
attending Electronic Messaging '90, so your membership may pay for itself
through the conference fee discounts. Contact the association for more
information about joining EMA.
Early Bird Discount
Registrants who pay the conference fee in full by August 31 may deduct
$50 from the conference fee.
Cancellations
All cancellations will be subject to a $50 processing fee. The balance of the
conference fee will be refunded provided written notice of cancellation is
received by EMA no later than October 15.
Hotel Accommodations
Electronic Messaging '90 will be held at The Fairmont Hotel, San Francisco, Ca.
Rooms are available at the special conference rate of $135 single/$155 double
(Main Bldg. Interior), $155 single/$180 double (Main Bldg. Exterior),
$205 single/$225 double (Tower City View), $245 single/$265 double
(Tower Bay View). Register with the hotel directly at 415/772-5000 before
September 21, 1990 to guarantee the above rates and availability. Please note
that you are with the Electronic Mail Association room block.
Airline Reservations
American Airlines is the official airline for Electronic Messaging '90. For the
convention rate, please contact (or have your travel agent contact) the
American Airlines convention desk at 1-800-433-1750 and ask for star
file number S04O04E.
TO REGISTER OR TO RECEIVE FURTHER INFORMATION
Electronic mail is the easiest way to register! Please message, fax or mail
registration information to EMA at the address below. Information should
include:
Name (Full, Middle Initial, Last)
Title
Company
Address
City, State, Zip
Telephone Number
Fax Number
Electronic Mail Address
Method of Conference Fee Payment (Member or Nonmember)
Electronic Mail Association
1555 Wilson Boulevard
Suite 555
Arlington, VA 22209-2405
Tel: 703/522-7111
Fax: 703/528-4251
AT&T Mail: !EMA
CompuServe: 70007,2377
Dialcom: 63:PRD003
EasyLink: 62886257
Envoy 100: EMA
GEnie: EMA
INET: ema.association
MCI Mail: EMA/2544290
SprintMail: [ema/associates]
mail/usa
FOR A COMPLETE LIST OF SPEAKERS, CONTACT EMA ELECTRONICALLY.
* * * * *
Please let me know if there will be any problem posting this. Thanks again!
Amy Louviere
Director, Marketing
EMA
.
-----------[000460][next][prev][last][first]---------------------------------------------------- Date: 30 Jul 90 22:20:33 GMT From: shelby!portia.stanford.edu!ack.Stanford.EDU!pst@decwrl.dec.com (Paul Traina) To: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Gee, in our part of California, making the server would be pretty trivial: #!/bin/sh # set `date` case $2 in Apr|May|Jun|Jul|Aug|Sep|Oct) echo "The weather today is really nice." echo "Take the day off from work and go to the beach or" echo "go for a bike ride." ;; Mar) echo "The weather is ok today, but it will probably rain." echo "Go home early so you don't get caught in an afternoon" echo "shower." ;; Dec|Jan|Feb) echo "It's cloudy today and really cold. Don't expect" echo "temperatures to get above 70." ;; Nov) echo "It's ok today, but a little too cold for the beach." ;; esac -- I told the priest - don't count on any second coming. God got his ass kicked the first time he came down here slumming. He had the balls to come, the gall to die and then forgive us - No, I don't wonder what he thought it would get us. -- Prieboy
-----------[000461][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 11:33:13 -0700 From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.arc.nasa.gov> To: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) Cc: tcp-ip@nic.ddn.mil Subject: Re: Serious Routing Problems
Kent, I'm a little confused here. Line flapping should be fixed by having hystersis in the up/down line protocol. It's been our experience that OSPF in our system reroutes completely after about 3 seconds on average after the dead link is detected. OSPF has it's timers set up in a way as to avoid link flap causing a lot of simultaneous LSP flooding, due to deliberate jitter in the timers (LSP's being flooded from all the gateways connected to a down net). As for link up/downs going on every few seconds, we haven't had experience with that sort of situation, but in the case of a link that flaps every couple of minutes, that seems to work fine. Because link-state protocols flood the topology information, and then the routers recompute the routing tables more or less in parallel, convergence can happen very quickly, and you also can do without the complicated holddowns and such needed to prevent route looping in vector-distance protocols. This should be true for any reasonably well implemented link-state protocol. It's just easy to do this part right. You can certainly screw up in other ways, but if you want fast convergance, fast enough to avoid lining up hundreds of user TCP connections against a wall and killing them in rapid sucession, you really need to use a link-state protocol. This is one reason why noone has bothered to build a new vector distance IGP in quite some time. Even the new proprietary IGP's these days are link-state based... BARRNET also runs OSPF now, and those guys can tell you more about how it's performance has been. Thanks, Milo
-----------[000462][next][prev][last][first]---------------------------------------------------- Date: Mon, 30 Jul 90 23:55:51 GMT From: Mills@udel.edu To: Marcus Leech <usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bcarh342!mleech@ucsd.edu> Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Marcus, I knew that, but my keyboard didn't. Halifax Radio is CFH, not CHU. Boy, did may pals pile on for that goof. Dave
-----------[000463][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 07:27:18 -0400 From: aloh@BBN.COM To: beach@ddnuvax.af.mil Cc: aloh@BBN.COM, khuber@BBN.COM, rng@BBN.COM, dhaskin@BBN.COM, jwojcik@BBN.COM, afddn.cmd@gunter-adam.af.mil, tcp-ip@nic.ddn.mil Subject: Re: [darrel beach: Those Milnet Mailbridges (clarification needed)]
Darryl,
>>> I've stepped all over your message containing Mailbridge questions,
>>> hoping to leave footprints that include the right answers:
Date: Fri, 27 Jul 90 12:20:35 CDT
From: darrel beach <beach@ddnuvax.af.mil>
To: tcp-ip@nic.ddn.mil
Cc: beach@ddnuvax.af.mil, afddn.cmd@gunter-adam.af.mil
Subject: Those Milnet Mailbridges (clarification needed)
...about those Mail Bridges and the IGP they use, and how they use EGP...
(The addresses are of course bogus.)
+----------------------------------+
| |
Mailbridge | | Mailbridge
MB1 -------+ Milnet +------ MB2
26.10.0.100 | 26.0.0.0 | 26.2.0.2
| |
| |
Router G1 | | Router G2
to -------+ +------to 192.50.50.0
192.25.25.0 on | | on 26.1.0.50
26.1.0.25 +-----+-----------------------+----+
| |
| |
| |
Router R1 Router R2
Gateway to Gateway to
131.2.0.0 128.5.0.0 on
26.2.0.131 26.5.0.128
Let's assume the following:
R1 has only MB1 as an EGP neighbor
G1 has only MB1 as an EGP neighbor
R2 has only MB2 as an EGP neighbor
G2 has only MB2 as an EGP neighbor
MB1 and MB2 are using the IGP currently being used by the
Milnet Mailbridges.
>>> The relevent IGP (internal gateway protocol) used in the Mailbridge
>>> Gateways' autonomous system is called "spread". The "internal gateway"
>>> is a gateway in the same autonomous system". All, and only Mailbridge
>>> gateways are in the same, core, autonomous system. Therefore all,
>>> and only Mailbridge gateways are "internal gateways" relative to their
>>> autonomous system. (Previously, the IGP used between the Mailbridges
>>> was "GGP". The IGP used in any autonomous system is not specified,
>>> but instead, is a choice left to the administrators of each autonomous
>>> system.)
>>>
>>> The "spread" protocol uses the same mechanisms as EGP, (i.e. the same
>>> format for Network Reachability messages, also called Updates) but has
>>> different algorithms for performing the autonomous system function of
>>> a core system, than the algorithms used for exchanging network
>>> reachability information with EGP peers in other autonomous systems
>>> ("external gateways").
The questions:
1. Is the following correct?
Its my understanding that MB1 does not provide the direct Milnet
address for EGP neighbors in its IGP exchange to MB2. This would
result in the following routing table for R1:
192.25.25.0 via 26.1.0.25 at 2 hops;
128.5.0.0 via 26.2.0.2 at 3 hops;
192.50.50.0 via 26.2.0.2 at 3 hops;
If my understanding of what's in the IGP packets is correct, then
the effect is obvious and leads to Mailbridge bashing when a direct
route is available.
>>> This is incorrect! Because, the IGP does indeed select optimal routes.
>>>
>>> EGP does not specify algorithms for route selection. The function
>>> to optimize route selection is implemented by the IGP of an autonmous
>>> system acting as a core system. The implementation of a particular
>>> IGP is indeed critical to the resulting route selection, and should
>>> not produce the (non-optimal!) results hypothesized above.
>>>
>>> In the Butterfly Mailbridge Gateways, the current implementation
>>> applies algorithms to both incoming (received) reachability
>>> information and on reachability information being transmitted.
>>> The purpose of these algorithms is to select optimal routes,
>>> which, in fact, is the point of applying the "autonomous system"
>>> concept, to the "core system" concept. (Some of these algorithms
>>> will be discussed in answer to the next question.)
>>>
>>> The routing selection results hypothesized in the question are known
>>> in the literature as the "extra hop problem". This problem is
>>> is conceptually solved by the IGP in the autonomous system acting
>>> as a core system. The IGP selects optimal routes and also supports
>>> consistent and complete network reachability information in each
>>> gateway in the core autonomous sytem.
>>>
>>> The reachability information received in EGP NR Updates is distributed
>>> within the core autonomous system gateways (between the Mailbridges only)
>>> by the autonomous system's IGP ("spread"). The same information, if
>>> received in EGP NR Updates, for indirect neighbors, is distributed in
>>> "spread" updates. And, information received in "spread" updates is
>>> the same information included in EGP NR Updates sent to external gateways
>>> ("acquired" EGP peers). (I have used the words "reachability
>>> information" instead of "route" because the concepts of "hop count" and
>>> "distance" are associated with "route".)
>>>
>>> The reachability information used to build R1's routing table is:
>>>
>>> 192.25.25.0 via 26.1.0.25 at distance 0
>>> 128.5.0.0 via 26.5.0.128 at distance 0
>>> 192.50.50.0 via 26.1.0.50 at distance 0
>>>
>>> Note that what is commonly referred to as the "hop count" of a route
>>> is the "distance" associated with each "neighbor, net" pair
>>> contained in NR updates. In fact, this "distance" is specified as a
>>> "metric whose definition is left to the designers of the autonomous
>>> system" (RFC 888) or "numbers depending on autonomous system
>>> architecture" (RFC 904). The distance values in NR updates can
>>> only be compared with values from the same autonomous sytem.
>>> Distance values from different autonomous systems cannot be
>>> used as routing metrics. It is actually misleading to interpret
>>> "distance" as a hop count.
2. The real question is yet to come and is moot if I'm wrong about 1.
Let's change the neighboring of R1 to use both MB1 and MB2. Let's
also say that R1 use a 10 minute poll and one mailbridge is polled
every 5 minutes, i.e. the polling is 180 degrees out of phase, wit
MB1 getting polled first. After the first update R1's routing
table would be as follows:
192.25.25.0 via 26.1.0.25 at 1 hops;
128.5.0.0 via 26.2.0.2 at 2 hops;
192.50.50.0 via 26.2.0.2 at 2 hops;
When the update from MB2 was received, it would include the
following infomation:
192.25.25.0 via 26.1.0.25 at 1 hops;
128.5.0.0 via 26.5.0.128 at 1 hops;
192.50.50.0 via 26.1.0.50 at 1 hops;
So, would R1 now overwrite the existing routes with the new ones,
or maintain both routes and use the lowest hopcount??
And the real question is what do various implementations do under
such conditions??? If the routes get overwritten, which seems
logical to me, then you have a table that changes with every
update. If you keep old routes when they're better than new ones,
you could never be sure the better route was still available. I
guess there are several philosophies for handling this situation,
and I'd really like to know which is implemented by whom.
>>> Note that EGP doesn't address the problem of route selection.
>>> Rather, EGP specifies how to exchange topological information: network
>>> reachability. And, EGP information is only useful in a topology which
>>> is a tree (has no cycles). This is because EGP does not specify
>>> how to prevent loops in the routing tables which the information is
>>> used to construct.
>>>
>>> The concept of a core system is to compromise on the question of where
>>> to store network reachability information (i.e. complete information in
>>> each reachable gateway vs. complete information in only one central
>>> gateway). The core system is a set of multiple gateways, which is a
>>> subset of all gateways. Each gateway in the core system contains
>>> complete network reachability information.
>>>
>>> The concept of an autonomous system provides for an IGP to maintain
>>> consistent and complete information within all the core system gateways,
>>> and to select optimal routes.
>>>
>>> EGP distinguishes between routes classified as "internal" (first hop
>>> through another gateway in this autonomous system (which,
>>> by definition is another Mailbridge); and "external" (first
>>> hop through a gateway in another autonomous system).
>>>
>>> The routes under discussion are all considered "external".
>>> The distinctive quality of a core system is that only gateways
>>> in a core system include routes through external gateways
>>> in their EGP Network Reachability Updates.
>>>
>>> Furthermore, EGP NR Updates (Network Reachability Updates), transmitted
>>> by a Mailbridge, are customized for each EGP peer. The classic example
>>> is the requirement that routing information for networks reached
>>> through a first hop to a particular EGP peer is not sent back to that
>>> peer!
>>>
>>> This requirement prevents Mailbridge "M", which has a 4 hop route
>>> to net "X" through (first hop) gateway "A" from sending an NR Update
>>> to "A" which contains a 5 hop route to network "X" with first hop
>>> through Mailbridge "M".
>>>
>>> In the literature, this problem is called the "count to infinity",
>>> which occurs once "A" actually loses its original route (i.e.
>>> through loss of the hardware link to the next hop to network "X").
>>>
>>> Without this requirement (known as "split horizon"), when network "X"
>>> is no longer reachable through "A", the NR Update from "M" to "A" could
>>> contain a route to "X" through "M". Then "A", also operating without
>>> "split horizon", could justifiably add 1 to the hop count and send a
>>> route to "X" through "A", back to "M". A bogus route to "X" could
>>> therefore continue to be transmitted back and forth between "M" and "A",
>>> increasing one hop in each NR Update, until "M" or "A" decide that the
>>> distance has been incremented to "infinity".
>>>
>>> Note the misleading use of "hop count" and "distance" in this discussion
>>> of "count to infinity" and "split horizon"! It follows the
>>> presentation of the problem and solution from the literature.
>>>
>>> Given the implementation of "split horizon", it is only reasonable
>>> to assume that other algorithms are applied. In fact, one such
>>> requirement of the core system is that at any one time, only one route
>>> to a network is effective. Periodically, the aggregate information
>>> received from EGP peers (direct neighbors) is reprocessed,
>>> to select the shortest route to each network, from among all routes
>>> to that network, received from all the EGP peers. Such information,
>>> of course may time out, and the information is discarded once
>>> its lifetime has expired. Therefore, periodically, the set of
>>> unique, optimal routes to each network may change!
>>>
>>> A particular EGP implementation is most effective if changes to
>>> routing tables (which may also be used to construct NR Updates!)
>>> only reflect changes to more optimal routes, and not simply
>>> arbitrary changes (i.e. most recently received routes).
>>>
>>> I chose a couple of random hosts registered on nic.ddn.mil,
>>> and queried the Mailbridge at 26.1.0.49, for routes to their
>>> nets. Here are the results:
>>>
>>> net 128.63.0.0 via 26.3.0.29 distance 0
>>> net 129.49.0.0 via 26.20.0.16 distance 21
>>>
>>> The gateway 26.30.0.29 is not a Mailbridge, it is a Milnet "stub"
>>> gateway. The gateway 26.20.0.16 is the Mailbridge at NASA Ames
>>> Research Center.
>>>
>>> Note that one cannot distinguish between an "external"
>>> route such as 128.63.0.0 (i.e. slim.brl.mil) or an "internal"
>>> route such as 129.49.0.0 (i.e. krill.nosc.mil), from the IP
>>> net address. Nor does the IP net address distinguish if the first
>>> hop to the net is through a direct neighbor ("acquired" EGP peer), or
>>> through an indirect neighbor (a neighbor which is listed as a first hop
>>> to some set of nets, in an EGP NR Update from a direct neighbor).
>>>
>>> Recall that EGP is performed between exterior neighbors (gateways
>>> in different autonomous systems). The distinction between a
>>> direct (exterior) neighbor and an indirect neighbor is that a direct
>>> neighbor is an EGP peer, while an indirect neighbor is not an EGP peer,
>>> but is listed in the NR Update from a direct neighbor. For a
>>> Mailbridge (in the core system!) a both direct and indirect neighbors
>>> are always exterior gateways. For a gateway in a non-core autonomous
>>> system, an indirect neighbor may be an interior gateway (relative to
>>> the non-core autonomous system) or it may be an exterior gateway.
>>>
>>> It is dangerous to generalize from random observation of routes
>>> from Mailbridges! It is easy to draw an incorrect conclusion if
>>> all the cases (indirect/direct/interior/exterior) are not observed!
Darrel Beach
....still only an egg after all this time
>>> ....You are hereby graduated to hatchling class, if I haven't
>>> told you too many lies!
>>>
>>> Tony Loh, aloh@bbn.com
-----------[000464][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 01:18:28 GMT From: att!cbnewsd!login@ucbvax.Berkeley.EDU (h.reza.zarafshar) To: tcp-ip@nic.ddn.mil Subject: Ethernet board performance with TCP/IP on PC?
I am looking for a very high performance ethernet board that would go into a 386/PC running AT&T UNIX/386 or some flavor there of. I will be using TCP/IP. I can use either dumb or inteligent boards. So far, I have not found a good combination. While the ones I have tried work, they do lack performance. If any one has tried a successful and high performance combination, I would appreicate it if you could tell me about your experience. Also, I have heard of this company called FTP supposedly located in Boston that sells TCP/IP drivers for UNIX. Does anyone know of them? Has anyone tried their product? Since I don't normally read these newsgroups, I would appreciate it if you would reply via e-mail to: Reza Zarafshar, att!iexist!reza (708)979-8855
-----------[000465][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 01:36:00 GMT From: gaf@uucs1.UUCP (gaf) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: Books on RPC programming?
I'm rather a novice at this remote procedure call stuff (Sun RPC variety), and am looking for reference material. The documentation which comes from our vendor(s) covers the basics well enough to get some simple-minded applications going, but I'd like to streamline them a bit. For example, where I'm currently returning fixed-size arrays back to the client, I'd rather return a variable-length array, with variable length strings in it. The docs I have don't get into this sort of thing, nor into the mysteries of passing lists & trees (pointers) between server and client. The bookstores around here don't have any titles on the subject, so I'm looking for some pointers to reading material from you old pros (emphasis on "pro", not "old"). -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
-----------[000466][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 09:28:35 PDT From: postel@venera.isi.edu To: tcp-ip@nic.ddn.mil, usc!zaphod.mps.ohio-state.edu!mips!ultra!rajiv@ucsd.edu Cc: jkrey@venera.isi.edu Subject: Re: ARP hardware address space values
These numbers are assigned by the Internet Assigned Numbers Authority (IANA). Semd email to IANA@ISI.EDU. See page 46 of RFC-1060 for the current list. --jon.
-----------[000467][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 5:06:06 GMT From: Mills@udel.edu To: Jim Olsen <artemis.ll.mit.edu!olsen@xn.ll.mit.edu> Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Temperature Protocol
Jim, Would be only that WBR70 continued its venerable broadcasts; but alas, Miami Radio has faded into the past. However, intrepid squirrels will discover yet a few 50-bps Baudot-coded WMO broadcasts from various European countries and also the interesting air-america types from Middle America. Gentleman, man your shortwave receivers. Dave
-----------[000468][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 11:19:08 EST From: Scott W. Rogers <rogers@osi540sn.gsfc.nasa.gov> To: tcp-ip@nic.ddn.mil Subject: Internet Access in Dallas, TX.
I am looking for an internet access point in or near Dallas, TX, hopefully one on an NSFnet regional network capable of supporting T1 access. This connection would be required for one week to support the 1991 UNIFORUM conference. If anyone as any information, please send mail to me directly at: Internet: rogers@osi540sn.gsfc.nasa.gov UUNET: uunet!osi540sn.gsfc.nasa.gov!rogers AT&T: (301) 572-8297 Thanks in advance.
-----------[000469][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 1990 15:50:14 PDT From: Ken Harrenstien <klh@NISC.SRI.COM> To: Electronic Mail Association <0002544290@mcimail.com> Cc: klh@NISC.SRI.COM, tcp-ip@nic.ddn.mil Subject: Re: ELECTRONIC MESSAGING '90
It is no doubt meaningful that the interesting list of e-mail addresses does not include an Internet address.
-----------[000470][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 09:34:55 GMT From: eru!luth!sunic!mcsun!piet@bloom-beacon.mit.edu (Piet Beertema) To: tcp-ip@nic.ddn.mil Subject: Re: whois Database
Has anyone else created whois databases? Yes: in Europe there is a body called "RIPE" for coordinating IP networking in Europe. Amongst other things it has collected information about IP networks, domains, etc. The information is available via "whois -h NIC.EU.net". What machines? The database resides on a SUN-4/280.
-----------[000471][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 17:49:54 -0400 From: bzs@world.std.com (Barry Shein) To: mcsun!ukc!tcdcs!swift.cs.tcd.ie!ul.ie!bourkej@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Spare some advice for an old ex-lepper
>Can anyone offer some words of wisdom from their expereinces, or, if you were
>to start from scratch, what would you do different ?
I'd have gone into poetics and put all my money into federal express
at $4.
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
-----------[000472][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 13:14:14 GMT From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: was: the BSD lpd protocol? Stevens' Book
>Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX >Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1. >Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall, >Englewood Cliffs, NJ, 1986. John, useful references, i agree; i meant its a shame there isnt anything of the level of detail of stevens' book for kernel work (i.e. Comer's xinu, Tanenbaum's minix, the old Lions version 6 unix text...level of detail and annotated source; perhaps a book on Amoeba or MACH would be instructive in OS and Comms terms, but i meant something useful for the profssional programmer right now) >>the structure is very similar to a course i teach on comms. software, >>and i think i'm gonna recommend it as a base text.... >Case in point.... the course i teach is a UK university course, and therefore *free* to uk people who meet the entry requirements...
-----------[000473][next][prev][last][first]----------------------------------------------------
Date: 31 Jul 90 13:48:15 GMT
From: uoft02.utoledo.edu!desire!anagram@tut.cis.ohio-state.edu ('ANAGRAM')
To: tcp-ip@nic.ddn.mil
Subject: Reviews of CMU-Tek TCP/IP, pleaseI am looking for reviews of some of the more recent CMU-Tek TCP/IP packages. My company is interested in purchasing the software, but are a little leary ofbuying such an inexpensive package (ever heard the saying you get what you pay?). I have tried local sources, but have either not been able to contact them, or they no longer use it due to upgrades. So, what can people tell me? Thanks Stephen P Potter ANAGRAM@desire.wright.edu
-----------[000474][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 14:56:56 GMT From: mcsun!ukc!axion!vision!ukpoit!ukpoit.co.uk!ian@uunet.uu.net (Ian J Spare) To: tcp-ip@nic.ddn.mil Subject: WIN/TCP Sessions Hanging
I have observed a problem ( or quirk :-) ) with our WIN/TCP and I would like to
know if others see it as well. We have WIN rel 4.0.0.2 and NCR Tower 400 and
500's under REL 3.
Basically when an rlogin or telnet drops whether from line loss ( often caused
by my Epsom PCe locking up ) or user request ( ie. on our annex terminal server)
the remote processes on the host remain. On UNIX this means after a time a
number of phantom users with entries in utmp showing up and a number of shells
etc hanging around. From a sys adm point of view this is a nightmare, I can't
tell if the users are logged in or where physically to look for the sessions.
DO YOU SEE THIS ????
Have you any tips/insights ???
Thanks
Ian
------------------------------------------------------------------------------
Ian Spare |
iT | E-mail : ian@ukpoit.uucp
Barker Lane | BANG-STYLE : ......!ukc!ukpoit!ian
CHESTERFIELD S40 1DY | VOICE : +44 246 214274
Derbys, England | FAX : +44 246 214353
--------------------------------------------------------------------------------
iT - The Information Technology Business Of The Post Office
----------------------- In Tune With Technology -------------------------------
-----------[000475][next][prev][last][first]---------------------------------------------------- Date: Tue, 31 Jul 90 14:14:14 +0100 From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> To: "John S. Quarterman" <jsq@tic.com> Cc: TCP-IP@nic.ddn.mil Subject: Re: was: the BSD lpd protocol? Stevens' Book
>Quarterman, John S., The Design and Implementation of the 4.3BSD UNIX >Operating System, Addison-Wesley, Reading, MA, 1989, ISBN 0-201-06196-1. >Bach, M.J., The Design of the UNIX Operating System, Prentice-Hall, >Englewood Cliffs, NJ, 1986. John, useful references, i agree; i meant its a shame there isnt anything of the level of detail of stevens' book for kernel work (i.e. Comer's xinu, Tanenbaum's minix, the old Lions version 6 unix text...level of detail and annotated source; perhaps a book on Amoeba or MACH would be instructive in OS and Comms terms, but i meant something useful for the profssional programmer right now) >>the structure is very similar to a course i teach on comms. software, >>and i think i'm gonna recommend it as a base text.... >Case in point.... the course i teach is a UK university course, and therefore *free* to uk people who meet the entry requirements...
-----------[000476][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 16:06:36 GMT From: kevin@gtisqr (Kevin Bagley) To: comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: TCP-IP->DOS->EtherTalk->LaserWriter?
O.K., I'm not giving up.... yet.
Recently, I posted a request for information regarding printing from
386 machines running Interactive Unix over a TCP/IP network to a
Mac SE with Ethernet card to a Laserwriter connected via LocalTalk.
The responses I have received indicated we need to purchace a Gateway
such as the Shiva Fast Path, or the Cayman GatorBox, etc.. Naturally,
I am looking for alternatives since these devices are priced from $1500
to more than $2500. My company doesn't want to pay those kind of prices.
I understand that EtherTalk and AppleTalk are available on DOS machines.
Is there a device/software that will convert TCP/IP into EtherTalk or
AppleTalk at the DOS machine level? Would it be possible to make this
'back door' route function enough to print a file from one of the Unix
boxes to the Laserwriter? How?
What about going the other direction? Could we hang the Laserwriter off
of one of the Unix boxes with a serial line and print from the Mac to a
DOS machnine an then to a Unix box, and finally, to the Laserwriter?
Any help you have to offer will be greatly appreciated.
--
_____ Kevin Bagley Global Tech. Int'l Inc., Mukilteo WA 98275 206-742-9111
)___) _ _ _ UUCP: {smart-host}!gtisqr!kevin
_/___) (_(__(_)_/_)_ "yisdersomenimororsesassesdenderisorses" (Mo's@Newport)
______________/ Disclaimer: "I did not say this. I am not here." (Dune)
-----------[000477][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 16:24:04 GMT From: philmtl!atha!aupair.cs.athabascau.ca!lyndon@uunet.uu.net (Lyndon Nerenberg) To: tcp-ip@nic.ddn.mil Subject: Is there a spec for "uucp-path 117/tcp" ?
Several of our machines list the service "uucp-path" on tcp port 117.
Does anyone have a reference describing what this service does?
--
Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University
{alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca
Practice Safe Government
Use Kingdoms
-----------[000478][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 17:23:21 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) To: tcp-ip@nic.ddn.mil Subject: Re: WIN/TCP 5.1 error...
My original reply to this bounced today, so I'll post instead: In article <28900@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: >I am getting a mystifying error (mystifying because there's nothing in >the docs about it) from WIN/TCP on my uVAX II. >%LPDSMB-F-FILEREAD, >What is happening? What should I check? This is telling you that your lpd deamon can't read some file. A short chat with the author of lpr/lpd for win/tcp reveals that this error is usually caused by the spool directory having the wrong protections. These directories should be readable and writable by the [LPD] account, but no other accounts (to avoid security holes) should be able to write to these directories. See the appendix of the System Admin guide for more details. In article <1990Jul30.203106.22496@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: >Decoding the message identifier according to normal rules says that >a component called LPDSMB (probably a print symbiont which is a client >for the Berkeley Line Printer Daemon; i.e. talking to a remote print >queue over the network) had a FILEREAD error. Yes, it is a LPR/LPD protocol speaker for VMS. LPD.EXE (the part of the system that worries about talking lpr/lpd to neighbors) runs effectively as SYSTEM. It can put files into the queue with no problems. However LPDSMB runs as LPD so there can be a few protection problems if the both the ownership of the spool directory (specified with the /SPOOL_DIR=xxxx qualifier in the TWG$TCP:[NETDIST.ETC]PRINTCAP file) isn't [LPD]. When setting the ownership of a spool directory that may have files in it, you will want to also set the ownerships of the files in that directory as well. Warner -- Warner Losh imp@Solbourne.COM
-----------[000479][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 18:53:09 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov To: tcp-ip@nic.ddn.mil Subject: Re: Ports 1000-1023 reserved?
In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes: > TCP/IP Version 2 for VM will start allocating ports at port number 1024, > to prevent this problem with the Hewlett Packard product. Ports > 1000-1023 are not restricted, and I am surprised that Hewlett Packard > does not have problems interoperating with other TCP/IP products than > VM. I beg to differ. Please check RFC-1060 in the section "UNIX PORTS". By convention, ports in the range 256 to 1024 are used for "Unix Standard" services. This is "by convention", but in IP-land "by convention" is what is really done. So HP has no problem with the vast majority of implementations since the authors knew that all addresses up to 1024 were reserved. Only those designed in strict compliance with the specs are going to have problems. And I doubt if any implementation has ever worked by designing to the spec. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
-----------[000480][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 19:51:51 GMT From: excelan!donp@ames.arc.nasa.gov (don provan) To: tcp-ip@nic.ddn.mil Subject: Re: Ports 1000-1023 reserved?
In article <1990Jul31.115309.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes: >In article <9007301547.AA19807@ucbvax.Berkeley.EDU>, DBARTON@IBM.COM writes: > >> TCP/IP Version 2 for VM will start allocating ports at port number 1024, >> to prevent this problem with the Hewlett Packard product. > >I beg to differ. Please check RFC-1060 in the section "UNIX PORTS". > > By convention, ports in the range 256 to 1024 are used for "Unix > Standard" services. OK, this discussion has gotten out of hand and i'm afraid some innocent novice it going to believe some of this misinformation. While it is true that ports lower than 1024 are reserved on many systems, that has nothing whatsoever to do with the HP bug that's being discussed here. The port given in the FTP PORT command is a *remote* port. There's no justification at all for HP checking this port for any range of any type for any reason. It should just use the port given. I don't even understand what prompted some misguided soul to add the extra, unnecessary code needed to make this check. I applaud the IBM developers for making this simple change to accommodate the HP implementation, but i want everyone to understand that the HP implementation is, in fact, broken. don provan donp@novell.com
-----------[000481][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 20:10:37 GMT From: media-lab!snorkelwacker!spdcc!mirror!necntc!necis!adamm@EDDIE.MIT.EDU (Adam S. Moskowitz) To: tcp-ip@nic.ddn.mil Subject: Re: tcpdump on 4.3 Reno?
In article <16330@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) wrote:
} In article <9007271758.AA13923@ucbvax.Berkeley.EDU>
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
}} btw. 'scuse my ignorance, but what is the origin of the 'tahoe', 'reno'
}} naming scheme - is't simply placenames?
}
} "Tahoe' was the model name of the CCI system that they had to port the
} 4.3 system to . . .
True enough.
} I'm told that the newer one is called 'Reno' because running it is
} taking a real gamble. Snicker.
The story, as I heard it from the nameless gradual student who claims to have
though of the name "4.3-Reno" (and a slightly inebriated but reliable BSD
hacker verified this), was that it's all a joke. Reno is the next town north
of Tahoe on I-80 hence the name.
Reveal my sources? Never! Could I be wrong? Sure - I was slightly inebriated
at the time the story was told to me. :-)
AdamM
--
What are you going to do if you're all plowed and too wet | Adam S. Moskowitz
to dance? | adamm@necis.nec.com
| ...!uunet!harvard!\
(nobody) | necntc!necis!adamm
-----------[000482][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 21:06:58 GMT From: pacbell.com!tandem!mytardis!jb@ucsd.edu (John Bartas) To: tcp-ip@nic.ddn.mil Subject: Software assigned Ethernet Addresses
I lost the posting from the fellow who was going to build an ethernet
board without an address prom and assign the address via software,
but I once worked for a company that was going to do the same thing.
Although they didn't find anything in the spec saying NOT to do it, I
was uneasy about the fact that although it seemed an obvious way of
reducing parts and cutting mfg costs, no one else that I knew of did
it. We even prototyped some boards and had them working in our labs
with commercial net protocols. Hand assigning unique ethernet numbers
to each board we brought up was a pain, but is was doable.
We gave up on the idea when we thought about booting via the net. We
needed an address to start to boot, but we needed to be booted for software
to assign an address. Chicken and Egg. There were other problems too,
but I left all my notes at the company and don't recall details. You
didn't mention what your machine was for, so maybe none of this applies
to you.
-JB-
-----------------------------------------------------------------------
John Bartas | This space for rent.
NetPort Software |
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |