----MESSAGE-BEGIN---- <1990050101263500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 30 Apr 90 22:30:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19598; Mon, 30 Apr 90 20:20:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 01:26:35 GMT From: xanadu!michael@apple.com (Michael McClary) Organization: Xanadu Operating Company, Palo Alto, CA Subject: Re: anonymous ftp, and the dangers thereof Message-Id: <1990May1.012635.16106@xanadu.com> References: <447@illini.osc.edu>, <183@tons61.UUCP>, <10309@yunexus.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: >How about: > This mechanism will ensure that only files in the directories > "under" the chroot-point are acessable: > > if program is not setuid-root, > program exits forthwith Note that it's not sufficient to limit a chroot to going leafword on a tree but leave it executable by non-root users. A generally-executable chroot lets a user build a directory tree like this: user_home user_root etc passwd then chroot to user_root and exec login. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050103354300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 30 Apr 90 22:31:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19298; Mon, 30 Apr 90 20:14:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 03:35:43 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu Organization: IR Subject: Re: seeking info on Acces Control List (ACL) mods to inetd Message-Id: <8986:May103:35:4390@stealth.acf.nyu.edu> References: <9004201533.AA14816@msr.EPM.ORNL.GOV>, <9004231817.AA19626@hp-ses.sde.hp.com>, <2006@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2006@tuminfo1.lan.informatik.tu-muenchen.dbp.de> k2@charly.bl.physik.tu-muenchen.de (Klaus Steinberger) writes: > > Has anyone hacked inetd to consult an Access Control List or other > > security extensions, ... > >Yes. HP-UX has had this extension for several years. We use the > >file /usr/adm/inetd.sec. I've appended a sample to this message. > Is it possible to post the modifications to inetd ? > Or will it be propietary code? > I think there is some interest on the net for ACL's on inetd Well, you could pick up my auth package, which was sent out today on comp.sources.unix. If you use attachport rather than inetd to handle connections, you can set these things up without much trouble: #!/bin/sh # Untested. Should allow connections from anyone at 128.9.0.32, # anyone in 192.48.96.*, and authenticated root at 128.122.128.22. # Should disallow connections from hacker@128.9.0.32 as well as all # unauthenticated connections from 128.9.0.32. # We should really test for PROTO=TCP first, since other communications # mechanisms might not have the same REMOTE format. Instead we'll # assume (ha!) that we're only invoked from the Internet. if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \ '^((.*@128\.9\.0\.32)|(.*@192\.48\.96\.[^\.]*)|(root@128\.122\.128\.22))$' then if /usr/ucb/printenv REMOTE | /usr/bin/egrep -s \ '^((shmoe@128\.9\.0\.32)|(@128\.9\.0\.32))$' then exit 1 # perhaps log error somewhere else exec /etc/whateverd fi else exit 2 # perhaps log error somewhere fi Notice how you can test for the username as easily as the host. To better simulate the HP/UX functionality, you'd have to write a program that would take those ``inetd.sec'' files, parse them, and check REMOTE accordingly. Anyone like writing text processing programs? ... If there's enough interest I'll do this and send it out. ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050104213800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 30 Apr 90 22:28:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22724; Mon, 30 Apr 90 21:14:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 04:21:38 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu Organization: IR Subject: Re: Remote Netstat Message-Id: <9313:May104:21:3890@stealth.acf.nyu.edu> References: <9004262255.AA14530@chico> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9004262255.AA14530@chico> mja@chico.simpact.com (Mike Anello) writes: > Does any have a public domain version of a remote netstat program available ? > I know about SNMP but I need something even simpler. Thanks. Pick up auth and authutil from comp.sources.unix. Install auth; follow the client-server examples in authutil. The basic idea is server% attachport -vp 52000 /usr/ucb/netstat -n & client% authtcp server 52000 /bin/sh -c '/bin/cat <&6' You can make arbitrarily complicated clients and servers. The authtcp client receives its connection in fd 6; the attachport server receives each connection in fds 0 and 1. Unless you specify -R to attachport, the server will see the client's user@in.et.num.ber in environment variable REMOTE, and vice versa for specifying -R to authtcp. (If the connection is unauthenticated, user will be blank.) ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050111381000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 1 May 90 10:36:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05593; Tue, 1 May 90 10:16:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 11:38:10 GMT From: cucstud!tfd!tons61!harrys@uunet.uu.net (Harry Skelton) Organization: U.S. Dept. of Transportation Subject: Re: anonymous ftp, and the dangers thereof Message-Id: <186@tons61.UUCP> References: <447@illini.osc.edu>, <183@tons61.UUCP>, <10309@yunexus.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <10309@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: >harrys@tons61.UUCP (Harry Skelton) writes: >>allow the local site to include security measures for such a problem. Like >>a chroot() before any work is done, or allocate spool directories that work >>like the chroot command/uucp environments. This would resolve all of these >>problems. > >How about: > This mechanism will ensure that only files in the directories > "under" the chroot-point are acessable: > > if program is not setuid-root, > program exits forthwith > if program is setuid-root > program changes directory to chroot-point > program changes root to chroot-point > program gives up privilege by setting euid to uid. > > Note that this does not protect the system from any manipulations > that the program does to the directorys below the chroot-point, only > limits changes to files outside that area. > >Corrections and suggestions welcome! Add to the list: o make config file much like HDB to control available commands for a particular user(s) (i.e. be able to limit CWD, etc) o allow for separate log files for each user (config?) o allow for 'secure' files although readable by anyone - be able to exclude files from a user - be able to include files for a user o Add dual logfile/console logging of transmistions - record user commands - add record output for accounting purposes o allow limits on amount of data passed or time consumed - modification to RFC's necessary for new result codes - changes in FTP commands to include overide protections? Changes other than security.... o Add protocols other than ethernet connections - add uucp transmitions interfaces - add xmodem/ymodem/zmodem transmitions interfaces o Add new binary standards - header/noheader options (good for Mac Binary and other such codes) - compress/nocompress options (for 56k/38.6k links, etc..) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050113592400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 1 May 90 21:44:09 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17766; Tue, 1 May 90 21:33:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 13:59:24 GMT From: mcsun!ukc!mucs!cns!ran@uunet.uu.net (Bob Nutter) Organization: UMIST, Manchester, England. Subject: What do FIN_WAIT_2 & CLOSE_WAIT mean? Message-Id: <1990May1.135924.11279@cns.umist.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Could anyone elighten me with regards to the meanings of FIN_WAIT_2 and CLOSE_WAIT (and for that matter ESTABLISHED) when they appear in the socket state column for the default netstat output? We can't seem to find an explanation in any of our documentation. One of our (apollo dn4000) nodes has a *lot* of FIN_WAIT_2 entries and seems to be slowing down, hence the need to figure this out. Please reply by email. Thanx in advance, bob ------------------------------------------------------------------------------ bob nutter, computer officer | (Witty message on vacation) dept. of computation, UMIST | po box 88, m60 1qd uk | tel:+44 61 200 3386 | email:ran@cns.umist.ac.uk | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050119022000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 2 May 90 00:17:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25916; Tue, 1 May 90 23:59:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 May 90 19:02:20 GMT From: zaphod.mps.ohio-state.edu!samsung!xylogics!transfer!lectroid!jjmhome!banyan!gordon@tut.cis.ohio-state.edu (Gordon Lee@Eng@Banyan) Organization: Banyan Systems, Inc. Subject: PC-LAN connection to Usenet Message-Id: <798@banyan.UUCP> References: <4950@netxcom.DHL.COM>, <2744@psueea.UUCP>, <2745@psueea.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2745@psueea.UUCP> dmatlock@eecs.UUCP (Delbert Matlock) writes: >In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes: >>I am asking the following question on behalf of my husband - at his work >>there is only a LAN - he would like to know what hardware, software and >>phone number he needs for a dial-up connection to Usenet - he would like >>to be able to read the newsgroups and post to them as well. > >Actually, I'de like to know if there is an implementation out there that >will run on a DOS or OS/2 based LAN. To be specific, a 3+Open LAN Manager >network. This LAN could easily be fitted with any protocols (TCP/IP) or >gateway equipment (X.25) needed, but I would like to avoid having to put >a 386 UNIX box on the network for just running Usenet. > I haven't heard of any implementations, but certainly wouldn't be conceptually difficult to write one. I've been thinking about this problem for the last two weeks or so. For cases where you have an Internet connection, it is possible to write an NNTP server for an OS/2 machine. The NNTP protocol can run over any stream oriented transport protocol, of course the protocol of choice would be TCP/IP stack since NNTP implementations within USENET are usually talking TCP/IP, (I haven't heard of an implementation which uses a different protocol). But NNTP could also be spoken over named pipes to transfer news to other OS/2 NNTP services. For that matter, it is possible to write an NNTP service for a DOS machine. Boot the pc, mount a large network file volume, fire up the NNTP server and leave the machine running on a continuous basis. The server fills the network volume up with USENET news. The directory structure would follow the same scheme found under UNIX implementations. Write a newsreader for DOS, and use it from other PC's to read news on the network file volume, no network code in the newsreader, it is doing sinple read system calls to the network file volume as if it were a local disk. Write an NNTP xmit client program to run under DOS and you can also post news. But where do you put the .newsrc file ? Oh, I dunno, punt for now, put it anywhere and then point an environment variable to it. Then of course, you'd also want to port all the other netnews support tools and utilities, like expire, and have something like cron to make them run on a schedule. And of course you'd have to leave the PC's running during the scheduled times. It all adds up to a large project made up of a lot of pieces, some of which are small though. Of course the whole thing rests on the assumption that you have network file volumes and a TCP/IP stack, but both of these have been commercially available for quite a while. I'd be interested in hearing of experiences or implementations from anyone else has looked at this problem, but please, no flames about DOS and/or OS/2, I am not interested in any Operating System holy wars. I am only interested in the communications aspects of the problem. - Gordon -- ============================================================================= Gordon Lee gordon@banyan.com Banyan Systems, Inc. Westboro, MA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050200324800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 2 May 90 19:30:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02017; Wed, 2 May 90 19:23:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 90 00:32:48 GMT From: paperboy!snorkelwacker!ira.uka.de!smurf!wrkof!dksoft!dirk@think.com (Dirk Koeppen) Organization: Koeppen EDV-Beratung , FRG-6050 Offenbach Subject: TCP and UDP socket write limits Message-Id: <982@dksoft.incom.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Where can I find information about the length I can write to a UDP or TCP socket. On my system (386/ix) I found out (try and error method) that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are limited to 4096 byte per write. There are some calls to increase the SOCK_STREAM buffer size but can I rely that another system will accept > 4096 byte packets ? Can't I let the kernel do the fragmentation ? cu, Dirk Koeppen dirk@incom.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050202413000> Received: from uu.psi.com by NIC.DDN.MIL with TCP; Wed, 2 May 90 04:48:08 PDT Received: from seadog.UUCP by uu.psi.com (5.61/3.1.043090-Performance Systems International-Albany) id AA05271; Wed, 2 May 90 07:45:57 -0400 Date: Wed, 2 May 90 07:41:30 EST From: seadog!stan@uu.psi.com (Stanfield L. Smith) Subject: Local bridge w/SNMP Message-Id: <9005020741.0.UUL1.3#20145@seadog.UUCP> To: tcp-ip@nic.ddn.mil >Date: 23 Apr 90 20:24:12 GMT >From: Mitch Wood >Organization: Federal Express Corp., Memphis, TN >Subject: LoNeed Local Bridge w/SNMP > >Does anyone have a suggestion for a Local Bridge with SNMP support? > >thanx in advance >Mitch Wood` > Emerging Technologies Inc has a PC-based local bridge which supports SNMP. Its a hybrid bridge (it supports concurrent IP router and MAC-level bridging), and it can support up to 4 Ethernet networks. It uses the Western Digital WD8013E 16-bit card. Runs on any 25mhz AT, and the software is fairly inexpensive (about $1K). They are on Email: etinc!info@uu.psi.com Stan ----------------------------------------------------------------- Real Name : Stanfield L. Smith USmail : CNS Enterprises Internet : stan@seadog.cns.com : P.O. Box 1127 UUCP : uupsi!seadog!stan : Lk Ronkonkoma Phone : 516-737-2238 : New York 11779 ----------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050209215900> Received: from uc.msc.umn.edu by NIC.DDN.MIL with TCP; Wed, 2 May 90 14:29:34 PDT Received: by uc.msc.umn.edu (5.59/1.14) id AA01110; Wed, 2 May 90 14:21:59 CDT Date: Wed, 2 May 90 14:21:59 CDT From: cei001@uc.msc.umn.edu Message-Id: <9005021921.AA01110@uc.msc.umn.edu> To: tcp-ip@NIC.DDN.MIL Subject: IP based job submission services.. I'm am sure that this story has been told before but I can't find it in the archives: A large organization decides to get its act together and connect the numerous machines with an open and robust communication network based on TCP/IP. Everything gets installed just fine, and the next day people are telnet'ing and ftp'ing to their hearts content. (Sounds great, doesn't it?) Now along comes a user who wants to do "batch" processing. He'd like to "submit" a job to another system. Imagine his surprise to find no popular IP service for this. He protests the "new" network and in order to avoid deinstalling the entire net, the organization quickly establishshes a RJE network (or equivalent) of sync lines between the very same host. Is it possible that there is some answer to this problem, and it just hasn't made it out to the commercial market yet? The only two published services I can find is the (old?) RJE spec, and the NQS code. Are there other common ones that I'm missing? I am interested in who's running what out there in field for this problem.. Now for the one little question I had (and I will repost this to IBMTCP list): Is there any sites that have a method for IP systems to submit MVS jobs? (On most other systems, ftp [or mail!] and some deamons will work..) ------- John Curran Engineering Computer Services Asea Brown Boveri (203) 285-652 cei001@uc.msc.umn.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050212485200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 2 May 90 10:16:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27938; Wed, 2 May 90 10:13:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 90 12:48:52 GMT From: mcsun!ukc!axion!masalla.fulcrum.bt.co.uk!igb@uunet.uu.net (Ian G Batten) Organization: BT Fulcrum, Birmingham, England. Subject: Bootp, Rarpd Wanted Message-Id: <7|4#-{#@masalla.fulcrum.bt.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for sources to either an implementation of bootp or, failing that, rarp. It's for System 5, but I'd be happy with anything Unix-y! Thanks for any pointers ian ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050219295400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 01:46:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23555; Thu, 3 May 90 01:32:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 90 19:29:54 GMT From: mcsun!unido!fauern!fauern!eckert@uunet.uu.net (Toerless Eckert) Organization: CSD, University of Erlangen, W-Germany Subject: FAX over IP software wanted. Message-Id: <2698@medusa.informatik.uni-erlangen.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Sorry, i lost all my pointers on this subject. Can anyone give me a hint, where to find such a beast ? Thanks -- Toerless Eckert Internet: eckert@informatik.uni-erlangen.de X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050223155700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 00:20:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18641; Thu, 3 May 90 00:05:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 May 90 23:15:57 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) Subject: Addressing SNMP proxy agents Message-Id: <373@minya.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, y'all. My question today is triggered by a request by the folks I'm working for that I see if our SNMP agents can be made to act as proxies for machines that don't talk IP. On perusing rfc1085, I get the impression that it is supposed to be possible. On the other hand, I don't quite know enough to be able to say for sure how the code should be modified, if it is even possible. Several times in the past, I've written proxy agents for other configurations, but then I've always had the advantage of writing both the client and the agent code, so of course I could make them understand each other. In this case, I'm just the proud posessor of the source code to the agent, which is expected to talk to assorted SNMP clients from assorted vendors. This isn't too surprising; this is what SNMP is all about, after all. My problem is that I can't quite determine from the rfcs just what sort of byte string (ASN.1, of course) to expect from a client that has sent me a message. The current agent only understands addresses like: 40 4 16 121 0 95 where 40=IPaddress, 4 is the size, and the address is 16.1212.0.95. We've gotten a couple of sessions together to bat about ideas, and the ways this might be extended to indirect through a proxy, well, let's say that if you have N people in the discussion, you probably have N*log(N) ways of doing the job. What I'm interested in is hearing how others expect this to work. If you are writing an application that deals with proxy agents, what sort of addresses will you be sending my agent? To make things more concrete, suppose that behind the above proxy agent, which is listening on the SNMP port, we have a bunch of machines on the local FOOnet, and they have n-byte addresses. These could be represented in various ways, such as a string: 4 3 54 71 71 where 4=string, 3 is its size, 54='f', 71='o', etc. The easiest way to combine this with the agent's IP address would be as a 7-octet string: 40 7 16 121 0 95 54 77 71 This is, of course, far too simple-minded for any self-respecting hacker (oops, I mean professional software engineer) to even consider, so obviously it's not correct, and we must think of another method. One possibility is to combine them into an ASN.1 sequence: 30 14 40 4 16 121 0 95 54 77 71 4 3 54 71 71 Many other possibilities come easily to mind, especially after a few drinks (or perhaps something stronger than ethanol :-). I'd like to find out which (if any) are "correct", and also which are likely to be encountered in the Real World. (Note the implicit admission that these aren't synonymous.) On reading rfc1085, I find mention of something called a "presentation selector", though I can't find anything that tells me how to recognize one when it bites me. There's also a comment mentioning a 16-bit port number, as well as something about a set indicating which transport services are available. I speculate that this has something to do with the problem but I can't quite decide what. The whole problem is, of course, isomorphic to the older problem of routing to indirectly reach machines that can't be reached directly. We know lots of ways of doing this, and it's obvious that the SNMP people, as well as the CMIP people, have considered it. They even seem to have decided that they've solved the problem. Now someone should be getting across to dummies like me just what the solution(s) might look like. I'd prefer email responses, since I've been sort of falling behind in reading all the netnews that I should... -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc -- If you're not part of the solution, you're part of the precipitate. [Kiel oni ^ci tiun diras esperante?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050300274800> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 3 May 90 13:13:49 PDT Received: from wrs.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA23270; Thu, 3 May 90 16:12:39 -0400 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA20958; Thu, 3 May 90 12:02:25 PDT Received: from daahoud. by yuba.WRS.COM (4.0/SMI-4.0) id AA00671; Thu, 3 May 90 12:07:37 PDT From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) Message-Id: <9005031907.AA00671@yuba.WRS.COM> Received: by daahoud. (4.0/SMI-4.0) id AA05544; Thu, 3 May 90 12:07:49 PDT To: uunet!think.com!barmar@uunet.UU.NET (Barry Margolin) Cc: tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET Subject: Re: TCP and UDP socket write limits In-Reply-To: Your message of 03 May 90 05:06:23 +0000. <36029@think.Think.COM> Date: Thu, 03 May 90 12:07:48 -0700 > > In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes: > >that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are > >limited to 4096 byte per write. There are some calls to increase the > >SOCK_STREAM buffer size but can I rely that another system will accept > >> 4096 byte packets ? Can't I let the kernel do the fragmentation ? > > There's should be no necessary relationship between kernel buffer size and > packet/datagram sizes for stream sockets. Stream sockets are byte streams, > and they can be packetized arbitrarily. During TCP connection setup each > side tells the other the largest packet size it's willing to accept. Also, > while the connection is open windows are increased and decreased to > accommodate the receiver's available buffer space. There kernel will have > to buffer data and/or block the sending process in order to accommodate the > other system's limits. > > Barry Margolin, Thinking Machines Corp. the socket level buffering is mostly independent of the protocol level buffering. tcp connection goes through max segment negotiation at the connection setup time but this is unrelated to the socket level buffer size; it is more dependent upon the mtu of the interface you're using. (see in tcp_mss() in tcp_input.c in 4.3 bsd tahoe tcp/ip implementation). the receive side tcp buffer window adjustments are related to the socket level buffer space. tcp uses the size of socket level buffers in calculating its receive window size. the socket level buffers are mbufs whose size can be adjusted via setsockopt() commands SO_RCVBUF and SO_SNDBUF. the default values for these buffers in stock 4.3 bsd tahoe tcp/ip are: tcp-receive (4K), tcp-send (4k), udp-receive (4k), udp-send (2k). if not enough space is available at the socket level and you're sending large piece of buffer you'll get an EMSGSIZE error. hwajin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050300365300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 2 May 90 19:30:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01745; Wed, 2 May 90 19:18:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 00:36:53 GMT From: usc!samsung!munnari.oz.au!metro!bunyip!cuscus.cc.uq.oz.au!ggm@ucsd.edu (George Michaelson) Subject: Re: Could MX be made to do more? Message-Id: <`='.641695013@cuscus.cc.uq.oz.au> References: <9004302020.AA24158@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil craig@NNSC.NSF.NET (Craig Partridge) writes: >> this means.... your mail sits in the local queue. >Why are all the MX RRs on the wrong side of the pipe?? Good question. In general, one does not have control over the MX records of ones elders and betters (c/f kre@munnari.oz.AU) or (being less flippant) of distant hosts. >In general, your lowest MXs ought to be very close to your system. So >if you miss munnari, you oughtta be getting an MX nearby. I'm confused by the "your" in there. Whose MXs should be close to me? *my* MX records are: 0 myself 100 munnari 200 uunet.uu.net but thats how I assert people should reach me. In sending stuff outwards its "their" MX I'm using and for a.n.other's MX records you are dependant on the sanity of the individual unknown sysop. Munnari, in offering wildcard MXs for "big" networks is doing me a favour so I don't want to cause any ill feeling there. Do they need gentle hints about extending their MX structure? -George -- George Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre Queensland University, St Lucia, QLD Australia 4067. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050302091800> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 3 May 90 09:08:53 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 3 May 90 09:08:33 -0700 Date: Thu, 3 May 90 09:09:18 PDT From: braden@venera.isi.edu Posted-Date: Thu, 3 May 90 09:09:18 PDT Message-Id: <9005031609.AA03619@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Thu, 3 May 90 09:09:18 PDT To: cei001@uc.msc.umn.edu, tcp-ip@nic.ddn.mil Subject: Re: IP based job submission services.. Is there any sites that have a method for IP systems to submit MVS jobs? (On most other systems, ftp [or mail!] and some deamons will work..) The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, supports batch submission via SMTP. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050302355900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 00:19:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19403; Thu, 3 May 90 00:14:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 02:35:59 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) Subject: Re: Is there SNMP Certification Testing? Message-Id: <375@minya.UUCP> References: <9004191416.AA19284@jove.pa.dec.com>, <9004200313.AA22741@psi.com>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , emv@math.lsa.umich.edu (Edward Vielmetti) writes: > In article <9004200313.AA22741@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes: > ... Now add > a full-time neutral coordinator, ready to work with the various > communities,from small startups, to the researchers, to big dinosaurs, > to users, and we might catalyze the process. > > Ah, but who will pay the salary of this full-time coordinator? You're not > going to find too many volunteers for the task. > sounds like real work (but interesting) to me. Yah; I've been volunteering for such a lab at various places for years, and I've even been told I'd be good at it. ("Man, you sure know how to find ways to make things fail!" ;-) So far, everyone thinks it's a real good idea, but they want someone else to pay for it. And people wonder why our stuff doesn't interoperate very well. -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc -- If you're not part of the solution, you're part of the precipitate. [Kiel oni ^ci tiun diras esperante?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050302501700> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 06:50:49 PDT Received: from [129.118.224.5] by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with TCP; Fri, 04 May 90 09:50:18 EDT To: TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU In-Reply-To: Your message of Thu, 3 May 90 09:09:18 PDT Subject: Re: IP based job submission services.. Date: Thu, 03 May 90 08:50:17 cst From: (strick) > Is there any sites that have a method for IP systems to submit MVS jobs? > > (On most other systems, ftp [or mail!] and some deamons will work..) > >The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, >supports batch submission via SMTP. > >Bob Braden How can I get more information about UCLA ACP? strick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050303482100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 00:20:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19457; Thu, 3 May 90 00:14:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 03:48:21 GMT From: spdcc!ima!minya!jc@husc6.harvard.edu (John Chambers) Subject: Is the hostname "foo" or "foo.bar.com"? Message-Id: <376@minya.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil While I'm at it, I'll ask another question that has triggered a raging religious war at work. The subject summarizes it, but I oughta give some more details. At this site, and at several others I've seen, there are some machines on which if you type a hostname command you get a response like: foo.bar.com while on other machines, you would get only foo with the domain junk added by the mailer. The managers of each sort of machine generally insist that they are doing it right, and it's the idiots who do it the other way that are responsible for all the network screwups that result. I've just spent an hour or so perusing the RFCs, and I can see why there is a question. There seems to be no unambiguous definition of "hostname" that I can find. There are several apparently-relevant passages, but it doesn't take a fine legal mind to pick holes in the wording of any of them. For instance, in RFC883 we find: | The labels must follow the rules for ARPANET host names. They must | start with a letter, end with a letter or digit, and have as interior | characters only letters, digits, and hyphen. There are also some | restrictions on the length. Labels must be 63 characters or less. | | For example, the following strings identify hosts in the ARPA | Internet: | | F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA This is at first glance self-inconsistent. At second glance, we see that it in fact doesn't state the rules for a "hostname" It says that "labels" contain only letters, digits, and hyphen. Leaving aside the question as to whether two hyphens might be legal, we just note that the "foo.bar.com" faction would simply say "Fine, the *label* `foo' follows the rules, and the hostname is `foo.bar.com'." But the above examples aren't actually stated to be hostnames; they are rather "strings [that] identify hosts", something to which both factions would readily agree. The "foo" faction would note that "foo.bar.com" identifies a host, and consists of two main portions: "foo" is the hostname, and "bar.com" is the (2-level) domain. My only contribution to this battle so far is to mention that I've seen cases in which a mailer would take a name like "foo.bar.com" and append the domain "bar.com" to it, giving "foo.bar.com.bar.com". Then there's the fun you can have if JNET is involved: "com.bar.foo.bar.com". This is clearly brain damage on the part of the mailer; it can be fixed easily by telling the kernel that its hostname is "foo". This also satisfies my penchant for less typing, so I tend to go with it. But it'd be nice to know which (if any) is correct. It'd also be nice to have an official document to point to to settle the debate when it rears its time-wasting head again. There is also the problem with a hostname of foo.bar.com, in that many common commands (such as who) truncate the hostname to N bytes, where N is typically in the 10-16 range. The truncated output of such programs can't be used as input to others, because the "hostnames" don't match anything in /etc/hosts, although that's where they came from. Of course, this can happen with the short form, since the RFCs state that 40-char names are legal, but have you tried using one? Part of the basis of the battle is that both factions "prove" their point of view in terms of /etc/hosts. The "foo" crowd says that a proper entry looks like: 16.37.91.42 foo foo.bar.com baz fliorph while the "foo.bar.com" faction insists that the entry should read: 16.37.91.42 foo.bar.com foo baz fliorph It's easy to show that BSD systems (and sendmail) require that the first field of the localhost's entry by the same as the output of the hostname command. If this isn't true, things can get very weird. But experiment doesn't seem to say which is the One True Host Entry. It does show that if both ends of a conversation do it differently, things can also get a bit weird. Anyone know what the answer to this is? (If history is any guide, I'd expect followups proving that both are correct, and I'll have one more entry in my growing list of Why Networks Are So Messed Up. ;-) -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc -- If you're not part of the solution, you're part of the precipitate. [Kiel oni ^ci tiun diras esperante?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050304502300> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Thu, 3 May 90 08:56:08 PDT To: jc@minya.uucp cc: tcp-ip@nic.ddn.mil Subject: re: Is the hostname "foo" or "foo.bar.com"? Date: Thu, 03 May 90 11:30:23 -0400 From: Craig Partridge John: I think the proper answer to your question is: ``who cares what hostname says?'' Hostname is simply a UNIX program to let you give your host a name. It has no standing in the Internet protocol suite. What the RFCs are about is what comes out of your system. On that subject, they're pretty clear (see RFCs 1122 and 1123). You're supposed to deliver fully qualified domain names to the outside world. If you want to lie internally to your users and call yourself "foo" that's your problem -- just make sure that when the mail comes off your host, it reads "foo.bar.com" That having been said, there's considerable annecdotal evidence that using just "foo" is a mistake. Users assume that the name space is universal, and will do things like tell their colleagues at other companies that their e-mail address is "joe@foo" -- which isn't true, the actual address is "joe@foo.bar.com" The result is upset and confused users -- if they learn to think of their host as "foo.bar.com" they won't make this mistake. [Hunt-and-peck typists will grumble briefly about the extra typing and then write their own shell scripts so they can connect to their favorite hosts by just typing "foo"] Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050305033700> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 09:05:22 PDT Received: from [129.118.224.5] by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with TCP; Mon, 07 May 90 12:05:00 EDT To: TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU In-Reply-To: Your message of Thu, 3 May 90 09:09:18 PDT Subject: ACP basic info... Date: Thu, 03 May 90 11:03:37 cst From: (strick) >The UCLA ACP software is available from UCLA for a $500 handling fee, >it includes most but all of the source code... the JOB Submittal code >is not available in source form as it was funded by IBM Federal Systems >Division. > >I'll be away until the end of the month, if you have any other questions >or wish to secure our code, with the limitations outlined, we can talk >more then. > >-- Denis DeLaRoca > UCLA Office of Academic Computing Thanks for your response. My director has OK'd payment of the $500. I need to find out What language(s) the code is written in. Also, what hardware does the program use to connect to ethernet? Steve Strickland Mgr. Network Services Texas Tech University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050305062300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 2 May 90 22:15:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11066; Wed, 2 May 90 22:06:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 05:06:23 GMT From: barmar@think.com (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: TCP and UDP socket write limits Message-Id: <36029@think.Think.COM> References: <982@dksoft.incom.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <982@dksoft.incom.de> dirk@dksoft.incom.de (Dirk Koeppen) writes: >that SOCK_DGRAM sockets are limited to 1024 byte and SOCK_STREAM are >limited to 4096 byte per write. There are some calls to increase the >SOCK_STREAM buffer size but can I rely that another system will accept >> 4096 byte packets ? Can't I let the kernel do the fragmentation ? There's should be no necessary relationship between kernel buffer size and packet/datagram sizes for stream sockets. Stream sockets are byte streams, and they can be packetized arbitrarily. During TCP connection setup each side tells the other the largest packet size it's willing to accept. Also, while the connection is open windows are increased and decreased to accommodate the receiver's available buffer space. There kernel will have to buffer data and/or block the sending process in order to accommodate the other system's limits. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050305275700> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 3 May 90 18:14:19 PDT Received: from wrs.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA28175; Thu, 3 May 90 21:13:42 -0400 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA21857; Thu, 3 May 90 17:02:32 PDT Received: from daahoud. by yuba.WRS.COM (4.0/SMI-4.0) id AA13233; Thu, 3 May 90 17:07:46 PDT From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) Message-Id: <9005040007.AA13233@yuba.WRS.COM> Received: by daahoud. (4.0/SMI-4.0) id AA06347; Thu, 3 May 90 17:07:58 PDT To: uunet!ucsd.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!@uunet.UU.NET, enea!mats@uunet.UU.NET (Mats Josefsson) Cc: tcp-ip@nic.ddn.mil, hwajin@uunet.UU.NET Subject: Re: The best TCP/IP implementation to base a port on? In-Reply-To: Your message of 30 Apr 90 12:01:47 +0000. <1386@enea.se> Date: Thu, 03 May 90 17:07:57 -0700 > > We're in the process of implementing the TCP/IP protocol suite on a > Motorola 680x0 based system. It is running a Real-Time Operating > system radically different from Unix (more about that below). > what is the name of the OS? i work for wind river systems which develops & sells a realtime OS and development environment called VxWorks for a wide variety of motorola 680x0 based VME SBC's. VxWorks comes complete with 4.3 bsd tahoe tcp/ip, socket interface, NFS client implementation, RPC, etc. > It should be possible to boot our system from a Unix host over > Ethernet (this will require a minimal implementation of ARP/RARP, > BOOTP and TFTP, right?). > you'll definitely need ARP and TFTP (or FTP), but not necessary either BOOTP or RARP unless you don't know your Internet address at the time you boot your machine. if you're putting in the tcp/ip code in your EPROM, when the board powers up you can change the boot parameters (via a command line interface) or just use the default parameters to initialize the network device with a set Internet address, in which case you don't have to use RARP or BOOTP to get boot info. if you don't know the file name your loading or need some vendor specific info at boot time, you'll need to use BOOTP rather than RARP. overall, this is not a hard problem compared to the rest of the work you'll need to do to port/implement tcp/ip on your OS. > 1. Which TCP/IP implementation would be the best to start from? My > understanding is that we could use the 'BSD 4.3-Tahoe' > implementation. It is free (with some restrictions), implements > most of the required functionality, and it is widely used. I'm sure > there are several other alternatives. > the 4.3 bsd tahoe tcp/ip code is one of the best implementation (if not the best). many people are familiar with it and many are still working on some incredible optimization work. > The Real-Time OS we are using supports processes with hard > priorities, messages between processes, shared memory, semaphores, > timers, interrupt handlers etc. It is very fast. Process switch and > message sending takes about ten microseconds (on a 25 MHz MC68020). > gee... this sounds awful familiar to our system (minus tcp/ip and other networking stuff) ... 8-) hwajin bae wind river systems, emeryville, california, usa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050306532400> Received: from ub.d.umn.edu by NIC.DDN.MIL with TCP; Thu, 3 May 90 09:52:41 PDT Received: by ub.d.umn.edu (5.59/UMD-891211) id AA12802; Thu, 3 May 90 11:53:26 CDT From: pdurrant@ub.d.umn.edu (Paul Durrant) Message-Id: <9005031653.AA12802@ub.d.umn.edu> Subject: Re: Is the hostname "foo" or "foo.bar.com"? To: TCP-IP@NIC.DDN.MIL Date: Thu, 3 May 90 11:53:24 CDT In-Reply-To: <9005031635.AA14317@garcon.cso.uiuc.edu>; from "John Chambers" at May 3, 90 3:48 am X-Mailer: Elm [version 2.1 PL1] Mr. Chambers, I'd appreciate learning what responses you get to the question on the subject line. Thanks, Paul Durrant ----MESSAGE-END---- ----MESSAGE-BEGIN---- [800@semto.sem.it] <1990050309031700> From: paolo@semto.sem.it (Paolo Zeppegno) Newsgroups: comp.protocols.tcp-ip Subject: help with ntp Message-ID: <800@semto.sem.it> Date: 3 May 90 09:03:17 GMT Reply-To: paolo@semto.sem.it (Paolo Zeppegno) Organization: Systems & Management (Torino - Italy) Lines: 10 Posted: Thu May 3 10:03:17 1990 Hi, here is a very simple question. I have a very small network, just a couple of machines (more to come real soon now) running ultrix 3.1. I have compiled ntp and I would like to have the clocks in my network synchronized. How do I do it? My brain is probably dead, but the doc is very hard to understand. Keep in mind that I have no access to any reference clock. Thanks a lot in advance. Paolo Zeppegno ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050312321200> Received: from brownvm.brown.edu by NIC.DDN.MIL with TCP; Thu, 3 May 90 13:35:36 PDT Received: from BROWNVM.BROWN.EDU by brownvm.brown.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0059; Thu, 03 May 90 16:34:46 EDT Received: by BROWNVM (Mailer R2.07B) id 6081; Thu, 03 May 90 16:34:45 EDT Date: Thu, 03 May 90 16:32:12 EDT From: Bob Haring-Smith Subject: Tektronix emulation To: TCP-IP@SRI-NIC.ARPA Does anyone know of software permitting Tektronix emulation over tcp/ip? The sorts of connections for which I'm interested in this are PC to MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks. --Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050314195200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 07:48:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA12685; Thu, 3 May 90 07:41:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 14:19:52 GMT From: netnews.upenn.edu!eniac.seas.upenn.edu!tao@rutgers.edu (Chun Tao) Organization: University of Pennsylvania Subject: tn3270 Message-Id: <24477@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for the sources of tn3270 wrote by Mark Solomon from U. of Wisc. (not Berkeley version). Anyone can tell me where I can get this. Please e-mail to tao@eniac.seas.upenn.edu. Thanks. Regards, Chun Tao Chun Tao tao@mickey.nic.kingston.ibm.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005041437.AA03631@ucbvax.Berkeley.EDU] <1990050314501700> From: strick@TTUVM2.TTU.EDU (strick) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP based job submission services.. Message-ID: <9005041437.AA03631@ucbvax.Berkeley.EDU> Date: 3 May 90 14:50:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Thu May 3 15:50:17 1990 > Is there any sites that have a method for IP systems to submit MVS jobs? > > (On most other systems, ftp [or mail!] and some deamons will work..) > >The UCLA ACP implementation of TCP/IP, running on a 3090 under OS/MVS, >supports batch submission via SMTP. > >Bob Braden How can I get more information about UCLA ACP? strick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005032308.AA14782@ucbvax.Berkeley.EDU] <1990050315302300> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: Is the hostname "foo" or "foo.bar.com"? Message-ID: <9005032308.AA14782@ucbvax.Berkeley.EDU> Date: 3 May 90 15:30:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Posted: Thu May 3 16:30:23 1990 John: I think the proper answer to your question is: ``who cares what hostname says?'' Hostname is simply a UNIX program to let you give your host a name. It has no standing in the Internet protocol suite. What the RFCs are about is what comes out of your system. On that subject, they're pretty clear (see RFCs 1122 and 1123). You're supposed to deliver fully qualified domain names to the outside world. If you want to lie internally to your users and call yourself "foo" that's your problem -- just make sure that when the mail comes off your host, it reads "foo.bar.com" That having been said, there's considerable annecdotal evidence that using just "foo" is a mistake. Users assume that the name space is universal, and will do things like tell their colleagues at other companies that their e-mail address is "joe@foo" -- which isn't true, the actual address is "joe@foo.bar.com" The result is upset and confused users -- if they learn to think of their host as "foo.bar.com" they won't make this mistake. [Hunt-and-peck typists will grumble briefly about the extra typing and then write their own shell scripts so they can connect to their favorite hosts by just typing "foo"] Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050319323100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 12:48:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02274; Thu, 3 May 90 12:46:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 May 90 19:32:31 GMT From: new@louie.udel.edu (Darren New) Organization: University of Delaware Subject: Estelle Specifications On-Line Message-Id: <18442@estelle.udel.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This is an announcement of the availability of specifications written in the Estelle formal description technique. These specifications are provided as a public service. The only requirement for obtaining any specifications so available are the following: 1) Your name, organization, state, and country are provided in the request. This is to allow us to send updates and to stay in touch with other users of Estelle. It would be best to specify enough information that anyone worldwide could contact you via postal mail. This list will be distributed only to others on the same list; if you so specify, we will avoid distributing your information at all. 2) Your email address is provided. Contact us if email is inapproriate; we will try to accomodate your needs. 3) You agree to the disclaimer below. We also have various tools and memoranda concerning Estelle. Contact GROPE@UDEL.EDU for details. The NIST also provides an assortment of tools; see below. It is hoped that others will contribute specifications of real-world protocols. Appropriate credit will of course be given and any copyright restrictions will be observed. I hope this will become a major resource in the research and engineering community. In addition, additions to the "people" list and the "biblio" list are welcome. Points of contact at University of Delaware: amer@udel.edu -- Prof. Paul Amer -- Advisor new@udel.edu -- Graphical Representation of Protocols in Estelle chun@udel.edu -- Test Sequence Generation from Estelle chamber@udel.edu -- Adding Broadcast, RendezVous, and Real-Time to Estelle. est-specs@udel.edu -- Currently aliases to new@udel.edu. This is where to send requests for specs. This may eventually become automated or moved to another individual. grope@udel.edu -- Requests about Graphical Representation Of Protocols in Estelle (aka GROPE). Unless otherwise noted in the individual specification, the following conditions are taken to apply: This specification and all derivative works are copyright 1990 by the University of Delaware. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of the copyright holder or author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. BOTH THE AUTHOR AND THE COPYRIGHT HOLDER DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDER OR THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The specifications which are commented as "compilable" means that the specification has been checked and found to be statically correct using the version of PET available 5/1/90 from NIST. It does NOT mean that the specification is an official standard, nor does it mean that the specification is complete or correct relative to the English version of the standard. Even some of the "non-compilable" specs can be compiled with the NBS prototype compiler. WISE is available directly from National Institute of Standards and Technology (NIST, formerly NBS), without whose help GROPE would never have come to be. >From: Rachid Sijelmassi >Organization: National Institute of Standards and Technology (NIST) >Sub-Organization: National Computer Systems Laboratory > >The latest version of WISE is available by anonymous FTP >from osi.ncsl.nist.gov. The code for WISE is part of >the OSIkit package, so you can take all or part of it. >Once you are on osi.ncsl.nist.gov, go to pub/osikit. >You will find the Estelle-to-C compiler (estpc.tar), >the ASN1 tool (asnfvt.tar), Wizard (estwizard.tar), >WISE (estwise.tar) and the manuals (mansrc.tar). Please note that to translate from Estelle to Smalltalk, estwizard.tar will be needed in addition to estwise.tar. Files you should receive: README -- This file biblio -- A bibliographic database of FDT infomation (Scribe/LaTeX format) people -- Other people to whom this has been sent vtp.e -- ISO Virtual Terminal Protocol sess.e -- ISO Session Layer ntp.tex -- RFC1119 Network Time Protocol ip.e -- CLNP in Estelle ab.e -- Alternating Bit (again) bump.e -- R. Tenney's bumpgame fep.e -- The Fact Exchange Protocol Thanks for your interest! -- Darren ------------------------------------------------------------ These people are already on the list and will receive the first batch of specs: alex@comsys.COM -- IF I CAN GET TO YOU! MY HOST DOES NOT KNOW COMSYS.COM dabbous@mirsa.inria.fr thomson@unix.sri.com calvert@cs.utexas.edu mondain@iro.umontreal.ca Others are expected shortly as the result of mailing this announcement to various conference-proceedings lists. Thank you -- Darren ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005040701.AA12937@ucbvax.Berkeley.EDU] <1990050320321200> From: RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Tektronix emulation Message-ID: <9005040701.AA12937@ucbvax.Berkeley.EDU> Date: 3 May 90 20:32:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Posted: Thu May 3 21:32:12 1990 Does anyone know of software permitting Tektronix emulation over tcp/ip? The sorts of connections for which I'm interested in this are PC to MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks. --Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050402302800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 3 May 90 19:47:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27445; Thu, 3 May 90 19:38:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 02:30:28 GMT From: law@louie.udel.edu (Jeff Law) Organization: University of Delaware Subject: Re: Is the hostname "foo" or "foo.bar.com"? Message-Id: <18464@nigel.udel.EDU> References: <9005032308.AA14782@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >John: >I think the proper answer to your question is: > ``who cares what hostname says?'' > >Hostname is simply a UNIX program to let you give your host a name. It >has no standing in the Internet protocol suite. >That having been said, there's considerable annecdotal evidence that using >just "foo" is a mistake. Users assume that the name space is universal, >and will do things like tell their colleagues at other companies that >their e-mail address is "joe@foo" -- which isn't true, the actual address >is "joe@foo.bar.com" The result is upset and confused users -- if they >learn to think of their host as "foo.bar.com" they won't make this >mistake. [Hunt-and-peck typists will grumble briefly about the extra >typing and then write their own shell scripts so they can connect to >their favorite hosts by just typing "foo"] agreed. you wouldnt believe how true this is... we found out the hard way, we've changed all the machines we run to return fully qualified hostnames... interesting side effects are that braindamaged mail agents work much better with the rest of the world now. you will never see a mail message like From: Joe User from any of our machines... whatever you set hostname to will be returned as the official name when gethostname is called.. mucho better! now i wont mention what YP and some braindamaged shell scripts that only looked for unqualified hostnames think of this change :) jeff -- Jeff Law University of Delaware PHONE: (302)-451-8005 work, (302) 731-1462 home E-Mail: law@ee.udel.edu, UUCP: ...!!udel.edu!law ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050406030000> Received: from vx.acs.umn.edu by NIC.DDN.MIL with TCP; Fri, 4 May 90 09:03:09 PDT Date: Fri, 4 May 90 11:03 CDT From: "Paul W. Fakler" Subject: Re: Bad domain name To: tcp-ip@nic.ddn.mil, bobr@dbm1.mpc.af.mil Message-id: <9D496D584DDFE0551B@UMNACVX.BITNET> X-Envelope-to: tcp-ip@nic.ddn.mil X-VMS-To: IN%"tcp-ip@nic.ddn.mil",IN%"bobr@dbm1.mpc.af.mil" >From: Robert Reed >As one of the AF.MIL domain name servers, I have noticed that you are one >of the 100 sites that are sending queries for the address of > > GENTER-ADAM.AF.MIL > >As this name is not in the domain, and has never been, these queries are >a large overhead with no payback. We receive an average of 1500 per hour >just for this host. > >Please help us trace down where these queries are originating from. Any info >will be welcome, address of originating host, or a copy of mail that is >generating the request. I checked out the information in the nameserver on vx.acs.umn.edu, and found a record for GENTER-ADAM.AF.MIL listed as one of the root name servers! > set q=ns > . Server: vx.acs.umn.edu Address: 128.101.63.1 (root) server name = GENTER-ADAM.AF.MIL (root) server name = NS.NASA.GOV ... Unless it happens again, I am assuming for the moment that a typo got into the configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should have been GUNTER-ADAM.AF.MIL. When I restarted the name server, the cache was initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL). Paul Fakler. My cache initialization file follows: ------------------------------------------------------------------------------ $ORIGIN . 99999999 IN NS NS.NIC.DDN.MIL. 99999999 IN NS C.NYSER.NET. 99999999 IN NS NS.NASA.GOV. 99999999 IN NS TERP.UMD.EDU. 99999999 IN NS A.ISI.EDU. 99999999 IN NS AOS.BRL.MIL. ; NS.NIC.DDN.MIL. 99999999 IN A 192.67.67.53 C.NYSER.NET. 99999999 IN A 192.33.4.12 NS.NASA.GOV. 99999999 IN A 128.102.16.10 NS.NASA.GOV. 99999999 IN A 192.52.195.10 TERP.UMD.EDU. 99999999 IN A 128.8.10.90 A.ISI.EDU. 99999999 IN A 128.9.0.107 AOS.BRL.MIL. 99999999 IN A 192.5.25.82 AOS.BRL.MIL. 99999999 IN A 128.20.1.2 -------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050411380000> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Fri, 4 May 90 18:38:44 PDT Received: from SCU.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 4250; Fri, 04 May 90 21:38:34 EDT Date: Fri, 4 May 90 18:38 PDT From: "Henry W. Miller" Subject: Ingres certification of TCP/IP To: tcp-ip@nic.ddn.MIL We are in the process of augmenting our current TCP/IP software with a version that is "Ingres certified". I can't seem to get a decent answer to what this means. Can anyone out there fill me in? Thanks in advance, -HWM ---------- Henry W. Miller U.S. Bureau of Reclamation Assistant Systems Manager, Mid Pacific Region 2800 Cottage Way, MP-1100 Sacramento, CA 95825 (916) 978-5108 / FTS 460-5108 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050413290100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 08:33:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06704; Fri, 4 May 90 08:26:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 13:29:01 GMT From: aecom!naftoli@uunet.uu.net (Robert N. Berlinger) Organization: Albert Einstein College of Medicine Subject: Re: rlogin and security Message-Id: <2832@aecom.yu.edu> References: <9004300749.AA01275@ISIS.U-STRASBG.FR> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9004300749.AA01275@ISIS.U-STRASBG.FR> pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes: > >I know that rlogin is not secure, but its worse than what i thought. >Basically with rlogin anybody can break into your computer (at leasr Sun, >Silicon Graphics,...) provided you have entries in your /etc/passwd with >* as a password. I thought * was used to forbid login, it is quite the >contrary. >Is this a well known Bug of rlogin? Is there a Fix ? I'm running SunOS 4.1 and don't have the same behavior. Perhaps you left the default /etc/hosts.equiv in place, which opens the host to all other hosts in the NIS. -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: ...uunet!aecom!naftoli Scientific Computing Center |CompuServe: 76067.1114@compuserve.com Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050416203600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 09:49:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11217; Fri, 4 May 90 09:38:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 16:20:36 GMT From: stan!dancer!imp@boulder.colorado.edu (Warner Losh) Organization: Solbourne Computers Inc. Subject: Re: Is the hostname "foo" or "foo.bar.com"? Message-Id: <1990May4.162036.25762@Solbourne.COM> References: <9005032308.AA14782@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >[Hunt-and-peck typists will grumble briefly about the extra >typing and then write their own shell scripts so they can connect to >their favorite hosts by just typing "foo"] Most TCP/IP's that I have abused (er ah used) have a feature that lets you say telnet foo when you mean telnet foo.bar.com. That is they add the current domain to the name if there are no dots (some do even if there are). Others there is a list of domains to append to the hostname when trying. The only draw back to doing a "hostname foo.bar.com" in your rc.local (or where ever) file is that the default csh prompt is "foo.bar.com% " rather than "foo% ". Warner Losh imp@Solbourne.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050416271300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 21:23:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22394; Fri, 4 May 90 21:04:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 16:27:13 GMT From: mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net (Daniel Huber) Organization: Ascom Autelca AG, CH-3073 Guemligen Switzerland Subject: Connect AS/400 and UNIX (TCP/IP). HOW? Message-Id: <1285@telsys.aut.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi We have some UNIX Computers : 30 Sun's (SunOS 4), 34 HP's (HP-UX 7.0), 2 NCR's (SysV.2), 2 Plexus (SysV.2), some PC's (Interactiv UNIX), about 50 Mac's (MultiFinder) and about 120 PC's (MSDOS). All are connected together with ETHERNET 802.3 (TCP/IP). Some Mac's with AppleTalk (there is actually a GatorBox in test for AppleTalk - TCP/IP connectivity). Then I have an AS/400 and 2 System/36. ;-( My problem is: How can I connect the AS/400 and /36's to the UNIX-TCP/IP world. I've tried with an ASTEK-Box (Mytek). Works ok (ftp, telnet), but we need more. We want something like NFS. How can I realise that. - Is it true that AS400 supports TCP/IP ? - Can I directly connect an AS400 to 802.3 ? - Is there a product for "NFS" filesystems, from and to AS400 ( UNIX <-> AS400) ? - I heard something about OS/2 EE 1.2. What's that ? (could be a similar thing as OS/2-LanManager for sharing AS400 disk with OS/2-PC's ? Or perhaps a gateway between SNA and TCP/IP ?) - If OS/2 EE is a software (like LanManager), does it run with Microsoft's LanManager for OS/2, so I'm able to export AS400 directories via OS/2 EE and OS/2-LanManager to LanManager/X an then to other users. Utopia ? Who knows ? Please e-mail, if you can help me. Thanks Daniel -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 77 45 CH-3073 Guemligen email: huber@aut.uucp Switzerland uucp: uunet!mcsun!cernvax!hslrswi!aut!huber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050418020000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 23:20:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29106; Fri, 4 May 90 23:13:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 18:02:00 GMT From: usc!snorkelwacker!spdcc!xylogics!transfer!lectroid!jjmhome!cpoint!frog!barr@ucsd.edu (Chris Barr) Organization: Charles River Data Systems Subject: /etc/hosts used for 2 protocols' addresses Message-Id: <14508@frog.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'd like to use an IP-format /etc/hosts file to lookup network addresses used by a another protocol run on the same host. (The addresses happen to be Ethernet card hardware addresses.) I wonder if anyone else has faced this question of entering a second network address in /etc/hosts. TCP/IP will continue to use the same /etc/hosts file. The simplest extension seems to be using the comment field for the 2nd protocol's address ---------------- | v nnn.nnn.nnn.nnn name name ... # 0xnn0xnn0xnn0xnn0xnn0xnn A new entry in /etc/protocols doesn't make sense, because this protocol doesn't use IP. Thanks, in advance, for any comments. barr@frog {!harvard !mit-eddie} !frog!barr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050420371900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 14:34:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28883; Fri, 4 May 90 14:21:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 20:37:19 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Tektronix emulation Message-Id: <2641E7FF.3E13@intercon.com> References: <9005040701.AA12937@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) writes: > Does anyone know of software permitting Tektronix emulation over tcp/ip? > The sorts of connections for which I'm interested in this are PC to > MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks. > --Bob There are a couple of packages that you might want to look at. One is the NCSA telnet for the PC and Mac that does tektronix 4014 emulation. Our product TCP/Connect II does 4014 emulation on the PC and Mac, as well as IBM 3278 emulation. We also have a package called InterCon Telnet Driver which runs on the Mac and allows VersaTerm Pro (tek 4105 emulation) and MicroPhone II to run over a telnet session. You can get NCSA telnet from zaphod.uiuc.edu (I believe). You can get info on TCP/Connect II and the Telnet Driver by dropping a note to comment@intercon.com or to me. Hope that helps.-- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050421573100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 15:04:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01303; Fri, 4 May 90 14:58:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 21:57:31 GMT From: swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!mike@ucsd.edu (Mike Trogni) Organization: University of Illinois at Urbana Subject: Re: NCSA Telnet availability Message-Id: <1990May4.215731.5512@ux1.cso.uiuc.edu> References: <9005040701.AA12937@ucbvax.Berkeley.EDU>, <2641E7FF.3E13@intercon.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2641E7FF.3E13@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes: > >You can get NCSA telnet from zaphod.uiuc.edu (I believe). > actually its available from ftp.ncsa.uiuc.edu which is Cname for zaphod.ncsa. uiuc.edu (128.174.20.50). - mike -- mike@uxa.cso.uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050423274100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 17:18:49 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08646; Fri, 4 May 90 17:04:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 May 90 23:27:41 GMT From: phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho) Organization: Cognitive Science Lab. Princeton University. Subject: PPP ?? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm not sure if these are the right newsgroups to send to but I'm interested in knowing current developments concerning PPP. I would be very much appreciated if anyone can give me any pointers on this. -- Eric Ho Princeton University eho@clarity.princeton.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050501165100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 5 May 90 02:34:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08031; Sat, 5 May 90 02:31:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 01:16:51 GMT From: excelan!manoj@ames.arc.nasa.gov (manoj @ Prod Mktg) Organization: Novell Inc., San Jose CA. Subject: Re: Tektronix emulation Message-Id: <1306@excelan.COM> References: <9005040701.AA12937@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005040701.AA12937@ucbvax.Berkeley.EDU>, RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith) writes: > Does anyone know of software permitting Tektronix emulation over tcp/ip? > The sorts of connections for which I'm interested in this are PC to > MicroVax or VaxStation, Mac to IBM Mainframe, and PC to RT. Thanks. A number of coompanies offer tektronix term. emulators that write to int14 or int6b and can be used as is on top of tcp/ip networks that have int14 & 6b support.. With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the 3rd party term emulators.. walker richer quinn, seattle, WA kea systems, vancouver , canada softronics, grafpoint, saratoga, ca persoft, polygon, diversified computer systems thx.. 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" __ ((__ \ \\ ! !!! o_@@--.\ (___, / ___! ! Regards! / .-! ! _) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050501231500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 22:19:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26170; Fri, 4 May 90 22:13:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 01:23:15 GMT From: van-bc!mplex!fff@ucbvax.Berkeley.EDU (Fred Fierling) Organization: Microplex Systems Ltd Subject: Re: The best TCP/IP implementation to base a port on? Message-Id: <445@mplex.UUCP> References: <1386@enea.se>, <9005040007.AA13233@yuba.WRS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005040007.AA13233@yuba.WRS.COM>, hwajin@yuba.UUCP (Hwa Jin Bae) writes: > > 1. Which TCP/IP implementation would be the best to start from? My > > understanding is that we could use the 'BSD 4.3-Tahoe' > > implementation. It is free (with some restrictions), implements From where can you get BSD 4.3-Tahoe TCP/IP? -- Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 Microplex Systems Ltd 265 East 1st Avenue Vancouver, BC V5T 1A7, Canada ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005050253.AA18113@ucbvax.Berkeley.EDU] <1990050501380000> From: HMILLER@SCU.BITNET ("Henry W. Miller") Newsgroups: comp.protocols.tcp-ip Subject: Ingres certification of TCP/IP Message-ID: <9005050253.AA18113@ucbvax.Berkeley.EDU> Date: 5 May 90 01:38:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Posted: Sat May 5 02:38:00 1990 We are in the process of augmenting our current TCP/IP software with a version that is "Ingres certified". I can't seem to get a decent answer to what this means. Can anyone out there fill me in? Thanks in advance, -HWM ---------- Henry W. Miller U.S. Bureau of Reclamation Assistant Systems Manager, Mid Pacific Region 2800 Cottage Way, MP-1100 Sacramento, CA 95825 (916) 978-5108 / FTS 460-5108 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005050218.AA16274@ucbvax.Berkeley.EDU] <1990050502191000> From: CCECHAN@NUSVM.BITNET (Luther Chan) Newsgroups: comp.protocols.tcp-ip Subject: How to turn RIP off in Sun 3/50?? Message-ID: <9005050218.AA16274@ucbvax.Berkeley.EDU> Date: 5 May 90 02:19:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Sat May 5 03:19:10 1990 X-Unparsable-Date: Sat, 05 May 90 09:17:48 SST Dear Networkers, Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Please tell where is the file contain the switch and the file name. Thank you in advance! Luther ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050502195200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 20:04:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18215; Fri, 4 May 90 19:54:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 02:19:52 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Is the hostname "foo" or "foo.bar.com"? Message-Id: <59362@sgi.sgi.com> References: <376@minya.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <376@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > It's easy to show that BSD systems (and sendmail) require that the first > field of the localhost's entry by the same as the output of the hostname > command. I know of a few thousand hosts running 4.3BSD networking code and sendmail which violate this rule, and send and receive mail all over the Internet, UUCP, BITNET, and beyond. These machines are configured so that `hostname` returns "foo", but the moral equivalent of gethostbyname("foo") returns an pointer to foo.bar.com as the first name. Vernon Schryver vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050502294100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 19:49:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17203; Fri, 4 May 90 19:35:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 02:29:41 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@ucsd.edu (Don Lewis) Organization: Harris Semiconductor, Melbourne FL Subject: Re: Bad domain name Message-Id: <1990May5.022941.14069@mlb.semi.harris.com> References: <9D496D584DDFE0551B@UMNACVX.BITNET> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9D496D584DDFE0551B@UMNACVX.BITNET> PWF@VX.ACS.UMN.EDU ("Paul W. Fakler") writes: >>From: Robert Reed >>As one of the AF.MIL domain name servers, I have noticed that you are one >>of the 100 sites that are sending queries for the address of >> >> GENTER-ADAM.AF.MIL >> >>As this name is not in the domain, and has never been, these queries are >>a large overhead with no payback. We receive an average of 1500 per hour >>just for this host. >> >>Please help us trace down where these queries are originating from. Any info >>will be welcome, address of originating host, or a copy of mail that is >>generating the request. > >I checked out the information in the nameserver on vx.acs.umn.edu, and found >a record for GENTER-ADAM.AF.MIL listed as one of the root name servers! > >> set q=ns >> . >Server: vx.acs.umn.edu >Address: 128.101.63.1 > >(root) server name = GENTER-ADAM.AF.MIL >(root) server name = NS.NASA.GOV >... > >Unless it happens again, I am assuming for the moment that a typo got into the >configuration file on one of the root servers, and GENTER-ADAM.AF.MIL should >have been GUNTER-ADAM.AF.MIL. When I restarted the name server, the cache was >initialized correctly (and had a root server record for GUNTER-ADAM.AF.MIL). Ah, GENTER-ADAM.AF.MIL is back again. I haven't seen that one in a couple of months. Last week it was SRI-NIC.ARPA and BRL-AOS.ARPA. I don't think the fault lies with the root name servers, it is mainly due to misconfiguration the name servers for some of the subdomains, typically in-addr.arpa subdomains. Let's say that hosts X and Y are listed as the name servers for xxx.128.in-addr.arpa. Now lets assume that Y thinks that GENTER-ADAM is one of the root name servers. If host Z queries host Y for the PTR record for aaa.bbb.xxx.128.in-addr.arpa, and host Y is *not* actually a name server for xxx.128.in-addr.arpa, then host Y will respond with a referral message. In this example the message will contain an empty answer section, a list of the root name servers in the authority section, and the addresses of these name servers in the additional section. Now host Z will believe that GENTER-ADAM.AF.MIL is a root name server. If Z is also listed as a name server for a zone that it is not actually a server for, it will in turn pass on this information. I have also observed hosts returning a list of the root name servers in the authority section when in fact they are authoritative name servers for the domain, but I don't know whether this is due to broken software or some other type of misconfiguration. Let's stamp out DTB's (DNS Transmitted Bogosities)! Now as far as the large number of queries to the root name servers is concerned, there appears to be a nasty bug in BIND 4.8.1, and probably other versions as well. When a resolver is referred to a name server in order to the answer a query and it does not have the address of the name server, the resolver must start a second query for the address of the name server. In BIND, if the result of the query for the address of the name server is a CNAME, it is not smart enough to follow the CNAME to get the address. If the result is NXDOMAIN, this information is not cached. Now if one of the name servers that BIND doesn't have an address for is one of the *root* name servers, this will probably happen quite a lot considering that BIND has to consult the root name servers in order to look up the address of one of the root servers. It gets worse if there are other problems, like unreachable name servers if BIND's clients don't understand how to correctly deal with temporary failure and keep retrying. I've seen its rubber band get wound pretty tight. I keep hearing rumors of a new version of BIND, but I haven't seen any official word. Having negative caching and a few bug fixes would help the situation a lot. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050506472000> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 6 May 90 02:13:06 PDT Received: from wrs.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA12299; Sat, 5 May 90 22:22:13 -0400 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA05165; Sat, 5 May 90 18:21:45 PDT Received: from daahoud. by yuba.WRS.COM (4.0/SMI-4.0) id AA08860; Sat, 5 May 90 18:27:13 PDT From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) Message-Id: <9005060127.AA08860@yuba.WRS.COM> Received: by daahoud. (4.0/SMI-4.0) id AA05885; Sat, 5 May 90 18:27:21 PDT To: uunet!ucbvax.Berkeley.EDU!van-bc!mplex!fff@uunet.UU.NET (Fred Fierling) Cc: tcp-ip@nic.ddn.mil Subject: Re: The best TCP/IP implementation to base a port on? In-Reply-To: Your message of 05 May 90 01:23:15 +0000. <445@mplex.UUCP> Date: Sat, 05 May 90 18:27:20 -0700 > >From where can you get BSD 4.3-Tahoe TCP/IP? > -- > Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 via anonymous ftp or uucp from uunet machine. look under the directory: /usr/spool/ftp/bsd-sources hwajin wind river systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050511174800> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 4 May 90 18:18:43 PDT Received: from NUSVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8304; Fri, 04 May 90 21:18:17 EDT Received: by NUSVM (Mailer R2.03B) id 4172; Sat, 05 May 90 09:20:39 SST Date: Sat, 05 May 90 09:17:48 SST From: Luther Chan Subject: How to turn RIP off in Sun 3/50?? To: Vivian Neou Dear Networkers, Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Please tell where is the file contain the switch and the file name. Thank you in advance! Luther ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050513422400> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Sun, 6 May 90 00:53:06 PDT Received: from PUCC.PRINCETON.EDU by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2065; Sat, 05 May 90 17:55:42 EDT Received: by PUCC (Mailer R2.07) id 4184; Sat, 05 May 90 17:55:46 EDT Date: Sat, 05 May 90 17:42:24 EDT From: "Lee C. Varian" Subject: Re: IP based job submission services.. To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Wed, 2 May 90 14:21:59 CDT from On Wed, 2 May 90 14:21:59 CDT said: >Now along comes a user who wants to do "batch" processing. He'd like to >"submit" a job to another system. Imagine his surprise to find no popular >IP service for this. He protests the "new" network and in order to avoid >deinstalling the entire net, the organization quickly establishshes a RJE >network (or equivalent) of sync lines between the very same host. John, Another approach is simply to run NJE as an application on top of TCP/IP. This is being done by about 100 sites worldwide, using the BITNET II protocol (for NJE over TCP) developed at Princeton University and implemented for IBM VM systems by Princeton University (VMNET); for VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University (UREP TCP/IP) and Technion-Haifa. Lee Varian lvarian@pucc.princeton.edu Princeton University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050517180000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 6 May 90 03:52:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20487; Sun, 6 May 90 03:44:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 17:18:00 GMT From: ogicse!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!gupta@ucsd.edu Subject: protocol tester wanted Message-Id: <13000006@ux1.cso.uiuc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for a C package that can be used to test various protocols over a network. I'm currently trying to port x-kernel, but am wondering if there are any other packages (preferably ones that don't simulate an entire kernel!) that will do the job. Please email all replies to rohit@uiuc.edu because I do not read this group. Thanks in advance! Rohit NOTE: this is being cross-posted to a couple of groups, my apologies if you see it more than once... ------------------------------------------------------------------------------- Internet:rohit@uiuc.edu UUCP:uunet!uiucuxc!ux1!gupta BITnet:GUPTA@UIUCVMD "There are no good wars, with the following exceptions: the American Revolution, World War II, and the Star Wars Trilogy..." -- Bart Simpson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050519181100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 6 May 90 01:09:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05966; Sat, 5 May 90 12:21:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 May 90 19:18:11 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: Bridges not passing bcasts (update) Message-Id: <1990May5.121811.1@rogue.llnl.gov> References: <7594@uswat.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <7594@uswat.UUCP>, matthews@uswat.uswest.com (John Matthews) writes: > Please give a little detail if possible. What other bridges does everyone > know about that learn these bad source addresses? I can also confirm the reports, but what you really need to know is that this bad behaviour is the result of a bug in V2.0 ROMs. If you get your ROMs updated, the problem will go away. 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005061028.AA19477@ucbvax.Berkeley.EDU] <1990050521422400> From: LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian") Newsgroups: comp.protocols.tcp-ip Subject: Re: IP based job submission services.. Message-ID: <9005061028.AA19477@ucbvax.Berkeley.EDU> Date: 5 May 90 21:42:24 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Sat May 5 22:42:24 1990 On Wed, 2 May 90 14:21:59 CDT said: >Now along comes a user who wants to do "batch" processing. He'd like to >"submit" a job to another system. Imagine his surprise to find no popular >IP service for this. He protests the "new" network and in order to avoid >deinstalling the entire net, the organization quickly establishshes a RJE >network (or equivalent) of sync lines between the very same host. John, Another approach is simply to run NJE as an application on top of TCP/IP. This is being done by about 100 sites worldwide, using the BITNET II protocol (for NJE over TCP) developed at Princeton University and implemented for IBM VM systems by Princeton University (VMNET); for VMS systems by Joiner Associates (JNET TCP NJE) and Hebrew University of Jerusalem (HUJI-NJE); and for Berkeley Unix systems by Harvard University (UREP TCP/IP) and Technion-Haifa. Lee Varian lvarian@pucc.princeton.edu Princeton University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050620503800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 6 May 90 23:24:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17706; Sun, 6 May 90 22:56:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 May 90 20:50:38 GMT From: minya!jc@eddie.mit.edu (John Chambers) Subject: Re: Is the hostname "foo" or "foo.bar.com"? Message-Id: <380@minya.UUCP> References: <9005032308.AA14782@ucbvax.Berkeley.EDU>, <18464@nigel.udel.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <18464@nigel.udel.EDU>, law@udel.EDU (Jeff Law) writes: > In article <9005032308.AA14782@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: > >John: > >I think the proper answer to your question is: > > ``who cares what hostname says?'' For starters: sendmail, rsh, rcp, telnet, gethostbyname(), ... > >Hostname is simply a UNIX program to let you give your host a name. It > >has no standing in the Internet protocol suite. If true, then how could SMTP ever possibly work? One of the documentable anomalies is host foo.bar.com calling bletch.org's SMTP port, and one of them rejecting the other because they disagree on the hostname convention. If there were a paragraph in an RFC I could point to, perhaps I could say "All you guys doing it *that* way are wrong." But it looks like I can't say that, so the turkeys will continue insisting they're right, and the anomalies will continue. > agreed. you wouldnt believe how true this is... we found out the hard way, > we've changed all the machines we run to return fully qualified hostnames... > > now i wont mention what YP and some braindamaged shell scripts that only > looked for unqualified hostnames think of this change :) But this is the whole point of the question. Personally, I think that any software that can't handle both conventions is braindamaged. But I can't correct them all; I don't have the time or the source code. Perhaps I could ask it this way: Suppose we were to uniformly adopt one convention of the other. Is there a straighforward way to identify the programs that have problems with it, and diddle their config files so they work correctly? If this can be answered for one convention or the other, that would also answer the original question, at least for pragmatists like me. BTW, are you aware that there are systems being sold that limit hostnames (sometimes doubling as sysnames or nodenames) to 16 bytes? -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc -- If you're not part of the solution, you're part of the precipitate. [Kiel oni ^ci tiun diras esperante?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050623084100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 6 May 90 16:23:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26705; Sun, 6 May 90 16:14:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 May 90 23:08:41 GMT From: phri!news@nyu.edu (Roy Smith) Organization: Public Health Research Institute, New York City Subject: How to discover current list of DNS root servers Message-Id: <1990May6.230841.11143@phri.nyu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil If I want to find out the most current list of DNS root servers, does it suffice to run nslookup and do the following? > server suspected.root.server > set type=ns > . -- 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!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050706043600> Received: from IBM.COM by NIC.DDN.MIL with TCP; Mon, 7 May 90 12:37:54 PDT Received: from rchland by IBM.COM (IBM VM SMTP R1.2.1MX) with BSMTP id 6961; Mon, 07 May 90 12:37:58 PDT Received: from po1.rchland.ibm.com by RCHGATE.rchland.ibm.com (IBM VM SMTP R1.2.1) with TCP; Mon, 07 May 90 14:25:56 CDT Received: by po1.rchland.ibm.com (5.51/4.7) id for tcp-ip@nic.ddn.mil; Mon, 7 May 90 14:24:51 CDT Received: via switchmail; Mon, 7 May 90 14:24:51 -0500 (CDT) Received: from resolute.rchland.ibm.com via qmail ID ; Mon, 7 May 90 14:24:42 -0500 (CDT) Received: from resolute.rchland.ibm.com via qmail ID ; Mon, 7 May 90 14:24:39 -0500 (CDT) Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.resolute.rchland.ibm.com.rt.aix221 via MS.5.6.resolute.rchland.ibm.com.rt_aix221; Mon, 7 May 90 14:24:36 -0500 (CDT) Message-Id: Date: Mon, 7 May 90 14:24:36 -0500 (CDT) From: Wayne Richardson To: tcp-ip@nic.ddn.mil Reply-To: Subject: Re: Connect AS/400 and UNIX (TCP/IP). HOW? In-Reply-To: <1285@telsys.aut.UUCP> References: <1285@telsys.aut.UUCP> Daniel, In response to your specific questions: 1) Yes, there is a new LP for the AS/400 called TCP/IP Connectivity Utilities. It started shipping 1/26/90. The S/36 is still only available through Business Partners (like Mytek). 2) The AS/400 only attaches through 802.5 (Token-Ring) in the initial release, but native Ethernet V2 and 802.3 are coming very soon (there are SOD's for them now). 3) NFS Server is also a Statement-of-Direction, but is farther out than 802.3. For everyone, there is an excellent list of all the IBM platforms and what they support in the way of TCP/IP, OSI, LU6.2, etc. It is a list that came out when the RS/6000 was announced and is titled, "IBM Interoperability for SAA and AIX environments". The Date on it is 900215, and the Number is 290-070. It talks about everything from SAA compilers to SNMP to X.400 and should be available through the IBM branches. It may answer a lot of questions like yours. Bob Dick TCP/IP DCG 51E/015-2, (507) 253-3014 Rochester, Minnesota 55901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050709260100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 06:39:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08960; Mon, 7 May 90 06:30:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 09:26:01 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) Organization: TNO Institute for Perception, Soesterberg, The Netherlands Subject: A SUSPICIOUS SECURE GATEWAY Message-Id: <1158@tnosoes.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I modified a version of Phil Karns KA9Q internet package so it acts as a suspicious secure gateway. The goal of this gateway is to establish security of a local network at the gateway instead of securing every host on your local network. One would for example disallow excess to rlogin, rsh, ftp and telnet because many users have bad passwords. I'll make the binary and sources available to those who are interested. The README follows. (start reading at 'Security Features' if you are only interested in the secure gateway extensions) I would like to receive suggestions and comments about this package. ===================================================================== Microsoft C 4.00 Changes to KA9Q ================================ The assembler files are translated to a format suitable for the MASM assembler. The clocktick rate has been increased from 1 tick per second to 10 ticks per seconds. (This is useful for fast transmission paths like ethernet). A little bug in the ping command (Concerning echo timing) has been fixed. One can now specify TCP receive window and mss sizes which are different from the send sizes. The is needed for dumb ethernet cards (3C501, 3C503) which are easily overrun when a fast TCP peer (e.g. a Sun) sends bursts of ethernet packets. 'tcp rwin 512' and 'tcp rmss 512' are appropriate values. Some little improvements has been made to the TCP timeout mechanisms. The file 'autoexec.net' is now searched for in the working directory and subsequently in the root. (This allows easy customization for different users). Command line arguments are now interpreted as NET commands. (It used to be the name of a startup file). These commands are executed after the default startup file has been read. Multiple command may be given when delimited by ';'. The FTP server now recognizes printer names, so you can use NET as a print server. (e.g.: put text lpt1). Function keys are transmitted as \033[ sequences. (Useful for emacs, etc). Four additional commands has been added: funkeys [on|off] funkeys on will disable Functionkey-10 so one can use emacs. Abort is by means of CTRL-FN10 when funkeys are on. rsh host command will execute a shell command on the specified host by means of the rexecd(8) or rshd(8) daemon. uprsh file host command acts like rsh but gives file as standard input. buprsh file host command acts like rsh but gives binary file as standard input. Before a rsh command may be given you should identify yourself by means of the name command. ("name username password" or "name username RSH localname" for use of rshd instead of rexed). examples: DOS PROMPT> net rsh rainbow date will show the date on the unix host rainbow and return to DOS. DOS PROMPT> net uprsh \mail\greeting rainbow mail tom will mail the contents of DOS-file \mail\greeting to tom from host rainbow. DOS PROMPT> net buprsh \dos\del.com rainbow cat ">" binfile will copy the contents of DOS-file \dos\del.com to "binfile" in your home directory on host rainbow. A new server has been added. This server allows a tcp-stream to a serial line (COMx) or the screen of a PC. (Could be used for a remotely accessible printer). start com 20000 1 silent This starts the server which listens on port 20000 and directs all incoming data to the first attached serial line. (Use 0 for the screen). In the attach command one should specify the COM-port, baudrate, etc. (E.g.: "attach asy 0x3f8 4 slip sl0 1024 576 9600"). If the fourth argument is omitted then diagnostic output will be printed on the screen. (E.g.: "Incoming com session from.....") A WD8003E ethernet driver has been added. This version of the KA9Q internet package has been tested on a IBM-AT communicating with Suns running SunOS 3.2/3.5/4.0.3 and Masscomps. Slip has also been tested. SMTP mail has been tested. The log command now has an onscreen option which duplicates messages on the screen. The logfile is now cyclic and will be rewritten after 500kB of messages. When net is started it will begin writing at the start of the logfile. The best strategy is to start with a logfile with a (random) contents of about 501kB. This will garantee that messages can be logged even if the disk is completely full. The NET program can act as a real gateway by giving an ethernet interface a different IP address: gateway ec0 [131.34.2.8] On this gateway interface is only ping (= ICMP Echo Request) allowed. SECURITY Features ================= This version of net can act as a secure gateway between a local net and an external IP network. It allows connections to be initiated from the local network(s) to the external network(s) but it disallows all connection attempts from the external networks(s) the the local network(s). Note that the gateway itself is always accesible over all interfaces. So it can act as FTP server for the external insecure networks. (This has ofcourse a negative impact on its performance as a secure internetwork router.) Be carefull to configure the file '\ftpusers` before you start FTP service with the 'start ftp' command. Disallow access to the root directory or the NET binary! The insecure external network interface has to be attached with a name that starts with 'Se' (Secure). The local network(s) has to be specified with the command: secure localnet [/] Example: secure localnet [140.24.67]/24 This will add the specified network to the list of protected (local) networks. The protection is established by examination of packets which enter the network over the 'Secure' interface: 1: == A packet which has an IP-source which matches one of the specified local networks is considered a faked packet and is simply dropped. A warning is written in the logfile. 2: == Every UDP packet with a port destination number < 1024 is rejected with an ICMP Port Unreachable message. 3: == Every TCP packet with a port destination number < 1024 is rejected with an ICMP Port Unreachable number. 4: == ICMP redirect packets are dropped. 5: == Source Routed packets are rejected with an ICMP Parameter Problem. Local networks (or hosts) can be completely isolated from the external networks by specifying a 'sink' route. The will reject EVERY packet with an IP-source or IP-destination that matches the specified sink route with an ICMP Host Unreachable message. Example: route add lonely sink route add [140.24.67.128]/25 sink A local network can be completely isolated with the exception of 1 or more specific hosts by: route add [197.25.45.0]/25 sink route add [197.25.45.128]/25 sink route add [197.25.45.212] ec0 route add [197.25.45.213] ec0 Tracing ======= The command: secure trace on will trace incoming packets on the 'Secure' interface. Remember that turning trace on has a negative impact on routing performance. Creating (dangerous) exceptions =============================== It is possible to allow TCP connections to special hosts in order to establish anonymous FTP connections or incoming mail. This can be very dangerous because many older Unix FTP- and SMTP- (= sendmail) daemons have dangerous security holes. A safe alternative is to use a PC which runs this NET program as anonymous FTP server. Many mail SMTP (and FTP) daemons have the famous Morris internet worm holes. Do not allow connections until you are certain that your version is secure. The safest way to assure this is to install the latest Berkeley sendmail and ftpd sources which are publicly available. The use of mail-aliases which resolve to programs (like |uudecode) is also considered insecure. This is an extract of: =============================================================================== CERT Advisory March 19, 1990 Internet Intruder Warning ------------------------------------------------------------------------------- 3) Exploit holes in sendmail. Make sure you are running the latest sendmail from your vendor. BSD 5.61 fixes all known holes that the intruder is using. 4) Exploit bugs in old versions of FTP; exploit mis-configured anonymous FTP Make sure you are running the most recent version of FTP which is the Berkeley version 4.163 of Nov. 8 1988. Check with your vendor for information on configuration upgrades. Also check your anonymous FTP configuration. It is important to follow the instructions provided with the operating system to properly configure the files available through anonymous ftp (e.g., file permissions, ownership, group, etc.). Note especially that you should not use your system's standard password file as the password file for FTP. 9) Examine the /usr/lib/aliases (mail alias) file for unauthorized entries. Some alias files include an alias named 'uudecode'; if this alias exists on your system, and you are not explicitly using it, then it should be removed. =========================End of extract=============== After you have convinced yourself that your Unix servers are really secure you can execute an secure allow command. Example: secure allow mailhost TCP 25 This will allow TCP connections to be established over the Secure interface to tcp port 25 on host 'mailhost'. 25 is the TCP port number of the SMTP mail daemon. The general syntax is: secure allow [source-host] If no source-host is specified then it defaults to ALL. RPC-UDP specifies a filter which examines UDP packets and determines if these packets are RPC calls to a RPC based server. The port number contains the RPC program number which should be filtered. Example: sec allow ALL RPC-UDP 100012 ALL One can also specify disallows: secure disallow [source-host] Example: secure disallow ALL RPC-UDP ALL NOTE that 'disallow' specifiers always overrule 'allow' specifiers except 'allows' which have specified all four fields without any 'ALL' wildcard. =============================================================================== Tom Vijlbrief TNO Institute for Perception P.O. Box 23 Phone: +31 34 63 562 11 3769 ZG Soesterberg E-mail: tnosoes!tom@hp4nl.nluug.nl The Netherlands or: uunet!hp4nl.nluug.nl!tnosoes!tom =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050709462100> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 12:34:40 PDT Received: from CLSEPF51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3278; Mon, 07 May 90 13:29:39 EDT Date: Mon, 7 May 90 11:26:21 N From: virchaux%CLSEPF51.BITNET@CUNYVM.CUNY.EDU (Jacques Virchaux) Message-Id: <900507112639.5a0@SIC.Epfl.CH> Subject: Upgrade kit LAN100 -> LAN150 To: tcp-ip@nic.ddn.mil X-ST-Vmsmail-To: GW::"tcp-ip@nic.ddn.mil" Does anyone know if there is a kit available to upgrade a LanBridge 100 to a LanBridge 150. DEC offers an exchange rather expensive and there are only two PROMs to change and one wire to add ! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050712543200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 06:08:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07168; Mon, 7 May 90 05:54:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 12:54:32 GMT From: daemon@tut.cis.ohio-state.edu (Bob Dixon) Subject: IBM Batch Job Submission via tcp/ip Message-Id: <80147@tut.cis.ohio-state.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The ACC implementation of tcp/ip (called Access/Mvs) allows easy submission of batch jobs via ftp, using the "site submit" option. Bob ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050714394200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 09:40:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19569; Mon, 7 May 90 09:35:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 14:39:42 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu (Bryan Beecher) Organization: U of Michigan, ITD Research Systems Subject: Re: How to discover current list of DNS root servers Message-Id: <1990May7.143942.23249@terminator.cc.umich.edu> References: <1990May6.230841.11143@phri.nyu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: > > If I want to find out the most current list of DNS root servers, >does it suffice to run nslookup and do the following? > >> server suspected.root.server >> set type=ns >> . The only way to make sure you've got the current list of root servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from the NIC. The suspected.root.server could have all kinds of bogus NS RR's for root in its cache along with the list of correct ones (which could be incomplete or incorrect itself). -- Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) Domain: bryan@terminator.cc.umich.edu Path: mailrus!terminator!bryan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050716135300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 12:10:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29008; Mon, 7 May 90 12:04:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 16:13:53 GMT From: mcsun!cernvax!chx400!hslrswi!aut!huber@uunet.uu.net (Daniel Huber) Organization: Ascom Autelca AG, CH-3073 Guemligen Switzerland Subject: UUCP over TCP/IP with HP9000/835S (HP-UX 7.0) ????? Message-Id: <1294@telsys.aut.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I tried to set up uucp connections to other computers on our ethernet. But UUCP over TCP/IP seems not working with HP-UX 7.0 and 835S. I have HDB on both sides, or uucp version 2. HP9000/835S called is "aut" (HDB), other machine is NCR Tower 650 SysV.2 (HDB) called "telsys", or a Plexus P75 SysV.2 (uucp V2) called "autte". Here are my File entrys: Systems: telsys Any telsys Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp autte Any autte Any nophone "" \d "" \r ogin: nuucp ssword: uucpuucp Devices: I tried many different entrys telsys - - Any TCP or telsys TCP - Any TCP or telsys TCP - - TCP and more.... (similar entrys for autte) Permissions: #entry for system called "telsys" MACHINE=telsys LOGNAME=nuucp \ SENDFILES=yes REQUEST=yes CALLBACK=no \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ COMMANDS=rmail:uux:uucp:pr #entry for system called "autte" MACHINE=autte LOGNAME=nuucp \ SENDFILES=yes REQUEST=yes CALLBACK=no \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic \ COMMANDS=rmail:uux:uucp:pr And that's what Uutry means: # ~uucp/Uutry -r telsys /usr/lib/uucp/uucico -r1 -stelsys -x5 >/tmp/telsys 2>&1& tmp=/tmp/telsys mchFind called (telsys) conn(telsys) Device Type telsys wanted mlock - succeeded generic open failed, errno = 9 getto ret -1 Call Failed: CAN'T ACCESS DEVICE exit code 101 Conversation Complete: Status FAILED What's wrong? Does HP not support UUCP over TCP/IP ? Please e-mail, if you can help me. Thanks Daniel -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 77 45 CH-3073 Guemligen email: huber@aut.uucp Switzerland uucp: uunet!mcsun!cernvax!hslrswi!aut!huber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050716231600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 17:59:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21798; Wed, 9 May 90 17:51:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 16:23:16 GMT From: hpfcso!hpldola!hpctdlb!hpctdkp!jeff@hplabs.hp.com (Jeff Hughes) Organization: Hewlett-Packard CTD, Colo. Spgs. Subject: Re: Re: question about caching in UDP based RPC Message-Id: <3270023@hpctdkp.HP.COM> References: <23170@joshua.athertn.Atherton.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Caching can be thought of as a kludge which is needed to try to give >UDP the same reliablity as TCP. Why not use TCP directly? I am not sure I follow your reasoning here. I believe that RPC provides the necessary retransmission feature. Therefore, it is RPC which is attempting to provide the reliability of TCP, caching is a separate issue. TCP may be more desirable because it is usually tied more directly to the operating system and would perform better under heavy loads than RPC/UDP (less likely to suffer retransmissions). Also, it would not double buffer an RPC request because it only keeps around 1 copy of an incoming packet. >Your cache will not ensure execute at most once behavior. Think about >a server and three clients. The server gets an RPC from client 1, >then 2, then 3. But it must trash the cache from client 1 in order >to store client 3's result. Now it gets a resend from client 1; it >will execute the service routine a second time. >The trick to caching UDP/RPC results it to cache exactly one result for >each client the server has. The cost is 8K per client, max. You never >need to cache more than one response from each client, since a client >will only send a new RPC only if the old one has been completed. This is a good idea. I believe there are some exceptions to the 1 reply per request rule, however. I believe the "spray" application will blast a host with a number of packets before requiring a reply. Also, keep in mind that this caching scheme will not work for RPC/TCP connections where batched RPC is being used. Again, multiple requests will be received before a response is required. *** These opinions are my own, blah, blah, blah *********** jeff@hpctdlb.hp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050717212200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 10:24:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22630; Mon, 7 May 90 10:23:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 17:21:22 GMT From: news@psuvax1.cs.psu.edu (Daniel Ehrlich) Organization: Computer Science Department, Penn State University Subject: Re: How to turn RIP off in Sun 3/50?? Message-Id: References: <9005050218.AA16274@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005050218.AA16274@ucbvax.Berkeley.EDU> CCECHAN@NUSVM.BITNET (Luther Chan) writes: Luther> Can anyone tell me how to turn the RIP in Sun 3/50 with Sun OS 3.3 or 3.4? Luther> Please tell where is the file contain the switch and the file name. If you run routed there are two choices. 1) Stop running routed, in which case you need to install a default route in rc.local at boot time. 2) Run routed with the '-q' switch which says do not under any conditions send RIP packets. Hope this helps. -- Dan Ehrlich /Voice: +1 814 863 1142/FAX: +1 814 865 3176 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050719102000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 08:10:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06274; Tue, 8 May 90 08:05:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 May 90 19:10:20 GMT From: bywater!arnor!news@uunet.uu.net Organization: IBM T.J. Watson Research Center Subject: RE: IP based job submission services.. Message-Id: <1990May7.191020.9034@arnor.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil John Curran (cei001@uc.msc.umn.edu) writes: > > Is there any sites that have a method for IP systems to submit MVS jobs? > > John Curran While IBM's TCP/IP for MVS does not provide this function today, we are currently working on code which will allow remote job submission via FTP and will distribute it via normal service channels when it is complete. Bill Rubin IBM TJ Watson Research ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005080242.AA28470@ucbvax.Berkeley.EDU] <1990050802424400> From: CCECHAN@NUSVM.BITNET (Luther Chan) Newsgroups: comp.protocols.tcp-ip Subject: SUN 3/50 PROBLEM: HELP Message-ID: <9005080242.AA28470@ucbvax.Berkeley.EDU> Date: 8 May 90 02:42:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Posted: Tue May 8 03:42:44 1990 X-Unparsable-Date: Tue, 08 May 90 09:36:05 SST Hi, Thanks for the two reply on my previous question about turn the RIP off. Now I have a problem when the Sun 3/50 bootup, note I have not changed any- thing yet. The Sun 3/50 in here asked for Internet address after the selftest but unable to abort the request. The ethernet connector was terminated without any external connection. It act as a stand alone with a SCSI harddisk. The harddisk did fail once and later it was working again. The symptom was not the same as when the harddisk fail(was the handdisk unable to spin reported ). I can get into the PROM but I do not know what can I do except reset the system. Anyone has any idea what can I do to make the request of internet address by passed. (Note I have not been able to get to the login prompt). Luther Chan PS. I am from National University of Singapore. This message has nothing to do with the University. I am acting on my own opinion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050805085500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 09:01:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09091; Tue, 8 May 90 08:52:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 05:08:55 GMT From: mailrus!cs.utexas.edu!samsung!munnari.oz.au!ditmela!yarra!melba.bby.oz.au!gnb@tut.cis.ohio-state.edu (Gregory N. Bond) Organization: Burdett, Buckeridge and Young Ltd. Subject: Re: help with ntp Message-Id: <1990May8.050855.11995@melba.bby.oz.au> References: <800@semto.sem.it> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <800@semto.sem.it> paolo@semto.sem.it (Paolo Zeppegno) writes: I have a very small network, just a couple of machines (more to come real soon now) running ultrix 3.1. I have compiled ntp and I would like to have the clocks in my network synchronized. How do I do it? My brain is probably dead, but the doc is very hard to understand. Keep in mind that I have no access to any reference clock. This is what I did here. I run a network of some 20 Suns. I used the talking telephone clock over a period of a week or so to find a server with the smallest clock drift (in free-running mode, no ntp or rdate etc). It turned out (by luck) that my workstation has the lowest drift of any I measured. So I run my workstation as an NTP stratum-3 server, synced to the local clock. A second stable workstation syncs to my machine and its own internal clock (at stratum-4) so will take over the time server role if my machine dies. All the file servers on my net (and the backup master) are synced to my machine, and to one other server. All diskless clients are synced to their respective file servers. This means that I can set the absolute time from my workstation, and the rest of the net will track it. And my clock drifts only a few seconds a week, so the effort is minimal. Greg. some ntp.conf files: my workstation (the master): ---- # ntp.conf file for baby - the master clock server precision -7 tickadj 10 # Use my clock as a reference peer /dev/null LOCL 3 -5 local ------ One file server: --- # ntp slave server configuration tickadj 10 precision -6 peer baby peer sid --- The backup server --- # bottle : the backup time server tickadj 10 precision -6 peer baby peer melba peer /dev/null LOCL 4 -5 local ----- -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050805233600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 03:29:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20515; Tue, 8 May 90 03:16:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 05:23:36 GMT From: cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@tut.cis.ohio-state.edu (Dewey Henize) Organization: Home for Recalcitrant Hackers Subject: Broadcasts and YP service(s) Message-Id: <15346@sequoia.execu.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Perhaps the collective wisdom of the net will come to my ignorant aid... Our network is an 'interesting' collection of various machines, including Suns, a Sequent, and an HP. We are running YP (NIS now I guess). In the past, we used one of the Suns, the Sequent, and the HP (under HP-UP) as YP servers. The Sun was/is the master, the other two slaves. Things went pretty well until recently when we started added more machines and we noticed some pretty big slowdowns. Tracking things for a while, it became apparent that machines that had bound to the HP for a YP server were getting slowed down a LOT by the responses from it. Since it was already as unloaded as possible, I wanted to take it out of the YP server business (I've got other machines I can draft later). HOWEVER, if it doesn't come up with the ypserv daemon, it doesn't seem to be able to find a ypserver anywhere. Once they are up, however, I can use ypset to redirect them to using other servers and kill off the HP's ypserv daemon and go on merrily about my business. The only thing I can figure out is that the sequent and sun use a broadcast of 130.211.200.0 (class B, subnetted) while the HP appears to use 130.211.200.255. I can't figure out any way to make the HP use anything else, since the ifconfig on it doesn't know about the broadcast parameter. Ideas? Suggestions? Help!? Thanks in advance. I'm sure this is in TFM somewhere, but I haven't been able to find it after looking all afternoon. Dewey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050806322400> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Tue, 8 May 90 13:35:13 PDT Date: Tue 8 May 90 13:32:24-PDT From: William "Chops" Westfield Subject: Re: pinging a remote TCP port to see if it's in use To: shelby!cis!interran@eos.arc.nasa.gov cc: tcp-ip@nic.ddn.mil In-Reply-To: Message-ID: <12588117089.28.BILLW@mathom.cisco.com> I want the ping to tell me whether or not an attempt to connect to the TCP port would succeed (i.e., whether or not the TCP port's in use). How do I find out if a given TCP port on a given host is in use without affecting the remote program's behavior? This is next to impossible. The problem is that in theory, you can have any number of connections to a particular tcp port, as long as the source host and/or port are different. Thus you can have many connections to the SMTP or Telnet ports of a host, and you can't easilly tell how many more will be accepted. Of course, some host/port combinations are "stupid", and will accept only one connection to a particular port. (The obvious example being a port tied to a particular line on a tcp terminal server.) If you KNOW that the port you are trying to reach is of this type, your best bet may be to use a network managment protocol (eg SNMP) to see if that port already has a connection. Of course, this may be more expensive in many ways than just trying the TCP connection... Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050808120400> Received: from po2.andrew.cmu.edu by NIC.DDN.MIL with TCP; Tue, 8 May 90 16:31:20 PDT Received: by po2.andrew.cmu.edu (5.54/3.15) id ; Tue, 8 May 90 18:03:48 EDT Received: via switchmail; Tue, 8 May 90 18:03:38 -0400 (EDT) Received: from po3.andrew.cmu.edu via qmail ID ; Tue, 8 May 90 14:59:56 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 8 May 90 14:52:11 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 8 May 90 14:52:06 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Tue, 8 May 90 14:52:04 -0400 (EDT) Message-Id: Date: Tue, 8 May 90 14:52:04 -0400 (EDT) From: Drew Daniel Perkins To: tcp-ip@nic.ddn.mil, phoenix!phoenix.princeton.edu!eho@princeton.edu (Eric Ho) Subject: Re: PPP ?? In-Reply-To: References: > Excerpts from internet.tcp-ip: 4-May-90 PPP ?? Eric Ho@princeton.edu (264) > I'm not sure if these are the right newsgroups to send to but I'm interested > in knowing current developments concerning PPP. I would be very much > appreciated if anyone can give me any pointers on this. The most recent developments: 1. The IESG has recommended to the IAB that PPP be advanced to Draft Standard status. 2. Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer over PPP have been submitted. 3. Two PD implementations are available, one for 4.3 BSD the other for KA9Q on PCs. Another two for SunOs will become available shortly. 4. A number of manufacturers have already implement/ported or plan to implement/port PPP very soon. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050809291800> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 8 May 90 21:14:51 PDT Received: from wrs.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA22942; Wed, 9 May 90 00:14:51 -0400 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA18386; Tue, 8 May 90 21:03:28 PDT Received: from daahoud. by yuba.WRS.COM (4.0/SMI-4.0) id AA20205; Tue, 8 May 90 21:09:17 PDT From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) Message-Id: <9005090409.AA20205@yuba.WRS.COM> Received: by daahoud. (4.0/SMI-4.0) id AA22614; Tue, 8 May 90 21:09:19 PDT To: uunet!mathom.cisco.com!BILLW@uunet.UU.NET Cc: shelby!cis!interran@eos.arc.nasa.gov, tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use In-Reply-To: Your message of Tue, 08 May 90 13:32:24 -0700. <12588117089.28.BILLW@mathom.cisco.com> Date: Tue, 08 May 90 21:09:18 -0700 > I want the ping to tell me whether or not an attempt to connect to the > TCP port would succeed (i.e., whether or not the TCP port's in use). > How do I find out if a given TCP port on a given host is in use without > affecting the remote program's behavior? > > This is next to impossible. > using ping which uses ICMP for something like this is inconsistent. ICMP is at the same level as IP (network layer in osi terms) and has no relevant information about the transport level concept of a "port" per se although some transport protocol implementations make use of ICMP "port unreachable" message type to tell the remote machine when there's no one bound to a particular target port requested by incoming packets. > The problem is that in theory, you can have any number of connections to > a particular tcp port, as long as the source host and/or port are different. > Thus you can have many connections to the SMTP or Telnet ports of a host, > and you can't easilly tell how many more will be accepted. > i think the original question is asking for a way to tell whether or not it is possible to make a connection. a connection attempt will hang if there's an existing connection between TCP sockets that are bound to the same combinations of the port numbers (i.e. the case where the source port and destination port combination is already being used by an existing connection between the machines in question). that is, i don't think he's asking for the number of max connections a server process is willing to accept on a given listener port. assuming that i'm interpreting his question correctly, i'll say that pretty much the only way is to use the non-blocking I/O on the socket (via FIONBIO ioctl command) and selecting on the writing side of the socket with a set time limitation (an argument to select). you'll do a ioctl of FIONBIO on the socket and then issue a connect on the socket and then select on the writing side for a give time. if the select times out you have not successfully connected to the remote machine within a given amount of time. you can try two things at this time: (a) increase the time interval, or (b) try to use a different port number on your side. and try again until you succeed. this procedure will help when the remote machine refuses time out zombie sockets that are hung up by some previous connections that are terminated inconsistenly. hwajin, wind river systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050809455600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 04:54:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25691; Tue, 8 May 90 04:45:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 09:45:56 GMT From: shelby!cis!interran@eos.arc.nasa.gov (John Interrante) Organization: InterViews group, Stanford University Subject: pinging a remote TCP port to see if it's in use Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I would like to "ping" a program listening to a TCP port to find out if it's alive without actually creating a connection to that program's TCP port. I want the ping to tell me whether or not an attempt to connect to the TCP port would succeed (i.e., whether or not the TCP port's in use). How do I find out if a given TCP port on a given host is in use without affecting the remote program's behavior? (I don't want the remote program to have to accept a new connection and then tear it down.) John Interrante interran@lurch.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050809481500> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Tue, 8 May 90 16:48:08 PDT Posted-Date: Tue, 08 May 90 16:48:15 PDT Message-Id: <9005082348.AA22539@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.61/5.61+local) id ; Tue, 8 May 90 16:48:17 -0700 To: swrinde!zaphod.mps.ohio-state.edu!samsung!umich!terminator!terminator.cc.umich.edu!bryan@ucsd.edu (Bryan Beecher) Cc: tcp-ip@nic.ddn.mil Reply-To: pvm@venera.isi.edu Subject: Re: How to discover current list of DNS root servers In-Reply-To: Your message of 07 May 90 14:39:42 +0000. <1990May7.143942.23249@terminator.cc.umich.edu> Date: Tue, 08 May 90 16:48:15 PDT From: Paul Mockapetris > In article <1990May6.230841.11143@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes: > > > > If I want to find out the most current list of DNS root servers, > >does it suffice to run nslookup and do the following? > > > >> server suspected.root.server > >> set type=ns > >> . > > The only way to make sure you've got the current list of root > servers is to pick up a copy of NETINFO:ROOT-SERVERS.TXT from > the NIC. The suspected.root.server could have all kinds of > bogus NS RR's for root in its cache along with the list of > correct ones (which could be incomplete or incorrect itself). > -- > Bryan Beecher, U-M Information Technology Division (+1 313 747 4050) > Domain: bryan@terminator.cc.umich.edu Path: mailrus!terminator!bryan I'd maintain that doing the query is EXACTLY the right way to get the current list of root servers IF the suspected.root.server is chosen from a reputable set. Just as you know that NIC.DDN.MIL is the host to FTP the NETINFO:ROOT-SERVERS.TXT file from, you could just as easily know one machine that is a root server, say NS.NIC.DDN.MIL or whatever. paul ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050810370900> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Tue, 8 May 90 11:43:10 PDT Received: from UNB.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57442; Tue, 8 May 90 14:41:38 EDT Received: by UNBMVS1 (Mailer 13.09) id 5943; Tue, 08 May 90 15:37:09 ADT Date: Tue, 8 May 90 14:37:09 EDT From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: IP based job submission services.. In-Reply-To: Message of Tue, 08 May 90 14:12:43 ADT from What about retreiving jobs? Is it in the same package? Brian Kaye University of New Brunswick > > While IBM's TCP/IP for MVS does not provide this function today, we > are currently working on code which will allow remote job submission > via FTP and will distribute it via normal service channels when it is > complete. > Bill Rubin > IBM TJ Watson Research ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050811360500> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 7 May 90 18:53:40 PDT Received: from NUSVM.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0964; Mon, 07 May 90 21:52:43 EDT Received: by NUSVM (Mailer R2.03B) id 4846; Tue, 08 May 90 09:55:32 SST Date: Tue, 08 May 90 09:36:05 SST From: Luther Chan Subject: SUN 3/50 PROBLEM: HELP To: Vivian Neou Hi, Thanks for the two reply on my previous question about turn the RIP off. Now I have a problem when the Sun 3/50 bootup, note I have not changed any- thing yet. The Sun 3/50 in here asked for Internet address after the selftest but unable to abort the request. The ethernet connector was terminated without any external connection. It act as a stand alone with a SCSI harddisk. The harddisk did fail once and later it was working again. The symptom was not the same as when the harddisk fail(was the handdisk unable to spin reported ). I can get into the PROM but I do not know what can I do except reset the system. Anyone has any idea what can I do to make the request of internet address by passed. (Note I have not been able to get to the login prompt). Luther Chan PS. I am from National University of Singapore. This message has nothing to do with the University. I am acting on my own opinion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050812461200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 07:26:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11976; Wed, 9 May 90 07:12:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 12:46:12 GMT From: mcsun!unido!quando!wichert@uunet.uu.net (Peter Wichert) Organization: Quantum GmbH, Dortmund, W-Germany Subject: Looking for fast file-transfer on ethernet Message-Id: <1494@quando.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, I want to do a fast file-transfer between hosts using ethernet. I have implemented a file-transfer based on the BSD socket interface with TCP protocol. My problem is that the transmission rate is too slow, so to speed things up I want to do the same with UDP protocol, but UDP is unreliable. What I'm looking for is an interface that supports reliable byte/sec streams using UDP. What does rcp use?, it is a lot faster than ftp'ing? Any ideas ???? Many Thanks, for any replies. Please DON'T send sources, send me mail first... -- Peter Wichert UUCP: {backbone}!unido!quando!wichert OR wichert@quando.uucp Quantum GmbH Bitnet: UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet) Dortmund internet: wichert%quando%unido.UUCP@mcsun.cwi.nl Germany internet: wichert@quando.quantum.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050814153400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 08:10:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06315; Tue, 8 May 90 08:06:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 14:15:34 GMT From: sparkyfs!arsocomvax.socom.mil!news@ames.arc.nasa.gov (Ted Nolan) Organization: SOFNET Subject: Re: PC-LAN connection to Usenet Message-Id: <1990May8.141534.8796@arsocomvax.socom.mil> References: <2744@psueea.UUCP>, <2745@psueea.UUCP>, <798@banyan.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >In article <4950@netxcom.DHL.COM> cmoussav@dhlmis.DHL.COM (C. Ognibene-Moussavi) writes: >I am asking the following question on behalf of my husband - at his work >there is only a LAN - he would like to know what hardware, software and >phone number he needs for a dial-up connection to Usenet - he would like >to be able to read the newsgroups and post to them as well. I think Lauren Weinstein wrote a complete netnews/uucp (commercial) package for DOS PCs a couple of years ago. It may be that you could put this on one PC and have the rest get at it over the LAN. According to whois, his address is: Weinstein, Lauren (LW2) Lauren@RAND.ORG Vortex Technology P.O. Box 1323 Topanga, CA 90290 (213) 455-9300 Ted Nolan ted@usasoc.soc.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050815231000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 20:55:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14841; Tue, 8 May 90 20:47:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 15:23:10 GMT From: usc!srhqla!nrcvax!bvs@ucsd.edu (Bill Versteeg) Organization: Network Research Corp., Oxnard CA Subject: Re: pinging a remote TCP port to see if it's in use Message-Id: <521@nrcvax.NRC.COM> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article interran@lurch.Stanford.EDU (John Interrante) writes: >I would like to "ping" a program listening to a TCP port to find out >if it's alive without actually creating a connection to that program's >TCP port. If the machine in question speaks SNMP, the information is available. The easiest way to get it is using "snmpnetstat host_name community_string -a". If you don't have snmpnetstat, a snmpwalk of the tcp group will do. If the machine does not speak SNMP, you could log onto the machine and use "netstat -a". Yet another example of why EVERYONE SHOULD IMPLEMENT SNMP!!!! Bill VerSteeg -- Bill VerSteeg Network Research Corporation 170 Watermill Falls Alpharetta Ga. 30201 bvs@nrc.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050815333100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 09:41:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11802; Tue, 8 May 90 09:36:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 15:33:31 GMT From: usc!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) Organization: Motorola Inc. Austin, Tx Subject: NNTP-socket-based News Interface (Eg: "rrn") Message-Id: <3258@apogee.oakhill.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for a NNTP-based news reader interface like "rrn". Currently we have a "rrn" binary in place [as also the "rn" scheme]. The "rrn" interface we have is either not complete or terribly out-dated unless what we suffer from is due to an inherent drawback of "rrn". I do not know. "rrn" we have does not give any WRITE capabilites to users, i.e. one cannot follow-up ('f' or 'F') or reply ('r' or 'R') to a posting. Quite logically it follows that one also cannot 'postnews' through "rrn". What I am interested in is any or all of the following: 1. A cleaner and more complete implementation of "rrn", and/or more generally, 2. An IP socket-based (NNTP or other) Bulletin Board/News Reader interface that works. Are there any out there running or aware of such implementations? We have the GNU Emacs package that comes with a built in NNTP-based news reader interface. Emacs is something that many do not use and we are looking for a more common-place alternative that would keep the user-learning curves and migration to new Bulletin Board features simple and minimal. I would also like to hear if the capabilities we lack in "rrn" are endemic to it or is there someone running "rrn" with write capabilities (say, comparable to "rn") other than thru GNU Emacs. Also, it is not clear whether the "rrn" deficiency we face is in the client part or server or both. I would prefer EMail. If there is interest, I shall consolidate responses and post. ----- Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com Software Engineer UUCP : oakhill!apogee!guri@cs.utexas.edu Global Networking Phone : 512/891-3310 MOTOROLA - SPS Austin, TX 78735 ----- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050818563700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 21:11:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17719; Tue, 8 May 90 20:58:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 18:56:37 GMT From: usc!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) Organization: Motorola Inc., Austin, Texas Subject: Re: pinging a remote TCP port to see if it's in use Message-Id: <3262@apogee.oakhill.UUCP> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article interran@lurch.Stanford.EDU (John Interrante) writes: >I would like to "ping" a program listening to a TCP port to find out >if it's alive without actually creating a connection to that program's >TCP port. I want the ping to tell me whether or not an attempt to >connect to the TCP port would succeed (i.e., whether or not the TCP >port's in use). ... stuff deleted ... > >John Interrante interran@lurch.stanford.edu I don't belive you can do this thru ping. ping is an echo program at the Network Layer (IP) (without a Transport Layer, if you may). It does not take port connections into its folds. It uses "raw sockets" to interface between the Application and Network Layers. If you figure out a something to the contrary, I would like to know. Gurvinder. ---------- Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com Software Engineer UUCP : {}oakhill!apogee!guri@cs.utexas.edu Global Networking Phone : 512/891-3310 Motorola SPS Austin, TX ---------- #include ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050821072600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 00:41:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22313; Wed, 9 May 90 00:28:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 21:07:26 GMT From: cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!briand@tut.cis.ohio-state.edu (brian donat) Organization: Informix Software Inc., Menlo Park, CA. Subject: gated Message-Id: <4194@infmx.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello, Some time ago, somebody brought up a discussion aobut Dave Mill's Fuzzballs. I'd like to dig up some further info on cost metrics, so if anybody knows of any good references on this topic, could you please advise me. Also, I don't seem to be able to access 'devvax.tn.cornell.edu' and would like to obtain gated. Can anybody help me here? --briand ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050821152900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 16:11:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05496; Tue, 8 May 90 16:00:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 21:15:29 GMT From: ftp!fks@BLOOM-BEACON.MIT.EDU (Frances Selkirk) Organization: FTP Software Inc., Wakefield, MA Subject: Re: Tektronix emulation Message-Id: <989@ftp.COM> References: <9005040701.AA12937@ucbvax.Berkeley.EDU>, <1306@excelan.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1306@excelan.COM>, manoj@excelan.COM (manoj @ Prod Mktg) writes: > With LAN WorkPlace for DOS (Novell's TCP/IP for DOS), these are some of the > 3rd party term emulators.. > walker richer quinn, seattle, WA > kea systems, vancouver , canada > softronics, > grafpoint, saratoga, ca > persoft, > polygon, > diversified computer systems These packages are a good way to get many terminal emulator, especially those for graphics terminals. FTP Software's PC/TCP also supports INT-14 emulators. Any other compatible telnets/rlogins out there? To the list of companies making INT-14 emulators, you should add Pericom and Mitek. Again, any others present or known? Enjoy! Frances -- Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050822091800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 15:26:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02606; Tue, 8 May 90 15:13:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 May 90 22:09:18 GMT From: oliveb!orc!bu.edu!bu-it!kwe@apple.com (Kent England) Organization: Boston University Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <56957@bu.edu.bu.edu> References: <1158@tnosoes.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes: > I modified a version of Phil Karns KA9Q internet package > so it acts as a suspicious secure gateway. > > The goal of this gateway is to establish security of a local network > at the gateway instead of securing every host on your local network. > > One would for example disallow excess to rlogin, rsh, ftp and telnet > because many users have bad passwords. > Source address "authentication" is very weak security. If you allow any ftp connections to any host on your net, a way will be found to attempt ftp connections to all your hosts. The path to good internet security is to build security hooks into the protocol suite and the applications software and implement a robust authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol. There are no shortcuts. [Jon Rochlis from MIT has pounded this point of view into my head.] The IETF is addressing this need by requiring security (among other things) to be accounted for in every new protocol proposal. Sort of like a security environmental impact statement. Steve Crocker of Trusted Information Systems is the Area Director of Security in the IETF. He is worrying about all kinds and levels of security. This is a very active area of research in the IETF, in other words. It is affecting PPP, OSPF, BGP to name a few new protocols. Stay tuned. Meanwhile, if you want to use this modified KA9Q, just be aware of how weak this approach really is. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050902330800> Received: from cheetah.nyser.net by NIC.DDN.MIL with TCP; Wed, 9 May 90 14:15:40 PDT Received: from localhost by cheetah.nyser.net at Wed, 9 May 90 14:13:16 -0700. (5.61.14/XIDA-1.2.8.34) id AA11129 for tcp-ip@nic.ddn.mil via SMTP To: johns@hpwade.UUCP Reply-To: tcp-ip@nic.ddn.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: pinging a remote TCP port to see if it's in use In-Reply-To: Your message of 09 May 90 12:52:13 +0000. <876@hpwala.wal.hp.com> Date: Wed, 09 May 90 14:13:08 -0700 Message-Id: <11124.642287588@cheetah.nyser.net> From: Marshall Rose Actually, there are at least three non-proprietary implementations of SNMP available, of which you described one. Parties interested in hearing more about SNMP are invited to join the snmp list (drop a note to snmp-request@nisc.nyser.net.) /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050902525500> Received: from cheetah.nyser.net by NIC.DDN.MIL with TCP; Wed, 9 May 90 14:33:53 PDT Received: from localhost by cheetah.nyser.net at Wed, 9 May 90 14:33:05 -0700. (5.61.14/XIDA-1.2.8.34) id AA11219 for tcp-ip@nic.ddn.mil via SMTP To: HAGGAR@bnr.ca (Haggar Alsaleh, H.) Cc: tcp-ip@nic.ddn.mil Reply-To: tcp-ip@nic.ddn.mil Subject: Re: IEEE 802.1 Network Management. In-Reply-To: Your message of Wed, 09 May 90 13:09:00 -0400. <90May9.131241edt.57495@ugw.utcs.utoronto.ca> Date: Wed, 09 May 90 14:32:55 -0700 Message-Id: <11210.642288775@cheetah.nyser.net> From: Marshall Rose There is a "transmission working group" that is working on defining MIBs for things below the IP (e.g., 802.3). If you want to get on the mailing list, send a note to trans-wg-request@nisc.nyser.net. For the last couple of years, it has generally been felt that management protocols specific to the data-link layer are not all that helpful. The reason is: If you have a well-engineered management protocol for your protocol suite (e.g., the SNMP for the Internet suite of protocols), then the additional amount of work required to implement the protocols between the data-link protocol and the management protocol, should be quite small. In the case of the SNMP, you implement both the IP and the UDP. Minimal implementations of these are straight-forward. Once you have these protocols in place, management requests can be fielded across an internet, instead of restricting them to the local LAN. As such, you can do remote management of your LAN using the same applications and techniques that you use locally. This gives you tremendous leverage! Of course, not all management protocols are this well-engineered. As such, other management frameworks may not enjoy this advantage. In brief, true power in a well-designed system comes from simplicity in design, not over-wrought complexity. So, the answer to your question is: look at trans-wg if you're interested in 802 managed objects ... and use the SNMP to manage them! /mtr Thank-you for your support! --the SNMP PAC (-: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050904321300> Received: from next.cis.brown.edu by NIC.DDN.MIL with TCP; Wed, 9 May 90 08:15:07 PDT Received: by next.cis.brown.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA14146; Wed, 9 May 90 11:12:13 GMT-0400 Date: Wed, 9 May 90 11:12:13 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) Message-Id: <9005091512.AA14146@next.cis.brown.edu> To: TCP-IP@nic.ddn.mil Subject: Returned mail: User unknown >>>Original Msg<<< Most TCP/IP's that I have abused (er ah used) have a feature that lets you say telnet foo when you mean telnet foo.bar.com. That is they add the current domain to the name if htere are no dots (some do even if there are). Others there is a list of domains to append to the hostname when trying. The only draw back to doing a "hostname foo.bar.com" in your rc.local (or where eveer) file is that the default csh prompt is foo.bar.com%" rather than "foo%". >>EOM<<< Actually the default prompt is usually set in the .cshrc file and one could use something similar to : set host="`whoami`@`hostname`" set host=`expr $host : '\([@a-zA-Z0-9]*\)'` set prompt="${host}> " and the prompt would not be a problem either. We have over a 1000 nodes and we use fully qualified 4 level domain names in most cases (We use 3 level names for major routers and just Brown.EDU for our main nameserver/router/etc). Within each sub-domain, we only have to specify the "1st" label, and never more than 2 labels to refer to any host within Brown.EDU using the usuall network client programs (telnet, ftp etc). We are using bind4.8.2+ resolver code. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050904593200> Received: from next.cis.brown.edu by NIC.DDN.MIL with TCP; Wed, 9 May 90 08:42:01 PDT Received: by next.cis.brown.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA14166; Wed, 9 May 90 11:39:32 GMT-0400 Date: Wed, 9 May 90 11:39:32 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) Message-Id: <9005091539.AA14166@next.cis.brown.edu> To: tcp-ip@nic.ddn.mil Subject: GENTER-ADAM.AF.MIL && BIND && root nameservers ... >>>Original Msg<<< .... there appears to be a nasty bug in Bind 4.8.1 ... >>>EOM<<< you should use bind4.8.2. You can get bind4.8.2.tar.Z from netlab.cis.brown.edu. It is in the pub directory. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050905055600> Received: from next.cis.brown.edu by NIC.DDN.MIL with TCP; Wed, 9 May 90 08:48:33 PDT Received: by next.cis.brown.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA14173; Wed, 9 May 90 11:45:56 GMT-0400 Date: Wed, 9 May 90 11:45:56 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) Message-Id: <9005091545.AA14173@next.cis.brown.edu> To: tcp-ip@nic.ddn.mil Subject: Find out the current list of root nameservers Roy - You got it right: nslookup > server suspected.root.server > set type=ns > . This will give you the suspected server's current root cache. You may want to compare that with ns.nic.ddn.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050905241700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 8 May 90 22:41:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA10914; Tue, 8 May 90 22:28:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 05:24:17 GMT From: dna@psuvax1.cs.psu.edu (Douglas N. Arnold) Organization: Department of Mathematics, Pennsylvania State University Subject: Re: PPP ?? Message-Id: References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > ... current developments concerning PPP. I would be very much > appreciated if anyone can give me any pointers on this. >> Two PD implementations are available, one for 4.3 BSD the other for >> KA9Q on PCs. Another two for SunOs will become available shortly. Available where? -- Douglas N. Arnold dna@math.psu.edu Dept. of Mathematics, Penn State Univ. (814) 865-0246 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050907200900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 01:41:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25174; Wed, 9 May 90 01:29:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 07:20:09 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) Organization: TNO Institute for Perception, Soesterberg, The Netherlands Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1159@tnosoes.UUCP> References: <1158@tnosoes.UUCP>, <56957@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil kwe@bu-it.bu.edu (Kent England) writes: >In article <1158@tnosoes.UUCP>, tom@tnosoes.UUCP (Tom Vijlbrief) writes: >> I modified a version of Phil Karns KA9Q internet package >> so it acts as a suspicious secure gateway. >> >> The goal of this gateway is to establish security of a local network >> at the gateway instead of securing every host on your local network. >> >> One would for example disallow excess to rlogin, rsh, ftp and telnet >> because many users have bad passwords. >> > Source address "authentication" is very weak security. If you >allow any ftp connections to any host on your net, a way will be found >to attempt ftp connections to all your hosts. What do you mean ? Can you be a little bit more specific? Authentication is not done on source address at all. One should disallow all FTP connections from the outside world, except to a special host. If this host is the PC which runs the gateway software than you can be sure that NO ONE WILL EVER access a FTP server on any other host on your local network from the outside internet. The idea is to make inaccessible well known ports from the outside internet except those you need to establish mail and FTP connections. Filtering is done on destination port number, there is no way you can break this if it is properly implemented. Prove me wrong. > The path to good internet security is to build security hooks into >the protocol suite and the applications software and implement a robust >authentication protocol, like Kerberos or the Privacy Enhanced Mail protocol. >There are no shortcuts. [Jon Rochlis from MIT has pounded this point >of view into my head.] This is nice but it does not help when it is not implemented in vendors software. Kerberos and other authentication protocols are needed when possible intruders have access to your local physical layer (your ethernet backbone). If you don't need or want remote logins and remote shells to be initiated from the outside world at all, then there is no need for kerberos or other more secure protocols. My approach is sufficient and works for all TCP/IP hosts on your local network without the need to install new software. Again prove me wrong. > The IETF is addressing this need by requiring security (among >other things) to be accounted for in every new protocol proposal. Sort >of like a security environmental impact statement. Steve Crocker of >Trusted Information Systems is the Area Director of Security in the >IETF. He is worrying about all kinds and levels of security. This >is a very active area of research in the IETF, in other words. It >is affecting PPP, OSPF, BGP to name a few new protocols. Stay tuned. > Meanwhile, if you want to use this modified KA9Q, just be >aware of how weak this approach really is. I hope you can indicate REAL holes in my security approach, otherwise your statement is really weak, instead of the modified KA9Q. (I don't want to be offensive but I really figured out many different ways of attack and iterated my gateway implementation till it was secure. I really like (constructive) criticism, so I can make it better). > --Kent Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050907251100> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Fri, 11 May 90 00:22:50 PDT Date: Wed 9 May 90 14:25:11-PDT From: William "Chops" Westfield Subject: Re: pinging a remote TCP port to see if it's in use To: usc!cs.utexas.edu!oakhill!guri@ucsd.edu cc: tcp-ip@nic.ddn.mil In-Reply-To: <3262@apogee.oakhill.UUCP> Message-ID: <12588388842.28.BILLW@mathom.cisco.com> Please, people: "ping" is not a specific network protocol - it is a concept. The unix "ping" command happens to use ICMP ECHO packets, but there are also XNS, CLNS, Appletalk, Chaosnet, PUP equivilents of ping, as well as conceptually similar concepts for UDP, TCP, and so on. The original request asked for a way of determining the status of a particular TCP port, which is more or less within the scope of "pinging" - I don't think there was any intentiion of using ICMP for this. BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050908322800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 07:46:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03891; Thu, 10 May 90 07:35:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 08:32:28 GMT From: usc!samsung!munnari.oz.au!bruce!goanna!dmh@ucsd.edu (Darren Hosking) Organization: Comp Sci, RMIT, Melbourne, Australia Subject: Too many tftp requests causes "Connection Refused" Message-Id: <2885@goanna.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have cross posted this to comp.windows.x because the problem was highlighted by a lab of X terminals and someone may have had a similar problem. We have a lab full of X terminals that all use tftp to fetch the downloadable server and fonts. If I start one X terminal at a time the terminal boots up (and fetches its fonts) without any problems, however, if I start several at once the machine that they are all trying to tftp from comes up with the following console messages: May 7 15:29:41 yallara.oz tftpd[2009]: tftpd: read: Connection refused May 7 15:29:42 yallara.oz tftpd[2015]: tftpd: read: Connection refused May 7 15:29:44 yallara.oz tftpd[2019]: tftpd: read: Connection refused ... May 7 15:29:54 yallara.oz tftpd[2072]: tftpd: read: Connection refused May 7 15:29:55 yallara.oz inetd[169]: tftp/udp server failing (looping), servic e terminated After which inetd will no longer run tftpd. The X terminals report errors when the above happens. This problem occurs on an Encore Multimax running UMAXV 2.2J, a VAX 11/750 running 4.3 BSD, and a Sony 1850 running 4.3 BSD. However, the problem does NOT occur on an Encore running 4.3 BSD (R4_0.0). Tftpd appears to be failing in recvfrom() and is returned "Connection Refused". My question is this, why do lots of tftp's work on one machine and not most others? Is there are kernel configurable parameter that will increase the backlog of UDP packets (if this is the problem)? The problem can be recreated without using X terminals by using two shell scripts that generates several tftp requests for a small file on a particular machine in the background. For example: #! /bin/csh # Filename: t # foreach f (1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0) tf & end #! /bin/csh # Filename: tf # tftp MACHINENAME << EOF get /FILENAME q EOF Thanks in advance, dmh Darren Hosking ACSnet: dmh@goanna.oz Department Of Computer Science ARPA: dmh%goanna.oz.au@uunet.uu.net RMIT CSNET: dmh%goanna.oz.au@australia GPO Box 2476V UUCP: ...!uunet!goanna.oz.au!dmh Melbourne Vic., Australia 3001 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050909090000> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Wed, 9 May 90 10:17:16 PDT Received: from BNR.CA (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57495; Wed, 9 May 90 13:12:41 EDT Received: by BNR (Mailer R2.04) id 1553; Wed, 09 May 90 13:12:00 EDT Date: Wed, 9 May 90 13:09:00 EDT To: tcp-ip@nic.ddn.mil From: Haggar (H.) Alsaleh Subject: IEEE 802.1 Network Management. Sender: Haggar (H.) Alsaleh Message-Id: <90May9.131241edt.57495@ugw.utcs.utoronto.ca> Is anybody looking at alternative network management protocol such us IEEE 802.1b, I have the standard but I need more info If you could help or know where I could find it, I would very much appreciate it. Thanks Haggar Alsaleh 1150 E. Arapho Rd. Richardson, TX 75081. (214) 997-4806. Haggar@bnr.ca ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050912521300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 10:14:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22152; Wed, 9 May 90 10:04:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 12:52:13 GMT From: hpda!hpwala!hpwade!johns@ucbvax.Berkeley.EDU (John Silva) Organization: Hewlett Packard, Waltham, Mass Subject: Re: pinging a remote TCP port to see if it's in use Message-Id: <876@hpwala.wal.hp.com> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article interran@lurch.Stanford.EDU (John Interrante) writes: >I would like to "ping" a program listening to a TCP port to find out >if it's alive without actually creating a connection to that program's >TCP port. I want the ping to tell me whether or not an attempt to Well, this may not exactly be the answer you are looking for but ... If your target machine is running SNMP (i.e. snmpd) and you have the snmpwalk program on your source machine you can do the following to query SNMP for an available service : $ snmpwalk \ tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25 Name: tcp.tcpConnTable.tcpConnEntry.tcpConnState.0.0.0.0.25.0.0.0.0.0 INTEGER: listen(2) (This example would check to see if the SMTP [sendmail] port is listening. To check for another service port, just put its number in place of the 25.) I believe that the SNMP package is available from CMU (I do not have the FTP address available). >John Interrante interran@lurch.stanford.edu Hope this helps, John Silva johns@hpwarf.hp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050915181400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 09:28:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19826; Wed, 9 May 90 09:26:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 15:18:14 GMT From: grebyn!pat@decuac.dec.com (Pat Bahn) Organization: Grebyn Timesharing, Vienna, VA, USA Subject: Re: IP based job submission services.. Message-Id: <20023@grebyn.com> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil JTM in OSI does this, course that means someone would actually have to implement it. then put in the bridges to TCP. Any volunteers? -- ============================================================================= Pat @ grebyn.com | If the human mind was simple enough to understand, 301-948-8142 | We'd be too simple to understand it. -Emerson Pugh ============================================================================= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050917342000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 11:28:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27432; Wed, 9 May 90 11:24:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 17:34:20 GMT From: pollux!ccruss@ucdavis.ucdavis.edu (Russ Hobby) Organization: University of California, Davis Subject: Re: Ingres certification of TCP/IP Message-Id: <7303@aggie.ucdavis.edu> References: <9005050253.AA18113@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi Henry, Funny you should bring this up. Although I can't answer you specific question on Ingres, I do have a comment. One problem we have with SQL databases running over TCP/IP networks is that each vendor is starting to do it their own way. From the users porint of view, this won't do! Thus, I have just formed an Internet Engineering Task Force Working Group to standardize SQL over IP. The WG has the goals of getting the vendors together and agreeing on a standard. After that the WG will move on to Z39.50 over the Internet. The chair of the WG is Cliff Lynch and if you are interested following the WG or partisipating, you can write to him at lynch@postgres.berkeley.edu Russ Hobby INTERNET: rdhobby@ucdavis.edu IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS UUCP: ...!ucbvax!ucdavis!rdhobby ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050918290300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 12:14:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29884; Wed, 9 May 90 12:02:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 18:29:03 GMT From: eru!luth!sunic!tut!jh@bloom-beacon.mit.edu (Juha Heinanen) Organization: Tampere Univ. of Technology, Finland. Subject: Re: PPP ?? Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: 2. Draft proposals for 802.3 and 802.5 Bridging and OSI Network Layer over PPP have been submitted. Any idea if the latter is going to be submitted also to ISO? The current ISO standard (8880-3) lists ISO 8473 over ISO 7809 BAC in the Point-to-Point case. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050920440900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 14:27:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07858; Wed, 9 May 90 14:08:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 20:44:09 GMT From: sgi!pchin%midautumn.wpd.sgi.com@ucbvax.Berkeley.EDU (Phil Chin) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Looking for Kermit Protocol Manual Message-Id: <59728@sgi.sgi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Any one know where I can get the following manuals from? "Kermit, A File Transfer Protocol", Frank de Cruz "Kermit Protocol Manual", Frank de Cruz Thanks Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050921044100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 15:12:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11321; Wed, 9 May 90 15:04:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 21:04:41 GMT From: att!cbnewsh!fsi@ucbvax.Berkeley.EDU (furrokh.s.irani) Organization: AT&T Bell Laboratories Subject: comparision of sockets to tli Message-Id: <1990May9.210441.4731@cbnewsh.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone have a comparision of the 'TLI' interface versus the 'socket' interface? Please email to att!odyssey!fsi. Thanks v. much. -Furrokh S. Irani ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050921525100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 20:59:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02331; Wed, 9 May 90 20:51:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 21:52:51 GMT From: cbmvax!grr@uunet.uu.net (George Robbins) Organization: Commodore, West Chester, PA Subject: Lantastic vs. the World - Problems? Message-Id: <11484@cbmvax.commodore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil One of our user areas here has decided that they want to use one of those PC network products call "Lantastic" with WD8003 Ethernet cards. Up to now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on 3c503 cards for PC's. The apparent reason for going with the WD8003 cards is lack of Netbios support for the 3c503. I find this somewhat hard to argue with. Has anyone had any interoperbility problems with Lantastic and traditional protcols on the same Ethernet? I know there shouldn't be, but I'd like be sure before these guys commit (me) to a bunch of new hardware and software. Is the Lantastic stuff yet another unique proprietary protocol or is it related to something more generic? Apologies to tcp/ip folk who find this somewhat peripheral... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990050922561700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 22:29:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07253; Wed, 9 May 90 22:16:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 May 90 22:56:17 GMT From: agate!shelby!cis!interran@ucbvax.Berkeley.EDU (John Interrante) Organization: InterViews group, Stanford University Subject: Re: pinging a remote TCP port to see if it's in use Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I got about four types of responses: 1. There is no way to get this information from the TCP protocol layer. [ Everybody agreed on this one. ] 2. If you have a way to bypass the TCP protocol layer and access the raw packet layer, you can send a SYN to the remote port. If there is no server listening on the other end, but the host is reachable, you should get a RST back. If there is a server listening on the other end, then the remote TCP will set up a connection block to handle your SYN and return a SYN ACK. The remote TCP will not have reached established state yet, so the listening server should still be unaffected. You would tear down your connection block and send a RST. The other end will tear down its connection block when it gets the RST. If your RST gets lost, the other end will retransmit the SYN ACK and your TCP will send a RST (as usual). Another person had a similar response with slightly different details: You can send and receive arbitrary packets behind TCP's back with Sun's Network Interface Tap (NIT) facility. You would synthesize the initial TCP SYN packet, listen for the SYN-ACK, and send an ABORT if one is received (to prevent the connection from being accepted). If no SYN-ACK is received, despite repeated retransmissions of the initial SYN, the remote port is not accepting connections. [ This is what I wanted to know. Unfortunately, it's too OS-specific to be worth implementing in my portmapper. ] 3. A network management protocol such as SNMP can tell you if a port already has a connection. Etc. [ No mention was made of a programmer-level interface to the network management protocol. Even if there was one, I wouldn't use it because it's not a standard part of most Unix systems (yet). ] 4. You can avoid a connection that hangs (because there's already an existing connection between the same TCP ports on both machines) by ioctling the socket with FIONBIO to put it in non-blocking I/O, issuing a connect on the socket, and then selecting on the socket for a ready to write condition with a timeout set. If the select times out, you have not successfully connected to the remote machine within that amount of time and you have the choice of increasing the time interval or using a different port on your side. [ This answer was very interesting even though it wasn't what I was asking for. If you use ANYPORT (i.e., a zero port), you're supposed to get an unused port on your side. Would or wouldn't ANYPORT prevent this kind of problem from occurring? ] A couple of people were curious why I wanted to know how to validate a port number. I don't mind explaining that the reason I asked was to improve a portmapper I wrote for InterViews programs making RPC calls. We couldn't use Sun's /etc/portmap because we wanted servers to register their TCP port numbers under a variable-length string of characters (i.e., a name), not a tuple of integers (i.e., a program number and a version number). I noticed that SunOS 4.1's /etc/portmap will let you register the port number of a non-existent server, but it will unregister the port number and give you zero when you try to ask for the non-existent server's port number. I set a breakpoint in a server to find out how portmap validated the server's port number and I know that the server never noticed a new connection. Yet portmap definitely WAS validating port numbers in some way because I never got a port number for a non-existent server. I checked the public RPC sources on gatekeeper.dec.com but the source for portmap didn't include this kind of code so that's why I posted my question. I wanted to be able to validate port numbers in my portmapper too because it would prevent clients from trying to connect to a server that crashed after registering its port number with the portmapper. I want to thank everybody who replied to my question. You all were very helpful in letting me know that the way Sun's /etc/portmap validates port numbers is too OS-specific to be worth duplicating. John Interrante interran@lurch.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051000250600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 9 May 90 18:47:08 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24468; Wed, 9 May 90 18:35:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 00:25:06 GMT From: usc!cs.utexas.edu!execu!sequoia!sequoia.execu.com!dewey@ucsd.edu (Dewey Henize) Organization: Home for Recalcitrant Hackers Subject: 1's broadcast vs 0's broadcast (summary and thanks) Message-Id: <15511@sequoia.execu.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <15346@sequoia.execu.com> I asked about a problem with YP and IP broadcasts. I recieved a good bit of help from folks out there, and wanted to thank you all! The overall concensus was that the 1's broadcast was the only good way to go to be sure of continued compliance. (We had been using the 0's broadcast as a relic from our first couple Sun-2's - amazing how a network can grow.) It also appears that HP has support for broadcast selection in their (later? latest) OS upgrade/release, should someone find themselves in the corner I was in. I did do a convert on all the machines around to all 1's though, and was then able to remove the HP from the YP/NIS server business. In the middle we had one nice ARP storm as some clients got confused, but it all settled out and without the HP slowing the other machines down, our net is more responsive now. Thanks to those that posted suggestions, and I'd like to especially thank the following folks who wrote me with references and suggestions: WLV.IMSD.CONTEL.COM!mcc Merton Campbell Crockett mlb.semi.harris.com!del Don "Truck" Lewis ongs.LANCE.ColoState.Edu!steved Steve Dempsey idt.unit.no!he Haavard Eidnes tuegate.tue.nl!rcjoep Joep Brand uhura.cc.rochester.edu!leadley Scott Leadley Regards, Dew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051001210700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 10:22:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04711; Fri, 11 May 90 10:16:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 01:21:07 GMT From: snorkelwacker!bu.edu!mirror!adelie!minya!jc@uunet.uu.net (John Chambers) Subject: Re: Is the hostname "foo" or "foo.bar.com"? Message-Id: <381@minya.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From mail Tue May 8 03:37 EDT 1990 >From cfisun!ima!haddock.ima.isc.com!ico!stan!imp Tue May 8 03:37:53 1990 remote from adelie Received: by minya.uucp (smail2.5) id AA27964; 8 May 90 03:37:53 EDT (Tue) Received: by adelie.Adelie.COM (5.57/smail2.2/02-18-87) Received: from ima.UUCP by cfisun.cfi.com (4.1/SMI-4.0) id AA14084; Mon, 7 May 90 14:34:34 EDT Received: from haddock.ima.isc.com by ima.ima.isc.com (5.61/1.35f) id AA03828; Mon, 7 May 90 13:20:34 -0400 Received: from ico by haddock.ima.isc.com (5.61/1.36) id AA22163; Mon, 7 May 90 13:20:58 -0400 Received: by ico.isc.com (5.61/1.35) id AA00739; Mon, 7 May 90 11:14:36 -0600 Received: by stan.UUCP (smail2.5) id AA06715; 7 May 90 10:55:23 MDT (Mon) Received: from dancer.Solbourne.COM (dancer-gw) by Solbourne.COM (4.0/SMI-4.0) id AA06706; Mon, 7 May 90 10:55:18 MDT Received: by dancer.Solbourne.COM (4.0/SMI-4.0) id AA04231; Mon, 7 May 90 10:55:17 MDT Date: Mon, 7 May 90 10:55:17 MDT From: cfisun!ima.ima.isc.com!Solbourne.COM!ico.isc.com!imp (Warner Losh) Message-Id: <9005071655.AA04231@dancer.Solbourne.COM> To: minya!jc Subject: Re: Is the hostname "foo" or "foo.bar.com"? Newsgroups: comp.protocols.tcp-ip In-Reply-To: <380@minya.UUCP> References: <9005032308.AA14782@ucbvax.Berkeley.EDU> <18464@nigel.udel.EDU> Organization: Solbourne Computers Inc. Cc: | give me details and I will quote you RFC's. EVERY SMTP IMPLENETATION | MUST ACCEPT MAIL THAT IS GIVEN TO IT, EVEN IF IT LOOKS "Forged". Hmmm....If this is true, then there isn't, and never will be a compliant implementation, unless someone finds a way to build a computer with unlimited memory. All existing implementations are guaranteed to not accept mail when their file system is full. I've also been amused on many occasions by sendmail's "I refuse to talk to myself" message. This is one of the cleverest screwups, in which the mail actually makes it to the destination machine, and is rejected in a totally demented fashion. I suppose this could be a violation of the RFC, but my impression is that the authors of the program intended it to act that way, and they don't consider it a violation (or a bug). It's just a screwup on the part of the machine's administrator. "If you'd done it right, you wouldn't have problems." | >BTW, are you aware that there are systems being sold that limit hostnames | >(sometimes doubling as sysnames or nodenames) to 16 bytes? | | Those hosts are brain dead. They do not conform to the internet | standard of 256 characters in a host name. Limits on nodename that | never leave the machine are fine, but limits that are exported are as | bogus as 14 character file names. :-) I'm not sure I totally agree. Sure, I think the limit should be larger. But as for the idea that the designers of system X (e.g., the Internet) should come along and tell the designers of system Y (e.g., Sys/V) that "You don't do it our way, so you're brain dead", well, I'll reserve judgement. I've seen too much of this sort of thing, and it's a game that nobody wins. This is a Sys/V machine with a 9-byte limit to the sysname and the nodename. I would have made the limit larger, but in fact, it isn't a problem. These names clearly aren't supposed to include domain info. It makes a lot more sense to have the domain junk added by the mailer. One effect the small limit has had is that people who ported BSD software had to make sure it all allowed short names. I've found this to be a real advantage against the BSD-based systems where I must constantly type very long names. An interesting case arises when (as is true here) a machine is in more than one domain (.edu and .com), and there's no "correct" domain for the machine as a whole. This situation is the main reason (other than being a lazy typist ;-) that I personally prefer non-domainized hostnames. If your machine always identifies itself as being in exactly one domain, a lot of problems arise that are more easily solved if it doesn't know its own domain. It's useful to be able to partition the problems, and say that domains are email artifacts that are best localized in the mail software. In any case, I'm not trying to insult anyone (well, maybe a few :-). I'm looking at complicated software that doesn't work very well, people are saying incompatible things about the "right" way to do it, and I'd like to find out if there is indeed a right way. So far, the answer seems to be that various pieces of software decide that different ways are right, the standards don't give answers, so it'll remain a mess for some time. (It'll probably get straightened out when IBM comes along and says how we'll do it, and we'll be stuck with a bumbling, incompetent email system for the next 5 decades. ;-) Sigh. -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc -- If you're not part of the solution, you're part of the precipitate. [Kiel oni ^ci tiun diras esperante?] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051003361600> Received: from vm1.mcgill.ca by NIC.DDN.MIL with TCP; Thu, 10 May 90 04:41:21 PDT Received: from VM1.MCGILL.CA by vm1.mcgill.ca (IBM VM SMTP R1.2.1MX) with BSMTP id 5439; Thu, 10 May 90 07:39:23 EDT Received: by MCGILL1 (Mailer R2.05) id 7393; Thu, 10 May 90 07:39:21 EDT Date: Thu, 10 May 90 07:36:16 EDT From: Robert Craig Subject: tcp/ip for Prime To: tcp-ip@nic.ddn.mil I remember seeing a few months ago a message (I think it was on this list) concerning TCP/IP for Primes. We have a department with a Prime which they desperately want to connect, but can't afford the outrageous price for the ethernet adapter and TCP/IP that Prime wants to charge. The message seemed to imply that there were implementations of TCP/IP other than that sold by the vendor, which might cost significantly less. I've looked in the vendors' guide from the nic, but all I find in there is the stuff sold by Prime. Robert Craig domain: robert@vm1.mcgill.ca Network Analyst bitnet: robert@mcgill1 McGill University Computing Centre Tel: (514) 398-3710 (office) 805 Sherbrooke St. W. FAX: (514) 398-6876 Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051005471100> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Thu, 10 May 90 06:47:48 PDT Received: by gateway.mitre.org (5.54/SMI-2.2) id AA23044; Thu, 10 May 90 09:51:36 EDT Full-Name: Phil Mellinger Return-Path: Received: by blackhole.mitre.org (5.54/SMI-2.2) id AA04260; Thu, 10 May 90 09:47:11 EDT Date: Thu, 10 May 90 09:47:11 EDT From: melling@gateway.mitre.org Message-Id: <9005101347.AA04260@blackhole.mitre.org> To: tcp-ip@nic.ddn.mil Subject: IETF Security Cc: infsecur@smiley.mitre.org I am interested in finding out the role of the IETF security group (?) and which security issues it is dealing with in particular. What is its role/charter concerning security services? Phil Mellinger ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051006430800> Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 14:29:36 PDT Date: Thu 10 May 90 10:43:08 EDT From: Dan Lynch Subject: Re: Ingres certification of TCP/IP To: pollux!ccruss@ucdavis.ucdavis.edu cc: tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU In-Reply-To: <7303@aggie.ucdavis.edu> Message-ID: <12588577792.41.LYNCH@A.ISI.EDU> Russ, THis is interesting. I thought there was a vendor coalition of SQL providers that is called the SQL access group and that they were coming up with interoperability standards. Are they missing something you folks have latched on to? Roger Sippl of Informix is the chair of this group. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051006555000> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 10 May 90 13:55:39 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 10 May 90 13:55:50 -0700 Date: Thu, 10 May 90 13:55:50 PDT From: postel@venera.isi.edu Posted-Date: Thu, 10 May 90 13:55:50 PDT Message-Id: <9005102055.AA21563@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 10 May 90 13:55:50 PDT To: phri!news@nyu.edu Subject: What is the IAB? Cc: tcp-ip@nic.ddn.mil Roy Smith: Please see RFC-1120 for an explanation of the IAB. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051007101500> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 10 May 90 14:10:05 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 10 May 90 14:10:20 -0700 Date: Thu, 10 May 90 14:10:15 PDT From: postel@venera.isi.edu Posted-Date: Thu, 10 May 90 14:10:15 PDT Message-Id: <9005102110.AA21622@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 10 May 90 14:10:15 PDT To: phri!news@nyu.edu Subject: What is the IAB? Cc: tcp-ip@nic.ddn.mil Roy Smith: The Internet Activities Board (IAB) is the coordinating committee for Internet design, engineering and management. The Internet is a collection of over a thousand packet switched networks located principally in the U.S., but also includes systems in many other parts of the world, all interlinked and operating using the protocols of the TCP/IP protocol suite. The IAB is an independent committee of researchers and professionals with a technical interest in the health and evolution of the Internet system. Membership changes with time to adjust to the current realities of the research interests of the participants, the needs of the Internet system and the concerns of the U.S. Government, university and industrial sponsors of the elements of the Internet. IAB members are deeply committed to making the Internet function effectively and evolve to meet a large scale, high speed future. All IAB members are required to have at least one other major role in the Internet community in addition to their IAB membership. New members are appointed by the chairman of the IAB, with the advice and consent of the remaining members. The chairman serves a term of two years. [From RFC-1120] --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005101225.AA26854@ucbvax.Berkeley.EDU] <1990051011361600> From: ROBERT@VM1.MCGILL.CA (Robert Craig) Newsgroups: comp.protocols.tcp-ip Subject: tcp/ip for Prime Message-ID: <9005101225.AA26854@ucbvax.Berkeley.EDU> Date: 10 May 90 11:36:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Posted: Thu May 10 12:36:16 1990 I remember seeing a few months ago a message (I think it was on this list) concerning TCP/IP for Primes. We have a department with a Prime which they desperately want to connect, but can't afford the outrageous price for the ethernet adapter and TCP/IP that Prime wants to charge. The message seemed to imply that there were implementations of TCP/IP other than that sold by the vendor, which might cost significantly less. I've looked in the vendors' guide from the nic, but all I find in there is the stuff sold by Prime. Robert Craig domain: robert@vm1.mcgill.ca Network Analyst bitnet: robert@mcgill1 McGill University Computing Centre Tel: (514) 398-3710 (office) 805 Sherbrooke St. W. FAX: (514) 398-6876 Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051013022900> Received: from udel.edu (louie.udel.edu) by NIC.DDN.MIL with TCP; Thu, 10 May 90 06:49:43 PDT Received: from huey.udel.edu by louie.udel.edu id ad00787; 10 May 90 9:39 EDT Date: Thu, 10 May 90 13:02:29 GMT From: Mills@udel.edu To: brian donat cc: tcp-ip@nic.ddn.mil Subject: Re: gated Message-ID: <9005100902.aa00295@huey.udel.edu> briand, I'm not sure what you mean by cost metrics on the fuzzlings, but if you want more information, see my paper in SIGCOMM 88 and/or the info in the SRI Vendor's Guide. If that doesn't work, light a match in a dark corner of your junkbox and whisper "fuzzbug" and see if an old backplane comes to life. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051013201500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 07:28:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02854; Thu, 10 May 90 07:16:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 13:20:15 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!kaarne.tut.fi!jja@ucsd.edu (Ahola Jari) Organization: Tampere University of Technology, Finland Subject: Microsoft's ? SMB protocol - info needed. Message-Id: <13013@etana.tut.fi> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello all! Im in a desperate need of information concerning a PC protocol called SMB (Send Message Block ??) possibly by Microsoft. This protocol is at least used by DCA's networking software and I know that there is servers for Unix machines using this protocol. But I haven't succeeded to find any other information except what's in this message. So if YOU have any single piece of information about SMB, drop me a line. I'm especially interested to get my hands in the specification of SMB. -jja Jari 'jja' Ahola |Tampere University of Technology, Signal Processing Lab Opiskelijankatu 16A12 |P.O. Box 527, 33101 Tampere, Finland 33720 Tampere, Finland|Tel (intl) 358 31 162708 (work)/358 31 174009 (home) Puh. 931-174009 |Net address: jja@tut.fi, AHOLA@FINTUTA (BITNET), bix:jja ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005110237.AA15972@ucbvax.Berkeley.EDU] <1990051015020700> From: PIRARD@BLIULG11.BITNET (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for Kermit Protocol Manual Message-ID: <9005110237.AA15972@ucbvax.Berkeley.EDU> Date: 10 May 90 15:02:07 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Thu May 10 16:02:07 1990 > "Kermit, A File Transfer Protocol", Frank de Cruz Digital Press DEC 12 Crosby Drive Bedford Massach 01730 Order EY-6705E-DP > "Kermit Protocol Manual", Frank de Cruz The file KPROTO.DOC, maybe still missing the latest features. Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET. Andr). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051015074400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 08:30:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06537; Thu, 10 May 90 08:19:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 15:07:44 GMT From: phri!news@nyu.edu (Roy Smith) Organization: Public Health Research Institute, New York City Subject: What is the IAB? Message-Id: <1990May10.150744.12108@phri.nyu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil At the recent PSI Internetworking Tutorial, I asked two people who should have known the answer, "Exactly what *is* the Internet Activities Board?" and in both cases all I got were some random moderately derogatory comments but no real answer (which I found somewhat annoying, BTW). So, can anybody on this list answer my question? -- 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!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051017225900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 10:28:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04491; Thu, 10 May 90 10:23:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 17:22:59 GMT From: bu.edu!bu-it!kwe@uunet.uu.net (Kent England) Organization: Boston University Subject: Re: What is the IAB? Message-Id: <57064@bu.edu.bu.edu> References: <1990May10.150744.12108@phri.nyu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May10.150744.12108@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes: > > At the recent PSI Internetworking Tutorial, I asked two people who > should have known the answer, "Exactly what *is* the Internet Activities > Board?" and in both cases all I got were some random moderately derogatory > comments but no real answer (which I found somewhat annoying, BTW). > > So, can anybody on this list answer my question? > -- Some wires must have gotten crossed. It would be very strange indeed for anyone in PSI to take this view, since several of the principals at PSI have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and that work would be exactly nowhere without the IAB. Strange, indeed. The IAB is sponsored by the Federal Networking Committee (formerly the Federal Research Internet Coordinating Committee or FRICC). The FNC is made up of government agencies (DARPA, NSF, DoE, NASA, HHS, et al) that fund research and education networks, like NSFnet, ESnet, NSI, et al. The IAB has two steering committees reporting to it, one of which is responsible for the Internet Engineering Task Force. The IETF is where the engineering work of TCP/IP gets done, thru the WGs and the RFC process. IETF meets quarterly and the last meeting was just last week at PSC in Pittsburgh. The IETF is open and you can learn more by subscribing to ietf-request@venera.isi.edu. Vint Cerf is the Chair of the IAB and Phill Gross is the Chair of the IETF and perhaps they may have some words to say about the IAB. You can also learn a great deal more about the IAB by ftp'ing to nnsc.nsf.net and looking thru the directories there. There are charters and reports from all the IETF working groups, as well as drafts that might eventually be submitted as RFCs. Most WGs have active mailing lists that you can subscribe to and that info is on NNSC. The IAB and IETF are open, very open in my opinion. All you have to do is roll up your sleeves and decide to join the process and everyone will be delighted to have you participate in whatever you find interesting. It is much easier to participate in the IETF than any other standards process that I am aware of. Only vendors can afford ANSI, IEEE, and OSI (exaggeration, perhaps, but there are few users in those bodies). On the other hand, IETF is overwhelmingly attended by users and network managers, although vendors are well represented and take particular interest in those issues that affect their bottom lines. That's enough from me, but the IAB/IESG/IETF don't do as well as others at self promotion, so perhaps this exposition will be useful to some. As they say, enjoy. Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051017380100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 18:33:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11404; Thu, 10 May 90 18:20:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 May 90 17:38:01 GMT From: hsi!stevens@uunet.uu.net (Richard Stevens) Organization: Health Systems Intl., New Haven, CT. Subject: Re: Microsoft's ? SMB protocol - info needed. Message-Id: <1467@hsi86.hsi.UUCP> References: <13013@etana.tut.fi> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The references in %T OS/2 to UNIX LAN %A M. R. M. Dunsmuir %B UNIX Networking %E S. G. Kochan and P. H. Wood %I Howard W. Sams and Company %C Indianapolis, Ind. %P 237-284 %D 1989 state that "Server Message Block, Protocol Specification (Core, Extended, XENIX)" is published by Microsoft and is available from the OEM marketing department at Micrsoft. Richard Stevens Health Systems International, New Haven, CT stevens@hsi.com ... { uunet | yale } ! hsi ! stevens ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051018083100> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 05:39:01 PDT Received: from FRCCSC21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2563; Thu, 10 May 90 08:38:08 EDT Received: (from FRCCSC12 for via BSMTP) Received: (from SMTP@FRCCSC12 for MAILER@FRCCSC21 via NJE) (UCLA/Mail400 V1.417 A-RSCS1424-1424-31); Thu, 10 May 90 14:38:43 CET Received: from isis.u-strasbg.fr by FRCCSC12.U-STRASBG.FR (IBM VM SMTP R1.2.1) with TCP; Thu, 10 May 90 14:38:38 GMT Received: by isis.u-strasbg.fr (3.2/(JJP 13/2/90)) id AA12059; Thu, 10 May 90 14:48:31 +0200 Date: Thu, 10 May 90 14:48:31 +0200 From: root%ISIS.U-STRASBG.FR(Operator)@CUNYVM.CUNY.EDU Message-Id: <9005101248.AA12059@ISIS.U-STRASBG.FR> To: tcpipl@UNKNOWN.DOMAIN Subject: Setting multicast addresses Cc: hajjam@OSIRIS1.BITNET I am currently working on multicast protocols over Ethernet . Now my question: how is it possible to set multicast (ethernet) addresses, using streams, on a sun 3, SunOS4.0.3 ? If this is not possible using streams, are there any other simple solutions ? Thanks for your help moha hajjam@osiris1.u-strasbg.fr Universite louis Pasteur, Strasbourg , France ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051020220700> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 10 May 90 08:22:13 PDT Received: from VM1.EARN-ULG.AC.BE by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4719; Thu, 10 May 90 11:21:10 EDT Received: by BLIULG11 (Mailer R2.07) id 5753; Thu, 10 May 90 17:21:31 +0200 Date: Thu, 10 May 90 17:02:07 +0200 From: Andr'e PIRARD Subject: Re: Looking for Kermit Protocol Manual To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Wed, 9 May 90 20:44:09 GMT from > "Kermit, A File Transfer Protocol", Frank de Cruz Digital Press DEC 12 Crosby Drive Bedford Massach 01730 Order EY-6705E-DP > "Kermit Protocol Manual", Frank de Cruz The file KPROTO.DOC, maybe still missing the latest features. Open the mass of data with HELP mail to KERMSRV@CUVMA on BITNET. Andr). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051103200200> Received: from cheetah.nyser.net by NIC.DDN.MIL with TCP; Fri, 11 May 90 15:01:39 PDT Received: from localhost by cheetah.nyser.net at Fri, 11 May 90 15:00:09 -0700. (5.61.14/XIDA-1.2.8.34) id AA19063 for tcp-ip@nic.ddn.mil via SMTP To: john@pcsbst.pcs.com Reply-To: tcp-ip@nic.ddn.mil Cc: tcp-ip@nic.ddn.mil Subject: Re: In search of SNMP Sources In-Reply-To: Your message of 11 May 90 15:09:59 +0000. <1990May11.150959.26662@pcsbst.pcs.com> Date: Fri, 11 May 90 15:00:02 -0700 Message-Id: <19061.642463202@cheetah.nyser.net> From: Marshall Rose Get a copy of RFC1147 which should contain all the information you need. Also, please direct further questions regarding the SNMP, products, etc., to the snmp list. You can join by sending a note to snmp-request@nisc.nyser.net Thanks, /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051104300000> Received: from nrl3.arpa by NIC.DDN.MIL with TCP; Fri, 11 May 90 06:40:52 PDT Date: 11 May 90 09:30:00 EST From: "Carla" Subject: TCP-IP BULLETIN BOARD TOPIC To: "tcp-ip" I am the Bulletin Board manager at the Naval Research Laboratory's Central Computing Facility. I would like to subscribe to your topic board, TCP-IP. Please add the mailing address, CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list. If additional information is required, please send mail to BAZEMORE@CCF.NRL.NAVY.MIL. Thank you, Carla Bazemore (202) 767-3884 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051107254500> Received: from SPARK.BRL.MIL by NIC.DDN.MIL with TCP; Fri, 11 May 90 10:24:59 PDT Date: Fri, 11 May 90 11:25:45 EDT From: Don Merritt To: Joerg Hertzer cc: tcp-ip@nic.ddn.mil Subject: Re: "ttcp" program Message-ID: <9005111125.aa25411@SPARK.BRL.MIL> >In a c program I found the following coment: > >/* > * This program is based on the "ttcp" program originally developed by > * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery. > * Due to the large number of changes, however (asynchio, data checking, > * random length and offset, fake-data option, ...), it has effectively > * been completely rewritten. > */ > >Where can I get the original ttcp program or the mentioned improved version? The original ttcp program is available for anonymous ftp from vgr.brl.mil (26.2.0.29) in pub/ttcp.c Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005110935.AA03059@awssn3.rus.uni-stuttgart.de.] <1990051109351300> From: zrfp0128@AWSSN3.RUS.UNI-STUTTGART.DE (Joerg Hertzer) Newsgroups: comp.protocols.tcp-ip Subject: "ttcp" program Message-ID: <9005110935.AA03059@awssn3.rus.uni-stuttgart.de.> Date: 11 May 90 09:35:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 Posted: Fri May 11 10:35:13 1990 In a c program I found the following coment: /* * This program is based on the "ttcp" program originally developed by * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery. * Due to the large number of changes, however (asynchio, data checking, * random length and offset, fake-data option, ...), it has effectively * been completely rewritten. */ Where can I get the original ttcp program or the mentioned improved version? Thanks for your help Joerg Hertzer Computer Center University Stuttgart Allmandring 30 D-7000 Stuttgart 80 West Germany Phone: ++49-711-685-5803 Fax: ++49-711-682357 E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de (favored) hertzer@rus.uni-stuttgart.dbp.de S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de ZRFP@DS0RUS1I.bitnet "Life is satire" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051110104700> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 11 May 90 18:53:02 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 11 May 90 17:13:50 -0700 Date: Fri, 11 May 90 17:10:47 PDT From: postel@venera.isi.edu Posted-Date: Fri, 11 May 90 17:10:47 PDT Message-Id: <9005120010.AA27452@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Fri, 11 May 90 17:10:47 PDT To: mussar@bnr.ca Subject: Re: Obtaining PPP (draft) spec Cc: tcp-ip@nic.ddn.mil Hi. The PPP Specificarion id RFC-1134. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051112110500> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 11 May 90 15:55:22 PDT Received: from UNB.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57798; Fri, 11 May 90 18:52:06 EDT Received: by UNBMVS1 (Mailer 13.09) id 2390; Fri, 11 May 90 17:11:05 ADT Date: Fri, 11 May 90 16:11:05 EDT From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: tcp/ip for Prime In-Reply-To: Message of Thu, 10 May 90 09:57:29 ADT from Message-ID: I don't have an answer for you but am interested in the replies. Brian Kaye University Of New Brunswick On Thu, 10 May 90 09:57:29 ADT Robert Craig writes: > I remember seeing a few months ago a message (I think it > was on this list) concerning TCP/IP for Primes. We have > a department with a Prime which they desperately want to > connect, but can't afford the outrageous price for the > ethernet adapter and TCP/IP that Prime wants to charge. > The message seemed to imply that there were implementations > of TCP/IP other than that sold by the vendor, which might > cost significantly less. > > I've looked in the vendors' guide from the nic, but all I find > in there is the stuff sold by Prime. > > Robert Craig domain: robert@vm1.mcgill.ca > Network Analyst bitnet: robert@mcgill1 > McGill University Computing Centre Tel: (514) 398-3710 (office) > 805 Sherbrooke St. W. FAX: (514) 398-6876 > Montreal, Quebec H3A 2K6 CORISQ: (514) 398-RISQ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051113272400> Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Fri, 11 May 90 18:14:11 PDT Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 11 May 90 18:14:28 -0700 Received: from LiBai.UUCP by ultra.com (4.0/Ultra-1.2-02-12-90) id AA06900; Fri, 11 May 90 17:34:51 PDT Received: by LiBai.ultra.com (4.0/SMI-4.0) id AA18528; Fri, 11 May 90 20:27:24 PDT Date: Fri, 11 May 90 20:27:24 PDT From: LiBai!tinker@ames.arc.nasa.gov (Don Tinker) Message-Id: <9005120327.AA18528@LiBai.ultra.com> To: zrfp0128%awssn3.rus.uni-stuttgart.de@ames!RELAY.CS.NET Cc: tcp-ip@NIC.DDN.MIL In-Reply-To: Joerg Hertzer's message of Fri, 11 May 90 11:35:13 +0200 <9005110935.AA03059@awssn3.rus.uni-stuttgart.de > Subject: "ttcp" program > >In a c program I found the following coment: > >/* > * This program is based on the "ttcp" program originally developed by > * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery. > * Due to the large number of changes, however (asynchio, data checking, > * random length and offset, fake-data option, ...), it has effectively > * been completely rewritten. > */ > >Where can I get the original ttcp program or the mentioned improved version? What you have is a copy of a program "tsock", written by the folks at Ultra Network Technologies (my company) in order to test high-performance i/o through high-performance networks. I'll mail you a copy, and because this is the third or fourth request for it I've gotten lately, I'll see about putting it on someplace ftp-able-to. Don Tinker tinker@ultra.com Senior Field Support Engineer {core}!ames!ultra!tinker UltraNetwork Technologies Inc. (703) 821-8393 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051113410000> Received: from jetson.uh.edu by NIC.DDN.MIL with TCP; Fri, 11 May 90 16:42:45 PDT Date: Fri, 11 May 90 18:41 CDT From: Buckaroo Bonzai and the Team of Baker Street Irregulars Subject: this is a test... disregard if you receive this To: NEXT-L@BROWNVM.BITNET, INFO-UNIX@BRL.ARPA, TCP-IP@NIC.DDN.MIL, DLV@CUNYVMS1.BITNET, GAELIC-L@IRLEARN.BITNET, Info-Mac@sumex-aim.stanford.edu, space+@andrew.cmu.edu, I-PACRAD@UIUCVMD.BITNET, Packet-Radio@UCSD.Edu, Info-IBMPC@WSMR-SIMTEL20.ARMY.mil Message-id: <97893724DF5FA06DDD@jetson.uh.edu> X-Envelope-to: TCP-IP@NIC.DDN.MIL X-VMS-To: @DISB.LIS X-VMS-Cc: ELEE6WK this is a test.. please disregard if you get this... my mail router here at the university of houston has died a death or two. william sanders, a subscriber to this list ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005111447.AA25540@ucbvax.Berkeley.EDU] <1990051114300000> From: bazemore@CCF3.NRL.NAVY.MIL ("Carla") Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP BULLETIN BOARD TOPIC Message-ID: <9005111447.AA25540@ucbvax.Berkeley.EDU> Date: 11 May 90 14:30:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Fri May 11 15:30:00 1990 I am the Bulletin Board manager at the Naval Research Laboratory's Central Computing Facility. I would like to subscribe to your topic board, TCP-IP. Please add the mailing address, CCF_BITNET@CCF.NRL.NAVY.MIL, to your distribution list. If additional information is required, please send mail to BAZEMORE@CCF.NRL.NAVY.MIL. Thank you, Carla Bazemore (202) 767-3884 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051114371200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 07:49:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25267; Fri, 11 May 90 07:42:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 14:37:12 GMT From: crdgw1!gecrdvm1!hathawa@uunet.uu.net (Barry Hathaway) Organization: General Electric Corporate Research & Development Subject: tn3270 for Suns Message-Id: <90131.103712HATHAWA@gecrdvm1.crd.ge.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This is a reposting of an earlier note in hopes that someone can help me find a tn3270 that works correctly. HELP! Thanks in advance. Recently I retreived the latest version (4.1.1) of tn3270 from Berkeley and have been playing around it. The reason I went to the new version was that our prior version had cursor positioning problems. When users would tn3270 to our VTAM session manager (Netview/Access Services) on MVS the cursor would appear 1 position to the left of the first (userid) unprotected field on the screen - so if the user wanted to enter his userid he would have to move the cursor one position to the right. This only seemed to happen with this particular application. Happily, Version 4.1.1 fixed that problem; however, it introduced a much more serious problem - improper highlighing. (Note: the termcap entry is set up to do bold instead of reverse video.) In some, but important, applications some things are hightligted when they are not supposed to be. I have seen this most in IDMS applications. For example: in one application the date and time appears in the upper right corner of the screen and the lower portion of the screen contains a number of unprotected fields, and some highlighted fields. When you press enter or a PF key the application does some things and updates the time in the upper right corner. When it does this the seconds become highlighted. If one waits until the minute changes then the minutes will also become highlighted. This is only one example, but it happens often. Apparently some strange cursor positioning orders are generated by IDMS. This did not seems to happen in the older version (unknown version) of tn3270. Any ideas? Is anyone else having the same problem? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051114551300> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 11 May 90 02:37:04 PDT Received: from iraun1.ira.uka.de by RELAY.CS.NET id aa23450; 11 May 90 5:36 EDT Received: from noc.belwue.de by iraun1.ira.uka.de id aa06312; 11 May 90 11:35 MET DST Received: from awssn3.rus.uni-stuttgart.de (awssn3.rus.uni-stuttgart.de) by noc.belwue.de (4.0/BelWue-1.0(main)) id AA02708; Fri, 11 May 90 11:32:24 +0200 Received: by awssn3.rus.uni-stuttgart.de (4.0/BelWue-1.0(subsidiary)) id AA03059; Fri, 11 May 90 11:35:13 +0200 Date: Fri, 11 May 90 11:35:13 +0200 From: Joerg Hertzer Message-Id: <9005110935.AA03059@awssn3.rus.uni-stuttgart.de > To: tcp-ip@NIC.DDN.MIL Subject: "ttcp" program In a c program I found the following coment: /* * This program is based on the "ttcp" program originally developed by * T.C. Slattery, USNA, and improved by Mike Muuss and Terry Slattery. * Due to the large number of changes, however (asynchio, data checking, * random length and offset, fake-data option, ...), it has effectively * been completely rewritten. */ Where can I get the original ttcp program or the mentioned improved version? Thanks for your help Joerg Hertzer Computer Center University Stuttgart Allmandring 30 D-7000 Stuttgart 80 West Germany Phone: ++49-711-685-5803 Fax: ++49-711-682357 E-Mail: zrfp0128@awssn3.rus.uni-stuttgart.de (favored) hertzer@rus.uni-stuttgart.dbp.de S=hertzer;OU=rus;P=uni-stuttgart;A=dbp;C=de ZRFP@DS0RUS1I.bitnet "Life is satire" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051115095900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 10:20:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04394; Fri, 11 May 90 10:11:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 15:09:59 GMT From: mcsun!unido!fauern!tumuc!guug!pcsbst!john@uunet.uu.net (John Ludbrook (Marketing)) Organization: PCS Computer Systeme, GmbH Subject: In search of SNMP Sources Message-Id: <1990May11.150959.26662@pcsbst.pcs.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi Networkers, I am currently seeking SNMP Source to run on UNIX V.3.2 and have only the names of the following companies/ institutes ( but no contacts) : Epilogue Technologies MIT ( Network Manager Lab.?) Perfomance Systems International SNMP Research Netlabs Carnegie Mellon University Can anyone help out with names, phone/fax nos., mail addresses etc? appreciate your help. john ludbrook ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051115183100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 14:52:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20913; Fri, 11 May 90 14:48:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 15:18:31 GMT From: hercules!sparkyfs!arsocomvax.socom.mil!news@apple.com (Ted Nolan) Organization: SRI International, Ft. Bragg NC Subject: 4.3BSD VAX/sendmail vs Sperry 5000/MMDF? Message-Id: <1990May11.151831.29755@arsocomvax.socom.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm having kind of a strange problem. For our mailhost and gateway, we have a Vax 11/780 running (fairly vanilla) 4.3BSD (with a recent sendmail). This vax sits on our ethernet and has an ACC ACP6250 connection to our MILNET PSN. Recently we've had users trying to send mail to a couple of Serry-5000/80 Unix systems running MMDF as the SMTP server. The mail never gets there, sitting queued on a "Bad file number". Here's the strange part. From the vax, I can telnet to both of these hosts with no problem (quite a good connection as a matter of fact). However, if I try to manually talk to the SMTP server (for example): telnet fulda-emh1.army.mil 25 I get: Trying... Connected to fulda-emh1.army.mil. Escape character is '^]'. Connection closed by foreign host. And the connection closes immediately, before getting any response from MMDF. This is apparently the same thing sendmail sees when it declares a "bad file number". But, if I try the same thing from one of our Suns, which all use the vax as a gateway, I get a connection with no problem: telnet 26.14.0.175 25 Trying 26.14.0.175 ... Connected to 26.14.0.175. Escape character is '^]'. 220 s5000 Server SMTP (Complaints/bugs to: mmdf@fulda-emh1.army.mil) Are there any known problems between 4.3 and Sperry? Since telnet doesn't work on port 25 either, I don't really think it's a sendmail/mmdf problem.. Thoughts appreciated, Ted Nolan ted@usasoc.soc.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051116490200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 10:50:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06186; Fri, 11 May 90 10:42:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 16:49:02 GMT From: usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!cunews!bcars8!bnrgate!bigsur!bcars53!mussar@ucsd.edu (G. Mussar) Organization: Bell-Northern Research, Ottawa, Canada Subject: Obtaining PPP (draft) spec Message-Id: <1990May11.164902.5326@bigsur.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Can anyone tell me where to find the PPP spec. Is it sitting as an RFC at the NIC? Email to either of the addresses should reach me (but I have never tried them myself). Thanks in advance. -- ------------------------------------------------------------------------------- Gary Mussar |Bitnet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | UUCP: ..uunet!bnrgate!bcars53!mussar | FAX: (613) 763-2626 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051117372200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 11:07:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07132; Fri, 11 May 90 10:57:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 17:37:22 GMT From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu (Steve Dempsey) Organization: Engineering College, Colorado State University Subject: BSD networking installation Message-Id: <6832@ccncsu.ColoState.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've been playing with the [March '89] BSD networking code, (ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and incorporating pieces of it into Ultrix3.1. I've had a bit of difficulty getting the ICMP record-route to work correctly. Specifically, icmp_reflect() in ip_icmp.c contains the following: * @(#)ip_icmp.c 7.8.1.2 (Berkeley) 3/2/89 /* Retrieve any source routing from the incoming packet; * add on any record-route or timestamp options. */ [much code deleted] /* Now strip out original options by copying rest of first * mbuf's data back, and adjust the IP length. */ ip->ip_len -= optlen; ip->ip_hl = sizeof(struct ip) >> 2; /*XX*/ m->m_len -= optlen; optlen += sizeof(struct ip); bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1), /*XX*/ m->m_len - sizeof(struct ip)); It's obvious that the variable m in the marked lines is a pointer to struct mbuf, but m is neither referenced nor declared in this routine, nor anywhere else that I can find. I've tried various things to get this to work and have not yet found a stable solution; my kernel debugging skills are sorely lacking. So my questions are: has anyone fixed this, and where might I find the right code? Steve Dempsey, Center for Computer Assisted Engineering Colorado State University, Fort Collins, CO 80523 +1 303 491 0630 INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051117491400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 11:07:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07435; Fri, 11 May 90 11:02:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 17:49:14 GMT From: ccncsu!longs.LANCE.ColoState.Edu!steved@boulder.colorado.edu (Steve Dempsey) Organization: Engineering College, Colorado State University Subject: BSD networking installation Message-Id: <6834@ccncsu.ColoState.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've been playing with the [March '89] BSD networking code, (ftp'd from uunet:bsd-sources/src/network/sys.tar.Z) and incorporating pieces of it into Ultrix3.1. I've had a bit of difficulty getting the ICMP record-route to work correctly. Specifically, icmp_reflect() in ip_icmp.c contains the following: * @(#)ip_icmp.c 7.8.1.2 (Berkeley) 3/2/89 /* Retrieve any source routing from the incoming packet; * add on any record-route or timestamp options. */ [much code deleted] /* Now strip out original options by copying rest of first * mbuf's data back, and adjust the IP length. */ ip->ip_len -= optlen; ip->ip_hl = sizeof(struct ip) >> 2; /*XX*/ m->m_len -= optlen; optlen += sizeof(struct ip); bcopy((caddr_t)ip + optlen, (caddr_t)(ip + 1), /*XX*/ m->m_len - sizeof(struct ip)); It's obvious that the variable m in the marked lines is a pointer to struct mbuf, but m is neither referenced nor otherwise declared in this routine, nor anywhere else that I can find. I've tried various things to get this to work and have not yet found a stable solution; my kernel debugging skills are sorely lacking. So my questions are: has anyone fixed this, and where might I find the right code? Steve Dempsey, Center for Computer Assisted Engineering Colorado State University, Fort Collins, CO 80523 +1 303 491 0630 INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051118103500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 11:52:01 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08561; Fri, 11 May 90 11:20:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 18:10:35 GMT From: usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens) Organization: PUCC UNIX Group Subject: Re: BSD networking installation Message-Id: <10679@mentor.cc.purdue.edu> References: <6832@ccncsu.ColoState.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil *** /tmp/,RCSt1019886 Fri May 11 13:07:41 1990 --- ip_icmp.c Tue Jun 13 00:18:11 1989 *************** *** 349,354 **** --- 349,355 ---- register struct in_ifaddr *ia; struct in_addr t; struct mbuf *opts = 0, *ip_srcroute(); + struct mbuf *m = dtom(ip); int optlen = (ip->ip_hl << 2) - sizeof(struct ip); t = ip->ip_dst; -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051118413100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 21:52:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13791; Fri, 11 May 90 21:36:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 18:41:31 GMT From: voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU (Kwang Sung) Organization: Informix, Menlo Park, Ca. U.S.A. Subject: Re: comparision of sockets to tli Message-Id: <4224@infmx.UUCP> References: <1990May9.210441.4731@cbnewsh.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >From: fsi@cbnewsh.att.com (furrokh.s.irani) >Organization: AT&T Bell Laboratories > > Does anyone have a comparision of the 'TLI' interface versus >the 'socket' interface? > Please email to att!odyssey!fsi. Thanks v. much. >-Furrokh S. Irani Dear Mr. Furrokh Irani: Currently, I am not working on 'TLI' or 'socket', but here are the differences I can think of. 1. In order to establish a transport endpoint.... TLI: "t_open" call which can open any minor devices. Those devices can be shared by unrelated processes. Sockets: "socket" call which uses different parameters such as type, domain, protocol. It can not access a minor device which is already opened, except if the processes are related. 2. In order to establish a connection... TLI: "t_listen" call which can be done without accepting a connection. One can listen multiple times without accepting a connection. "t_bind" call will set the queue length for the incoming connections. "t_connect" is used for connection with another transport user. The endpoint should be bound to a protocol address before that. Sockets: "listen" call which is followed by an "accept". This is necessary as "listen" only sets the queue length. "connect" used for connection initiation. It's possible to connect without being bound to a protocol address. 3. In order to accept a connect request... TLI: "t_accept" can be used. You have to allocate a file descriptor, upon which the connection is accepted. This will give more flexibility of accepting the connection. It also give the option of not accepting, or delaying for the multiple t_listens. It's possible to accept connection request in any order. Sockets: "accept" can be use, which returns a socket file descriptor. It's not possible to select which connect request to accept. 4. For user date on connection or disconnection... TLI: One can receive the user data in the "t_listen". One can send the user data in both the "t_connect", and the "t_accept". One can both send and receive the user data on all the disconnection primitives. This will be determined by "t_getinfo". Sockets: There is no concept of sending or receiving the user data on any of the connection/disconnection primitives. 5. For the asynchronous processing... TLI: It's possible to send connection request, and receive asynchrously thru "t_sndconnect" and "t_rcvconnect". Sockets: It has similar feature, but one can get errors and will be lost after an asynchronous operation. 6. For getting address info for an established connection... TLI: It's not possible to get the connection address info, but one can get the connection status. Sockets: "getsockname", "getpeername" will give the address info. 7. For the data transfer... TLI: MORE_flag specifies record boundaries. Sockets: There is no way of reading/writing partial records. 8. For the urgent or out of band data... TLI: The only way is to read all the data, and then find out in the data queue. Sockets: The socket can be registered to receive a SIGURG signal. 9. For other misc.... TLI: On System V.3, one has to push "tirdwr" module, otherwise Read/Write will fail. Sockets: Read/Write calls work directly on a socket. 10. Other problems on TLI... The interactions between the "t_listen" and "t_accept" is too tight. The "t_snd" should permit a scatter/gather array for an argument. --- By the way, please don't trust TLI !! There are a lot other problems on TLI implementation besides the above. It was actually poorly designed. But still you can migrate to OSI world easily, since it was modelled after ISO 8072. That's why I am enjoying OSI protocols now. Thanx. Kwang Sung Informix Software, Inc. 4100 Bohannon Dr. Menlo Park, CA 94025 415 / 926 - 6758 (O) UUCP: ...!uunet!infmx!kwang ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051122004000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 20:36:01 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA10095; Fri, 11 May 90 20:27:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 22:00:40 GMT From: snorkelwacker!bu.edu!mirror!redsox!campbell@tut.cis.ohio-state.edu (Larry Campbell) Organization: The Boston Software Works, Inc. Subject: Re: Microsoft's ? SMB protocol - info needed. Message-Id: <1566@redsox.bsw.com> References: <13013@etana.tut.fi> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <13013@etana.tut.fi> jja@kaarne.tut.fi (Ahola Jari) writes: -Im in a desperate need of information concerning a PC protocol called SMB -(Send Message Block ??) possibly by Microsoft. It's "Server Message Block". Perhaps this is just too obvious, but why don't you call Microsoft and ask them? It's their protocol. -- Larry Campbell The Boston Software Works, Inc. campbell@redsox.bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02109 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051122042900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 11 May 90 15:35:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22008; Fri, 11 May 90 15:05:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 May 90 22:04:29 GMT From: usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu (Kent England) Organization: Boston University Subject: Re: What is the IAB? Message-Id: <57149@bu.edu.bu.edu> References: <57064@bu.edu.bu.edu>, <1990May10.150744.12108@phri.nyu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I said: > The IAB is sponsored by the Federal Networking Committee (formerly >the Federal Research Internet Coordinating Committee or FRICC). in my response to Roy Smith's question, and some people took pains to point out to me that sponsor is an unfortunate term. The IAB is independent of the FNC, even though the FNC does contribute funds to the operation of the IAB, and obviously serves a wider constituency that simply the FNC agencies. Perhaps "support" is a better term? --Kent "not a spokesman for the IAB" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051201503800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 14 May 90 00:07:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA11112; Sun, 13 May 90 23:55:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 01:50:38 GMT From: van-bc!mplex!fff@ucbvax.Berkeley.EDU (Fred Fierling) Organization: Microplex Systems Ltd Subject: thin ethernet tcpip to printer interface Message-Id: <446@mplex.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a device which: - connects a single parallel port of a printer to a thin ethernet - allows a host running tcp/ip to spool data to it - costs less than $1k ? -- Fred Fierling uunet!van-bc!mplex!fff Tel: 604 875-1461 Fax: 604 875-9029 Microplex Systems Ltd 265 East 1st Avenue Vancouver, BC V5T 1A7, Canada ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051211020900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 12 May 90 04:22:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01094; Sat, 12 May 90 04:11:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 11:02:09 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!chic@ucsd.edu (Chris C. L. CHING) Subject: (HELP!) Question on socket (Datagram) Message-Id: <3973@munnari.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, I got a problem of using socket on sun. The "recmsg" call is supposed to wait for a message to arrive if no messages are available at the socket. But I don't know why it does not do that in my program. My program terminated normally and received 0 byte. I was running my program in SunOS 4.0.3 environment. Does anyone know how to solve my problem? Thanks in advance. Here is my program ------------------------------------------------------------------------- #include #include #include #include #include #include #define NAME "sock" #define NAMESIZE 256 #define STDOUT 1 extern int errno; caddr_t malloc(); main() { int sd; int fd; int nc; struct sockaddr_un master; struct msghdr *msg; struct iovec *iobuf; sd = socket(AF_UNIX, SOCK_DGRAM,0); /* datagram */ iobuf = (struct iovec *) malloc(sizeof(struct iovec)); msg = (struct msghdr *) malloc(sizeof(struct msghdr)); bzero ((char *) msg, sizeof *msg); msg->msg_name = (caddr_t) malloc(NAMESIZE); msg->msg_namelen = NAMESIZE; msg->msg_iov = iobuf; msg->msg_iovlen = 1; msg->msg_accrights = (caddr_t) malloc(NAMESIZE); msg->msg_accrightslen = NAMESIZE; master.sun_family = AF_UNIX; strcpy(master.sun_path, NAME); if (bind(sd, (struct sockaddr *)&master, strlen(master.sun_path) + sizeof(master.sun_family))<0) { perror("bind"); } if ((nc = recvmsg(sd, msg, 0))<0) perror("recverr"); fd = *((int *) msg->msg_accrights); close(sd); unlink(NAME); } --------------------------------------------------------------------------- |Chris Ching |The University of Melbourne |Department of Computer Science |Parkville, 3052, Australia |ACSNET: chic@munmurra.cs.mu.OZ.AU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051214394800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 12 May 90 15:36:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03622; Sat, 12 May 90 15:31:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 14:39:48 GMT From: mcsun!unido!uklirb!incas!popper!zessel@uunet.uu.net (Holger Zessel) Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!) Message-Id: <4411@incas.informatik.uni-kl.de> References: <23170@joshua.athertn.Atherton.COM>, <3270023@hpctdkp.HP.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil jeff@hpctdkp.HP.COM (Jeff Hughes) writes: >>Your cache will not ensure execute at most once behavior. Think about >>a server and three clients. The server gets an RPC from client 1, >>then 2, then 3. But it must trash the cache from client 1 in order >>to store client 3's result. Now it gets a resend from client 1; it >>will execute the service routine a second time. >>The trick to caching UDP/RPC results it to cache exactly one result for >>each client the server has. The cost is 8K per client, max. You never >>need to cache more than one response from each client, since a client >>will only send a new RPC only if the old one has been completed. >This is a good idea. I believe there are some exceptions to the 1 reply >per request rule, however. I believe the "spray" application will blast >a host with a number of packets before requiring a reply. There is no need to implement a cache for RPC replies in UDP. At least RPC3.9 and 4.0 contain a call "svcudp_enablecache" which does exactly what you want ! Its arguments are the transp and the cachesize. The cache is implemented as a fifo. With cache enabled RPC will cache every sent reply until it has to be trashed as the fifo pointer is at the same cell again. You don't have to worry about collisions between client replies. The cache can distinguish between all clients and all their messages using the RPC transaction id's and the sockaddr_in structure of the clients (and some other additional values). I used it successfully in a not-in-kernel implementation of an NFS server. I first noticed its correct working every time in dbx where clients always time out when I single step through the server code. I added some "sent cached reply"-line to RPC which told me it worked. BUT BEWARE ! In some RPC3.9 the cache is ok. In 4.0 a simple bug was introduced. Therefore the cache did not work for SunOS4.03. As I had to use our suns I took RPC4.0 sources and made a really LITTLE patch to them: In file rpc/svc_udp.c, routine svcudp_recv, which is called by the server getting packets from the clients. ....getting a packet through recvfrom... ....some xdr managing... and now: /* comments are mine */ if (su->su_cache != NULL) { /* cache yes/no */ if (cache_get(xprt, msg, &reply, &replylen)) { /* cache hit ? */ /* yes ! a hit ! therefore send stored reply ! */ (void) sendto(xprt->xp_sock, reply, (int) replylen, 0, (struct sockaddr *) &xprt->xp_raddr, xprt->xp_addrlen); fprintf(stderr,"Sending cached reply...\n"); /* my debug line !*/ return (FALSE); /* Here was TRUE before !!! And this was the bug ! Returning true causes the the serverfunction to be called despite a reply was sent already ! */ } ... I hope that helps some other people trying to use the cache too. Keep hacking ! Holger >jeff@hpctdlb.hp.com ---------------------------------------------------------------- Holger Zessel, uucp: ...!uunet!unido!uklirb!incas!zessel or zessel@informatik.uni-kl.de or zessel%informatik.uni-kl.de@relay.cs.net (from usa) Fachbereich Informatik, SFB124-D1 Universitaet Kaiserslautern, West-Germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051218294300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 13 May 90 21:52:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04341; Sun, 13 May 90 21:48:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 18:29:43 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) Organization: Polygen Corporation, Waltham, MA Subject: rwhod problems with Xenix/286 Message-Id: <799@tzu.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I installed Xenix/286 2.3.2, and Excelan's LAN Workplace for Xenix/286 and have noticed a problem. When the system starts up, everything starts up great, ecept for the rwhod program. When the rc script file is excecuted, I get the following message: rwhod: send:Bad address I have all my routing info set up, the Excelan driver works perfectly. Any help would greatly be apprecited. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | | bill@polygen.com | +-----------------+---------------------------+-----------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051218350300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 13 May 90 21:52:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04358; Sun, 13 May 90 21:49:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 18:35:03 GMT From: bu.edu!polygen!bill@uunet.uu.net (Bill Poitras) Organization: Polygen Corporation, Waltham, MA Subject: ftp on Xenix/286 Message-Id: <800@tzu.UUCP> References: <799@tzu.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a 386SX system set up with Xenix/286 2.3.2, and Excelan's LAN Workplace for Xenix/286. When I use ftp, after every command, I get "error on read". During a get, I get it multiple times. TFM (as in RTFM :-) doesn't tell me squat. Telnet works great, and installation went by flawlessly. The only other problem is when rwhod gets installed, but thats a different problem. Thanks for any help you can give me. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | | bill@polygen.com | +-----------------+---------------------------+-----------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051218580600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 12 May 90 12:21:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22956; Sat, 12 May 90 12:15:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 May 90 18:58:06 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!lth.se!newsuser@ucsd.edu (Jan Engvald) Organization: Communication Systems, Lund Institute of Technology, Sweden Subject: Re: Lantastic vs. the World - Problems? Message-Id: <1990May12.185806.27545@lth.se> References: <11484@cbmvax.commodore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <11484@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: >One of our user areas here has decided that they want to use one of those >PC network products call "Lantastic" with WD8003 Ethernet cards. Up to >now our LAN has been exclusivly TCP/DECnet/XNS and we've standardized on >3c503 cards for PC's. > >The apparent reason for going with the WD8003 cards is lack of Netbios >support for the 3c503. I find this somewhat hard to argue with. > >Has anyone had any interoperbility problems with Lantastic and traditional >protcols on the same Ethernet? I know there shouldn't be, but I'd like be >sure before these guys commit (me) to a bunch of new hardware and software. > >Is the Lantastic stuff yet another unique proprietary protocol or is it >related to something more generic? Don't run Lantastic on a big LAN or you can expect interference with other protocols sooner or later. We have had to forbid Lantastic nets to be connected to our backbone because it upsets our HP computers (HP 3000 type). The reason for this is that Lantastic is NOT runing ethernet 2 protocol (which have protocol id in byte 13-14 of the ethernet packet), but is using an ISO-like packet (with a length in byte 13-14). However, they don't continue like an ISO-packet, instead of required headers they have their own data. This confuses for all of those that uses ISO-packets the right way (or almost right :-). I know for sure that it affects HP Advancenet used by HP 3000 computers. I expect it will affect DECnet phase 5 too and also ISO IP protocols. There are two ways for the Lantastic developers to fix it: - They can make it an ethernet 2 packet by applying for a unique protocol id that they can put into byte 13-14. - They can add the required ISO headers after byte 14. I have several times sent the above info to the Lantastic developers (and Lantastic engineering management have visited me to discuss it!!), but as of yet they have not changed their protocol. Its a pity, because Lantastic is otherwise a very good low cost network. Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: xjeldc@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%24020031020720::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=Delta; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051302040500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 13 May 90 01:36:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03894; Sun, 13 May 90 01:27:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 May 90 02:04:05 GMT From: sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU (Vernon Schryver) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: "ttcp" program Message-Id: <60091@sgi.sgi.com> References: <9005110935.AA03059@awssn3.rus.uni-stuttgart.de.>, <9005120327.AA18528@LiBai.ultra.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Ttcp is handy for tuning a TCP or UDP implementation. Versions of ttcp can be found in sgi/src on sgi.sgi.com, currently 192.48.153.1. ttcp.c.brl is the most recent BRL version I've seen. Ttcp.shar is from last August. Ttcp.c is our current understanding of what was acceptable to BRL. It includes controls for buffer alignment and other things. By default it is a file transfer program, needing '-s' to make it generate and sink data as a test program. I think there are also versions available from BRL, perhaps on brl.mil. They are probably newer than sgi:.../ttcp.c.brl. Ttcp has never appeared in comp.sources.unix, although I understood from the moderator that it would someday. If you buy a Silicon Graphics "IRIS", you'll find ttcp.c among other example and test programs in /usr/people/4Dgifts. There was some hassle with the port number. The original port 2000 conflicted with a certain solar window manager, currently the default window manager for SGI. BRL and SGI checked with the Net Gods about getting an official port number for ttcp, but failed. Be careful to understand the numbers people give you. Not long ago a vendor trying to sell stuff gave me what I thought were some good numbers. A few weeks later they happened to mention to some of my colleagues that the numbers were obtained by summing some simultaneous tests. It is as they say, "lies, damn lies, and benchmarks." Vernon Schryver Silicon Graphics vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051302244300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 12 May 90 19:51:13 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16835; Sat, 12 May 90 19:50:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 May 90 02:24:43 GMT From: watson!sob@tmc.edu (Stan Barber) Organization: Baylor College of Medicine, Houston, Tx Subject: Re: PC-LAN connection to Usenet Message-Id: <870@gazette.bcm.tmc.edu> References: <2744@psueea.UUCP>, <2745@psueea.UUCP>, <798@banyan.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <798@banyan.UUCP> gordon@banyan.com (Gordon Lee@Eng@Banyan) writes: >For cases where you have an Internet connection, it is possible to write >an NNTP server for an OS/2 machine. The NNTP protocol can run over any >stream oriented transport protocol, of course the protocol of choice would >be TCP/IP stack since NNTP implementations within USENET are usually talking >TCP/IP, (I haven't heard of an implementation which uses a different protocol). The "canonical" NNTP for Unix has supported TCP/IP and DECNET for a very very long time. There is an implementation that run on VMS that supports TCP/IP and DECNET. There are rumors of other implementations (on VM) that may support other transports. Please see "news.announce.newusers" for the "USENET: History and Sources" posting for more information on NNTP and the platforms is it available on. Maintainer of NNTP and RN/RRN, -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: {rutgers,mailrus}!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051304585100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 15 May 90 13:10:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17938; Tue, 15 May 90 13:01:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 May 90 04:58:51 GMT From: iscden!jbev@boulder.colorado.edu (J.Bevier @ Home on Hipeak) Organization: J B Systems @ home on HiPeak, Morrison, Co. Subject: tcp/ip software Message-Id: <200@iscden.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for public domain software for tcp, ip, tftp, ftp, and telnet. I am doing a port to a new environment and need all of the software. Could someone please direct me to an archive site or UUCP site were I can download the the software. Thanks, Jim Bevier --- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+ From the mountains of Colorado: +=+ +=+ when it's not snowing, the sun is shining +=+ +=+ Jim Bevier - J B Systems (303)-697-1038 +=+ +=+ 10136 Horizon View, Morrison, CO 80465 +=+ +=+ jbev@iscden.UUCP or ...!boulder!iscden!jbev +=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051314284900> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Sun, 13 May 90 18:12:35 PDT Received: from [127.0.0.1] by NRI.NRI.Reston.VA.US id aa18312; 13 May 90 21:08 EDT To: tcp-ip@nic.ddn.mil cc: jif@venera.isi.edu Subject: What is the IAB? Date: Sun, 13 May 90 21:08:49 -0400 From: vcerf@NRI.Reston.VA.US Message-ID: <9005132108.aa18312@NRI.NRI.Reston.VA.US> Roy Smith: Please see RFC 1120 which you can obtain by anonymous FTP from the DDN NIC (nic.ddn.mil). This RFC will be updated soon to reflect the addition of several new members to the IAB (Tony Lauck from Digital Equipment Corporation and Lyman Chapin of Data General - who is also chairman of ANSI X3S3.3). Those interested in IAB actions may find monthly summaries in the Internet Monthly published by Joyce K. Reynolds and Jonathan Postel of USC-ISI. The Executive Director of IAB is Bob Braden also of ISI. Vint Cerf Chairman, IAB Corp. for National Research Initiatives ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051322204900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 13 May 90 15:39:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13491; Sun, 13 May 90 15:31:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 May 90 22:20:49 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <23178@bellcore.bellcore.com> References: <1158@tnosoes.UUCP>, <56957@bu.edu.bu.edu>, <1159@tnosoes.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a few comments on the use of gateway filtering for security purposes. In my opinion, it is suitable only as a temporary, emergency response to an actual attack, and for "buying time" until the security holes in individual hosts can be fixed. It is admittedly preferable to going off the Internet entirely. As standard operating procedure, however, gateway filtering has two serious drawbacks: 1. It makes life much more difficult for the legitimate users. You are often forced to "stage" your operations through a "secure" gateway. This is not the seamless, easy-to-use network that the Internet was supposed to be all about. 2. It is not entirely secure, either. The usual goal in gateway filtering is to allow locally originated connections to go out while keeping externally originated ones from coming in except to specified hosts. But an IP router is a connectionless entity, so this can only be done heuristically, typically by violating layering and examining the destination port fields of the TCP and UDP headers. Although it is currently fashionable to think of the "layering violation" as an obsolete taboo, experience has taught me to stop and think hard before committing one because they have a way of coming back to bite you, albeit not for a while. The problem here is that "only the hosts know for sure" when it comes to the meaning of a port number. True, *most* do adhere to Internet convention in that servers usually listen on ports less than 1000 while clients usually originate using ports above 1000, so a gateway that discards incoming packets destined to ports below 1000 *usually* has the desired effect of allowing outbound traffic while blocking incoming traffic. But what about hosts that don't follow this convention? I only recently discovered that Xylogics AnnexII terminal servers listen on TCP port 5000 in addition to the standard Telnet port, 23. So if somebody puts up an Annex box on your "safe" network and doesn't turn on the security option, he has just made all the hosts on your network accessible from the outside even though your gateway is supposedly blocking all incoming traffic. And even if you take care of this specific problem, how do you know that somebody on some machine somewhere on your network isn't running a homegrown server that listens on an unrestricted port, creating yet another opening? I feel very strongly that true Internet security can only be achieved when it is widely recognized that each host must take the responsibility of protecting itself instead of relying on other network entities to do it. Yes, it takes more work to do it right, but the results will be worth it. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051403265500> Received: from csli.Stanford.EDU by NIC.DDN.MIL with TCP; Mon, 14 May 90 10:25:22 PDT Received: by csli.Stanford.EDU (4.1/inc-1.0) id AA13445; Mon, 14 May 90 10:26:58 PDT Date: Mon 14 May 90 10:26:55-PDT From: Ole J. Jacobsen Subject: Commercial IP service offerings To: tcp-ip@nic.ddn.mil Cc: ietf@venera.isi.edu Message-Id: <642706015.0.OLE@CSLI.Stanford.EDU> Mail-System-Version: Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP Or: +1 415 325-9427 (Home) or +1 415 990-9427 (Cellular) Hi, One of the sessions planned for INTEROP 90 (Oct 8-12) deals with commercial IP services, that is companies offering internet (or Internet) connectivity for a fee. We know about PSI and UUNET's AlterNet, but we are looking for concrete information about RBOCs offering similar services. So far, all I've heard are rumors. Any information would be greatly appreciated. Thanks, Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051405420700> Received: from terminator.cc.umich.edu by NIC.DDN.MIL with TCP; Mon, 14 May 90 09:21:58 PDT Received: from terminator.cc.umich.edu by terminator.cc.umich.edu (5.61/1123-1.0) id AA17355; Mon, 14 May 90 12:22:09 -0400 Message-Id: <9005141622.AA17355@terminator.cc.umich.edu> To: zessel%popper%incas%uklirb%unido%mcsun.uucp@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!) In-Reply-To: Your message of 12 May 90 14:39:48 +0000. <4411@incas.informatik.uni-kl.de> Date: Mon, 14 May 90 12:22:07 -0400 From: Michael T. Stolarchuk >>The trick to caching UDP/RPC results it to cache exactly one result for >>each client the server has. The cost is 8K per client, max. You never >>need to cache more than one response from each client, since a client >>will only send a new RPC only if the old one has been completed. >This is a good idea. I believe there are some exceptions to the 1 reply >per request rule, however. I believe the "spray" application will blast >a host with a number of packets before requiring a reply. I don't really want to get too involved in this discussion, but I have decided to add my (short) thoughts. Maybe I'm adding some complexity to an already noisy issue... One of the (current) largest uses of RPC's around here is for NFS. I mentioning that not because I think we ought to tune RPC's for NFS, but rather to point out that there are RPC's which are used to exchange large amounts of data. Painful delays exist. Partially due to (MOST) RPC's not using windoing to transmit data... like TCP... Mostly people make a decision not to do windoing since they assume they are shipping small amounts of data... I don't windowing will help NFS too much, since most of the UDP packets it wants to send out are either 8 or 4k. But if your needs are 'exchange of large amounts of data in one direction' and you would like to use an RPC, some attributes of TCP would be *real nice*. mts. the snail. ann arbor, mi. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051407021300> Received: from sonny.proteon.com by NIC.DDN.MIL with TCP; Mon, 14 May 90 07:55:41 PDT Received: by sonny.proteon.com (5.59/1.6) id AA18706; Mon, 14 May 90 11:02:13 EDT Date: Mon, 14 May 90 11:02:13 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005141502.AA18706@sonny.proteon.com> To: tcp-ip@nic.ddn.mil In-Reply-To: (Jan Engvald's message of 12 May 90 18:58:06 GMT <1990May12.185806.27545@lth.se> Subject: Lantastic vs. the World (& Novell) - Problems? Oh boy, another protocol using IEEE 802.3 without IEEE 802.2! Novell NetWare does that out of the box on "Ethernet" as well. I bet Lantastic and Novell NetWare absolutely go crazy trying to share one Ethernet! I guess people still don't understand the why's and wherefores of layered network architectures. My Sun with ISO didn't crash over NetWare, but it did log one message to disk for every NetWare broadcast packet. Ran out of disk space real fast. At least you can repair NetWare, using the barely documented ECONFIG program. It will change back to using Ethernet frames with type 8137, at least for most NetWare Ethernet drivers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051407202100> Received: from next.cis.brown.edu by NIC.DDN.MIL with TCP; Mon, 14 May 90 11:02:56 PDT Received: by next.cis.brown.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA17284; Mon, 14 May 90 14:00:21 GMT-0400 Date: Mon, 14 May 90 14:00:21 GMT-0400 From: ad@cis.brown.edu (Arif Diwan) Message-Id: <9005141800.AA17284@next.cis.brown.edu> To: tcp-ip@nic.ddn.mil Subject: "pop" Reply to Lloyd Buchanan >>>Original msg<<< ... Is there a BSD/SunOS compatible version .... >>>EOM<<< We have three BSD compatible pop servers: 1. POP II which came from IBM YorkTown which has been hacked around at several sites 2. MHPOP by Marshall T. Rose, which we have used 3. MHPOP modified at MIT using Kerberos authentication. You can get the latter two from athena-dist.mit.edu. If you use the Kerberized version you will also need the Kerberos authentication package from athena-dist. We are using that with another package from MIT - Techmail. Which runs on the MAC. It is great. That is also available from athena-dist via anonymous ftp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051413570800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 14 May 90 07:09:59 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01013; Mon, 14 May 90 07:04:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 May 90 13:57:08 GMT From: axecore!lloyd@uunet.uu.net (Lloyd Buchanan) Organization: Axe Core Investors, Inc. Subject: pop Message-Id: <1990May14.135708.1023@Axecore.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Just received a marvelous, though expensive, product for the Macintosh called TCP/Connect. For the purpose of receiving mail, this program requires a "pop" server. Never heard of it. Is there a BSD/SunOS compatible version of this protocol around. Please email any suggestions. thanks -- Lloyd Buchanan lloyd@Axecore.COM Axe Core Investors uunet!axecore!lloyd Axe Castle (914) 333-5226 (phone) Tarrytown, NY 10591 (914) 333-5208 (FAX) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051417564200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 14 May 90 23:09:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29410; Mon, 14 May 90 23:01:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 May 90 17:56:42 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!ns!jmh@tut.cis.ohio-state.edu (Joel Halpern) Organization: Network Systems Corporation, Mpls., MN Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1990May14.175642.6859@ns.network.com> References: <56957@bu.edu.bu.edu>, <1159@tnosoes.UUCP>, <23178@bellcore.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil An article proposed using a filtering gateway to improve security of an internet connection. Phil commented that he considers this an emergency measure, and pointed out that one telnet server listens on port 5000, which breaks the filtering. I agree with Phil (and several other people) that overall security requires that hosts be improved. I will note however that, by assumption, perfect security is impossible. There will always be holes. Ignoring the case where you do not know what your local servers are doing, a filtering gateway can provide significant security enhancements. It is certainly not perfect. But the statelessness is not a difficulty, if the filtering can be sufficiently smart. We have a router here which filters such that I can initiate FTP sessions outward from my host, but they can not be initiated inwards. Similarly with regard to telnet. Now, we have a machine which does have inward access, and if security were breached on that one could go anywhere. Therefore, we can focus most of our energy on managing that machine well. (Not that we can neglect everything else, but it is ehlpful to know where ones biggest weakness is.) Joel M. Halpern jmh@nsco.network.com Network Systems Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051423324300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 14 May 90 16:55:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07981; Mon, 14 May 90 16:41:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 May 90 23:32:43 GMT From: cayz@louie.udel.edu (James Cayz) Organization: University of Delaware Subject: Mac <-> SMTP via Enet box info needed Message-Id: <19381@nigel.udel.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi all, If this is posted in the wrong place, I do apologize, I tried to pick the most applicable groups.... Scenerio: Localtalk Net, Macs for now, PC probably later, using LocaltalkPC or LocaltalkPS/2 cards, all on Farallon network. Ethernet, with a KA9Q-based SMTP server in-place (IBM PC), 2 IBM PC/AT's with 3C501 or 503 cards in them, running (as need be) KA9Q (for mail), and NCSA (for telnet, etc) (Can't get KA9Q termcap on remote Unix boxes to work right!). Questions: I am looking for Mail for the Macs. Both Mac<->Mac and Mac<->Outside world (via Ethernet). I know that most Mac<->Mac systems require a server, which I don't have available (I have an AppleShare Server, with the Printer Spooler in the foreground, and a 128K Mac working not doing anything). I would like to know: 1) Are there any mac<->mac systems that don't require a server (or maybe use a 128K Mac, or a remote server on the Ethernet?) ??? 2) Are there any Mac<->Ethernet smtp systems, given that I get a Fastpath, Shiva EtherGate (with TCP/IP) or GatorBox? KA9Q for the Mac??? 3) If there are no server-less mac<->mac systems, but there are mac<->smtp systems, can I go macA->smtp->macB given some funky routing on my smtp router? Please, Please, Please mail all replies directly to me, cayz@louie.udel.edu (Internet). I don't get to read this groups as often as I should..... Thank you all in advance for your replies. James Cayz |James Cayz can be found via: USPS: Educational Technology Laboratory |EMAIL Internet: cayz@louie.udel.edu : 203 Willard Hall Education Building |PHONE: +1 302 451-6307 : University of Delaware, Newark DE 19716 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051503432500> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Tue, 15 May 90 10:43:09 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Tue, 15 May 90 10:42:40 -0700 Date: Tue, 15 May 90 10:43:25 PDT From: braden@venera.isi.edu Posted-Date: Tue, 15 May 90 10:43:25 PDT Message-Id: <9005151743.AA08651@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Tue, 15 May 90 10:43:25 PDT To: iesg@venera.isi.edu, ietf@venera.isi.edu, irsg@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: IAB Monthly Report -- April 1990 IAB Report for April 1990: A. MEETING The IAB held a video teleconference on May 26, 1990. Minutes of this meeting will be published as soon as possible. B. STANDARDS ACTIONS During April, the IAB took the following actions concerning Internet standards, following recommendations from the IESG. These changes will be reflected in the next edition of the IAB Official Protocols RFC. 1. Advance to Standard: SNMP -- Simple Network Management Protocol (RFC-1098) SMI -- Structure and Identification of Management Information for TCP/IP-based internets (RFC-1065) MIB I -- Management Information Base for Network Management for TCP/IP-based internets (RFC-1066) 2. Advance to Draft Standard: RFC-1006 -- ISO Transport Service on top of TCP RIP -- Routing Information Protocol (RFC-1058) NICNAME -- WhoIs Protocol (RFC-954) 3. Designate as Proposed Standard: MIB II -- Extensions to MIB OSPF -- Open Shortest Path First IGP (RFC-1131) 4. Retain as Proposed Standard: NNTP -- Network News Transfer Protocol (RFC-977) 5. Move back to Experimental: VMTP -- Versative Message Transaction Protocol (RFC-1045) C. STANDARDS STATUS The IAB has held extensive discussions on possible improvements in the way that status (e.g., Elective vs. Recommended) and applicability is attached to Internet protocol specifications, but decision has not yet been reached on these issues. The intent of any change would be to give vendors and users better guidance in determining the relevance of each standard. The IAB welcomes constructive input from any member of the Internet community on these and any other issues relating to the standard- ization process. Send comments to Vint Cerf, chair of the IAB (VCerf@NRI.RESTON.VA.US) or to Phill Gross, chair of the IETF (PGross@NRI.RESTON.VA.US). D. WORKING WITH ANSI Three members of the IAB, along with interested IETF members, met with ANSI X3S3.3 on April 18 and April 20 in Tucson, Arizona. At that meeting we discussed the possibility of introducing several new work items for entering IP, ICMP, TCP and UCP into the American National Standards track. A vote by the members of X3S3.3 was put off until June 27th, to allow X3S3.3 members to discuss these proposals with their respective organizations and to come to conclusions about the advisability and feasibility of entering the TCP/IP protocols into ANSI. Joint work with ANSI is already under way within the IETF OSI area, specifically with respect to the IS-IS dual routing protocols (OSI and TCP/IP). It is anticipated that joint meetings or, at least, colocated IETF and ANSI X3S3.3 meetings, will be scheduled in the future. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051505363400> Received: from wolf.cisco.com by NIC.DDN.MIL with TCP; Tue, 15 May 90 12:36:47 PDT Received: from dustbin.cisco.com by wolf.cisco.com with TCP; Tue, 15 May 90 12:33:43 -0700 To: hal@gateway.mitre.org (Hal Feinstein) Cc: tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org Subject: Re: SNAP on Ethernet Date: Tue, 15 May 90 12:36:34 MST From: cire|eric Hal, Your message appeared very confusing to me. Perhaps I can clear some of that up. SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header appended after the 802.2 header in 802 packets. Its use is denoted by the use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered Information. It consists of two fields, a three byte OUI (organizational unique identifier) and a prototcol type. The OUI identifies the prototcol family that the protocol type field values come from. One common use of SNAP is to allow the use of ethernet type codes to denote what kind of information is inside a packet. You will have a MAC header (802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header (OUI=0x000000, type field), and protocol data. The type field for an OUI of 0 is exactly the same 16 bits of what Ethernet uses. >> Date: Tue, 15 May 90 10:47:29 EDT >> From: hal@gateway.mitre.org (Hal Feinstein) >> Subject: SNAP on Ethernet >> >> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >> defined by ISO to rides just above the Ethernet LLC layer to indicate >> (among other things) the protocol ID of the next higher layer of >> protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >> replacing the current trick (see RFC-1042) used to identify this >> next higher protocol layer. But the jury is out as >> far as if and when this replacement will occur. RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes and notably IP on 802 media. Since 802.3 is already an 802 media it already defines how do using snap on 802.3. At this time few people do it. There is no such thing as using SNAP with IP-on-Ethernet. It is IP on 802.3 which would use 1042 mechanisms including SNAP to incapsulate the IP packet. There is no jury. Whether this is implemented or not depends mostly on vendor implementations in primarily the end nodes. Yes routers have to do it too. However, this stuff already exists and some people are using it. >> I'm trying to get a better view of what experiences people have using or >> planning for SNAP (if they have at all) and what commercial products >> people have run into (gateways for example) that contemplate introducing >> it. Is it worth designing into a future product? Any information would >> be highly appreciated. Cisco already handles SNAP'd protocols. >> Thanks in advance. -hal@gateway.mitre.org -c cisco engineering ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051506472900> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Tue, 15 May 90 07:43:29 PDT Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA06753; Tue, 15 May 90 10:47:29 EDT Date: Tue, 15 May 90 10:47:29 EDT From: hal@gateway.mitre.org (Hal Feinstein) Full-Name: Hal Feinstein Message-Id: <9005151447.AA06753@gateway.mitre.org> To: -v@gateway.mitre.org, tcp-ip@nic.ddn.mil Subject: SNAP on Ethernet Cc: dscott@gateway.mitre.org The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol defined by ISO to rides just above the Ethernet LLC layer to indicate (among other things) the protocol ID of the next higher layer of protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, replacing the current trick (see RFC-1042) used to identify this next higher protocol layer. But the jury is out as far as if and when this replacement will occur. I'm trying to get a better view of what experiences people have using or planning for SNAP (if they have at all) and what commercial products people have run into (gateways for example) that contemplate introducing it. Is it worth designing into a future product? Any information would be highly appreciated. Thanks in advance. -hal@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051509150800> Received: from umich.edu by NIC.DDN.MIL with TCP; Tue, 15 May 90 10:16:00 PDT Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) id AA21070; Tue, 15 May 90 13:16:19 -0400 Date: Tue, 15 May 90 13:15:08 EDT From: Dave_Katz@um.cc.umich.edu To: tcp-ip@nic.ddn.mil Cc: dscott@gateway.mitre.org Message-Id: <6198903@um.cc.umich.edu> Subject: SNAP on Ethernet >The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >defined by ISO to rides just above the Ethernet LLC layer to indicate >(among other things) the protocol ID of the next higher layer of >protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >replacing the current trick (see RFC-1042) used to identify this >next higher protocol layer. But the jury is out as >far as if and when this replacement will occur. A few technical nits: The Subnetwork *Access* Protocol (SNAP) is defined by IEEE 802.1a and is *5* bytes long. It rides just above the *802.2* LLC layer (which in turn runs over 802.3, *not* Ethernet). The SNAP protocol is intended to be used by "non-standard" protocols (those not assigned an LSAP value by IEEE), and includes a 3 octet Organizationally Unique Indentifier (OUI, otherwise known as the Manufacturer ID in MAC addresses) and a 2 octet protocol indentifier assigned by the owner of the OUI. If the OUI field is all zeroes, the protocol identifier field is defined as carrying the familiar 2 octet Ethernet Type value. This is the more- or-less standard way of carrying Ethernet protocols across true 802 media (which cannot use the EtherType field). RFC1042 in fact uses the SNAP "trick" to carry IP and ARP over 802 media, and RFC1103 (and the Internet Draft that replaces it) specifies the same for FDDI. The use of SNAP to carry IP over 802 media is extremely unlikely to change. Be careful about the terms "Ethernet" and "802.3"--they refer to the same media, but different framing conventions. Ethernet frames carry a 2 octet type field for higher layer protocol identification, while 802.3 frames carry a 2 octet length field and a 3 octet 802.2 LLC header. Both can run simultaneously on the same wire. There is very little use of 802.3/SNAP for IP, due to interoperability difficulties with Ethernet/IP. 802.5/SNAP/IP is used exclusively on token rings, and FDDI/SNAP/IP will be used on FDDI rings. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051510121900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Tue, 15 May 90 17:11:18 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Tue, 15 May 90 17:11:42 -0700 Date: Tue, 15 May 90 17:12:19 PDT From: braden@venera.isi.edu Posted-Date: Tue, 15 May 90 17:12:19 PDT Message-Id: <9005160012.AA09021@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Tue, 15 May 90 17:12:19 PDT To: hal@gateway.mitre.org, jas@proteon.com Subject: Re: SNAP on Ethernet Cc: -v@gateway.mitre.org, dscott@gateway.mitre.org, tcp-ip@nic.ddn.mil Not implementing SNAP in an IEEE 802.2 implementation would be incredibly shortsighted, unless the only protocol stack you want is ISO. It would also violate the Host Requirements RFC; please see section 2.3.3 of RFC-1122. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051510404200> Received: from sonny.proteon.com by NIC.DDN.MIL with TCP; Tue, 15 May 90 11:34:18 PDT Received: by sonny.proteon.com (5.59/1.6) id AA05823; Tue, 15 May 90 14:40:42 EDT Date: Tue, 15 May 90 14:40:42 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9005151840.AA05823@sonny.proteon.com> To: hal@gateway.mitre.org Cc: -v@gateway.mitre.org, tcp-ip@nic.ddn.mil, dscott@gateway.mitre.org In-Reply-To: Hal Feinstein's message of Tue, 15 May 90 10:47:29 EDT <9005151447.AA06753@gateway.mitre.org> Subject: SNAP on Ethernet SNAP is not used on Ethernet. (It uses Ethernet types.) You might see SNAP used on IEEE 802.3, as well as IEEE 802.4 and IEEE 802.5. In all cases, it runs on top of IEEE 802.2. The definition of SNAP will be in IEEE 802.1a, whenever it is approved. It's in the current draft. Almost all protocols on IEEE 802.2 will use SNAP, since IEEE 802.2 SAP's are only available to protocols defined by established international standards bodies. Realize that the (generally unused) DoD IP SAP in IEEE 802.2 was an *exception* to these rules, and they would not give out a further SAP for ARP. (The need for ARP is what caused us to search out SNAP.) However, anyone who owns a vendor block (3-byte prefix of Ethernet/IEEE 802 address) can assign his own SNAP types. Also, vendor block 00-00-00 incorporates the existing Xerox-assigned Ethernet types. SNAP is only 5 bytes. The preceeding IEEE 802.2 is 3 bytes. This sums to 8 bytes. Not implementing SNAP in an IEEE 802.2 implementation would be incredibly shortsighted, unless the only protocol stack you want is ISO. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051514203700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 15 May 90 08:39:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01066; Tue, 15 May 90 08:33:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 May 90 14:20:37 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!jh@ucsd.edu (Juha Heinanen) Organization: Tampere Univ. of Technology, Finland. Subject: Re: Commercial IP service offerings Message-Id: References: <642706015.0.OLE@CSLI.Stanford.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In Finland there has been a commercial IP service called DataNet offered by the state PTT for about a year now. It's backbone covers all major cities in Finland and has many large and small customers. Another competing IP service called LanLink is starting operation in September. You will meet people from both of these in Interop 90. -- -- Juha Heinanen, Tampere Univ. of Technology, Finland jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051516000000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 15 May 90 09:14:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03181; Tue, 15 May 90 09:05:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 May 90 16:00:00 GMT From: usc!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin@ucsd.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: question about caching in UDP based RPC (AND bug in UDP Cache?!) Message-Id: <4a68b5c9.20b6d@apollo.HP.COM> References: <4411@incas.informatik.uni-kl.de>, <9005141622.AA17355@terminator.cc.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005141622.AA17355@terminator.cc.umich.edu>, mts@TERMINATOR.CC.UMICH.EDU (Michael T. Stolarchuk) writes: |> Painful delays exist. Partially due to (MOST) RPC's not using windoing |> to transmit data... like TCP... |> |> Mostly people make a decision not to do windoing since they assume |> they are shipping small amounts of data... I don't windowing will |> help NFS too much, since most of the UDP packets it wants to send out |> are either 8 or 4k. |> |> But if your needs are 'exchange of large amounts of data in one direction' |> and you would like to use an RPC, some attributes of TCP would be |> *real nice*. Yeah, I'll admit that when I built the first version of our RPC system (NCS), I said: "Ah, who'd want to send more than a few K of data in a remote call anyway; why bother with all the hair?" But of course, it's not only the file system types who want to do that, but you run into these people who want to pass some 1000x1000 array of double precision floating point numbers from their workstation to their minisuper. I heard from them pretty quick. The latest version of our system does windowing just like the big boys. The hard thing is to keep the machinery that supports all that out of the way of the person who wants to make a call whose in's and out's can each be represented in one datagram. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005160012.AA03884@ucbvax.Berkeley.EDU] <1990051519363400> From: cire@CISCO.COM (cire|eric) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNAP on Ethernet Message-ID: <9005160012.AA03884@ucbvax.Berkeley.EDU> Date: 15 May 90 19:36:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 56 Posted: Tue May 15 20:36:34 1990 Hal, Your message appeared very confusing to me. Perhaps I can clear some of that up. SNAP (Sub-Network Access Protocol, don't ask me) is a 5 byte header appended after the 802.2 header in 802 packets. Its use is denoted by the use of the LSAPs 0xAA (170 decimal, internet network order) and Unnumbered Information. It consists of two fields, a three byte OUI (organizational unique identifier) and a prototcol type. The OUI identifies the prototcol family that the protocol type field values come from. One common use of SNAP is to allow the use of ethernet type codes to denote what kind of information is inside a packet. You will have a MAC header (802 mac), 802.2 header (DSAP=0xAA, SSAP=0xAA, CTL=0x3 (UI)), SNAP header (OUI=0x000000, type field), and protocol data. The type field for an OUI of 0 is exactly the same 16 bits of what Ethernet uses. >> Date: Tue, 15 May 90 10:47:29 EDT >> From: hal@gateway.mitre.org (Hal Feinstein) >> Subject: SNAP on Ethernet >> >> The Subnetwork Addressing Protocol is an 8 byte long auxiliary protocol >> defined by ISO to rides just above the Ethernet LLC layer to indicate >> (among other things) the protocol ID of the next higher layer of >> protocol (IP, ARP, etc.). There is talk of using SNAP with IP-on-Ethernet, >> replacing the current trick (see RFC-1042) used to identify this >> next higher protocol layer. But the jury is out as >> far as if and when this replacement will occur. RFC-1042 defines how to use SNAP to encapsulate protocols using ethertypes and notably IP on 802 media. Since 802.3 is already an 802 media it already defines how do using snap on 802.3. At this time few people do it. There is no such thing as using SNAP with IP-on-Ethernet. It is IP on 802.3 which would use 1042 mechanisms including SNAP to incapsulate the IP packet. There is no jury. Whether this is implemented or not depends mostly on vendor implementations in primarily the end nodes. Yes routers have to do it too. However, this stuff already exists and some people are using it. >> I'm trying to get a better view of what experiences people have using or >> planning for SNAP (if they have at all) and what commercial products >> people have run into (gateways for example) that contemplate introducing >> it. Is it worth designing into a future product? Any information would >> be highly appreciated. Cisco already handles SNAP'd protocols. >> Thanks in advance. -hal@gateway.mitre.org -c cisco engineering ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051602584600> Received: from sayshell.umd.edu by NIC.DDN.MIL with TCP; Wed, 16 May 90 06:38:36 PDT Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA07959; Wed, 16 May 90 09:38:48 EDT Message-Id: <9005161338.AA07959@sayshell.umd.edu> To: tcp-ip@nic.ddn.mil, jmh@ns.network.com (Joel Halpern) Subject: Re: A SUSPICIOUS SECURE GATEWAY Date: Wed, 16 May 90 09:38:46 -0400 From: "Louis A. Mamakos" > We have a router here which filters such that I can initiate FTP > sessions outward from my host, but they can not be initiated inwards. > Similarly with regard to telnet. I wonder what would happen if I kludged up a client telnet that used a local port number of 23, and then tried to connect to your TELNET server? Maybe you thought about this particular problem, but there are lots of interesting things you can do with source routed packets. I know that I can't sleep any better at night knowing that I have a filtering gateway "protecting" me. If you want security, you need to take a comprehensive approach to providing it, not shots in the dark here and there. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051611443100> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Wed, 16 May 90 18:44:44 PDT Date: Wed 16 May 90 18:44:31-PDT From: William "Chops" Westfield Subject: Re: Max FDDI frame rate on the glass To: kwe@bu.edu cc: tcp-ip@nic.ddn.mil In-Reply-To: <57399@bu.edu.bu.edu> Message-ID: <12590271059.21.BILLW@mathom.cisco.com> With FDDI things get more complicated. FDDI signals in 5 bit symbols. Four bits of data go into every five bits on the wire, so a byte takes 10 bits. : : Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps Well, if you are going to count the 4 to 5 encoding, then you also have to count the wire data rate as 1.25e8 bps. The 100 Mbps everyone talks about is AFTER the funny bit encoding... I doubt this makes much difference the the 10x faster generalization. BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051614230800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 08:32:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22470; Wed, 16 May 90 08:18:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 14:23:08 GMT From: e2big.dec.com!shlump.nac.dec.com!killie.enet.dec.com!colliton@decuac.dec.com Organization: Digital Equipment Corporation Subject: tcp protocol Message-Id: <11619@shlump.nac.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is there a field in the tcp protocol or other protocol that will allow me to collect/rollup stats (frames, byte , duration ) on active between ports by user. I do not wish to identify the user but log the start of active and collect stats to the end of the active. Luke ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051616130800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 09:32:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26406; Wed, 16 May 90 09:22:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 16:13:08 GMT From: mailrus!accuvax.nwu.edu!delta.eecs.nwu.edu!morrison@uunet.uu.net (Vance Morrison) Organization: Northwestern U, Evanston IL, USA Subject: 56K, T1 Boards for PC : cheap bridge/IP router Message-Id: <7802@accuvax.nwu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello Here are the results from my question on synchronous serial (56K or T1) cards for the IBM-PC. Actually I got many more requests for this information than reply's giving information, so the list below is not that long. I am certainly willing to post an adendum to this list if anyone else knows of any leads that do not apear below. For those intrested in cheap bridges or routers, check my comment below on Emerging Technologies. They are commercially selling a product very simmilar to PCroute/bridge (but developed independantly). Note that I have no knowledge of how good or bad this product is and have no stake in its success. I merely present the information because I believe it may be on interest to those who for whatever reason can't/won't use PCroute/bridge. Vance ----------------------------------------------------------------------- From: "John D. Balogh" Check out the Proteon p4100 router options. That box is approximatly a PC with some option cards (Ethernet, Token Ring, SIO (Slow {56K}, Fast {T1}). I would assume that Proteon selected "good" SIO cards for thier box. ----------------------------------------------------------------------- From: macy@fmsystm.UUCP I understand Dialogic makes such a beast. They have offices in Austin, TX and in the Boston area. --------------------------------------------------------------------------- From: "Dennis E. Baasch" (516)271-4525 Regarding your request for high speed synchronous cards for a PC, Emerging Technologies has several cards which might meet your requirements. We have both 8 and 16-bit cards, with each card a few different options. The 8-bit card will run any speed up to 1.544mbs, while the 16-bit card will run 2.048mbs. We're coming out with a new 8-bit card (which will be 100% software compatible with the existing one) in a couple of months. Both cards have a LAPB/HDLC chip which provide co-processor like functionality with a high-speed access shared memory interface. The cards are capable of about 3500 frames per second at 1.544mbs. There are 2 development type products available for the cards, both with 'C' language interfaces and drivers for MS-DOS or SCO XENIX. One is an HDLC development system, and the other is a full X.25 development system. Both use the same drivers for the cards, and both can support up to 4 cards per machine. The X.25 driver allows individual cards to be run in HDLC mode, allowing for mixed-mode applications (like routers) where you need a T1 line and an X.25 line. The 8-bit card (8mbs bus transfer rate) with a V.35 interface is priced at $725 for 56kbs and $925 for T1. The 16-bit card (14mbs transfer rate) is $995 for 56kbs and $1495. for T1. The HDLC driver is $285 per CPU, X.25 is $375. per CPU, and there is a one-time fee of $325. for the 'C' libraries for either product. For further info, send me your address or give me a call at (516) 271-4525. 900 Walt Whitman Rd. Melville, NY. 11747 Note: Denis is the Network Products manager for Emerging Technologies. --------------------------------------------------------------------------- From: "Steven P. Donegan" The Sea Level Systems ACB-II card does quite a nice job of sync HDLC handling at speeds from 0 to 1.544 MBPS. Sealevel Communications & I/O P.O. Box 1808 Easley, SC 29641 803-855-1581 --------------------------------------------------------------------------- Additional Comments: I check into the cards offered by Emerging Technologies and SeaLevel Systems and have some addtional Info on them Emerging Technologies: From what I could tell Emerging Technologies is actually in the buisness of selling a router/bridge that works on a IBM PC. (Basically PCroute/bridge). However in some ways it is superior. For example their package has SNMP, T1 and X.25 interface (if desired), as well as (I assume) support. There prices are actually pretty good (for $2500 you could put together a nice ether-ether bridge or router). They do sell the T1 and X.25 cards seperately but the price is reasonably steep (since that is not really what they are in the business of selling). They do have XENIX and DOS drivers for those who are interested. Sea Level Systems: The ACB-II card Steve talks about is a nice board and has a good price ($299). Also for $20 more you can get a board that is identical except that it has two serial interfaces instead of just one. The literature I have says the ACB-II only goes up to about 1.0 MBit/Sec. This precluded T1 use. However talking with the people at SLS, it seems that reasonably easy hardware mods may fix that. If enough people ask, I suspect they would come out with a card capable of T1 speeds. DISCLAMER: I am only relying what I read from the literature I have. Thus take all of this with a grain of salt. If you REALLY want to know, call these people up yourself and ask. Vance ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051616315900> Received: from wolf.cisco.com by NIC.DDN.MIL with TCP; Wed, 16 May 90 23:33:56 PDT Received: from dirt.cisco.com by wolf.cisco.com with TCP; Wed, 16 May 90 23:29:54 -0700 To: swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) Cc: tcp-ip@nic.ddn.mil Subject: Re: "LARP" on Port 91 ? In-Reply-To: Your message of 16 May 90 20:41:23 +0000. <3315@apogee.oakhill.UUCP> Date: Wed, 16 May 90 23:31:59 PDT From: Greg Satz According to the latest Assigned Numbers RFC, protocol number 91 is: 91 LARP Locus Address Resolution Protocol [BXH] and BXH is: [BXH] Brian Horn Locus ---none--- Apparently LARP is a protocol above IP, so any router, including those from cisco Systems, Inc., should forward those packets just fine. If you have any further questions about cisco products or technical issues/interoperability questions, feel free to drop a note to customer-service@cisco.com. Greg Satz cisco ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051618595400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 14:13:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13937; Wed, 16 May 90 13:59:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 18:59:54 GMT From: psuvm!ysub!doug@psuvax1.cs.psu.edu (Doug Sewell) Organization: Youngstown State University VM system (YSUB) Subject: tcp-ip source for SysV multi-user environment Message-Id: <90136.145954DOUG@ysub.ysu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for tcp-ip source for a small SysV multi-user environment - sufficient to support telnet in/out, ftp in/out, and e-mail in/out. There will not be very many concurrent users. I looked at the KA9Q SysV source (thanks to those that directed me to vax.cs.pitt.edu) but as far as I could tell could support only one user at a time. I've also downloaded the Berkeley source, but I'd rather not attempt to convert the code to SysV myself. I will be writing my own driver for a non-standard adapter. Any help, pointers, and recommendations are welcome. Please reply to me directly at one of the addresses below (doug@ysub.ysu.edu is probably best). I have FTP available, but no UUCP. Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 E-mail: DOUG@YSUB.BITNET, DOUG@YSUB.YSU.EDU, ...!uunet!ysub.bitnet!doug >> I am not a wizard. What I do isn't magic. I am a computer professional. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051619053800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 12:16:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06848; Wed, 16 May 90 12:09:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 19:05:38 GMT From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@ucsd.edu (Kent England) Organization: Boston U. Information Technology Subject: Max FDDI frame rate on the glass Message-Id: <57399@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I was wondering what the maximum packet per second rate an FDDI network would experience if 3 million monkeys were running telnet, ie minimum sized frames, across an FDDI backbone. I made some calculations, with help from Ram Das Rao, who knows all about FDDI frames, even if he hasn't seen many. :-) With Ethernet the computation goes like so: Interframe gap of 9.6 us = 96 bits = 12 bytes Preamble 8 MAC 14 Data 46 min (that covers IP and TCP mins) CRC 4 -- Total 84 bytes/frame This is the absolute minimum frame size that an Ethernet can support on the wire, taking account of the interframe gap and all real bits. Then; 10**7 bits/sec x (1 byte/8 bits) x (1 frame/84 bytes) = 14,880 pps. Maximum sized packets fill up the wire at about 800 pps. Those should be familiar numbers to most of you. With FDDI things get more complicated. FDDI signals in 5 bit symbols. Four bits of data go into every five bits on the wire, so a byte takes 10 bits. There is also no interframe gap required in a token ring protocol. For FDDI the calculations go like: Preamble (PA/SD/FC) = 19 symbols = 95 bits MAC 12 bytes =120 bits Data (TCP min) 41 bytes =410 (there is no FDDI min value) FCS/ED/FS 10 symbols = 50 --- Total 675 bits/frame (min size) Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps FDDI supports about 4k bytes as the maximum frame size. That is approximately 4000 bytes at 10 bits/byte; 10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps. So, max sized packets fill up the wire at a 2500 pps rate, versus about 800 for Ethernet. Conclusion: Guess what? FDDI is 10x more than Ethernet, almost exactly. Who would have thought? [So we aren't talking 3 million monkeys- more like a quarter million would do the job.] I thought you might be interested in the 150 kpps number for future reference. Sock it away up in the gray matter along with 15 kpps for Ethernet. Or just know that the 10x approximation is actually pretty good, all things considered. --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051620412300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 15:02:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16580; Wed, 16 May 90 14:42:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 20:41:23 GMT From: swrinde!cs.utexas.edu!oakhill!guri@ucsd.edu (Gurvinder Singh Ahluwalia) Organization: Motorola Inc. Austin, Tx Subject: "LARP" on Port 91 ? Message-Id: <3315@apogee.oakhill.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone heard of a protocol called LARP? Context in which I have encountered this is IBMs Transparent Cluster Facility (TCF) on the 4381 running VM/AIX. IBM indicates it employs port # 91. For those out there aware of this and also running cisco routers, I would like to go a step further to find out compatibility of this protocol on ciscos, including access/passage of LARP traffic through cisc.o Is there something that has to be enabled to allow LARP through cisco? What is the default? - Gurvinder ------ Gurvinder Ahluwalia Internet: guri@apogee.sps.mot.com Software Engineer uucp : {}oakhill!apogee!guri@cs.utexas.edu Global Networking Phone : 512/891-3310 Motorola SPS Austin, TX. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051621105700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 14:31:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14686; Wed, 16 May 90 14:11:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 May 90 21:10:57 GMT From: orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu (David Walker) Organization: University of California, Irvine Subject: Re: Max FDDI frame rate on the glass Message-Id: <2651C1E1.23165@orion.oac.uci.edu> References: <57399@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Kent, In article <57399@bu.edu.bu.edu> kwe@bu.edu (Kent England) writes: > Conclusion: > > Guess what? FDDI is 10x more than Ethernet, almost exactly. > Who would have thought? [So we aren't talking 3 million monkeys- more > like a quarter million would do the job.] Actually, I think it may really be more like 3 million, depending on the size of the ring. Since FDDI allows a device to release the token after finishing its transmission (rather than after it receives the message it sent), it's possible to have multiple packets on the ring, particularly if they're small packets. Does anyone feel like calculating how many packets can be carried per second by FDDI as a function of the number of nodes and length of fiber? I don't know enough about the delay introduced by each node to do it. David Walker Network Services Manager UC Irvine DHWalker@uci.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051623214300> Received: from scslwide.sony.co.jp by NIC.DDN.MIL with TCP; Tue, 15 May 90 16:21:43 PDT Received: from smgw6.sm.sony.co.jp (smbrg6.sm.sony.co.jp) by scslwide.sony.co.jp with SMTP (4.0/2.7W) id AA22903; Wed, 16 May 90 08:21:49 JST Received: from smdnd.sm.sony.co.jp by smgw6.sm.sony.co.jp with SMTP (4.0/6.4J.6) id AA17022; Wed, 16 May 90 08:21:51 JST Received: from chang1.sm.sony.co.jp by smdnd.sm.sony.co.jp (4.0/6.4J.5) id AA03555; Wed, 16 May 90 08:20:57 JST Received: from localhost by chang1.sm.sony.co.jp (4.0/6.4J.5) id AA01801; Wed, 16 May 90 08:21:44 JST Return-Path: Message-Id: <9005152321.AA01801@chang1.sm.sony.co.jp> To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: Info.wanted on Dial up PPP From: David C. Hagiwara Organization: Super Micro Systems Gp., Sony Corporation, Tokyo, Japan Reply-To: hagiwara@sm.sony.co.jp Date: Wed, 16 May 90 08:21:43 +0900 Sender: hagiwara@sm.sony.co.jp Does anyone inplemnt "Dial up PPP" ? Are there any RFCs describing the matter on dialing ? (I have got the PPP of Perkins from CMU) Takashi Hagiwara (Hagiwara@Sm.Sony.Co.Jp) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005160939.AA03962@ucbvax.Berkeley.EDU] <1990051700520000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: RE: pinging a remote TCP port to see if it's in used Message-ID: <9005160939.AA03962@ucbvax.Berkeley.EDU> Date: 17 May 90 00:52:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 36 Posted: Thu May 17 01:52:00 1990 John Interrante, >port number. I don't mind explaining that the reason I asked was to >improve a portmapper I wrote for InterViews programs making RPC calls. >We couldn't use Sun's /etc/portmap because we wanted servers to >register their TCP port numbers under a variable-length string of >characters (i.e., a name), not a tuple of integers (i.e., a program >number and a version number). I noticed that SunOS 4.1's /etc/portmap >will let you register the port number of a non-existent server, but it Do u mean non-existent server as those server dies/crashes after registerred the port number to portmap? >will unregister the port number and give you zero when you try to ask >for the non-existent server's port number. I set a breakpoint in a >server to find out how portmap validated the server's port number and >I know that the server never noticed a new connection. Yet portmap >definitely WAS validating port numbers in some way because I never got >a port number for a non-existent server. I checked the public RPC >sources on gatekeeper.dec.com but the source for portmap didn't >include this kind of code so that's why I posted my question. I >wanted to be able to validate port numbers in my portmapper too >because it would prevent clients from trying to connect to a server >that crashed after registering its port number with the portmapper. Since your server resides in the same host as portmap and your server port number is kept by portmap, what you can do is to create a dummy socket and bind this socket to the server port number. If the bind fails and returns an error saying that the port number is in used, then the server is still alive. If the binding is successful, then most likely that particular server is dead since port number cannot be re-used. Note that this technique can apply to check both UDP and TCP servers. - Beng Hang Tay (email: taybengh@nusdiscs) Dept. Info. and Comp. Sc. National University of Singapore (NUS) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051701020000> Received: from DOCKMASTER.NCSC.MIL by NIC.DDN.MIL with TCP; Thu, 17 May 90 05:22:09 PDT Date: Thu, 17 May 90 05:02 EDT From: Fitch@DOCKMASTER.NCSC.MIL Subject: COMTEN TCP To: tcp-ip@NIC.DDN.MIL Message-ID: <900517090204.424102@DOCKMASTER.NCSC.MIL> I would like to talk with someone about COMTEN TCP. COMTEN's are front-ends for IBM mainframes made by NCR. I believe they also market a TCP. Right now I'm looking for basic product info. Please provide a phone number if you care to help. Thanks. --Jack (Fitch -at dockmaster.ncsc.mil) (301)738-8018 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051704140200> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 17 May 90 21:03:56 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa07768; 17 May 90 22:01 EDT Received: from [192.31.242.27] by RELAY.CS.NET id aa19990; 17 May 90 21:53 EDT Received: by interlan.Interlan.Com (5.51/5.17) id AA11160; Thu, 17 May 90 08:14:37 EDT Received: by europa.Com (4.0/SMI-4.0) id AA00386; Thu, 17 May 90 08:14:02 EDT Date: Thu, 17 May 90 08:14:02 EDT From: Frank Kastenholz Message-Id: <9005171214.AA00386@europa.Com> To: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bu.edu!kwe@UCSD.EDU, tcp-ip@NIC.DDN.MIL Subject: Re: Max FDDI frame rate on the glass > For FDDI the calculations go like: > > Preamble (PA/SD/FC) = 19 symbols = 95 bits > MAC 12 bytes =120 bits > Data (TCP min) 41 bytes =410 (there is no FDDI min value) > FCS/ED/FS 10 symbols = 50 > --- > Total 675 bits/frame (min size) > > Then; 10**8 bits/sec x (1 frame/675 bits) = 148,000 pps > > FDDI supports about 4k bytes as the maximum frame size. That > is approximately 4000 bytes at 10 bits/byte; > > 10**8 bits/sec x (1 frame/40,000 bits) = 2500 pps. So, max > sized packets fill up the wire at a 2500 pps rate, versus about 800 > for Ethernet. Kent, The FDDI signalling rate is 125,000,000 bits per second. With the 4/5 encoding, that comes to 100,000,000 effective data bits per second. This comes to just over 185Kpps for the telnet monkeys and 3032pps for the 4096 data byte packets. Frank Kastenholz Racal Interlan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051706120000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Wed, 16 May 90 01:49:55 PDT Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8775; Wed, 16 May 90 04:49:13 EDT Date: Wed, 16 May 90 16:52 H From: Subject: RE: pinging a remote TCP port to see if it's in used To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH John Interrante, >port number. I don't mind explaining that the reason I asked was to >improve a portmapper I wrote for InterViews programs making RPC calls. >We couldn't use Sun's /etc/portmap because we wanted servers to >register their TCP port numbers under a variable-length string of >characters (i.e., a name), not a tuple of integers (i.e., a program >number and a version number). I noticed that SunOS 4.1's /etc/portmap >will let you register the port number of a non-existent server, but it Do u mean non-existent server as those server dies/crashes after registerred the port number to portmap? >will unregister the port number and give you zero when you try to ask >for the non-existent server's port number. I set a breakpoint in a >server to find out how portmap validated the server's port number and >I know that the server never noticed a new connection. Yet portmap >definitely WAS validating port numbers in some way because I never got >a port number for a non-existent server. I checked the public RPC >sources on gatekeeper.dec.com but the source for portmap didn't >include this kind of code so that's why I posted my question. I >wanted to be able to validate port numbers in my portmapper too >because it would prevent clients from trying to connect to a server >that crashed after registering its port number with the portmapper. Since your server resides in the same host as portmap and your server port number is kept by portmap, what you can do is to create a dummy socket and bind this socket to the server port number. If the bind fails and returns an error saying that the port number is in used, then the server is still alive. If the binding is successful, then most likely that particular server is dead since port number cannot be re-used. Note that this technique can apply to check both UDP and TCP servers. - Beng Hang Tay (email: taybengh@nusdiscs) Dept. Info. and Comp. Sc. National University of Singapore (NUS) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005170739.AA21279@ucbvax.Berkeley.EDU] <1990051706315900> From: satz@CISCO.COM (Greg Satz) Newsgroups: comp.protocols.tcp-ip Subject: Re: "LARP" on Port 91 ? Message-ID: <9005170739.AA21279@ucbvax.Berkeley.EDU> Date: 17 May 90 06:31:59 GMT References: <3315@apogee.oakhill.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Posted: Thu May 17 07:31:59 1990 According to the latest Assigned Numbers RFC, protocol number 91 is: 91 LARP Locus Address Resolution Protocol [BXH] and BXH is: [BXH] Brian Horn Locus ---none--- Apparently LARP is a protocol above IP, so any router, including those from cisco Systems, Inc., should forward those packets just fine. If you have any further questions about cisco products or technical issues/interoperability questions, feel free to drop a note to customer-service@cisco.com. Greg Satz cisco ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051706583900> Return-Path: Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Thu, 17 May 90 09:35:08 PDT Received: from pocasset.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2) id AA23872; Thu, 17 May 90 10:59:52 EDT Received: by pocasset.Wellfleet.Com (3.2/SMI-3.2) id AA05122; Thu, 17 May 90 10:58:39 EDT Date: Thu, 17 May 90 10:58:39 EDT From: Bill Streilein Message-Id: <9005171458.AA05122@pocasset.Wellfleet.Com> To: philipp@gipsi.gipsi.fr Subject: Arp on point-to-point Cc: tcp-ip@nic.ddn.mil Phillipe, We solve this problem by running ARP over our point-to-point links. Although there's a direct connection to a specific host/gateway on the other side, this allows dynamic mapping. Bill Streilein / bstreile@wellfleet.com / Wellfleet Communications, Inc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051707040300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 00:44:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20890; Thu, 17 May 90 00:32:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 07:04:03 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Max FDDI frame rate on the glass Message-Id: <60453@sgi.sgi.com> References: <57399@bu.edu.bu.edu>, <2651C1E1.23165@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes: +--------------- | ... Since FDDI allows a device to release the token after | finishing its transmission (rather than after it receives the message it | sent), it's possible to have multiple packets on the ring, particularly if | they're small packets. Does anyone feel like calculating how many packets | can be carried per second by FDDI as a function of the number of nodes and | length of fiber? +--------------- According to the FDDI MAC spec I have (ANSI draft X3T9.5/88-139 Revision 1), the maximum (idle-net) ring latency "D_Max" is 1.617 milliseconds, thus the longest permitted ring has 20212.5 bytes of delay in the ring. This is enough for about 4.5 maximum-length frames, or 631 claim frames, or just under 266 TCP/IP "ack" packets (assuming RFC 1103 encapsulation). This is why you don't wait for your message to come back. Ring throughput would be horrible if you did. -Rob p.s. The delay is a combination of fiber (speed-of-light) delay and station (MAC entity) delay. There is a max of 1000 "MAC entities" and a max of 2km between "PHY entities". (Loosely speaking, "PHY" is the optoelectronics, and "MAC" is the byte-level state machine. These aren't one-to-one, because you can have "single-attach stations" = 1 PHY / 1 MAC, "dual-attach" = 2 PHY / 1 MAC, "dual-MAC" = 2 PHY / 2 MAC, and "concentrator"= n+2 PHY/1 MAC.) The spec shows how this delay can results from 200km of fiber (100 km "circumference", to allow for ring "wrap" on failure) and 1000 stations, assuming 5.085ns/m in the fiber and 600ns (15 symbols) in the PHY/MAC. If on the other hand, you max out the distance between stations with single-MAC dual-attach stations, you get another set of numbers. Since a given fiber must be less than 2km, we have one 0.6us station delay (15 symbols, including PHY, MAC, elasticity buffer, etc.) and 20.34us fiber delay (2 fibers, 2km, 5.085ns/m) per hop. That gives 1617/20.94 or 77 stations max, for a 154km (duplex) circumference (308km of fiber). (I'm not sure this configuration is permitted. Anybody know?) ----- 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051707310800> Received: from VM.CC.OLEMISS.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 11:32:51 PDT Received: from VM.CC.OLEMISS.EDU by VM.CC.OLEMISS.EDU (IBM VM SMTP R1.2.1) with BSMTP id 6267; Thu, 17 May 90 13:32:12 CST Received: from UMSVM (CCBUSTER) by VM.CC.OLEMISS.EDU (Mailer R2.02A) with BSMTP id 6266; Thu, 17 May 90 13:31:56 CST Date: Thu, 17 May 90 13:31:08 CST From: POSTMASTER Subject: AEDAVIS To: TCP-IP Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list. He is no longer here. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051710330500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 05:43:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05919; Thu, 17 May 90 05:30:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 10:33:05 GMT From: mcsun!hp4nl!tnosoes!tom@uunet.uu.net (Tom Vijlbrief) Organization: TNO Institute for Perception, Soesterberg, The Netherlands Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1173@tnosoes.UUCP> References: <9005161338.AA07959@sayshell.umd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes: >> We have a router here which filters such that I can initiate FTP >> sessions outward from my host, but they can not be initiated inwards. >> Similarly with regard to telnet. >I wonder what would happen if I kludged up a client telnet that used a local >port number of 23, and then tried to connect to your TELNET server? Maybe >you thought about this particular problem, but there are lots of interesting >things you can do with source routed packets. Filtering is done on destination port number (at least in my adapted KA9Q) and not on host source port number. If you read the posted README you would see that source-routed packets are rejected. >I know that I can't sleep any better at night knowing that I have a filtering >gateway "protecting" me. If you want security, you need to take a comprehensive >approach to providing it, not shots in the dark here and there. You are correct, but how can you be sure that a local network with dozens of Unix boxes with different administrators are correctly installing their machines ? (E.g. not export NFS-filesystems to the world as is the default). How can you be sure that hunderds of users have non trivial passwords, etc. Eliminating access to NFS, rlogin, telnet, FTP, ... from the outside world to all the machines (or a selected group of machines) does certainly make ME sleep much better. I think that inspecting each host on your network is an example of "shots in the dark here and there". Is a secure gateway not an example of a comprehensive approach because it does effect all hosts on your local network? (The KA9Q-gateway for examples catches by default all RPC calls, so for example rwalld calls are catched. Did you for example disable the rwalld on every host on your local network ? And would did you do about source-routed packet attacks ?) Tom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051710453400> Received: from GUNTER-ADAM.AF.MIL by NIC.DDN.MIL with TCP; Thu, 17 May 90 13:44:48 PDT Date: Thu 17 May 90 15:45:34-CDT From: AFDDN.BEACH@GUNTER-ADAM.AF.MIL Subject: CLNS and routing (IS-IS) and ES-IS To: tcp-Ip@nic.ddn.mil cc: AFDDN.BEACH@GUNTER-ADAM.AF.MIL Message-ID: <12590478782.15.AFDDN.BEACH@GUNTER-ADAM.AF.MIL> Help.... . . Can anybody tell me where to get any info at all on proposed routing protocols and implementations of them for the GOSIP world. I assume OSPF will be used. What I'd really like is pointers to discussions of how the routing would operate and clues on what implementations might look like. I'd also like any comments on resource utilization. I think the ISO address formats look a lot harder to deal with than IP. Please send responses directly to me so as not to clutter up this list... AND if there's another list I should be talking to, feel free to flame as long as you tell me the list's address. Going from TCP/IP is like teaching a sho'nuff southern boy to talk with a french accent. It ain't easy! Darrel B. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051712532600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 06:45:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09969; Thu, 17 May 90 06:38:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 12:53:26 GMT From: fernwood!portal!cup.portal.com!thad@uunet.uu.net (Thad P Floryan) Organization: The Portal System (TM) Subject: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <29973@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW} {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip} If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU happy with the performance? My experiences recently show the 10Mbit/S Ethernet to be an order of magnitude SLOWER than the 1Mbit/S StarLAN between the same two systems under identical load conditions, etc. These tests were run on the SAME two systems with both networks' cards and software installed. To test, I alternated between: ftp> put /unix (or get /unix depending on the direction) and uuto unix tlabs3!thad multiple times. For uucp I've set up ",e" protocol; for the TCP/IP stuff there isn't anything than can be set (yeah, I've read all the docs). With uucp over StarLAN (1BASE5), the average tranfer is 40,000 to 50,000 bytes per second, end-to-end, disk-to-disk. With ftp over Ethernet (10BASE2 (ThinNet)), the average transfer is 5,000 to 8,000 bytes/second, end-to-end, disk-to-disk, though I once, just once, had a peak of 24,000 bytes/second. The only conclusion I can draw is that the Wollongong WIN/3B Applications Package, version 1.4, for the UNIXPC/3B1 is seriously flawed. Some of the support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but this level of "performance" is so poor I wonder if there's something I might be missing. And, yes, I did check whether the SQE (heartbeat) signal is enabled; it's not (when it WAS enabled for another set of tests, the transfer rates dropped to about 400 bytes/second, TWO orders of magnitude less than the StarLAN). I placed a simple Ethernet monitor (POWER, Collision, Transmit, Receive LEDS) on the AUI cables, and it looks like there's a 1/2 second of activity followed by several seconds of NO activity ANYPLACE on the net ... this inactivity would explain the poor overall transfer performance, but the question is "WHY?" I'm convinced there's nothing wrong with the hardware. I also ran some tests using the "loopback" mode, again using ftp with the same file, and there wasn't any appreciable change in performance. Also, if anyone knows how/where to get the Ethernet software for a Motorola 6300 (similar to the 3B1) for placement in /usr/sys/LAN/* in order to do a sysgen, I'd appreciate hearing about that, too. My Motorola 6300 does have the comm expansion card with the Ethernet D-15 (and the board uses the Lance chip set, same as does the 3B1). Thad Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051713295200> Received: from visual1.tamu.edu by NIC.DDN.MIL with TCP; Thu, 17 May 90 16:25:31 PDT Received: by visual1.tamu.edu (AA11569); Thu, 17 May 90 18:29:52 CDT Date: Thu, 17 May 90 18:29:52 CDT From: stanley@visual1.tamu.edu (Stanley Guan) Message-Id: <9005172329.AA11569@visual1.tamu.edu> To: tcp-ip@nic.ddn.mil Subject: stanley@visual1.tamu.edu Please remove me from this list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051714545000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 09:45:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20973; Thu, 17 May 90 09:36:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 14:54:50 GMT From: swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!jackv@ucsd.edu (Jack F. Vogel) Organization: Turnkey Computer Consultants, Westchester, CA Subject: Re: "LARP" on Port 91 ? Message-Id: <6754@turnkey.TCC.COM> References: <3315@apogee.oakhill.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3315@apogee.oakhill.UUCP> guri@oakhill.UUCP (Gurvinder Singh Ahluwalia) writes: > >Has anyone heard of a protocol called LARP? Well, yes you might say I've heard of it, considering we invented it :-}. Locus has two officially registered IP protocol's, LARP is, as you noted number 91, another is number 87 which is an IP packet containing what is called a net message which is an inter-kernel communication packet. The former is used to initialize TCF it resolves an address to a TCF site number. The later lays the foundation for TCF. Since the registration of these protocols was relatively recent some sniffers will see the packets but not give you a protocol name. >For those out there aware of this and also running cisco routers, >I would like to go a step further to find out compatibility of this >protocol on ciscos, including access/passage of LARP traffic through >cisc.o Is there something that has to be enabled to allow LARP through >cisco? What is the default? We use Proteon routers here at LCC but I know that Cisco is in use at a couple of locations running AIX370. I don't believe there is anything that you need to do to the router, it should pass the packets through by default, it is just an IP packet. Disclaimer: I speak for myself, not my employer. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051717553300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 11:14:09 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27031; Thu, 17 May 90 11:12:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 17:55:33 GMT From: mcsun!unido!zgdvda!zhang@uunet.uu.net (Ning Zhang) Organization: ZGDV Darmstadt, FRG Subject: help wanted for installing MIT/CMU PC/IP public domain package on NI5210 Message-Id: <2025@zgdvda.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Sorry for crossposting. Please reply me by email (unido!zgdvda!zhang or zhang@agd.fhg.de), since I have no access to these newsgroups. We just received a public domain PC/IP package, which was originally developed at the Lab of CS at MIT and later enhanced by CMU. I compiled this TCP/IP package on a Compaq At with MSC 5.0 without any problem. Since the default configuration did not support Interlan NI5210A ethernet card, I relinked the whole exe commands with the NI5210A driver library (instead of the old NI5010 driver library), which was developed by at B. N. Davis at Darbick Instructional Software Systems in 1988, also without any problem. Then I had to customize the netdev.sys file to set up correct parameters about the hardware, internet address, etc., and also turned all debug options on. The RACAL Interlan ethernet card we have is NI5210A-8-V (REV AA). The IO address was configured as 0x360, the base memory address was 0xC0000 and the interrupt vector was at IRQ2 level. I would think I had correctly set up all parameters. Then I changed my config.sys file for installing netdev.sys and rebooted the pc. After the machine came up again, I simply tried the iping command, but it didn't work. It complained that "Error: board not responding". This message came from the i_init.c file in the NI5210 driver directory. I also tried hopelessly by changing the DMA channel numbers. I thought I might have done something wrong during the compiling or configuration. Here I ask you PC/IP gurus to enlight me about the problem. Enclosed here is the first few lines of the "i82586.h" about the version I have. /* See permission and disclaimer notice in file "bnd-note.h" */ #include "bnd-note.h" /* Copyright 1986 by Carnegie Mellon */ /* See permission and disclaimer notice in file "cmu-note.h" */ #include /* Copyright 1984 by the Massachusetts Institute of Technology */ /* See permission and disclaimer notice in file "notice.h" */ #include /* This header file includes register descriptions of the Ethernet boards for the IBM PC based on the Intel 82586 chip (hence known as "the ethernet"). */ As we are in a poor institute and cannot afford to buy a expensive package for network monitoring, we only need two program included in this PD PC/IP package, i.e. netwatch, monitor. If you know PD stuff else for this purpose, please also let me know. Thanks in advance, Ning Zhang unido!zgdvda!zhang zhang@agd.fhg.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005172228.AA13447@ucbvax.Berkeley.EDU] <1990051719310800> From: CCBUSTER@VM.CC.OLEMISS.EDU (POSTMASTER) Newsgroups: comp.protocols.tcp-ip Subject: AEDAVIS Message-ID: <9005172228.AA13447@ucbvax.Berkeley.EDU> Date: 17 May 90 19:31:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Posted: Thu May 17 20:31:08 1990 Please remove AEDAVIS@VM.CC.OLEMISS.EDU or AEDAVIS@UMSVM from this list. He is no longer here. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051720351400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 14:40:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09609; Thu, 17 May 90 14:28:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 20:35:14 GMT From: shlump.nac.dec.com!delni.dec.com!mcclellan@decuac.dec.com (Rolf McClellan) Organization: Digital Equipment Corporation Subject: Announcing biz.dec.ip--a newsgroup on DEC's TCP/IP products Message-Id: <11682@shlump.nac.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This posting is to announce a USENET newsgroup for the discussion of products from Digital Equipment Corporation that support the Internet protocol suite (TCP/IP). The newsgroup will be unmoderated, but will be read regularly by employees of Digital, including some of the engineers who develop TCP/IP networking products, as well as marketing and field support personnel. The goal of the newsgroup is to provide a forum for the exchange of information from user-user, as well as user-Digital, and Digital-user. Digital employees intend to contribute to the newsgroup by posting detailed product descriptions and specifications similar to Digital's Software Products Descriptions (SPDs), and by trying to answer questions about the applicability and use of Digital's TCP/IP products. There is no intention of posting the sort of marketing literature that simply extols product virtues in general terms. The newsgroup is also not intended as an alternative to normal channels for product support. However, every attempt will be made to respond in some way to postings that are addressed to Digital. Because of the unavoidable commercial nature of product descriptions and application notes, it was felt that the newsgroup should be established as biz.dec.ip. In spite of this, it is hoped that the nature of the newsgroup will be very similar to user-sponsored newsgroups. Rolf McClellan mcclellan@delni.enet.dec.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051721032600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 17:00:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18078; Thu, 17 May 90 16:47:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 May 90 21:03:26 GMT From: amdcad!pepsi!ohara@ucbvax.Berkeley.EDU (Bob O'Hara) Organization: Advanced Micro Devices; Sunnyvale, CA Subject: Re: Max FDDI frame rate on the glass Message-Id: <1990May17.210326.23605@bach.amd.com> References: <57399@bu.edu.bu.edu>, <2651C1E1.23165@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes: [stuff from Kent's earlier post deleted.] > >Actually, I think it may really be more like 3 million, depending on the >size of the ring. Since FDDI allows a device to release the token after >finishing its transmission (rather than after it receives the message it >sent), it's possible to have multiple packets on the ring, particularly if >they're small packets. Does anyone feel like calculating how many packets >can be carried per second by FDDI as a function of the number of nodes and >length of fiber? I don't know enough about the delay introduced by each >node to do it. > > David Walker > Network Services Manager > UC Irvine > DHWalker@uci.edu David, Kent was pretty close. You have probably seen my response to him just prior to this posting. You are correct that there may be many frames on the ring simultaneously, but any one node will only see the one passing immediately in front of it. Therfore, a node needs to support only 100 Mbps into and out of the ring. Only if a node has multiple connections to the ring (i.e. a dual MAC, dual attachment station) would it need anything beyond 100 Mbps. The FDDI standard does specify a maximum latency for each node and a delay figure for the fiber, so it is possible to calculate (approximately, since bits in the preamble can be eaten and created as a frame goes round the ring) how many bits and from that how many frames are on a ring. I think the equation would look like this: n = number of stations, l = length of fiber in meters. # of data bits on the ring = ((n * 756ns) + (l * 5ns/m)) / 10ns per bit These numbers are taken from ANSI X3.148-1988, the Physical protocol sublayer standard. Divide the number of bits by your favorite average frame length and you will have your answer. -Bob Bob O'Hara Net: ohara@pepsi.amd.com Advanced Micro Devices, Inc. Phone: +408-749-2321 P.O. Box 3453 MS 70 Fax: +408-749-2825 Sunnyvale, Ca. 94088-3000 Disclaimer: Everyone needs a disclaimer and I disclaim this one. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051803105000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 17 May 90 21:30:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03074; Thu, 17 May 90 21:09:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 03:10:50 GMT From: hercules!dirt.cisco.com!kph@apple.com (Kevin Paul Herbert) Organization: cisco Systems Subject: Re: CLNS and routing (IS-IS) and ES-IS Message-Id: <18178@hercules.csl.sri.com> References: <12590478782.15.AFDDN.BEACH@GUNTER-ADAM.AF.MIL> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil At cisco, we just released support for CLNS routing based on a proprietary protocol, ISO IGRP. We support ES-IS, so we'll autoconfigure and do dynamic routing based on addresses learned from end systems, although our routing won't interroperate in the same CLNS area with routers using IS-IS (although, to our knowledge, there are no IS-IS routers today). If you want to learn more about the features and capabilities of ISO IGRP, we can move this discussion to comp.dcom.sys.cisco. Kevin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051804493200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 04:47:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23087; Fri, 18 May 90 04:41:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 04:49:32 GMT From: news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@rutgers.edu (Greg A. Woods) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <1990May18.044932.28911@robohack.UUCP> References: <29973@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW} > {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip} > > If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU > happy with the performance? > > The only conclusion I can draw is that the Wollongong WIN/3B Applications > Package, version 1.4, for the UNIXPC/3B1 is seriously flawed. Some of the > support programs (e.g. telnet, sendmail, etc.) are buggy beyond belief, but > this level of "performance" is so poor I wonder if there's something I might > be missing. Please don't infer too much from my posting, BUT.... Everything I've ever heard about Wollongong WIN/TCP products leaves a lot to be desired. Certainly they are over-priced ($7,500 for binaries, $35,000 for sources for a 3b2 at announcement). A colleague who has seen the sources of early versions says they are a very sorry sight. I'm not entirely surprised to hear that the WIN/3B1 version suffers from poor performance, especially given that it was never marketed to any degree. I'm not too surprised to hear of any nasty bugs either, and I would consider the several second pauses between activity to be a bug too!. You might consider porting much of the BSD4.3 code.... -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051807580000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 09:16:35 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09643; Fri, 18 May 90 09:09:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 07:58:00 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov (Oberman, Kevin) Organization: Lawrence Livermore National Laboratory-Engineering Subject: Re: CLNS and routing (IS-IS) and ES-IS Message-Id: <59032@lll-winken.LLNL.GOV> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12590478782.15.AFDDN.BEACH@GUNTER-ADAM.AF.MIL>, AFDDN.BEACH@GUNTER-ADAM.AF.MIL writes... >Can anybody tell me where to get any info at all on proposed routing >protocols and implementations of them for the GOSIP world. I assume >OSPF will be used. What I'd really like is pointers to discussions >of how the routing would operate and clues on what implementations >might look like. I'd also like any comments on resource utilization. >I think the ISO address formats look a lot harder to deal with than IP. > >Please send responses directly to me so as not to clutter up this list... >AND if there's another list I should be talking to, feel free to flame >as long as you tell me the list's address. > >Going from TCP/IP is like teaching a sho'nuff southern boy to talk with >a french accent. It ain't easy! The IS-IS standard is currently in DP (Draft Proposal) status. It is DP 10589. I'm posting to the list because I suspect lots of people are not familiar with the status of this (unless they read the OSI group). The full title of the beast is "Intermediate system to Intermediate system Intra-Domaon routeing exchange protocol for use in Conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)". The spelling and caps ARE exact to the best of my proof reading. The proposal is similar to OSPF in concept, but very different in detail. It is far from certain that IETF will recommend OSPF as the Internet standard, but it looks to be the front-runner. 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051809400400> Received: from TGV.COM by NIC.DDN.MIL with TCP; Fri, 18 May 90 16:39:21 PDT Date: Fri 18 May 90 16:40:04-PDT From: VANCE@TGV.COM (L. Stuart Vance) Subject: Interesting uses of networking To: tcp-ip@nic.ddn.mil Message-ID: <643074004.829297.VANCE@TGV.COM> Mail-System-Version: Organization: TGV, Incorporated X-Phone: 408/427-4366 (work); 408/684-0916 (home) X-Address: 603 Mission Street; Santa Cruz, CA 95060 (work) I'm putting together a talk on interesting uses of networking, and am looking for good stories/applications that people have run across. I'm very familiar with two: o TCP (Mr. Romkey's Toaster Control Protocol) o An SNMP controlled CD player If anyone has any information on other uses (in particular, I'd like to find people with information on the coke machine wired up to a DEC-20[?] at MIT[?] and/or the geographic coordinates server at [I believe] MERIT), I'd be most interested in talking you. Many thanks, ----Stuart ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051812202500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 05:46:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26385; Fri, 18 May 90 05:30:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 12:20:25 GMT From: pandora!scj@bellcore.com (Steve Johnson) Organization: Bellcore Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <23377@bellcore.bellcore.com> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >> {Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW} >> {unix-pc.general,comp.sys.att,comp.dcom.lans,comp.protocols.tcp-ip} >> >> If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU >> happy with the performance? ... >I'm not entirely surprised to hear that the WIN/3B1 version suffers >from poor performance, especially given that it was never marketed to >any degree. I'm not too surprised to hear of any nasty bugs either, >and I would consider the several second pauses between activity to be >a bug too!. You might consider porting much of the BSD4.3 code.... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Two points: 1. If anyone begins the port of BSD code, I suggest using Alex Crain's UnixPC socket implementation *OR* spending the time to re-write the BSD code using TLI as provided with the WIN/3B package. Having used (both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept of socket emulation is 90% of the reason WIN/3B is a poor performer. (most socket calls are actually TLI calls wrapped with a function that is supposed to behave like a socket call). In the case of the UnixPC, I hope to be proven wrong but it looks like TLI may done using *sockets* at the kernel level! (If true, this means socket "calls" invoking TLI "calls" invoking socket calls -- blecch!) (Anyone with decent Motorola 68k assembler and device driver experience want to take a look at a disassembled socket.o? :-) I'm having trouble making sense of the assembler code). 2. Although well known in sun (workstation) circles, the fact that rwhod and routed are BIG cpu hogs seems lost on Wollongong - NO mention of the potentially anti-social behavior of these bad boys in the manual! The Moral? Don't run these guys unless you need them, our UnixPC's are already anaemic by today's standards. BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish my gas project 8-( ). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051812522100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 07:49:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04072; Fri, 18 May 90 07:43:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 12:52:21 GMT From: pmf@mimsy.umd.edu (Paul M. Franceus) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: Re: Max FDDI frame rate on the glass Message-Id: <24484@mimsy.umd.edu> References: <57399@bu.edu.bu.edu>, <2651C1E1.23165@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2651C1E1.23165@orion.oac.uci.edu> DHWalker@uci.edu (David Walker) writes: >sent), it's possible to have multiple packets on the ring, particularly if >they're small packets. Does anyone feel like calculating how many packets >can be carried per second by FDDI as a function of the number of nodes and >length of fiber? I don't know enough about the delay introduced by each > ... > David Walker I don't believe that the maximum frame rate depends on the latency of the ring. The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are being technical.) The latency in the ring may decrease the maximum number of usable frames per second, and there may be many frames in transit at any time. If you ignore IP and TCP overhead (don't forget the 802.2 and SNAP headers) the FDDI can go much faster than 14,000 pps. The maximum frame rate is really something around 480,000( given the 17 Byte min frame and the preamble). Paul Franceus ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051812595700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 07:48:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04079; Fri, 18 May 90 07:43:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 12:59:57 GMT From: pmf@mimsy.umd.edu (Paul M. Franceus) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <24485@mimsy.umd.edu> References: <9005161338.AA07959@sayshell.umd.edu>, <1173@tnosoes.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil While Gateway filtering is not a cure-all, Host based security is not a cure all either. In any security architecture it is important that each piece of the system do its part. Any individual "secure" component of a system will not give "total" security. Security will not be achieved unless you have mapped out a security architecture where each part of the system does its piece. It is important also, for functions to overlap somewhat to provide a layered security approach. Filtering gateways can be an important part of such a security architecture. Paul Franceus ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051813355100> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Fri, 18 May 90 15:11:11 PDT Received: from MSU.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 1479; Fri, 18 May 90 18:11:22 EDT Received: by MSU (Mailer R2.03B) id 1829; Fri, 18 May 90 17:51:58 EDT Date: Fri, 18 May 90 17:35:51 EDT From: Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: Dial up access to Internet facilities To: Campus-Size LAN Discussion Group , Don Lewis cc: "TCP/IP list (plus more)" In-Reply-To: Message of Fri, 18 May 90 16:18:13 EDT from > We are in the process of evaluating terminal severvs that provide >TCP/IP support for dialup users. We are currently having a philosphical >discussion on what users should have acces to once dialed in. We, >University of Missouri - St. Louis, are part of a TCP/IP network that is >associatied with MIDnet. I have no problems allowing users access to >our local TCP/IP host plus the other hosts in the U. of Mo. network. >Should dialup users have access to the Internet? There is something >about allowing this type of access that doesn't sound right to me. >Should this be a concern? How are other institutions handling this >type of access? Yes, this should be a concern. As I understand it, NSFnet policy is that unlimited access is not permitted. You would have to check to see if MIDnet has its own policy. What this policy seems to translate to in practice is that you should only permit "known" users to have access outside of your local net (and perhaps your regional net, if it is within their guidelines). This generally means that terminal servers should be restricted to local use, requiring dial-up users to access a workstation or larger system and identify themselves (as something other than "guest", hopefully!) in order to have unlimited Internet access. Here at MSU, we are part of two regional networks - Merit and CICnet. Our dial-up lines have unlimited access to any hosts at MSU or within the Merit Network, but not CICnet or beyond. This is true of all the dial-up lines within the Merit Network and its member institutions as well. Doug Nelson Network Software Manager Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051814482000> Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by NIC.DDN.MIL with TCP; Fri, 18 May 90 09:33:19 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA10757; Fri, 18 May 90 09:25:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 14:48:20 GMT From: haven!umbc3!umbc5.umbc.edu!alex@ames.arc.nasa.gov (Alex S. Crain) Organization: University of Maryland, Baltimore County Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <3333@umbc3.UMBC.EDU> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >I'm not entirely surprised to hear that the WIN/3B1 version suffers >from poor performance, especially given that it was never marketed to >any degree. I'm not too surprised to hear of any nasty bugs either, >and I would consider the several second pauses between activity to be >a bug too!. You might consider porting much of the BSD4.3 code.... >-- > Greg A. Woods Just a passing note, the uipc driver thats going around is directly derived from BSD, all you need to do is add the driver for the ethernet card and the af_inet code, available from uunet. I haven't looked at the code in awhile, but I did finish most of the top level, and a few things were added later. I had always planned to add a slip interface, but it never got finished because of hardware problems on my end (I may find some time for it this summer, in between rebuilding my Harley, rehabbing my house, getting married, etc ... ). t################################# :alex. #Disclamer: Anyone who agrees # Systems Programmer #with me deserves what they get.# University of Maryland Baltimore County ################################# alex@umbc3.umbc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051815332100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 09:02:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07485; Fri, 18 May 90 08:35:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 15:33:21 GMT From: swrinde!emory!km@ucsd.edu (Ken Mandelberg) Organization: Emory University, Dept of Math and CS Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <5494@emory.mathcs.emory.edu> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <23377@bellcore.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes: >In article <1990May18.044932.28911@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes: >>In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > >2. Although well known in sun (workstation) circles, the fact that rwhod and > routed are BIG cpu hogs seems lost on Wollongong - NO mention of the > potentially anti-social behavior of these bad boys in the manual! The > Moral? Don't run these guys unless you need them, our UnixPC's are > already anaemic by today's standards. > The problem with rwhod on Suns is not really that it is a CPU hog, but relates to diskless workstations. On a Sun network with well synchronized clocks all the diskless workstations send out a broadcast packet at almost the same moment once a minute, with their own load info. Each one receives all its fellows packets and tries to write the updated info to the /usr/spool/rwho directory, each to a separte file. These files are all NFS so each takes several additional packets for the write. The broadcasts don't really hurt much, its the NFS writes. If you have N machines there are N^2 NFS writes per minute, all at about the same moment. This causes many collisions and retries. On our diskless Suns we patched rwho to do the broadcasts but not update its own /usr/spool/rwho. Only the server updates this directory, and it is mounted on all the clients. This cuts out the NFS packets entirely, there are just N broadcast packets a minute. For the 3B1, there is nothing to do since /usr/spool/rwho is already local. With this in place, with in execess of 50 rwhod machines on our net, rwhod consumes on the order of 10 seconds an hour. If all you have is diskfull machines (like 3B1s) that would be what you should expect with no patches. In fact I got the 10 second estimate from "ps" on one of our 3B1s. Even if you have unpatched diskless Suns and 3B1s, the 3B1s would not see high cpu usage on rwhod, just the Suns. However, everyone would suffer the network congestion for the NFS writes. If N gets very large (say 1000), and the clocks are very well synchronized (say with timed), the broadcasts and collisions alone would kill you (even with the patch). The very large /usr/spool/rwho directory on the server would also degrade performance on the server and thrash the inode cache. Rwhod clearly doesn't scale well, but is really not much of a problem (with the patch) on relatively small nets. -- 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051817451300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 11:08:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16723; Fri, 18 May 90 10:51:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 17:45:13 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu (Dan Schlitt) Organization: City College of New York - Science Computing Facility Subject: Re: What is the IAB? Message-Id: <1990May18.174513.26941@sci.ccny.cuny.edu> References: <1990May10.150744.12108@phri.nyu.edu>, <57064@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <57064@bu.edu.bu.edu> kwe@bu-it.bu.edu (Kent England) writes: :In article <1990May10.150744.12108@phri.nyu.edu>, :roy@alanine.phri.nyu.edu (Roy Smith) writes: :> :> At the recent PSI Internetworking Tutorial, I asked two people who :> should have known the answer, "Exactly what *is* the Internet Activities :> Board?" and in both cases all I got were some random moderately derogatory :> comments but no real answer (which I found somewhat annoying, BTW). :> :> So, can anybody on this list answer my question? :> -- : : Some wires must have gotten crossed. It would be very strange indeed :for anyone in PSI to take this view, since several of the principals at PSI :have been involved in TCP/IP standards, including SNMP and "ISO-on-TCP", and :that work would be exactly nowhere without the IAB. Strange, indeed. : I have my doubts about Roy's interpretation too. However one should also note the anonymous critique of the governance of the Internet that was published in Goodfellow's newsletter. Participation in the IAB and the IETF can't be read as 100% support. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051819231300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 13:40:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22848; Fri, 18 May 90 12:32:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 19:23:13 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!bbn.com!mmcintos@tut.cis.ohio-state.edu (Martin M. McIntosh) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Max FDDI frame rate on the glass Message-Id: <56388@bbn.BBN.COM> References: <57399@bu.edu.bu.edu>, <2651C1E1.23165@orion.oac.uci.edu>, <24484@mimsy.umd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The maximum throughput of a FDDI ring *does* depend on the propagation delay, as many people have pointed out. More accurate, the throughput depends on the delay between adjacent stations, since no traffic can enter the ring as the token is passed. The TTRT will also have some effect on the throughput, since this will determine the rate that the token must be passed. If you assume that each station will send for the entire TTRT, the next station cannot send until one-ring-rotation + time-to-next-station after the TTRT expires. If the stations can only send one frame (each monkey types slowly) per token, the time between frames will be time-to-next-station until the TTRT expires and then the time will be equal to the above.If you want a lower bound on PPS, pick a ring with - TRT set to expire just before the last bit of the frame is transmited - maximim ring size - only two stations (one terminal with monkey and one server not sending) This will get one frame per *two* rotations of the ring. The maximum throughput will be a small ring with large TTRT and lots and lots of stations all sending frames until the TTRT expires. I would recommend reading "Analysis and Tuning of the FDDI Media Access Protocol", D. Dykeman and W. Bux, IEEE Journal on Selected Areas in Communications, July 1988. This provides very good analytic solutions to throughput on FDDI. At least it was confirmed by some simulation work that I have done. [much of this information was included in a past posting by myself. I am sorry for any duplication] Martin McIntosh Bolt Beranek and Newman Network Analysis mmintosh@BBN.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051819554300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 18:30:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13779; Fri, 18 May 90 18:22:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 May 90 19:55:43 GMT From: zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!david@tut.cis.ohio-state.edu (David H. Wolfskill) Organization: Wolfskill & Dowling residence; Anaheim, CA (USA) Subject: IBM MVS[/XA or /ESA] TCP/IP Implementations Message-Id: <1990May18.195543.20700@dhw68k.cts.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am seeking information about implementations of the TCP/IP protocol suite for use in an MVS/XA (or MVS/ESA) environment on an IBM 3090. (This is for my employer, who shall remain mercifully nameless. :-) I have heard reports that there may be implementations other than the IBM one that may be worth examining; I would appreciate knowing: * Who the vendors are * What experiences folks have had with the products (and the vendors) (Naturally, I am also interested in folk's experiences with the IBM product, although I already am aware of its existence....) I much prefer mail; I will certainly post a summary if more than a couple of folks request it -- probably around the middle of June (unless I get inundated by responses well before then). If you can't reach me any other way, my (work) telephone number is (714) 385-4055. Thank you, david -- David H. Wolfskill uucp: ...{spsd,zardoz,felix}!dhw68k!david InterNet: david@dhw68k.cts.com CompuServe: >internet:david@dhw68k.cts.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051820060900> Received: from TWG.COM by NIC.DDN.MIL with TCP; Fri, 18 May 90 13:34:07 PDT Received: from TWG.COM by TWG.COM with SMTP ; Fri, 18 May 90 13:33:55 PST Received: from dragon.twg.com by Obelix.TWG.COM id aa21532; 18 May 90 13:28 PDT Received: by dragon.twg.com (5.59/25 TWG 1) id AA00073; Fri, 18 May 90 20:06:09 GMT Date: Fri, 18 May 90 20:06:09 GMT From: "Douglas P. Ambort" Message-Id: <9005182006.AA00073@dragon.twg.com> To: tcp-ip@nic.ddn.mil Subject: Re. Wollongong TCP/IP Cc: fernwood!portal!cup.portal.com!thad@uunet.uu.net Ouch! Mr. Floryan's indictment of AT&T's implementation of a very old outdated version of Wollongong TCP/IP, ported a long time ago by AT&T to its 3B1's is harsh. Given the 3B1, his indictment may not be altogether off base; but it could be misconstrued by netnews readers as a general indictment of all Wollongong TCP/IP (past, present, future, and on good, bad or indifferent platforms). And such an indictment would not only be unfair, but misinformed. Wollongong continues to upgrade its TCP/IP with _significant_ enhancements. And AT&T continues to select Wollonong as its TCP/IP vendor of choice, for current and future platforms. Why? Because of our TCP/IP's performance and features, our commitment to continued enhancement, and because of the solid OEM support we provide. In this case of the (the 3B1 shortcomings described by Mr. Floryan), AT&T has simply chosen not to upgrade an ancient TCP/IP on a platform that has been retired. Perhaps AT&T is concentrating on new platforms? If you want to see the best TCP/IP in its class, check out the TCP/IP on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. It's Wollongong's. And we're proud of it. On the other hand, if someone must rail against an old TCP/IP implementation on (let's face it) 'old iron', go ahead. You could just as easily criticise the skinny tires on a Model T for not being steel belted radials. Time passes. Technology progresses. And so has Wollongong's TCP/IP! .--------------------------------------------------------------------. | Douglas Ambort The Wollongong Group, Inc. | | Product Manager 1129 San Antonio Road | | INTERNET: douglas@twg.com Palo Alto, CA 94303 | | (415) 962-7248 | | FAX: (415) 969-5547 | `--------------------------------------------------------------------' ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005190447.AA25263@ucbvax.Berkeley.EDU] <1990051821355100> From: 08071TCP@MSU.BITNET (Doug Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities Message-ID: <9005190447.AA25263@ucbvax.Berkeley.EDU> Date: 18 May 90 21:35:51 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 Posted: Fri May 18 22:35:51 1990 > We are in the process of evaluating terminal severvs that provide >TCP/IP support for dialup users. We are currently having a philosphical >discussion on what users should have acces to once dialed in. We, >University of Missouri - St. Louis, are part of a TCP/IP network that is >associatied with MIDnet. I have no problems allowing users access to >our local TCP/IP host plus the other hosts in the U. of Mo. network. >Should dialup users have access to the Internet? There is something >about allowing this type of access that doesn't sound right to me. >Should this be a concern? How are other institutions handling this >type of access? Yes, this should be a concern. As I understand it, NSFnet policy is that unlimited access is not permitted. You would have to check to see if MIDnet has its own policy. What this policy seems to translate to in practice is that you should only permit "known" users to have access outside of your local net (and perhaps your regional net, if it is within their guidelines). This generally means that terminal servers should be restricted to local use, requiring dial-up users to access a workstation or larger system and identify themselves (as something other than "guest", hopefully!) in order to have unlimited Internet access. Here at MSU, we are part of two regional networks - Merit and CICnet. Our dial-up lines have unlimited access to any hosts at MSU or within the Merit Network, but not CICnet or beyond. This is true of all the dial-up lines within the Merit Network and its member institutions as well. Doug Nelson Network Software Manager Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051900080400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 18 May 90 17:15:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09951; Fri, 18 May 90 17:11:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 May 90 00:08:04 GMT From: usc!orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu (David Walker) Organization: University of California, Irvine Subject: Re: Max FDDI frame rate on the glass Message-Id: <26548E64.20897@orion.oac.uci.edu> References: <57399@bu.edu.bu.edu>, <2651C1E1.23165@orion.oac.uci.edu>, <24484@mimsy.umd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <24484@mimsy.umd.edu> pmf@mimsy.umd.edu (Paul M. Franceus) writes: > I don't believe that the maximum frame rate depends on the latency of the > ring. The FDDI still only transmits at 100Mb/sec (125 Mb/sec if you are > being technical.) The latency in the ring may decrease the maximum number > of usable frames per second, and there may be many frames in transit at > any time. > If you ignore IP and TCP overhead (don't forget the 802.2 and > SNAP headers) the FDDI can go much faster than 14,000 pps. The maximum > frame rate is really something around 480,000( given the 17 Byte min frame and > the preamble). > > Paul Franceus Thanks, Paul. I can see that I misunderstood Kent's original question. What I'm interested in is what *aggregate* packet rate can be carried by FDDI for *multiple* sources (i.e., the monkeys are not all at one node), so your 480K is what I was looking for. Of course, none of us would ever expect to actually achieve that rate any more than we'd expect to achieve 14,000 pps on an Ethernet. All of the other discussion of the maximum rate that's available to a *single* node is sure interesting, though; I had no idea that FDDI was so (mis)tunable. David Walker Network Services Manager UC Irvine DHWalker@uci.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23433@bellcore.bellcore.com] <1990051905392000> From: karn@ka9q.bellcore.com (Phil Karn) Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Quote without comment Message-ID: <23433@bellcore.bellcore.com> Date: 19 May 90 05:39:20 GMT Sender: news@bellcore.bellcore.com Reply-To: karn@ka9q.bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Lines: 19 Posted: Sat May 19 06:39:20 1990 Advertisement in the October 7, 1989 issue of the British magazine "New Scientist", page 15: "The International Organization for Standardization (ISO) is seeking, for its new project based on OSI LAN with distributed environment including servers and VM and VMS hosts (PC or PS/2 user terminals), an experienced NETWORK SYSTEMS SPECIALIST familiar with the hardware/software aspects of LAN, network management and operating systems, terminal emulation and host coupling, OSI protocols INCLUDING TCP/IP [my emphasis - Phil], X.400 and X.25, to be responsible for overall implementation of the network system. Please apply with cv to ISO Personnel Services, Case postale 56, CH-1211 Geneva 20, Switzerland." --Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051915102400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 20 May 90 06:32:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26260; Sun, 20 May 90 06:31:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 May 90 15:10:24 GMT From: vmp!sonyd1!blilly!bruce@uunet.uu.net (Bruce Lilly) Organization: none Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <1990May19.151024.12766@blilly.uucp> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <23377@bellcore.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <23377@bellcore.bellcore.com> scj@pandora.UUCP (Steve Johnson) writes: [ several lines from other postings deleted ] >Two points: > >1. If anyone begins the port of BSD code, I suggest using Alex Crain's > UnixPC socket implementation *OR* spending the time to re-write the > BSD code using TLI as provided with the WIN/3B package. Having used > (both UnixPC and 3B2) WIN/3B, my personal opinion is that the concept > of socket emulation is 90% of the reason WIN/3B is a poor performer. > (most socket calls are actually TLI calls wrapped with a function that > is supposed to behave like a socket call). In the case of the UnixPC, > I hope to be proven wrong but it looks like TLI may done using *sockets* > at the kernel level! (If true, this means socket "calls" invoking TLI > "calls" invoking socket calls -- blecch!) > Forget it. The Wollongong ``emulation'' of TLI is extremely buggy -- it does not comply with any of the standards (SVID, POSIX, X/OPEN). It is so brain-damaged that I have found it impossible to write even a trivial program with it. The biggest problem is that asynchronous events are returned as a bit map, rather than one-at-a-time events in a queue. As a result, it is possible (even very likely) for a function to fail due to an asynchronous event, with no way to recover because of other ``events'' in the bit map. [ more lines deleted ] >2. Although well known in sun (workstation) circles, the fact that rwhod and > routed are BIG cpu hogs seems lost on Wollongong - NO mention of the > potentially anti-social behavior of these bad boys in the manual! The > Moral? Don't run these guys unless you need them, our UnixPC's are > already anaemic by today's standards. > Routed from Wollongong doesn't even work AT ALL. It dies after not finding a non-existent symbol in the kernel's nlist. >BTW, NFS for the UnixPC (WIN/3B or ??) is in my queue (right after I finish >my gas project 8-( ). -- Bruce Lilly uunet!vmp!sonyd1!blilly!bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051919542800> Received: from boole.ece.cmu.edu by NIC.DDN.MIL with TCP; Sat, 19 May 90 20:53:43 PDT Received: by boole.ece.cmu.edu (5.54-ECE2/5.17) id AA09926; Sat, 19 May 90 23:54:30 EDT Date: Saturday, 19 May 1990 23:54:28 EDT From: Gene.Hastings@boole.ece.cmu.edu Reply-To: hastings@psc.edu To: emv@math.lsa.umich.edu (Edward Vielmetti) Cc: tcp-ip@nic.ddn.mil Subject: Re: archives of ietf "network joint management" list ? Message-Id: <1990.5.20.3.14.46.Gene.Hastings@boole> In-Reply-To: I am the chair of tha Network Joint Management working group of the IETF. There is no formal archive of the mailing list , but there are public agendae and reports from meetings, and specific documents online in multiple places. Is there specific information you're seeking? Gene Hastings Pittsburgh Supercomputing Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990051922214900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 19 May 90 17:31:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21685; Sat, 19 May 90 17:18:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 May 90 22:21:49 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!barsoom!tih@ucsd.edu (Tom Ivar Helbekkmo) Organization: Norwegian School of Economics Subject: Re: Re. Wollongong TCP/IP Message-Id: <878@barsoom.nhh.no> References: <9005182006.AA00073@dragon.twg.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil douglas@TWG.COM ("Douglas P. Ambort") writes (among other things): >Time passes. Technology progresses. And so has Wollongong's TCP/IP! Yeah, you're right about that. We used to call it "Willgowrong" here, but after receiving our last upgrade (to version 5.1 for VAX/VMS), we've had to reevaluate. It's a darn good package, and well documented. Congratulations! -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052000393200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 19 May 90 17:46:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22949; Sat, 19 May 90 17:39:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 May 90 00:39:32 GMT From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@tut.cis.ohio-state.edu (Edward Vielmetti) Organization: University of Michigan Math Dept., Ann Arbor MI. Subject: archives of ietf "network joint management" list ? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil hi. I'm trying to find the site which archives the IETF "network joint management" mailing list. So far no luck. Can someone help? thanks. --Ed Edward Vielmetti, U of Michigan math dept. emv@math.lsa.umich.edu moderator, comp.archives ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052021083700> Received: from ucla-an.anes.ucla.edu by NIC.DDN.MIL with TCP; Mon, 21 May 90 08:48:33 PDT Return-Path: Received: by ucla-an.anes.ucla.edu (Sendmail 5.61/1.03) id AA13756; Mon, 21 May 90 08:48:37 -0700 Date: Mon, 21 May 90 08:48:37 -0700 From: Stan Stead Message-Id: <9005211548.AA13756@ucla-an.anes.ucla.edu> To: tcp-ip@sri-nic.arpa Subject: Dealing with systems without nameservice. Greetings: We are running 4.3 BSD. We currently use nameservice. However, a site that we wish to exchange mail and files, while connected to the internet, does not use nameservice. We can access the site by internet number, but not by name. Is there anyway to "hot-wire" an address (perhaps via /etc/hosts). Currently, the only way /etc/hosts is read is if named is not running. Please reply to my email address directly. Thank you. Stan Stanley W. Stead UCLA School of Medicine / Dept of Anesthesiology BELL: (213) 206-6238 ARPA: stan@anes.ucla.edu BITNET: stan@anes.UCLA.EDU UUCP: {randvax | ucla-cs}\ !ucla-an!stan UUCP: {att|decvax}!hermix/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052022363000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 20 May 90 15:47:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21619; Sun, 20 May 90 15:45:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 May 90 22:36:30 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <23444@bellcore.bellcore.com> References: <9005161338.AA07959@sayshell.umd.edu>, <1173@tnosoes.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1173@tnosoes.UUCP> tom@tnosoes.UUCP (Tom Vijlbrief) writes: >[...] but how can you be sure that a local network >with dozens of Unix boxes with different administrators are >correctly installing their machines ? (E.g. not export NFS-filesystems >to the world as is the default). >How can you be sure that hunderds of users have non trivial passwords, etc. One way is to build and use "sweep" programs that regularly test each machine on your local network for a list of specific security holes. For maximum effectiveness, you should not rely solely on your domain database or host tables for a list of machines to sweep; you should also look for unregistered "squatters" by monitoring ARP packets, probing your entire IP address space, etc. According to my conversations with the folks at CERT, all of the break-ins to computers on the Internet over the past year have exploited holes that have been well known for some time. I've found it fairly easy to construct programs that automatically test large numbers of machines for these known holes. The hard problem, as it turns out, lies not in generating a list of vulnerable systems, but in getting the administrators of those machines to update their software or to fix their system configurations. Gateway filtering is useful as a TEMPORARY protective measure while this process continues, but it does NOT lessen in any way the need to fix the vulnerable hosts. In my opinion, host security is both necessary and sufficient to prevent break-ins. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052101225500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 20 May 90 18:32:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA29495; Sun, 20 May 90 18:23:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 May 90 01:22:55 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Dial up access to Internet facilities Message-Id: References: , <9005190447.AA25263@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >Yes, this should be a concern. As I understand it, NSFnet policy is >that unlimited access is not permitted. We have been unable to find any definite statement of policy in this area. However a number of system managers have gotten tired of responding to complaints about intrusions from their terminal servers, and have instituted restrictions. I have a feeling that over the course of the next year or so even without a definite policy, the number of unrestricted terminal servers is going to fall off to nearly zero. Another policy issue is preventing people from telnetting in and then out in an attempt to obscure their identity by going through many sites. I believe there is a growing concensus that this should be stopped in some way. If anyone knows of more definite policies in this area I'd like to hear about them. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052104330300> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Mon, 21 May 90 05:32:49 PDT Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA15946; Mon, 21 May 90 08:33:03 EDT Date: Mon, 21 May 90 08:33:03 EDT From: hal@gateway.mitre.org (Hal Feinstein) Full-Name: Hal Feinstein Message-Id: <9005211233.AA15946@gateway.mitre.org> To: tcp-ip@nic.ddn.mil Subject: Wither Ethernet? It has been suggested by some standards gurus that in the future all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead (or possibly dying) protocol. That a couple of vendors (like Sun or CISCO) supporting "dual stacks" (that is both protocols) are simply startling a changing marketplace. There really will not be two different standards. Now I've found strong avocates who disagree and say that ethernet will be around and, others who say that current ethernet users will stay with ethernet (because they already have it installed) but *future* installations will use ISO/IEEE802. I have not seen any rush to man ethernets lifeboats at the trade shows so I wonder if what the standards gurus are saying is true? Have you faced this questions also? If you have I'd appreciate hearing from you. Hal ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052107431100> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Mon, 21 May 90 14:45:45 PDT Received: from mathom.cisco.com by Note.NSF.GOV id aa11991; 21 May 90 17:41 EDT Date: Mon 21 May 90 14:43:11-PDT From: William Chops Westfield Subject: Re: A SUSPICIOUS SECURE GATEWAY To: mmorse@note.nsf.gov cc: tcp-ip@NSF.GOV In-Reply-To: <9005211349.aa00180@Note.NSF.GOV> Message-ID: <12591537844.24.BILLW@mathom.cisco.com> cisco routers have supported very general packet access list mechanisms for some time. I believe that the ciscos can do everything the modified KA9Q can do, as well as other things (although in a rather more complex manner). Similar access list mechanisms are supported for otehr protocols. Bill Westfield cisco Systems. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052109494800> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Mon, 21 May 90 11:05:43 PDT To: tcp-ip@NSF.GOV Subject: Re: A SUSPICIOUS SECURE GATEWAY Date: Mon, 21 May 90 13:49:48 EDT From: Michael Morse Message-ID: <9005211349.aa00180@Note.NSF.GOV> Are any commercial router vendors considering implementing this kind of security? --Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052109553600> Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 21 May 90 22:08:00 PDT Received: by WLV.IMSD.CONTEL.COM (5.61/1.25) id AA18593; Mon, 21 May 90 21:35:36 -0700 Date: Mon, 21 May 90 21:35:36 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Message-Id: <9005220435.AA18593@WLV.IMSD.CONTEL.COM> To: tcp-ip@nic.ddn.mil Subject: ATT and TWG Products My group is responsible for the installation and distribution of a number of different software products on a number of different platforms. I appreciate the alerts of problems with an application in a given software environment on a given hardware system. I don't appreciate, generalized, bashing of a specific product or vendor without stating the equivalent of name, rank, and serial number. It strikes me as being counter-productive to the goals that one wants to achieve--namely, a solution to a specific problem, If you have a plaint concerning a product, please be specific about the part, model, or other identification of the product, Also be clear about the en- vironment in which you are using the product. Now that I've aired my beef, please continue with reporting of problems. This allows me to approach the vendor to verify that the problem has been resolved or to suggest to my customers other products that do not exhibit the problems. Merton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052111003000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 08:49:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA12383; Mon, 21 May 90 08:43:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 May 90 11:00:30 GMT From: vsi1!teda!ditka!kls@apple.com (Karl Swartz) Organization: Inaction Central, San Jose, California Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <25086@ditka.UUCP> References: <29973@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <29973@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >If you have the WIN/3B card and the Wollongong Software on your 3B1, are YOU >happy with the performance? Well, at present there's just ditka, without even a transceiver cable connected to the back. The other machine expected to be on my Bedroom Area Network (BAN) doesn't have a board yet. And I'm still unhappy with the network performance of with LOSE/3B (er, WIN/3B) package. Shortly after installing the stuff I noticed that my UUCP connections were taking dramatically longer. Looking at xferstats the reason became apparent -- while outgoing TrailBlazer traffic was going at full speed, incoming traffic had dropped from 1100 BPS down to around 200 - 300 BPS, with one large news batch turning in an astoundingly bad 84 BPS. Further investigation revealed that incoming characters were dropping like crazy. Hmmmm ... all the HFC control signals were still there and seemed to be doing the right things. Besides, with g-protocol and the stock 3 windows, it shouldn't matter. The only way to lose in this case would be the device driver simply not responding in time. Yet the characters dropped even when nothing else was happening on the machine, not even any activity shown by Metermaid. Thinking about recent changes, I disabled the WIN/3B stuff, and low and behold, uucp ran at full speed again. Still no observable change in the Metermaid. I turned WIN/3B back on, and bits started spewing all over the floor again. As a further experiment, I disabled all the TCP/IP daemons (fingerd, ftpd, rlogind, rshd, and telnetd) but left the driver and other stuff running. That returned uucp to normal. So, running one or more of these daemons somehow screws up incoming uucp ports. I haven't tried to figure which one or ones is at fault. For reference, ditka is a 3B1 with 3.5 MB and two disks using the ICUS upgrade, running the 3.51dG1 kernel, which is almost 3.51m. I normally run the TrailBlazer Plus (4.0 ROMs) on tty000 but also gave it a try on the combo board's tty002 with similar results. >With uucp over StarLAN (1BASE5) ... Too bad their uucp doesn't run over TCP connections as it will with Starlan. And it's not just a documentation issue -- I ran strings on uucico and there's nothing in there that would suggest TCP support. :-( (This is HoneyDanBer; I could care less about broken uucp.) -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052111123100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 08:48:57 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA12396; Mon, 21 May 90 08:43:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 May 90 11:12:31 GMT From: vsi1!teda!ditka!kls@apple.com (Karl Swartz) Organization: Inaction Central, San Jose, California Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <25087@ditka.UUCP> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <3333@umbc3.UMBC.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3333@umbc3.UMBC.EDU> alex@umbc5.umbc.edu.UUCP (Alex S. Crain) writes: >Just a passing note, the uipc driver thats going around is >directly derived from BSD, all you need to do is add the driver for >the ethernet card and the af_inet code, available from uunet. Well, I've grabbed some of the higher level BSD code and started looking at the effort required to port it. Things like inetd, ping, and BIND for starters. And the BSD lpr package as I hate, despise, loath, and am otherwise disgusted by the System V lp rubbish. Alas, I've never done device drivers ... surely somebody must be able and willing to fill in this missing piece?! I'll happily do as much higher level stuff as I can. >I had always planned to add a slip interface ... SLIP was high on my list of wants. Ethernet has diminished my desire for it but I'd still like to have it. How 'bout it, folks? Seems we have several nice pieces here needing some attention. Here's your big chance to save the world! :-) >in between rebuilding my Harley, rehabbing my house, getting married, etc Minor problems, Alex. Get on with the important things! :-) -- Karl Swartz |UUCP uunet!apple!zygot!ditka!kls 1-408/223-1308 |INet zygot!ditka!kls@apple.com "I never let my schooling get in |BIX kswartz the way of my education."(Twain) |Snail 1738 Deer Creek Ct., San Jose CA 95148 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1572@ryn.esg.dec.com] <1990052112554100> From: taber@pstjtt.enet.dec.com Newsgroups: rec.ham-radio.packet,comp.protocols.tcp-ip Subject: Re: Quote without comment Message-ID: <1572@ryn.esg.dec.com> Date: 21 May 90 12:55:41 GMT Sender: guest@ryn.esg.dec.com Followup-To: rec.ham-radio.packet Organization: Digital Equipment Corporation Lines: 15 Posted: Mon May 21 13:55:41 1990 In article <23433@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes... > NETWORK SYSTEMS SPECIALIST > >familiar with the hardware/software aspects of LAN, network management and >operating systems, terminal emulation and host coupling, OSI protocols >INCLUDING TCP/IP [my emphasis - Phil], ... Yeah, so? OSI's TP4 is almost exactly TCP/IP -- that's no secret. >>>==>PStJTT Patrick St. Joseph Teahan Taber Mail address: Nahhhhh, you don't want to send me mail.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052117390200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 11:20:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22391; Mon, 21 May 90 11:18:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 May 90 17:39:02 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: Re. Wollongong TCP/IP Message-Id: <3362@auspex.auspex.com> References: <9005182006.AA00073@dragon.twg.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >If you want to see the best TCP/IP in its class, check out the TCP/IP >on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >It's Wollongong's. And we're proud of it. So AT&T threw out the Lachman-based one they supply standard with S5R4 and supply a Woolongong-based release instead? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052120305600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 04:08:01 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27392; Thu, 24 May 90 04:05:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 May 90 20:30:56 GMT From: sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!fiuggi!fiuggi!dds@ucsd.edu (Dennis D. Sherod) Organization: Data General, Irvine, CA Subject: RFI -- TCP/IP in Fortran Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Please don't make me explain why I need this info ;-} I would like to know if anyone has ever done a TCP/IP implementation in Fortran (flavor not important). I need some of the utilities (ftp, telnet, r*, smtp) as well as the kernel pieces. Again, please don't ask. -- Dennis Sherod, Data General Corporation UUCP: ..!uunet!spsd!d_sherod 2603 Main St., Ste. 360, Irvine, CA 92714 ARPA: d_sherod@irvine.dg.com FAX: +1 714 250 6061 VOICE: +1 714 250 6005 x4233 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052120505000> Received: from cheetah.nyser.net by NIC.DDN.MIL with TCP; Tue, 22 May 90 08:31:17 PDT Received: from localhost by cheetah.nyser.net at Tue, 22 May 90 08:30:56 -0700. (5.61.14/XIDA-1.2.8.34) id AA14153 for tcp-ip@nic.ddn.mil via SMTP To: menges@menges.UUCP Cc: tcp-ip@nic.ddn.mil Reply-To: snmp@nisc.nyser.net Subject: Re: SNMP Application Query In-Reply-To: Your message of 22 May 90 13:35:32 +0000. <14228@thorin.cs.unc.edu> Date: Tue, 22 May 90 08:30:50 -0700 Message-Id: <14149.643390250@cheetah.nyser.net> From: Marshall Rose Check out RFC1147. In addition there are now unlicensed SNMP implementations: MIT, CMU, and ISODE. Please direct further questions to the SNMP list (send a note to snmp-request@nisc.nyser.net to subscribe). /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12981@ulysses.att.com] <1990052123483400> From: ekrell@ulysses.att.com (Eduardo Krell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re. Wollongong TCP/IP Message-ID: <12981@ulysses.att.com> Date: 21 May 90 23:48:34 GMT References: <9005182006.AA00073@dragon.twg.com> <3362@auspex.auspex.com> Sender: netnews@ulysses.att.com Organization: AT&T Bell Labs Lines: 14 Posted: Tue May 22 00:48:34 1990 In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >So AT&T threw out the Lachman-based one they supply standard with S5R4 >and supply a Woolongong-based release instead? Not so, a quick scan at the header files shows that they all contain: * System V STREAMS TCP was jointly developed by Lachman Associates and * Convergent Technologies. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052200015200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 17:49:14 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16179; Mon, 21 May 90 17:37:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 00:01:52 GMT From: cs.umn.edu!wsmith@ub.d.umn.edu (Warren Smith [Randy]) Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1990May22.000152.25309@cs.umn.edu> References: <9005161338.AA07959@sayshell.umd.edu>, <1173@tnosoes.UUCP>, <23444@bellcore.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <23444@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: > .... >In my opinion, host security is both necessary and sufficient to prevent >break-ins. > >Phil I'll agree with necessary, but I'm not so sure about sufficient. Just because most break-ins so far have used known bugs doesn't mean they always will. The suspicious secure gateway seems to add an extra layer of security that can complement host security. Then of course, there is always the question of who the "known" bugs are known to. -Randy -- Randy Smith wsmith@umn-cs.cs.umn.edu ...!rutgers!umn-cs!wsmith ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052200164200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 17:22:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14905; Mon, 21 May 90 17:16:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 00:16:42 GMT From: andante!cbnewsm!cbnewsd!cage@EDDIE.MIT.EDU (charles.gerlach) Organization: AT&T Bell Laboratories Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <1990May21.162713.1244@cbnewsd.att.com> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Enough is enough. The 3B1 WIN release you are complaining about is over 4 years old. To the best of my knowledge, there has never been another release for the 3B1. (To say the 3B1 is "mature" is probably an understatement.) But in the meantime, there have been 2 major releases to the WIN/3B and WIN/386 product lines. To imply that what you got has any resemblance to the current releases is stretching it a bit. I agree with you when you talk about the problems with the 3B1 WIN release. After 4 years, it would be unrealistic to expect it not to have any. I totally disagree when you extrapolate these problems to cover the entire WIN/3B product line to date. To take the 3B1 WIN release as a fair representation of the current products is wrong. I think your real problem is what do you do now? How do you solve your problems? Unfortunately I don't have a solution. Hopefully someone else does. It just that bashing AT&T or TWG is not productive and does not get you closer to a solution. It may make you feel better but ... Well thanks for listening. Chuck Gerlach AT&T Bell Labs cag@iwlcs.att.com ...!att!iwlcs!cag ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052201295500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 13:26:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18578; Tue, 22 May 90 13:20:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 01:29:55 GMT From: mailrus!sharkey!cfctech!kevin@tut.cis.ohio-state.edu (Kevin Darcy) Organization: Chrysler Financial Corp., Southfield, MI Subject: Re: Re. Wollongong TCP/IP Message-Id: <22427@cfctech.cfc.com> References: <9005182006.AA00073@dragon.twg.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005182006.AA00073@dragon.twg.com> douglas@TWG.COM ("Douglas P. Ambort") writes: >Ouch! Mr. Floryan's indictment of AT&T's implementation of a very old >outdated version of Wollongong TCP/IP, ported a long time ago by AT&T >to its 3B1's is harsh. Given the 3B1, his indictment may not be >altogether off base; but it could be misconstrued by netnews readers as >a general indictment of all Wollongong TCP/IP (past, present, future, >and on good, bad or indifferent platforms). And such an indictment >would not only be unfair, but misinformed. He (Thad Floryan) criticizes the "latest" version of TCP/IP software publically available (and, if I'm not mistaken, still sold, perhaps only by Wollongong directly) for a still-existing base of 3B1's, based on his own personal experiences and professional expertise. I don't know what *you* would qualify as an "informed indictment"...? >In this case of the (the 3B1 shortcomings described by Mr. Floryan), >AT&T has simply chosen not to upgrade an ancient TCP/IP >on a platform that has been retired. Perhaps AT&T is concentrating on >new platforms? How convenient for Wollongong to blame AT&T for not updating the product, while AT&T can cite the unfeasibility of doing so, given the state of the original version (perhaps even give that as one of the marketing reasons that the UNIX PC line was discontinued). At some point, I would think that one or the other party would admit their mistake - either Wollongong for providing a flawed product, or AT&T for distributing it without adequate updates. >If you want to see the best TCP/IP in its class, check out the TCP/IP >on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >It's Wollongong's. And we're proud of it. Sorry, I don't have a 6386, I have a 3B1, along with a lot of other "cult diehards" who haven't joined the 80x86 tribe. I just bought a 3B1 ethernet card, and was looking forward to running TCP/IP on it to see what makes it tick. Now I hesitate. Would I be learning the *wrong* things from this setup? Is this really the ancestor of Wollongong's later products? >On the other hand, if someone must rail against an old TCP/IP >implementation on (let's face it) 'old iron', go ahead. And what happens when 3B2's or WGS's become 'old iron'? Cast them off in the same manner? I don't accuse Wollongong of being opportunistic and of only hyping their latest, sexiest implementations of TCP/IP on AT&T products, but if Mr. Ambort's attitude is representative of Wollongong's as a whole, it seems to be bordering very close to that... >You could just as easily criticise the skinny tires on a Model T >for not being steel belted radials. But, then again, software and tires differ in significant ways: one seemingly small deficiency or bug can render software useless for a given environment. It's not a question of *performance*, but (as I understand Mr. Floryan's comments), one of *functionality*. Those old tires *did work*, in other words. (Since this is at this point mainly a vendor-support and 3B1 performance issue, respondents please do not follow up to comp.protocols.tcp-ip. Thank you.) DISCLAIMERS: I speak only for myself (*not* at all for Chrysler); a concerned 3B1 owner who has not yet used the product, but heard of its shortcomings secondhand. ------------------------------------------------------------------------------ kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator ...[mailrus!]sharkey!cfctech!kevin | Technical Services (CFC) Voice: (313) 948-4863 | Chrysler Corporation Fax: (313) 948-4975 | 27777 Franklin, Southfield, MI 48034 ------------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12984@ulysses.att.com] <1990052201352400> From: ekrell@ulysses.att.com (Eduardo Krell[dgb]) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re. Wollongong TCP/IP Message-ID: <12984@ulysses.att.com> Date: 22 May 90 01:35:24 GMT References: <9005182006.AA00073@dragon.twg.com> <3362@auspex.auspex.com> <12981@ulysses.att.com> Reply-To: ekrell@ulysses.UUCP (Eduardo Krell[dgb]) Organization: AT&T Bell Laboratories, Murray Hill Lines: 14 Posted: Tue May 22 02:35:24 1990 In article <12981@ulysses.att.com> I wrote: >Not so, a quick scan at the header files shows that they all contain: > > * System V STREAMS TCP was jointly developed by Lachman Associates and > * Convergent Technologies. This is what I saw in the SVR4 source distribution. The binaries shipped with the AT&T machines are from Wollongong, though. Go figure ... -- Eduardo Krell AT&T Bell Laboratories, Murray Hill {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052203084400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 20:19:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25497; Mon, 21 May 90 20:15:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 03:08:44 GMT From: cs.utexas.edu!uwm.edu!rpi!image.soe.clarkson.edu!news@tut.cis.ohio-state.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Dial up access to Internet facilities Message-Id: References: , <9005190447.AA25263@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article hedrick@athos.rutgers.edu (Charles Hedrick) writes: I have a feeling that over the course of the next year or so even without a definite policy, the number of unrestricted terminal servers is going to fall off to nearly zero. That's too bad, because when I've gone travelling in the past, I've called the local university, asked for their terminal server's phone number, and telnetted back to Clarkson to check my mail. It's a shame that that kind of service has to go away... -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052203310900> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 22 May 90 12:15:09 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 8214; Tue, 22 May 90 08:42:50 EDT Received: by * (Mailer R2.03B) id 4630; Tue, 22 May 90 08:34:00 EST Date: Tue, 22 May 90 08:31:09 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: TCPIP for the 3B1 To: tcp-ip@nic.ddn.mil I find all this talk about WINTCP and BSD and 3B1s very interesting, but it leaves one very big question (at least to me.) Where does one look to find an ethernet card for a 3B1?? I have a pair of them that I would love to put on my ethernet and then start writing some decent software for them. I would have to write it myself, cause I sure couldn't afford to buy it from Wolongong!!! Any ideas about where I can find real cheap ethernet cards for a couple of 3B1s??? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052204265100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 21 May 90 21:50:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00173; Mon, 21 May 90 21:40:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 04:26:51 GMT From: mojo!smaug@mimsy.umd.edu (Kurt Lidl) Organization: Dragon Finishing School of Unix and Magic Subject: Re: Dealing with systems without nameservice. Message-Id: <1990May22.042651.1911@eng.umd.edu> References: <9005211548.AA13756@ucla-an.anes.ucla.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005211548.AA13756@ucla-an.anes.ucla.edu> stan@ANES.UCLA.EDU (Stan Stead) writes: > We are running 4.3 BSD. We currently use nameservice. >Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. Please reply to my email address directly. I was thinking about hacking in some changes to our version of libc gethost*() routines. We are currently running SunOS 4.0.3c on our Suns, but are looking at upgrading to 4.1... Sun has been good enough to tell us all how to make our own dynamically run libraries and I was thinking about putting in the U of Toronto's version of the resolver routines. One of the things that we have noticed is that if the nameservers are down, with the current version of libc (from uunet), nothing works. We have a small /etc/hosts file on all our machines that is kept up to date... What it all boils down to is this: If I alter the gethost*() routines to try the nameservers first, and then, if they fail, check the /etc/hosts files, will anything go terribly wrong? I am wondering why the current routines don't fall back on the hosts in /etc/hosts? Thanks. E-Mail is preferred, but I also read this newsgroup. -Kurt -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052204535800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 04:22:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16261; Tue, 22 May 90 04:14:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 04:53:58 GMT From: sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Max FDDI frame rate on the glass Message-Id: <60732@sgi.sgi.com> References: <2651C1E1.23165@orion.oac.uci.edu>, <24484@mimsy.umd.edu>, <26548E64.20897@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Anyone not yet saturated by the FDDI (mis)tuning discussion should also check out traffic posted recently on "comp.dcom.lan" on the same subject. (Some of the stuff may duplicate what has been said here recently, but not all.) -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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1516@quando.UUCP] <1990052207051700> From: wichert@quando.UUCP (Peter Wichert) Newsgroups: comp.protocols.tcp-ip Subject: tcp problem auf MX500 Keywords: tcp Message-ID: <1516@quando.UUCP> Date: 22 May 90 07:05:17 GMT Reply-To: wichert@quando.UUCP (Peter Wichert) Distribution: dnet Organization: Quantum GmbH, Dortmund, W-Germany Lines: 21 Posted: Tue May 22 08:05:17 1990 References: Hallo, Ich habe das Problem, eine tcp-ip Verbindung mit Siemens MX500 Rechnern aufzubauen. In unserem Netz gibt es diverse Rechner verschiedener Hersteller (HP, Nixdorf, Sun), und zwischen allen laeuft das Programm (Client/Server). Auf der MX500 liefert aus mir unerklaerlichen Gruenden das 'connect' die Fehlermeldung "connection refused", was natuerlich nicht viel aussagt. ftp, rlogin usw. funktioniert, lokale Verbindungen innerhalb der MX500 klappen auch, nur zu anderen Rechnern per eigenen Sockets geht's nicht. Hat jemand eine Idee ???? -- Peter Wichert UUCP: {backbone}!unido!quando!wichert OR wichert@quando.uucp Quantum GmbH Bitnet: UNIDO!quando!wichert OR wichert%quando@UNIDO(.bitnet) Dortmund internet: wichert%quando%unido.UUCP@mcsun.cwi.nl Germany internet: wichert@quando.quantum.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052208144500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 21:51:42 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19073; Tue, 22 May 90 21:51:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 08:14:45 GMT From: mcsun!ukc!acorn!tenset!paul@uunet.uu.net (Paul Andrews) Organization: Tenset Technologies Limited, Cambridge, United Kingdom Subject: Packet drivers & Novell (confused...) Message-Id: <537@tenset.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm getting confused about whats needed to run IPX over a packet driver on a Novell diskless workstation (as you can probably guess, I haven't tried it yet but I will have to in the future). A document that comes with 6.x of the packet drivers says you need to run romrel because simply delaying the card initialisation by the packet driver doesn't work. A recent posting of a mod to the 5.x head & tail.asm suggested that a delay was sufficient. I know that there may be many variables here, but can people with experience of this let me know which approach worked for them? I guess for a true comparison you would really have had to use John's mods in case he does something different for the initialisation delay, but anyway... I was in the process of making a similar mod to the 6.x head and tail.asm that John had made to 5.x, I wouldn't have got it working without Johns posting though. I have an addition that you can turn of the 802.3<->DIX translation with an optional command line switch if you want to run in 'pure' mode. If anyone is interested in having the mod, mail me and I'll arrange it. All the mods are ifdef'd so you can assemble the original code using an assembler switch. - Paul -- ------------------------------------------------------------------ | Paul Andrews | Post: Tenset Technologies Limited, | | paul@tenset.uucp | Norfolk House, | | Phone: +44 223 328886 | 301 Histon Road, | | Fax: +44 223 460929 | Cambridge CB4 3NF, UK. | ------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052208444000> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Tue, 22 May 90 02:01:38 PDT Received: by mcsun.EU.net via EUnet; Tue, 22 May 90 11:02:38 +0200 (MET) Message-Id: <9005220902.AA25385@mcsun.EU.net> Received: from cctal by kestrel.Ukc.AC.UK with UUCP id aa09833; 22 May 90 9:55 BST To: tcp-ip@nic.ddn.mil Subject: Background Ethernet under MS-DOS? Cc: cctal!andrew@relay.EU.net Date: Tue May 22 08:44:40 1990 From: cctal!andrew@relay.EU.net Does any one know of a way or a product to give background file transfer over Ethernet with an Ethernet card in a PC running MS-DOS? I am looking for the Ethernet equivalent of the program "Backmail" which gives this sort of function over modem dialup. background while foregound word processor (Wordperfect) continues. Thanks Replies+Interest--->Summary to net Andrew Hardie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052209465100> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 22 May 90 11:25:28 PDT Received: from MSU.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0298; Tue, 22 May 90 14:06:25 EDT Received: by MSU (Mailer R2.03B) id 0049; Tue, 22 May 90 14:00:39 EDT Date: Tue, 22 May 90 13:46:51 EDT From: Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: Dealing with systems without nameservice. To: Stan Stead , "TCP/IP list (plus more)" , "Kurt J. Lidl" In-Reply-To: Your message of Mon, 21 May 90 08:48:37 -0700 From Stan Stead: > We are running 4.3 BSD. We currently use nameservice. However, >a site that we wish to exchange mail and files, while connected to the >internet, does not use nameservice. We can access the site by internet >number, but not by name. Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. The real answer is for them to set up name service. I can't think of any good reason for sites attached to the internet to not be running name service, or to find a site that can run name service for them. And from Kurt Lidl: >One of the things that we have noticed is that if the nameservers >are down, with the current version of libc (from uunet), nothing >works. We have a small /etc/hosts file on all our machines that is >kept up to date... If the name servers go down too frequently, you may want to set up more name servers, at least in caching mode. >What it all boils down to is this: If I alter the gethost*() >routines to try the nameservers first, and then, if they fail, check >the /etc/hosts files, will anything go terribly wrong? I am >wondering why the current routines don't fall back on the hosts in >/etc/hosts? This topic has been discussed. The answer is that for most applications (Telnet, FTP, etc.) the worst that will happen is that you will use the wrong address for a host due to old information. For mail, it can be worse - an SMTP mailer will likely bounce some mail because the host isn't listed in the hosts file. Or it may mis-deliver it due to the use of old information, or the failure to take MX records into account. Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052211504300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 08:05:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28989; Tue, 22 May 90 08:05:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 11:50:43 GMT From: usc!samsung!emory!hubcap!ncrcae!secola!syackey@ucsd.edu (Steve Yackey) Organization: NCR Comten Columbia Subject: Re: Re. Wollongong TCP/IP Message-Id: <539@secola.Columbia.NCR.COM> References: <9005182006.AA00073@dragon.twg.com>, <3362@auspex.auspex.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>If you want to see the best TCP/IP in its class, check out the TCP/IP >>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >>It's Wollongong's. And we're proud of it. > >So AT&T threw out the Lachman-based one they supply standard with S5R4 >and supply a Woolongong-based release instead? no, when you buy 5.4 you get lachman tcp. when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052212083500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 10:21:28 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07143; Tue, 22 May 90 10:14:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 12:08:35 GMT From: psuvm!pmw1@psuvax1.cs.psu.edu (Peter Weiss) Organization: Penn State University Subject: Re: Dial up access to Internet facilities Message-Id: <90142.080835PMW1@psuvm.psu.edu> References: , <9005190447.AA25263@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , nelson@sun.soe.clarkson.edu (Russ Nelson) says: >That's too bad, because when I've gone travelling in the past, I've called >the local university, asked for their terminal server's phone number, and >telnetted back to Clarkson to check my mail. It's a shame that that kind >of service has to go away... Actually, you can still check your mail, but for the price of a toll call back to your own terminal server. Maybe this is the price we have to pay for added security? /Pete -- Peter M. Weiss | (this line intentionally left blank) 31 Shields Bldg (the AIS people) | 2 4 6 8 We don't want to calculate! University Park, PA USA 16802 | Disclaimer -* +* applies herein ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052212393400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 08:05:37 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28144; Tue, 22 May 90 07:50:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 12:39:34 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!hybrid!robohack!woods@tut.cis.ohio-state.edu (Greg A. Woods) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <1990May22.123934.21520@robohack.UUCP> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <1990May21.162713.1244@cbnewsd.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes: > I agree with you when you talk about the problems with the 3B1 WIN > release. After 4 years, it would be unrealistic to expect it not to > have any. I totally disagree when you extrapolate these problems to > cover the entire WIN/3B product line to date. To take the 3B1 WIN > release as a fair representation of the current products is wrong. I assume, from what I see on the References line, that you are refering to the "flame" I wrote. I must appologize if it sounded like I was flaming AT&T or the current WIN/3B product. I've never seen the WIN/3B1 software, and I'm unlikely to ever get much direct experience with it. The WIN/3B I was refering to was either for the 3B2 or some non-AT&T machine. It was also at least two years old. However, I do know that there are still sites hobbling along on with it. They don't know any better solution, and they do flame AT&T and TWG. It is unfortunate that AT&T chose the original WIN/3B. The original WIN/3B has tainted my feelings, and I'm unlikely to ever try any current version. -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005230242.AA12279@ucbvax.Berkeley.EDU] <1990052213310900> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: TCPIP for the 3B1 Message-ID: <9005230242.AA12279@ucbvax.Berkeley.EDU> Date: 22 May 90 13:31:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Posted: Tue May 22 14:31:09 1990 I find all this talk about WINTCP and BSD and 3B1s very interesting, but it leaves one very big question (at least to me.) Where does one look to find an ethernet card for a 3B1?? I have a pair of them that I would love to put on my ethernet and then start writing some decent software for them. I would have to write it myself, cause I sure couldn't afford to buy it from Wolongong!!! Any ideas about where I can find real cheap ethernet cards for a couple of 3B1s??? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052213353200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 07:50:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27499; Tue, 22 May 90 07:37:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 13:35:32 GMT From: thorin!menges!menges@mcnc.org (John Menges) Subject: SNMP Application Query Message-Id: <14228@thorin.cs.unc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've been away from network management for a while and need an update on what's available in the way of SNMP applications for under, say, $2500. A year ago I'd have chosen Nysernet's SNMP distribution, possibly augmented by CMU's or MIT's public domain stuff. Is anything else available now? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052214231600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 07:51:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28109; Tue, 22 May 90 07:50:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 14:23:16 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!jhunix!ereiamjh@ucsd.edu (Tom B. O'Toole) Organization: The Johns Hopkins University - HCF Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <5333@jhunix.HCF.JHU.EDU> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <1990May21.162713.1244@cbnewsd.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes: >Enough is enough. >The 3B1 WIN release you are complaining about is over 4 years old. To >the best of my knowledge, there has never been another release for the >3B1. (To say the 3B1 is "mature" is probably an understatement.) If it's so "mature" (translation "we won't support you any more"), shouldn't it at least work? It doesn't make much sense to declare something "mature" if it's obviously so immature... I also find it suspect that something that is not all THAT old should have been retired over 4 years ago. The VAX 11/780 is much older and new software releases are still coming out for that platform. An eye towards compatibility can work wonders... >I totally disagree when you extrapolate these problems to >cover the entire WIN/3B product line to date. To take the 3B1 WIN >release as a fair representation of the current products is wrong. Is the release of WIN/3b for the 3b/4000 considered current? It still has myriad problems. But I guess that doesn't matter because the 3b/4000 is now "mature", right??? Everyone should move on to yet another platform which is not binary compatible at the OS or applications level. > >I think your real problem is what do you do now? How do you >solve your problems? Unfortunately I don't have a solution. For starters, maybe AT&T should stop moving rapidly from platform to non-compatible platform, stating that each is the next "great thing" only to abandon it two years down the road. But since they keep doing this, I agree, there isn't a solution; the user is totally hosed. >Hopefully someone else does. It just that bashing AT&T or TWG >is not productive and does not get you closer to a solution. It >may make you feel better but ... People will feel even better when AT&T and TWG don't deserve to be bashed, but for now, it's the only "solution" they have... >Well thanks for listening. Is AT&T? -- Tom O'Toole - ecf_stbo@jhuvms.bitnet "Internet is the wide area network JHUVMS system programmer protocol packaged with TCP/IP that unix systems Homewood Computing Facilities rely on to communicate remotely with each other" Johns Hopkins University, Balto. Md. 21218 -Digital Review ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052214320500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 07:51:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27726; Tue, 22 May 90 07:41:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 14:32:05 GMT From: paperboy!meissner@think.com (Michael Meissner) Organization: Open Software Foundation Subject: Re: Dealing with systems without nameservice. Message-Id: References: <9005211548.AA13756@ucla-an.anes.ucla.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May22.042651.1911@eng.umd.edu> smaug@eng.umd.edu (Kurt Lidl) writes: | I was thinking about hacking in some changes to our version of libc | gethost*() routines. We are currently running SunOS 4.0.3c on our | Suns, but are looking at upgrading to 4.1... Sun has been good | enough to tell us all how to make our own dynamically run libraries | and I was thinking about putting in the U of Toronto's version of | the resolver routines. | | One of the things that we have noticed is that if the nameservers | are down, with the current version of libc (from uunet), nothing | works. We have a small /etc/hosts file on all our machines that is | kept up to date... | | What it all boils down to is this: If I alter the gethost*() | routines to try the nameservers first, and then, if they fail, check | the /etc/hosts files, will anything go terribly wrong? I am | wondering why the current routines don't fall back on the hosts in | /etc/hosts? While this may not apply to Suns, other systems provide means that a system manager can configure the order hosts are searched (/etc/hosts, yp, and DNS). I know both DG/UX and Ultrix provide this capability (in a slightly different fashion). Here is the appropriate man page from Ultrix: NAME svcorder - designate the order and selection of services SYNTAX /etc/svcorder DESCRIPTION The file designates the order and selection of name services that will be queried to resolve host names and addresses. The queries to the services are made through the interface. The file must exist if your system accesses host names and addresses by database lookup services such as Yellow Pages (YP) or BIND. You do not need the file if you only have local access, that is, if you are using only the local file to obtain host name and address information. The service names are defined in the file. The order in which the service names are placed in the file indicates the order that they are queried to resolve a given name or address. The following example shows the contents of the file if YP will be queried first, then BIND, and then the local service, if YP cannot resolve the data: yp bind local The file must have an entry for Otherwise, your system cannot resolve any queries in the event that the lookup services, other than local, are down. If you set up a database lookup service such as YP or BIND, be sure that the file exists. Create the file if it does not. The and commands do this automatically. FILES /etc/hosts /usr/include/netdb.h /etc/svcorder SEE ALSO gethostent(3n), hosts(5), bindsetup(8), ypsetup(8yp) Guide to the BIND Service Guide to the Yellow Pages Service -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005230215.AA10732@ucbvax.Berkeley.EDU] <1990052217465100> From: 08071TCP@MSU.BITNET (Doug Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dealing with systems without nameservice. Message-ID: <9005230215.AA10732@ucbvax.Berkeley.EDU> Date: 22 May 90 17:46:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 36 Posted: Tue May 22 18:46:51 1990 From Stan Stead: > We are running 4.3 BSD. We currently use nameservice. However, >a site that we wish to exchange mail and files, while connected to the >internet, does not use nameservice. We can access the site by internet >number, but not by name. Is there anyway to "hot-wire" an address >(perhaps via /etc/hosts). Currently, the only way /etc/hosts is read >is if named is not running. The real answer is for them to set up name service. I can't think of any good reason for sites attached to the internet to not be running name service, or to find a site that can run name service for them. And from Kurt Lidl: >One of the things that we have noticed is that if the nameservers >are down, with the current version of libc (from uunet), nothing >works. We have a small /etc/hosts file on all our machines that is >kept up to date... If the name servers go down too frequently, you may want to set up more name servers, at least in caching mode. >What it all boils down to is this: If I alter the gethost*() >routines to try the nameservers first, and then, if they fail, check >the /etc/hosts files, will anything go terribly wrong? I am >wondering why the current routines don't fall back on the hosts in >/etc/hosts? This topic has been discussed. The answer is that for most applications (Telnet, FTP, etc.) the worst that will happen is that you will use the wrong address for a host due to old information. For mail, it can be worse - an SMTP mailer will likely bounce some mail because the host isn't listed in the hosts file. Or it may mis-deliver it due to the use of old information, or the failure to take MX records into account. Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052219051200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 17:23:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03813; Tue, 22 May 90 17:20:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 19:05:12 GMT From: vmp!sonyd1!bruce@uunet.uu.net (Bruce Lilly) Organization: Sony Communications Products Company, Teaneck, NJ Subject: Re: Poor 3B1 WIN/3B TCP/IP performance; Moto 6300 Ethernet SW Message-Id: <1990May22.190512.5756@sonyd1.uucp> References: <29973@cup.portal.com>, <1990May18.044932.28911@robohack.UUCP>, <1990May21.162713.1244@cbnewsd.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May21.162713.1244@cbnewsd.att.com> cage@cbnewsd.att.com (charles.gerlach) writes: >Enough is enough. > >The 3B1 WIN release you are complaining about is over 4 years old. To >the best of my knowledge, there has never been another release for the >3B1. (To say the 3B1 is "mature" is probably an understatement.) > >But in the meantime, there have been 2 major releases to the WIN/3B and >WIN/386 product lines. To imply that what you got has any resemblance >to the current releases is stretching it a bit. > >I agree with you when you talk about the problems with the 3B1 WIN >release. After 4 years, it would be unrealistic to expect it not to >have any. I totally disagree when you extrapolate these problems to >cover the entire WIN/3B product line to date. To take the 3B1 WIN >release as a fair representation of the current products is wrong. If one's sole experience with WIN/3B is the version for the 3B1, and neither Wollongong nor AT&T has issued a fixdisk or other update for the product, then it is reasonable to expect that the vendor(s) are not interested in correcting the problems, and therefore the product IS probably representative of other products from the vendor(s). >I think your real problem is what do you do now? How do you >solve your problems? Unfortunately I don't have a solution. >Hopefully someone else does. It just that bashing AT&T or TWG >is not productive and does not get you closer to a solution. It >may make you feel better but ... The real problem is what should AT&T and Wollongong do now? Speaking for myself, I will certainly not buy any other Wollongong/AT&T product unless and until they ``make good'' that which I have purchased. Although the 3B1 has been discontinued, AT&T has supported it with fixdisks. A similar policy regarding the AT&T/Wollongong WIN/3B product for the 3B1 would go a long way towards easing the current hard feelings toward the product. It would seem to be in AT&T's interest to ensure that the product works reasonably (especially the TLI routines -- AT&T's answer to Berkeley-style networking) since AT&T's name is on the product. Similarly, it is in Wollongong's interest to make a reasonable effort to correct the product's deficiencies in order to AVOID the impression that all Wollongong products are similarly deficient. This is simply good business practice. Finally, I don't recall seeing any ``bashing'' of either AT&T or Wollongong -- simply the result of frustrations caused by a clearly deficient product. Disclaimer: these are my opinions, not my employer's. -- Bruce Lilly, Product Manager, | bruce@sonyd1.Broadcast.Sony.COM Digital Television Tape Recording, | uunet!{sonyusa,vmp}!sonyd1!bruce Sony Communications Products Co. | lilb@sony.compuserve.com (slow) Telephone: 1(201)833-5693 | FAX: 1(201)833-9279 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1381@athen.sinix.UUCP] <1990052219532000> From: pete@sinix.UUCP (Pete Delany) Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip,bit.listserv.tcpip-l,comp.lang.postscript,comp.windows.news Subject: NeFS - Network Extensible File System Keywords: NeFS, NeWS, PS, PostScript, NFS, TCP, IP Message-ID: <1381@athen.sinix.UUCP> Date: 22 May 90 19:53:20 GMT Reply-To: pete@athen.UUCP Organization: Siemens AG, DI ST SP4, Munich Lines: 18 Posted: Tue May 22 20:53:20 1990 Carl Smith mentioned that: > > The NFS version 3 protocol (now called NeFS - Network extensible > File System) is available as a PostScript file via anonymous > FTP as > > ./public/nefs.doc.ps on titan.rice.EDU (128.42.1.30). > > the file is ~250K and generates 52 pages. Is there a recient posting on usenet and if not could someone post one to make it easily available? It would take a non-trivial amount of work to FTP a copy and get it here. It sounds very important, and more than worthy of a posting. For those that have read the new NFS spec, any opinion? Sounds a bit like Microsoft focusing more on Windows 3.0 than OS2 (See Wall Street Journal 22-May-90). -pete ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052220363400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 13:20:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA18033; Tue, 22 May 90 13:12:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 20:36:34 GMT From: stealth.acf.nyu.edu!brnstnd@nyu.edu Organization: IR Subject: Re: Dealing with systems without nameservice. Message-Id: <611:May2220:36:3490@stealth.acf.nyu.edu> References: <9005211548.AA13756@ucla-an.anes.ucla.edu>, <1990May22.042651.1911@eng.umd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Perhaps gethostbyname() should use intra-machine IPC (e.g., UNIX-domain sockets) to connect to the nameserver. This would have the advantage of strict modularity: you could change the name lookup mechanism without even recompiling any programs. It also wouldn't require the burden of shared libraries. /dev/hostbyname, maybe. > One of the things that we have noticed is that if the nameservers > are down, Gasp! Your nameservers go down? This can't be the ultra-reliable DNS we're talking about here? ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052222153000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 16:07:01 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28677; Tue, 22 May 90 15:55:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 May 90 22:15:30 GMT From: cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!atha!lyndon@tut.cis.ohio-state.edu (Lyndon Nerenberg) Organization: Athabasca University Subject: is "localhost" an official name? Message-Id: <1898@aurora.cs.athabascau.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I seem to recall reading in an RFC somewhere that the loopback interface must have loopback[.domain] as it's name, or as an alias. Is this in fact the case? If so, I would appreciate a reference ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052300151700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 17:36:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03884; Tue, 22 May 90 17:21:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 00:15:17 GMT From: mogul@decwrl.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <435@jove.dec.com> References: <9005161338.AA07959@sayshell.umd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Phil Karn and Louie Mamakos have come down pretty hard against filtering in routers. Phil sez In my opinion, host security is both necessary and sufficient to prevent break-ins. Well, we've had a fair amount of experience with a screening gateway between thousands of hosts inside DEC and the cruel world out there. (People who want to know the details: see my paper in Proc. USENIX Summer '89.) Anyone who thinks that it is possible to keep that many hosts secure (most of them run by people who aren't interested in keeping them secure, and probably wouldn't know how to do it) is dreaming. Of course these machines can and should be fixed; at the same time, we would be fools to believe that they all ever will be. The advantage of the screening gateway is that we reduce the size of the set of must-be-secure hosts from 10K or 100K down to around 10 or 100. I assert that it is possible to build a screening gateway that will guarantee that only these hosts are exposed to attacks from the network. (This is not to say that all implementations are secure, of course!) There is always the temptation to push the limits of this guarantee. For example, we do allow certain kinds of packets to flow between the Internet and random DEC hosts. This is done in the belief that what we are doing is safe, but ultimately it is a tradeoff between possibly impairing security and definitely impairing functionality. If we discover that we have misunderstood the security implications, we can pull the plug on this bypass at one place: the screening gateway. We don't have to run around to 100K hosts and fix them all, and we don't have to unplug from the network entirely while we try to discover what happened. Louie sez I know that I can't sleep any better at night knowing that I have a filtering gateway "protecting" me. If you want security, you need to take a comprehensive approach to providing it, not shots in the dark here and there. I do sleep better knowing that the screening gateway is there. We've had machines attacked by numerous and occasionally clever hackers, but as far as we know (we could be wrong) the hosts inside the screen have been untouched by such attacks as the Morris Worm and the Australians earlier this year. In both those instances, I can point to specific ways in which the screen prevented the problem from spreading. I would not want to say that any of these hackers would have been stopped forever by the screen, and I would not want to say that I am sure that the screen protects me ... but I do sleep better. (I know that the lock on my front door could be picked, but I wouldn't get as much sleep if it were removed!) In summary, a screening gateway is NOT a "shot in the dark", and it IS part of a "comprehensive approach" to security. I claim that for the time being, it is a required part of any approach that could be claimed to be comprehensive; you can't rely on one mechanism for security. Think of an ocean liner: the captain had better not let the ship hit an iceberg, but when it happens (and it does!) those watertight bulkhead doors may well save the passengers. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052300485400> Received: from cise.cise.nsf.gov by NIC.DDN.MIL with TCP; Wed, 23 May 90 04:27:58 PDT Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id ; Wed, 23 May 90 07:28:57 -0400 From: Stephen Wolff Received: by ncri.cise.nsf.gov id ; Wed, 23 May 90 07:28:54 -0400 Date: Wed, 23 May 90 07:28:54 -0400 Message-Id: <9005231128.AA19114@ncri.cise.nsf.gov> To: psuvm!pmw1@PSUVAX1.CS.PSU.EDU Subject: Re: Dial up access to Internet facilities Cc: tcp-ip@NIC.DDN.MIL In article , nelson@sun.soe.clarkson.edu (Russ Nelson) says: >That's too bad, because when I've gone travelling in the past, I've called >the local university, asked for their terminal server's phone number, and >telnetted back to Clarkson to check my mail. It's a shame that that kind >of service has to go away... Dial-up access is now offered as a commercial service in some cities. It's all a part of the Internet's growing up... -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052303234100> Received: from hp-sde.sde.hp.com by NIC.DDN.MIL with TCP; Wed, 23 May 90 10:22:44 PDT Received: from hp-ses.sde.hp.com by hp-sde.sde.hp.com with SMTP (16.2A/15.5+IOS 3.13) id AA03821; Wed, 23 May 90 10:00:13 -0700 Received: by hp-ses.sde.hp.com (15.11/15.5+IOS 3.21) id AA20278; Wed, 23 May 90 10:23:41 pdt Date: Wed, 23 May 90 10:23:41 pdt From: Walter Underwood Message-Id: <9005231723.AA20278@hp-ses.sde.hp.com> To: tcp-ip@nic.ddn.mil Subject: Re: A SUSPICIOUS SECURE GATEWAY Newsgroups: comp.protocols.tcp-ip In-Reply-To: article <435@jove.dec.com> of Wed, 23 May 1990 00:15:17 GMT Jeff Mogul: The advantage of the screening gateway is that we reduce the size of the set of must-be-secure hosts from 10K or 100K down to around 10 or 100. HP does exactly the same thing. I think of it as similar to international borders. If you are flying into the US, you must land at an international airport. You can't land at any random airstrip. Maybe 1% of the airports in the US are set up with customs agents and all that border jazz. Same thing for hosts in HP. Less than 1% are "open subnet hosts", and those get special attention. We don't issue visas, though. That is Jeff's department. wunder ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052303472100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 22 May 90 21:06:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16417; Tue, 22 May 90 21:03:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 03:47:21 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <23521@bellcore.bellcore.com> References: <9005161338.AA07959@sayshell.umd.edu>, <435@jove.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <435@jove.dec.com> mogul@decwrl.dec.com (Jeffrey Mogul) writes: >[...] I assert that it is possible to build a screening gateway >that will guarantee that only these hosts are exposed to attacks from >the network. (This is not to say that all implementations are secure, >of course!) How sure are you? You have a pretty big network, probably much larger than ours, and if it's at all like ours I bet you don't keep perfect track of *everything* that might be attached to it. Are you willing to bet that in some remote backwater of your network there isn't an unprotected Cisco terminal server or a Xylogics Annex box connected to a bunch of outside modem lines? How about the BSD workstation or PC running KA9Q or PCroute that somebody sets up in his office between his Ethernet tap and his office phone to give himself unpassworded, ad-hoc SLIP access from home? And are you willing to bet that every host on your network with outside dialups is completely secure? I think it's a rare organization whose ONLY possible route to the outside world is through exactly one IP router. I think that filtering IP routers are like the Maginot Line. The latter did exactly what it was designed to do. It's just that the Germans had plenty of other routes for attacking the West, so they simply went around it. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052306463900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 04:06:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08471; Wed, 23 May 90 04:00:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 06:46:39 GMT From: eru!luth!sunic!mcsun!inria!irisa!leconte@bloom-beacon.mit.edu (Thierry Leconte) Organization: IRISA, Rennes (Fr) Subject: C source of sftp (RFC913) wanted Message-Id: <1990May23.064639.12579@irisa.fr> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for public domain C sources of the Simple File Transfer Protocol (RFC 913) or any other simple file transfer protocol that use exclusively tcp (and not udp ). Please answer by email Thanks in advance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Thierry LECONTE | , ,--- ,--- | | INRIA/IRISA | / / /--- | | Campus de Beaulieu | (___ (___ (___ | | 35042 RENNES CEDEX | | | FRANCE | GOTHIC project (INRIA/BULL) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Tel: 99 36 20 00 e-mail: Thierry.Leconte@irisa.fr | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052307190000> Received: from ecs.umass.edu (omega.ecs.umass.edu) by NIC.DDN.MIL with TCP; Wed, 23 May 90 08:17:24 PDT Date: Wed, 23 May 90 11:19 EDT From: PARCHAMB@ecs.umass.edu Subject: mailing list To: tcp-ip@nic.ddn.mil Message-id: <8E58F37329DF40024E@UMAECS> X-Envelope-to: tcp-ip@nic.ddn.mil X-VMS-To: IN%"tcp-ip@nic.ddn.mil" Please Remove my name from the mailing list Thanks, Peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052311261900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 06:23:48 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14547; Wed, 23 May 90 06:11:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 11:26:19 GMT From: mojo!smaug@mimsy.umd.edu (Kurt Lidl) Organization: Dragon Finishing School of Unix and Magic Subject: Re: Dealing with systems without nameservice. Message-Id: <1990May23.112619.14724@eng.umd.edu> References: <9005230215.AA10732@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Doug Nelson (08071TCP@MSU.BITNET) writes: >And from Kurt Lidl: >>One of the things that we have noticed is that if the nameservers >>are down, with the current version of libc (from uunet), nothing >>works. We have a small /etc/hosts file on all our machines that is >>kept up to date... > >If the name servers go down too frequently, you may want to set up >more name servers, at least in caching mode. The particular incident that started this line of questioning on my part was dealing with a one second power glitch that nailed the SOA nameserver and the two caching nameservers for our network. All the dataless clients that were hit came up first (just a local hard disk to fsck, compared to a couple of gigabytes of storage on the nameserving machines), and then failed to add the default gateway when "route" was unable to get the address of the gateway from the nameservers. I guess the real solution to the problem is giving the SOA nameserver have a UPS of its own. (Aha! The solution involves spending money. Luckily, it is not my money.) >>[my naive question was here] >This topic has been discussed. Are there a comprehensive sets of archives that I can FTP from someplace or another? I assume that someone must archive this group for posterity's sake. (I don't remember seeing a "Commonly Asked Questions" message, or any announcements of a archive site for this newsgroup. Maybe I just missed them.) >Doug Nelson I would also like to take this opportunity to thank all of the individuals who responded to my questions in a most helpful manner. Jim Guyton guyton@rand.org Richard Dunbar rdunbar@dftsrv.gsfc.nasa.gov Tony Nardo trn@warper.jhuapl.edu Steve Miller steve@umiacs.umd.edu Doug Nelson 08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu (reply posted to tcp-ip as well as mailed) The general concensus was that having the gethost*() routines fall back on the /etc/hosts file is "iffy at best". I may try the modifications for the heck of it, at least for the simple address lookup call. Several of the responses pointed out that bad interactions would happen with MX-record things and so forth... Steve pointed out that keeping anything in the /etc/hosts file that was not under my administrative control would be a *bad* thing to do. I agree with this whole-heartedly. If I have any really outrageous problems with the modifications, I will let the list know about them. Also, if anyone can give a really good reason NOT to make these changes, please mail me. The worst that has been pointed out to me was the possibility of some bounced mail. Thanks again. -- /* Kurt J. Lidl (smaug@eng.umd.edu) | Unix is the answer, but only if you */ /* UUCP: uunet!eng.umd.edu!smaug | phrase the question very carefully. */ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052312140900> Received: from psi.com by NIC.DDN.MIL with TCP; Wed, 23 May 90 15:56:32 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA00559; Wed, 23 May 90 18:54:10 -0400 Message-Id: <9005232254.AA00559@psi.com> To: snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu (Steve Dyer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-Reply-To: Your message of 23 May 90 16:38:25 +0000. <2936@ursa-major.SPDCC.COM> Date: Wed, 23 May 90 18:54:09 -0400 From: "Martin Lee Schoffstall" Steve and Steve, PSI does not offer Internet access through its free dialups scattered throughout the US, the access is restricted to its customer base by using validated network numbers. This service has been advertised through our brochure since Janaury. Aside from any economic considerations in providing an Internet wide terminal service there are two issues that are of signifcant concern to us: 1) Is it appropriate for any organization to provide this service in consideration of the security issues, and appropriate use of many people's network. 2) What are the legal/monetary liability issues for an organization who's customer did something "bad". Essentially we're concerned about being good Internet citizens here, we could price, bill, and deliver Internet access dialups throughout the US. But is that a good thing? I believe that a number of network providers may require active filtering against this type of dialup to protect themselves. Our current customers certainly ask and we provide the addresses for that purpose. Marty ------------------------ In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes: >Dial-up access is now offered as a commercial service in some cities. It's >all a part of the Internet's growing up... -s And when they start advertising so that potential clients actually *know* about it, then the Internet will really have passed adolescence. :-) I'd love to hear more about this. I hope such services don't require that you have a direct hookup to their own network in order to take advantage of the dialups (i.e., TACACS at the dialup point only authorizes you iff you are in their databases, and you only get into their databases if your site is spending big bucks for a direct connection to their network.) That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement with PSI, UUNET, MERIT, etc. Maybe we need something like cellular "roaming"... -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052312490800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 08:12:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05377; Fri, 25 May 90 08:02:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 12:49:08 GMT From: att!dptg!mtune!rkh@ucbvax.Berkeley.EDU (Robert Halloran) Organization: AT&T BL Middletown/Lincroft NJ USA Subject: Re: Re. Wollongong TCP/IP Message-Id: <582@mtune.ATT.COM> References: <9005182006.AA00073@dragon.twg.com>, <3362@auspex.auspex.com>, <539@secola.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes: >In article <3362@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>>If you want to see the best TCP/IP in its class, check out the TCP/IP >>>on UNIX System Release V 4.0 on AT&T's 6386 WGS series of machines. >>>It's Wollongong's. And we're proud of it. >> >>So AT&T threw out the Lachman-based one they supply standard with S5R4 >>and supply a Woolongong-based release instead? > >no, when you buy 5.4 you get lachman tcp. >when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. The SVr4 source package includes Lachman TCP/IP code. Binary distributions for AT&T 3B (and probably 386 - haven't seen it) have TWG binaries included. On the 6386, the Micom/Interlan package we OEM'd has been replaced with TWG. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.dptg.att.com Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "Remember, kids, if some weirdo in a blue suit offers you some DOS, JUST SAY NO!!!" ========================================================================= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052314454300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 26 May 90 19:00:30 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AB25728; Sat, 26 May 90 18:50:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 14:45:43 GMT From: mitel!sce!cognos!dy4!paul@uunet.uu.net (Paul Burry) Organization: DY-4 Systems Inc. Nepean, Ont Can. Subject: Request for protocol overhead references Message-Id: <168@dy4.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are interested in any information that may be available regarding the processing overhead associated with network protocols such as TCP/IP, TP4, etc. In particular, we are interested in the amount of processing required per unit of data transferred via these protocols. Could someone please refer me to any relevant articles? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Burry PHONE: (613)-596-9911 UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road, or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul Burry PHONE: (613)-596-9911 UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road, or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052315204800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 10:40:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00113; Wed, 23 May 90 10:29:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 15:20:48 GMT From: mcsun!hp4nl!ncsbv!peter@uunet.uu.net (Peter Jannesen) Organization: N.C.S., Rotterdam, the Netherlands Subject: PC-LAN and TCP-IP Message-Id: <397@ncsbv.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A client of use has a tokenring network running IBM's pc-network. We would like to add to this network a UNIX box running 386/ix or SCO-UNIX. The only thing we want is a telnet session to the UNIX box. So I have the following questions: 1. Is there a tokenringcard driver for 386/ix or SCO-UNIX? 2. Is there a streams devices driver in sources avaible for UNIX. (To adopt this driver to the tokenring card). 3. Is there a driver for the tokenringcard from IBM which is capable to run PC-LAN and TCP-IP on the same time. 4. which products are availble to run TELNET/TCP-IP on a PC. How much memory use those product. =============================================================================== Peter Jannesen Network Communication Systems (N.C.S), The Netherlands Phone: +31104130093 Fax: +31104146452 Address: Westbaak 96 3012 KM Rotterdam, The Netherlands =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052315350100> Received: from psi.com by NIC.DDN.MIL with TCP; Wed, 23 May 90 19:17:04 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA01426; Wed, 23 May 90 22:15:02 -0400 Message-Id: <9005240215.AA01426@psi.com> To: snorkelwacker!spdcc!dyer@think.com (Steve Dyer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-Reply-To: Your message of 24 May 90 00:15:29 +0000. <2944@ursa-major.SPDCC.COM> Date: Wed, 23 May 90 22:15:01 -0400 From: "Martin Lee Schoffstall" > On this topic, I am concerned about the balkanization of the Internet > in the interest of "security" without attention being payed to what > customers want. I think that laying the blame for the balkanization of the Internet at the feet of security is a pretty superficial analysis. Most of the balkanization is an effect of the very concept of "regional networks" which have customers tied together by a national network which effectively has no customers. Some indviduals might posit that the model is exhausted and that national/international networks that have customers directly is the future for the Internet. > Clearly a dialup facility which restricts access to > members of a particular commercial network (like PSI) is one very > proper service, and I'm glad it's offered to its customers, but it > doesn't yet address the needs of people associated with regional > networks trying to stay in touch when they're out of town. Given that it is free to its customer base (a point that seems to have been overlooked) others might perceive it as a value added that a "competitor" doesn't have. You might even sell it that way to prospective customers.... :-) > Thus, I > applaud the efforts of CERFnet and UUNET to offer authenticated, > for-fee access to Internet as a whole. I can guarantee that I'll > be interested in using their services whereas Marty's (if I understand > him correctly) just looks like an interesting service. You don't understand me correctly. Essentially we've been waiting for the time that a prescedent is set, permission is granted, or a consensus may be achievable in the Internet community. That time may be now, and the PSI blitzkreig may descend. I'll of course let you know in the least crass commercial manner that I can, if it is of interest..... Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052316382500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 09:53:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27135; Wed, 23 May 90 09:44:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 16:38:25 GMT From: snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Subject: Re: Dial up access to Internet facilities Message-Id: <2936@ursa-major.SPDCC.COM> References: <9005231128.AA19114@ncri.cise.nsf.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes: >Dial-up access is now offered as a commercial service in some cities. It's >all a part of the Internet's growing up... -s And when they start advertising so that potential clients actually *know* about it, then the Internet will really have passed adolescence. :-) I'd love to hear more about this. I hope such services don't require that you have a direct hookup to their own network in order to take advantage of the dialups (i.e., TACACS at the dialup point only authorizes you iff you are in their databases, and you only get into their databases if your site is spending big bucks for a direct connection to their network.) That is, as a NEARnet/CENTnet site, I'd hardly have a preexisting arrangement with PSI, UUNET, MERIT, etc. Maybe we need something like cellular "roaming"... -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052316480700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 10:21:38 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA28779; Wed, 23 May 90 10:11:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 16:48:07 GMT From: hercules!heap.cisco.com!byrd@apple.com (Bruce Byrd) Organization: cisco Systems, Menlo Park, CA Subject: MAC with SLIP Message-Id: <12592008417053@heap.cisco.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm trying to find software packages for the MAC that support SLIP (commercial and public domain). Can you send me an email if you know of any (besides cisco's public domain version). Thx, Bruce Byrd cisco Systems byrd@cisco.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052317403400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 11:37:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04083; Wed, 23 May 90 11:31:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 17:40:34 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: Re. Wollongong TCP/IP Message-Id: <3370@auspex.auspex.com> References: <9005182006.AA00073@dragon.twg.com>, <3362@auspex.auspex.com>, <539@secola.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >>So AT&T threw out the Lachman-based one they supply standard with S5R4 >>and supply a Woolongong-based release instead? > >no, when you buy 5.4 you get lachman tcp. >when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. Lots of people seem to have misread what I said. In the hope that nobody who hasn't yet had the opportunity to do so does so, I'll note that I said > ...the Lachman-based one they supply standard with S5R4... *explicitly acknowledging* that "when you buy 5.4 you get lachman tcp", and that what I was asking was whether AT&T, when building the S5R4 release that they supply as the OS for their 386-based machines, threw out the Lachman-based TCP/IP supplied in source form with S5R4 source, and replaced it with Woolongong's version. The answer to that question is "yes, they did". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052318255300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 12:38:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07431; Wed, 23 May 90 12:24:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 18:25:53 GMT From: cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1990May23.182553.26291@utzoo.uucp> References: <9005161338.AA07959@sayshell.umd.edu>, <435@jove.dec.com>, <23521@bellcore.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <23521@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >I think that filtering IP routers are like the Maginot Line. The latter did >exactly what it was designed to do. It's just that the Germans had plenty of >other routes for attacking the West, so they simply went around it. If one wishes a complete and accurate analogy, one should note that the original planners of the Maginot Line specified that it should cover the routes the Germans ended up using... it was cut back by the politicians to save money. -- Life is too short to spend | Henry Spencer at U of Toronto Zoology debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052318293400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 11:37:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03975; Wed, 23 May 90 11:29:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 18:29:34 GMT From: rick@uunet.uu.net (Rick Adams) Organization: UUNET Communications Services, Falls Church, VA Subject: Re: Dial up access to Internet facilities Message-Id: <90121@uunet.UU.NET> References: <9005231128.AA19114@ncri.cise.nsf.gov>, <2936@ursa-major.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil UUNET plans to offer access to any Internet site from any Compuserve Dialup in the continental US. All access will require an individual login/password for accountability and authorization to use the Internet will be verified before the account is established. Performance is "acceptable". Certainly better than the MILNET TACs, but not quite as good as a direct modem connection. We plan to charge $5 per connect hour (in increments of 1 minute). We could start tomorrow if I could figure out how to bill for it. Its not worth sending out invoices for only $5. --rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052318314800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 12:39:03 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07477; Wed, 23 May 90 12:25:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 18:31:48 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@tut.cis.ohio-state.edu (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Wither Ethernet? Message-Id: <1990May23.183148.26385@utzoo.uucp> References: <9005211233.AA15946@gateway.mitre.org> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005211233.AA15946@gateway.mitre.org> hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes: >It has been suggested by some standards gurus that in the future >all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead >(or possibly dying) protocol... Um, what do you mean by "Ethernet"? If you're referring to the hardware, all three flavors -- Ethernet 1, Ethernet 2, and 802.3 -- are pretty much cable-compatible and there is no issue here. Half the people with Ethernet networks probably don't even know exactly which flavor all their boxes are. Or care. If you're thinking of the 802.2 protocol stuff as opposed to Ethernet packet-type codes, or the OSI protocol stack as opposed to TCP/IP (neither of which is tied to Ethernet in any way), then to borrow a phrase from the past, if this is so, it's one of the few known protocols that is dying out on a steep upward curve. -- Life is too short to spend | Henry Spencer at U of Toronto Zoology debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052321044300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 15:09:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17262; Wed, 23 May 90 14:53:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 21:04:43 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!ogicse!plains!lodin@ucsd.edu (Joe Schmo) Organization: North Dakota State University, Fargo Subject: Subnetting problems Message-Id: <4861@plains.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have a question relating to subnetting. We at GM/EDS/Delco are starting to get our act together and registering all TCP/IP hosts on the company internetwork. As far as I know, GM/EDS has been given the class B Internet Address 130.171. Delco has been given the address range 130.171.8-15 from EDS. They (EDS) have decided to divide it as such for Delco: 130.171.8.0 - 130.171.11.255 subnet mask 0xfffffc00 broadcast 130.171.11.255 130.171.12.0 - 130.171.12.15 subnet mask 0xfffffff0 broadcast 130.171.12.15 130.171.12.16 - 130.171.12.31 subnet mask 0xfffffff0 broadcast 130.171.12.31 ... 130.171.12.128 - 130.171.12.159 subnet mask 0xfffffe0 broadcast 130.171.12.159 130.171.12.160 - 130.171.12.191 subnet mask 0xfffffe0 broadcast 130.171.12.151 ... 130.171.14.0 - 130.171.14.63 subnet mask 0xffffffc0 broadcast 130.171.14.63 130.171.14.64 - 130.171.14.127 subnet mask 0xffffffc0 broadcast 130.171.14.127 ... 130.171.15.0 - 130.171.14.127 subnet mask 0xffffff80 broadcast 130.171.14.127 130.171.15.128 - 130.171.14.255 subnet mask 0xffffff80 broadcast 130.171.14.255 Essentially what they have done is subdivide our subnet into unequal networks that would seem to require different netmasks. I have a gateway workstation with one LANIC connected to the backbone with address 130.171.8.204 and then I have the network 130.171.12.1-15. If I set my netmasks different, 0xfffffc00 on the gateway LANIC and 0xfffffff0 on the local LANIC, my networking software has problems getting thru the gateway. If I set them the same (0xfffffc00) then I can get thru the gateway fine, but now the the range 130.171.12-15.xx seem to be on the same physical wire. The machines involved are HP 9000/3XX w/HP-UX 7.0, Sun 386i w/SunOS 4.0.2, Sun 4 w/SunOS 4.0.3, and eventually Intergraphs. The HP's are running gated and the Suns are running routed. Customer reps with HP and Sun recommended we keep the same netmask on all machines regardless of the network, and for now that works until I want to talk to machines in the rest of the 130.171.12-15 range. Comer's book alludes to being able to have multiple subnets on the same physical wire with discrete fixed routing tables. As an experiment, we tried this (metric 0) and it didn't work. It also said something about netmask information being kept in the routing tables, but I haven't seen that in dumps from routed and gated. I could only see it in ifconfig information. From what I can determine, we may need to go to multiple virtual subnets on one network like described in "Introduction to Administration of an Internet-based Local Network". Yet this seems to imply that all subnets will be of the same size. I'm not sure of the planning or analysis that went into this method of address allocation, but it seems to be improper. I understand that will a company of our size, there will be tradeoffs in any decision involving networking adminstration. We have small local department networks and large company-wide networks, that in some instances, are all connected on the same physical wire. EDS has traditionally been an IBM house, so I'm not sure of their TCP/IP networking experience (go ahead and send flames), and I question their network administrative tactics. Please send any answers (:-), comments, references, or experiences to: Steve Lodin Advanced Instrumentation Engineering ------------- Delco |Electronics| Corp ------------- \ \ It's who we are Tel: ATT 317-451-8722 GM 8-322-8722 Domain: lodin%koiasvr01.uucp@ee.ecn.purdue.edu or swlodin@koess.gm.hac.com UUCP: ![iuvax|pur-ee]!koiasvr01!lodin GM: LODIN,SW ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052322592400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 16:40:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23267; Wed, 23 May 90 16:25:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 May 90 22:59:24 GMT From: sdcc6!ee299at@ucsd.edu Organization: University of California, San Diego Subject: Re: Dial up access to Internet facilities Message-Id: <10775@sdcc6.ucsd.edu> References: <9005231128.AA19114@ncri.cise.nsf.gov>, <2936@ursa-major.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2936@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >In article <9005231128.AA19114@ncri.cise.nsf.gov> steve@cise.nsf.gov (Stephen Wolff) writes: >>Dial-up access is now offered as a commercial service in some cities. It's >>all a part of the Internet's growing up... -s > >And when they start advertising so that potential clients actually *know* >about it, then the Internet will really have passed adolescence. :-) > >I'd love to hear more about this. I hope such services don't require that >you have a direct hookup to their own network in order to take advantage >of the dialups (i.e., TACACS at the dialup point only authorizes you iff >you are in their databases, and you only get into their databases if your >site is spending big bucks for a direct connection to their network.) > > >-- >Steve Dyer >dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer >dyer@arktouros.mit.edu, dyer@hstbme.mit.edu CERFNet recently announced a dial-up internet access service from terminal servers at UCLA , UCIrvine , Caltech , SDSC and UCOP(Oakland) and will be expanding to other sites on demand. The service also offers SLIP A direct connection from your site to CERFNet is *NOT* required . In fact we designed this service for those who do not need /cannot afford the high-end service and those who like to "roam" ( we also offer mail and netnews) You do need to prove that your use is commensurate with the "Internet Acceptable Use Policy" and you will need to authenticate yourself whenever you login. There will be a monthly fee and connect charges of $5/hr. --pushpendra pushp@cerf.net (619) 534-5067 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052400152900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 17:26:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26591; Wed, 23 May 90 17:19:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 00:15:29 GMT From: snorkelwacker!spdcc!dyer@think.com (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Subject: Re: Dial up access to Internet facilities Message-Id: <2944@ursa-major.SPDCC.COM> References: <2936@ursa-major.SPDCC.COM>, <9005232254.AA00559@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On this topic, I am concerned about the balkanization of the Internet in the interest of "security" without attention being payed to what customers want. Clearly a dialup facility which restricts access to members of a particular commercial network (like PSI) is one very proper service, and I'm glad it's offered to its customers, but it doesn't yet address the needs of people associated with regional networks trying to stay in touch when they're out of town. Thus, I applaud the efforts of CERFnet and UUNET to offer authenticated, for-fee access to Internet as a whole. I can guarantee that I'll be interested in using their services whereas Marty's (if I understand him correctly) just looks like an interesting service. Of course, there are all sorts of ways to have your cake and eat it too: I wouldn't have any problem with using a dialup service which associated an authenticated dialup account with some restriction on the target nets (or even hosts) which could be reached. Thus, an account whose password was improperly disseminated would not be such a gaping security hole. You're talking database lookups rather than static address matching, of course. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052403163800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 23 May 90 20:38:40 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07914; Wed, 23 May 90 20:25:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 03:16:38 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: UDP protocol for short messages? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Has anyone implemented a UDP protocol for sending short messages to a resource- limited host? If so, I'd like to see how you did it. I'm working on such a protocol, and I'd prefer to make new mistakes, rather than repeat any of yours. :-) -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052406120000> Received: from att-in.att.com by NIC.DDN.MIL with TCP; Thu, 24 May 90 07:13:17 PDT From: dangelo@whuts.att.com Date: Thu, 24 May 90 10:12 EDT Original-From: whuts!dangelo (Diana Messano D'Angelo +1 201 386 3163) To: tcp-ip@nic.ddn.mil Subject: remove name from list Please remove my name from the mailing list. Thank you. Diana ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052406123400> Received: from thumper.bellcore.com by NIC.DDN.MIL with TCP; Thu, 24 May 90 07:10:41 PDT Received: by thumper.bellcore.com (5.54/4.7) id AA02121; Thu, 24 May 90 10:11:44 EDT Received: by chiya.bellcore.com (4.12/4.7) id AA08804; Thu, 24 May 90 10:12:34 edt Date: Thu, 24 May 90 10:12:34 edt From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9005241412.AA08804@chiya.bellcore.com> To: rick@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities Since mail is one of the big uses of the Internet, do most people that subscribe to dial-up internet already have directly connected machines in other places at which they receive mail? Or will someone start selling permantly attached accounts in addition to dial-up, so that one can retrieve their mail after they dial-up? PT ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052408301000> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by NIC.DDN.MIL with TCP; Thu, 24 May 90 12:10:30 PDT To: tcp-ip@nic.ddn.mil Subject: re: Dial up access to Internet facilities Date: Thu, 24 May 90 15:10:10 -0400 From: Craig Partridge I've always felt that the best solution to the dial-up access problem was to make it easy for people to hook up their PC to your local Ethernet, get a temporary IP address (via some address assignment protocol) and voila, they are connected. One could do similar things with a 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, you're off]. In other words, the key problem is making it easy for someone with a PC to get a local IP address and do something. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052409453200> Received: from GUNTER-ADAM.AF.MIL by NIC.DDN.MIL with TCP; Thu, 24 May 90 12:44:06 PDT Date: Thu 24 May 90 14:45:32-CDT From: Matt Jonson Subject: Netwatch ??? To: tcp-ip@nic.ddn.mil Org: AF DDN PMO Message-ID: <12592302861.16.AFDDN.JONSON@GUNTER-ADAM.AF.MIL> I heard that there was an ethernet monitor package called netwatch, and that the latest version was available for anonymous ftp from either husc6.harvard.edu or lancaster.andrew.cmu.edu. Unfortunately, I could not find it in either place. Am I blind? Is it called something other than netwatch? I got my original info off this mailing list, so please everyone bear with this repeat question. Thanks for any help. -Matt ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052412515400> Received: from BBN.COM by NIC.DDN.MIL with TCP; Thu, 24 May 90 14:02:03 PDT From: Mary Byrne Subject: remove me please To: tcp-ip@nic.ddn.mil Cc: mbyrne@BBN.COM Date: Thu, 24 May 90 16:51:54 EDT Mail-System-Version: Kindly remove me from the list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052413053600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 06:23:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04794; Thu, 24 May 90 06:09:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 13:05:36 GMT From: sdd.hp.com!uakari.primate.wisc.edu!ark1!skister!tdrake@ucsd.edu (Tim Drake - E41) Organization: Naval Surface Warfare Center, Dahlgren VA Subject: TCP/IP for ROLM 1666, in Fortran ?? Message-Id: <1990May24.130536.21740@relay.nswc.navy.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Keywords: I am a member of a team seeking to find/make a TCP/IP implemen- tation for a ROLM 1666 (mainly the FTP portion). The only languages available are assembly and FORTRAN. We have a TCP/IP implementation for a General Data MV20000 which has a similar OS and the same controller board as the ROLM. Unfortunately, this implementation is written in C. We will consider any alternative that will aid in the development/reuse of a TCP/IP package for a ROLM 1666. 1) Does a TCP/IP (at least the FTP portion) already exist for the ROLM 1666? 2) Is there a TCP/IP implementation already in FORTRAN (any flavor) for any computer and OS? 3) Are there any C to FORTRAN translators available? 4) Does anybody have a C compiler front end that is suitable for a plug-in code generator? 5) Is there a generic C compiler (or C compiler writing system) that accepts some sort of target computer description? 6) Is there a near context-free grammar description available for C that is suitable for YACC? Please respond to any of these questions if you can. Thanks! John J. Zaloudek Naval Surface Warfare Center Phone: (703) 663-8547 Code N44 (DSN) 249-8547 Dahlgren, VA 22448 MILNET: jzaloud@relay.nswc.navy.mil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005241700.AA18861@ucbvax.Berkeley.EDU] <1990052414120000> From: dangelo@whuts.att.com Newsgroups: comp.protocols.tcp-ip Subject: remove name from list Message-ID: <9005241700.AA18861@ucbvax.Berkeley.EDU> Date: 24 May 90 14:12:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Posted: Thu May 24 15:12:00 1990 Please remove my name from the mailing list. Thank you. Diana ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052414202000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 21:24:16 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02365; Thu, 24 May 90 21:11:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 14:20:20 GMT From: matrix!venkat@uunet.uu.net (D Venkatrangan) Organization: Matrix Computer Systems, Nashua, NH Subject: TCP Urgent Mode. Message-Id: <151@matrix.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for ways to determine where exactly in the sequence space at the receive side, Urgent Data begins. The RFC793 on Transmission Contol Protocol does not appear to be very clear on this. TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly. The above paragraph describes the general philosophy. Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set. Does this mean than Urgent Data starts at the beginning of this segment and extends up to current segment's sequence number + urgent data pointer? The objective of the TCP urgent mechanism is to allow the sending user to stimulate the receiving user to accept some urgent data and to permit the receiving TCP to indicate to the receiving user when all the currently known urgent data has been received by the user. This mechanism permits a point in the data stream to be designated as the end of urgent information. Whenever this point is in advance of the receive sequence number (RCV.NXT) at the receiving TCP, that TCP must tell the user to go into "urgent mode"; when the receive sequence number catches up to the urgent pointer, the TCP must tell user to go into "normal mode". If the urgent pointer is updated while the user is in "urgent mode", the update will be invisible to the user. This again describes when "urgent mode" starts, but not where urgent data starts. Do users of TCP, such as Telnet, agree on how many bytes of urgent data exist and thereby know the start of urgent data? Is there an update to RFC793 since Sept. 1981 that describes changes if any to the TCP urgent mechanism? If one were to implement the TLI API on top of TCP and were to provide the t_rcv(fd, buf, nbytes, flagsp) call, how would they be able to provide T_EXPEDITED data? TLI appears to treat normal and expedited data as two independent streams. Thanks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052415420700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 09:53:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17829; Thu, 24 May 90 09:43:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 15:42:07 GMT From: fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net (Kevin Paul Herbert) Organization: cisco Systems Subject: Re: TCP/IP for ROLM 1666, in Fortran ?? Message-Id: <18329@hercules.csl.sri.com> References: <1990May24.130536.21740@relay.nswc.navy.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I suggest checking out use of gcc from project GNU - it is a portable C compiler designed to be easy to retarget to different host architectures. Check out the gnu.* newsgroups for more information. Kevin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052415572000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 09:08:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14818; Thu, 24 May 90 08:58:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 15:57:20 GMT From: bu.edu!bu-it!kwe@uunet.uu.net (Kent England) Organization: Boston University Subject: Re: Dial up [blitzkreig] Message-Id: <57748@bu.edu.bu.edu> References: <9005240215.AA01426@psi.com>, <2944@ursa-major.SPDCC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005240215.AA01426@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes: > ... That time may > be now, and the PSI blitzkreig may descend. > Man the bunkers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052417181100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 10:23:20 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA20172; Thu, 24 May 90 10:18:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 17:18:11 GMT From: rick@uunet.uu.net (Rick Adams) Organization: UUNET Communications Services, Falls Church, VA Subject: Re: Dial up access to Internet facilities Message-Id: <90239@uunet.UU.NET> References: <9005241412.AA08804@chiya.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil There already exist several places that will let you have an account that can send and receive Internet mail. They are not on the Internet and have no need to be. (Portal and the World are two examples). The major point of having dialup internet access is for people who alerady have accounts on Internet machines and need to "call home". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052418014200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 11:28:44 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24473; Thu, 24 May 90 11:21:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 18:01:42 GMT From: intercon!news@uunet.uu.net (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Dial up access to Internet facilities Message-Id: <265C2187.4671@intercon.com> References: <2944@ursa-major.SPDCC.COM>, <9005240215.AA01426@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005240215.AA01426@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes: > Some indviduals might posit that the model is exhausted and that > national/international networks that have customers directly is the future > for the Internet. This, in fact, seems to be how many people (myself included) view things even now. In fact, several people at PSI are probably all too aware that I'm interested in being a customer of the Internet as a whole, and am not particularly interested in what PSI can do for me except in pursuit of that goal :-). Anyway... I know that I tend to think of "the Internet" along the same lines that I think of the interstate highway system. I know that each piece is maintained by its oown tax base and personnel, but each piece is also part an overall system. When I drive to NYC from DC, I think of it as "getting on I-95 and heading north until I get to the George Washington Bridge", not as getting on a series of "X Memorial Highways". Likewise, when I was at OSU and FTP'd something from Stanford, I thought of it as "using the Internet", not "using ORnet and PSCnet and MERIT and BARRnet...". And, just as I avoid taking toll roads unless I have to, I'd prefer to have the underlying partitioning of the Internet to be as invisible as possible. Where this analogy breaks down, of course, is that the interstates are a public resource (despite their "official" designation as the Defense Highway System), and the Internet is not. On the other hand, the interstate system shows that public access and subsidization is not necessarily a bad thing either, even for a resource developed by the government. -- Amanda Walker, InterCon Systems Corporation -- "Go not to the elves for counsel, for they will say both no and yes." --J.R.R. Tolkien, The Lord of the Rings ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052418343600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 12:08:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA26529; Thu, 24 May 90 11:55:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 18:34:36 GMT From: sdcc6!cerf.net@ucsd.edu (Pushpendra Mohta) Organization: University of California, San Diego Subject: Re: Dial up access to Internet facilities Message-Id: <10810@sdcc6.ucsd.edu> References: <9005241412.AA08804@chiya.bellcore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005241412.AA08804@chiya.bellcore.com> tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya) writes: >Since mail is one of the big uses of the Internet, do most people >that subscribe to dial-up internet already have directly connected >machines in other places at which they receive mail? Or will >someone start selling permantly attached accounts in addition to >dial-up, so that one can retrieve their mail after they dial-up? > >PT As I said earlier , if you can demonstrate that your use of the Internet is bonafide , CERFNet will offer you a "permanently attached account" on one of our machines . Other than helping the "roamers" our intention is to provide a low cost service to people with no current Internet access. In conjunction with our SLIP service, we are working on providing mail services through POP and alikes--- bringing the Internet to your portable PC.:-) --pushpendra CERFNet (619) 534-5056 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005242339.AA15030@ucbvax.Berkeley.EDU] <1990052419101000> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: Dial up access to Internet facilities Message-ID: <9005242339.AA15030@ucbvax.Berkeley.EDU> Date: 24 May 90 19:10:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Thu May 24 20:10:10 1990 I've always felt that the best solution to the dial-up access problem was to make it easy for people to hook up their PC to your local Ethernet, get a temporary IP address (via some address assignment protocol) and voila, they are connected. One could do similar things with a 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, you're off]. In other words, the key problem is making it easy for someone with a PC to get a local IP address and do something. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052419105800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 12:27:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27622; Thu, 24 May 90 12:12:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 19:10:58 GMT From: paperboy!meissner@think.com (Michael Meissner) Organization: Open Software Foundation Subject: Re: TCP/IP for ROLM 1666, in Fortran ?? Message-Id: References: <1990May24.130536.21740@relay.nswc.navy.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <18329@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul Herbert) writes: | I suggest checking out use of gcc from project GNU - it is a portable C | compiler designed to be easy to retarget to different host | architectures. Check out the gnu.* newsgroups for more information. Reality check time. I believe that the ROLM 1666 computer is instruction compatible with the DG MV/Eclipse computers. I wrote the front end for the DG C compiler on the MV/Eclipse computers, and then switched over to working on GNU C for the 88k (and now MIPS + ns32k). IMHO, it would be a hericulean effort to port GCC to the MV architecture. The biggest problem is that the MV has three types of pointers: * bit pointers consisting of a word pointer in one register and a bit offset in another, or alternatively, the word pointer shifted left 4 bits + the bit offset in one register, which restricts the range pointed to; * word pointers (words are 16 bits, but word pointers can also load 32 bits in one operation), which have three parts, an indirect bit (which isn't always used), a segment field (always 7 in normal user code), and the word offset. * byte pointers, which is the word pointer shifted left one bit position (loosing the indirect bit), and the byte number within the 16-bit word in the least significant bit. GCC firmly believes that there is only type of pointer (in fact, it took somebody else a good month or two to just get the 88k compiler running as a cross compiler on the MV, to straighten out the pointer kinks in the compiler itself). The internal language has no means of expressing the different pointer types, so you would have to always resprent things as byte pointers, and continually do word <-> byte pointer conversions. The second biggest problem is the lack of registers. The machine only has 4 integer registers and 4 floating point registers (the stack registers are present in the machine, but you have to use explicit instructions to move them to the integer registers to use them as indexes, except directly after a SAVE). I suspect that the GCC algorithms will break down if confronted with so few registers. The registers are also not completely regular either -- memory references involving word pointers can only be done from two registers, etc. Finally, writing ANY new machine description for GCC is a #!$% of a lot of work. It was a year of my time before I felt the 88k port was reliable, and I was starting from a 3/4 finished port done by a person who had done 2 other GCC ports previously. It might be easier, to poke around, and see if the object formats are compatible and if so, cross develop on the MV. Or write a translator from the MV object format to the ROLM, if different. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052419363500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 24 May 90 21:40:18 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03583; Thu, 24 May 90 21:30:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 90 19:36:35 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@tut.cis.ohio-state.edu (Tim Evans) Organization: Social Security Admin., Baltimore/Washington Subject: TCP/IP for the MacIntosh? Message-Id: <413@oss670.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil My boss has just asked about putting Mac's on our TCP/IP Ethernet. Since I'm not a regular reader of the Mac groups, can someone give me an E-mail yell and let me know what's available and what's required to implement it? Thanks. PLEASE: Use the E-mail address BELOW, not the one above. -- cc:Mail Tim K. Evans at ~OSS UUCP ...!{rutgers|ames|uunet}!mimsy!woodb!tkevans INTERNET tkevans%woodb@mimsy.umd.edu PHONE: (301) 965-3286 US MAIL 6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD 21235 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005250518.AA06617@ucbvax.Berkeley.EDU] <1990052420515400> From: mbyrne@BBN.COM (Mary Byrne) Newsgroups: comp.protocols.tcp-ip Subject: remove me please Message-ID: <9005250518.AA06617@ucbvax.Berkeley.EDU> Date: 24 May 90 20:51:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 Posted: Thu May 24 21:51:54 1990 Kindly remove me from the list. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052500313800> Received: from Xerox.COM by NIC.DDN.MIL with TCP; Fri, 25 May 90 07:31:30 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 25 MAY 90 07:32:00 PDT Sender: "Jeff_Lloyd.WGC1RX"@Xerox.COM Date: 25 May 90 07:31:38 PDT (Friday) Subject: Re: PC-LAN and TCP-IP From: "Jeff_Lloyd.WGC1RX"@Xerox.COM To: mcsun!hp4nl!ncsbv!peter@uunet.uu.NET cc: tcp-ip@nic.ddn.MIL In-Reply-to: mcsun!hp4nl!ncsbv!peter%uunet.uu:NET:Xerox's message of 25-May-90 (Friday) 13:48:23 +1 Message-ID: <900525-073200-6840@Xerox> Peter, SCOs Open Desktop product (SCO UNIX 3.2 etc) is shipped with Lachmans' TCP/IP support. This product supports a nice range of standard (ish) ethernet cards PLUS Token Ring Boards. The system (ODT-NET) supports TCP/IP, Streams and IBM Lan Manager (NetBIOS) protocols. Therefore you can have all these from one ethernet or Token Ring board !!. Item 3. See Above. Item 4 has many options, those that come to mind are, Sun's PC-NFS - Telnet, FTP et al, Ethernet only, NFS (Of Course) would work nice with Open Desktop (Is as NFS too !) Uses Loadsa RAM. FTP TCP/IP Package Excelan - Telnet, FTP etc. LAN-Workplace Ethernet only (I Think) for DOS NetBIOS Support IBM LAN Manager support can be used to mount PC-Net disks from ODT. Most of the TCP/IP protocol support is down loaded to their board, (it has a 80186) this frees up loadsa RAM. Many others I can't think of...... Hope this helps -jeff BTW: I Don't work for sco :-) I just develop with ODT. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052501040100> Received: from ocdis01.af.mil by NIC.DDN.MIL with TCP; Fri, 25 May 90 07:23:53 PDT Return-Path: Received: by ocdis01.af.mil id AA08810; Fri, 25 May 90 09:24:02 -0500 Message-Id: <9005251424.AA08810@ocdis01.af.mil> Date: Fri May 25 09:24:01 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) Subject: dial-up access to the Internet To: tcp-ip@nic.ddn.mil Status: N It seems to me that the real question of dial-up access for the Internet stems from folks who travel and need to "phone home". The most obvious solution is to have a dial-up modem on their "home" system and stay off the Internet altogether. That way, their home system does all the user verification and auditing. But that's not how the real world works - right? I get a the willies about letting anyone dial up and get on the Internet without authentication and audit trail. That would seem to invite abuse. The open-door "guest" account is an invitation to disaster (or hassle, if the FBI asks why your system allowed the bad guy access to the Internet). Unfortunately, all sites seem to have their share of traveling dignitaries who need to check their email in some other corner of the world. To handle these, we set up a "guest" account which is password protected. When a user logs into this account, they see a list of systems that they can connect to. When a travelling dignitary comes on base, our customer support folks offer the courtesy of using the guest account, and provide him with the current password (they also make sure the right "home system" is currently on the menu). After he leaves, they change the password on the account. No logins to this guest account are allowed over modem or >from the Internet. The user must be "on base" to use the account. Not only are we controlling guest access, but visitors are impressed by our "thoughtfulness" in providing them with this "phone home" capability, without them having to ask for it. Bob Johnson Tinker AFB ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052501453400> Received: from rice.edu by NIC.DDN.MIL with TCP; Fri, 25 May 90 08:03:10 PDT Received: from iapetus.rice.edu by rice.edu (AA26320); Fri, 25 May 90 10:04:03 CDT Received: by iapetus.rice.edu (AA27779); Fri, 25 May 90 10:05:34 -0500 Date: Fri, 25 May 90 10:05:34 -0500 From: Guy Almes Message-Id: <9005251505.AA27779@iapetus.rice.edu> To: robjohn@ocdis01.af.mil, tcp-ip@nic.ddn.mil Subject: Re: dial-up access to the Internet robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) writes:<< But that's not how the real world works - right? I get a the willies about letting anyone dial up and get on the Internet without authentication and audit trail. That would seem to invite abuse. The open-door "guest" account is an invitation to disaster (or hassle, if the FBI asks why your system allowed the bad guy access to the Internet). Unfortunately, all sites seem to have their share of traveling dignitaries who need to check their email in some other corner of the world. >> Bob makes a good point which I'd like to strengthen. The Federation of American Research Networks (FARnet) has gone on record as urging its mid-level networks and the campuses they serve to dis-allow any unauthenticated access to the Internet. Specifically, terminal servers that require no authentication and then allow the caller full access to the Internet must be reconfigured to either require authentication or to provide access only to a set of hosts on campus that *do* require authentication. I also like his later example of how to be both courteous and careful:<< To handle these, we set up a "guest" account which is password protected. When a user logs into this account, they see a list of systems that they can connect to. When a travelling dignitary comes on base, our customer support folks offer the courtesy of using the guest account, and provide him with the current password (they also make sure the right "home system" is currently on the menu). After he leaves, they change the password on the account. No logins to this guest account are allowed over modem or >from the Internet. The user must be "on base" to use the account. Not only are we controlling guest access, but visitors are impressed by our "thoughtfulness" in providing them with this "phone home" capability, without them having to ask for it. Bob Johnson Tinker AFB >> This is one example, among many possibilities, of how to be responsible. -- Guy Almes ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052503242500> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Fri, 25 May 90 04:24:26 PDT Received: by gateway.mitre.org (5.54/SMI-2.2) id AA16577; Fri, 25 May 90 07:25:37 EDT Full-Name: Richard Verjinski Return-Path: Received: by mercury.mitre.org (5.54/SMI-2.2) id AA00811; Fri, 25 May 90 07:24:25 EDT Date: Fri, 25 May 90 07:24:25 EDT From: rich@gateway.mitre.org Message-Id: <9005251124.AA00811@mercury.mitre.org> To: tcp-ip@nic.ddn.mil Subject: re: Dial up access to Internet facilities Date: Thu, 24 May 90 15:10:10 -0400 From: Craig Partridge Status: R Craig Partridge writes... > I've always felt that the best solution to the dial-up access problem > was to make it easy for people to hook up their PC to your local Ethernet, > get a temporary IP address (via some address assignment protocol) and > voila, they are connected. One could do similar things with a > 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, > you're off]. > In other words, the key problem is making it easy for someone with a > PC to get a local IP address and do something. > Craig While at Unisys, myself and others developed and implemented a system that did exactly what Craig describes... A PC user could dial into a gateway that would give the PC a temporary IP address. A protocol was also developed that would allow the PC user to update a modified Domain Name Server with its temporary IP address so that other hosts could initiate connections to the PC. An FTP user protocol, Telnet user protocol, and SMTP server protocol implementations were written to run on the PC. The usefulness is that a user with a portable PC can dial into a system and his email would automatically be sent to the PC at the temporary location. More information on this system can be found in the conference record of MILCOM '89, under "PHASE, A Portable Host Access System Environment". Rich Verjinski rich@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052503354200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 25 May 90 10:33:34 PDT Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 25 May 90 10:34:40 -0700 Date: Fri, 25 May 90 10:35:42 PDT From: braden@venera.isi.edu Posted-Date: Fri, 25 May 90 10:35:42 PDT Message-Id: <9005251735.AA00858@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Fri, 25 May 90 10:35:42 PDT To: matrix!venkat@uunet.uu.net, tcp-ip@nic.ddn.mil Subject: Re: TCP Urgent Mode. Cc: braden@venera.isi.edu From tcp-ip-RELAY@NIC.DDN.MIL Fri May 25 01:59:41 1990 Date: 24 May 90 14:20:20 GMT From: matrix!venkat@uunet.uu.net (D Venkatrangan) Organization: Matrix Computer Systems, Nashua, NH Subject: TCP Urgent Mode. Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for ways to determine where exactly in the sequence space at the receive side, Urgent Data begins. The RFC793 on Transmission Contol Protocol does not appear to be very clear on this. TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly. The above paragraph describes the general philosophy. Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set. Does this mean than Urgent Data starts at the beginning of this segment and extends up to current segment's sequence number + urgent data pointer? Yes. Up to, but not including. See RFC-1122 p. 84 for more info. This again describes when "urgent mode" starts, but not where urgent data starts. Do users of TCP, such as Telnet, agree on how many bytes of urgent data exist and thereby know the start of urgent data? Urgent data starts as soon as an Urgent Ptr appears. Is there an update to RFC793 since Sept. 1981 that describes changes if any to the TCP urgent mechanism? If one were to implement the TLI API on top of TCP and were to provide the t_rcv(fd, buf, nbytes, flagsp) call, how would they be able to provide T_EXPEDITED data? TLI appears to treat normal and expedited data as two independent streams. Thanks. It's not clear you can map TCP urgent into a user interface that has two independent streams. The essential piece of information that the receiving application has to be able to get is: How many bytes of urgent data remain to be read? As long as the answer is non-zero, the application has to be in "urgent mode"; when the result reaches zero, normal mode resumes. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052505270000> Received: from mitvma.mit.edu by NIC.DDN.MIL with TCP; Fri, 25 May 90 07:30:17 PDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 7588; Fri, 25 May 90 10:30:40 EDT Received: from TUFTS.BITNET (MLEVIN) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 9809; Fri, 25 May 90 10:30:40 EDT Date: Fri, 25 May 90 10:27 EST From: Subject: multinet problem To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, MLEVIN We (Tufts U) have an Encore running Umax 4.2 on a network with a VAX running VMS. The vax has the multinet package, and I was trying the ttcp.c program supplied in [multinet.examples]. It seems that the only way it works with the sender on VMS and the reciever on the UMAX system is with the -u option (using datagrams, instead of SOCK_STREAM). Why? Is there any way to get it to use the stream protocol? I note that it works fine without the -u when the vax program recieves, and the Umax sends. It also works fine when both modules are run on VMS machines. Any ideas? Mike Levin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052506295300> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Fri, 25 May 90 07:28:47 PDT Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA19854; Fri, 25 May 90 10:29:53 EDT Date: Fri, 25 May 90 10:29:53 EDT From: rich@gateway.mitre.org (Richard Verjinski) Full-Name: Richard Verjinski Message-Id: <9005251429.AA19854@gateway.mitre.org> To: tcp-ip@nic.ddn.mil Craig Partridge writes... > I've always felt that the best solution to the dial-up access problem > was to make it easy for people to hook up their PC to your local Ethernet, > get a temporary IP address (via some address assignment protocol) and > voila, they are connected. One could do similar things with a > 900 voice line [dial 1-900-ARPANET, negotiate for a temporary IP address, > you're off]. > In other words, the key problem is making it easy for someone with a > PC to get a local IP address and do something. > Craig While at Unisys, myself and others developed and implemented a system that did exactly what Craig describes... **** I feel it necessary to publicly acknowledge the persons described as "others" in the above statement. Those people are: John Swanson, Jose Rodrigues, Jim O'Conner, and Ed Yancy. I apologize for not mentioning each person explicitly. Rich Verjinski ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052508323200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 02:24:06 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19487; Fri, 25 May 90 02:16:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 08:32:32 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <23617@bellcore.bellcore.com> References: <435@jove.dec.com>, <9005231723.AA20278@hp-ses.sde.hp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005231723.AA20278@hp-ses.sde.hp.com> wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: >HP does exactly the same thing. I think of it as similar to >international borders.[...] That's not a bad analogy, because I absolutely detest having to deal with customs stations. And I certainly don't depend on US customs to protect my house (or computer) from being burglarized. My personal favorite analogy is the Berlin Wall. Shortly after the wall was opened some East German official was quoted by the AP as saying that the wall as a whole would stay up because it was "necessary to protect East Germans against AIDS", among other things. Unfortunately, this kind of thinking is not unheard of in the computer security business. Once again, I argue that there is no substitute for each individual taking the responsibility for protecting his own local domain. Security mechanisms are always most effectively implemented as close as possible to whatever is being protected. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052508385400> Received: from hp-sde.sde.hp.com by NIC.DDN.MIL with TCP; Fri, 25 May 90 15:37:58 PDT Received: from orac.sde.hp.com by hp-sde.sde.hp.com with SMTP (16.2A/15.5+IOS 3.13) id AA02015; Fri, 25 May 90 15:15:27 -0700 Received: by hpsdel.sde.hp.com (15.7/SES42.42) id AA06892; Fri, 25 May 90 15:38:54 pdt Date: Fri, 25 May 90 15:38:54 pdt From: Walter Underwood Message-Id: <9005252238.AA06892@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil Subject: Re: Wither Ethernet? Newsgroups: comp.protocols.tcp-ip In-Reply-To: article <13019@ulysses.att.com> of Fri, 25 May 1990 20:53:09 GMT If find it really amusing that the vendor independent standard, IEEE 802, is mostly used for proprietary protocols (HP, IBM, and Apple), while the proprietary standard, Ethernet (remember DEC, Intel, and Xerox?) carries all the multi-vendor protocols. Just goes to show that you can't judge a standard by its cover. wunder PS: Nearly all HP equipment can talk Ethernet and ARP these days. Only one OS, MPE/XL, is still 802-only, and Ethernet is scheduled for release on that, too. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052508515400> Received: from sparta.com by NIC.DDN.MIL with TCP; Fri, 25 May 90 10:13:23 PDT Received: from Fourier.sparta.com by sparta.com (4.0/cfm-mcl-MX-1.2(Babbage)) id AA10106; Fri, 25 May 90 12:54:46 EDT Received: by Fourier.sparta.com (4.0/cfm-mcl-sub-1.1 (generic subsidiary)) id AA00482; Fri, 25 May 90 12:51:54 EDT Date: Fri, 25 May 90 12:51:54 EDT From: stine@sparta.com (Robert Havens Stine) Message-Id: <9005251651.AA00482@Fourier.sparta.com> To: AFDDN.JONSON@GUNTER-ADAM.AF.MIL, tcp-ip@nic.ddn.mil Subject: Re: Netwatch ??? According to RFC 1147, netwatch is: Available as a utility program in the pcip distribution from host husc6.harvard.edu, in directory pub/pcip. Available in a standalone package via anonymous FTP from windom.ucar.edu, in file pc/network/netwatch.arc; a binary "dearc" program is also available from windom.ucar.edu. Cheers, Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052510485400> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by NIC.DDN.MIL with TCP; Fri, 25 May 90 14:28:33 PDT To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '90 Information Date: Fri, 25 May 90 17:28:54 -0400 From: Craig Partridge Hi folks: Postscript copies of the SIGCOMM '90 Program and Registration form can FTPed at the following location: nnsc.nsf.net:CCR/sigcomm90-prog.ps nnsc.nsf.net:CCR/sigcomm90-reg.ps For those of you who don't have FTP access or prefer plain text, please be patient -- plain text copies of the registration materials will be e-mailed out sometime next week. Craig PS: Please note, the SIGCOMM '90 phone number and e-mail address may work until June 1st. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052511222200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 07:56:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03817; Fri, 25 May 90 07:44:09 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 11:22:22 GMT From: psuvm!pmw1@cunyvm.cuny.edu (Peter Weiss) Organization: Penn State University Subject: Anonymous FTP case sensitivity Message-Id: <90145.072222PMW1@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Being an Anonymous FTP neophite, I discovered at least one host that was case sensitive to the userid _anonymous_. Is this standard practice? /Pete ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052512485400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 08:01:36 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04408; Fri, 25 May 90 07:50:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 12:48:54 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@ucsd.edu (Roy Smith) Organization: Public Health Research Institute, New York City Subject: Re: (none) Message-Id: <1990May25.124854.12334@phri.nyu.edu> References: <9005251124.AA00811@mercury.mitre.org> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In <9005251124.AA00811@mercury.mitre.org> rich@GATEWAY.MITRE.ORG writes: > A PC user could dial into a gateway that would give the PC a temporary IP > address. A protocol was also developed that would allow the PC user to > update a modified Domain Name Server with its temporary IP address so > that other hosts could initiate connections to the PC. One could set up a Shiva NetModem in dial-in-network-access mode on an AppleTalk net behind a FastPath running KIP and then anybody with a Mac could do exactly that. KIP hands out IP addresses from a pool on a dynamic basis and all you need at the remote end is a Mac, any of a number of commercial or free IP packages, and a regular 1200/2400/9600 bps modem. The only thing missing is the automatic updating of DNS, but if your intent is to just let the roming user get his/her mail, all you need is an account on a POP server and DNS doesn't have to know anything. -- 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!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005251743.AA16378@ucbvax.Berkeley.EDU] <1990052515270000> From: MLEVIN@TUFTS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: multinet problem Message-ID: <9005251743.AA16378@ucbvax.Berkeley.EDU> Date: 25 May 90 15:27:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Posted: Fri May 25 16:27:00 1990 We (Tufts U) have an Encore running Umax 4.2 on a network with a VAX running VMS. The vax has the multinet package, and I was trying the ttcp.c program supplied in [multinet.examples]. It seems that the only way it works with the sender on VMS and the reciever on the UMAX system is with the -u option (using datagrams, instead of SOCK_STREAM). Why? Is there any way to get it to use the stream protocol? I note that it works fine without the -u when the vax program recieves, and the Umax sends. It also works fine when both modules are run on VMS machines. Any ideas? Mike Levin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052515584000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 09:09:47 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09332; Fri, 25 May 90 09:00:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 15:58:40 GMT From: silver!hughes@iuvax.cs.indiana.edu (larry hughes) Organization: Indiana University, Bloomington IN. Subject: tn3270 daemon? Message-Id: <45793@iuvax.cs.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of a tn3270 daemon, somewhat of a hybrid between telnetd and (reverse) tn3270? I'm fairly certain there's no such animal, but if there is we'd have a good use for it. Please respond via email...thanks in advance. //=========================================================================\\ || 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... || \\==========================================================================// ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052516352800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 09:58:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA12462; Fri, 25 May 90 09:46:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 16:35:28 GMT From: ameristar!rick@sbcs.sunysb.edu (Rick Spanbauer) Organization: Ameristar Technology, Inc Subject: Re: Dial up access to Internet facilities Message-Id: <1990May25.163528.14300@ameristar> References: <2944@ursa-major.SPDCC.COM>, <9005240215.AA01426@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes: >> Thus, I >> applaud the efforts of CERFnet and UUNET to offer authenticated, >> for-fee access to Internet as a whole. I can guarantee that I'll >> be interested in using their services whereas Marty's (if I understand >> him correctly) just looks like an interesting service. > >You don't understand me correctly. Essentially we've been waiting >for the time that a prescedent is set, permission is granted, or >a consensus may be achievable in the Internet community. That time may >be now, and the PSI blitzkreig may descend. The plight of many small technical businesses is that we just cannot justify spending $30K+ for access into the Internet for the occasional FTP/smtp transfer. Were access fees brought inline with the level of service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI and other regionals would see their business pick up substantially. Note that it isn't small business alone that has a problem with the high connection costs to the Internet. Ameristar sells IP/TCP network products and every once in a while I ask some of our larger customers ($20M & up) why they are not on the Internet. The answer is usually that the perceived value of the connection is not in line with the yearly access fee. In such cases, a low cost dialup SLIP service would go a long way in giving people a chance to experiment with Internet access to evaluate its usefullness to their organization. Dialup SLIP is also a safe way for the regionals to toy with their price/volume curve without having to add infastructure (ie additional or higher capacity links) at the outset of the experiment. One other suggestion I have is that the regionals ought to survey potential customers about the sort of connectivity and services they would purchase as a function of cost. Good starting sample data sets might be the lists of technical companies that local business organizations or government maintains, or even UUCP maps. >I'll of course let you know in the least crass commercial manner that >I can, if it is of interest..... Please do make an announcement of any new services PSI introduces. I for one would like to hear what PSI is doing to moderate access fees without having to ping your sales organization every few months. >Marty Rick Spanbauer Ameristar Technology Usual disclaimers: my opinions are my own, etc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052518055100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 11:42:29 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19952; Fri, 25 May 90 11:37:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 18:05:51 GMT From: zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1!hathawa@tut.cis.ohio-state.edu (Barry Hathaway) Organization: General Electric Corporate Research & Development Subject: Re: tn3270 daemon? Message-Id: <90145.140551HATHAWA@gecrdvm1.crd.ge.com> References: <45793@iuvax.cs.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry hughes) says: > >Does anyone know of a tn3270 daemon, somewhat of a hybrid between >telnetd and (reverse) tn3270? I'm fairly certain there's no such >animal, but if there is we'd have a good use for it. > Many TCP/IP packages for IBM mainframes offer terminal emulation on the host side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus) KNET package has this as an option. Simware offers SIM/TCPIP an add-on to IBM's TCP/IP package which does terminal emulation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052518250300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 12:26:05 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA23089; Fri, 25 May 90 12:24:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 18:25:03 GMT From: auspex!guy@uunet.uu.net (Guy Harris) Organization: Auspex Systems, Santa Clara Subject: Re: TCP Urgent Mode. Message-Id: <3386@auspex.auspex.com> References: <151@matrix.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >If one were to implement the TLI API on top of TCP and were to provide the > > t_rcv(fd, buf, nbytes, flagsp) > >call, how would they be able to provide T_EXPEDITED data? TCP doesn't really have expedited data in the same way that, say, TP4 does; it has an urgent pointer. >TLI appears to treat normal and expedited data as two independent streams. Yup. S5R4's streams code implements the notion of a "marked" message for precisely that reason; that's how it handles the urgent pointer. It may also support the notion that the last byte of urgent data is treated as expedited data, as per, say, 4.2BSD, and 4.3BSD when SO_OOBINLINE isn't set. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052519332200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 18:25:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA15650; Fri, 25 May 90 18:16:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 19:33:22 GMT From: usc!samsung!dali!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!aero!aerospace.aero.org!obrien@ucsd.edu (Michael O'Brien) Organization: The Aerospace Corporation Subject: IP/TCP/UDP benchmarks? Message-Id: <74052@aerospace.AERO.ORG> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Some folks around here have to benchmark a number of different boxes, and they've asked me to help with the part that benchmarks TCP/IP and UDP performance. Before I go off developing wheels, I'd like to know of any prior art. I already know about "ttcp.c" on brl.mil. Is there any other IP/TCP/UDP benchmarking software out there? As always, please respond by email and I'll summarize if there's interest. -- Mike O'Brien obrien@aerospace.aero.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13019@ulysses.att.com] <1990052520530900> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Wither Ethernet? Message-ID: <13019@ulysses.att.com> Date: 25 May 90 20:53:09 GMT References: <9005211233.AA15946@gateway.mitre.org> Sender: netnews@ulysses.att.com Lines: 35 Posted: Fri May 25 21:53:09 1990 In article <9005211233.AA15946@gateway.mitre.org>, hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes: > It has been suggested by some standards gurus that in the future > all LANs will be "standardized" to ISO/IEEE802 and that ethernet is a dead > (or possibly dying) protocol. I've never been a worshipper of ``standards'' that try to impose rather than describe. 802.3 would seem to me to meet that criterion, I'm afraid. At least in the TCP/IP world, I don't see that much movement to 802.3 (and away from Ethernet) simply because there's no compelling reason to. The current technology is here, it works, and it's compatible with (almost) everyone else. I'm sure folks will correct me if I'm wrong, but I thought that HP was the only major vendor to try to use 802.3 encapsulation for IP over Ethernet, and that a few others (i.e., Cisco) would accomdate them, mostly for compatibility. Furthermore, as a result, it was hard to talk to some HP machines. The 802.3 format -- and in particular the 802.2 goo you're supposed to use -- makes sense if you're trying to do routing at that layer. In ``our'' world, there's a better, more flexible way to do routing, and that's at the IP layer. So why switch? The situation is different for other media. Token ring is inhabited by bluish PCs, and FDDI was decreed from the outset to use 802.2. For those, a simpler (or at least different) encapsulation has never had a chance to take hold. Thus, 802.2 will rule, even for IP. The higher levels? I'm *not* going to start another TCP/IP vs OSI flamefest here today... --Steve Bellovin P.S. I don't have a very good track record as a prophet; beware... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13020@ulysses.att.com] <1990052521044500> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-ID: <13020@ulysses.att.com> Date: 25 May 90 21:04:45 GMT References: <435@jove.dec.com> <9005231723.AA20278@hp-ses.sde.hp.com> Sender: netnews@ulysses.att.com Lines: 38 Posted: Fri May 25 22:04:45 1990 In article <9005231723.AA20278@hp-ses.sde.hp.com>, wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: > HP does exactly the same thing. And Bell Labs goes even farther; we have just 2 non-isolated machines on the Internet. Application-level gateways do the rest. Why? Because in the Real World (whatever that is), our machines are not secure enough today. Blame complacent vendors, blame lazy administrators, blame careless users -- it doesn't matter much, since the empirical fact remains: a very significant fraction of hosts (and not just ours, I might add) are vulnerable. We, as a corporation, have chosen not to take the risk of exposure. Total isolation would be a serious problem; as is, most of what most people need to do on the Internet -- mail, FTP out, telnet both ways -- can be handled in a safer fashion. And most of the exceptions can be dealt with in other ways -- we do have a few more hosts that are directly connected to the Internet, but they're used for special purposes, and don't talk to anything else internally; they're dead ends. In the abstract, I mostly agree with Phil Karn -- hosts should be able to protect themselves. In fact, I spend a lot of my time working on mechanisms to help that cause. In practice, neither he nor I can administer every machine in our respective companies. I'll quote Phil's own article: The hard problem, as it turns out, lies not in generating a list of vulnerable systems, but in getting the administrators of those machines to update their software or to fix their system configurations. It's not a technical problem, but it's very real. And, given rlogin and its friends, if one host falls, a lot more will fall with it. Incidentally, I say ``mostly'' because there's an important class of device -- dial-out modems -- that is not capable of security today, and is not likely to be in the forseeable future. Finding a dialer pool on the Internet would be a hacker's idea of heaven. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005260513.AA28802@ucbvax.Berkeley.EDU] <1990052521285400> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: SIGCOMM '90 Information Message-ID: <9005260513.AA28802@ucbvax.Berkeley.EDU> Date: 25 May 90 21:28:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Posted: Fri May 25 22:28:54 1990 Hi folks: Postscript copies of the SIGCOMM '90 Program and Registration form can FTPed at the following location: nnsc.nsf.net:CCR/sigcomm90-prog.ps nnsc.nsf.net:CCR/sigcomm90-reg.ps For those of you who don't have FTP access or prefer plain text, please be patient -- plain text copies of the registration materials will be e-mailed out sometime next week. Craig PS: Please note, the SIGCOMM '90 phone number and e-mail address may work until June 1st. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052523255600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 16:40:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09357; Fri, 25 May 90 16:30:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 90 23:25:56 GMT From: van-bc!sl@ucbvax.Berkeley.EDU (Stuart Lynne) Organization: Wimsey Associates Subject: Re: Dial up access to Internet facilities Message-Id: <432@van-bc.UUCP> References: <2944@ursa-major.SPDCC.COM>, <9005240215.AA01426@psi.com>, <1990May25.163528.14300@ameristar> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May25.163528.14300@ameristar> rick@ameristar (Rick Spanbauer) writes: >In article <9005240215.AA01426@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes: } The plight of many small technical businesses is that we just cannot } justify spending $30K+ for access into the Internet for the occasional } FTP/smtp transfer. Were access fees brought inline with the level of } service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI } and other regionals would see their business pick up substantially. van-bc has a dialup SLIP link (9600 bps) into BCNet and it works quite well. It's low cost, but effective for an NNTP news feed, mail and the occasion FTP. We have configured the modems (T2500's in V.32 mode) to auto-dial our private phone number on DTR. Every ten minutes we run a script which tests if the link is alive. If not we turn it off and on again. This drops the line and redials it. Works fairly reliably, and the cost is low. Now that we have it we couldn't do without it. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052602145100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 25 May 90 20:10:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21614; Fri, 25 May 90 20:02:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 90 02:14:51 GMT From: amelia!orville.nas.nasa.gov!jmccabe@ames.arc.nasa.gov (James D. McCabe) Organization: NASA Ames Research Center, Moffett Field, CA Subject: Please help! - History of Networking Message-Id: <6355@amelia.nas.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have been tasked to develop a "History of Networking" document that describes (in gory detail) the significant events of the networking world since the Big Bang. I would appreciate any pointers to good historical literature (besides IEEE journals) about networking hardware and protocols. Please send e-mail responses to my address. Thanks. Jim D. McCabe Numerical Aerodynamic Simulation (NAS) Program NASA/Ames Research Center jmccabe@nas.nasa.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052602200000> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Fri, 25 May 90 14:00:32 PDT Received: from vm.uni-c.dk by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 2722; Fri, 25 May 90 17:00:47 EDT X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from nbivax.nbi.dk (ENGELHAR) by vm.uni-c.dk (Mailer R2.03B) with BSMTP id 2134; Fri, 25 May 90 23:02:18 DNT Date: Fri, 25 May 90 23:00 +0200 (NBI, Copenhagen) From: ALLAN ENGELHARDT Subject: Will *somebody* PLEASE remove me from this list. To: TCP-IP@NIC.DDN.mil Message-id: <8C64ABD7FC9F2000E9@nbivax.nbi.dk> X-Envelope-to: TCP-IP@NIC.DDN.mil X-VMS-To: IN%"TCP-IP@NIC.DDN.mil" X-VMS-Cc: ENGELHARDT Copenhagen, 25-MAY-1990 HELP. I did an UNSUB * (NETWIDE and it worked on every other list than this. Will somebody please delete me from this list? Allan Engelhardt Internet: ENGELHARDT@nbivax.nbi.dk (nbivax.nbi.dk=129.142.100.3) HEPnet: NBIVAX::ENGELHARDT (NBIVAX=21.106=22105) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052603314900> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Sat, 26 May 90 07:14:57 PDT To: tcp-ip@nic.ddn.mil Subject: re: SIGCOMM '90 Information Date: Sat, 26 May 90 10:11:49 -0400 From: Craig Partridge Hi folks: Despite proof reading twice, my little note had an error. The SIGCOMM '90 e-mail address and phone number may NOT work until June 1st (In other words, after June 1 you can expect them to be up and running). My apologies to the University of Pennsylvania people who are working hard to set up the phone line and e-mail address. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052605125200> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Sat, 26 May 90 14:12:31 PDT Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5121; Sat, 26 May 90 17:12:52 EDT Received: by * (Mailer R2.03B) id 6933; Sat, 26 May 90 10:14:25 EST Date: Sat, 26 May 90 10:12:52 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: Re: Netwatch ??? To: tcp-ip@nic.ddn.mil And while we are on the subject, I have heard there is a version of NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec. Does anyone have any idea where I might find an EXE for this vesion?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005261728.AA00932@ucbvax.Berkeley.EDU] <1990052614114900> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: SIGCOMM '90 Information Message-ID: <9005261728.AA00932@ucbvax.Berkeley.EDU> Date: 26 May 90 14:11:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Posted: Sat May 26 15:11:49 1990 Hi folks: Despite proof reading twice, my little note had an error. The SIGCOMM '90 e-mail address and phone number may NOT work until June 1st (In other words, after June 1 you can expect them to be up and running). My apologies to the University of Pennsylvania people who are working hard to set up the phone line and e-mail address. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005262224.AA16033@ucbvax.Berkeley.EDU] <1990052615125200> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: Re: Netwatch ??? Message-ID: <9005262224.AA16033@ucbvax.Berkeley.EDU> Date: 26 May 90 15:12:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Sat May 26 16:12:52 1990 And while we are on the subject, I have heard there is a version of NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec. Does anyone have any idea where I might find an EXE for this vesion?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052617431200> Received: from psi.com by NIC.DDN.MIL with TCP; Sat, 26 May 90 21:01:29 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA19852; Sun, 27 May 90 00:23:12 -0400 Message-Id: <9005270423.AA19852@psi.com> To: ameristar!rick@sbcs.sunysb.edu (Rick Spanbauer) Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-Reply-To: Your message of 25 May 90 16:35:28 +0000. <1990May25.163528.14300@ameristar> Date: Sun, 27 May 90 00:23:12 -0400 From: "Martin Lee Schoffstall" Rick, Someday I hope to meet you..... 5 years of private and public email and our paths haven't crossed yet, just swords.... :-) The plight of many small technical businesses is that we just cannot justify spending $30K+ for access into the Internet for the occasional FTP/smtp transfer. Were access fees brought inline with the level of service offered, eg $2K-5K/yr for dialup SLIP is reasonable, surely PSI and other regionals would see their business pick up substantially. Aside for PSI/PSINet not being a regional, (think about th N word), I think most of us have recognized an entry level market. There must be half a dozen providers who have something that looks like ~$10K with dedicated facilities. One of the issues on the dialup front is that a major cost is hidden, the message units that all businesses have to pay. In many LATA's a 4wire unconditioned analog circuit costs $100/mo, the cross over point where the message units are more expensive is probably not too many of the 3 hour periods described below. Somehow dialup Internet access and SMTP don't go hand and hand in my mind, my estimate is that your going to have keep a connection open for about 3 hours every day to have some probablity of synchronizing with all the SMTP agents pushing mail out of their queues for the site. Realistically you'll be running uucp/tcp to a site like UUPSI who is MX'ing for your domain. Note that it isn't small business alone that has a problem with the high connection costs to the Internet. Ameristar sells IP/TCP network products and every once in a while I ask some of our larger customers ($20M & up) why they are not on the Internet. The answer is usually that the perceived value of the connection is not in line with the yearly access fee. In such cases, a low cost dialup SLIP service would go a long way in giving people a chance to experiment with Internet access to evaluate its usefullness to their organization. Dialup SLIP is also a safe way for the regionals to toy with their price/volume curve without having to add infastructure (ie additional or higher capacity links) at the outset of the experiment. At least you could talk them into getting a good quality UUCP connection so they can do email. I'm frightened by the lack of participation of many vertical industries in communicating with their customers, suppliers, except through phones. (Have you ever entered voice mail grid lock, where neither party ever gets through due to synchronization problems, and the use of voice mail systems as filtering devices. Someday the only time you'll ever get an answer is by dialing 1-900.lovenow). One other suggestion I have is that the regionals ought to survey potential customers about the sort of connectivity and services they would purchase as a function of cost. Good starting sample data sets might be the lists of technical companies that local business organizations or government maintains, or even UUCP maps. This has been done, but your sampling focus is a good suggestion. Please do make an announcement of any new services PSI introduces. I for one would like to hear what PSI is doing to moderate access fees without having to ping your sales organization every few months. Maybe Kent England will radio you in reports from "The Front", rumored to have been named "Operation Fortress Beantown", BarHarborAirlines has guaranteed that they can airlift as many cisco's as they will need to sustain the battle. :-) Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052618594100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 26 May 90 12:41:31 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06985; Sat, 26 May 90 12:31:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 90 18:59:41 GMT From: swrinde!cs.utexas.edu!mailrus!b-tech!zeeff@ucsd.edu (Jon Zeeff) Organization: Branch Technology Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <46F%_++@b-tech.uucp> References: <435@jove.dec.com>, <9005231723.AA20278@hp-ses.sde.hp.com>, <13020@ulysses.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >not secure enough today. Blame complacent vendors, blame lazy >administrators, blame careless users -- it doesn't matter much, >since the empirical fact remains: a very significant fraction While it may not matter when deciding to use a "secure" gateway, the cause matters very much when you go to fix the problems (which I hope you are still doing). It doesn't inspire confidence - even AT&T can't make a Unix they trust. >Incidentally, I say ``mostly'' because there's an important class of >device -- dial-out modems -- that is not capable of security today, and >is not likely to be in the forseeable future. Finding a dialer pool on There are these $100 toll restrictors (a little box) that help quite a bit. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052619471300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 26 May 90 13:41:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA10676; Sat, 26 May 90 13:39:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 May 90 19:47:13 GMT From: netnews.upenn.edu!pcpond.cis.upenn.edu!farber@rutgers.edu (David J. Farber) Organization: University of Pennsylvania Subject: SIGCOMM90 email is operational since 25 May Message-Id: <25293@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The email query address is available as of this time. Send any requests etc to: sigcomm90@cis.upenn.edu Dave David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele: 215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293; Cellular: 302-740- 1198 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- R. P. Feynman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13027@ulysses.att.com] <1990052700414900> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-ID: <13027@ulysses.att.com> Date: 27 May 90 00:41:49 GMT References: <435@jove.dec.com> <9005231723.AA20278@hp-ses.sde.hp.com> <46F%_++@b-tech.uucp> Sender: netnews@ulysses.att.com Lines: 21 Posted: Sun May 27 01:41:49 1990 In article <46F%_++@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > It doesn't inspire confidence - even AT&T can't make a Unix they trust. AT&T is not a homogeneous place -- for example, we have a lot of Sun workstations. (Remember the joint development deal, if nothing else.) We have an OEM agreement with Pyramid. We buy other machines for other reasons. And the best system in the world can be totally hosed by an incompetent administrator. And even on 6386s or 3B2s with good administrators, sometimes a machine *must* run back releases of the software, with known bugs not yet fixed. > >Incidentally, I say ``mostly'' because there's an important class of > >device -- dial-out modems -- that is not capable of security today, and > >is not likely to be in the forseeable future. Finding a dialer pool on > > There are these $100 toll restrictors (a little box) that help quite a bit. No, they don't. Why should we prevent ourselves from making long-distance calls? We have dial-out modems because we need them and use them, and often -- generally? -- not for local use. To give an important case in point, there's an AT&T office in Tokyo; we call it often via uucp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052701255000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 26 May 90 21:45:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04235; Sat, 26 May 90 21:41:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 May 90 01:25:50 GMT From: attcan!utgpu!utzoo!henry@uunet.uu.net (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1990May27.012550.14745@utzoo.uucp> References: <9005231723.AA20278@hp-ses.sde.hp.com>, <13020@ulysses.att.com>, <46F%_++@b-tech.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <46F%_++@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >It doesn't inspire confidence - even AT&T can't make a Unix they trust. More precisely, they can't make a Unix that they can trust when it is administered by incompetents. Nobody else can make such a system either. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052704033000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 26 May 90 21:15:25 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA02482; Sat, 26 May 90 21:05:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 May 90 04:03:30 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali!rpi!image.soe.clarkson.edu!news@ucsd.edu (Russ Nelson) Organization: Clarkson University, Potsdam NY Subject: Re: Netwatch ??? Message-Id: References: <9005262224.AA16033@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005262224.AA16033@ucbvax.Berkeley.EDU> 702WFG@SCRVMSYS.BITNET (bill gunshannon) writes: And while we are on the subject, I have heard there is a version of NETWATCH that uses Packet Drivers that meet the FTP Assoc. Spec. Does anyone have any idea where I might find an EXE for this vesion?? FTP to sun.soe.clarkson.edu:/pub/ka9q/pcippkt.arc. Or call (315)268-6667, log in, change to the TCP/IP area, and download pcippkt.arc -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052712323600> Received: from ocdis01.af.mil by NIC.DDN.MIL with TCP; Sun, 27 May 90 18:52:18 PDT Return-Path: Received: by ocdis01.af.mil id AA22778; Sun, 27 May 90 20:52:37 -0500 Message-Id: <9005280152.AA22778@ocdis01.af.mil> Date: Sun May 27 20:52:36 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) Subject: toll restrictors To: tcp-ip@nic.ddn.mil Status: N There are software products on the market which allow the system administrator to automate and control connections to other systems. We use a product that automates phone, network and direct connections, and restricts access to specified users or groups of users. The user picks the system they want from a menu, and the software handles the connection automatically. A few seconds later, they see the banner and login prompt of the system they wanted to use. There are two drawbacks. The administrator must set up access to new systems as needed, and must turn off other avenues such as tip, cu, and telnet. The product we use replaces telnet, but does not yet replace ftp. We have limited ftp access to a specified group of users, and we log their usage. At our site, the advantages far outweigh the disadvantages - simpler for the user, less user training/support, and a full audit trail of outbound connections made from our system. As background info, we have nearly 1500 users, about 550 people use the system each day, and several dozen use our system as a gateway to others. We plan on doubling this usage within a year. We have a Class A Internet address, a Class C Ethernet connection, outbound modems, and connection to several other systems through a base-wide broadband LAN. The product we use allows us to provide better service to our user community, reduce our training and support burden, and provide accountability and auditability. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052721011500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 27 May 90 14:17:54 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17808; Sun, 27 May 90 14:02:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 May 90 21:01:15 GMT From: mailrus!b-tech!zeeff@tut.cis.ohio-state.edu (Jon Zeeff) Organization: Branch Technology Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <+ZG%=Z=@b-tech.uucp> References: <9005231723.AA20278@hp-ses.sde.hp.com>, <46F%_++@b-tech.uucp>, <13027@ulysses.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >> There are these $100 toll restrictors (a little box) that help quite a bit. > >No, they don't. Why should we prevent ourselves from making long-distance >calls? We have dial-out modems because we need them and use them, and They don't prevent long distance calls - you just have to program in the numbers that are allowed. Even so, I will admit that that aren't suitable for all situations. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052721580700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 27 May 90 15:32:15 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21522; Sun, 27 May 90 15:18:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 May 90 21:58:07 GMT From: bbn.com!wbe@apple.com (Winston Edmond) Organization: Bolt Beranek and Newman, Inc., Cambridge, MA Subject: Re: Dial up access to Internet facilities Message-Id: <56695@bbn.BBN.COM> References: <9005231128.AA19114@ncri.cise.nsf.gov>, <2936@ursa-major.SPDCC.COM>, <90121@uunet.UU.NET> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <90121@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >UUNET plans to offer access to any Internet site from any Compuserve Dialup >in the continental US. >All access will require an individual login/password for accountability and >authorization to use the Internet will be verified before the account is >established. >We plan to charge $5 per connect hour (in increments of 1 minute). Would UUNET be a CompuServe service provider, charging a $5/hr. surcharge, or are you talking about using the CompuServe network and somehow bypassing logging in to CompuServe itself? Is the individual login/password the usual CompuServe user number and password, or a UUNET login? >We could start tomorrow if I could figure out how to bill for it. >Its not worth sending out invoices for only $5. There are a number of CompuServe service providers that collect surcharges directly from CompuServe -- the user gets a single bill, and CompuServe's billing system keeps track of the surcharges in case the user has questions about his bill. This allows a service provider to charge small amounts, like the $.02 stock quote charge, or the $.90 car profile charge, and still be able to make money -- you don't have to bill the customer yourself. -WBE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052803571600> Received: from andrew.cmu.edu by NIC.DDN.MIL with TCP; Mon, 28 May 90 07:39:06 PDT Received: by andrew.cmu.edu (5.54/3.15) id for tcp-ip@nic.ddn.mil; Mon, 28 May 90 10:42:06 EDT Received: via switchmail; Mon, 28 May 90 10:42:04 -0400 (EDT) Received: from unix4.andrew.cmu.edu via qmail ID ; Mon, 28 May 90 10:37:25 -0400 (EDT) Received: from unix4.andrew.cmu.edu via qmail ID ; Mon, 28 May 90 10:37:18 -0400 (EDT) Received: from VUI.Andrew.3.20.CUILIB.3.45.SNAP.NOT.LINKED.unix4.andrew.cmu.edu.vax.3 via MS.5.6.unix4.andrew.cmu.edu.vax_3; Mon, 28 May 90 10:37:16 -0400 (EDT) Message-Id: Date: Mon, 28 May 90 10:37:16 -0400 (EDT) From: Michael Ginsberg To: tcp-ip@nic.ddn.mil, Outbound News , Outbound News , Outbound News Subject: SLIP - Serial Line Internet Protocol I would like to be able to transfer data from a networked unix machine to a portable computer which cannot be put on the network. Both machines do have serial ports, and it was suggested that I look into SLIP, the Serial Line Internet Protocol. However, I have been very unsucccessful in tracking down information on how I can go about using SLIP. Can someone please tell mewhat I must do to use SLIP? Is there public domain software out there? Is it part of the system already? Thanks alot for any useful information/pointers. Please respond via email as I don't read this board. If there is any/enough response, I will post a summary. --Michael Ginsberg, i386 Mach Group, School of Computer Science Carnegie Mellon University, Pittsburgh, Pennsylvania, USA --------------------------------------------------------------------------- ARPA: mg32+@andrew.cmu.edu |Electrocution, n: BITNET: mg32@cmccvb | Burning at the stake with UUCP: ...!harvard!andrew.cmu.edu!mg32+ | all the modern improvements. --------------------------------------------------------------------------- Sex is not the answer. Sex is the question. Yes is the answer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052817434700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 28 May 90 10:48:52 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17349; Mon, 28 May 90 10:46:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 May 90 17:43:47 GMT From: bronze.ucs.indiana.edu!mckimg@iuvax.cs.indiana.edu (geoffrey mckim) Organization: Indiana University, Bloomington Subject: Re: Dial up access to Internet facilities Message-Id: <45934@iuvax.cs.indiana.edu> References: , , <90142.080835PMW1@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >In article , >nelson@sun.soe.clarkson.edu (Russ Nelson) says: >>That's too bad, because when I've gone travelling in the past, I've called >>the local university, asked for their terminal server's phone number, and >>telnetted back to Clarkson to check my mail. It's a shame that that kind >>of service has to go away... > >Actually, you can still check your mail, but for the price of a toll call >back to your own terminal server. > >Maybe this is the price we have to pay for added security? > >/Pete >-- >Peter M. Weiss I don't mean to flame but... Obviously one of the primary benefits of something like the Internet is fast, efficient connections around the world. Sure, if we wanted to, we could all just have cheapo 1200 baud modems on our desks and dial up whatever machine we want to directly. But that sort of defeats the purpose of a high-speed network. In other words, the easiest way to improve security is to simply disconnect all the machines on the network from all others. But then we've got no network eh? I'm afraid that knee-jerk reactions have long been the hallmark of those in charge of computer security. I realize that it will always be difficult to balance functionality and security, but I also hope that people realize that the reason for the network's existence is FUNCTIONALITY. I for one will certainly work to fight the elimination of dial-up terminal servers connected to the internet. Let's make our hosts more secure and not intentionally cripple the internet. Geoffrey McKim *** Standard disclaimers apply *** Indiana University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052900145600> Received: from salt.acc.com by NIC.DDN.MIL with TCP; Tue, 29 May 90 11:54:54 PDT Received: by salt.acc.com (5.61/1.34) id AA03976; Tue, 29 May 90 11:54:56 -0700 Date: Tue, 29 May 90 11:54:56 -0700 From: chris@salt.acc.com (Chris VandenBerg) Message-Id: <9005291854.AA03976@salt.acc.com> To: tcp-ip@nic.ddn.mil Subject: HPLaserJet Ethernet board? Good morning all, I was asked a question this morning about whether you could hook an HPLaserJet printer directly onto an Ethernet without using a terminal server port. I seem to remember hearing that someomne made a card that fit into the expansion slot that had an Ethernet connector and TCP/IP software righton it. Does anyone else know anything about this type of setup or am I sufferingillusions of connectivity? (:*) Thanks in advance, Chris VandenBerg ACC (chris@salt.acc.com) 805-963-9431 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052903252600> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by NIC.DDN.MIL with TCP; Tue, 29 May 90 07:05:03 PDT To: tcp-ip@nic.ddn.mil Subject: SIGCOMM '90 Advance Program [Text] Date: Tue, 29 May 90 10:05:26 -0400 From: Craig Partridge SIGCOMM '90 - General Information SIGCOMM is the annual conference of the ACM Special Interest Group in Computer Communication. This year's conference will be held at the University City Sheraton Hotel in Philadelphia, Pennsylvania, September 24-27th. This program contains the advance schedule for the conference, registration information, and hotel information. If you have any questions, feel free to contact the SIGCOMM '90 conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu. SIGCOMM Conference Committee General Chair: Prof. David J. Farber (Univ. Pennsylvania) Program Chair: Phil Karn (Bellcore) Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania) Local Arrangements: Dan Finnigan (Univ. Pennsylvania) Publicity Chair: Craig Partridge (Bolt Beranek and Newman) Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI) SIGCOMM Program Committee Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf (CNRI), Doug Comer (Purdue), Jon Crowcroft (Univ. College London), Gary Delp (IBM), John Demco (CDNnet), Magda El-Zarki (Univ. Pennsyl- vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ. Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington Univ. St. Louis), Larry L. Peterson (Univ. Arizona), Steve Pink (SICS), Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ. Pennsylvania) Tutorials: September 24th [9 AM to 5 PM] Tutorial #1: Protocols for High-Speed Networks Instructors: Harry Rudin and Van Jacobson Part A: High-Performance, Transport-Level Protocols (Rudin) Made possible by progress in fiber-optic and VLSI technologies, networks offering increasing transmission capacity at decreasing error rates are becoming available. New applications would benefit from this bandwidth but software protocol processing rates have not kept up with available raw transmission speed. The presentation is a comparative survey of techniques used at the transport layer in eight representative protocols, most of which were designed to improve the protocol processing rate. The protocols are the relevant portions of the APPN, Datakit, Delta-t, NETBLT, OSI/TP4, TCP, VMTP, and XTP architectures. The main functions covered are: connection management, acknowledgements, flow control, and error handling. Part B: Efficient TCP Implementation (Jacobson) Network protocol processing time has long been viewed as THE deter- miner of perceived network performance. For at least one well known suite, the TCP and IP Internet protocols, recent measurement has shown this view to be false: The protocol *implementation* affects perceived performance, as does the way in which the network interface hardware interacts with the entire software/hardware sys- tem it is a part of. But there is no inherent performance limit in the TCP/IP protocols themselves. In fact, a Unix TCP/IP imple- mentation has been constructed that runs at a essentially the information-theoretic minimum time for the the problem being solved. This tutorial will describe an efficient TCP/IP implementation in agonizing detail. It will describe where time goes in a typical implementation and what can be done in the protocol and system software to reclaim that time. It will discuss how the network interface hardware affects processing time and what hardware archi- tectures lead to cheap, efficient processing. Familiarity with the TCP and IP protocols will be assumed. Although the implementation described will be based on a real, pro- duction, Berkeley Unix TCP/IP, no Unix kernel expertise will be assumed, only familiarity with operating system issues and imple- mentations. Harry Rudin received the B.E. and D.Eng. degrees from Yale Univer- sity, where he also taught until 1964. He worked at Bell Telephone Laboratories in the area of data communications until 1968. Since then he has been doing research in computer communications systems at the Zurich Research Laboratory, IBM Research Division, in Rueschlikon, Switzerland. His interests are high-speed protocols and the use of formal description techniques for protocol develop- ment. He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a graduate course on computer networks at the Swiss Federal Institute of Technology in Zurich, and is a senior editor of Computer Net- works and ISDN Systems magazine. Van Jacobson received a MS in Physics and a BS in Mathematics from the University of Arizona in 1972. Since then he has been a Staff Scientist in the Real Time Systems Group of Lawrence Berkeley Laboratory, developing high performance, distributed, data acquisi- tion and control systems. Since 1984 his research has concentrated on network protocols and the dynamics of large-scale networks. Since 1985 he has served as an adjunct lecturer in Computer Science at the University of California, Berkeley, and Stanford University. Tutorial #2: Object-Oriented Network Management and Control Instructors: Aurel Lazar and Mark W. Sylor The objective of this tutorial is to present a structured approach to problems arising in network management and control. Object- oriented modeling of communication networks. Knowledge representa- tion, entity/relationship models for data representation. Models of network management and control. Managed and managing objects. Performance management. Computational models for data abstraction. The OSI Information Model and the Management Information Base. Knowledge based monitoring and control. Modeling examples of real networks. DECnet - EMA Entities, TCP/IP - MIB definitions. Exam- ples will also be drawn from AT&T's UNMA and IBM's Netview. Sup- porting capabilities and architectures: testing, down/line loading, event logging, time service and naming. Aurel A. Lazar is a Professor of Electrical Engineering and Direc- tor of the Telecommunication Networks Laboratory at Columbia University. He received the Dipl.-Ing. degree in communications engineering (Nachrichtentechnik) from the Technische Hochschule Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the Ph.D. degree in information sciences and systems from Princeton University, Princeton, NJ, in 1980. During the 80's he was involved in the design and implementation of integrated networks supporting video, voice and data services. Most recently, he was the chief architect of MAGNET II a metropolitan area network based on Asynchronous Time Sharing. Currently he is leading the design and implementation of a real-time traffic control architecture for integrated networks. Mark W. Sylor is a member of the Enterprise Management Architecture group at Digital Equipment Corperation in Littleton, MA, where he works on the EMA Entity Model, and the Phase V DECnet Network Management Specification. He has been a member of the ISO and ANSI committees working on OSI System Management, and was formerly the ANSI T5.4 ad-hoc group leader on the Structure of Management Infor- mation (SMI). Mark has been involved with the design and implemen- tation of many of Digital's Network Management systems, in particu- lar the NMCC/DECnet Monitor, where he was the principle designer and development supervisor. Mark earned a B.A. degreee at S.U.N.Y. at Geneseo in 1971 and an M.S. degree at the University of Notre Dame in 1975, both in Mathematics. Technical Program: September 25-27th MONDAY, September 24th RECEPTION [7 PM to 9 PM] TUESDAY, September 25th Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30] Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith Random Drop Congestion Control, A. Mankin (Mitre) A Stop-and-Go Queueing Framework for Congestion Management, S.J. Golestani (Bellcore) Virtual Clock: a new traffic control algorithm for packet switch- ing networks, L. Zhang (Xerox PARC) Dynamic Adaptive Windows for High Speed Data Networks: Theory and Simulations, D. Mitra (AT&T Bell Laboratories) Lunch [12:00 - 1:30] Session #2: Applications and Distributed Systems [1:30 - 3:00] Chair: Larry Peterson Efficient At-Most-Once Messages Based on Synchronized Clocks, L. Shrira, J. Wroclawski, B. Liskov (MIT) Uniform Access to Internet Directory Services, D. Comer (Purdue Univ.) and R.E. Droms (Bucknell Univ.) A Data Processing Performance Model for the OSI Application Layer Protocols, T. Shiroshita (NTT) Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft A Simple Multiple Access Protocol for Metropolitan Area Networks, J.O. Limb (Hewlett-Packard) The BBN Dual Bus Protocol: Performance in a Wide Area Network, W. Edmond, K. Seo, M. Leib, C. Topolcic (BBN) Machnet: A Simple Access Protocol for High Speed or Long Haul Com- munications, P. Jacquet, P. Muhlethaler (INRIA) SIGCOMM Business Meeting [5:15 - 6:00] WEDNESDAY, September 26th Session #4: Multimedia Protocols and Protocol Testing [9:00 - 10:30] Chair: Guru Parulkar Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler, G. Weiss (Brooklyn College) Link Access Blocking in Very Large Multi-Media Networks, J.-F. Labourdette, G. Hart (Columbia Univ.) Protocol Conformance Test Generation Using Multiple UIO Sequences with Overlapping, B. Yang, H. Ural (University of Ottawa) Session #5: High-Speed Switching [11:00 - 12:30] Chair: Zygmunt Haas Gauss: a simple high performance switch architecture for ATM, R.J.F. de Vries (PTT Research, Netherlands) Protocol Implementation on the Nectar Communication Processor, E.C. Cooper, P.A. Steenkiste, R.D. Sansom, B.D. Zill (Carnegie Mellon Univ.) Pulsar: Non-blocking Packet Switching with Shift-Register Rings, G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois) Lunch [12:30 - 2:00] Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox PARC) Shortest Path First with Emergency Exits, Z. Wang, J. Crowcroft (University College London) Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer- buch (MIT) Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge Transport Protocol Processing at GBPS rates, N. Jain, M. Schwartz (Columbia University) Architectural Considerations for a New Generation of Protocols, D.D. Clark, D.L. Tennenhouse (MIT) Multiplexing Issues in Transport Protocol Design, D.C. Feldmeier (Bellcore) Banquet [6:30 - 8:00] THURSDAY, September 27th Session #8: Routing [9:00 - 10:30] Chair: Steve Pink Avoiding Name Resolution Loops and Duplications in Group Communi- cations, L. Liang, G.W. Neufeld, S.T. Chanson (Univ. of British Columbia) Design of Inter-Administrative Domain Routing Protocols L. Breslau, D. Estrin (USC) Topology Distribution Cost vs. Efficient Routing In Large Net- works, A. Bar-Noy, M. Gopal (IBM Watson) Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco Efficient Use of Workstations for Passive Monitoring of Local Area Networks, J. Mogul (DEC) Performance Analysis of FDDI Token Ring Networks: Effect of Param- eters and Guidelines for Setting TTRT, R. Jain (DEC) Frame Content Independent Stripping for Token Rings, H. Yang, K. K. Ramakrishnan (DEC) Lunch [12:30 - 2:00] Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack Fast Connection Establishment in High Speed Networks, I. Cidon, I. Gopal, A. Segall (IBM Watson and Technion) Reliable Broadband Communications Using a Burst Erasure Correcting Code, A.J. McAuley (Bellcore) An Inclusive Session Protocol for Distributed Applications, V.S. Sunderam (Emory Univ.) SIGCOMM '90 wishes to thank our host site, the University of Pennsylvania for its considerable support in putting on this conference. SIGCOMM '90 would also like to acknowledge the generous support of the following corporations: Advance Computer Communications, Bellcore, FTP Software, Digital Equipment Corporation's Network Systems Lab, and Interop Inc. Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich, in Zurich, Switzerland. ******************************************************************************* SIGCOMM '90 Advance Registration Form mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania, 329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA NAME ____________________________________ AFFILIATION _____________________________ ADDRESS _________________________________ ____________________________________ ____________________________________ Phone: __________________________________ E-mail: _________________________________ SIGCOMM/ACM Member # ____________________ Tutorials: before 9/1 after 9/1 Members $175 $230 Non-Members $230 $280 Students $100 $100 [student tutorial rates on space available basis] Tutorial #1 ___ or Tutorial #2 ___ $_____ Conference: before 9/1 after 9/1 Members $230 $280 Non-Members $280 $330 Students $100 $100 $_____ Total $_____ dietary restrictions ___ kosher ___ vegetarian ******************************************************************************* SIGCOMM '90 Hotel Registration Form mail to: University City Sheraton Hotel, 36th and Chestnut St, Philadelphia, PA 19104 (215-387-8000) Registration must be received 8/23 to ensure these rates NAME ____________________________________ ___ Single $80 + tax AFFILIATION _____________________________ ___ Double $90 + tax ADDRESS _________________________________ Univ. of Pennsylvania CIS rate ____________________________________ ____________________________________ Phone: __________________________________ Arrival Date: ___________________________ Departure Date: _________________________ to guarantee arrival after 4PM please provide credit card information Card Name & Number _______________________________ Expires _______ Name on Card _________________________________ Signature _________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052905152500> Received: from vax.ftp.com by NIC.DDN.MIL with TCP; Tue, 29 May 90 06:14:44 PDT Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA01112; Tue, 29 May 90 09:15:25 EDT Date: Tue, 29 May 90 09:15:25 EDT Message-Id: <9005291315.AA01112@vax.ftp.com> To: swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!dan@ucsd.edu (Dan Schlitt) Subject: Re: What is the IAB? From: stev@vax.ftp.com Cc: tcp-ip@nic.ddn.mil Sender: stev@vax.ftp.com Repository: ftp.com Originating-Client: d-cell.ftp.com >I have my doubts about Roy's interpretation too. However one should >also note the anonymous critique of the governance of the Internet >that was published in Goodfellow's newsletter. Participation in the >IAB and the IETF can't be read as 100% support. >Dan Schlitt Manager, Science Division Computer Facility well, i am not on the IAB. i am an active participant in the IETF though. i am currently the PPP working group chair. while i do not support the actions of the organizations 100%, i do believe the process is the best one out there, and i also believe that one person, with well thought out arguements, and careful planning, can make a diffrence. i can also say that the IAB/IETF/IESG has never tried to shut me up, they has asked me to talk about something later, but always at reasonable times. they also have called on me many times at the IETF meetings to let me say my piece. it may not have always been in their best interest, and i am sure there have been times they wished i didnt open my mouth, but they do seem to put up with people with disenting opinions if these people are willing to work in the system to fix the problems they see. could be worse, i am told that the ISO people have to submit their statements in written form. they would get to miss my booming voice wafting out over the lecture hall. . . . :) stev knowles IETF PPP working group chair ftp software stev@ftp.com "Maybe they are all Bozo's on this bus, but they are *our* clowns, not someone elses!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052906042500> Received: from usc.edu by NIC.DDN.MIL with TCP; Tue, 29 May 90 13:03:16 PDT Received: from jerico.usc.edu by usc.edu (5.59/SMI-3.0DEV3) id AA20994; Tue, 29 May 90 13:04:28 PDT Received: by jerico.usc.edu (4.1/SMI-3.0DEV3) id AA03211; Tue, 29 May 90 13:04:25 PDT Date: Tue, 29 May 90 13:04:25 PDT Message-Id: <9005292004.AA03211@jerico.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%jerico.usc.edu@usc.edu To: paul%dy4%cognos%sce%mitel.uucp@uunet.uu.net Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Paul Burry's message of 23 May 90 14:45:43 GMT <168@dy4.UUCP> Subject: Re: Request for protocol overhead references Reply-To: estrin@usc.edu I believe that Dr. Liba Svobodova et. al. had a paper in Computer Networks and ISDN Systems (late '89 or early '90) with performance measures for TCP and TP4... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005291519.AA00280@ucbvax.Berkeley.EDU] <1990052913225500> From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities Message-ID: <9005291519.AA00280@ucbvax.Berkeley.EDU> Date: 29 May 90 13:22:55 GMT References: <8802010152.1.UUL1.3#10997@uu.psi.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Tue May 29 14:22:55 1990 >I think that "fast connections around the world" does not mean that we >have to allow anyone with a modem and terminal to telnet/rlogin into any >host at will on the Internet. Doesn't compute. dont agree - we have just been checking how fast you can clock a line based on the copper used for UK phones, and managed 200kbps without much trouble - i.e. multiple basic rate ISDNs (without even needing much tcp header compression) will make a X and NFS to 20 million UK homes feasible before the year 2000 - if anyone thought building such a wacky service ... if they do, security on my VCR is gonna be ultra-tight (i dont want some hacker making me miss my favourite show)... jon {p.s. this is not entirely serious:-} ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005291724.AA08037@ucbvax.Berkeley.EDU] <1990052914052600> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: SIGCOMM '90 Advance Program [Text] Message-ID: <9005291724.AA08037@ucbvax.Berkeley.EDU> Date: 29 May 90 14:05:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 358 Posted: Tue May 29 15:05:26 1990 SIGCOMM '90 - General Information SIGCOMM is the annual conference of the ACM Special Interest Group in Computer Communication. This year's conference will be held at the University City Sheraton Hotel in Philadelphia, Pennsylvania, September 24-27th. This program contains the advance schedule for the conference, registration information, and hotel information. If you have any questions, feel free to contact the SIGCOMM '90 conference committee, at 215-898-0016 or sigcomm90@cis.upenn.edu. SIGCOMM Conference Committee General Chair: Prof. David J. Farber (Univ. Pennsylvania) Program Chair: Phil Karn (Bellcore) Tutorial Chair: Prof. Magda El-Zarki (Univ. Pennsylvania) Local Arrangements: Dan Finnigan (Univ. Pennsylvania) Publicity Chair: Craig Partridge (Bolt Beranek and Newman) Advisors: Prof. Larry Landweber (Univ. Wisconsin), Prof. Chris Edmondson-Yurkanan (Univ. Texas), Dr. Vint Cerf (CNRI) SIGCOMM Program Committee Phil Karn (Bellcore), Ernst Biersack (Bellcore), Vint Cerf (CNRI), Doug Comer (Purdue), Jon Crowcroft (Univ. College London), Gary Delp (IBM), John Demco (CDNnet), Magda El-Zarki (Univ. Pennsyl- vania), Zygmunt Haas (AT&T), Raj Jain (DEC), Larry Landweber (Univ. Wisconsin), Craig Partridge (BBN), Guru Parulkar (Washington Univ. St. Louis), Larry L. Peterson (Univ. Arizona), Steve Pink (SICS), Marshall T. Rose (PSI), Harry Rudin (IBM), Jonathan M. Smith (Univ. Pennsylvania) Tutorials: September 24th [9 AM to 5 PM] Tutorial #1: Protocols for High-Speed Networks Instructors: Harry Rudin and Van Jacobson Part A: High-Performance, Transport-Level Protocols (Rudin) Made possible by progress in fiber-optic and VLSI technologies, networks offering increasing transmission capacity at decreasing error rates are becoming available. New applications would benefit from this bandwidth but software protocol processing rates have not kept up with available raw transmission speed. The presentation is a comparative survey of techniques used at the transport layer in eight representative protocols, most of which were designed to improve the protocol processing rate. The protocols are the relevant portions of the APPN, Datakit, Delta-t, NETBLT, OSI/TP4, TCP, VMTP, and XTP architectures. The main functions covered are: connection management, acknowledgements, flow control, and error handling. Part B: Efficient TCP Implementation (Jacobson) Network protocol processing time has long been viewed as THE deter- miner of perceived network performance. For at least one well known suite, the TCP and IP Internet protocols, recent measurement has shown this view to be false: The protocol *implementation* affects perceived performance, as does the way in which the network interface hardware interacts with the entire software/hardware sys- tem it is a part of. But there is no inherent performance limit in the TCP/IP protocols themselves. In fact, a Unix TCP/IP imple- mentation has been constructed that runs at a essentially the information-theoretic minimum time for the the problem being solved. This tutorial will describe an efficient TCP/IP implementation in agonizing detail. It will describe where time goes in a typical implementation and what can be done in the protocol and system software to reclaim that time. It will discuss how the network interface hardware affects processing time and what hardware archi- tectures lead to cheap, efficient processing. Familiarity with the TCP and IP protocols will be assumed. Although the implementation described will be based on a real, pro- duction, Berkeley Unix TCP/IP, no Unix kernel expertise will be assumed, only familiarity with operating system issues and imple- mentations. Harry Rudin received the B.E. and D.Eng. degrees from Yale Univer- sity, where he also taught until 1964. He worked at Bell Telephone Laboratories in the area of data communications until 1968. Since then he has been doing research in computer communications systems at the Zurich Research Laboratory, IBM Research Division, in Rueschlikon, Switzerland. His interests are high-speed protocols and the use of formal description techniques for protocol develop- ment. He is a Fellow of the IEEE, Chairman of IFIP WG6.1, gives a graduate course on computer networks at the Swiss Federal Institute of Technology in Zurich, and is a senior editor of Computer Net- works and ISDN Systems magazine. Van Jacobson received a MS in Physics and a BS in Mathematics from the University of Arizona in 1972. Since then he has been a Staff Scientist in the Real Time Systems Group of Lawrence Berkeley Laboratory, developing high performance, distributed, data acquisi- tion and control systems. Since 1984 his research has concentrated on network protocols and the dynamics of large-scale networks. Since 1985 he has served as an adjunct lecturer in Computer Science at the University of California, Berkeley, and Stanford University. Tutorial #2: Object-Oriented Network Management and Control Instructors: Aurel Lazar and Mark W. Sylor The objective of this tutorial is to present a structured approach to problems arising in network management and control. Object- oriented modeling of communication networks. Knowledge representa- tion, entity/relationship models for data representation. Models of network management and control. Managed and managing objects. Performance management. Computational models for data abstraction. The OSI Information Model and the Management Information Base. Knowledge based monitoring and control. Modeling examples of real networks. DECnet - EMA Entities, TCP/IP - MIB definitions. Exam- ples will also be drawn from AT&T's UNMA and IBM's Netview. Sup- porting capabilities and architectures: testing, down/line loading, event logging, time service and naming. Aurel A. Lazar is a Professor of Electrical Engineering and Direc- tor of the Telecommunication Networks Laboratory at Columbia University. He received the Dipl.-Ing. degree in communications engineering (Nachrichtentechnik) from the Technische Hochschule Darmstadt, Darmstadt, Federal Republic of Germany, in 1976, and the Ph.D. degree in information sciences and systems from Princeton University, Princeton, NJ, in 1980. During the 80's he was involved in the design and implementation of integrated networks supporting video, voice and data services. Most recently, he was the chief architect of MAGNET II a metropolitan area network based on Asynchronous Time Sharing. Currently he is leading the design and implementation of a real-time traffic control architecture for integrated networks. Mark W. Sylor is a member of the Enterprise Management Architecture group at Digital Equipment Corperation in Littleton, MA, where he works on the EMA Entity Model, and the Phase V DECnet Network Management Specification. He has been a member of the ISO and ANSI committees working on OSI System Management, and was formerly the ANSI T5.4 ad-hoc group leader on the Structure of Management Infor- mation (SMI). Mark has been involved with the design and implemen- tation of many of Digital's Network Management systems, in particu- lar the NMCC/DECnet Monitor, where he was the principle designer and development supervisor. Mark earned a B.A. degreee at S.U.N.Y. at Geneseo in 1971 and an M.S. degree at the University of Notre Dame in 1975, both in Mathematics. Technical Program: September 25-27th MONDAY, September 24th RECEPTION [7 PM to 9 PM] TUESDAY, September 25th Keynote Address: SIGCOMM AWARD Winner [9:00 - 9:30] Session #1: Congestion Control [10:00 - 12:00] Chair: Jon Smith Random Drop Congestion Control, A. Mankin (Mitre) A Stop-and-Go Queueing Framework for Congestion Management, S.J. Golestani (Bellcore) Virtual Clock: a new traffic control algorithm for packet switch- ing networks, L. Zhang (Xerox PARC) Dynamic Adaptive Windows for High Speed Data Networks: Theory and Simulations, D. Mitra (AT&T Bell Laboratories) Lunch [12:00 - 1:30] Session #2: Applications and Distributed Systems [1:30 - 3:00] Chair: Larry Peterson Efficient At-Most-Once Messages Based on Synchronized Clocks, L. Shrira, J. Wroclawski, B. Liskov (MIT) Uniform Access to Internet Directory Services, D. Comer (Purdue Univ.) and R.E. Droms (Bucknell Univ.) A Data Processing Performance Model for the OSI Application Layer Protocols, T. Shiroshita (NTT) Session #3: MANs and WANs [3:30 - 5:00] Chair: Jon Crowcroft A Simple Multiple Access Protocol for Metropolitan Area Networks, J.O. Limb (Hewlett-Packard) The BBN Dual Bus Protocol: Performance in a Wide Area Network, W. Edmond, K. Seo, M. Leib, C. Topolcic (BBN) Machnet: A Simple Access Protocol for High Speed or Long Haul Com- munications, P. Jacquet, P. Muhlethaler (INRIA) SIGCOMM Business Meeting [5:15 - 6:00] WEDNESDAY, September 26th Session #4: Multimedia Protocols and Protocol Testing [9:00 - 10:30] Chair: Guru Parulkar Mechanisms for Integrated Voice and Data Conferencing, C. Ziegler, G. Weiss (Brooklyn College) Link Access Blocking in Very Large Multi-Media Networks, J.-F. Labourdette, G. Hart (Columbia Univ.) Protocol Conformance Test Generation Using Multiple UIO Sequences with Overlapping, B. Yang, H. Ural (University of Ottawa) Session #5: High-Speed Switching [11:00 - 12:30] Chair: Zygmunt Haas Gauss: a simple high performance switch architecture for ATM, R.J.F. de Vries (PTT Research, Netherlands) Protocol Implementation on the Nectar Communication Processor, E.C. Cooper, P.A. Steenkiste, R.D. Sansom, B.D. Zill (Carnegie Mellon Univ.) Pulsar: Non-blocking Packet Switching with Shift-Register Rings, G.J. Murakami, R.H. Campbell, M. Faiman (Univ. of Illinois) Lunch [12:30 - 2:00] Session #6: Routing and Flow Control [2:00 - 3:30] Chair: Raj Jain A Theoretical Analysis of Feedback Flow Control, S. Shenker (Xerox PARC) Shortest Path First with Emergency Exits, Z. Wang, J. Crowcroft (University College London) Shortest Paths and Loop-Free Routing in Dynamic Networks, B. Awer- buch (MIT) Session #7: Gigabit Protocols [4:00 - 5:30] Chair: Craig Partridge Transport Protocol Processing at GBPS rates, N. Jain, M. Schwartz (Columbia University) Architectural Considerations for a New Generation of Protocols, D.D. Clark, D.L. Tennenhouse (MIT) Multiplexing Issues in Transport Protocol Design, D.C. Feldmeier (Bellcore) Banquet [6:30 - 8:00] THURSDAY, September 27th Session #8: Routing [9:00 - 10:30] Chair: Steve Pink Avoiding Name Resolution Loops and Duplications in Group Communi- cations, L. Liang, G.W. Neufeld, S.T. Chanson (Univ. of British Columbia) Design of Inter-Administrative Domain Routing Protocols L. Breslau, D. Estrin (USC) Topology Distribution Cost vs. Efficient Routing In Large Net- works, A. Bar-Noy, M. Gopal (IBM Watson) Session #9: LAN Issues [11:00 - 12:30] Chair: John Demco Efficient Use of Workstations for Passive Monitoring of Local Area Networks, J. Mogul (DEC) Performance Analysis of FDDI Token Ring Networks: Effect of Param- eters and Guidelines for Setting TTRT, R. Jain (DEC) Frame Content Independent Stripping for Token Rings, H. Yang, K. K. Ramakrishnan (DEC) Lunch [12:30 - 2:00] Session #10: Protocol Design [2:00 - 3:30] Chair: Ernst Biersack Fast Connection Establishment in High Speed Networks, I. Cidon, I. Gopal, A. Segall (IBM Watson and Technion) Reliable Broadband Communications Using a Burst Erasure Correcting Code, A.J. McAuley (Bellcore) An Inclusive Session Protocol for Distributed Applications, V.S. Sunderam (Emory Univ.) SIGCOMM '90 wishes to thank our host site, the University of Pennsylvania for its considerable support in putting on this conference. SIGCOMM '90 would also like to acknowledge the generous support of the following corporations: Advance Computer Communications, Bellcore, FTP Software, Digital Equipment Corporation's Network Systems Lab, and Interop Inc. Mark your calendars for SIGCOMM '91, September 3-6, 1991 at ETH Zurich, in Zurich, Switzerland. ******************************************************************************* SIGCOMM '90 Advance Registration Form mail to: SIGCOMM '90, attn: Dan Finnigan, University of Pennsylvania, 329 Moore Bldg, 200 South 33rd St, Philadelphia, PA 19104, USA NAME ____________________________________ AFFILIATION _____________________________ ADDRESS _________________________________ ____________________________________ ____________________________________ Phone: __________________________________ E-mail: _________________________________ SIGCOMM/ACM Member # ____________________ Tutorials: before 9/1 after 9/1 Members $175 $230 Non-Members $230 $280 Students $100 $100 [student tutorial rates on space available basis] Tutorial #1 ___ or Tutorial #2 ___ $_____ Conference: before 9/1 after 9/1 Members $230 $280 Non-Members $280 $330 Students $100 $100 $_____ Total $_____ dietary restrictions ___ kosher ___ vegetarian ******************************************************************************* SIGCOMM '90 Hotel Registration Form mail to: University City Sheraton Hotel, 36th and Chestnut St, Philadelphia, PA 19104 (215-387-8000) Registration must be received 8/23 to ensure these rates NAME ____________________________________ ___ Single $80 + tax AFFILIATION _____________________________ ___ Double $90 + tax ADDRESS _________________________________ Univ. of Pennsylvania CIS rate ____________________________________ ____________________________________ Phone: __________________________________ Arrival Date: ___________________________ Departure Date: _________________________ to guarantee arrival after 4PM please provide credit card information Card Name & Number _______________________________ Expires _______ Name on Card _________________________________ Signature _________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052914314500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 09:06:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03182; Tue, 29 May 90 09:02:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 14:31:45 GMT From: mcsun!cernvax!chx400!hslrswi!aut!ruef@uunet.uu.net (Bernhard Ruef) Organization: Ascom Autelca AG, CH-3073 Guemligen, Switzerland Subject: NFS for NCR TOWER Message-Id: <1332@telsys.aut.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Well, the subject line says it all: Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0 running System V.3 (Release 3.00.01 in NCR speak) ? Yes, I do know that this question has been asked before in comp.sys.ncr but I haven't yet seen a satisfactory, i.e. definite answer :-) Cheers -Beni -- Bernhard D. Ruef Ascom Autelca AG CH-3073 Guemligen/Switzerland E-mail: ruef@aut.UUCP FAX: +41 31 527 745 Voice mail: +41 31 529 602 "UNIX is the answer - what was the question ?" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052915014700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 20:24:22 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA16256; Tue, 29 May 90 20:19:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 15:01:47 GMT From: usc!jarthur!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@ucsd.edu (Bill Daniels) Organization: Federal Express Corp., Memphis, TN Subject: Query - Ethernet collisions Message-Id: <98@fedeva.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We recently acquired an Exelan LANalyzer. During our first uses of it, we noticed that about 40% of the packets on one ethernet segment (which is remotely bridged to another) show up as "Collision detected in preamble". This segment is not busy necessarily when this happens. The actual number of collisions reported seems fairly constant even as traffic picks up. On a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs. When the segment is a little more active (~ 1000 packets / sec.) the error rate is just about the same. I have tried disconnecting the devices that the errors are associated with but the collisions just move to the packets associated with other devices. Any clues? bd -- bill daniels federal express, memphis, tn {hplabs!csun,mit-eddie!premise}!fedeva!bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052915542600> Received: from psi.com by NIC.DDN.MIL with TCP; Tue, 29 May 90 18:26:30 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA07597; Tue, 29 May 90 22:34:27 -0400 Message-Id: <9005300234.AA07597@psi.com> To: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB? In-Reply-To: Your message of 29 May 90 18:41:46 +0000. <23691@bellcore.bellcore.com> Date: Tue, 29 May 90 22:34:26 -0400 From: "Martin Lee Schoffstall" Phil, Your almost correct.... > Perhaps the most important thing about the IAB is its "fly before buy" > policy. For a protocol to reach internet standard status, it must first be > implemented and widely used, and there must be a substantial body of > perational experience. CMOT was elevated to DIS without the above. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052915584600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 09:05:26 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03039; Tue, 29 May 90 09:00:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 15:58:46 GMT From: cica!ssw@iuvax.cs.indiana.edu (Steve Wallace) Organization: Center for Innov. Comp. Appl., Bloomington, IN Subject: When is an ethernet full? Message-Id: <1141@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil When is an ethernet full? We have a campus backbone composed of a chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over broadband (buffered repeaters). The UB and chipcom networks are bridged to form one logical networks. According to our Network General sniffer, we constantly maintain about 10-15 percent utilization or (300 - 1000 packets per second). How much more traffic can this network support before performance falls off measurably? Any ideas? Thanks, Steven Wallace Indiana University wallaces@ucs.indiana.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052916025500> Received: from Cs.Ucl.AC.UK by NIC.DDN.MIL with TCP; Tue, 29 May 90 06:26:51 PDT To: "Martin L. Schoffstall" cc: uupsi!iuvax.cs.indiana.edu!bronze.ucs.indiana.edu!mckimg@uu.psi.com, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-reply-to: Your message of Mon, 01 Feb 88 01:52:09 -0500. <8802010152.1.UUL1.3#10997@uu.psi.com> Date: Tue, 29 May 90 14:22:55 +0100 From: Jon Crowcroft Source-Info: sol.cs.ucl.ac.uk >I think that "fast connections around the world" does not mean that we >have to allow anyone with a modem and terminal to telnet/rlogin into any >host at will on the Internet. Doesn't compute. dont agree - we have just been checking how fast you can clock a line based on the copper used for UK phones, and managed 200kbps without much trouble - i.e. multiple basic rate ISDNs (without even needing much tcp header compression) will make a X and NFS to 20 million UK homes feasible before the year 2000 - if anyone thought building such a wacky service ... if they do, security on my VCR is gonna be ultra-tight (i dont want some hacker making me miss my favourite show)... jon {p.s. this is not entirely serious:-} ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052916533100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 10:49:43 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA07697; Tue, 29 May 90 10:19:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 16:53:31 GMT From: oliveb!orc!bbn.com!craig@apple.com (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: When is an ethernet full? Message-Id: <56724@bbn.BBN.COM> References: <1141@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > When is an ethernet full? .... > According to our Network General sniffer, > we constantly maintain about 10-15 percent utilization or (300 - 1000 > packets per second). How much more traffic can this network support > before performance falls off measurably? Any ideas? The best place I know of to start answering this question is Boggs, Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The gist of that article is that you can drive the Ethernet all the way to its rated capacity assuming you are careful in the way you lay out your network, and all your systems have good Ethernet hardware. In practice of course, many of the systems won't have good Ethernet hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd found an Ethernet chipset that could only go about 6 Mbits/sec). So you need to find some people out there with some good practical experience about when some of their systems start breaking down, to figure out when your network will die due to poor hardware/software. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052917240200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 10:53:02 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA08815; Tue, 29 May 90 10:34:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 17:24:02 GMT From: usc!cs.utexas.edu!uwm.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) Organization: Boston University Subject: Re: Dial up access to Internet facilities Message-Id: <57875@bu.edu.bu.edu> References: <9005270423.AA19852@psi.com>, <1990May25.163528.14300@ameristar> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005270423.AA19852@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes: ... > At least you could talk them into getting a good quality UUCP connection > so they can do email. I'm frightened by the lack of participation of > many vertical industries in communicating with their customers, suppliers, > except through phones. (Have you ever entered voice mail grid lock, where > neither party ever gets through due to synchronization problems, and > the use of voice mail systems as filtering devices. Someday the only > time you'll ever get an answer is by dialing 1-900.lovenow). > ... > Please do make an announcement of any new services PSI introduces. I > for one would like to hear what PSI is doing to moderate access fees > without having to ping your sales organization every few months. > > Maybe Kent England will radio you in reports from "The Front", rumored > to have been named "Operation Fortress Beantown", BarHarborAirlines has > guaranteed that they can airlift as many cisco's as they will need to > sustain the battle. :-) > > Marty Glad to! [BTW, it's not "Operation Fortress Beantown". Only folks from elsewhere and local sportswriters call Boston Beantown. :-] We got the three inches of water pumped out of the main bunker and the dehumidifier is fixed now, so it's bearable down here. I have a pretty good view of the harbor and Logan airport. PSI has been airlifting in dial-up servers, but we shot down most of them, since the visibility was pretty poor and PSI didn't pay for good IFR gear. Better luck next time, Marty. :-) Seriously, though, I share Marty's concern about a lack of interest in commercial enterprises in supporting business using modern internetworks. It would seem obvious to me what the benefits are, so perhaps we just need to be more aggressive in touting the capabilities of the technology we know and love. Marty will see to that, as far as he can, since his livelihood depends on it. I see a definite interest on the part of commercial organizations wishing to join the research and education (R&E) Internet, but I see much less interest from them in joining a purely commercial internet service- they don't seem to understand who they would be able to talk to on a purely commercial internet. Come to think of it, neither do I. But certainly there is a lot of interest from commercial outfits in becoming a part of our R&E Internet and in exploiting that technology to talk to the existing base of constituents. NEARnet has had a phenomenal response from commercial organizations joining NEARnet and the Internet. There are a lot of research labs in the Boston area, and they are very eager to be a part of the R&E Internet. Perhaps it is just that they are able to move more quickly allocating budget to the NEARnet connection, and are therefore able to connect more quickly than some of our colleagues in the academic field in New England. We'll see. Like the PSI folk, NEARnet is aware of an untapped potential base for lower cost access to the Internet, from both the commercial organizations and from academic organizations. As might be expected, this is due mostly to a scale pyramid= there are simply more small sites than large. NEARnet is committed to broadening its base of support to include smaller sites at lower cost. We are chafing against technical issues in being able to offer high quality service at lower costs, since we balance hardware and people costs, and people costs are not really that bandwidth sensitive. We also have strict standards on quality of service, and we do not wish to compromise these standards in offering less costly access, since we know that later on our customers would regret the compromise as much as we. Then there is the issue of just what is part-time access; is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have to keep in mind what services we provide and we have to make sure that our clients understand what they can and can't do with new service offerings. All in all, though we have been able to keep costs quite reasonable, so far as we can tell in comparing costs with our neighbors. As far as keeping up with new service offerings, you should keep an eye on comp.newprod. PSI always posts announcements of new service offerings there, and NEARnet will as well. Must get back to work; we have air raid drills scheduled for 2pm this afternoon and my anti-aircraft gun needs greasing. I'll radio in future reports so long as my lines to Princeton aren't cut. --Kent England, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052918414600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 11:49:45 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13956; Tue, 29 May 90 11:47:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 18:41:46 GMT From: ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Organization: Secular Humanists for No-Code Subject: Re: What is the IAB? Message-Id: <23691@bellcore.bellcore.com> References: <9005291315.AA01112@vax.ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have to agree with Stev Knowles. The IAB/IETF is the *only* standards body that actually seems to work. I've never seen an important technical decision made by anyone other than the members of the working group in charge of a given topic, and anyone with a technical interest is free to join and contribute. Perhaps the most important thing about the IAB is its "fly before buy" policy. For a protocol to reach internet standard status, it must first be implemented and widely used, and there must be a substantial body of operational experience. If only other standards organizations could follow this principle the world would be a far better place. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052918422500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 12:19:46 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA15043; Tue, 29 May 90 12:04:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 18:42:25 GMT From: usc!cs.utexas.edu!uwm.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu@ucsd.edu (Rusty Smith, MACC) Organization: University of Wisconsin Academic Computing Center Subject: Re: When is an ethernet full? Message-Id: <3718@dogie.macc.wisc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1141@cica.cica.indiana.edu>, ssw@cica.cica.indiana.edu (Steve Wallace) writes... > >When is an ethernet full? We have a campus backbone composed of a >chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over >broadband (buffered repeaters). The UB and chipcom networks are bridged >to form one logical networks. According to our Network General sniffer, >we constantly maintain about 10-15 percent utilization or (300 - 1000 >packets per second). How much more traffic can this network support >before performance falls off measurably? Any ideas? > We have a similar setup here. There are about 50 Chipcom's connected to our broadband backbone. All but 3 are coupled to DEC Lanbridges to keep local traffic local. We have had similar 1 minute averages and peaks of 3-4 times as much. As far as we can tell everyone is satisfied with the performance with these numbers. We have had other performance problems not caused by traffic volume. Rusty Smith Internet: rsmith@vms.macc.wisc.edu MACC Data Communications Bitnet: rsmith@wiscmacc (608) 263-6307 Univ. of Wisconsin @ Madison ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052919112500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 14:50:23 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25726; Tue, 29 May 90 14:49:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 19:11:25 GMT From: shelby!portia.stanford.edu!jessica.stanford.edu!morgan@eos.arc.nasa.gov (RL "Bob" Morgan) Organization: Academic Information Resources Subject: Re: Dial up access to Internet facilities Message-Id: <1990May29.191125.9800@portia.Stanford.EDU> References: <1990May25.163528.14300@ameristar>, <9005270423.AA19852@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > Somehow dialup Internet access and SMTP don't go hand and hand in my > mind, my estimate is that your going to have keep a connection open > for about 3 hours every day to have some probablity of synchronizing > with all the SMTP agents pushing mail out of their queues for the > site. Realistically you'll be running uucp/tcp to a site like UUPSI > who is MX'ing for your domain. Indeed, SMTP's assumption that everybody's connected all the time doesn't work well with occasionally-connected hosts. It would seem that the time is ripe for some sort of extension to SMTP to do receiver-initiated transfers to meet this need. Of course you'll still need the MXing host to hold your mail for you. Presumably getting away from uucp is one of the points of all this. Note that POP doesn't make it for the small-business customer. I want my address to be "morgan@mybusiness.com" not "morgan@barrnet.net". I also want to manage my own accounts on my own multi-user system, not ask my provider every time I need a new one. - RL "Bob" Morgan Networking Systems Stanford ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052921282100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 14:50:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24853; Tue, 29 May 90 14:36:57 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 21:28:21 GMT From: aramis.rutgers.edu!athos.rutgers.edu!hedrick@rutgers.edu (Charles Hedrick) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: When is an ethernet full? Message-Id: References: <1141@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >When is an ethernet full? We have a campus backbone composed of a >chipcom 10 Mbs ethernet over broadband and a UB 5 Mbs ethernet over >broadband (buffered repeaters). The UB and chipcom networks are bridged >to form one logical networks. According to our Network General sniffer, >we constantly maintain about 10-15 percent utilization or (300 - 1000 >packets per second). How much more traffic can this network support >before performance falls off measurably? Any ideas? I'd like to see you get data with a bit more time resolution. It's a bit unusual for networks to run at 10-15% all the time, day and night. More typically, there's a long-term variation over the course of a day, with more traffic during the day than night, and short-term variation as people boot machines, transfer big files, or do other things that cause a short-term demand for bandwidth. If you're running at 10% 24 hours a day, this suggests either a very odd mix of users and applications, or that most of your bandwidth is going to broadcast packets produced by rwhod or things of that nature. I have heard of networks with a constant broadcast load of that sort. In that case, replacing some or all of your bridges with routers might be more useful than trying to increase the bandwidth. In general I'd expect a peak to average ratio of about 10 to 1. That is, if you are averaging 10% usage, you are probably using 100% during brief periods. So you're about at capacity. If your 10% is made up mostly of a continuous background of broadcast packets, this might not be the case. But if you've really got that much broadcast traffic, you've got other problems. Like your hosts are all spending significant CPU dealing with it. If your 10% represents the maxima of your peaks, rather than a true average, then you're probably in good shape and still have some room to grow. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005290627.AA00921@ucbvax.Berkeley.EDU] <1990052921450000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: Public domain TCP/IP Software for VAX? Message-ID: <9005290627.AA00921@ucbvax.Berkeley.EDU> Date: 29 May 90 21:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Posted: Tue May 29 22:45:00 1990 Hi, Netlander! Does anybody know whether there is any public domain software TCP/IP for VAX? Please reply to me directly, I will summarize if there is enough interest. p/s: please inlcude the anonymous FTP site if there is - Beng Hang Tay (email: taybengh@nusdiscs) Dept. of Info. Sys. and Comp. Sc. NATIONAL UNIVERSITY OF SINGAPORE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052922121600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 15:26:53 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27225; Tue, 29 May 90 15:12:26 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 22:12:16 GMT From: barmar@think.com (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: Dial up access to Internet facilities Message-Id: <36901@think.Think.COM> References: <1990May25.163528.14300@ameristar>, <9005270423.AA19852@psi.com>, <1990May29.191125.9800@portia.Stanford.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes: >Indeed, SMTP's assumption that everybody's connected all the time >doesn't work well with occasionally-connected hosts. It would seem >that the time is ripe for some sort of extension to SMTP to do >receiver-initiated transfers to meet this need. No extension is needed: see the TURN command. However, most SMTP implementation don't enable this command for security reasons. To make it secure you need a way of authenticating the calling SMTP. One possibility would be to allow it only in cases where the name given in the HELO command corresponds to the address being used by the transport layer; however, not all transport layers make this available (what do you do if SMTP is being done over dialup lines?). >Note that POP doesn't make it for the small-business customer. I want >my address to be "morgan@mybusiness.com" not "morgan@barrnet.net". I >also want to manage my own accounts on my own multi-user system, not >ask my provider every time I need a new one. MX records solve the first problem. However, I'm not sure why you need any of this. What's wrong with the MX'ing host periodically trying to connect to the occasionally-connected hosts? Much of the time it will just time out, but when it succeeds it can forward all the accumulated mail. This is the default behavior, so no extensions are necessary. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990052923361500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 22:51:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24289; Tue, 29 May 90 22:45:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 May 90 23:36:15 GMT From: netcom!hinton@apple.com (Greg Hinton) Organization: NetCom Public Access Unix -- San Jose, CA Subject: What is VMTP? Message-Id: <12637@netcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've read bits & pieces about something called VMTP. From what I've seen, it appears to be a reliable counterpart of UDP. Can someone explain in more depth exactly what VMTP is and/or provide easily available references? Are there any implementations under UNIX? Thanks. -- Greg Hinton DOMAIN: hinton@netcom.uucp UUCP: uunet!apple!netcom!hinton ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053000100900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 17:53:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05594; Tue, 29 May 90 17:22:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 00:10:09 GMT From: intercon!news@uunet.uu.net (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Dial up access to Internet facilities Message-Id: <26630F61.2A9@intercon.com> References: <9005270423.AA19852@psi.com>, <1990May25.163528.14300@ameristar>, <57875@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: > I see a definite interest on the part of commercial organizations > wishing to join the research and education (R&E) Internet, but I see much > less interest from them in joining a purely commercial internet service- > they don't seem to understand who they would be able to talk to on a purely > commercial internet. Come to think of it, neither do I. In our case, at least, one of the reasons that a connection to what you call the R&E Internet would/will be so valuable is that a lot of the people that we want to communicate with are already there. I suspect that the companies that are currently most interested in the Internet fall into one of two categories: 1. Companies whose customer base is largely already on the Internet. TCP/IP vendors, supercomputer vendors, and so on. We fall into this category, for example. 2. Companies that want to reap the benefits of wide-area networking without having to develop their own infrastructure. Some bicoastal computer corporations fall into this category, for example. As the number of companies in category 2 increase, the perceived value of a purely commercial internet will also increase. At some point, also, commercial service providers may increase its value by allowing it to mediate services that the R&E Internet cannot or by policy will not support. -- Amanda Walker -- This posting is cursed. As you read it you will be confuset by ther printeb wertz. Yer intelijen will vabni ..... XRT! XRT! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053001593200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 21:21:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19293; Tue, 29 May 90 21:15:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 01:59:32 GMT From: zaphod.mps.ohio-state.edu!mips!cmic!garvey@tut.cis.ohio-state.edu (Joe Garvey) Organization: Califonia Microwave Inc., Sunnyvale, CA. Subject: tcp/ip services <--> decnet connectivity, help wanted Message-Id: <325@cmic.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need to connect a DEC (decnet) system to an HP unix system. My objective is to make the remote login, and file transfer services work. I can make the required physical connections of the LAN's involved... However, I assume a direct connection won't work. I need some kind of protocol tranlator in the middle. For a number of reasons, each machine must think it's working in its native services (decnet or arpa-berkeley). Can I use a PC and some netware? Does someone make a translator? Can I directly connect the two networks, and put some software package on my HP (9000/370)? It's out of the question to add software to the DEC machines (PDP/RSTS) ;-(. I've got some PC's and terminal servers using the arpa-berkeley tools, what about them? Am I crazy? :-) E-mail response preferred. ... normal stuff about summarizing ... Thanx. -- Joe Garvey UUCP: {apple,backbone}!versatc!mips!cmic!garvey California Microwave Internet: garvey%cmic@mips.com 990 Almanor Ave HP Desk: garvey (cmic@mips.com) /hp1900/ux Sunnyvale, Ca, 94086 800-831-3104 (outside CA) 408-720-6439 (let it ring) 800-824-7814 (inside CA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053002215600> Received: from TWG.COM by NIC.DDN.MIL with TCP; Wed, 30 May 90 09:21:56 PDT Received: from TWG.COM by TWG.COM with SMTP ; Wed, 30 May 90 09:03:01 PST Received: from lefty.twg.com by Obelix.TWG.COM id ab00402; 30 May 90 9:02 PDT From: lefty@obelix.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: Query - Ethernet collisions In-Reply-To: Msg from Bill Daniels dated 29 May 90 15:01:47 GMT Message-ID: <9005300902.ab00402@Obelix.TWG.COM> In <98@fedeva.UUCP>, Bill Daniels writes: > We recently acquired an Exelan LANalyzer. During our first uses of it, > we noticed that about 40% of the packets on one ethernet segment (which > is remotely bridged to another) show up as "Collision detected in preamble". > This segment is not busy necessarily when this happens. The actual number > of collisions reported seems fairly constant even as traffic picks up. On > a very quiet net (~ 2 packets / sec.) I see about 20 errors over ~ 30 secs. > When the segment is a little more active (~ 1000 packets / sec.) the error > rate is just about the same. > > I have tried disconnecting the devices that the errors are associated with > but the collisions just move to the packets associated with other devices. > > Any clues? My immediate guess would be a marginal terminator somewhere... |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>| | David N. Schlesinger || "When I have nothing to say, | | The Wollongong Group || my lips are sealed; | | Internet: Lefty@twg.com || say something once, | | POTS: 415/962-7219 || why say it again?" -- David Byrne | |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>| ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053002252400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 19:35:55 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA13357; Tue, 29 May 90 19:29:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 02:25:24 GMT From: zaphod.mps.ohio-state.edu!samsung!sol.ctr.columbia.edu!cica!ssw@tut.cis.ohio-state.edu (Steve Wallace) Organization: Center for Innov. Comp. Appl., Bloomington, IN Subject: Re: When is an ethernet full? Message-Id: References: <1141@cica.cica.indiana.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A little more info. We have about 45 IP subnets all behind cisco routers. We route appletalk phase I, DECnet, and bridge IPX. Between the hours of 9am to 5pm we see a pretty steady 10 - 15 percent load. Sometimes this drops to 2 percent but only for very brief periods. Steven Wallace wallaces@ucs.indiana.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053002354900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 29 May 90 21:21:04 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA19268; Tue, 29 May 90 21:14:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 02:35:49 GMT From: sumax!ctsx!dms@beaver.cs.washington.edu (Dave Stanhope) Organization: Cellular Technical Services, Seattle, WA Subject: Internet access Message-Id: <167@ctsx.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Is it possible (assuming correct usage) to get access to the Internet via the commercial X25 networks (Telenet and/or Tymnet). The connection would use TCP/IP over X25. Any comments would be appreciated! Reply to: ..!uwbeaver!sumax!ctsx!dms Thanks, Dave S. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053003050000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 28 May 90 22:41:35 PDT Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5832; Tue, 29 May 90 01:41:26 EDT Date: Tue, 29 May 90 13:45 H From: Subject: Public domain TCP/IP Software for VAX? To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, TAYBENGH Hi, Netlander! Does anybody know whether there is any public domain software TCP/IP for VAX? Please reply to me directly, I will summarize if there is enough interest. p/s: please inlcude the anonymous FTP site if there is - Beng Hang Tay (email: taybengh@nusdiscs) Dept. of Info. Sys. and Comp. Sc. NATIONAL UNIVERSITY OF SINGAPORE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053003132900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 30 May 90 10:13:08 PDT Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 30 May 90 10:13:15 -0700 Date: Wed, 30 May 90 10:13:29 PDT From: postel@venera.isi.edu Posted-Date: Wed, 30 May 90 10:13:29 PDT Message-Id: <9005301713.AA04813@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Wed, 30 May 90 10:13:29 PDT To: netcom!hinton@apple.com Subject: Re: What is VMTP? Cc: tcp-ip@nic.ddn.mil Hi. See RFC-1045 and the papers by Cheriton in various places (e.g., Sigcomm conference proceedings). --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053003570000> Received: from nusc-npt.navy.mil by NIC.DDN.MIL with TCP; Wed, 30 May 90 04:59:22 PDT Date: 30 May 90 07:57:00 EDT From: "VAXB::DBURKE" Subject: LanTastic NOS and TCP/IP To: "tcp-ip" Date sent: 30-MAY-1990 07:56:35 Hi, Does anyone know/have/hear of a gateway from Lantastic to TCP/IP? 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) || // ||_____|| ================================================================================ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053005293800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 04:37:24 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09833; Wed, 30 May 90 04:28:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 05:29:38 GMT From: nsc!pyramid!athertn!joshua@decwrl.dec.com (Flame Bait) Organization: Atherton Technology, Sunnyvale, CA Subject: Looking For Commercial RPC Protocols Message-Id: <24581@joshua.athertn.Atherton.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil About a year and a half ago I wrote a paper comparing RPC protocols from Sun, Apollo, and Netwise. I'm now updating and expanding this paper, since there have been many changes to all of those RPC systems over the last year and a half. I'm looking for other commercial RPC protocols to compare. If you know of a such a product, please send me the companies address, phone, and email. By commercial, I mean widely available and supported. I may include non commercial RPCs if they are especially interesting or important. RPC = Remote Procedure Call Joshua Levy -------- Quote: "If you haven't ported your program, it's not Addresses: a portable program. No exceptions." joshua@atherton.com {decwrl|sun|coherent}!athertn!joshua work:(408)734-9822 home:(415)968-3718 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053007162200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 11:09:41 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06607; Wed, 30 May 90 11:02:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 07:16:22 GMT From: eru!luth!sunic!mcsun!ub4b!syteke!jim@BLOOM-BEACON.MIT.EDU (Jim Sanchez) Organization: Hughes LAN Systems, Inc - European Support Office Subject: Re: When is an ethernet full? Message-Id: <1109@syteke.be> References: <1141@cica.cica.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil One thing you want to be SURE and remember is that the ethernet on broadband stuff has a significant distance limitation. If your campus cable system is a as large as I suspect, then the 10broad36 channel is probably working more as csma than csma/cd and the effective channel capacity is ~2 Mb not 10 Mb. That is why we use 802.4 for backbone applications it also uses much less bandwidth. The UB stuff is also just CSMA (if my memory serves me). In both cases, the effective channel capacity is approximately 35% of the data rate. If you calculate the maximum number of packets on an 802.3 channel it is about 13,000 and scale accordingly I don't think you are overloaded based on your numbers. However, this is a tricky thing to find out. -- Jim Sanchez | jim@syteke.be (PREFERRED) | OR {sun,hplabs}!sytek!syteke!jim Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim Brussels -- Jim Sanchez | jim@syteke.be (PREFERRED) | OR {sun,hplabs}!sytek!syteke!jim Hughes LAN Systems | OR uunet!mcsun!ub4b!syteke!jim Brussels ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053010120000> Received: from Pescadero.Stanford.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 17:13:31 PDT Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA14036; Wed, 30 May 90 17:13:11 PDT Date: 30 May 1990 17:12-PDT From: Steve Deering Subject: Re: What is VMTP? To: netcom!hinton@apple.com (Greg Hinton) Cc: tcp-ip@nic.ddn.mil Message-Id: <90/05/30 1712.019@pescadero.stanford.edu> In-Reply-To: netcom!hinton's message of 29 May 90 233615 GMT > I've read bits & pieces about something called VMTP. From what I've seen, > it appears to be a reliable counterpart of UDP. > Can someone explain in more depth exactly what VMTP is and/or provide > easily available references? VMTP is a transport-layer protocol that provides a reliable request/response or RPC style of service, rather than the reliable stream service of TCP or the unreliable datagram service of UDP. As others have pointed out, it has been described in several papers by David Cheriton of Stanford; the protocol specification can be found in RFC-1045. > Are there any implementations under UNIX? Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix) that may be obtained by anonymous FTP from host gregorio.stanford.edu, in the vmtp-ip directory. The software is free but covered by a Stanford license agreement, which can be found in the file vmtp.LICENSE in that directory. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053011084000> Received: from psi.com ([192.67.6.2]) by NIC.DDN.MIL with TCP; Wed, 30 May 90 15:26:05 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA02245; Wed, 30 May 90 17:48:40 -0400 Message-Id: <9005302148.AA02245@psi.com> To: jbloom@uhasun.hartford.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-Reply-To: Your message of 30 May 90 13:20:11 +0000. <118@ultrix.uhasun.hartford.edu> Date: Wed, 30 May 90 17:48:40 -0400 From: "Martin Lee Schoffstall" Jon, I think the counter argument is that if it doesn't work reliably/well especially in the beginning then people won't rely on it to provide communications for their everyday needs. If they don't use it everyday then it is luxury suitable for axing at the appropriate belt-tightening time. Marty --------------- > Speaking as one who is trying to figure out how to convince management that > $10k/yr would be well spent, I would be willing to accept service limitations > for a lower-cost net access. If the service truly is as useful to the > organization as I believe it would be, the demonstration of that usefulness > might just break loose the dollars for a higher quality ($10K) connection. So > providing low-cost, restricted service connections may well have the effect > of enhancing the number of sites getting full-service connections eventually. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053011341900> Received: from vax.ftp.com by NIC.DDN.MIL with TCP; Wed, 30 May 90 12:38:47 PDT Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA16351; Wed, 30 May 90 15:34:19 EDT Date: Wed, 30 May 90 15:34:19 EDT Message-Id: <9005301934.AA16351@vax.ftp.com> To: "Martin Lee Schoffstall" Subject: Re: What is the IAB? From: stev@vax.ftp.com Cc: tcp-ip@nic.ddn.mil, ka9q.bellcore.com!karn@bellcore.com (Phil Karn) Sender: stev@vax.ftp.com Repository: ftp.com Originating-Client: d-cell.ftp.com >CMOT was elevated to DIS without the above. >Marty after the abuse they got, i *doubt* that will ever happen again. i never said it was perfect. they *do* do some stupid things. but, then again, so do i . . . . . . ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9005301322.AA17657@ucbvax.Berkeley.EDU] <1990053011570000> From: dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE") Newsgroups: comp.protocols.tcp-ip Subject: LanTastic NOS and TCP/IP Message-ID: <9005301322.AA17657@ucbvax.Berkeley.EDU> Date: 30 May 90 11:57:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Posted: Wed May 30 12:57:00 1990 Date sent: 30-MAY-1990 07:56:35 Hi, Does anyone know/have/hear of a gateway from Lantastic to TCP/IP? 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) || // ||_____|| ================================================================================ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053012204400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 05:38:00 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA14192; Wed, 30 May 90 05:25:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 12:20:44 GMT From: mailrus!bbn.com!craig@uunet.uu.net (Craig Partridge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Subject: Re: Dial up access to Internet facilities Message-Id: <56756@bbn.BBN.COM> References: <1990May25.163528.14300@ameristar>, <9005270423.AA19852@psi.com>, <1990May29.191125.9800@portia.Stanford.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes: > >Indeed, SMTP's assumption that everybody's connected all the time >doesn't work well with occasionally-connected hosts. It would seem >that the time is ripe for some sort of extension to SMTP to do >receiver-initiated transfers to meet this need. Of course you'll >still need the MXing host to hold your mail for you. Presumably >getting away from uucp is one of the points of all this. CSNET did this some time ago with MMDF2b. Some of the dial-up sites run a script every night which brings up the dial-up line, and then opens a connection to a port on relay.cs.net and tells it to start delivering mail to the site. The application at that connection starts up the appropriate MMDF channel (mmdf can have multiple SMTP delivery channels, where a channel typically has messages destined for a particular site), which delivers the mail to the site. [Note there's no security problem here -- anyone can start up the channel, but the channel will only deliver to the proper remote system(s)] Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053012235800> Received: from psi.com by NIC.DDN.MIL with TCP; Wed, 30 May 90 16:08:36 PDT Date: Wed, 30 May 90 19:03:58 -0400 From: schoff@psi.com (Marty Schoffstall) Received: by psi.com (5.61/2.1-Performance Systems International) id AA02833; Wed, 30 May 90 19:03:58 -0400 Message-Id: <9005302303.AA02833@psi.com> To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: new mailing list of Commercial Internetworking Issues A new mailing list has been created: comint@psi.com (to post, and respond) comint-request@psi.com (to be added) To discuss commercial aspects of participation in the Internet. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053013201100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 07:22:49 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA21490; Wed, 30 May 90 07:18:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 13:20:11 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@ucsd.edu (Jon Bloom) Subject: Re: Dial up access to Internet facilities Message-Id: <118@ultrix.uhasun.hartford.edu> References: <9005270423.AA19852@psi.com>, <1990May25.163528.14300@ameristar>, <57875@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: > > NEARnet is committed to broadening its base of support to include > smaller sites at lower cost. We are chafing against technical issues in > being able to offer high quality service at lower costs, since we balance > hardware and people costs, and people costs are not really that bandwidth > sensitive. We also have strict standards on quality of service, and we > do not wish to compromise these standards in offering less costly access, > since we know that later on our customers would regret the compromise as > much as we. Then there is the issue of just what is part-time access; > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have > to keep in mind what services we provide and we have to make sure that > our clients understand what they can and can't do with new service offerings. > Speaking as one who is trying to figure out how to convince management that $10k/yr would be well spent, I would be willing to accept service limitations for a lower-cost net access. If the service truly is as useful to the organization as I believe it would be, the demonstration of that usefulness might just break loose the dollars for a higher quality ($10K) connection. So providing low-cost, restricted service connections may well have the effect of enhancing the number of sites getting full-service connections eventually. Jon -- Jon Bloom, KE3Z -- jbloom@uhasun.hartford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053015474200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 09:53:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA00846; Wed, 30 May 90 09:37:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 15:47:42 GMT From: fernwood!hercules!dirt.cisco.com!kph@uunet.uu.net (Kevin Paul Herbert) Organization: cisco Systems Subject: Re: tcp/ip services <--> decnet connectivity, help wanted Message-Id: <18409@hercules.csl.sri.com> References: <325@cmic.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The easiest thing to do would be to get a DECstation 3100 (or something else running Ultrix) and use the DECnet-Internet gateway software. I don't know many product specifics, but I know that you can use it for remote login and file transfer. You should also be running at least DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems dealing with Ultrix, if I recall correctly. I've always thought it would be *fun* to put up TCP/IP on RSTS, though. It really wouldn't be that hard to do for someone that was good with RSTS monitor internals. Kevin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053016354400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 09:53:39 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01239; Wed, 30 May 90 09:44:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 16:35:44 GMT From: kmeyer@decwrl.dec.com (Kraig Meyer) Organization: DEC Western Research Lab Subject: Re: What is VMTP? Message-Id: <4592@bacchus.dec.com> References: <12637@netcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12637@netcom.UUCP> hinton@netcom.UUCP (Greg Hinton) writes: ||I've read bits & pieces about something called VMTP. From what I've seen, ||it appears to be a reliable counterpart of UDP. ||Can someone explain in more depth exactly what VMTP is and/or provide ||easily available references? ||Are there any implementations under UNIX? VMTP was developed as a transport protocol for the V distributed system at Stanford. Try "VMTP as the Transport Layer for High-Performance Distributed Systems" by David Cheriton and Carey Williamson, IEEE Communications Magazine, June 1989, p. 37. **************************************************** Kraig Meyer kraig@wrl.dec.com On parole from the University of Southern California My views do not necessarily represent those of DEC. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053016361900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 10:52:32 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05455; Wed, 30 May 90 10:46:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 16:36:19 GMT From: intercon!news@uunet.uu.net (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: What is the IAB? Message-Id: <2663F684.917@intercon.com> References: <23691@bellcore.bellcore.com>, <9005300234.AA07597@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes: > CMOT was elevated to DIS without the above. It was my understanding that this was done by the ISO, not the IAB. The IAB has no authority to designate things DIS or IS. -- Amanda Walker InterCon Systems Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053016422900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 15:10:27 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA22188; Wed, 30 May 90 15:03:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 16:42:29 GMT From: frooz!cfa250!cliff@husc6.harvard.edu (Cliff Stoll) Organization: Harvard/Smithsonian Center for Astrophysics Subject: Re: A SUSPICIOUS SECURE GATEWAY Message-Id: <1919@cfa253.cfa250.harvard.edu> References: <1990May27.012550.14745@utzoo.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From henry@utzoo.uucp (Henry Spencer): > they can't make a Unix that they can trust when it is > administered by incompetents. Nobody else can make such a system either. I second that! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053017113000> Received: from psi.com by NIC.DDN.MIL with TCP; Wed, 30 May 90 20:54:27 PDT Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA04517; Wed, 30 May 90 23:51:31 -0400 Message-Id: <9005310351.AA04517@psi.com> To: intercon!news@uunet.uu.net (Amanda Walker) Cc: tcp-ip@nic.ddn.mil Subject: Re: What is the IAB? In-Reply-To: Your message of 30 May 90 16:36:19 +0000. <2663F684.917@intercon.com> Date: Wed, 30 May 90 23:51:30 -0400 From: "Martin Lee Schoffstall" > It was my understanding that this was done by the ISO, not the IAB. The > IAB has no authority to designate things DIS or IS. No, the "Internet" has a somewhat parallel concept with Draft Internet Standards (DIS) Internet Standards (IS) Which is outlined in one of the RFC's, the process of standardization is somewhat obscure. Marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053017144700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 10:22:50 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA03484; Wed, 30 May 90 10:16:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 17:14:47 GMT From: bu.edu!bu-it!kwe@eddie.mit.edu (Kent England) Organization: Boston University Subject: Re: Dial up access to Internet facilities Message-Id: <57952@bu.edu.bu.edu> References: <9005270423.AA19852@psi.com>, <1990May25.163528.14300@ameristar>, <57875@bu.edu.bu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu (Jon Bloom) writes: > In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: > > We also have strict standards on quality of service, and we > > do not wish to compromise these standards in offering less costly access, ... > > > Speaking as one who is trying to figure out how to convince management that > $10k/yr would be well spent, I would be willing to accept service limitations > for a lower-cost net access. If the service truly is as useful to the > organization as I believe it would be, the demonstration of that usefulness > might just break loose the dollars for a higher quality ($10K) connection. So > providing low-cost, restricted service connections may well have the effect > of enhancing the number of sites getting full-service connections eventually. > We hear you. Let me elaborate on some of the costs hidden in a NEARnet service fee. Consider these representative of a mid-level network service provider. I certainly don't mean this as an advertisement, but as explanation of the costs of internetworking. It might be helpful for someone starting from a UUCP or BITnet point of view. Cost of the router on your end. NEARnet requires that the demarcation point be on the local LAN and not somewhere on the leased line. In other words, NEARnet has to own and control the router at your site. You have to pay for that. But this has proved critical to achieving service objectives. Cost of the router on our end. It takes a lot of hardware to make the NEARnet core work and provide access to NSFnet and other services. Leased line charges. Leased lines are expensive and difficult to move and change. Fractional T1 is helping that a little, but still, we are in large part unable to provide distance-insensitive fees, and some of our clients pay large fees because of geography. Depreciation. What does your service provider do for you when your router is obsolete and can no longer function in an Internet? Do they make you pay for a new one? NEARnet builds depreciation into its fee schedules, so you pay for the cost of hardware and software continually, and not in a lump sum, or worse, never. Depreciation is critically important to a network service provider being able to keep up with the technology. People costs. It is very expensive in man-hours to run a mid-level network, but we have found that it does not pay to scrimp on people. I think new network management tools will help, particularly as we gain control of the wide area network, but it is still an expense that we feel is justified to provide a sufficiently high level of service. NOCs should be 24 hours a day, seven days a week, and that will never be cheap. User services. We have found it absolutely critical to be able to offer some minimal user services to our members. This is extremely important to some of our clients. Some of these services are things like name servers for their domains and help with registration and connected-status. But it also includes a committment from NEARnet to take responsibility for tracking down, identifying, and, to the extent possible, fixing users' connectivity problems, no matter where in the Internet the problem is lurking. This is a service available to anyone, anywhere. Finger @nic.near.net for details. It also includes Dan Long's time and effort in the IETF in the User Connectivity Problems Working Group to try to spread this capability and commitment throughout the Internet. All this adds up to quite a chunk of change. Makes UUCP look pretty good, eh? :-) I understand, though, that money is money and it still costs too much. I believe the NSF is sympathetic, as they are still considering proposals for grants to connect qualified sites to the Internet. You may be able to turn to the NSF for grant aid. It's all part of the Internet growing up, running like a business, going private, etc. And NEARnet is not the only mid-level network service provider working these issues. More and more operational people are getting into the IETF and there is the Federation of American Research Networks which is populated by the mid-level networks, among others, and is working on these sorts of issues. --Kent England ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053018071600> Received: from central.cis.upenn.edu by NIC.DDN.MIL with TCP; Wed, 30 May 90 19:07:42 PDT Received: from PCPOND.CIS.UPENN.EDU by central.cis.upenn.edu id AA26416; Wed, 30 May 90 22:07:24 -0400 Return-Path: Received: by pcpond.cis.upenn.edu id AA00792; Wed, 30 May 90 22:07:16 EDT Date: Wed, 30 May 90 22:07:16 EDT From: farber@pcpond.cis.upenn.edu (David J. Farber) Posted-Date: Wed, 30 May 90 22:07:16 EDT Message-Id: <9005310207.AA00792@pcpond.cis.upenn.edu> To: stev@vax.ftp.com Cc: tcp-ip@nic.ddn.mil In reply to: Date: Wed, 30 May 90 15:34:19 -0400Subject: Re: What is the IAB? From: stev@vax.ftp.com To: "Martin Lee Schoffstall" cc: tcp-ip@nic.ddn.mil, karn@ka9q.bellcore.com (Phil Karn) >CMOT was elevated to DIS without the above. >Marty after the abuse they got, i *doubt* that will ever happen again. ..... ============================================ If it was the wrong thing, then why haven't they rescinded the CMOT status? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053019120000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 14:09:10 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17906; Wed, 30 May 90 13:53:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 19:12:00 GMT From: att!cbnewsh!eric@ucbvax.Berkeley.EDU (eric.l.asbeck) Organization: AT&T Bell Laboratories Subject: IBM 5250 support on TCP/IP Message-Id: <1990May30.191200.25165@cbnewsh.att.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I want to connect a TCP/IP workstation and 5250-based applications on an AS/400. 5250 is the default or native data stream supported on the IBM AS/400 and the IBM S/3x (as opposed to the 3270 data stream used for MVS and VM systems). The workstation is on Ethernet and runs HP-UX, which is compatible with UNIX System 5.2 and BSD 4.2. The AS/400 is on a Token Ring and I know how to bridge the Token Ring to the Ethernet. Based on what I've learned so far, one of the following might work if I can find the necessary components: 1) "TN 5250" extensions to Telnet. I know that RFC 1041 defines a Telnet 3270 Regime Option which supports the 3270 data stream within the Telnet protocol. I've not been able to find a similar regime option for the 5250 protocol stream. I also understand that IBM does not presently include Telnet as part of its TCP/IP support on the AS/400, but that they have made a Statement of Direction for it. 2) An X-Windows 5250 emulation package for the workstation which can talk directly to the AS/400 or go through an intermediary system. I'd prefer a full-blown X application, but I'd consider a character-based application accessed by something like xterm. 3) Support of APPC/LU6.2 on HP-UX over the workstation's Ethernet interface. Ideally this would include support for the 5250 data stream under LU6.2, but I'd be happy just to find a vendor that provides the LU6.2 support. Any pointers or suggestions would be greatly appreciated. I don't regularly subscribe to this newsgroup, so I'd appreciate your replying directly to me via email at the address given below. Thanks in advance! Eric Asbeck AT&T Bell Labs ela@homxb.att.com or att!homxb!ela ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053020054100> Received: from SPARK.BRL.MIL by NIC.DDN.MIL with TCP; Wed, 30 May 90 21:08:03 PDT Date: Thu, 31 May 90 0:05:41 EDT From: "Robert J. Reschly Jr." To: tcp-ip@nic.ddn.mil Subject: Namespace clashes (was: What is the IAB?) Message-ID: <9005310005.aa26406@SPARK.BRL.MIL> Good evening, A quick point worth noting. I read Marty's note about CMOT being advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet Standard status". I later read Amanda's note about Draft International Standards under the same thread; again nodding in agreement. Only when I read the next followup (again referring to Draft Internet Standards) did I tumble -- namespace clash. I would propose PINS, DINS and INS where 'IN' comes from "InterNet" but fear that is still to close to ISOese. Maybe PIPS, DIPS, and IPS with 'IP' coming from "Internet Protocol". By tucking in the extra word, the likelyhood of these acronyms being collapsed back to TLAs (Three Letter Acronyms) is reduced. Later, Bob -------- IP: reschly@BRL.MIL UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. / Networking & Systems Dev. Team / ATTN: SLCBR-SE-A (Reschly) / Aberdeen Proving Grounds, MD 21005-5066 / (301)278-6808 AV: 298-6808 **** For a good time, call: (303) 499-7111. Seriously! **** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053022230000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 16:10:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA25435; Wed, 30 May 90 15:52:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 22:23:00 GMT From: mogul@decwrl.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: When is an ethernet full? Message-Id: <4597@bacchus.dec.com> References: <1141@cica.cica.indiana.edu>, <56724@bbn.BBN.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil When is an ethernet full? .... According to our Network General sniffer, we constantly maintain about 10-15 percent utilization or (300 - 1000 packets per second). How much more traffic can this network support before performance falls off measurably? Any ideas? The best place I know of to start answering this question is Boggs, Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The gist of that article is that you can drive the Ethernet all the way to its rated capacity assuming you are careful in the way you lay out your network, and all your systems have good Ethernet hardware. Thanks for the plug, Craig ... but I think you have misconstrued our results, at least in trying to apply them to the question at hand. True, "you can drive the Ethernet all the way to its rated capacity" (well, at least 95% of the way) if what you are trying to do is to make full use of the bandwidth. This is NOT the same thing as saying that you will have a useful network if the average load is 95%. In fact, as I found out last night (while running some TCP benchmarks on our lab's main Ether) if you use 90%+ of the network between one set of hosts, other hosts are going to suffer badly. The reason is queueing delay. Think of an arbitrary host with a stream of packets it wants to send. If the load on the network is 100%, then its output queue will grow forever and the effective delay will become infinite. Actually, I think you can show that the asymptote for infinite delay happens at a load below 100%, for any finite inter-arrival time for new packets. What then is the "right" level at which to declare an Ethernet "full"? That depends. If you are running a real-time application that can never accept a delay > 1.2 milliseconds, then you may not be able to use an Ethernet at all. If you are only using the net to carry non-interactive traffic (like electronic mail) then you might get away with an average load above 90%. In the usual "NFS+xterm+other stuff" kind of environment that we run, I've seen 5-second load averages above 50% without hearing users complain, although I would probably complain myself if the load stayed this high all the time. If your average load (calculated over one-second intervals, as is the usual practice) is only 15%, then you are probably not going to notice any problems. The point of our paper is not that you should run your net at 50% (or 70% or 90%) utilization; we even said ``Don't try this at home.'' The point is that an Ethernet is no worse when carrying high loads than other 10Mbit/sec multi-access LANs. In practice of course, many of the systems won't have good Ethernet hardware (for example, Jacobson's talk at SIGCOMM '88 indicated he'd found an Ethernet chipset that could only go about 6 Mbits/sec). So you need to find some people out there with some good practical experience about when some of their systems start breaking down, to figure out when your network will die due to poor hardware/software. In general, even the hosts with the full-speed ethernet interfaces won't be using them at full speed (because most protocols are flow-controlled at some level, and the ultimate data sources and sinks seldom run at 10Mbits/sec.) If you are worried about worst-case scenarios, such as somebody like David Boggs or myself running network benchmarks on your net, then you might want to pay attention to the capabilities of your host interfaces. But in most cases, your network load comes from a composite of many slower sources, and what matters is how many hosts you have and what fraction of them are going to be active at once. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053022254400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 03:22:51 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA04188; Thu, 31 May 90 03:12:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 May 90 22:25:44 GMT From: cs.utexas.edu!texbell!moxie!hack@tut.cis.ohio-state.edu (Greg Hackney) Organization: Home Subject: Re: NFS for NCR TOWER Message-Id: <2696@moxie.lonestar.org> References: <1332@telsys.aut.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1332@telsys.aut.UUCP> ruef@aut.UUCP (Bernhard Ruef) writes: > >Does anybody know about the availability of NFS for a NCR TOWER 32/[46]X0 >running System V.3 (Release 3.00.01 in NCR speak) ? >Bernhard D. Ruef Ascom Autelca AG CH-3073 Guemligen/Switzerland >E-mail: ruef@aut.UUCP FAX: +41 31 527 745 Voice mail: +41 31 529 602 I'm curious too. A friend at Cornell said he seemed to recollect a PD version of NFS than ran outside the kernel. -- Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [90.05.30.1712.019@pescadero.stanford.edu] <1990053100120000> From: deering@PESCADERO.STANFORD.EDU (Steve Deering) Newsgroups: comp.protocols.tcp-ip Subject: Re: What is VMTP? Message-ID: <90.05.30.1712.019@pescadero.stanford.edu> Date: 31 May 90 00:12:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Posted: Thu May 31 01:12:00 1990 > I've read bits & pieces about something called VMTP. From what I've seen, > it appears to be a reliable counterpart of UDP. > Can someone explain in more depth exactly what VMTP is and/or provide > easily available references? VMTP is a transport-layer protocol that provides a reliable request/response or RPC style of service, rather than the reliable stream service of TCP or the unreliable datagram service of UDP. As others have pointed out, it has been described in several papers by David Cheriton of Stanford; the protocol specification can be found in RFC-1045. > Are there any implementations under UNIX? Yes, there is an implementation for 4.3BSD and derivitives (SunOS, Ultrix) that may be obtained by anonymous FTP from host gregorio.stanford.edu, in the vmtp-ip directory. The software is free but covered by a Stanford license agreement, which can be found in the file vmtp.LICENSE in that directory. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13040@ulysses.att.com] <1990053101074800> From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dial up access to Internet facilities Message-ID: <13040@ulysses.att.com> Date: 31 May 90 01:07:48 GMT References: <1990May25.163528.14300@ameristar> <9005270423.AA19852@psi.com> <56756@bbn.BBN.COM> Sender: netnews@ulysses.att.com Lines: 3 Posted: Thu May 31 02:07:48 1990 There's no reason, of course, why the dial-up hub can't call out. As long as the time to complete the call (including login) is less than 30 seconds or so, most TCPs won't care (too much). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053101255000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 07:08:11 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA17512; Thu, 31 May 90 06:57:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 01:25:50 GMT From: zaphod.mps.ohio-state.edu!mips!prls!pyramid!infmx!aland@tut.cis.ohio-state.edu (Colonel Panic) Organization: INFORMIX Professional Services ("Peace thru Normalization") Subject: Re: Re. Wollongong TCP/IP Message-Id: <4360@infmx.UUCP> References: <9005182006.AA00073@dragon.twg.com>, <3362@auspex.auspex.com>, <539@secola.Columbia.NCR.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <539@secola.Columbia.NCR.COM> syackey@secola.UUCP (steve yackey) writes: >>So AT&T threw out the Lachman-based one they supply standard with S5R4 >>and supply a Woolongong-based release instead? > >no, when you buy 5.4 you get lachman tcp. >when you buy a 6386, you get wollongong. for the 6386 at&t "upgraded" the tcp. Uh, the 6386 definitely does not come with WIN/TCP automatically. It is an *option*, as is the Interlan solution. You can get either WIN/TCP 3.0 for StarLAN cards or a Racal Interlan s/w-card combo. Note that AT&T's version of WIN/TCP is still 3.0. Wollongong sells 3.1 themselves as the current release, and they include drivers for a number of common ethernet cards (AT&T strips those out). On my 6386s, I'm running Wollongong's own 3.1 version on WD cards because I have to use interrupt 2 (=9), and WIN/TCP 3.0 doesn't handle that interrupt properly... -- Alan Denney # Informix # aland@informix.com # {pyramid|uunet}!infmx!aland "These tests will have no effect on your grades. They will merely determine your future social status and financial success, if any." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053101404100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 19:08:17 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA06924; Wed, 30 May 90 19:00:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 01:40:41 GMT From: cs.umn.edu!wsmith@ub.d.umn.edu (Warren Smith [Randy]) Organization: University of Minnesota, Minneapolis - CSCI Dept. Subject: Re: When is an ethernet full? Message-Id: <1990May31.014041.13251@cs.umn.edu> References: <1141@cica.cica.indiana.edu>, <56724@bbn.BBN.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <56724@bbn.BBN.COM> craig@ws6.nnsc.nsf.net.BBN.COM (Craig Partridge) writes: >> When is an ethernet full? .... > >The best place I know of to start answering this question is Boggs, >Mogul and Kent's article in Proc. of SIGCOMM '88 pp. 222-233. The >gist of that article is that you can drive the Ethernet all the way >to its rated capacity assuming you are careful in the way you lay out >your network, and all your systems have good Ethernet hardware. > .... > >Craig One thing to remember - while Boggs, Mogul and Kent's article shows that the Ethernet will run right up to saturation (~95% depending on packet size and number of stations), it does not fully address the matter of delay. Delay increases as your Ethernet becomes more heavily loaded. BMK's measurement of delay does not include measurement of queueing delays, and thus underestimates the real delays that will be seen by many hosts (and users) on your network. I have seen real Ethernets running more than 40% load (averaged over 1 hour!, bursts up in the 80-95% range). Most of those nets aren't around any more - they've been split to improve performance. These networks were (and are) growing, so they would have had to split at some point anyway. When you should split depends on what the needs are for your network, and what the growth rate is. -Randy -- Randy Smith wsmith@umn-cs.cs.umn.edu ...!rutgers!umn-cs!wsmith ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053102524400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 30 May 90 20:07:33 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA10282; Wed, 30 May 90 19:58:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 02:52:44 GMT From: deimos.cis.ksu.edu!dino!cs.iastate.edu!hascall@uunet.uu.net (John Hascall) Organization: Iowa State University Computation Center Subject: Trying to write a bootp client for Ultrix Message-Id: <1758@dino.cs.iastate.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am working on a bootp client which I hope to use as follows (in /etc/rc.local): ifconfig `bootp-client` The aim of the program is to produce a string like the following: se0 129.186.1.62 netmask 255.255.255.0 broadcast 129.186.1.255 The client program creates a datagram socket, but when it attempts to bind (to addr=INADDR_ANY, port=BOOTP) it fails unless I preceed the bind with a SIOCSIFADDR (set address) ioctl call%. Herein lies the problem: the whole reason for this program is to discover the address! If I just stick in a bogus address (say 129.186.0.0) I get the bootp request sent fine, but I don't receive the reply. I have tried all sorts of things but none have worked... ...does any one have any ideas on how to make this work? Thanks again, John Hascall hascall@atanasoff.cs.iastate.edu % according to man side effect of SIOCSIFADDR is to initialize the interface ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053104552800> Received: from mbunix.mitre.org by NIC.DDN.MIL with TCP; Thu, 31 May 90 05:51:54 PDT Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: from localhost by ulana.mitre.org (4.1/SMI-4.0-MHS-6.0) id AA25004; Thu, 31 May 90 08:55:31 EDT Message-Id: <9005311255.AA25004@ulana.mitre.org> To: tcp-ip@nic.ddn.mil Subject: Re-posting of question on National Voluntary Lab Program Date: Thu, 31 May 90 08:55:28 EDT From: Frank J. Robey I posted this question several weeks ago and never received any replies so I'll assume that there has been no interest in having products undergo this testing. Haven't any of you that sell products to the Government been asked to certify your products?? >I was wondering if anyone has had any experience with the NVLAP Testing? If >so, how much work was involved in preparing your component for testing, what >the results were and how accurate you felt that the tests were. >Frank J. Robey >The MITRE Corporation >fjr@mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053105020400> Received: from ocdis01.af.mil by NIC.DDN.MIL with TCP; Thu, 31 May 90 11:20:12 PDT Return-Path: Received: by ocdis01.af.mil id AA14512; Thu, 31 May 90 13:22:06 -0500 Message-Id: <9005311822.AA14512@ocdis01.af.mil> Date: Thu May 31 13:22:04 1990 From: robjohn@ocdis01.af.mil (Robert Johnson (CDC Contractor);CDC;) Subject: re: toll restrictors To: tcp-ip@nic.ddn.mil Cc: ath@ptt.lcs.mit.edu Status: N In response to my recent posting about using a software product rather than a toll restrictor to control outbound connectivity, Andrew Heybey writes: > I'm curious as to what you mean by "turn off telnet". Of course, I don't > know what sort of system you're running and what sort of capabilities it > provides, but on a unix system, telnet is a user program that opens a > socket. If you remove the telnet program, all I have to do to get that > capability back is get the source to a telnet program from somewhere and > compile it in my home directory. Voila, I can telnet anywhere I want to. > I can do the same with ftp (in fact, I would write a crude ftp first so as > to be able to go get a better ftp and telnet from someplace else). Does > your system not allow unprivilidged users to open network connections? Are > you relying on nobody knowing how to write/compile/etc their own program to > use the net? Or does your system have some other mechanism for controlling > network access? Good question - nothing's ever as simple as it sounds, is it? By 'turn off', I mean we change permissions so only a trusted group of individuals can use it - not the user population at large. We protect telnet, ftp, cu, tip, and the compilers and debuggers this way. We also have daily reports showing who is using these functions. Rather than digress into a diatribe about system administration, I'll just say that our philosophy is not to deny service to our users, but to be fully accountable. Certain users need to use these compilers, debuggers and communications (other than we have provided by menu access) for valid purposes. We allow them to use them, but they must prove a valid need. And, they know that we regularly monitor these activities. Running the system this way provides full functionality for all users (based on a valid need), and yet maintains full accountability of our connectivity with other systems. Bob Johnson, System Administrator Tinker Air Force Base, Oklahoma ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053106334700> Received: from vax.ftp.com ([128.127.2.100]) by NIC.DDN.MIL with TCP; Thu, 31 May 90 07:34:29 PDT Received: by vax.ftp.com id AA03039; Thu, 31 May 90 10:33:47 EDT Date: Thu, 31 May 90 10:33:47 EDT From: jbvb@vax.ftp.com (James Van Bokkelen) Message-Id: <9005311433.AA03039@vax.ftp.com> To: tcp-ip@nic.ddn.mil Subject: LANWatch dumps of OSI ES-IS, CLNP/TP traffic wanted I asked this on comp.protocols.iso and got no replies... I tested our LANWatch product's OSI parsers at InterOp, but when I got home I discovered that the only CLNP packets I'd saved were an artifact of a router bug, and weren't adequate as examples or for further testing. Any LANWatch owners who have CLNP traffic on their local nets (802.5 or Ether), and would be willing to make me a few dump files, please reply via e-mail. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053107463000> Received: from vax.ftp.com by NIC.DDN.MIL with TCP; Thu, 31 May 90 08:49:25 PDT Received: from stev.d-cell.ftp.com by vax.ftp.com via PCMAIL with DMSP id AA04862; Thu, 31 May 90 11:46:30 EDT Date: Thu, 31 May 90 11:46:30 EDT Message-Id: <9005311546.AA04862@vax.ftp.com> To: intercon!news@uunet.uu.net (Amanda Walker) Subject: Re: What is the IAB? From: stev@vax.ftp.com Cc: tcp-ip@nic.ddn.mil Sender: stev@vax.ftp.com Repository: ftp.com Originating-Client: d-cell.ftp.com >In article <9005300234.AA07597@psi.com>, schoff@PSI.COM ("Martin Lee >Schoffstall") writes: >> CMOT was elevated to DIS without the above. > >It was my understanding that this was done by the ISO, not the IAB. The >IAB has no authority to designate things DIS or IS. > >-- >Amanda Walker >InterCon Systems Corporation marty was refering to Draft Internet Standard, while you are refering to Draft International Standard. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053110031000> Received: from ASNTSU.asn.net by NIC.DDN.MIL with TCP; Thu, 31 May 90 13:04:06 PDT Received: from ASNTSU.asn.net by ASNTSU.asn.net (IBM VM SMTP R1.2.1) with BSMTP id 7975; Thu, 31 May 90 15:03:29 CDT Date: Thu, 31 May 90 15:03:10 CDT From: MAINT@ASNTSU.asn.net To: tcp-ip@nic.ddn.mil In-Reply-To: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU -- 31 May 90 12:45:41 GMT I have only been subscribed to this list for a short time and the discussions seemed to be at a professional level. This looks to me like an unauthorized hacker. Can I assume this is atypical of this list? It seems someone is adding fuel to the flames being sent about dial-up access to the internet. This certainly points out the need for tracability if it is unauthorized. >HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND >MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R >NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!! >I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON >IC0WABUNGA!! > >------ >BIFF@BIFFVM.BIT.NET >BIFF+@ANDREW.CMU.EDU >BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF -------------------------------------------------------------------------------- Dennis Putnam, Service Manager Boeing Computer Services Alabama Supercomputer Network ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053110265000> Received: from cincsac.arc.nasa.gov by NIC.DDN.MIL with TCP; Thu, 31 May 90 22:07:16 PDT Received: Thu, 31 May 90 22:06:52 -0700 from localhost by cincsac.arc.nasa.gov (5.61/1.5T) Message-Id: <9006010506.AA03905@cincsac.arc.nasa.gov> To: "Martin Lee Schoffstall" Cc: jbloom@uhasun.hartford.edu, tcp-ip@nic.ddn.mil Subject: Re: Dial up access to Internet facilities In-Reply-To: Your message of "Wed, 30 May 90 17:48:40 EDT." <9005302148.AA02245@psi.com> Date: Thu, 31 May 90 22:06:50 -0700 From: "Milo S. Medin" (NASA ARC NSI Project Office) . . . I think the counter argument is that if it doesn't work reliably/well especially in the beginning then people won't rely on it to provide communications for their everyday needs. If they don't use it everyday then it is luxury suitable for axing at the appropriate belt-tightening time. Marty Marty, I think John was trying to espouse the "crack dealer's" approach to Internetting. First, you give them a little something either free or very low in cost. Then, once they are hooked, you stick it to them with high cost, high performance solutions, and by this time, they are screaming for more and can't do without. They will pay and and pay at this point. Those of us who work in the government side of networking don't use this exact tactic, but I know of many large organizations who were "hooked" this way... Thanks, Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053112083900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 06:25:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA09991; Fri, 1 Jun 90 06:10:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 12:08:39 GMT From: galbp!bagend!bvsatl!root@gatech.edu (Super user) Organization: bvsatl Atlanta Ga. Subject: Re: Query - Ethernet collisions Message-Id: <179@bvsatl.UUCP> References: <98@fedeva.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <98@fedeva.UUCP>, bill@fedeva.UUCP (Bill Daniels) writes: > We recently acquired an Exelan LANalyzer. During our first uses of it, > we noticed that about 40% of the packets on one ethernet segment (which > is remotely bridged to another) > Any clues? > > bill daniels > federal express, memphis, tn > {hplabs!csun,mit-eddie!premise}!fedeva!bill I had a similiar problem in the past. After much hair pulling, we found that you can not cascade DELNIs. That is, don't put the drop cable from a DELNI into a DELNI more than one level deep. While this may not be your problem, it sounds similiar. If this is not it, you may want to check cable lengths, cable types (ie rg58), etc. Bill VerSteeg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053112304400> Received: from mcsun.EU.net by NIC.DDN.MIL with TCP; Thu, 31 May 90 05:59:54 PDT Received: by mcsun.EU.net via EUnet; Thu, 31 May 90 14:59:48 +0200 (MET) Message-Id: <9005311259.AA25541@mcsun.EU.net> Received: from cctal by kestrel.Ukc.AC.UK with UUCP id aa02404; 31 May 90 13:34 BST To: tcp-ip@nic.ddn.mil Subject: SLIP Information Cc: cctal!andrew@relay.EU.net Date: Thu May 31 12:30:44 1990 From: cctal!andrew@relay.EU.net SLIP fans, old and new Having been watching the traffic for the past few weeks and noticed all the people looking for more info on SLIP, I think it's high time something was done about this, so (I'll probably regret this) I volunteer! Apart from the fact that I am looking for the same thing (and have had some modest success) I think it is a worthwhile exercise. So, I will undertake to prepare a summary for the net on SLIP and its availability and use. What I want to do this is info from SLIP users. All those of you out there using SLIP, please email me summaries of: Equipment Configuration SLIP software version, where you got it etc Usage Problems Any other info In particular, I think people wanting SLIP are looking for the PC + modem to Brand X UNIX box solution - feel free to correct me if I am wrong. No summary of SLIP would be complete without reference to ka9q and ppp, so info from actual users of these is solicited as well. Please do not send source code, RFCs, or long specifications of any sort, user experiences and known locations (USA, UK and Europe) of SLIP code is what is wanted. Look forward to hearing from you Andrew Hardie London, England ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053112454100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 06:08:12 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA12398; Thu, 31 May 90 05:45:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 12:45:41 GMT From: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF@ucbvax.Berkeley.EDU (THE BIFFMAN COMETH) Organization: BIFF FOR PREZ D00DS!! Subject: C0WABUNGA!! Message-Id: <901507476240BIFF@BIFFVM.BIT.NET> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!! I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON IC0WABUNGA!! ------ BIFF@BIFFVM.BIT.NET BIFF+@ANDREW.CMU.EDU BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053114520500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 11:40:56 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA05319; Thu, 31 May 90 11:23:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 14:52:05 GMT From: csusac!csuchico.edu!robin@ucdavis.ucdavis.edu (Robin Goldstone) Organization: California State University, Chico Subject: Re: tcp/ip services <--> decnet connectivity, help wanted Message-Id: <1990May31.145205.8371@csuchico.edu> References: <325@cmic.UUCP>, <18409@hercules.csl.sri.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <18409@hercules.csl.sri.com> kph@dirt.cisco.com (Kevin Paul Herbert) writes: >The easiest thing to do would be to get a DECstation 3100 (or something >else running Ultrix) and use the DECnet-Internet gateway software. I >don't know many product specifics, but I know that you can use it for >remote login and file transfer. You should also be running at least >DECnet/E V4.0 (RSTS/E V9.3) as previous versions had some problems >dealing with Ultrix, if I recall correctly. > >I've always thought it would be *fun* to put up TCP/IP on RSTS, though. >It really wouldn't be that hard to do for someone that was good with >RSTS monitor internals. > >Kevin I also spent a long time looking for a TCP/IP implementation for RSTS. After giving up on that, I looked at the solution described above, i.e. an Ultrix VAX as a gateway. All you need to run on it is DECnet-Ultrix. This automatically does conversion between DECnet protocols and TCP/IP protocols (according to DEC). Get DEC's "Local Area Network Solutions Guidebook" and read page 74. Well, in the end we decided that this solution was too indirect and ended up replacing our three RSTS systems with a VAX 6310! Too bad there wasn't a real TCP/IP solution for RSTS. I kinda miss it... Robin Goldstone, Systems Software Specialist California State University, Chico Computing Services robin@csuchico.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053115295800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 09:39:21 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA27547; Thu, 31 May 90 09:29:44 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 15:29:58 GMT From: intercon!news@uunet.uu.net (Amanda Walker) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Namespace clashes (was: What is the IAB?) Message-Id: <26653876.1395@intercon.com> References: <9005310005.aa26406@SPARK.BRL.MIL> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005310005.aa26406@SPARK.BRL.MIL>, reschly@BRL.MIL ("Robert J. Reschly Jr.") writes: > I read Marty's note about CMOT being > advanced to DIS; thinking, "Yeah, it did get advanced to Draft Internet > Standard status". I later read Amanda's note about Draft International > Standards under the same thread; again nodding in agreement. Only when I > read the next followup (again referring to Draft Internet Standards) did > I tumble -- namespace clash. I do apologize for that--I must admit that I hadn't seen the Internet version written as a TLA recently, and so the ISO interpretation was in my mental cache, reinforced by the fact that I think of CMOT as an ISO protocol that some strange people just happen to run over TCP :-). Sorry for any confusion... -- Amanda Walker InterCon Systems Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053117223400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 10:38:34 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA01562; Thu, 31 May 90 10:24:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 17:22:34 GMT From: silver!hughes@iuvax.cs.indiana.edu (larry hughes) Organization: Indiana University, Bloomington IN. Subject: Re: tn3270 daemon? Message-Id: <46298@iuvax.cs.indiana.edu> References: <45793@iuvax.cs.indiana.edu>, <90145.140551HATHAWA@gecrdvm1.crd.ge.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <90145.140551HATHAWA@gecrdvm1.crd.ge.com> HATHAWA@gecrdvm1.crd.ge.com (Barry Hathaway) writes: >In article <45793@iuvax.cs.indiana.edu>, hughes@silver.ucs.indiana.edu (larry >hughes) says: >> >>Does anyone know of a tn3270 daemon, somewhat of a hybrid between >>telnetd and (reverse) tn3270? I'm fairly certain there's no such >>animal, but if there is we'd have a good use for it. >> >Many TCP/IP packages for IBM mainframes offer terminal emulation on the host >side - which I guess could be called a tn3270 daemon. Fibronics (aka Sparticus) >KNET package has this as an option. Simware offers SIM/TCPIP an add-on to >IBM's TCP/IP package which does terminal emulation. Yes, thanks for the information, but I was aware of these. My question still stands in spite of them! Thanks, and I request further responses... //=========================================================================\\ || 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... || \\==========================================================================// ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9006011225.AA07219@ucbvax.Berkeley.EDU] <1990053120031000> From: MAINT@ASNTSU.ASN.NET Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9006011225.AA07219@ucbvax.Berkeley.EDU> Date: 31 May 90 20:03:10 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 Posted: Thu May 31 21:03:10 1990 In-Reply-To: usc!uscd!uwm!zaphod.cs.ohio-state!HERE!THERE!EVERYWHERE!BIFF AT ucbvax.Berkeley.EDU -- 31 May 90 12:45:41 GMT I have only been subscribed to this list for a short time and the discussions seemed to be at a professional level. This looks to me like an unauthorized hacker. Can I assume this is atypical of this list? It seems someone is adding fuel to the flames being sent about dial-up access to the internet. This certainly points out the need for tracability if it is unauthorized. >HIYA D00DS!! ICUZ MY BBROTHER <--BIG BROTHER, NEET HUH? WUZ BBSITTING ME AND >MY MOM WULD KILL HIM IF ANYTING HAPENED TO ME. THEES SHUR R >NIFTY BBOARDS!! IZ ANYWON MODURATING THEM?? I CAN DO IT D00DS!! >I PROVED MY BABAILITY BY MODURATING NEWS.GROUPS. SO FROM NOW ON >IC0WABUNGA!! > >------ >BIFF@BIFFVM.BIT.NET >BIFF+@ANDREW.CMU.EDU >BIFF@BIT.NET.GATE.WAY.MAN.WOMAN.BIRTH.DEATH.ALPHA.OMEGA.BIFF -------------------------------------------------------------------------------- Dennis Putnam, Service Manager Boeing Computer Services Alabama Supercomputer Network ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053121141400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 16:25:07 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24149; Thu, 31 May 90 16:20:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 21:14:14 GMT From: elroy.jpl.nasa.gov!usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@decwrl.dec.com (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Dial up access to Internet facilities Message-Id: <1990May31.211414.8140@utzoo.uucp> References: <118@ultrix.uhasun.hartford.edu>, <9005302148.AA02245@psi.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005302148.AA02245@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes: >I think the counter argument is that if it doesn't work reliably/well >especially in the beginning then people won't rely on it to provide >communications for their everyday needs... True in general, but one must beware of thinking of "reliably" and "well" as Booleans. Uucp mail is unreliable and ungodly slow by Internet standards, but vast numbers of sites found it reliable *enough* and workable *enough* to come to rely on it very extensively. The reason why a zoology department (!) was a major networking hub at U of T for some years was that everybody else was so obsessed with Internet (or better) performance that they wouldn't even look at silly ideas like networking via low-speed modems. We set up our phone links and started shipping mail and news, and pretty soon half the campus had uucp links to us. Half a loaf is much more nutritious than none. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990053123144500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 31 May 90 16:56:58 PDT Received: by ucbvax.Berkeley.EDU (5.63/1.41) id AA24438; Thu, 31 May 90 16:24:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 May 90 23:14:45 GMT From: paperboy!meissner@think.com (Michael Meissner) Organization: Open Software Foundation Subject: Re: Dial up access to Internet facilities Message-Id: References: <9005301640.6.142@cup.portal.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9005301640.6.142@cup.portal.com> jb.loom@uhasun.UUCP writes: | In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes: | > | > NEARnet is committed to broadening its base of support to include | > smaller sites at lower cost. We are chafing against technical issues in | > being able to offer high quality service at lower costs, since we balance | > hardware and people costs, and people costs are not really that bandwidth | > sensitive. We also have strict standards on quality of service, and we | > do not wish to compromise these standards in offering less costly access, | > since we know that later on our customers would regret the compromise as | > much as we. Then there is the issue of just what is part-time access; | > is it terminal dial-ups, SLIP/PPP (host or router?), uucp, what? We have | > to keep in mind what services we provide and we have to make sure that | > our clients understand what they can and can't do with new service offerings. | > | Speaking as one who is trying to figure out how to convince management that | $10k/yr would be well spent, I would be willing to accept service limitations | for a lower-cost net access. If the service truly is as useful to the | organization as I believe it would be, the demonstration of that usefulness | might just break loose the dollars for a higher quality ($10K) connection. So | providing low-cost, restricted service connections may well have the effect | of enhancing the number of sites getting full-service connections eventually. If all you currently want is SMTP and FTP initially, then uunet may be a way to start. They obviously will do mail, but another service they offer to paying customers is to do anonymous FTP's on request, and UUCP it to your machine. When I was at Data General, and the internet connection was extremely flakey (it did get better before I left), I begged, pleaded, and such to management to establish such a UUNET connection and buy the Telebit Trailblazer modem. I was able to get GCC releases and prereleases in a timely manner (though there was the time when I couldn't keep an internet connection or modem connection open long enough, thanks to the lousy GTE phone service in the RTP area of North Carolina or the lousy internal DG phone service). The last time I looked, the uunet charges where $35/month, $2/hour if you called their local number (using company WATTS lines if you have them), or $16/hour if you used their 800 number. A Telebit T2500 modem sells in the range of $1000. Obviously this is subject to change, as is their willingness to do anonymous FTP's for you (though they have most of the stuff people want directly on uunet). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so ----MESSAGE-END----