----MESSAGE-BEGIN---- <1990110101263800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 31 Oct 90 17:43:37 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26730; Wed, 31 Oct 90 17:40:25 -0800 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 Nov 90 01:26:38 GMT From: netcom!cmilono@apple.com (Carlo Milono) Organization: Netcom Subject: SLIP over X.25 Message-Id: <15960@netcom.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am involved in an overseas agreement where Intel-based UNIX platforms will be used in a distributed RDBMS environment. There is a domestic X.25 network (GE) in place, with UUCP traffic and H/TPAD access to the various hosts. The problem is that the cost of hooking up the international sites with private links to the X.25 (perhaps via X.75 gateways) is not economically feasible. My plan was to take advantage of the TCP/IP that is present in each of the nodes and route it over X.25...this has been done and works just fine. Since I cannot have private X.25 overseas, I was contemplating using SLIP to dial *into* a PAD and hence, route the info...this would be FTP'ing files only, perhaps bi-directionally; this would limit the initiator to the dial-in site.... Has anyone done anything similar? HELP!--- -- +--------------------------------------------------------------------------+ | Carlo Milono | | Personal: netcom!cmilono@apple.com or apple!netcom!cmilono | |"Sometimes I think the surest sign that intelligent life exists elsewhere | | in the universe is that none of it has tried to contact us." B.Watterson | +--------------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [361@organpipe.UUCP] <1990110108081400> From: royce@scoraz.resp-sci.arizona.edu (Royce Robbins) Newsgroups: comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip Subject: TCP/IP over AppleTalk for Apple IIgs???? Message-ID: <361@organpipe.UUCP> Date: 1 Nov 90 08:08:14 GMT Sender: news@organpipe.UUCP Followup-To: comp.sys.mac.comm Organization: University of Arizona, Tucson, AZ Lines: 13 Posted: Thu Nov 1 09:08:14 1990 Title says it all: Is there such a thing as a package that will let my Apple IIgs do TCP/IP over AppleTalk (like MacTCP + stuff) or even over ethernet? Any pointers would be appreciated. --Royce Robbins =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Royce Robbins INTERNET: royce@resp-sci.arizona.edu Div Resp Sciences FAX: (602) 626-4884 UofArizona PHONE: (602) 626-5022 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110114161100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 08:46:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13472; Thu, 1 Nov 90 08:26:59 -0800 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 Nov 90 14:16:11 GMT From: eru!hagbard!sunic!dkuug!vaxc!vax87!dalk@bloom-beacon.mit.edu Subject: Printers for Ultrix Message-Id: <431.27302e2b@vax87.aud.auc.dk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We want to connect our printers from a Ultrix machine through some terminalservers using TCP/IP ( CS/200). But we do not know how to do it. Can anyone help me - then please E-mail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110119112000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 11:30:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18352; Thu, 1 Nov 90 11:25:23 -0800 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 Nov 90 19:11:20 GMT From: usc!elroy.jpl.nasa.gov!jarthur!bridge2!api!gpz@ucsd.edu (G. Paul Ziemba) Subject: Re: Problem with Xmodem and 3Com terminal server Message-Id: References: <9010312149.AA07742@z.nsf.gov>, <12634372337.2.BILLW@mathom.cisco.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil BILLW@MATHOM.CISCO.COM (William Chops Westfield) writes: >Even when transferring text files, XMODEM needs a clear 8-bit path to >accomadate its block counts and checksum. By definition, telnet is a >7 bit protocol, and you must negotiate "binary" mode to get an 8-bit >path. The terminal server may be refusing binary mode negotiations, >may just do binary incorrectly, or may just need configured differently. Unfortunately, I did not read the original query, so I'm guessing that the original poster (someone @z.nsf.gov) is trying to establish an 8-bit path from a 3com terminal server. This can be done...the following settings are needed: fcf=n flow-control-from disabled fct=n flow-control-to disabled bra=ig break-action ignore ecmc=d escape-cmd-char disabled depending on the comserver software version, you may also need to set xb=on transmit binary enabled lbra=l local-break-action listen (so you can break the connection locally) If that doesn't answer the original question, well, then, never mind :-) ~!paul -- Paul Ziemba api!gpz gpz@ESD.3com.com 408.764.5390 OS/2: just say no. "How much char could a char star star if char star could star char?" (quote stolen from mspercy@clemson.clemson.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110119213100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 12:18:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19603; Thu, 1 Nov 90 12:09:07 -0800 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 Nov 90 19:21:31 GMT From: agate!shelby!unixhub!slacvm!ago@ucbvax.Berkeley.EDU Organization: Stanford Linear Accelerator Center Subject: TCP/IP-NFS Lan for Macs/PCs/Unix boxes - Opinions wanted Message-Id: <90305.112131AGO@SLACVM.SLAC.STANFORD.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm currently planning a LAN for the Electronics Department at the Stanford Linear Accelerator Center. The media is going to be Ethernet, and the protocols will be TCP/IP and NFS. As we have to support a vriety of machines, things start to get hairy. The platforms to be supported in a first phase are Macs, PCs, UNIX workstations, and Apple LaserWriters. Now, how do you get all these bozos to talk to each other? I suppose a lot of people had to deal with a similar problem, so I don't want to reinvent the wheel. Although searching quite intenseley, I wasn't able to find write-ups addressing the different facets of the problem. As I suppose that this subject interests a certain number of people, I describe the solutions I'm thinking about, and would like to hear comments/suggestions/ caveats, etc. I will post a summary under comp.dcom.lans as soon as a compilation is done. Of course, you can post your comments also directly on the net if you think a larger amount of people can directly take advantage of them. The number of machines on the net will be around 50-100, with a majority being PCs. During the first phase, only one file server (SparcStation) will be installed. The Macs will be running Pathway NFS client from Wollongong, and the PCs PC-NFS (or maybe a similar product from Wollongong or ftp software). On the Mac, TN3270 will be used for remote mainframe logon; no product has been identified yet on the PC side. Printing seems to be more of a problem. We'd like to attach the printer(s) directly to the net, not to a server. As the interface on the printer side is LocalTalk, a converter is needed. Moreover, the PCs and Suns don't speak PAP (the Apple Printing Protocol), and some of their output is non-PostScript. How to access the printer? One solution seems to be the Cayman GatorBox running GatorPrint. With the lpr feature of the NFS client packages, it should be possible to access the printer(s) through the GatorBox. Only disadvantage: LocalTalk cables have to be run to the printer(s). Another solution seems to be to run a few software packages on the server (CAP, Transript and UAB), but this looks much less straightforward and prone to failure. Comments would be appreciated in the following areas: - Do you see a problem with this scheme? Any better solutions? - Has anybody used Wollongong's PathWay Client NFS for Mac? Experience? - What about alternatives to PC-NFS? Has anybody used WIN/TCP for DOS, PathWay Client NFS for DOS (Wollongong), PC/TCP (ftp software), or similar packages? - What about the coexistence of the packages with Windows 3.0? - Printer access through these packages (+ GatorBox)? - Recommendations for Ethernet cards for Mac and PC? - Experience with the GatorBox and GatorPrint? Well, I hope this starts some interesting discussions on the net. I'm looking forward to hearing different opinions, so feel free to contact me. Posting of a summary will be done as soon as possible under comp.dcom.lans, as mentioned before. Romain C. Agostini Stanford Linear Accelerator Center Disclaimer: the views and opinions expressed in this document are my own, and do not necessarily reflect those of SLAC or Stanford University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110122124300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 15:43:38 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25132; Thu, 1 Nov 90 15:26:57 -0800 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 Nov 90 22:12:43 GMT From: rochester!rocksanne!sma@cu-arpa.cs.cornell.edu Organization: WRC, XEROX Subject: Re: Reliable Datagram ??? Protocols Message-Id: <630@rocksanne.WRC.XEROX.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have been doing some work on a reliable multicast transport protocol, the "Multicast Transport Protocol". MTP (or Empty Pea) attempts to satisfy two of the goals discussed recently - 1) fast, reliable multicasting at the transport level, and 2) agreement on order and delivery of "messages" built on top of the transport data. The transport layer is a NAK-based protocol that utilizes the multicast capability of the lower layers (e.g. IP and Ethernet). It provides reliable delivery of messages, which are uninterpreted sequences of bytes terminated by a end-of-message marker. The ordering and agreement protocol uses a token-based scheme to grant sending rights to producers of messages, to guarentee that a given message will either be accepted by all processes or not accepted by any, and to guarentee that all processes agree on the order in which the messages will be processed. Alan Freier at Apple and Keith Marzullo at Cornell have written a technical report on MTP available from Cornell. Ask marzullo@cs.cornell.edu for information on getting a copy. Cheers, Susie Armstrong Xerox Webster Research Center armstrong.wbst128@xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110122294900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 15:15:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24526; Thu, 1 Nov 90 15:01:52 -0800 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 Nov 90 22:29:49 GMT From: agate!shelby!neon!jackson@ucbvax.Berkeley.EDU (Robert D. Jackson) Organization: Computer Science Department, Stanford University Subject: TCP/IP Source Code Search Message-Id: <1990Nov1.222949.29575@Neon.Stanford.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm searching for vendors that sell TCP/IP source code. I have found two: Wollongong and Interactive Systems. I've been able to experiment a little with binaries from Wollongong (AT&T 6386, Unix System V, Rel 3.2.1) and have gotten a few comments from others that have used it. I have not been able to locate anyone that has had experience with the Interactive software. If you have had experience with the TCP/IP software and/or support from either of these vendors, good or bad, please drop me a line. If you know of another place I should look for TCP/IP source code, please let me know. Thanks in advance, -- Bob Jackson jackson@neon.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110203071300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 18:33:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29870; Thu, 1 Nov 90 18:25:41 -0800 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 Nov 90 03:07:13 GMT From: munnari.oz.au!uniwa!aldetec!smenda@uunet.uu.net (Greg Smenda) Organization: Aldetec Pty Ltd, Perth West Australia Subject: tcpip network problems Message-Id: <285@aldetec.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are running a TCP/IP network that is displaying some funny characteristics. The basic setup is a motorola Delta 1147 system connected to MVME147 processor board running pSOS+ real time operating system and pNA (it's tcp-ip module). The pNA side acts as a server, with sockets being created in SOCK_STREAM mode. Our delta machine is doing a blocked read on the opened socket, yet after a burst of data has commenced, some reads are only partially completing - i.e 200 bytes of a 500 byte packet is returned, and the remaining 300 bytes must be 'mopped-up' in the next read. The real crunch is that our data transfer seems to grind to a halt, with mopup reads required on nearly every unit of data that is transferred from the pSOS system. Also the time taken to actually read a complete packet goes way down the gurgler when these mopup reads are required. Running a similar data transfer between 2 delta machines results in similar problems, although the dreaded time-lag in mopping up doesn't appear to be present. Typically, a burst of data may be 5000 514-byte packets, sent at a rate of 5-20 a second ... Degradation can been seen from as early as the 20th packet. (The test between the 2 delta machines was transferring at a faster rate, allowing for time-sharing etc) I've tried using 'nettrace', which returns streams of information, most that does not concern the connection of interest. However, messages are rapidly sent to the console while this program is running, giving the diagnostic message 'if37x_rx: trace packet dropped - canput failed'. Some packets of interest that nettrace does report concerning our link, have a TCP flag value of RESET, where can I get info on what this means? Are there other utilities that may assist a novice networker in monitoring a specific connection, particularly being able to identify data that has arrived but not been read, and reporting any 'out-of-the-ordinary' retries/errors in the data transfer for that connection. (If not, what about information on structures, routines that I could use to monitor the socket from a program ??) -- __________________________________________________________________________ Greg Smenda Internet : smenda@aldetec.oz.au ACSnet : smenda@aldetec.oz Voice : +61-9-4451888 0800 - 1730 WST System Administrator : +61-9-3859521 otherwise Aldetec Pty Ltd. - Fishy fishy fishy fish, it would go where ever I did go - __________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110203362300> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 05:35:34 PST Received: from UNB.CA (stdin) by ugw.utcs.utoronto.ca with SMTP id 57385; Fri, 2 Nov 90 08:35:35 EST Received: by UNBMVS1 (Mailer 14.75) id 2226; Fri, 02 Nov 90 09:36:23 AST Date: Fri, 2 Nov 90 08:36:23 EST From: BDK@UNB.CA To: TCP-IP@NIC.DDN.MIL Subject: Re: Configuring a Sun to use DNS In-Reply-To: Message of Fri, 2 Nov 90 05:47:31 GMT from As it comes from the factory SunOS 4.1 requires the use of NIS in order to use the DNS. When we complained to SUN they provided a fix that they said would do the job. Since we were novices with SUNs at the time we decided to stick with standard things rather than modify the system. So contact your SUN technical support person. Brian Kaye University of New Brunswick On Fri, 2 Nov 90 05:47:31 GMT Samuel Lam writes: > Could someone please tell me what is the easiest way to get a NIS-less > Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name > lookups? > > Adding a /etc/resolv.conf file didn't do it. It just changed how > nslookup behaves, but nothing else. > > Thanks in advance for any pointers. > > ....Sam > -- > Internet: UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc. > ca!skl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110205473100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 1 Nov 90 22:00:28 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04373; Thu, 1 Nov 90 21:51:51 -0800 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 Nov 90 05:47:31 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!skl@ucsd.edu (Samuel Lam) Organization: Balliffe Intersystem, Vancouver, B.C., Canada Subject: Configuring a Sun to use DNS Message-Id: <39@van-bc.wimsey.bc.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Could someone please tell me what is the easiest way to get a NIS-less Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name lookups? Adding a /etc/resolv.conf file didn't do it. It just changed how nslookup behaves, but nothing else. Thanks in advance for any pointers. ...Sam -- Internet: UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110213414200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 10:32:46 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18044; Fri, 2 Nov 90 10:05:51 -0800 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 Nov 90 13:41:42 GMT From: encore!mperlman@husc6.harvard.edu (Mark Perlman) Organization: Independent Consultant Subject: Re: Problem with Xmodem and 3Com terminal server Message-Id: <13133@encore.Encore.COM> References: <9010312149.AA07742@z.nsf.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010312149.AA07742@z.nsf.gov> mmorse@Z.NSF.GOV ("Michael H. Morse") writes: > ... >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. Mike: I had a similar problem with uucp through a CMC Terminal Server. I had written a "reverse telnet" program to set a permanent circuit from the server to the host. To make a long story short, I found out that typically, telnet uses 7-bit mode, however, it is an option that is negotiable. It may be that Ultrix may default to 8-bit mode and the 3Com terminal server may default to 7-bit. The 3Com TS may not support 8-bit mode? I not sure about that. Hope that helps. +----------------------------------------------------------------------+ | Mark R. Perlman | | Independent Consultant 301-206-2016 | | 14014 Oakpointe Dr. mperlman@encore.com | | Laurel, MD 20707 uunet!gould!mperlman | +----------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110217093700> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 02:50:53 PST Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA18373; Sat, 3 Nov 90 02:51:18 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA18253; 3 Nov 90 01:09:37 PST (Sat) To: jackson@neon.stanford.edu Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Robert D. Jackson's message of 1 Nov 90 22:29:49 GMT <1990Nov1.222949.29575@Neon.Stanford.EDU> Subject: TCP/IP Source Code Search Reply-To: romkey@asylum.sf.ca.us Message-Id: <9011030109.AA18253@asylum.sf.ca.us> Date: 3 Nov 90 01:09:37 PST (Sat) From: romkey@asylum.sf.ca.us (John Romkey) A third vendor of TCP/IP source code is Epilogue Technology. We announced a portable TCP product at Interop. Email me for more information. Many people use the Berkeley code as a start. It's an excellent protocol engine; its main drawback is that it really really wants to live inside a UNIX kernel. It often takes many man-months to port properly. You can find it on uunet.uu.net for anonymous FTP. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110217414500> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 08:43:03 PST Received: from PTEARN.FCL.RCCN.PT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6375; Fri, 02 Nov 90 11:42:35 EST Received: by PTEARN (Mailer X1.25) id 1208; Fri, 02 Nov 90 17:42:19 PRT Date: Fri, 02 Nov 90 17:41:45 PRT From: CHIS%PTEARN.BITNET@CUNYVM.CUNY.EDU To: TCP-IP@NIC.DDN.MIL Unsubcribe me !!! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011021926.AA20314@ucbvax.Berkeley.EDU] <1990110219261200> From: CHIS@PTEARN.BITNET Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9011021926.AA20314@ucbvax.Berkeley.EDU> Date: 2 Nov 90 19:26:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 Posted: Fri Nov 2 20:26:12 1990 X-Unparsable-Date: Fri, 02 Nov 90 17:41:45 PRT Unsubcribe me !!! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110220231200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 19:32:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02054; Fri, 2 Nov 90 19:03:49 -0800 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 Nov 90 20:23:12 GMT From: attcan!telly!evan@uunet.uu.net (Evan Leibovitch) Organization: Somewhere just far enough out of Toronto Subject: Info needed on Beame & Whiteside TCP/IP & NFS Message-Id: <2731D5B2.5BBC@telly.on.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Title says it. I heard a consultant recommend this company to a client and know little or nothing about them. Any comments or suggestions are welcome. Please mail replies. Thank you. -- Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / moderator, rec.arts.erotica ...quoth the Raven, "Eat My Shorts!" -- Bart ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110220452600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 18:17:09 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01074; Fri, 2 Nov 90 18:14:25 -0800 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 Nov 90 20:45:26 GMT From: usc!elroy.jpl.nasa.gov!aero!aerospace.aero.org@ucsd.edu (Charles T. Wolverton) Organization: The Aerospace Corporation, El Segundo, CA Subject: X.400 over TCP/IP Message-Id: <90507@aerospace.AERO.ORG> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We would like to use an IP internetwork as an intermediary between two OSI networks for the purpose of X.400 E-mail exchange. The following kludge uses Wollongong products and appears (conceptually) to work: ------- ------- | MHS | | MHS | | --- | | --- | ------- | ULS | | ULS | ------- |X400 | --------- |w/RFC| |w/RFC| --------- |X400 | |MTAs | | TSB | |1006 | |1006 | | TSB | |MTAs | | ON | |-------| |-----| |-----| |-------| | ON | | TP4 | |LLS|TCP| | TCP | | TCP | |TCP|LLS| | TP4 | ------- --------- ------- ------- --------- ------- + + + + + + + + + + + + + + + + ++++++++++++ ++++++++++ ++++++++++ ++++++++++++ OSI #1 TCP/IP #1+ +TCP/IP #2 OSI #2 + + ++++++++++++++ TCP/IP internet Each OSI/TCP #N logical pair is physically one network. The Wollongong components are: TCP-based MTA: WIN/MHS, WIN/ULS (using the transport switch in RFC1006 "position"), WIN/TCP Transport bridge: WIN/TSB, WIN/LLS Altho shown logically separated, hopefully each MHS/ULS/LLS/TCP set would run on one machine. The assumptions leading to the kludge: i. The WIN/ULS transport switch is static, not dynamic -> a simple dual stack ULS-over-LLS+TCP wont work -> need the TSB ii. The TSB needs a true destination host address, not another TSB -> need the two TCP-based MTAs (MHS/ULS/TCP) Questions: i. Is there a more straightforward way to do this??? (with commercial products - no ISODE, "you can easily hack the blah, blah code", etc. - we're buyers, not developers) ii. If not, are the above assumptions correct?? Should the kludge work?? Has anyone tried it (or something similar and, hopefully, simpler)?? Many thanks for any help. Also, apologies if this isn't the best list for the question. -chas ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110220521600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 13:02:36 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22953; Fri, 2 Nov 90 13:02:50 -0800 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 Nov 90 20:52:16 GMT From: sdd.hp.com!samsung!umich!vela!srodawa@ucsd.edu (Ron Srodawa) Organization: Oakland University, Rochester MI Subject: Re: Problem with Xmodem and 3Com terminal server Message-Id: <3654@vela.acs.oakland.edu> References: <9010312149.AA07742@z.nsf.gov>, <13133@encore.Encore.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Another thing to watch out for with 3COM terminal servers is the setting for Net AScii. It can be either UseLF or UseNul. Flip it and see if it fixes things. (This changes whether a CR si followed by a NUL or by a LF character on the net. Some systems don't care. Others go bonkers if the setting is wrong.) -- | Ronald J. Srodawa | Internet: srodawa@unix.secs.oakland.edu | | School of Engineering and CS | UUCP: srodawa@egrunix.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110222315100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 14:49:03 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25564; Fri, 2 Nov 90 14:38:23 -0800 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 Nov 90 22:31:51 GMT From: icarus.eng.ohio-state.edu!kaul@tut.cis.ohio-state.edu (Rich Kaul) Organization: The Ohio State University Dept of Electrical Engineering Subject: Re: Configuring a Sun to use DNS Message-Id: References: <39@van-bc.wimsey.bc.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <39@van-bc.wimsey.bc.ca> Samuel Lam writes: Could someone please tell me what is the easiest way to get a NIS-less Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name lookups? Ah, something I just enabled on my Sun. Here's a previous posting that may be helpful. "It worked for me." -rich >From earle@POSEUR.JPL.NASA.GOV Mon May 21 09:58:30 1990 From: earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) Newsgroups: osu.sys.sun.managers Subject: Revised posting on how to create libc_resolv.so under SunOS 4.1 Date: 19 May 90 03:59:57 GMT Distribution: osu Organization: Sun-Managers Evan Wetstone's posting to Sun-Spots about libc+resolv under 4.1 has reminded me to repost a slightly revised version of the instructions. This is prompted by 3 things: (1) The original, virgin /usr/lib/shlib.etc/README file has an oversight in it; The original mentions that 2 files in the archive library need to be renamed after they are extracted, because the names are truncated at 16 characters. This is true for the Sun-3 and Sun-3x, but on Sun-4's and Sun-4c's (SPARCstation-1's, 1+'s, and presumably SLC's), there is an additional library module whose name is also truncated. This is corrected. (2) Several people complained to me that my instructions, being placed as an addendum rather than in line with the rest of the instructions, were thus unneccessarily confusing, and could even (if misinterpreted) cause someone to build a libc that would not work. (3) I accidentally included my .signature file at the end of the posting, and then told everyone to append the rest of my message to their README files, thus immortalizing my .signature in everybody's README (^: I humbly apologize ... So, without further ado, here is the revised version of the file /usr/lib/shlib.etc/README. I recommend backing up the original, nuke my previous version (the one that Evan re-posted), and insert this in its place. - Greg Earle | "This is Kraft. It uses a blue box. Sun Microsystems, Inc. | This is Stouffer's. It uses red. JPL on-site Software Support | The choice is yours." sun!poseur!earle | Pretty damn convincing argument, eh? ---------------- >8 Cut here - /usr/lib/shlib.etc/README 8< --------------- This is a procedure you can use to substitute or add a module in your shared libc C library. Note! If you are interested in a System V libc, please substitute libc_pic.a for libcs5_pic.a in step 3, libc.so.x.y.z for libcs5.so.x.y.z in step 8. ------------------------------------------------------------------------- 1. Become super user % su 2. Make a temporary directory # mkdir tmp 3. Change to the "tmp" directory just made, extract the pic .o from libc_pic.a and rm the file __.SYMDEF. The reason you need to do the 2 (or 3) "mv" commands is because "ar" truncated filenames over 16 characters. # cd tmp # ar x ../libc_pic.a # rm __.SYMDEF # mv rpc_dtablesize. rpc_dtablesize.o # mv rpc_commondata. rpc_commondata.o If on a Sun-4, perform this additional `mv' command: # mv xccs_multibyte. xccs_multibyte.o Here are some extra instructions for building a shared libc.so that uses the resolver for hostname/addr resolution: 3a. Extract the contents of libc_pic.a and /usr/lib/libresolv.a into the tmp directory: # ar x /usr/lib/libresolv.a The libresolv.a contains object modules that are position independant, so they can be added to the libc_pic modules. *Note* If you have your own copy of the resolver library sources, (perhaps from a post-4.8 BIND distribution) you can compile each of these modules yourself using `cc -pic' and the resulting object modules *should* be usable in this schema as well. To test that the custom resolver modules will be usable, cd to the directory containing the custom resolver sources and object modules and perform this test: # ld -assert pure-text *.o If `ld' issues no complaints, then you can assume that the object modules are safe to use. 3b. Remove the old routine to do the hostname/addr resolution: # rm gethostent.o 3c. Remove the libresolv module that contains `strncasecmp' (which is now in the main C library, so it is redundant): # rm strcasecmp.o 3d. As mentioned in step 5 below, edit the file `lorder-sparc' in the .. directory. Remove the reference to `gethostent.o' and add the references to the resolver library routines by applying this patch: *** lorder-sparc.orig Thu Feb 8 05:27:46 1990 --- lorder-sparc Mon Apr 9 12:58:59 1990 *************** *** 150,154 **** getwd.o getnetgrent.o ! gethostent.o ypxdr.o ttyname.o --- 150,161 ---- getwd.o getnetgrent.o ! gethostnamadr.o ! sethostent.o ! res_query.o ! res_mkquery.o ! res_send.o ! res_debug.o ! res_comp.o ! res_init.o ypxdr.o ttyname.o 3e. Continue on, from steps 6 to 9 (i.e., skip steps 4 and 5 immediately below). ------------------------------------------------------------------------------ 4. Replace or add the .o that you wanted by doing a copy. Please note here that you are advised to create your object with the following compiler option, i.e "cc -c -pic yourprogram.c" to make it shareable. # cp your.o . 5. If you add a new module then you need to do this step. You need to edit the file "lorder-sparc" and add the name of the file you have copied from step 4 at the end of this file. # vi ../lorder-sparc 6. # cd .. 7. # make libc.so 8. Now you should have some libc.so.x.y.z built in the current directory. It is recommended that you tested out this library at this point before installing it. You can do so by setting the environment LD_LIBRARY_PATH to the current directory for example: # setenv LD_LIBRARY_PATH `pwd` # your_favorite_test_cmd Once you are satisfied that the new library worked, you can proceed to install it with the following commands: # cp libc.so.x.y.z /usr/lib # ldconfig # unsetenv LD_LIBRARY_PATH 9. You are now running with the new library. You can verify this by doing a trace command of let's say "date". # trace date The output should informed you that the new library is being used. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110302103500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 21:22:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04810; Fri, 2 Nov 90 21:15:26 -0800 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 Nov 90 02:10:35 GMT From: usc!samsung!olivea!tymix!cirrusl!sunstorm!dhesi@ucsd.edu (Rahul Dhesi) Organization: Cirrus Logic Inc. Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <2650@cirrusl.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com>, <1990Oct29.205244.2051@supernet.haus.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In <1990Oct29.205244.2051@supernet.haus.com> cluther@supernet.haus.com (Clay Luther) writes: >Internet will not be cheap until it drops to say, $100/month, or less. I fail to see why it should be any more than about $1.50 per month, plus communications costs. You don't need $100/month for storing a password entry. The only significant cost should be for communications. While we're on the subject, the whole idea of requiring some sort of leased line for Internet access is all wrong. In this age of Trailblazers, low-volume access to a network shouldn't need to cost more than $30/hour after hours plus $1.50 per month for maintaining the account. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi A pointer is not an address. It is a way of finding an address. -- me ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110302164200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 18:21:59 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24012; Sat, 3 Nov 90 18:14:17 -0800 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 Nov 90 02:16:42 GMT From: hpda!hpcupt1!hpindwa!lmg@ucbvax.Berkeley.EDU (Lisa Gullicksen) Organization: Hewlett-Packard, Cupertino CA Subject: HPCIGETVAR error -- HELP!!! Message-Id: <36540015@hpindwa.cup.hp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Background: We encountered a problem in integration testing of SNMP/XL. The test system is a 925 running the test build Z.22.12 of the OS. The program under test is written in C. The problem occurs when we execute an snmpget from a UX machine to query the system.sysDescr.0 MIB object. The Problem: The error occurs when the HPCIGETVAR intrinsic is called. The return value of the status parameter is: hpcigetvar returned info = -8106 subsys = 166. The code that gets invoked, along with the parameter declarations, follows: -------------------------------------------------------------------- hpe_status status_c; char keyvalue1[200]; int keyvalue2; printf ("about to call hpcigetvar for HPCPUNAME.\n"); hpcigetvar ("HPCPUNAME$", &status_c, 2, keyvalue1, 11, &keyvalue2); printf ("hpcigetvar returned info = %d subsys = %d.\n", status_c.half.info, status_c.half.subsys); ------------------------------------------------------------------- Questions: What is the error -8106? Why is it that this call works when linked with the test driver but not with the module with which it is being integrated? Within the integrated module, hpcigetver is called twice. The first time it works. The second time it doesn't. The second invocation is the one that comes from the newly integrated code (linked with the main program as an RL). We've checked that the test driver and the actual code are built in the same manner with the same capabilities, execution level and priv level (xleast=2;privlev=2;cap=ph,ds,mr,pm,ia,ba). Any help will be greatly appreciated! Lisa Gullicksen 1-447-2499, lmg@hpindzl Brian McCracken 1-447-3478, bhm@hpda IND ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110302532500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 19:02:09 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01904; Fri, 2 Nov 90 18:56:26 -0800 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 Nov 90 02:53:25 GMT From: usc!jarthur!bridge2!mbt@ucsd.edu (Brad Turner) Organization: 3Com Corp., Mt. View, CA Subject: Re: Problem with Xmodem and 3Com terminal server Message-Id: <2910@bridge2.ESD.3Com.COM> References: <9010312149.AA07742@z.nsf.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil mmorse@Z.NSF.GOV ("Michael H. Morse") writes: >I am having a problem getting Xmodem to work between a Sun workstation >and a PC running a terminal emulator. >The PC uses a modem and a dial-up line to communicate, but it cannot >get to the workstation directly because the workstation has no serial >ports. Instead, the PC logs on to some other host, and then uses >telnet to get to the workstation. >We have a 3Com terminal server that is normally used in this situation, >but we've found that Xmodem does not work (the PC nacks everything it >gets) in this configuration. However, if the PC logs onto one of our >Ultrix hosts, and in effect uses it for a terminal server to telnet to >the workstation, Xmodem works fine. Subsequent tests have absolved the >terminal emulator (on the PC) and the xmodem program on the >workstation, leaving suspicion around the telnet implementation >on the terminal server. >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. >Thanks in advance. >--Mike >-- >Michael Morse Internet: mmorse@note.nsf.gov >National Science Foundation BITNET: mmorse@NSF > Telephone: (202) 357-7659 > FAX: (202) 357-7663 Mike, From your description above it sounds like you have the following topology. Ethernet | | Phone | PC--Modem1=========Modem2---TermServer-| Line | | |--WorkStation | If this is your topology then you should set up the termnial server parameters as follows for the duration of the Xmodem transfer: FlowControlTo=none FlowControlFrom=none BreakAction=(EscDTM) ECMChar=disable You can create a macro on the terminal server to do this and another macro to restore the parameters after the transfer. By default the terminal server attempts to negotiate a binary connection so the connection is 8-bits wide. It has been a while since I worked in tech support so let me know if this doesn't work (I'm winging it from memory.) I know that this can work since I've configured it and had it running in the past (Xmodem through our CS that is.) -brad- -- v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v Brad Turner |5400 Bayfront Plaza |Mktg.Engr.(408) 764-5261| I speak for myself 3Com Corp. |Santa Clara CA,95052|mbt@bridge2.ESD.3Com.Com| NOT for my employer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011030522.AA04907@ucbvax.Berkeley.EDU] <1990110303020000> From: KCPENG@TWNCTU01.BITNET Newsgroups: comp.protocols.tcp-ip Subject: annoying n/w problems Message-ID: <9011030522.AA04907@ucbvax.Berkeley.EDU> Date: 3 Nov 90 03:02:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Posted: Sat Nov 3 04:02:00 1990 Hi netter, There exist some problems in our network, though not(?) severe but indeed annoying. The net consists of tens of various machine: Vaxs, Suns, HPs, RS6000s, X-terminals... Some observable phenomenons follow: . the Sun 4/370 console keeps printing the message a period of time - 'le0 : No carrier - transceiver cable problem?' of course, it can still do network functions. Other Suns SSs just have no such annoyance. . there are 3 workstations, say A, B and C, networked together. (O) ftp A to B (O) ftp B to C (X) ftp A to C A, B = Sun, C = RS600. (B,C) and (A) are on two different repeter ports. . another 2 hosts, say D and E, connected. (O) telnet D to E (X) telnet E to D (X) telnet D to D these two nodes are not on the same repeter port. I've re-invoked the inetd of D, still in vain. (It seems D can telnet 'out' sometimes before) What I'm concerned are, 1) what's the causes? repeater? cable? others? 2) any utility to monitor the network problems, like re-transmission rate? or you have to put some command, like netstat, in cron table and run it periodically, then do statistics yourself? if so, how do I suppose to know the 'correct'(tolerable) value in all these statistical values? 3) some friend mentioned to me a product called 'cable scanner'. is it helpful to the above problems? Any clue is highly, highly welcome. Regards, Kai-Chih Peng, kcpeng@twnctu01.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110307272200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:33:57 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08316; Sat, 3 Nov 90 00:31:25 -0800 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 Nov 90 07:27:22 GMT From: mcb@presto.ig.com (Michael C. Berch) Organization: IntelliGenetics, Inc., Mountain View, Calif. USA Subject: Cost of Internet access Message-Id: References: <132136@pyramid.pyramid.com>, <1990Oct29.205244.2051@supernet.haus.com>, <2650@cirrusl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In the referenced article, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > While we're on the subject, the whole idea of requiring some sort of > leased line for Internet access is all wrong. In this age of > Trailblazers, low-volume access to a network shouldn't need to cost > more than $30/hour after hours plus $1.50 per month for maintaining the > account. Uhhh, $30/hour? That's about $21,000 per month, isn't it? Even assuming you typo'd "$30" for "$3" that would be $2,100/month which is still pretty high. Unless you meant some sort of access that would only be a few hours per day, which misses the main advantage of Internet access in the first place, which is real-time access to a large set of distributed resources. As an Internet user I can sit at my workstation during business hours and log in to remote accounts, FTP files to and from arbitrary locations all over the world, and send and receive mail that arrives in seconds or minutes. Dial-up SLIP or PPP on an after-hours batched basis can't offer those services and do not, to my mind, provide much of an advantage over dial-up UUCP. "Real" Internet access, to me, means real-time access. -- Michael C. Berch mcb@presto.ig.com / uunet!presto.ig.com!mcb / ames!bionet!mcb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110314490700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 14:49:52 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20742; Sat, 3 Nov 90 14:41:35 -0800 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 Nov 90 14:49:07 GMT From: bywater!acheron!clarke@uunet.uu.net (Ed Clarke/10240000) Organization: Ciliophora Associates Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Nov3.144907.15564@acheron.uucp> References: <2650@cirrusl.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <2650@cirrusl.UUCP>, by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi): - While we're on the subject, the whole idea of requiring some sort of - leased line for Internet access is all wrong. In this age of - Trailblazers, low-volume access to a network shouldn't need to cost - more than $30/hour after hours plus $1.50 per month for maintaining the - account. PSInet charges $250/month, flat fee using local phone numbers. There are no additional charges for packet or connect time. If you think that you will use internet access more than eight hours at your $30/hr, then you have access right now. Call 1.800.82PSI82 (blech!) to get more info. They support PPP (RFC 1171 asynch), SLIP (RFC 1055) and X.25/IP. I just got the add yesterday ... -- | "Pain, n. An uncomfortable frame of mind that may have Ed Clarke | a physical basis in something that is being done to the acheron!clarke | body, or may be purely mental, caused by the good fortune | of another." - Ambrose Bierce ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110316260700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 20:50:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26166; Sat, 3 Nov 90 20:33:38 -0800 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 Nov 90 16:26:07 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@ucsd.edu (Tim Evans) Organization: Social Security Admin., Baltimore/Washington Subject: SNMP Packages via Anonymous ftp? Message-Id: <591@oss670.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil What SNMP packages are available via anonymous ftp--and from where? Thanks. -- 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---- <1990110323170700> Received: from SPARK.BRL.MIL by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 01:21:10 PST Date: Sun, 4 Nov 90 4:17:07 EST From: "Robert J. Reschly Jr." To: Ian Heavens cc: tcp-ip@nic.ddn.mil Subject: Re: ttcp Message-ID: <9011040417.aa23837@SPARK.BRL.MIL> Ian, Sorry for the delay, but I wanted to ping Mike Muuss to confirm my understanding. The code for ttcp.c has been placed in the Public Domain, so you can fold, spindle, multilate, and resell to your heart's content. I modified our sources to include an explicit Public Domain comment and updated the anonymous FTP copy on FTP.BRL.MIL (aka VGR.BRL.MIL, 26.2.0.29, 128.64.4.4). Enjoy. 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 / Aberdeen Proving Grounds, MD 21005-5066 / ATTN: SLCBR-SE-A (Reschly) // (301) 278-6808 FAX:-5075 DSN:298- **** For a good time, call: (303) 499-7111. Seriously! **** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110400220000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 19:06:11 PST Received: from TWNCTU01.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4012; Fri, 02 Nov 90 22:06:06 EST Date: Sat, 3 Nov 90 11:02 U From: Subject: annoying n/w problems To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, KCPENG Hi netter, There exist some problems in our network, though not(?) severe but indeed annoying. The net consists of tens of various machine: Vaxs, Suns, HPs, RS6000s, X-terminals... Some observable phenomenons follow: . the Sun 4/370 console keeps printing the message a period of time - 'le0 : No carrier - transceiver cable problem?' of course, it can still do network functions. Other Suns SSs just have no such annoyance. . there are 3 workstations, say A, B and C, networked together. (O) ftp A to B (O) ftp B to C (X) ftp A to C A, B = Sun, C = RS600. (B,C) and (A) are on two different repeter ports. . another 2 hosts, say D and E, connected. (O) telnet D to E (X) telnet E to D (X) telnet D to D these two nodes are not on the same repeter port. I've re-invoked the inetd of D, still in vain. (It seems D can telnet 'out' sometimes before) What I'm concerned are, 1) what's the causes? repeater? cable? others? 2) any utility to monitor the network problems, like re-transmission rate? or you have to put some command, like netstat, in cron table and run it periodically, then do statistics yourself? if so, how do I suppose to know the 'correct'(tolerable) value in all these statistical values? 3) some friend mentioned to me a product called 'cable scanner'. is it helpful to the above problems? Any clue is highly, highly welcome. Regards, Kai-Chih Peng, kcpeng@twnctu01.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110406265000> Received: from ub.d.umn.edu by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 10:23:26 PST Received: by ub.d.umn.edu (5.59/UMD-891211) id AA18370; Sun, 4 Nov 90 12:26:51 CST From: pdurrant@ub.d.umn.edu (Paul Durrant) Message-Id: <9011041826.AA18370@ub.d.umn.edu> Subject: Re: your mail To: TCP-IP-L@VMD.CSO.UIUC.EDU Date: Sun, 4 Nov 90 12:26:50 CST Cc: tcp-ip@nic.ddn.mil In-Reply-To: <9011021948.AA03899@ub.d.umn.edu>; from "TCP-IP-L@VMD.CSO.UIUC.EDU" at Nov 2, 90 5:41 pm X-Mailer: ELM [version 2.3 PL5] > > Unsubcribe me !!! > UNSUBSCRIBE me, too! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011050311.AA15665@ucbvax.Berkeley.EDU] <1990110406525800> From: HANK@BARILVM.BITNET (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: Router scorecard 1.7 Message-ID: <9011050311.AA15665@ucbvax.Berkeley.EDU> Date: 4 Nov 90 06:52:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 458 Posted: Sun Nov 4 07:52:58 1990 CAVEATS ------- The following scorecard tries to compare various multi-protocol routers. The current scorecard mainly contains information for cisco and Wellfleet but any other vendor is welcome to send me a complete set of manuals for their equipment so that I can analyze and update the scorecard. The fact of the matter is that certain features and "gotchas" only appear when testing the actual equipment. I hope that the user population of multi-protocol routers will assist me in making this scorecard as comprehensive as possible so that people who follow do not have to go through what I have gone through. It was difficult to decide whether to include future release notes in this scorecard. I trust the user population in the Internet to take each promise for a "future feature" with a grain of salt and to keep watch on the vendors that indeed they follow through with their promises. All too often vendors state certain features will be available in a certain release and sometimes their deadlines slip. It is advised that people should not base their decisions on the future release notes. [That was a long caveat]. If you have comments, suggestions, additions, or subtractions or corrections, please send them to: HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!) The scorecard will be updated on a monthly basis. This report may be freely reproduced as long as nothing is altered or removed. If you read this report and are not connected to the Internet, you can send your comments to: Hank Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- V1.6 update: Various vendors have been in contact with me but after expressing interest in having an entry for their machine they disappear. Other vendors have tried to change the particular hardware box that is being compared to another box. I hope that vendors will participate in keeping this scorecard up-to-date. -------------------------------------------------------------------- Distribution: cisco@spot.colorado.edu wellfleet@nstn.ns.ca tcpip@nic.ddn.mil ripe@mcsun.eu.net p4200@devvax.tn.cornell.edu Usenet: comp.dcom.lans -------------------------------------------------------------------- Comparison of Multiprotocol Routers Henry Nussbacher November 1990 Version 1.7 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.40 | Rel. 8.3 | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | 7 | - Processor | 30Mhz 68020 | 32MHz 68030 | ??Mhz 68020 | - Memory | 4Mbyte | 4Mbyte | 2Mbyte | - Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | 160Mb/sec | - Boot from | | | | - ROM | Yes | No | No | - Net-boot | | | | - IP | Yes | Rel 5.60 | Yes | - Decnet (MOP) | No | No | No | - Diskette | No | Yes | No | - Another router | Yes | Rel 5.60 | No | - Volatile changes | Yes (b) | No | Yes (h) | - CPU statistics | Yes (c) | No | Yes | - Memory stats | Yes | Yes | Yes | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | Clear, orderly| - Autorestart (d) | Yes | Yes | Yes | - Restart for | | | | config changes | No | Yes | Yes | - Watchdog timer | Yes | Yes | Yes | - Reboot time (e) | 29 sec (f) | 60 sec (j) | 32 sec (i) | - Power-up time (g)| 29 sec | 120 sec (j) | 32 sec (i) | Notes: a. Speed of old AGS bus is 160Mb. b. Volatile changes represents the ability of the router to accept a configuration change that is dynamic that only affects the current running system and once the system is rebooted, the change disappears. c. CPU statistics refers to the ability of the router to provide a monitoring facility to see what the CPU is doing and how often it is doing it. d. Autorestart in the event of a power failure. e. Reboot time refers to the amount of elapsed time needed to perform a logical restart (reboot) from the fastest available media. f. cisco timings are for older AGS system. g. Power-up time refers to the amount of elapsed time needed from the time of a power failure and recovery until the router is up and operational. h. Only available for DECnet and OSPF, and only for a subset of available parameters. i. Booting via Proteon's Intergrated Boot Device, with running diagnostics. j. Timings include CPU and I/O module diagnostics run at power-up. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 4x10Mb | No | - 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb | - 16Mb Token Ring | Rel 8.2 (j) | 4x16Mb | No | - RS232 | 24x64kb | 16x64kb | 14x64kb | - RS449 | 12x64kb | 16x6Mb | 14x64kb | - V.35 | 12x64kb | 16x6Mb | 14x64kb | - X.21 | ?? | 16x6Mb | ?? | - T1 (1.544Mb) | | | | - Serial | 12 | 8 | 14 | - Framed | ?? | 8 | ?? | - CEPT DS1 (2Mb) | | | | - Serial | 12 | 8 | 12 | - Framed | ?? | 8 | ?? | - FDDI | 2x100Mb (l)| 1x100Mb | 2x100Mb | - DAS (Dual) (e)| Yes | Yes | Yes | - SAS (Single) | Yes | No | Yes | - Ultranet | Rel 8.2 (k)| No | ?? | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | 255 | - Card types (g) | 6E, 1E2S, | 2E, 1E1S, 1T,| 1E, 2S, 4S, | per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F (m) | | 1TR, 1F (h)| 1TR2S, 4S, | | | | 1TR, 2TR2S | | | | 1TR1S, 2T, 2C| | Notes: a. Each interface subsection represents the maximum number of LANs or WANS that can be configured for that particular subsection. It is possible to "mix and match" various subsections by reducing the upper limit. b. Thin Ethernet refers to a standard BNC connector available directly on the router. e. Dual is also known as Type A and Single is also known as Type B. f. Depends on memory limitations. g. Card types: E: Ethernet S: Serial/Synchronous line TR: Token-Ring F: FDDI T: Framed T1 C: Framed CEPT (2.048Mbs) h. The 6E and 1F cards are for the faster cBus only. i. The AGS can take 4 Token Rings while the AGS+ can only take 3. j. To be supported in later release of Version 8.2. k. Ultranet support will be in a later release of 8.2 but will only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN. l. 4x100Mb as of Rel 8.2. m. Proteon's FDDI is a 2 card set. 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | Rel 6.0 | No | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | Yes | Yes | - IEEE 802.3 | Yes | Yes | Yes | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | No | - Serial | | | | encapsulation | | | | - HDLC | Yes | Yes | Yes | - LAPB | Yes | Yes | No | - PPP (RFC1134) | Yes | No | No | - DDCMP | No | No | No | - X.25 | | | | - SVC | Yes | Yes | Yes | - PVC | Yes | Yes | Yes | - Encryption (b) | Pulse-time | No | No | - Filtering by | | | | source/dest | Yes | Yes | Yes | Notes: a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D) b. Encryption refers to the ability of the router to compensate for encrypting devices on various interfaces or circuits. c. For CLNP only. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | Yes | - ARP (RFC826) | Yes | Yes | Yes | - RARP (RFC903) | Yes | No | No | - BOOTP (RFC951) | Yes | Rel 5.60 | No | - proxy ARP | | | | (RFC1027) | Yes | Yes | Yes | - ICMP | Yes | Yes | Yes | - Name-server | Yes | No | No | - Accounting | Yes | No | No | - MTU | Yes | Yes | No | - Security - IPSO | Yes | No | No | - Static routing | Yes | Yes | Yes | - Source routing | Yes | Yes | Yes | - Filters | | | | - source/dest | Yes | Yes | Yes | - TCP | Yes | Yes | No | - UDP | Yes | Yes | No | - ICMP | Yes | No | No | - by protocol (b)| Yes (a) | Yes | No | - Routing protocols| | | No | - RIP (RFC1058) | Yes | Yes | Yes | - EGP (RFC904) | Yes | Yes | Yes | - BGP (RFC1105) | Yes | No | No | - Proprietary | IGRP | eRIP | No | - Filtering | Yes | Rel 5.60 | Yes | - Default routes | Yes | Yes | Yes | - OSPF | Rel 9.0 | Rel 5.60 | Yes | Notes: a. Can be done but is difficult and requires advanced knowledge of the specific protocols. b. Filtering by protocol can also be viewed as filtering by port number. 5. DECNET | | | | - Phase IV Router | Yes | Yes | Yes | - Area Router | Yes | Yes | Yes | - Phase IV+ (a) | Rel 8.2 | No | No | - Phase IV-V | | | | Transitional gty | Rel 8.2 | No | No | - Phase V | Yes (b) | No | Yes (b) | - Address xlation | | | | gateway (c) | Yes | No | No | - NCP | | | | - area-max-cost | Yes | Yes | Yes | - area-max-hops | Yes | Yes | Yes | - max-address | Yes | Yes | Yes | - max-area | Yes | Yes | Yes | - max-cost | Yes | Yes | Yes | - max-hops | Yes | Yes | Yes | - max-visits | Yes | Yes | Yes | - router-priority| Yes | Yes | Yes (e) | - hello-timer | Yes | Yes | Yes | - routing-timer | Yes | Yes | Yes | - Filtering | | | | - source/dest | Yes | No | Yes | - by protocol | No | No | No | - by object | No | No | No | - routing | Yes (d) | No | Yes (d) | - MOP | Bridged | Bridged | Yes (f) | - Static routing | No | No | No | - Max routing table| 1023 | 1023 | 1023 | - Max # of broad. | | | | router adjencency| 32 | 128 | ?? | Notes: a. Phase IV+ refers to path-split capability. This means "normal" and not "interim". Normal allows out-of-sequence packets to arrive. Interim does not allow out-of-sequence packets to arrive. b. cisco claims that it's ISO CLNS support is compatible with Decnet Phase V. c. Address Translation Gateway is the ability to connect two separate Decnet networks with overlapping addresses. d. It is not possible to filter out of area addresses. It is only possible to filter an entire area or addresses within one's area. e. On a per circuit basis, as required by DECnet specs. f. MOP System ID. 6. Bridging | | | | - Local bridging | Yes | Yes | No | - LAVC (a) | Yes | Yes | No | - Remote bridging | Yes (b) | Yes | No | - Transparent | | | | - Learning | Yes | Yes | No | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | No | - Priority (c) | Rel 8.2 | Yes (h) | No | - Filtering | | | | - Multicast | Yes | Yes | No | - Protocol | Yes | Yes | No | - Source/dest | Yes | Yes (g) | No | - Masking (d) | No | No | No | - Load sharing | Yes (e) | Yes | No | - Token Ring | | | | - Source route | Yes | Yes | Yes | - Multi-ring (f) | Yes | Yes | No | Notes a. LAVC refers to the ability to act as a local bridge between two Vax clusters using the DEC LAVC protocol. b. cisco does not support bridging over X.25 or LAPB. c. Priority refers to the ability to assign a priority to a specific protocol so that that protocol is sent faster than any other protocol over a specific circuit/interface. d. Masking refers to the ability to specify some pattern string to be matched within the packet, so that the user can specify almost any filter. e. cisco load sharing (balancing) is on a per-node basis and not on a per packet basis. That means that over 2 parallel serial lines the cisco will automatically allocate 50% of the learned Ethernet addresses to one line and the other 50% to the other line. f. Multi-ring refers to bridging between multiple Token Ring networks (all hosts must understand RIF). g. Wellfleet can only filter on destination address and not on source address. h. Priority can be implemented using circuit groups. 7. Other protocols | | | | (ability to route) | | | | - XNS | Yes (a) | Yes | Yes | - UB derivitive | Yes | Yes | Yes | - Appletalk | | | | - Phase 1 | Yes | Yes | Yes | - Phase 2 | Rel 8.2 | Yes | No | - Tokentalk | Rel 8.2 | Yes | No | - Ethertalk | Yes | Yes | Yes | - Localtalk | No | No | No | - RTMP | Yes | Yes | Yes | - AARP | Yes | Yes | Yes | - NBP | Yes | Yes | Yes | - EP | Yes | Yes | Yes | - ATP (c) | Yes | No | Yes | - ZIP | Yes | Yes | Yes | - DDP | Yes | Yes | Yes | - ISO | | | | - ISO 8473 CLNP | Yes | No | Yes | - ISO 9542 ES-IS | Yes | No | Yes | - Apollo Domain | Yes | No | Yes | - Novell IPX | Yes (a) | Yes | Yes | - Banyan Vines | Rel 8.2 | No | No | - X.25 | Yes | Yes | Yes | - bridging | Rel 9.0 | Yes | No | - routing | Yes | Yes | Yes | - switching | Yes | Yes | No | - Security | Yes (b) | Rel 5.60 | No | Notes: a. With cisco equipment, if there are both Ethernet and Token Ring interfaces, then DECnet cannot be run simultaneously with either Novell IPX or XNS. This restriction will be removed in Release 8.2. b. cisco provides filtering/permitting/denying certain packets only for IPX, XNS and Appletalk in the section listed above. c. Not required for correct operation of a Phase II router. 8. Management | | | | - Central managed | Yes | Yes | Yes | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3, Sparc | 80286 AT | - External | | | | software (b) | No (c) | No | No | - X netmap | Yes | Yes | Yes | - Telnet to | | | | device (d) | Yes | Yes | Yes | - X interactive | | | | performance | Yes | Yes | Yes | - History stats | Yes | Yes | No | - Report writer | Yes (c) | No | No | - Alerts (e) | No | No | No | - User defined | | | | extensions (m) | Yes | Yes | No | - Usage stats | Yes | Yes (f) | Yes | - Direct MIB access| No | Yes | No | - PING | Yes | Yes (g) | No | - Traceroute | Yes | No | No | - Telnet | Yes (h) | Yes (i) | Yes (n) | - MOP Remote Cons. | Rel. 8.2 | Bridged | No | - NICE (j) | No | No | No | - Decnet connect | No | No | No | - Passwords (k) | Yes | Yes | Yes | - Disable lines | | | | dynamically | Yes (l) | Yes | Yes | Notes: b. External software refers to the need to have some external software package available in order to run SNMP monitoring. c. cisco requires the Sybase database system in order to run their NMS software. This package is bundled with their NMS. d. Ability to click on an icon on the X-11 network map and open a telnet connection to the device in question. e. Alerts refers to the ability to define a preset limit for a specific MIB variable at which point the SNMP monitoring software will present a window on top of the network map informing the network operator of the problem. f. Wellfleet interactive usage statistics are only for (ISO model) level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet HELLO, ARP) are not available. g. Wellfleet PING command stops after first failure and waits for user response. This makes it very hard to check the total percentage of line failures over a short period of time. h. cisco is limited to 5 incoming Telnet sessions but has no limitation on outgoing Telnet sessions. i. Wellfleet Telnet is limited to one incoming and one outgoing session. j. NICE refers to the ability of the router to accept "SET EXECUTOR" as well as initiate a "SET EXECUTOR" to a remote host. k. Passwords refers to the ability to limit certain configuration and customization options only to those users who supply a password. l. cisco command is not an EXEC command but actually requires a configuration change to disable a line. m. The ability for the NMS software to add other vendor MIBs to their database, in order to manage these particular hardware units. n. Proteon is limited to 2 incoming and no outgoing sessions. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | Yes | - LAN | Yes | Yes | Yes | - Link | Yes | Yes | Yes | - Decnet | Yes | Yes | Yes | - Tcp/Ip | Yes | Yes | Yes | - Event log | Yes | Yes | Yes | - Network Logging| Yes | Yes | ?? | - Local Storage | No | Yes | ?? | - Environmentals | Yes | No | No | Notes: a. Environmentals refers to the monitoring of variables such as fan, power supply, memory, temperature, etc. 10. Performance (a) | | | | - Router forward | 4494 | 4494 | 1493 | - Router filter | 4494 | 4494 | 1248 | - Bridge forward | 4494 | 4494 | N/A | - Bridge filter | 4494 | 4494 | N/A | - LAT compression | Yes | No | No | Notes: a. Performance based on 256 byte IP packets, between separate interface cards, with no packet loss. Numbers listed are in packets per second. Numbers based on Bradner report #3, Harvard University, Oct 1990. 11. Survivability | | | | - alternate power | | | | supply | No | Yes (d) | No | - standby line (a)| No | No | No | - fault tolerant(b)| No | No | No | - field tolerant(c)| No | No | No | - broadcast storms | Yes | Yes | Yes | Notes: a. Standby line refers to the ability to define a line that is to be a hot standby, in the event that the primary line goes down. The software switches all traffic automatically to the backup line. b. Fault tolerant refers to having redundent systems that are normally in standby mode, and that are only called into active mode in the event that the primary system fails. Various systems are the power supply, the fan, the bus, the controller cards, etc. c. Field tolerant refers to the ability to withstand harsh elements and conditions out in the "field." d. Alternate power supply only available in large Concentrator model. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110412225800> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 15:55:14 PST Received: from VM.BIU.AC.IL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6620; Sun, 04 Nov 90 18:55:06 EST Received: from BARILVM (HANK) by VM.BIU.AC.IL (Mailer R2.03B) with BSMTP id 2273; Sun, 04 Nov 90 08:53:53 O Date: Sun, 04 Nov 90 08:52:58 O From: Hank Nussbacher Subject: Router scorecard 1.7 To: cisco@spot.colorado.edu, wellfleet-l@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu CAVEATS ------- The following scorecard tries to compare various multi-protocol routers. The current scorecard mainly contains information for cisco and Wellfleet but any other vendor is welcome to send me a complete set of manuals for their equipment so that I can analyze and update the scorecard. The fact of the matter is that certain features and "gotchas" only appear when testing the actual equipment. I hope that the user population of multi-protocol routers will assist me in making this scorecard as comprehensive as possible so that people who follow do not have to go through what I have gone through. It was difficult to decide whether to include future release notes in this scorecard. I trust the user population in the Internet to take each promise for a "future feature" with a grain of salt and to keep watch on the vendors that indeed they follow through with their promises. All too often vendors state certain features will be available in a certain release and sometimes their deadlines slip. It is advised that people should not base their decisions on the future release notes. [That was a long caveat]. If you have comments, suggestions, additions, or subtractions or corrections, please send them to: HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!) The scorecard will be updated on a monthly basis. This report may be freely reproduced as long as nothing is altered or removed. If you read this report and are not connected to the Internet, you can send your comments to: Hank Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel [The above employer has nothing to do with this scorecard so if something bothers you about it, I take full responsibility.] END OF CAVEATS -------------------------------------------------------------------- V1.6 update: Various vendors have been in contact with me but after expressing interest in having an entry for their machine they disappear. Other vendors have tried to change the particular hardware box that is being compared to another box. I hope that vendors will participate in keeping this scorecard up-to-date. -------------------------------------------------------------------- Distribution: cisco@spot.colorado.edu wellfleet@nstn.ns.ca tcpip@nic.ddn.mil ripe@mcsun.eu.net p4200@devvax.tn.cornell.edu Usenet: comp.dcom.lans -------------------------------------------------------------------- Comparison of Multiprotocol Routers Henry Nussbacher November 1990 Version 1.7 +--------------+--------------+---------------+ Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 | Router | Rel. 8.1(14) | Rel. 5.40 | Rel. 8.3 | +--------------+--------------+---------------+ 1. General | | | | - # of slots | 9 | 4 | 7 | - Processor | 30Mhz 68020 | 32MHz 68030 | ??Mhz 68020 | - Memory | 4Mbyte | 4Mbyte | 2Mbyte | - Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP | - Speed of bus | 530Mb/sec (a)| 320Mb/sec | 160Mb/sec | - Boot from | | | | - ROM | Yes | No | No | - Net-boot | | | | - IP | Yes | Rel 5.60 | Yes | - Decnet (MOP) | No | No | No | - Diskette | No | Yes | No | - Another router | Yes | Rel 5.60 | No | - Volatile changes | Yes (b) | No | Yes (h) | - CPU statistics | Yes (c) | No | Yes | - Memory stats | Yes | Yes | Yes | - Ease of install | Very easy | menu driven | | - Documentation | Difficult | Skimpy | Clear, orderly| - Autorestart (d) | Yes | Yes | Yes | - Restart for | | | | config changes | No | Yes | Yes | - Watchdog timer | Yes | Yes | Yes | - Reboot time (e) | 29 sec (f) | 60 sec (j) | 32 sec (i) | - Power-up time (g)| 29 sec | 120 sec (j) | 32 sec (i) | Notes: a. Speed of old AGS bus is 160Mb. b. Volatile changes represents the ability of the router to accept a configuration change that is dynamic that only affects the current running system and once the system is rebooted, the change disappears. c. CPU statistics refers to the ability of the router to provide a monitoring facility to see what the CPU is doing and how often it is doing it. d. Autorestart in the event of a power failure. e. Reboot time refers to the amount of elapsed time needed to perform a logical restart (reboot) from the fastest available media. f. cisco timings are for older AGS system. g. Power-up time refers to the amount of elapsed time needed from the time of a power failure and recovery until the router is up and operational. h. Only available for DECnet and OSPF, and only for a subset of available parameters. i. Booting via Proteon's Intergrated Boot Device, with running diagnostics. j. Timings include CPU and I/O module diagnostics run at power-up. 2. Interfaces (a) | | | | - Ethernet | | | | (802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb | - Thin Ethernet (b)| | | | (802.3 10Base2) | No | 4x10Mb | No | - 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb | - 16Mb Token Ring | Rel 8.2 (j) | 4x16Mb | No | - RS232 | 24x64kb | 16x64kb | 14x64kb | - RS449 | 12x64kb | 16x6Mb | 14x64kb | - V.35 | 12x64kb | 16x6Mb | 14x64kb | - X.21 | ?? | 16x6Mb | ?? | - T1 (1.544Mb) | | | | - Serial | 12 | 8 | 14 | - Framed | ?? | 8 | ?? | - CEPT DS1 (2Mb) | | | | - Serial | 12 | 8 | 12 | - Framed | ?? | 8 | ?? | - FDDI | 2x100Mb (l)| 1x100Mb | 2x100Mb | - DAS (Dual) (e)| Yes | Yes | Yes | - SAS (Single) | Yes | No | Yes | - Ultranet | Rel 8.2 (k)| No | ?? | - X.25 | | | | - Max # of VCs | Unlimited (f)| 254 | 255 | - Card types (g) | 6E, 1E2S, | 2E, 1E1S, 1T,| 1E, 2S, 4S, | per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F (m) | | 1TR, 1F (h)| 1TR2S, 4S, | | | | 1TR, 2TR2S | | | | 1TR1S, 2T, 2C| | Notes: a. Each interface subsection represents the maximum number of LANs or WANS that can be configured for that particular subsection. It is possible to "mix and match" various subsections by reducing the upper limit. b. Thin Ethernet refers to a standard BNC connector available directly on the router. e. Dual is also known as Type A and Single is also known as Type B. f. Depends on memory limitations. g. Card types: E: Ethernet S: Serial/Synchronous line TR: Token-Ring F: FDDI T: Framed T1 C: Framed CEPT (2.048Mbs) h. The 6E and 1F cards are for the faster cBus only. i. The AGS can take 4 Token Rings while the AGS+ can only take 3. j. To be supported in later release of Version 8.2. k. Ultranet support will be in a later release of 8.2 but will only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN. l. 4x100Mb as of Rel 8.2. m. Proteon's FDDI is a 2 card set. 3. Interface part II | | | | - Frame Relay (a) | Rel 8.2 | Rel 6.0 | No | - Ethernet | | | | encapsulation | | | | - Standard v2.0 | Yes | Yes | Yes | - IEEE 802.3 | Yes | Yes | Yes | - SNAP 802.2 | | | | (RFC1042) | Yes | Yes | No | - Serial | | | | encapsulation | | | | - HDLC | Yes | Yes | Yes | - LAPB | Yes | Yes | No | - PPP (RFC1134) | Yes | No | No | - DDCMP | No | No | No | - X.25 | | | | - SVC | Yes | Yes | Yes | - PVC | Yes | Yes | Yes | - Encryption (b) | Pulse-time | No | No | - Filtering by | | | | source/dest | Yes | Yes | Yes | Notes: a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D) b. Encryption refers to the ability of the router to compensate for encrypting devices on various interfaces or circuits. c. For CLNP only. 4. IP | | | | - Subnetting | | | | (RFC950) | Yes | Yes | Yes | - ARP (RFC826) | Yes | Yes | Yes | - RARP (RFC903) | Yes | No | No | - BOOTP (RFC951) | Yes | Rel 5.60 | No | - proxy ARP | | | | (RFC1027) | Yes | Yes | Yes | - ICMP | Yes | Yes | Yes | - Name-server | Yes | No | No | - Accounting | Yes | No | No | - MTU | Yes | Yes | No | - Security - IPSO | Yes | No | No | - Static routing | Yes | Yes | Yes | - Source routing | Yes | Yes | Yes | - Filters | | | | - source/dest | Yes | Yes | Yes | - TCP | Yes | Yes | No | - UDP | Yes | Yes | No | - ICMP | Yes | No | No | - by protocol (b)| Yes (a) | Yes | No | - Routing protocols| | | No | - RIP (RFC1058) | Yes | Yes | Yes | - EGP (RFC904) | Yes | Yes | Yes | - BGP (RFC1105) | Yes | No | No | - Proprietary | IGRP | eRIP | No | - Filtering | Yes | Rel 5.60 | Yes | - Default routes | Yes | Yes | Yes | - OSPF | Rel 9.0 | Rel 5.60 | Yes | Notes: a. Can be done but is difficult and requires advanced knowledge of the specific protocols. b. Filtering by protocol can also be viewed as filtering by port number. 5. DECNET | | | | - Phase IV Router | Yes | Yes | Yes | - Area Router | Yes | Yes | Yes | - Phase IV+ (a) | Rel 8.2 | No | No | - Phase IV-V | | | | Transitional gty | Rel 8.2 | No | No | - Phase V | Yes (b) | No | Yes (b) | - Address xlation | | | | gateway (c) | Yes | No | No | - NCP | | | | - area-max-cost | Yes | Yes | Yes | - area-max-hops | Yes | Yes | Yes | - max-address | Yes | Yes | Yes | - max-area | Yes | Yes | Yes | - max-cost | Yes | Yes | Yes | - max-hops | Yes | Yes | Yes | - max-visits | Yes | Yes | Yes | - router-priority| Yes | Yes | Yes (e) | - hello-timer | Yes | Yes | Yes | - routing-timer | Yes | Yes | Yes | - Filtering | | | | - source/dest | Yes | No | Yes | - by protocol | No | No | No | - by object | No | No | No | - routing | Yes (d) | No | Yes (d) | - MOP | Bridged | Bridged | Yes (f) | - Static routing | No | No | No | - Max routing table| 1023 | 1023 | 1023 | - Max # of broad. | | | | router adjencency| 32 | 128 | ?? | Notes: a. Phase IV+ refers to path-split capability. This means "normal" and not "interim". Normal allows out-of-sequence packets to arrive. Interim does not allow out-of-sequence packets to arrive. b. cisco claims that it's ISO CLNS support is compatible with Decnet Phase V. c. Address Translation Gateway is the ability to connect two separate Decnet networks with overlapping addresses. d. It is not possible to filter out of area addresses. It is only possible to filter an entire area or addresses within one's area. e. On a per circuit basis, as required by DECnet specs. f. MOP System ID. 6. Bridging | | | | - Local bridging | Yes | Yes | No | - LAVC (a) | Yes | Yes | No | - Remote bridging | Yes (b) | Yes | No | - Transparent | | | | - Learning | Yes | Yes | No | - Spanning tree | | | | (IEEE 802.1) | Yes | Yes | No | - Priority (c) | Rel 8.2 | Yes (h) | No | - Filtering | | | | - Multicast | Yes | Yes | No | - Protocol | Yes | Yes | No | - Source/dest | Yes | Yes (g) | No | - Masking (d) | No | No | No | - Load sharing | Yes (e) | Yes | No | - Token Ring | | | | - Source route | Yes | Yes | Yes | - Multi-ring (f) | Yes | Yes | No | Notes a. LAVC refers to the ability to act as a local bridge between two Vax clusters using the DEC LAVC protocol. b. cisco does not support bridging over X.25 or LAPB. c. Priority refers to the ability to assign a priority to a specific protocol so that that protocol is sent faster than any other protocol over a specific circuit/interface. d. Masking refers to the ability to specify some pattern string to be matched within the packet, so that the user can specify almost any filter. e. cisco load sharing (balancing) is on a per-node basis and not on a per packet basis. That means that over 2 parallel serial lines the cisco will automatically allocate 50% of the learned Ethernet addresses to one line and the other 50% to the other line. f. Multi-ring refers to bridging between multiple Token Ring networks (all hosts must understand RIF). g. Wellfleet can only filter on destination address and not on source address. h. Priority can be implemented using circuit groups. 7. Other protocols | | | | (ability to route) | | | | - XNS | Yes (a) | Yes | Yes | - UB derivitive | Yes | Yes | Yes | - Appletalk | | | | - Phase 1 | Yes | Yes | Yes | - Phase 2 | Rel 8.2 | Yes | No | - Tokentalk | Rel 8.2 | Yes | No | - Ethertalk | Yes | Yes | Yes | - Localtalk | No | No | No | - RTMP | Yes | Yes | Yes | - AARP | Yes | Yes | Yes | - NBP | Yes | Yes | Yes | - EP | Yes | Yes | Yes | - ATP (c) | Yes | No | Yes | - ZIP | Yes | Yes | Yes | - DDP | Yes | Yes | Yes | - ISO | | | | - ISO 8473 CLNP | Yes | No | Yes | - ISO 9542 ES-IS | Yes | No | Yes | - Apollo Domain | Yes | No | Yes | - Novell IPX | Yes (a) | Yes | Yes | - Banyan Vines | Rel 8.2 | No | No | - X.25 | Yes | Yes | Yes | - bridging | Rel 9.0 | Yes | No | - routing | Yes | Yes | Yes | - switching | Yes | Yes | No | - Security | Yes (b) | Rel 5.60 | No | Notes: a. With cisco equipment, if there are both Ethernet and Token Ring interfaces, then DECnet cannot be run simultaneously with either Novell IPX or XNS. This restriction will be removed in Release 8.2. b. cisco provides filtering/permitting/denying certain packets only for IPX, XNS and Appletalk in the section listed above. c. Not required for correct operation of a Phase II router. 8. Management | | | | - Central managed | Yes | Yes | Yes | - SNMP | | | | - Platform | Sun 3, Sparc | Sun 3, Sparc | 80286 AT | - External | | | | software (b) | No (c) | No | No | - X netmap | Yes | Yes | Yes | - Telnet to | | | | device (d) | Yes | Yes | Yes | - X interactive | | | | performance | Yes | Yes | Yes | - History stats | Yes | Yes | No | - Report writer | Yes (c) | No | No | - Alerts (e) | No | No | No | - User defined | | | | extensions (m) | Yes | Yes | No | - Usage stats | Yes | Yes (f) | Yes | - Direct MIB access| No | Yes | No | - PING | Yes | Yes (g) | No | - Traceroute | Yes | No | No | - Telnet | Yes (h) | Yes (i) | Yes (n) | - MOP Remote Cons. | Rel. 8.2 | Bridged | No | - NICE (j) | No | No | No | - Decnet connect | No | No | No | - Passwords (k) | Yes | Yes | Yes | - Disable lines | | | | dynamically | Yes (l) | Yes | Yes | Notes: b. External software refers to the need to have some external software package available in order to run SNMP monitoring. c. cisco requires the Sybase database system in order to run their NMS software. This package is bundled with their NMS. d. Ability to click on an icon on the X-11 network map and open a telnet connection to the device in question. e. Alerts refers to the ability to define a preset limit for a specific MIB variable at which point the SNMP monitoring software will present a window on top of the network map informing the network operator of the problem. f. Wellfleet interactive usage statistics are only for (ISO model) level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet HELLO, ARP) are not available. g. Wellfleet PING command stops after first failure and waits for user response. This makes it very hard to check the total percentage of line failures over a short period of time. h. cisco is limited to 5 incoming Telnet sessions but has no limitation on outgoing Telnet sessions. i. Wellfleet Telnet is limited to one incoming and one outgoing session. j. NICE refers to the ability of the router to accept "SET EXECUTOR" as well as initiate a "SET EXECUTOR" to a remote host. k. Passwords refers to the ability to limit certain configuration and customization options only to those users who supply a password. l. cisco command is not an EXEC command but actually requires a configuration change to disable a line. m. The ability for the NMS software to add other vendor MIBs to their database, in order to manage these particular hardware units. n. Proteon is limited to 2 incoming and no outgoing sessions. 9. Debugging & | | | | Monitoring | | | | - Data-Link Layer | Yes | Yes | Yes | - LAN | Yes | Yes | Yes | - Link | Yes | Yes | Yes | - Decnet | Yes | Yes | Yes | - Tcp/Ip | Yes | Yes | Yes | - Event log | Yes | Yes | Yes | - Network Logging| Yes | Yes | ?? | - Local Storage | No | Yes | ?? | - Environmentals | Yes | No | No | Notes: a. Environmentals refers to the monitoring of variables such as fan, power supply, memory, temperature, etc. 10. Performance (a) | | | | - Router forward | 4494 | 4494 | 1493 | - Router filter | 4494 | 4494 | 1248 | - Bridge forward | 4494 | 4494 | N/A | - Bridge filter | 4494 | 4494 | N/A | - LAT compression | Yes | No | No | Notes: a. Performance based on 256 byte IP packets, between separate interface cards, with no packet loss. Numbers listed are in packets per second. Numbers based on Bradner report #3, Harvard University, Oct 1990. 11. Survivability | | | | - alternate power | | | | supply | No | Yes (d) | No | - standby line (a)| No | No | No | - fault tolerant(b)| No | No | No | - field tolerant(c)| No | No | No | - broadcast storms | Yes | Yes | Yes | Notes: a. Standby line refers to the ability to define a line that is to be a hot standby, in the event that the primary line goes down. The software switches all traffic automatically to the backup line. b. Fault tolerant refers to having redundent systems that are normally in standby mode, and that are only called into active mode in the event that the primary system fails. Various systems are the power supply, the fan, the bus, the controller cards, etc. c. Field tolerant refers to the ability to withstand harsh elements and conditions out in the "field." d. Alternate power supply only available in large Concentrator model. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110413382800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 23:34:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20433; Sun, 4 Nov 90 23:23:32 -0800 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 Nov 90 13:38:28 GMT From: tiamat!chromc!dynasys!jessea@uunet.uu.net (Jesse W. Asher) Organization: Dynasys: Consulting for the Future. Subject: Re: Internet/NSFNet proposal - what should we do? Message-Id: <722@dynasys.UUCP> References: <1990Oct28.220432.521@ddsw1.MCS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Oct28.220432.521@ddsw1.MCS.COM>, karl@mcs.MCS.COM (Karl Denninger) wrote the following: >This is a call to action by all interested parties. > >There is wind of a proposal stirring in Washington that would place the >NSFNet backbone, and eventually the entire government-run part of the >Internet, into the hands of IBM. Is there anything besides calling our elected officials that we can do? Anyone else we should write to? Should we have an overall plan of attack? I know the modem line surcharge that was proposed a while back was hacked because of the coordinated outpouring of indignation. Let's do the same thing with this crap. Most of us think its a bad idea so let's stop saying it's a bad idea and do something about it. Ideas anyone? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110414570000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 09:13:02 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id ad12112; 4 Nov 90 9:59 EST Date: Sun, 4 Nov 90 14:57 GMT From: Bob Stine <0004219666@mcimail.com> To: Tim Evans Cc: tcp ip Subject: RE: SNMP Packages via Anonymous ftp? Message-Id: <43901104145734/0004219666NB1EM@mcimail.com> >What SNMP packages are available via anonymous ftp--and from where? (I apologize to the list for sounding like a broken record, but...) Check RFC 1147. It describes, and tells how to get, many free and commercial products for managing TCP/IP internets. In particular, it tells how to get CMU's SNMP and MIT's SNMP via anonymous FTP. - Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110418220000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 10:48:57 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07059; Sun, 4 Nov 90 10:48:00 -0800 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 Nov 90 18:22:00 GMT From: usc!cs.utexas.edu!sun-barr!newstop!texsun!netdev!alex@ucsd.edu (Alex Huppenthal) Organization: Communication Systems Research, Dallas, Tx 75252 Subject: Public Domain PPP Available? Message-Id: <6@netdev.comsys.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Looking for PPP freely-available software. Please respond by E-mail. -Alex -- alex@netdev.comsys.com Communication Systems Research {cs.utexas.edu}!texsun!netdev!alex Dallas, Texas 75252 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110421563100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 16:21:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12442; Sun, 4 Nov 90 16:17:23 -0800 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 Nov 90 21:56:31 GMT From: mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net (Piercarlo Grandi) Organization: Coleg Prifysgol Cymru Subject: Re: Cost of Internet access Message-Id: References: <1990Oct28.220432.521@ddsw1.MCS.COM>, <132136@pyramid.pyramid.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On 3 Nov 90 07:27:22 GMT, mcb@presto.ig.com (Michael C. Berch) said: [ ... on cheaper Internet access ... ] mcb> Unless you meant some sort of access that would only be a few hours mcb> per day, which misses the main advantage of Internet access in the mcb> first place, which is real-time access to a large set of mcb> distributed resources. As an Internet user I can sit at my mcb> workstation during business hours and log in to remote accounts, mcb> FTP files to and from arbitrary locations all over the world, and mcb> send and receive mail that arrives in seconds or minutes. All these goodies COST MONEY. If you are the one signing the cheques and you are given an option between instant service during business hours at 3X and evenings at X, maybe you think more than three times about the choice. mcb> Dial-up SLIP or PPP on an after-hours batched basis can't offer those mcb> services and do not, to my mind, provide much of an advantage over mcb> dial-up UUCP. "Real" Internet access, to me, means real-time access. Note that dialup IP connections are indeed non batched -- it is applications that would be batched, waiting for the IP connection to be established. Just like sendmail does today wih SMTP. The difference between dialup IP and dialup UUCP is that UUCP can only be offline, while IP can also be online. The difference between dialup IP and direct link IP is that dialup IP does not give continuous access, but only on request. It is up to you do delay the request or not. So the issue is not batched vs. online, but continuous vs. on demand. Once we all have ISDN and IP over ISDN we will all have continuous IP at the same price as dialup IP; for now, dedicated lines offering continuous Internet connectivity are expensive... -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110422175300> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 06:51:25 PST Received: from timbuk.cray.com by Note.NSF.GOV id aa12076; 5 Nov 90 9:16 EST Received: from berserkly.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA25190; Mon, 5 Nov 90 08:18:40 CST Received: by berserkly.cray.com id AA04240; 5.64/CRI-4.4; Mon, 5 Nov 90 08:17:53 -0600 Date: Mon, 5 Nov 90 08:17:53 -0600 From: David Borman Message-Id: <9011051417.AA04240@berserkly.cray.com> To: BILLW@mathom.cisco.com, mmorse@z.nsf.gov Subject: Re: Problem with Xmodem and 3Com terminal server Cc: tcp-ip@NSF.GOV > Also, some telnet implementations ignore the "7-bit" definition, and > routinely send 8 bit data anyway. This is useful, but means that a > telnet terminal server strictly adhering to the standard might not work > as well as one with a more flexible interpretation. The Hosts Requirement > document was carefully worded to allow 8-bit transmission, as long as > you were doing actual "parity". ^^^^^^^^^^ > Bill Westfield That should have been "were NOT doing"... I assume that Bill just made a typeo. Everyone should be aware that the Hosts Requirement document was carefully worded to allow 8-bit transmission while in Telnet NVT mode, but we were very explicit that the eighth bit is NOT a "parity" bit, and any implementation that transmits 7-bit data with the eighth bit as a parity bit is broken. -David Borman, dab@cray.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110422470700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 15:19:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11255; Sun, 4 Nov 90 15:06:20 -0800 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 Nov 90 22:47:07 GMT From: prism!prism.gatech.EDU!ce1zzes@gatech.edu (Eric Sheppard) Organization: Georgia Institute of Technology Subject: NCSA Telnet question Message-Id: <16367@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file. I've set an environment variable CONFIGTEL to point to this file (as mentioned in the docs), but the programs still can't find it. Is the environment variable different? Eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110422532400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 4 Nov 90 15:19:24 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11265; Sun, 4 Nov 90 15:06:37 -0800 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 Nov 90 22:53:24 GMT From: prism!prism.gatech.EDU!ce1zzes@gatech.edu (Eric Sheppard) Organization: Georgia Institute of Technology Subject: Mail for PC with Ethernet? Message-Id: <16368@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil What are the various packages available that can process (send and receive) mail on the PC platform? I'm hooked up to the Ethernet with a 3C503 card, and I'm currently using packet drivers with it. I've experimented with MUSH a bit, but I couldn't get it to work; probably missing some important pieces. What is out there? Eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110501273100> Received: from nisc.jvnc.net by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 06:47:23 PST Received: by nisc.jvnc.net (5.61/1.34) id AA16140; Mon, 5 Nov 90 09:47:31 -0500 Date: Mon, 5 Nov 90 09:47:31 -0500 From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) Message-Id: <9011051447.AA16140@nisc.jvnc.net> To: icarus.eng.ohio-state.edu!kaul@tut.cis.ohio-state.edu Subject: Re: Configuring a Sun to use DNS Cc: tcp-ip@nic.ddn.mil > 3c. Remove the libresolv module that contains `strncasecmp' (which is now > in the main C library, so it is redundant): > # rm strcasecmp.o The present 4.8.3 bind distribution also has some other "strxxx" routines- any problems if these are also included in the shared library ? (these routines are not present in the Sun libresolv or in the libc provided). I allude to the following routines provided with the bind 4.8.3 distribution: herror.o mktemp.o strerror.o strpbrk.o -vikas vikas@nisc.jvnc.net (609) 258-2403 -------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110504071000> Received: from nisc.jvnc.net by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 09:26:45 PST Received: by nisc.jvnc.net (5.61/1.34) id AA16922; Mon, 5 Nov 90 12:27:10 -0500 Date: Mon, 5 Nov 90 12:27:10 -0500 From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) Message-Id: <9011051727.AA16922@nisc.jvnc.net> To: tcp-ip@nic.ddn.mil Subject: SENDMAIL configuration I have spent enough time trying to figure it out for myself, and now I want to know if there is an easier way... I am trying to set up sendmail on our Sun 4, and I have the latest version of bind and sendmail (with MX kludge, etc, etc) running. I have a host, call it "A.FOO.NET", and I wanted that mail addresses of the form "user@foo.net" be accepted by the mailer on A.FOO.NET. I set up an MX record for FOO.NET which points to A.FOO.NET so that mail destined for "user@foo.net" gets to this host atleast. My problem lies in the A.FOO.NET mailer accepting the fact that mail addressed to "user@foo.net" actually implies itself. I am using the standard Berkeley config files, and finally got the whole thing to work by adding ruleset 8 where I replaced an occurrence of "@DOMAIN" with "@host.domain". I have bounced mail of berkley.edu (a.k.a ucbvax.berkeley.edu) and noticed that that mailer does not do any replacement stuff. I would prefer to do something like that. Can I create a name server entry where "A.FOO.NET" is a CNAME for "FOO.NET" - then the resolver routines will automagically replace the FOO.NET with A.FOO.NET - but maybe my nameserver will choke... Any ideas / suggestions (postmaster@berkeley.edu ....?!!) ?? -vikas vikas@nisc.jvnc.net (609) 258-2403 -------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110504414300> Received: from note.nsf.gov by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 12:53:06 PST Received: from mathom.cisco.com by Note.NSF.GOV id aa02379; 5 Nov 90 15:42 EST Date: Mon 5 Nov 90 12:41:43-PST From: William Chops Westfield Subject: Re: Problem with Xmodem and 3Com terminal server To: dab@berserkly.cray.com cc: mmorse@z.nsf.gov, tcp-ip@NSF.GOV In-Reply-To: <9011051417.AA04240@berserkly.cray.com> Message-ID: <12635566849.26.BILLW@mathom.cisco.com> From: David Borman > you were doing actual "parity". ^^^^^^^^^^ > Bill Westfield That should have been "were NOT doing"... oops. It was a typo, and Dave is exactly correct. Sorry BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110505014500> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 10:26:49 PST To: tcp-ip@nic.ddn.mil cc: jcurran@SH.CS.NET Subject: Re: Cost of Internet access Date: Mon, 05 Nov 90 13:21:45 -0500 From: jcurran@SH.CS.NET Dialup IP services are quite inexpensive, and if set up with care will give all the advantages of a dedicated circuit only with an occasional 30 second delay (those times when the line must be brought up.) Yes, dedicated circuits are very nice. But if it takes a dial-up line to get some companies on the Internet, then so be it. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110507550800> Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 16:59:34 PST Received: from wrs.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA01293; Mon, 5 Nov 90 18:56:44 -0500 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA29972; Mon, 5 Nov 90 15:53:38 PST Received: from daahoud.WRS.COM by yuba.WRS.COM (4.0/SMI-4.0) id AA28967; Mon, 5 Nov 90 15:55:09 PST Date: Mon, 5 Nov 90 15:55:08 PST From: wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae) Message-Id: <9011052355.AA28967@yuba.WRS.COM> To: jackson@neon.stanford.edu, uunet!asylum.sf.ca.us!romkey@uunet.UU.NET Subject: Re: TCP/IP Source Code Search Cc: tcp-ip@nic.ddn.mil >Many people use the Berkeley code as a start. It's an excellent >protocol engine; its main drawback is that it really really wants to >live inside a UNIX kernel. It often takes many man-months to port >properly. You can find it on uunet.uu.net for anonymous FTP. berkeley code is actually pretty portable. it's really not that hard to port berkeley code to non-unix environment. you need to write a set of compatible routines -- spl*(), splx() can be emulated using semaphores, timeout() can be emulated in most operating systems that support watchdog timers of some sort, sleep() (kernel version) can be done via a semaphore or mailbox, wakeup() the same way, perror() and panic() are trivial, cluster mbuf can be emulated if you change the mbuf structure slightly even on systems that lack virtual memory, etc. i'm speaking from my experience... your mileage may vary. hwajin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110508125700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 02:50:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24315; Mon, 5 Nov 90 02:40:46 -0800 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 Nov 90 08:12:57 GMT From: uupsi!sunic!lth.se!newsuser@nyu.edu (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: NCSA Telnet question Message-Id: <1990Nov5.081257.25872@lth.se> References: <16367@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <16367@hydra.gatech.EDU> ce1zzes@prism.gatech.EDU (Eric Sheppard) writes: >I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file. >I've set an environment variable CONFIGTEL to point to this file (as >mentioned in the docs), but the programs still can't find it. Is the >environment variable different? > I have a .bat file containing the line: d:\ncsa\telbin -h d:\ncsa\config.tel %1 %2 %3 %4 %5 ( I don't remember why it looks like this - it was some time ago since I installed it.) The version inquestion is 2.2DSb, but don't take the version letters too seriously; it's been modified for use with Swedish national characters. The basic program is the same though... -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110510292700> Received: from Relay.Prime.COM by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 12:48:07 PST Received: (from user ALLEN) by Relay.Prime.COM; 05 Nov 90 15:29:27 EST To: tcp-ip@nic.ddn.mil From: Christopher Allen (SIBU Special Systems) Subject: Wanted: IP directly over HDLC Date: 05 Nov 90 15:29:27 EST Hi, We have an opportunity here to productize a capability of doing IP over serial lines. The way I've prototyped this is to encapsulate IP datagrams directly into HDLC framing (ISO 3309), without any of the "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. We were wondering if there are any implementations out there that are also able to do this. Both Wellfleet and cisco boxes come to mind, but are there any other implementations that can do this in a non-proprietary manner? Note: I am aware of PPP and am not interested in implementing it as a solution at this time. Please email me directly; I will post a summary if enough interest. -Chris Allen allen@relay.prime.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011051402.AA27213@ucbvax.Berkeley.EDU] <1990110511250000> From: CBAD33@UCVAX.ULSTER.AC.UK Newsgroups: comp.protocols.tcp-ip Subject: help Message-ID: <9011051402.AA27213@ucbvax.Berkeley.EDU> Date: 5 Nov 90 11:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Posted: Mon Nov 5 12:25:00 1990 Could you please help me. I am trying to gather addresses of companies/ academic institutions who are involved with Wide Area Distribution of Geographic Information. This would involve the capture of aerial photographs, digitizing the image, and transferring the resultant material from location to location, based on requirements. Thus, workstations would exist at key sites around the Area, displaying the information to users who access it for particular applications (line maps with data superimposed showing drainage/ telephone cables/elecdtrical ducts), maybe even the location of medical facilities on a town/city map, which would be of interest to planners etc. The obvious problem to the communications engineer, is how to best provide a communications infrastructure to service such a facility at many locations. The problem is compounded by the time scales and class of data being transferred. A user requesting a raster image of a node of a particular line map will want to see the hotel/hospital/golf course that has been highlighted by the mouse, so the amount of information required to satisfy the query is suddenly increased many fold. The time scale is such that one does not want the user to have to wait minutes while this image is transferred from a server located somewhere. What I would like is any clues as to who is involved in this area, that includes companies/universities/real=life commercial/research institutions etc. I can assure you that any information will only be used for research purposes. I would require the e.mail addresses or postal addresses of the places concerned. Please direct your replies to my e.mail address. Thanks for your time Dr Gerard Parr Department of Applied Computing Institute of InformAtics University of Ulster Derry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110511250001> Received: from pucc.PRINCETON.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 04:20:09 PST Received: from UKACRL.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9085; Mon, 05 Nov 90 07:19:36 EST Received: from RL.IB by UKACRL.BITNET (Mailer R2.03B) with BSMTP id 3680; Mon, 05 Nov 90 11:35:47 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.03B) with BSMTP id 3209; Mon, 05 Nov 90 11:35:47 GMT Via: UK.AC.ULST.UCVAX; 5 NOV 90 11:35:43 GMT Date: Mon, 5 Nov 90 11:25 GMT From: CBAD33%UCVAX.ULSTER.AC.UK@pucc.PRINCETON.EDU To: TCP-IP@NIC.DDN.MIL Subject: help Could you please help me. I am trying to gather addresses of companies/ academic institutions who are involved with Wide Area Distribution of Geographic Information. This would involve the capture of aerial photographs, digitizing the image, and transferring the resultant material from location to location, based on requirements. Thus, workstations would exist at key sites around the Area, displaying the information to users who access it for particular applications (line maps with data superimposed showing drainage/ telephone cables/elecdtrical ducts), maybe even the location of medical facilities on a town/city map, which would be of interest to planners etc. The obvious problem to the communications engineer, is how to best provide a communications infrastructure to service such a facility at many locations. The problem is compounded by the time scales and class of data being transferred. A user requesting a raster image of a node of a particular line map will want to see the hotel/hospital/golf course that has been highlighted by the mouse, so the amount of information required to satisfy the query is suddenly increased many fold. The time scale is such that one does not want the user to have to wait minutes while this image is transferred from a server located somewhere. What I would like is any clues as to who is involved in this area, that includes companies/universities/real=life commercial/research institutions etc. I can assure you that any information will only be used for research purposes. I would require the e.mail addresses or postal addresses of the places concerned. Please direct your replies to my e.mail address. Thanks for your time Dr Gerard Parr Department of Applied Computing Institute of InformAtics University of Ulster Derry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9611.2735a48f@ul.ie] <1990110517423900> From: bourkej@ul.ie Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: MultiLan vs Wollongong for VAX/VMS ????? Message-ID: <9611.2735a48f@ul.ie> Date: 5 Nov 90 17:42:39 GMT Organization: University of Limerick, Ireland Lines: 10 Posted: Mon Nov 5 18:42:39 1990 Can anyone compare the relative merits of TGV MultiLan and the Wollongong offering for VMX/VMS ? I'm told MultiLan is the bees knees, but does Wollongong live up to it ? John Bourke O-O | Information Technology Department, # _ # University Of Limerick, Ireland. ### ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011061147.AA20765@ucbvax.Berkeley.EDU] <1990110518214500> From: jcurran@SH.CS.NET Newsgroups: comp.protocols.tcp-ip Subject: Re: Cost of Internet access Message-ID: <9011061147.AA20765@ucbvax.Berkeley.EDU> Date: 5 Nov 90 18:21:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Mon Nov 5 19:21:45 1990 Dialup IP services are quite inexpensive, and if set up with care will give all the advantages of a dedicated circuit only with an occasional 30 second delay (those times when the line must be brought up.) Yes, dedicated circuits are very nice. But if it takes a dial-up line to get some companies on the Internet, then so be it. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110518501800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 17:58:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09043; Mon, 5 Nov 90 17:54:31 -0800 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 Nov 90 18:50:18 GMT From: van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!GHOLAN@ucbvax.Berkeley.EDU (Geoffrey Holan) Organization: University of Alberta VM/CMS Subject: pc-routers Message-Id: <1103@vm.ucs.UAlberta.CA> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Three quick questions: 1. Has anyone converted ka9q to Microsoft c from turbo ? 2. Has anyone put snmp into ka9q ? 3. Does anyone know where I could find CMU's pcrouter with snmp support? thanks in advance. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011060338.AA11437@ucbvax.Berkeley.EDU] <1990110519063700> From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: LPD for the Mac? Message-ID: <9011060338.AA11437@ucbvax.Berkeley.EDU> Date: 5 Nov 90 19:06:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Mon Nov 5 20:06:37 1990 I guess this is THE lpd everyone likes and that can be FTPed from some place. What I am looking for is one that would operate as a background process under MacTCP and print via the Mac print spooler on Appletalk Laserwriter. Or any functionally equivalent solution. Or a MacIntosh oriented TCP/IP mailing list as a better place to ask. I have connected Appletalk to Ethernet with the (excellent) PCROUTE. Many thanks in advance. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011061430.AA23253@ucbvax.Berkeley.EDU] <1990110520292700> From: Allen@RELAY.PRIME.COM (Christopher Allen, SIBU Special Systems) Newsgroups: comp.protocols.tcp-ip Subject: Wanted: IP directly over HDLC Message-ID: <9011061430.AA23253@ucbvax.Berkeley.EDU> Date: 5 Nov 90 20:29:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Posted: Mon Nov 5 21:29:27 1990 Hi, We have an opportunity here to productize a capability of doing IP over serial lines. The way I've prototyped this is to encapsulate IP datagrams directly into HDLC framing (ISO 3309), without any of the "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. We were wondering if there are any implementations out there that are also able to do this. Both Wellfleet and cisco boxes come to mind, but are there any other implementations that can do this in a non-proprietary manner? Note: I am aware of PPP and am not interested in implementing it as a solution at this time. Please email me directly; I will post a summary if enough interest. -Chris Allen allen@relay.prime.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110521421900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 14:59:24 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04260; Mon, 5 Nov 90 14:57:57 -0800 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 Nov 90 21:42:19 GMT From: swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!usenet@ucsd.edu (Brian Wolfe) Organization: Henry Ford Hospital, Detroit Michigan Subject: Cheap (or Free) TCP-IP summary Message-Id: <1990Nov5.214219.26857@terminator.cc.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Here is the summary of Cheap TCP-IP implementations for VAX/VMS: I receieved about 15 responses pointing me towards CMU/TEK TCP-IP, a few people thought that it was painful to get working and that they thought Multinet was cheaper in terms of their time. Several people recommended CMU/TEK as a very solid alternative to Wollengong, TGV et al, although they thought that CMU didn't scale well on a large machine. For this price I'm going to try it and see how things go, if it doesn't do exactly what we need at least we should be able to do something until we can budget the money for a commercial TCP. Here is a typical response... ------------------------------------------------------------------- CMU/TEK TCP-IP This is a full-blown implementation, including Telnet, FTP, SMTP support, LPR and Finger. It is very stable and well-supported. Order from: Karen Heilman, CMU (412) 268-5896 karen.heilman@andrew.cmu.edu There is a mailing list, cmu-tek-tcp@andrew.cmu.edu, that you can subscribe to (cmu-tek-tcp-request@andrew.cmu.edu) -- ------------------------------------------------------------------------- Brian Wolfe Internet: baw@terminator.cc.umich.edu Systems Analyst UUCP: {rutgers,uunet}!sharkey!hfhrv!brian Henry Ford Hospital Voice: (313)-876-7461 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110521463700> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 14:53:49 PST Received: from BLIULG11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0944; Mon, 05 Nov 90 17:52:04 EST Received: from vm1.ulg.ac.be by BLIULG11 (Mailer R2.07) with BSMTP id 4275; Mon, 05 Nov 90 20:36:27 +0100 Date: Mon, 05 Nov 90 20:06:37 +0100 From: Andr'e PIRARD Subject: LPD for the Mac? To: tcp-ip@nic.ddn.mil I guess this is THE lpd everyone likes and that can be FTPed from some place. What I am looking for is one that would operate as a background process under MacTCP and print via the Mac print spooler on Appletalk Laserwriter. Or any functionally equivalent solution. Or a MacIntosh oriented TCP/IP mailing list as a better place to ask. I have connected Appletalk to Ethernet with the (excellent) PCROUTE. Many thanks in advance. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110521535800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 15:11:34 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04287; Mon, 5 Nov 90 14:58:36 -0800 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 Nov 90 21:53:58 GMT From: swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!usenet@ucsd.edu (Brian Wolfe) Organization: Rush Medical Center, Chicago IL Subject: Berkeley Socket Libraries for Macintosh? Message-Id: <1990Nov5.215358.27116@terminator.cc.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know if there is a Berkeley sockets API (for TCP-IP) available for the Macintosh? The people I've spoken to at Wollengong have said that they will have such a product in about 6 months. regards, Brian -- Brian Wolfe Internet: brian@rpslmc.edu Rush Medical Center Voice: (312)-942-5781 Chicago, IL 60612 FAX: (312)-942-2114 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110522291400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 16:42:25 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07024; Mon, 5 Nov 90 16:36:59 -0800 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 Nov 90 22:29:14 GMT From: swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!halley!news@ucsd.edu (usenet news) Organization: Tandem Micro Products Division Subject: X.25 Host Interface Specification? Message-Id: <1117@halley.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Where might I obtain a copy of the following document? "Defense Data Network X.25 Host Interface Specification" Your help is greatly appreciated. Phil Webster (Keep trying if halley bounces mail. It's flakey) (cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com) ^Preferred ^Most reliable (?) ----------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110523451000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 16:58:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07304; Mon, 5 Nov 90 16:45:45 -0800 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 Nov 90 23:45:10 GMT From: arc!chet@apple.com (Chet Wood) Organization: Advansoft Research Corp, Santa Clara, CA Subject: How do you use Dial-up SLIP? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil It appears SLIP was designed for people who want to extend their IP universe from work to home. I'm sure that it works fairly well for this. But now organizations can use it to connect with the Internet. The logistics of using it for this seem awkward. Would those who are making use of this service kindly tell me how they make it work? Here's how I suppose it works: User dials up the network service provider using tip, and logs in with a name and password. In another window, you run "slip-attach" to configure the interface. Then you do your ftp, or whatever. Then you kill the slip-attach process with -HUP and somehow get the modem to hang up. There are several things wrong with this picture. 1. Am I supposed to tell all our users our login name and password on our providers equipment? Seems like a security risk to me. 2. Who pays the phone bill when a user forgets to hang up after a session? [ A/UX 2.0 - specific ] 3. Based on my very limited experimentation, killing slip-attach (or whatever it's called) on the Mac sometimes leaves grunge around so that it cannot be run again without rebooting the machine. It seems to me, because of these things, that it would be more than worth it to use a leased line for SLIP access, unless someone can tell me of some effective workarounds... Thanks... Chet -- Chet Wood ~ (408)727-3357 X269 chet@Advansoft.Com . Advansoft Research Corporation arc!chet@apple.COM . 4301 Great America Parkway, 6th floor apple!arc!chet . Santa Clara, CA 95054, USA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110600365200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 17:29:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08304; Mon, 5 Nov 90 17:22:41 -0800 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 Nov 90 00:36:52 GMT From: bacchus.pa.dec.com!mogul@decuac.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: Looking for utility to monitor RIP packets Message-Id: <1990Nov6.003652.15271@wrl.dec.com> References: <775@casbah.acns.nwu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <775@casbah.acns.nwu.edu> matt@acns.nwu.edu writes: >I am looking for a UNIX utility that will listen for all the RIP >packets on a network and display their contents. I am essentially >trying to duplicate the output of a cisco router with RIP debugging >turned on. The output looks something like: > >Received RIP update from xxx.xxx.xxx.xxx: > network yyy.yyy.yyy.yyy in n hops > network zzz.zzz.zzz.zzz in m hops > ... The "tcpdump" program (from the folks at LBL) decodes RIP packets, among others. A new version of tcpdump is being tested at the moment; it now includes support for Ultrix systems and 4.3BSD, as well as the SunOS support it has always had. No, I don't know when the latest version will be available, but you probably shouldn't bother to write your own. The output format is a little different, but otherwise you should get all the information you want. For example: 16:34:07.612 16.1.16.252.520 > 16.1.31.255.520: rip-resp 25: 16.183.1.0(8) 16.10.0.1(3) 16.10.16.3(9) 16.10.0.4(3) 16.10.16.4(3) 16.10.16.5(5) 16.10.16.6(4) 16.10.16.8(3) 16.4.16.12(5) 16.10.16.13(4) 16.10.16.14(8) 16.10.16.16(3) 16.10.16.17(8) 16.10.16.18(8) 16.10.16.20(3) 16.4.16.22(5) 16.4.16.23(5) 16.10.16.23(4) 16.10.16.24(5) 16.10.16.25(5) 16.10.16.26(5) 16.36.192.0(7) 16.68.192.0(7) 16.26.192.0(7) 16.153.192.0(7) -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110601423200> Received: from gateway.mitre.org by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 07:04:57 PST Return-Path: Received: by gateway.mitre.org (5.61/SMI-2.2) id AA02205; Tue, 6 Nov 90 10:03:32 -0500 Full-Name: Bill Barns Message-Id: <9011061503.AA02205@gateway.mitre.org> To: halley!phil@cs.utexas.edu Cc: tcp-ip@nic.ddn.mil, barns@gateway.mitre.org Subject: Re: X.25 Host Interface Specification? In-Reply-To: Your message of "05 Nov 90 22:29:14 GMT." <1117@halley.UUCP> Date: Tue, 06 Nov 90 10:02:32 -0500 From: barns@gateway.mitre.org This document is available through the Defense Technical Information Center as accession number ADA 137427. You must be registered with DTIC to get documents from them, and you must be a government contractor or potential contractor or other specifically authorized type of entity to get registered. Most medium or large companies that do business with DOD are already registered, usually via their library or marketing organization. The payment mechanism runs through NTIS and DTIC will give you information on setting up a deposit account with NTIS. Since this document has an ADA number, you can probably get the document directly from NTIS. NTIS usually costs more than DTIC, but they are often a little quicker (potentially overnight if you don't mind paying about four times as much). For normal NTIS orders, call them at (703) 487-4650. For rush orders, call (800) 336-4700 or (703) 487-4700. This document is almost 7 years old and is somewhat behind the times. A revision is somewhere in the works. Implementations built to this spec will still work, but some areas of possible interest such as support of GOSIP protocols are not discussed in it. I think I am on the hook to draft the DDN OSI Subscriber Interface document. Feel free to send me questions and comments. I'll try to respond if I am able, or will try to identify an appropriate contact in DCA or wherever. Bill Barns / MITRE-Washington / barns@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110602013700> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 10:51:55 PST Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA25199; Tue, 6 Nov 90 10:51:54 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA27908; 6 Nov 90 10:01:37 PST (Tue) To: wrs!yuba!hwajin@uunet.uu.net Cc: jackson@neon.stanford.edu, tcp-ip@nic.ddn.mil In-Reply-To: Hwa Jin Bae's message of Mon, 5 Nov 90 15:55:08 PST <9011052355.AA28967@yuba.WRS.COM> Subject: TCP/IP Source Code Search Reply-To: romkey@asylum.sf.ca.us Message-Id: <9011061001.AA27908@asylum.sf.ca.us> Date: 6 Nov 90 10:01:37 PST (Tue) From: romkey@asylum.sf.ca.us (John Romkey) Well, my experience from watching many people port the Berkeley code is that it's a four to six month effort to get it working. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110604355900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 20:57:53 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13035; Mon, 5 Nov 90 20:44:08 -0800 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 Nov 90 04:35:59 GMT From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@ucbvax.Berkeley.EDU (Johnny Zweig) Organization: U of Illinois, Dept. of Computer Science, Systems Research Group Subject: Definitive TCP, IP, UDP Message-Id: <1990Nov6.043559.5133@julius.cs.uiuc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil If I wanted the definitive word on what TCP is, for example, I imagine I could slog through the list of RFCs and figure out what obsoletes what, print out all the ones that seem relevant and scratch my head. Is there a document out there (say an RFC in preparation) that describes exactly how all parts of the protocol work (RTT calculations, options, etc.)? How about for IP and UDP? -Johnny TCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110605363300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 5 Nov 90 22:42:30 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15444; Mon, 5 Nov 90 22:31:44 -0800 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 Nov 90 05:36:33 GMT From: amdcad!brahms!ching@ucbvax.Berkeley.EDU (Mike Ching) Organization: Advanced Micro Devices; Sunnyvale, CA Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Message-Id: <1990Nov6.053633.9261@amd.com> References: <9010311729.AA07194@braden.isi.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9010311729.AA07194@braden.isi.edu> braden@VENERA.ISI.EDU writes: >I would like to suggest that IBM-bashing, no matter how enjoyable a >pastime for some, is not an appropriate use of this mailing list. >Besides, it is very BORING. > >Bob Braden But the bashing is not unwarranted. Prodigy (owned by IBM and Sears Roebuck) cancelled membership of people who protested new per-message fees by con- tacting advertisers. Complaining to advertisers was considered harassment. Is IBM a company you want administering your network? Mike Ching Disclaimer: My opinions do not represent those of my employer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110607101400> Received: from CORNELLC.cit.cornell.edu by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 09:15:03 PST Received: from LOCAL.DOMAIN.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 6062; Tue, 06 Nov 90 12:14:24 EST Received: by * (Mailer R2.03B) id 9758; Tue, 06 Nov 90 12:10:45 EST Date: Tue, 06 Nov 90 12:10:14 EST From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu> Subject: PPP and VJ's Header Compression for SUNs To: tcp-ip@nic.ddn.mil Does anyone know where I can get the necessary sources to add PPP and hopefully VJ's Header Compression to SUN 3's and 4's?? Or are we still stuck with slip even when something better has been devised?? Any pointers?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110608531700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 08:38:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25757; Tue, 6 Nov 90 08:17:40 -0800 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 Nov 90 08:53:17 GMT From: mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net (Daniel Huber) Organization: Ascom Autelca AG, CH-3073 Guemligen Switzerland Subject: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) Message-Id: <1087@aut.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm searching for a TELNET client software which emulates IBM 3270. I know there is a PD tn3270 package somewhere in an archive. I'm also able to get it, but before I ask somebody to download it for me, I have some questions. I try to connect our CAD environment (based on HP9000/3xx, 835) and the engineering environment (based on Sun) to our AS/400 (OS/400). IBM's AS/400 has a TCP/IP solution which supports FTP, TELNET etc. The TELNET server (also the client) on the IBM only supports ASCII streams, 3270 or 5250. For our applications we need at least the 3270 emulation. As I understand, the TELNET client must support 3270 emulation. In fact, the AS/400 expect a 3270 controller (I'm not sure about this) so the client has to simulate that. The user himself use his terminal as a 3270 terminal (with a quite different keyboard :-) ). Questions: - Does tn3270 have all this features I need ? - Is there another product available (as tn3270) ? - Is tn3270 usefull (speed, performance, keyboardmapping...) ? - Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ? - Does tn3270 work with X-Windows(Openlook and Motif), Sunview and ASCII Terminals ? - Is tn3270 also usefull over 9600 Baud Modem ? (Terminal->modem->UNIX->tcpip->AS/400) - Native language support ? Thanks for all answers. (Do I get any ?) :-) Daniel -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 53 01 CH-3073 Guemligen email: dhuber@autelca.ascom.ch Switzerland uucp: uunet!mcsun!chx400!hslrswi!aut!dhuber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110611354700> Received: from crdgw1.ge.com by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 13:35:35 PST Received: by crdgw1.ge.com (5.57/GE 1.76) id AA15426; Tue, 6 Nov 90 16:35:24 EST Received: from ORCAD2.dnet.ge.com by ge-dab.GE.COM (5.61/GE-DAB 1.12) with SMTP id AA01288 for tcp-ip@nic.ddn.mil; Tue, 6 Nov 90 16:35:37 -0500 Message-Id: <9011062135.AA01288@ge-dab.GE.COM> Received: from ORCAD2.dnet.ge.com by ADVAX.dnet.ge.com (utk-mail11d v1.5) with MAIL-11; Tue, 6 Nov 90 16:35:47 EST Date: Tue, 6 Nov 90 16:35:47 EST From: THIER@ORCAD2.dnet.ge.com X-To: ADVAX::"tcp-ip@nic.ddn.mil" Subject: Determining Socket Status To: tcp-ip@nic.ddn.mil I am implementing a UDP/TCP/IP communication software package for a small network of SPARCStation 1+'s running 4.1 and Motorola MVME147 boards running VADSWorks. Message receive tasks are to be kicked off using the asynchronous I/O mechanism. My approach is to utilize SIGIO to alert the receive processing to socket activity, and then use SELECT and the associated mask manipulation macros to identify the active sockets. What I haven't figured out is how to determine the cause of a given SIGIO. Sun documentation states that the signal is posted upon state changes to the socket. Fair enough, but how does one go about determining which change (e.g, connection establishment/disestablishment, data available in receive queue, etc.) has occurred? SELECT, I assume, flags data availability, but a look at the socket state #defines (SS_NODREF, etc.) tells me that I need more than that to safely multiplex sockets. Is there a socket (or file) status call that I'm missing? Thanks in advance. John Thier GE DSD Pittsfield MA thier@orcad2.dnet.ge.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110613471000> Received: from foralie.ics.Hawaii.Edu by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 01:48:10 PST Received: by foralie.ics.Hawaii.Edu id 2335; Tue, 6 Nov 90 23:47:25 HST From: Torben Nielsen To: tcp-ip@NIC.DDN.MIL Subject: PPP for Sun OS.... Message-Id: <90Nov6.234725hst.2335@foralie.ics.Hawaii.Edu> Date: Tue, 6 Nov 90 23:47:10 HST >CSLIP and SLIP sources for Sun 3 & 4 systems are available from >uunet and several other systems. As of Interop, I have not seen >or heard of a WORKING PPP for SunOS. Good Luck! > >=============================================================================== >Cerafin E. Castillo || //\\ ||\\ || We have had one for the better part of a year now and it does work. The problem with it is that it is written to run on top of the lower layer drivers provided as part of Sun's INR package and thus it's difficult to distribute. We have no problem distributing it and we even have an independent lower layer driver that will work on Sun's. But we're not willing to support it.... Torben ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011061355.AA22607@ucbvax.Berkeley.EDU] <1990110613550800> From: AYYOUB@TRMETU.BITNET (Ayyoub) Newsgroups: comp.protocols.tcp-ip Subject: Re: Industrial Computing Society - Call for Papers Message-ID: <9011061355.AA22607@ucbvax.Berkeley.EDU> Date: 6 Nov 90 13:55:08 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Posted: Tue Nov 6 14:55:08 1990 X-Unparsable-Date: Tue, 06 Nov 90 14:05:52 TUR Dear Mr. OZGIT I have posted the article to metu.campus.news group today at 14:00. Most probably you got the draft for October's CCNEWS from ISIK. Pls let me know as soon as you finish reviewing it. Pls know that we are a little late, so I would like to submitt to Matbaa asap. Regards Ayyoub ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011061419.AA23047@ucbvax.Berkeley.EDU] <1990110614195000> From: AYYOUB@TRMETU.BITNET (Ayyoub) Newsgroups: comp.protocols.tcp-ip Subject: Re: Industrial Computing Society - Call for Papers Message-ID: <9011061419.AA23047@ucbvax.Berkeley.EDU> Date: 6 Nov 90 14:19:50 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Posted: Tue Nov 6 15:19:50 1990 X-Unparsable-Date: Tue, 06 Nov 90 14:17:50 TUR Sorry the last mail was sent by mistake. Ayyoub ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110615072900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 11:43:34 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01135; Tue, 6 Nov 90 11:37:00 -0800 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 Nov 90 15:07:29 GMT From: world!bzs@uunet.uu.net (Barry Shein) Organization: The World Subject: Re: Definitive TCP, IP, UDP Message-Id: References: <1990Nov6.043559.5133@julius.cs.uiuc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >If I wanted the definitive word on what TCP is, for example, I imagine I could >slog through the list of RFCs and figure out what obsoletes what, print out >all the ones that seem relevant and scratch my head. Is there a document out >there (say an RFC in preparation) that describes exactly how all parts of the >protocol work (RTT calculations, options, etc.)? How about for IP and UDP? Sounds like you want Doug Comer's textbook, "Internetworking with TCP/IP", Prentice-Hall. Should be available at any college bookstore. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110615573300> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 00:03:24 PST Date: Tue 6 Nov 90 23:57:33-PST From: William "Chops" Westfield Subject: Re: Wanted: IP directly over HDLC To: Allen@Relay.Prime.COM cc: tcp-ip@nic.ddn.mil In-Reply-To: Message from "Christopher Allen (SIBU Special Systems) " of Mon 5 Nov 90 15:29:27-PST Message-ID: <12635952023.2.BILLW@mathom.cisco.com> We have an opportunity here to productize a capability of doing IP over serial lines. The way I've prototyped this is to encapsulate IP datagrams directly into HDLC framing (ISO 3309), without any of the "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. Indeed, this is what almost all of the major router vendors do. PPP is also like this except that there is a potential of doing millions of lines of code to support all the random option negotiation. We were wondering if there are any implementations out there that are also able to do this. Both Wellfleet and cisco boxes come to mind, but are there any other implementations that can do this in a non-proprietary manner? As far as I know, wellfleet and cisco "hdlc" encapsulations are only "proprietary" in that no one else does them - they aren't big secrets. (Ill enclose a description of cisco's spec later in this message...) Note: I am aware of PPP and am not interested in implementing it as a solution at this time. Why not? I would think that this would be a good idea, especially if you leave out the negotiation of the millions of options. A "minimal subset" (refuse all options) of PPP is not difficult, and even a format equivilent to PPP with not option negotiation supported at all (eg only the PPP wire format) probably has a better interoperability future than anything else... Bill Westfield cisco Systems. cisco Serial Line Encapsulation ------------------------------- cisco's default encapsulation on synchronous serial lines uses HDLC framing, with packet contents defined as follows: The first ("address") octet is set to 0x0F for unicast packets and 0x8F for broadcast packets. Broadcast just means that the higher-level protocol thought this was a broadcast packet; cisco doesn't support multidrop HDLC at this time. The second ("control") octet is always 0. The next two octets are a 16-bit protocol code, sent most-significant-first. These codes are usually Ethernet type codes. cisco has added some codes to support packet types that don't appear on Ethernets. The current list of codes is as follows: TYPE_PUP 0x0200 PUP TYPE_XNS 0x0600 XNS TYPE_IP10MB 0x0800 IP TYPE_CHAOS 0x0804 Chaos TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot. TYPE_DECNET 0x6003 DECnet phase IV TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet TYPE_APOLLO 0x8019 Apollo domain TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!) TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol TYPE_ETHERTALK 0x809b Apple EtherTalk TYPE_AARP 0x80f3 Appletalk ARP TYPE_NOVELL1 0x8137 Novell IPX TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP This list is shared between serial and Ethernet encapsulations. Not all these codes will necessarily appear on serial lines. This list will probably be extended as cisco adds support for more protocols. Bytes after this are higher-level protocol data. These normally look the same as they'd look on Ethernet. Bridging packets include Ethernet/802.3 MAC headers; no other packets do. Packets with type 8035 (reverse ARP) don't contain reverse ARP data as they would on an Ethernet. Instead, they carry a protocol cisco refers to as SLARP. SLARP has two functions: dynamic IP address determination and serial line keepalive. The serial line model supported by SLARP assumes that each serial line is a separate IP subnet, and that one end of the line is host number 1, while the other end is host number 2. The SLARP address resolution protocol allows system A to request that system B tell system A system B's IP address, along with the IP netmask to be used on the network. It does this by sending a SLARP address resolution request packet, to which system B responds with a SLARP address resolution reply packet. System A then attempts to determine its own IP address based on the address of system B. If the host portion of system B's address is 1, system A will use 2 for the host portion of its own IP address. Conversely, if system B's IP host number is 2, system A will use IP host number 1. If system B replies with any IP host number other than 1 or 2, system A assumes that system B is unable to provide it with an address via SLARP. For the SLARP keepalive protocol, each system sends the other a keepalive packet at a user-configurable interval. The default interval is 10 seconds. Both systems must use the same interval to ensure reliable operation. Each system assigns sequence numbers to the keepalive packets it sends, starting with zero, independent of the other system. These sequence numbers are included in the keepalive packets sent to the other system. Also included in each keepalive packet is the sequence number of the last keepalive packet _received_ from the other system, as assigned by the other system. This number is called the returned sequence number. Each system keeps track of the last returned sequence number it has received. Immediately before sending a keepalive packet, it compares the sequence number of the packet it is about to send with the returned sequence number in the last keepalive packet it has received. If the two differ by 3 or more, it considers the line to have failed, and will route no further higher-level data across it until an acceptable keepalive response is received. There is interaction between the SLARP address resolution protocol and the SLARP keepalive protocol. When one end of a serial line receives a SLARP address resolution request packet, it assumes that the other end has restarted its serial interface and reset its keepalive sequence numbers. In addition to responding to the address resolution request, it will act as if the other end had sent it a keepalive packet with a sequence number of zero, and a returned sequence number the same as the returned sequence number of the last real keepalive packet it received from the other end. The following is a C definition for the SLARP packet. The "long" and "ulong" types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit number, high octet sent first. struct slarp { long code; /* SLARP packet type code */ union sl { /* followed by one of: */ struct { /* Address resolution functions */ ulong address; /* Address of system sending this pkt */ ulong mask; /* IP subnet mask for this line */ ushort unused; /* Unused: contents undefined */ } add; /* -- or -- */ struct { /* Keepalive probing functions */ ulong mysequence; /* Outgoing sequence number */ ulong yoursequence; /* Returned sequence number */ ushort reliability; /* Reserved: set to FFFF */ } chk; } t; }; Note that the data storage for t.add is overlayed on the data storage for t.chk. The whole SLARP packet consists of a 32-bit type code, followed by two 32-bit quantities and one 16-bit quantity. The overall length of the SLARP packet is 14 octets. The "code" field is used to identify the packet's SLARP type. Legal values for the "code" field are as follows: SLARP_REQUEST 0 Address resolution request SLARP_REPLY 1 Address resolution reply SLARP_LINECHECK 2 Line keepalive For address resolution request packets, the "address" and "mask" fields are set to zero, and the contents of the "unused" field field are undefined. For address resolution reply packets, the "address" field contains the IP address of the _replying_ system, and the "mask" field contains the IP subnet mask to be used. The contents of the "unused" field are undefined. For keepalive packets, the "mysequence" field contains the sequence number of the packet and the "yoursequence" field contains the returned sequence number, which is the sequence number of the last keepalive packet the sending system has gotten from the receiving system. The "reliability" field is reserved for future use, and _must_ be set to FFFF hexadecimal. ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110616055200> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 04:13:59 PST Received: from TRMETU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2996; Tue, 06 Nov 90 07:13:32 EST Received: from TRMETU (AYYOUB) by TRMETU.BITNET (Mailer R2.07) with BSMTP id 7897; Tue, 06 Nov 90 14:14:05 TUR Date: Tue, 06 Nov 90 14:05:52 TUR From: Ayyoub Subject: Re: Industrial Computing Society - Call for Papers To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Tue, 06 Nov 90 12:48:51 TUR from Dear Mr. OZGIT I have posted the article to metu.campus.news group today at 14:00. Most probably you got the draft for October's CCNEWS from ISIK. Pls let me know as soon as you finish reviewing it. Pls know that we are a little late, so I would like to submitt to Matbaa asap. Regards Ayyoub ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110616175000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 04:21:37 PST Received: from TRMETU.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3083; Tue, 06 Nov 90 07:21:11 EST Received: from TRMETU (AYYOUB) by TRMETU.BITNET (Mailer R2.07) with BSMTP id 7899; Tue, 06 Nov 90 14:18:48 TUR Date: Tue, 06 Nov 90 14:17:50 TUR From: Ayyoub Subject: Re: Industrial Computing Society - Call for Papers To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Tue, 06 Nov 90 12:48:51 TUR from Sorry the last mail was sent by mistake. Ayyoub ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110616205400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 08:28:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25913; Tue, 6 Nov 90 08:24:59 -0800 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 Nov 90 16:20:54 GMT From: usc!samsung!b-tech!zeeff@ucsd.edu (Jon Zeeff) Organization: Branch Technology Subject: Re: How do you use Dial-up SLIP? Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > stuff about dial-up slip >1. Am I supposed to tell all our users our login name and password on >our providers equipment? Seems like a security risk to me. > >2. Who pays the phone bill when a user forgets to hang up after a >session? All you need is a little program to detect the need for an outgoing connection, dial up and establish the connection, and then drop it when there is not traffic for some period. It's not hard (I've done it). -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011061907.AA00177@ucbvax.Berkeley.EDU] <1990110617101400> From: 702WFG@SCRVMSYS.BITNET (bill gunshannon) Newsgroups: comp.protocols.tcp-ip Subject: PPP and VJ's Header Compression for SUNs Message-ID: <9011061907.AA00177@ucbvax.Berkeley.EDU> Date: 6 Nov 90 17:10:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Posted: Tue Nov 6 18:10:14 1990 Does anyone know where I can get the necessary sources to add PPP and hopefully VJ's Header Compression to SUN 3's and 4's?? Or are we still stuck with slip even when something better has been devised?? Any pointers?? bill bill gunshannon 702WFG@SCRVMSYS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110619371600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 12:58:50 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03172; Tue, 6 Nov 90 12:51:27 -0800 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 Nov 90 19:37:16 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Berkeley Socket Libraries for Macintosh? Message-Id: <273710EC.45E9@intercon.com> References: <1990Nov5.215358.27116@terminator.cc.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov5.215358.27116@terminator.cc.umich.edu>, baw@terminator.cc.umich.edu (Brian Wolfe) writes: > Does anyone know if there is a Berkeley sockets API > (for TCP-IP) available for the Macintosh? The people I've spoken > to at Wollengong have said that they will have such a product > in about 6 months. > > regards, > > Brian Well while you are waiting for theirs, give Novell a call they have been selling such a beast for the last 2-3 years. They call it TCPort, yeah I know it looks like TCP - ort, what an ort is I don't know. But given a call and take a look at it. It should be compatable with their TCP/IP stack and with Apple's MacTCP. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110619443200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 12:59:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03185; Tue, 6 Nov 90 12:51:58 -0800 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 Nov 90 19:44:32 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: LPD for the Mac? Message-Id: <273712A0.4634@intercon.com> References: <9011060338.AA11437@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011060338.AA11437@ucbvax.Berkeley.EDU>, PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) writes: > I guess this is THE lpd everyone likes and that can be FTPed from some place. > What I am looking for is one that would operate as a background process > under MacTCP and print via the Mac print spooler on Appletalk Laserwriter. > Or any functionally equivalent solution. > Or a MacIntosh oriented TCP/IP mailing list as a better place to ask. > I have connected Appletalk to Ethernet with the (excellent) PCROUTE. > > Many thanks in advance. > If you just want to be able to use MacTCP and print on AppleTalk at the sametime, you don't need a lpd.?.? Just set the printer to AppleTalk within Chooser, and set MacTCP to be running on your ethernet card. There isn't much else to it. Now if you want to print from a UNIX box to the LaserWriter hanging off of AppleTalk, that's a different story. This list, so far, is about the best place to talk about TCP/IP and the Macintosh, the only other list you could try is comp.sys.mac.comm. Hope this helps. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011070014.AA08334@ucbvax.Berkeley.EDU] <1990110620550100> From: jcurran@SH.CS.NET (John Curran) Newsgroups: comp.protocols.tcp-ip Subject: UDP Checksumming of IP addresses Message-ID: <9011070014.AA08334@ucbvax.Berkeley.EDU> Date: 6 Nov 90 20:55:01 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Tue Nov 6 21:55:01 1990 I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-header that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the datagram checksum? /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110620550101> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 12:54:54 PST Date: Tue, 6 Nov 90 20:55:01 GMT From: John Curran To: tcp-ip@nic.ddn.mil Subject: UDP Checksumming of IP addresses I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-header that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the datagram checksum? /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110621025900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 13:59:21 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04876; Tue, 6 Nov 90 13:55:26 -0800 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 Nov 90 21:02:59 GMT From: portal!cup.portal.com!cec@apple.com (Cerafin E Castillo) Organization: The Portal System (TM) Subject: Re: PPP and VJ's Header Compression for SUNs Message-Id: <35676@cup.portal.com> References: <9011061907.AA00177@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil CSLIP and SLIP sources for Sun 3 & 4 systems are available from uunet and several other systems. As of Interop, I have not seen or heard of a WORKING PPP for SunOS. Good Luck! =============================================================================== Cerafin E. Castillo || //\\ ||\\ || Network Consultant || //__\\ || \\ || Los Altos Los Altos Networks || // ---\\|| \\|| Networks 340 Second St. #6 ||___// \|| \\| Los Altos, CA 94022 (415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec NTERNET: cec@cup.portal.com "...No hay mal que por bien no venga..." =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110701383600> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 06:58:20 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA25335; Wed, 7 Nov 90 09:58:36 -0500 Date: Wed, 7 Nov 90 09:58:36 -0500 Message-Id: <9011071458.AA25335@ftp.com> To: mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net (Daniel Huber) Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com IBM's AS/400 has a TCP/IP solution which supports FTP, TELNET etc. The TELNET server (also the client) on the IBM only supports ASCII streams, 3270 or 5250. For our applications we need at least the 3270 emulation. I have heard rumors about the "TN5250" support being developed, but no standard has been published and for the moment it must be viewed as IBM proprietary (anyone from IBM want to comment or publish?). - Does tn3270 have all this features I need ? - Is tn3270 usefull (speed, performance, keyboardmapping...) ? That's hard to say: TN3270 does its best to make the terminal on your desk into a 327x device connected to the mainframe via co-ax. How well it succeeds depends on how well your terminal can be mapped to the specific model of 327x your application expects. A PC with the proper display adapter can do quite well for all kinds of 3278, and some varieties of 3279. 3179G is possible, too (talk to Mitek for that). Minshall's Unix TN3270 has a much harder job, in that it doesn't have a directly-addressable display and has to use curses and a keyboard-remapping scheme to transform random asynch Ascii terminals. Basic 3278-2 isn't too bad, but things like screen painting tend to be slow... - Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ? Don't know, even about our own DOS product. I haven't yet heard of an AS/400 on the Internet that we could test against (any volunteers?). Either there would have to be something on the AS/400 which translated a 5250 data stram into a 3270 data stream, or you'd need AS/400 applications which understood 3270s. - Does tn3270 work with X-Windows(Openlook and Motif), Sunview and ASCII Terminals ? The curses output can be sent to a terminal emulator running in a window. It won't be too quick, but it works. I don't know of anyone who has re-hacked it to bypass curses and the emulator, but it could certainly be done, at the cost of marrying it to a particular environment. - Is tn3270 also usefull over 9600 Baud Modem ? (Terminal->modem->UNIX->tcpip->AS/400) I've used it that way. Reading or writing the whole screen will be slow, so watch out for applications for which this is a way of life... - Native language support ? Our DOS product has a user-loadable Ascii-EBCDIC translation table, and the screen and keyboard can be re-mapped. Minshall's original version would have to be customized in the source. I don't know what other vendors have done. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110701532600> Received: from foralie.ics.Hawaii.Edu by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 13:54:44 PST Received: by foralie.ics.Hawaii.Edu id 2335; Wed, 7 Nov 90 11:53:33 HST From: Torben Nielsen To: bkc@omnigate.clarkson.edu, portal!cup.portal.com!cec@apple.com Subject: Re: PPP and VJ's Header Compression for SUNs Cc: tcp-ip@NIC.DDN.MIL Message-Id: <90Nov7.115333hst.2335@foralie.ics.Hawaii.Edu> Date: Wed, 7 Nov 90 11:53:26 HST Brad, I presume yours is an asynchronous implementation? Ours is purely synchronous..... Torben ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110702400400> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 04:43:19 PST Received: from interlan.interlan.com by RELAY.CS.NET id ab14307; 7 Nov 90 7:41 EST Received: from europa.InterLan.COM by interlan.interlan.com (5.61/5.17) id AA27097; Wed, 7 Nov 90 07:39:44 -0500 Received: by europa.Interlan.COM (4.0/SMI-4.0) id AA02170; Wed, 7 Nov 90 07:40:04 EST Date: Wed, 7 Nov 90 07:40:04 EST From: Frank Kastenholz Message-Id: <9011071240.AA02170@europa.Interlan.COM> To: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@UCBVAX.BERKELEY.EDU, tcp-ip@NIC.DDN.MIL Subject: Re: Definitive TCP, IP, UDP > From tcp-ip-RELAY@NIC.DDN.MIL Tue Nov 6 18:26:40 1990 > From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@ucbvax.Berkeley.EDU (Johnny Zweig) > Organization: U of Illinois, Dept. of Computer Science, Systems Research Group > Subject: Definitive TCP, IP, UDP > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > If I wanted the definitive word on what TCP is, for example, I imagine I could > slog through the list of RFCs and figure out what obsoletes what, print out > all the ones that seem relevant and scratch my head. Is there a document out > there (say an RFC in preparation) that describes exactly how all parts of the > protocol work (RTT calculations, options, etc.)? How about for IP and UDP? > > -Johnny TCP > Johnny TCP, You might wish to start with the host requirements RFCs - 1122/23(?). ^^^^^ Frank Kastenholz Racal Interlan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110702411800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 22:02:17 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06473; Tue, 6 Nov 90 22:00:34 -0800 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 Nov 90 02:41:18 GMT From: bu.edu!wang!fitz@uunet.uu.net (Tom Fitzgerald) Organization: Wang Labs, Lowell MA, USA Subject: Any experiences with PCroute 2.0? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP routing package - has anyone else had any experiences with it? From the looks of it, it seems like a great package for setting up a router, quickly, in a low-traffic situation. The main disadvantage seems to be that you need turbo-assembler to build it, and rebuilding it is necessary to reconfigure the interface hardware. But it handles plain routing, SLIP, proxy-arping and RIP, and it runs on a machine that you can buy for $800 these days. In fact, I'm kinda surprised it isn't used all over the place.... --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110702491400> Received: from bridge2.ESD.3Com.COM by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 10:49:26 PST Received: from ain.ESD.3Com.COM by bridge2.ESD.3Com.COM with SMTP id AA23147 (5.64+/IDA-1.3.4-901018 for tcp-ip@nic.ddn.mil); Wed, 7 Nov 90 10:49:20 -0800 Received: by ain.ESD.3Com.COM (4.0/SMI-3.0DEV3.890509) id AA21432; Wed, 7 Nov 90 10:49:14 PST Date: Wed, 7 Nov 90 10:49:14 PST From: rxk@ain.ESD.3Com.COM (Rajeev Kochhar) Message-Id: <9011071849.AA21432@ain.ESD.3Com.COM> To: tcp-ip@nic.ddn.mil Subject: Re: Problem with Xmodem and 3Com terminal server mmorse@Z.NSF.GOV ("Michael H. Morse") writes: >I am having a problem getting Xmodem to work between a Sun workstation >and a PC running a terminal emulator. >The PC uses a modem and a dial-up line to communicate, but it cannot >get to the workstation directly because the workstation has no serial >ports. Instead, the PC logs on to some other host, and then uses >telnet to get to the workstation. >We have a 3Com terminal server that is normally used in this situation, >but we've found that Xmodem does not work (the PC nacks everything it >gets) in this configuration. However, if the PC logs onto one of our >Ultrix hosts, and in effect uses it for a terminal server to telnet to >the workstation, Xmodem works fine. Subsequent tests have absolved the >terminal emulator (on the PC) and the xmodem program on the >workstation, leaving suspicion around the telnet implementation >on the terminal server. >I suspect this has something to do with parity, since the ASCII >characters transmitted by Xmodem, and received by the PC are >identical. Has anybody run into a similar problem? Any information on >how telnet reacts when raw mode is selected would be appreciated. >Thanks in advance. >--Mike >-- >Michael Morse Internet: mmorse@note.nsf.gov >National Science Foundation BITNET: mmorse@NSF > Telephone: (202) 357-7659 > FAX: (202) 357-7663 The dicussion following the above posting raised a few points about the 3Com terminal server which I want to clarify. The server does support 8-bit (binary transmission) mode in Telnet. The server can initiate negotiation for 8-bit transmission any time during a session. When the server initiates a connection it negotiates 8-bit mode based on the setting of the XmitBinary (can be ON or OFF) parameter. Default value is off. When the terminal server is the server side of a connection it negotiates 8-bit mode by default. The server has a parameter called NetAscii which determines the character sequence transmitted when a is seen at the terminal port. Can be configured to transmit or . However, in 8-bit mode, no extra characters are added to the data stream (i.e. NetAscii is ignored). For a completely transparent session the terminal parameters should be set as following: XmitBinary = ON FlowControlTo = none FlowControlFrom = none ECMChar = disable BreakChar = disable DataBits = 8 Parity = None Hope this helps, -Rajeev Kochhar 3Com Disclaimer: Comments reflect my own understanding and opinion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110704443900> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 10:07:21 PST To: John Curran cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: UDP Checksumming of IP addresses In-reply-to: Your message of Tue, 06 Nov 90 20:55:01 +0000. Date: Wed, 07 Nov 90 13:04:39 -0500 From: George Williams I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-he ader that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the da tagram checksum? /John >Not an expert, but my best-guess-protocol-based response would be for possible fragmentation. >If I were writing a similar protocol...would take into account the data link level transmission >medium below IP. >Sounds like the above scheme allows for just that. A datagram is so logically, right. There is >nothing to say it has to stay physically intact....during transit. What's the real deal wizards out there ? George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110705122500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 6 Nov 90 21:17:42 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05538; Tue, 6 Nov 90 21:16:43 -0800 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 Nov 90 05:12:25 GMT From: jon@bloom-beacon.mit.edu (Jon A. Rochlis) Organization: Massachusetts Institute of Technology Subject: Re: Berkeley Socket Libraries for Macintosh? Message-Id: <1990Nov7.051225.25221@athena.mit.edu> References: <1990Nov5.215358.27116@terminator.cc.umich.edu>, <273710EC.45E9@intercon.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil When I ported Kerberos to the Mac I built a primitive socket library on top of MacTCP. You can get the "alpha" Kerberos distribution including the socket library via anonymous ftp from athena-dist.mit.edu ... retrieve the file pub/kerberos/README.mac for intructions and export restrictions. If you don't want to deal with Kerberos, you can get just the socket library (plus a couple of other bsd compatibility routines) via anonymous ftp from net-dist.mit.edu as jon/bsd-mac-compat.sit.Hqx ... Please send any fixes or comments to me. -- Jon Rochlis (jon@mit.edu) MIT Network Services ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110705365000> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 09:37:07 PST Received: from hemlock.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1) id AA05898; Wed, 7 Nov 90 11:36:58 CST Received: by hemlock.cray.com id AA21257; 4.1/CRI-4.4; Wed, 7 Nov 90 11:36:50 CST Date: Wed, 7 Nov 90 11:36:50 CST From: santa@hemlock.cray.com (Dave Sadler) Message-Id: <9011071736.AA21257@hemlock.cray.com> To: tcp-ip@nic.ddn.mil Subject: TCP/IP for UNISYS 1100/OS? Cc: M.Cutts@uk.cray.com Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be appreciated. Thanks, Dave Sadler (santa@cray.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110706115800> Received: from omnigate.clarkson.edu by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 09:23:20 PST Date: Wed, 7 Nov 90 11:11:58 EST From: Brad Clements To: Cerafin E Castillo cc: tcp-ip@nic.ddn.mil Subject: Re: PPP and VJ's Header Compression for SUNs You can get a version of PPP for Sun OS 4.* (using streams) via anonymous ftp from omnigate.clarkson.edu:/pub/sun/ppp.tar.Z This distribution is for non-commercial use. It was generated on a Sun 386i running 4.0.1, hence some of the include file requirements have changed. If you have trouble installing it, drop me a line and I'll send you some comments from others who have gone through and determined what changes are required. This version does VJ TCP header compression. | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292 ps. By non-commercial I mean, not to be integrated into another product, nor bundled for resale. If you are a commercial org and need to use it in house to connect things togother, thats ok. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110706184500> Received: from po10.andrew.cmu.edu by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 11:40:30 PST Received: by po10.andrew.cmu.edu (5.54/3.15) id for tcp-ip@nic.ddn.mil; Wed, 7 Nov 90 14:40:11 EST Received: via switchmail; Wed, 7 Nov 90 14:40:06 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Wed, 7 Nov 90 14:38:56 -0500 (EST) Received: from valkyries.andrew.cmu.edu via qmail ID ; Wed, 7 Nov 90 14:38:49 -0500 (EST) 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; Wed, 7 Nov 90 14:38:45 -0500 (EST) Message-Id: Date: Wed, 7 Nov 90 14:38:45 -0500 (EST) From: Drew Daniel Perkins To: tcp-ip@nic.ddn.mil Subject: Re: PPP and VJ's Header Compression for SUNs In-Reply-To: <35676@cup.portal.com> References: <9011061907.AA00177@ucbvax.Berkeley.EDU>, <35676@cup.portal.com> There IS a PPP available for SunOS which supports VJ compression. You can get it from Brad Clements, bkc@omnigate.clarkson.edu. Drew ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110707250900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 02:32:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11451; Wed, 7 Nov 90 02:26:33 -0800 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 Nov 90 07:25:09 GMT From: eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: TCP/IP Source Code Search Message-Id: <1990Nov7.072509.5047@lth.se> References: <9011052355.AA28967@yuba.WRS.COM>, <9011061001.AA27908@asylum.sf.ca.us> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011061001.AA27908@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes: >Well, my experience from watching many people port the Berkeley code >is that it's a four to six month effort to get it working. Speaking as someone who has just spent a few months porting the berkeley code to a simple microprossesor environment (no virtual memory, no this, no that...), I have to agree ... IT DOES! (:-)) -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110708383400> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 16:38:38 PST Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 7 Nov 90 16:38:39 -0800 Date: Wed, 7 Nov 90 16:38:34 PST From: braden@venera.isi.edu Posted-Date: Wed, 7 Nov 90 16:38:34 PST Message-Id: <9011080038.AA11962@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Wed, 7 Nov 90 16:38:34 PST To: gwilliam@sh.cs.net, jcurran@sh.cs.net Subject: Re: UDP Checksumming of IP addresses Cc: tcp-ip@nic.ddn.mil There are two answers, one historical and the other architectural. Historically, the early versions of TCP/IP followed the original Cerk&Kahn paper in having a single protocol. Only later (version 4) was it split into an IP and a Transport layer. When it was split, the addressing information was split between the two layers. But who wants to change the checksum definition...? The architectural justification was that the transport layer should be able to verify the integrity of its addressing information no matter what lower-layer protocol it runs over. "Don't trust ANYBODY". The TCP and UDP specs say, "This gives protection against misrouted segments". Actually, all it probably gives you is protection against software bugs. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011080112.AA02246@ucbvax.Berkeley.EDU] <1990110716115800> From: bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) Newsgroups: comp.protocols.tcp-ip Subject: Re: PPP and VJ's Header Compression for SUNs Message-ID: <9011080112.AA02246@ucbvax.Berkeley.EDU> Date: 7 Nov 90 16:11:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Posted: Wed Nov 7 17:11:58 1990 You can get a version of PPP for Sun OS 4.* (using streams) via anonymous ftp from omnigate.clarkson.edu:/pub/sun/ppp.tar.Z This distribution is for non-commercial use. It was generated on a Sun 386i running 4.0.1, hence some of the include file requirements have changed. If you have trouble installing it, drop me a line and I'll send you some comments from others who have gone through and determined what changes are required. This version does VJ TCP header compression. | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292 ps. By non-commercial I mean, not to be integrated into another product, nor bundled for resale. If you are a commercial org and need to use it in house to connect things togother, thats ok. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110717050000> Received: from MVST.OAC.UCLA.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 01:05:54 PST Received: from UCLAMVS.BITNET by MVST.OAC.UCLA.EDU (IBM MVS SMTP R1.0.1) with BSMTP id 1555; Thu, 08 Nov 90 01:05:46 PDT Date: Thu, 08 Nov 90 01:05 PST To: tcp-ip@NIC.DDN.MIL From: Denis DeLaRoca (213) 825-4580 Subject: Re: Re: PPP and VJ's Header Compression for SUNs Sometime ago Karl Fox from Morning Start Technologies had actually made the changes necessary to have Brad Clements' PPP code compile and run on Sun platforms other than the 386i... I had the changes from Karl but my Sun's hard disk broke down. Karl may be reached at Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 17:40:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02192; Wed, 7 Nov 90 17:09:18 -0800 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 Nov 90 17:57:35 GMT From: sci34hub!gary@uunet.uu.net (Gary Heston) Organization: SCI Technology, Inc., Huntsville, Al. Subject: Re: SENDMAIL configuration Message-Id: <796@sci34hub.UUCP> References: <9011051727.AA16922@nisc.jvnc.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011051727.AA16922@nisc.jvnc.net> aggarwal@NISC.JVNC.NET (Vikas Aggarwal) writes: > [ typical tale of sendmail woe deleted ] >Any ideas / suggestions (postmaster@berkeley.edu ....?!!) ?? Yes. I fought with sendmail configuration for a long time, and never succeeded in getting it running just the way I wanted to. Then, I pulled smail3.14 off uunet, and had it installed and running right in about three days. I'm happy, the users are happy, the mail is getting thru.... HIGHLY recommended. The only thing to watch are the log and error files in /usr/spool/smail, which can get large if you don't clean them out every week. -- Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com The sysadmin sees all, knows all, and doesn't tell the boss who's updating their resumes.... This .sig Copyright G. L. Heston, 1990 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011080248.AA04564@ucbvax.Berkeley.EDU] <1990110718043900> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: UDP Checksumming of IP addresses Message-ID: <9011080248.AA04564@ucbvax.Berkeley.EDU> Date: 7 Nov 90 18:04:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Posted: Wed Nov 7 19:04:39 1990 I'm sure I've overlooked something, and could use a push.. Why does UDP (when used with checksumming enabled) create a pseudo-he ader that contains both the port numbers and the source and destination IP addresses? Isn't it already protected from address changes by the da tagram checksum? /John >Not an expert, but my best-guess-protocol-based response would be for possible fragmentation. >If I were writing a similar protocol...would take into account the data link level transmission >medium below IP. >Sounds like the above scheme allows for just that. A datagram is so logically, right. There is >nothing to say it has to stay physically intact....during transit. What's the real deal wizards out there ? George Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110719160900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 19:18:42 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05233; Wed, 7 Nov 90 19:15:15 -0800 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 Nov 90 19:16:09 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: How do you use Dial-up SLIP? Message-Id: <1990Nov7.191609.19972@zoo.toronto.edu> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article chet@Advansoft.COM (Chet Wood) writes: >It seems to me, because of these things, that it would be more than >worth it to use a leased line for SLIP access... Leased lines are better than dialup connections; there is no doubt about that. However, they also are significantly expensive, can sometimes be hard to get, and generally require explicit budget justification rather than getting a "free ride" on existing hardware and existing phone bills. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110719230500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 12:18:12 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23748; Wed, 7 Nov 90 12:06:43 -0800 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 Nov 90 19:23:05 GMT From: cs!samadams.princeton.edu@princeton.edu (Tom Reingold) Organization: Noo Joizy -- The Cultural Mecca Subject: looking for SLIP for System V Release 3 Message-Id: <4299@rossignol.Princeton.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am interested in learning who sells versions of SLIP for System V Release 3. I have 3B2's and 386's. Does each brand of SLIP depend on a particular brand of TCP/IP? Any information on any brands would be appreciated. -- Tom Reingold tr@samadams.princeton.edu OR ...!princeton!samadams!tr "Warning: Do not drive with Auto-Shade in place. Remove from windshield before starting ignition." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110720070500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 19:19:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05254; Wed, 7 Nov 90 19:15:58 -0800 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 Nov 90 20:07:05 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Definitive TCP, IP, UDP Message-Id: <1990Nov7.200705.21169@zoo.toronto.edu> References: <1990Nov6.043559.5133@julius.cs.uiuc.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article bzs@world.std.com (Barry Shein) writes: >>... Is there a document out >>there (say an RFC in preparation) that describes exactly how all parts of the >>protocol work (RTT calculations, options, etc.)? How about for IP and UDP? > >Sounds like you want Doug Comer's textbook, "Internetworking with >TCP/IP", Prentice-Hall. Should be available at any college bookstore. Uh, Barry, had a hard night last night? :-) Comer is a good textbook, but it is not in any way, shape, or form the sort of reference manual that he is asking for. Too many things are alluded to but not discussed. (I've heard there is a second edition, which may have improved the situation, but I'd still be surprised if it was what he's after.) It doesn't even discuss the details of closing a TCP connection, for example. As far as I know, there is no substitute for wading through lots of RFCs. The Host Requirements and Protocol Standards ones are the places to start. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110720580000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 13:04:02 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id ae10672; 7 Nov 90 16:01 EST Date: Wed, 7 Nov 90 20:58 GMT From: Bob Stine <0004219666@mcimail.com> To: David Doll To: tcp-ip Subject: SNMP Packages via Anonymous ftp? Message-Id: <12901107205821/0004219666NB1EM@mcimail.com> >Simple question: what is RFC 1147? >David Doll David, Glad you asked. :-) RFC 1147 is "A Network Management Tool Catalog." It is a (by no means comprehensive) list of free and commericial tools for managing TCP/IP internets and the devices that they interconnect. RFC 1147 is also FYI 2; the purpose of the FYI series of documents is to provide general or practical information on the Internet. As you might surmise from the number, the FYI document series is rather new. RFC 1147 was published in April of this year. The IETF is currently working on developing son-of-1147. Anyone who would like to have his/her tool listed in the next edition of the catalog, or anyone who would like to have an existing catalog entry updated, should contact me, or drop a note to noctools@merit.edu. For various reasons, we require vendors to provide the draft entries of their commercial products. Regards, Bob Stine bstine@MCIMail.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110721580100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 15:34:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29283; Wed, 7 Nov 90 15:28:44 -0800 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 Nov 90 21:58:01 GMT From: usc!zaphod.mps.ohio-state.edu!think.com!barmar@ucsd.edu (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: UDP Checksumming of IP addresses Message-Id: <1990Nov7.215801.10016@Think.COM> References: <9011070014.AA08334@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011070014.AA08334@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET (John Curran) writes: >I'm sure I've overlooked something, and could use a push.. > >Why does UDP (when used with checksumming enabled) create a pseudo-header >that contains both the port numbers and the source and destination IP >addresses? The pseudo-header doesn't have port numbers in it. It contains the addresses, the protocol number (17 when used with IP as the network layer), and the length. > Isn't it already protected from address changes by the datagram >checksum? From RFC 768: "This information gives protection against misrouted datagrams." In other words, it's there to detect failure of the IP layer. For instance, if the receiving host is single-homed and the datagram isn't a broadcast, the destination IP address in the pseudo-header could be the address of the interface rather than the address in the IP header, and which will catch attempts by a broken IP layer to pass up packets intended for another host (an IP layer might not check the destination address of packets coming in through a point-to-point link, or it might not be prepared for an interface being in promiscuous mode). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110723594900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 16:33:31 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00940; Wed, 7 Nov 90 16:21:59 -0800 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 Nov 90 23:59:49 GMT From: usc!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!unger@ucsd.edu (Tom Unger) Subject: Help with XModem over telnet Message-Id: <10763@milton.u.washington.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Reply-To: tom@citi.umich.edu (Tom Unger) Distribution: usa Organization: University of Washington, Seattle I am trying to implement a file transfer over telnet. On the unix side I am running sz (as sx for XModem) and on the Mac side I'm runing the software that I'm writing. For the file transfer I negociate telnet binary mode, in both directions. The unix machine responds positivly, for both directions. (I think that sx also does what is necessary to transmit binary data). For downloads (unix to mac) I find that a NULL is inserted after every CR. I know that this is required for default operation but I expected that in binary mode I would only have to watch for IACs. Is the unix implementation that I have wrong (a/ux 2.0) or does the CR NULL rull apply even in binary mode? I checked the RFCs but didn't see anything pertaining to how CR should be handled in binary mode. Please reply via mail to: unger@cdp.igc.orgTo UnMIT Tom Unger MITEM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110802255900> Received: from ncsuvm.ncsu.edu by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 04:33:25 PST Received: from ECUVM1.BITNET by ncsuvm.ncsu.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 7411; Thu, 08 Nov 90 07:32:13 EST Received: from ECUVM1 (SSROB) by ECUVM1.BITNET (Mailer R2.07) with BSMTP id 2465; Thu, 08 Nov 90 07:30:44 EST Date: Thu, 08 Nov 90 07:25:59 EST From: Rob Hudson Organization: "ECU Computing and Information Systems" Subject: Re: TCP/IP for UNISYS 1100/OS? To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Wed, 7 Nov 90 11:36:50 CST from On Wed, 7 Nov 90 11:36:50 CST Dave Sadler said: >Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be >appreciated. > >Thanks, Dave Sadler (santa@cray.com) Dave, There are one of 2 options for TCP/IP on Unisys 1100/2200 Mainframes. If your host has a DCP there is a DCP Ethernet Line Module that requires the following software: Comm Delivery 4, TCP/IP Stack, DCP Lan Platform. If you want ftp smtp you will also need DDN-1100. The other option is a channel attached box call a Host Lan Controller (HLC). This box requires DDN-1100 also but not the other software. Both of these options allow connection to an Ethernet Segment. If you have any further questions please email me or give me a call. ======================================================================= * Rob L. Hudson ___ ___ SSROB@ECUVM1.BITNET * * Systems Programmer |__ | | | ( 919 ) 757 - 6401 * * East Carolina University |___ |___ |__| Greenville, NC 27858 * ======================================================================= ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011090137.AA10315@ucbvax.Berkeley.EDU] <1990110808051900> From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: Re: Any experiences with PCroute 2.0? Message-ID: <9011090137.AA10315@ucbvax.Berkeley.EDU> Date: 8 Nov 90 08:05:19 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Posted: Thu Nov 8 09:05:19 1990 On Wed, 7 Nov 90 02:41:18 GMT Tom Fitzgerald said: >We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP >routing package - has anyone else had any experiences with it? I have been using PCROUTE 2.0 (now 2.1 for just a fix to SLIP) for 6 months without a glitch (or should I say with just one which was a power one after which the PC wouldn't restart and no PCROUTE's fault). 3 days work (tests before production) for a router novice at that time. It's got 2 Ethernet, 1 Appletalk and 2 SLIPs (SLIP not tried yet). I didn't figure how to get to overload it. Our hosts would overload first. It even helps big blue's static routing with its proxy-arp. The doc is excellent. But it doesn't teach what is routing and RIP. Practically, it doesn't even cost what you say: it's the occasion to dust stranded PC's or reuse unwanted ones. Better use ATs for SLIP, though. I didn't mind using the savings to buy TurboAsm (and TC++). >In fact, I'm kinda surprised it isn't used all over the place.... So am I. Or is it and nobody cares to say? We are hearing much about problems, don't we? The only good reason we don't use more of it here is that it would be a good reason not to buy more sophisticated hardware that some people feel proud of. I wanted to make this reply public both in thanks to Vance and in reaction to having read that PCROUTE is not supported. It doesn't need it. It works. This note via tn3270 through it. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110808103900> Received: from ftp.com by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 13:31:02 PST Received: from cws.ice.ftp.com by ftp.com via PCMAIL with DMSP id AA17924; Thu, 8 Nov 90 16:30:39 -0500 Date: Thu, 8 Nov 90 16:30:39 -0500 Message-Id: <9011082130.AA17924@ftp.com> To: psuvm!cjs@psuvax1.cs.psu.edu Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) From: cws@ftp.com (Cris Shuldiner) Reply-To: cws@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: cws@ftp.com Repository: babyoil.ftp.com Originating-Client: ice.ftp.com Date: 8 Nov 90 16:45:31 GMT From: psuvm!cjs@psuvax1.cs.psu.edu Organization: Penn State University Subject: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) To: tcp-ip@nic.ddn.mil I sure would like 3179G emulation in a TN3720. Does anyone have an address or phone number for Mitek handy? The number for Mitek is (214) 490-4090. They are located in Carrollton, TX. We are using FTP Software's TN3270 to telnet to an AS/400. It works pretty good; I wish it (TN3270) supported color or at least extended attributes (like underscore). The default 3270-to-5250 keyboard mapping (on the AS/400) is brain-damaged, but (somewhat) easily remedied with a user command. Also, it only does 24 lines. I also use FAL's telnet to log onto the AS/400. Extended color and highlighting work. Our TN program [in ver 2.05 which was released a couple of weeks ago] does support extended attributes affecting color and highlighting. It also supports 32x80, 43x80, and 27x132 screen sizes, if your video card and monitor can handle them. Cris Shuldiner Product Support cws@ftp.com FTP Software, Inc. -------------------------------------------------------------------------- "The pain of war can not exceed the woe of aftermath..." - Led Zeppelin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110808525000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 03:04:04 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13099; Thu, 8 Nov 90 02:53:17 -0800 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 Nov 90 08:52:50 GMT From: munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!manic!chris@uunet.uu.net (Chris Clarkson) Organization: Communica Software Consultants, Adelaide, Australia Subject: Adding a SLIP streams module to a 3b2 running WIN TCP/IP Message-Id: <779@manic.communica.oz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need to get SLIP up on a 3b2/400 & 3b2/600 running WIN TCP/IP and vanilla 3b2 System V.3 Unix. I can find plenty of Berkely SLIP examples but no System V.3 examples. Can anyone point me towards articles, source or just give me some general pointers on the complexity of what I'm contemplating? Please reply by post. -- Chris Clarkson Tel: 61 8 410 1442 chris@manic.communica.oz.au Fax: 61 8 410 1443 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011082343.AA07471@ucbvax.Berkeley.EDU] <1990110809050000> From: CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca 825-4580, 213) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: PPP and VJ's Header Compression for SUNs Message-ID: <9011082343.AA07471@ucbvax.Berkeley.EDU> Date: 8 Nov 90 09:05:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Thu Nov 8 10:05:00 1990 Sometime ago Karl Fox from Morning Start Technologies had actually made the changes necessary to have Brad Clements' PPP code compile and run on Sun platforms other than the 386i... I had the changes from Karl but my Sun's hard disk broke down. Karl may be reached at From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: TCP sockets driver, Desqview/X Message-ID: <9011090407.AA13863@ucbvax.Berkeley.EDU> Date: 8 Nov 90 09:50:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Thu Nov 8 10:50:42 1990 Go to your bookshop and buy the IBM PC special issue of BYTE. Detach the booklet from Quarterdeck and read it. Full X support in the DESQview multitasking environment for MSDOS. Seems amazing. Just as striking to me is that it looks like (I have to check) Quarterdeck have managed to multiplex the FTP Software socket driver between several concurrent DOS applications. More like TCP/IP wouldn't it? This strengthens my opinion that PD software for DOS should detect and use this socket API when present. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110810451900> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 02:52:22 PST Received: from BLIULG11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9281; Thu, 08 Nov 90 05:51:46 EST Received: from vm1.ulg.ac.be by BLIULG11 (Mailer R2.07) with BSMTP id 6679; Thu, 08 Nov 90 10:05:12 +0100 Date: Thu, 08 Nov 90 09:05:19 +0100 From: Andr'e PIRARD Subject: Re: Any experiences with PCroute 2.0? To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Wed, 7 Nov 90 02:41:18 GMT from On Wed, 7 Nov 90 02:41:18 GMT Tom Fitzgerald said: >We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP >routing package - has anyone else had any experiences with it? I have been using PCROUTE 2.0 (now 2.1 for just a fix to SLIP) for 6 months without a glitch (or should I say with just one which was a power one after which the PC wouldn't restart and no PCROUTE's fault). 3 days work (tests before production) for a router novice at that time. It's got 2 Ethernet, 1 Appletalk and 2 SLIPs (SLIP not tried yet). I didn't figure how to get to overload it. Our hosts would overload first. It even helps big blue's static routing with its proxy-arp. The doc is excellent. But it doesn't teach what is routing and RIP. Practically, it doesn't even cost what you say: it's the occasion to dust stranded PC's or reuse unwanted ones. Better use ATs for SLIP, though. I didn't mind using the savings to buy TurboAsm (and TC++). >In fact, I'm kinda surprised it isn't used all over the place.... So am I. Or is it and nobody cares to say? We are hearing much about problems, don't we? The only good reason we don't use more of it here is that it would be a good reason not to buy more sophisticated hardware that some people feel proud of. I wanted to make this reply public both in thanks to Vance and in reaction to having read that PCROUTE is not supported. It doesn't need it. It works. This note via tn3270 through it. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110811410000> Received: from fccc.edu by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 13:43:52 PST Message-id: <095EEFD3487FA01806@fccc.edu> Date: Thu, 8 Nov 90 16:41 EST From: Dan Subject: Is there a way to send OOB data with CMU-TEK TCP/IP? To: tcp-ip@nic.ddn.mil X-Organization: The Fox Chase Cancer Center X-VMS-To: IN%"tcp-ip@nic.ddn.mil" X-VMS-Cc: MORTON I'm looking to notify a client program on a UNIX system that the server on a VMS system is going to go away (I'm using the CMU TEK implementation of TCP/IP). I've read that a program will receive a SIGURG signal when it receives out-of-band data. Does anyone know of a way to send it using CMU-TEK? Given my VMS/UNIX combination, does anyone know of a simple way to trigger a signal to the UNIX side, failing the OOB approach? -------------------------------------------------------------------------------- Return address: Dan Morton Voice: 215-728-3644 Fox Chase Cancer Center 7701 Burholme Avenue Fax: 215-728-3574 Philadelphia, PA 19111 USA Net: morton@fccc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011090517.AA15216@ucbvax.Berkeley.EDU] <1990110812255900> From: SSROB@ECUVM1.BITNET (Rob Hudson) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP for UNISYS 1100/OS? Message-ID: <9011090517.AA15216@ucbvax.Berkeley.EDU> Date: 8 Nov 90 12:25:59 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: "ECU Computing and Information Systems" Lines: 20 Posted: Thu Nov 8 13:25:59 1990 On Wed, 7 Nov 90 11:36:50 CST Dave Sadler said: >Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be >appreciated. > >Thanks, Dave Sadler (santa@cray.com) Dave, There are one of 2 options for TCP/IP on Unisys 1100/2200 Mainframes. If your host has a DCP there is a DCP Ethernet Line Module that requires the following software: Comm Delivery 4, TCP/IP Stack, DCP Lan Platform. If you want ftp smtp you will also need DDN-1100. The other option is a channel attached box call a Host Lan Controller (HLC). This box requires DDN-1100 also but not the other software. Both of these options allow connection to an Ethernet Segment. If you have any further questions please email me or give me a call. ======================================================================= * Rob L. Hudson ___ ___ SSROB@ECUVM1.BITNET * * Systems Programmer |__ | | | ( 919 ) 757 - 6401 * * East Carolina University |___ |___ |__| Greenville, NC 27858 * ======================================================================= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110812304200> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 03:26:50 PST Received: from BLIULG11 by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0070; Thu, 08 Nov 90 06:18:05 EST Received: from vm1.ulg.ac.be by BLIULG11 (Mailer R2.07) with BSMTP id 6743; Thu, 08 Nov 90 11:06:35 +0100 Date: Thu, 08 Nov 90 10:50:42 +0100 From: Andr'e PIRARD Subject: TCP sockets driver, Desqview/X To: cutcp@omnigate.clarkson.edu, tcp-ip@nic.ddn.mil Go to your bookshop and buy the IBM PC special issue of BYTE. Detach the booklet from Quarterdeck and read it. Full X support in the DESQview multitasking environment for MSDOS. Seems amazing. Just as striking to me is that it looks like (I have to check) Quarterdeck have managed to multiplex the FTP Software socket driver between several concurrent DOS applications. More like TCP/IP wouldn't it? This strengthens my opinion that PD software for DOS should detect and use this socket API when present. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110812355300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 11:10:49 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02526; Wed, 14 Nov 90 11:03:12 -0800 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 Nov 90 12:35:53 GMT From: mcsun!ukc!keele!csd35@uunet.uu.net (Jonathan Knight) Organization: University of Keele, England Subject: Why do I need multiple host names for the same host? Message-Id: <705@keele.keele.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Our dept has just re-arranged its ethernet into 2 seperate ethernets with a sun 4 acting as the router. It is the only host which has more than one cable attached to it. Following the manual we have put: 192.42.100.3 do loghost 192.82.242.1 doc_1 into our hosts table. This causes problems as some of our diskless stations need to be told to get their swap and root from 'doc' and others need to get it from 'doc_1'. This is caused by the fact that they have no routing information at the point at which they want to download vmunix. Therefore the host they boot from must be on their network. I have two questions. 1) When a host on the 192.82.242 network tries to talk to 'doc' is the packet addressed to 192.42.100.3? If not is this packet unpacked by doc? If not does this packet actually get placed on the 192.42.100 network and re-read by doc? 2) Is there a way to indicate to each host that doc is local on their ethernet? The only solution I came up with was having multiple /etc/hosts, one for each network with doc listed on that network. This is inelegant as we want to use YP (sorry - NIS) to distribute the known hosts to all networks and we want to avoid multiple domains. Any help will be gratefully received. -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110814133800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 19:56:30 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13478; Thu, 8 Nov 90 19:48:37 -0800 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 Nov 90 14:13:38 GMT From: pasteur!agate!linus!nixbur!nixpbe!peun33!freiss@ucbvax.Berkeley.EDU (the hacker) Subject: Multiple subnets on same cable Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This might be a silly question, but it's been worrying me for some time. What happens if different IP subnets live on the same ethernet cable? I'm worried about excessive ICMP traffic (ICMP net_redirect packets); I see some SGI workstations here react to some packets from a different subnet with this ICMP message. Could somebody tell me if this is a problem or what other problems I haven't even thought of might arise? Pointers to books, RFCs etc. on this subject are also welcome. Thanks, Martin -- Martin Freiss | internet: freiss.pad@nixdorf.com SNI AG | dnet: freiss.pad@nixdorf.de Dept. STO-NC 333 | Voice: +49 5251 14 6601 D-4790 Paderborn | fun: marvin%dg5kx@infodn.rmi.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110815371100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 08:04:35 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18625; Thu, 8 Nov 90 07:51:23 -0800 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 Nov 90 15:37:11 GMT From: pacbell.com!tandem!netcom!jbreeden@ucsd.edu (John Breeden) Organization: Netcom- The Bay Area's Public Access Unix System {408 241-9760 guest} Subject: Re: looking for SLIP for System V Release 3 Message-Id: <16441@netcom.UUCP> References: <4299@rossignol.Princeton.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <4299@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes: >I am interested in learning who sells versions of SLIP for System V >Release 3. I have 3B2's and 386's. Does each brand of SLIP depend on >a particular brand of TCP/IP? > The AT&T/Wollongong tcp-ip that's available for SysV R4 (you need to rev your 3bs and 386s) includes SLIP (along with an snmp agent, ip over x.25 and other goodies). I also understand that the AT&T/Wollongong tcp-ip for SysV R3 (win/386 R3.0) has a slip module, AT&T just dosn't include it. You might try Wollongong directly. -- John Robert Breeden, netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model." ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110816453100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 10:06:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21752; Thu, 8 Nov 90 09:57:14 -0800 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 Nov 90 16:45:31 GMT From: psuvm!cjs@psuvax1.cs.psu.edu Organization: Penn State University Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) Message-Id: <90312.114531CJS@psuvm.psu.edu> References: <9011071458.AA25335@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011071458.AA25335@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) says: >A PC with the proper display adapter >can do quite well for all kinds of 3278, and some varieties of 3279. 3179G >is possible, too (talk to Mitek for that). I sure would like 3179G emulation in a TN3720. Does anyone have an address or phone number for Mitek handy? > - Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ? >Don't know, even about our own DOS product. I haven't yet heard of an >AS/400 on the Internet that we could test against (any volunteers?). We are using FTP Software's TN3270 to telnet to an AS/400. It works pretty good; I wish it (TN3270) supported color or at least extended attributes (like underscore). The default 3270-to-5250 keyboard mapping (on the AS/400) is brain-damaged, but (somewhat) easily remedied with a user command. Also, it only does 24 lines. I also use FAL's telnet to log onto the AS/400. Extended color and highlighting work. Because of the weirdness in remapping the 3270->5250 keys, I wish I had a TN3720 that allowed its keyboard remapping to define more than one 3270 key to be transmitted with one PC key. The 5250 has 24 PF keys plus more than the usual 3270 attention keys: help, page up (roll down) and page down (roll up), some some functions have to be mapped to dual 3270 attention keys (PA1+PFx or PA2+PFx). A TN5250 would be nice for this reason. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110817264000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 18:56:43 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12093; Thu, 8 Nov 90 18:46:38 -0800 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 Nov 90 17:26:40 GMT From: van-bc!robinson@ucbvax.Berkeley.EDU Organization: Mobile Data International, Richmond, B.C., Canada Subject: Re: TCP/IP Source Code Search Message-Id: <1990Nov8.172640.13894@mdivax1.uucp> References: <9011052355.AA28967@yuba.WRS.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011052355.AA28967@yuba.WRS.COM> hwajin@yuba.UUCP (Hwa Jin Bae) writes: >>Many people use the Berkeley code as a start. It's an excellent >>protocol engine; its main drawback is that it really really wants to >>live inside a UNIX kernel. It often takes many man-months to port >>properly. You can find it on uunet.uu.net for anonymous FTP. > >berkeley code is actually pretty portable. it's really not that hard >to port berkeley code to non-unix environment. you need to write a set >of compatible routines -- spl*(), splx() can be emulated using semaphores, >timeout() can be emulated in most operating systems that support >watchdog timers of some sort, sleep() (kernel version) can be done >via a semaphore or mailbox, wakeup() the same way, perror() and panic() >are trivial, cluster mbuf can be emulated if you change the mbuf structure >slightly even on systems that lack virtual memory, etc. i'm speaking >from my experience... your mileage may vary. One possible problem is the use of non-int bit fields in the tcp and ip header structures. Pre-ANSI C requires only that unsigned int bit fields be supported by a compiler and ANSI C requires only (*I believe*) signed or unsigned bit fields be supported. Thus, if your compiler does not support, say, unsigned char bit fields, which are indeed used in the BSD code, you will have to do a bit of work to work around this problem. If you are unlucky, as I was, your compiler will *not* complain, but merely generate incorrect code. You will also run into a number of annoying problems if the sizes of ints and pointers on your target machine are greater than 32 bits, since there are several coding practices employed that assume 32 bit pointers and ints. -- Jim Robinson {uunet,ubc-cs}!van-bc!mdivax1!robinson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110818022200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 10:37:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22688; Thu, 8 Nov 90 10:32:22 -0800 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 Nov 90 18:02:22 GMT From: agate!shelby!morrow.stanford.edu!Valinor.Stanford.EDU!vaf@ucbvax.Berkeley.EDU (Vince Fuller) Organization: Networking Systems, Stanford University Subject: Re: How do you use Dial-up SLIP? Message-Id: <1990Nov8.100222@Valinor.Stanford.EDU> References: , <1990Nov7.191609.19972@zoo.toronto.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov7.191609.19972@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: |> In article chet@Advansoft.COM (Chet Wood) writes: |> >It seems to me, because of these things, that it would be more than |> >worth it to use a leased line for SLIP access... |> |> Leased lines are better than dialup connections; there is no doubt about |> that. However, they also are significantly expensive, can sometimes be hard |> to get, and generally require explicit budget justification rather than |> getting a "free ride" on existing hardware and existing phone bills. |> -- |> "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology |> "Not to worry." | henry@zoo.toronto.edu utzoo!henry The above statement may or may not be true, depending on the nature of the local telephone service where you are located. In the Bay Area, for example, you can't get a business line with unlimited local dailing - everything is measured rate. For this reason, it will be cheaper to lease a dedicated 9.6KB line if you plan on using for more than a very small amount (like an hour a day or thereabouts). In additione, 56KB ADN ("advanced digital network") circuits are not much more expensive than 9.6KB leased lines, though they are not quite as ubiquitous as 9.6KB lines. Of course, there are other capital costs associated with a leased line connection which are not present when getting "a free ride on existing hardware" (but a "free ride on existing phone bills" is much harder to hide if you have measured service...) Vince Fuller, Stanford University/BARRNet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110822352000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 14:56:25 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05585; Thu, 8 Nov 90 14:42:35 -0800 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 Nov 90 22:35:20 GMT From: usc!zaphod.mps.ohio-state.edu!mips!wdl1.wdl.fac.com!wdl51!wrl@ucsd.edu (Bill Lewandowski) Organization: Loral Western Development Labs Subject: Annex Terminal Server Message-Id: <1990Nov8.223520.1890@wdl1.wdl.fac.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, I have an annex terminal server. It works great on our local network. But, when I try and use it towards the internet, I get the destination unreachables. The netstat -r on the annex shows that there are routes to some of our cisco gateways. Even though the default route is not to our internet gateway, it should follow the icmp redirects. Anyone have any advise for me (besides throwing it away). We have a large meeting here next week and I would like to use it to allow people to access their home machines over the Internet. I have tried to tell it the correct default gateway with no results. Thanks, (Mail answers directly to me). -- Bill Lewandowski LORAL Western Development Labs (408) 473-4362 Internet: wrl@wdl1.wdl.fac.com FAX: (408) 473-7926 UUCP: wdl1!wrl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110900263300> Received: from thumper.bellcore.com by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 05:46:44 PST Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id AA21978; Fri, 9 Nov 90 08:46:46 EST Received: by chiya.bellcore.com (5.57/4.7) id AA02038; Fri, 9 Nov 90 08:46:33 -0500 Date: Fri, 9 Nov 90 08:46:33 -0500 From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9011091346.AA02038@chiya.bellcore.com> To: tcp-ip@sri-nic.arpa Subject: SLIP weirdness Often when running SLIP over modem home to work, SLIP will go down even though the modem stays up. When this happens, I simply restart SLIP, and even my rlogins stay up. Does anyone know why SLIP does this, or what diagnostics SLIP has so I can find out myself? PT ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110904515700> Received: from nmdsc20.nmdsc.nnmc.navy.mil by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 06:55:20 PST Received: by nmdsc20.nmdsc.nnmc.navy.mil (5.59/25-eef) id AA22691; Fri, 9 Nov 90 09:51:57 EST Date: Fri, 9 Nov 90 09:51:57 EST From: Bob Stratton Message-Id: <9011091451.AA22691@nmdsc20.nmdsc.nnmc.navy.mil> To: munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!manic!chris@uunet.uu.net Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Chris Clarkson's message of 8 Nov 90 <779@manic.communica.oz>) Subject: Adding a SLIP streams module to a 3b2 running WIN TCP/IP >I need to get SLIP up on a 3b2/400 & 3b2/600 running WIN TCP/IP and vanilla >3b2 System V.3 Unix. I can find plenty of Berkely SLIP examples but no >System V.3 examples. Can anyone point me towards articles, source or just give >me some general pointers on the complexity of what I'm contemplating? I'm working on the same issue, although I'm leaning toward PPP. If I get it ported, I'd be glad to send you a copy/mods to the BSD code, etc. If you do it first, PLEASE tell me what you did... The AT&T Enhanced TCP/IP WIN/3B has pretty good Berkeley compatibility routines in it as delivered. The real issue is one of linking the module into the Sys V kernel. I haven't tried this yet. I have seen SLIP implementations that seem to run as a user (as opposed to kernel) process, and if at all possible, I'm going to try to bring one of these up first, as I expect it'll be considerably easier. Thanks... Bob Stratton | dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet] NAVMEDATASERVCEN | dsc3rjs@vmnmdsc [BITNET] (Innova Comms. / AT&T) | 295-3503 [AV] +1 301 295 3322 [PSTNet] Disclaimer: The above opinions are mine alone - Who else would want them? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110905102500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 8 Nov 90 23:44:20 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17620; Thu, 8 Nov 90 23:37:58 -0800 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 Nov 90 05:10:25 GMT From: bu.edu!rpi!clarkson!nelson%image.soe.clarkson.edu@bloom-beacon.mit.edu (Russ Nelson) Organization: Clarkson University, Potsdam, NY Subject: Status of, and mailing list for Clarkson packet drivers Message-Id: <9011090510.AA09890@image.soe.clarkson.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi. This is just a note to keep you all up to date on the packet drivers, and to announce the creation of a mailing list for packet driver issues. I should also mention that it's the Clarkson *collection* of packet drivers, but that doesn't fit very well on the subject line. The mailing list: To subscribe to the mailing list, send an automated add request to listserv@sun.soe.clarkson.edu. Send a one line mail message whose sole contents are "add drivers". To get off the list, send "delete drivers". To send mail to a human (in case of trouble), send mail to drivers-request@sun.soe.clarkson.edu. To post to the list, send mail to drivers@sun.soe.clarkson.edu. The 7.x release: o The -w switch seems to cause problems, although I can't see why. o The Tiara and NE2000 packet drivers do not work with the -n switch. The fix is trivial but requires reassembling those drivers. o 3c523.com and 3c523_5.com are both broken. I have a replacement that seems to work. Ask me for it. o The wd8003e driver seems to be unreliable. You may wish to drop back to the 6.x version, available in sun.soe.clarkson.edu:pub/packet-drivers/ pktd6_0.arc. o I've seen the ni6510 driver head south. I haven't determined if it's the transmitter or receiver. It doesn't crash, it just stops sending (or receiving). Donations: Since the 7.x release, we've received donations of Ethernet equipment from Hewlett-Packard (including an Ethertwist hub), Cabletron, D-Link, and Digital Equipment Corporation. Thanks to all of them, their support is appreciated and encouraging. Please remember to tell your Ethernet equipment vendor that you're using the packet drivers. Otherwise, they have no way to know that the packet drivers "butter their side of the bread". The 8.x release (no date yet): o If anyone has any bug fixes or new drivers, please tell us about them, so that they may be included. o We have several new drivers: 3Com 3c507, D-Link DE-600, and Ungermann-Bass ubnicps2. o Everex has a Clarkson-derived packet driver for their SpeedLink-16 that they distribute without source. They promised to send us the source, but we haven't gotten it yet. o The new 3c507 driver sometimes goes deaf. This is unacceptable and must be fixed before the driver is released. Hopefully this is just a problem with the 3c507, and not a problem with the 82586 generic driver. o We have two new drivers in the works, an HP Ethertwist, and a DEPCA. o Someone is working on a Mylex driver. o I am working on "genericizing" the 8390 drivers, similar to the way the 82586 drivers use a common file. This serves two purposes, one to include the wd8003e high performance code in all 8390 drivers, and the other to write the Ethertwist driver. o I will include Jochen Kornitzky's changes that let a packet be upcalled to multiple protocol stacks. This is of great use to those running Novell who wish to run a packet spy, such as Netwatch or FTP's Lanwatch. Anyone thinking about using it to run two stacks of the same protocol should get more sleep, he says at midnight. :-) Useful projects I don't see myself finding the time for: o A real but small program written in C that uses the packet driver, with source code for study and modification. o A program or programs that exercise the packet drivers. For example, a ping client that loops through all possible packet sizes would be handy. Perhaps the PC-IP ping client could be modified to do this? o Genericize the three LANCE-based drivers, the ni6510, the nti16, and the (unreleased) isolink. o Write an article on the packet drivers for a PC programmer's magazine such a Programmer's Journal, or suchlike. -russ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110908153800> Received: from pX1.stfx.ca by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 11:00:11 PST Received: by pX1.stfx.ca (5.57/Ultrix3.0-C) id AA14950; Fri, 9 Nov 90 14:55:38 -0400 Date: Fri, 9 Nov 90 14:55:38 -0400 From: doucette@px1.stfx.ca (Gary Doucette) Message-Id: <9011091855.AA14950@pX1.stfx.ca> To: tcp-ip@nic.ddn.mil Subject: TCP - SLIP over Dialup I am interested in setting up slip for dialup access. Where should I start. Gary Doucette Network/Unix System Manager Saint Francis Xavier University Antigonish, Nova Scotia CANADA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [542.273aab6d@nbivax.nbi.dk] <1990110912131700> From: spang@nbivax.nbi.dk (Karsten Spang) Newsgroups: comp.os.vms,vmsnet.misc,comp.protocols.tcp-ip Subject: TCP/IP print server running under VMS and UCX Message-ID: <542.273aab6d@nbivax.nbi.dk> Date: 9 Nov 90 12:13:17 GMT Organization: Niels Bohr Institute and Nordita, Copenhagen Lines: 25 Posted: Fri Nov 9 13:13:17 1990 Hello I have a VAX/VMS system running DEC's TCP/IP implementation UCX. I need to have a print server process running on the VAX accept print files from an Apollo over TCP/IP and print them on a printer connected to the VAX. I probably need more than one print server, printing to different queues and/or forms, so it should be possible to 1) Run several print server processes on one machine 2) Specify the queue and form for each server process Does anybody know about a (public domain or commercially available) print server that fullfills these requirements? Please answer by e-mail, as I don't read this newsgroup regularly. Thanks in advance, Karsten -------------------------------------------------------------------------------- InterNet: spang@nbivax.nbi.dk (nbivax=129.142.100.3) Karsten Spang NORDUNET/HEPnet:NBIVAX::SPANG (NBIVAX=21.601=22105) Midtflxjene 22, 2tv VAXPSI MAIL: (0)238301032352::SPANG DK-2700 Brxnshxj Phone: +45 31 28 03 24 Denmark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110916565500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 09:29:37 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28430; Fri, 9 Nov 90 09:04:18 -0800 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 Nov 90 16:56:55 GMT From: sdd.hp.com!wuarchive!cs.utexas.edu!halley!news@ucsd.edu (usenet news) Organization: Tandem Micro Products Division Subject: Simple Book Message-Id: <1126@halley.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need information on the publisher of Marshall Rose's recent book on SNMP entitiled, I believe, "The Simple Book". Thanks, Phil Webster (Keep trying if halley bounces mail. It's flakey) (cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com) ^Preferred ^Most reliable (?) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011091209.aa15828@FSAC1.PICA.ARMY.MIL] <1990110917094700> From: tcora@PICA.ARMY.MIL (Tom Coradeschi) Newsgroups: comp.protocols.tcp-ip Subject: SLIP Advantages? Message-ID: <9011091209.aa15828@FSAC1.PICA.ARMY.MIL> Date: 9 Nov 90 17:09:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Electric Armaments Div, US Army Armaments RDE Center Lines: 8 Posted: Fri Nov 9 18:09:47 1990 I've been reading a bit about SLIP, and have a few questions. What are the real advantages of SLIP, over serial connections. I have a 9600bps dialin connection, via broadband cable, to the host I'm mailing this from. What do I gain by going to SLIP, which would make it worthwhile to broach the subject with the powers that be here. Please email your comments (as I cannot easily read USENET), and I'll summarize for the net. tom coradeschi <+> tcora@pica.army.mil <+> tcora@dacth01.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110918333700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 10:57:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01081; Fri, 9 Nov 90 10:47:50 -0800 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 Nov 90 18:33:37 GMT From: mintaka!olivea!orc!bu.edu!buit13!kwe@bloom-beacon.mit.edu (Kent England) Organization: Boston U. Information Technology Subject: Re: Multiple subnets on same cable Message-Id: <68286@bu.edu.bu.edu> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >What happens if different IP subnets live on the same ethernet cable? This question comes up often and bears mention occasionally. Don't forget that what happens with subnets depends on who is looking and how they are configured. If you subnet your (eg) Class B with eight bit subnet masks and you don't want (can't have) variable length subnets, then subnet layering looks attractive for configuring your routers. But your hosts can see things differently than their routers. If you layer subnets, you may set the subnet mask on these layered subnet hosts to be the network mask. They will then ARP for all members of their (subnetted) net and communicate directly to all their directly attached neighbors with no extra hops, failure points or extra traffic and the routers will answer for off-net members of the subnetted net, if your routers are set to proxy ARP. It works for 4.2BSD and it works well for layered subnets. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110918411700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 12:33:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03735; Fri, 9 Nov 90 12:19:29 -0800 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 Nov 90 18:41:17 GMT From: psuvm!jhl1@psuvax1.cs.psu.edu Organization: Penn State University Subject: DECnet encapsulation in TCP-IP Message-Id: <90313.134117JHL1@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We're interested in encapsulating DECnet within a TCP-IP package. We are looking primarily for a software solution, although hardware solutions would be considered. If anyone knows of such a product. please e-mail at the following address. JEFF@PSUPEN.PSU.EDU Thanks, Jeffrey H. Lynn Penn State College of Agriculture ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110918414900> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 16:53:30 PST Received: from PTEARN.FCL.RCCN.PT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1515; Fri, 09 Nov 90 19:52:53 EST Received: by PTEARN (Mailer X1.25) id 0827; Fri, 09 Nov 90 18:42:44 PRT Date: Fri, 09 Nov 90 18:41:49 PRT From: CHIS%PTEARN.BITNET@CUNYVM.CUNY.EDU To: TCP-IP@NIC.DDN.MIL Please, unsubcribe me. Ana Violante ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110918523000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 11:42:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01636; Fri, 9 Nov 90 11:07:35 -0800 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 Nov 90 18:52:30 GMT From: mips!wdl1.wdl.fac.com!wdl51!wrl@apple.com (Bill Lewandowski) Organization: Loral Western Development Labs Subject: ANNEX (FIXED) Message-Id: <1990Nov9.185230.10853@wdl1.wdl.fac.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, Thanks to all who replied. There were two problems. 1. I needed to have a /erpcd/bfs/gateways file that specified a default gateway. 2. (This one I don't understand) The problem turned out to be our cisco gateway security filters. We have them set to allow tcp in only to ports 1023 & above. (Standard set up). While using the debug icmp I could see that we were sending out 'destination unreachables'. I added a filter to allow any host to talk to our annex (any port) and it works. I guess the annex does not set up its tcp connections to use ports 1023 & above like normal systems (at least ones I'm used to). Thanks again to all the answers. Bill......... -- Bill Lewandowski LORAL Western Development Labs (408) 473-4362 Internet: wrl@wdl1.wdl.fac.com FAX: (408) 473-7926 UUCP: wdl1!wrl ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110919394900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 21:08:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09221; Fri, 9 Nov 90 20:59:01 -0800 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 Nov 90 19:39:49 GMT From: eagle!news@ucbvax.Berkeley.EDU (Steven Eubanks) Organization: NASA/Lewis Research Center, Cleveland Subject: Looking for SMB/NETBIOS/RFC1001/RFC1002 server product Message-Id: <1990Nov9.193949.23062@eagle.lerc.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am interested in examining NETBIOS/SMB servers for both *NIX and VMS-based platforms. I'm aware of one company call Syntax Systems having a product in this area. Are there others? Company names and phone numbers would be appreciated as well as any experiences with this type of product (good and/or bad). Thanks in advance! Steve -- Steven W. Eubanks, EDS/LIMS NASA Lewis Research Center Internet:xxseub@osprey.lerc.nasa.gov 21000 Brookpark Rd. (216)433-8498 Cleveland, OH 44135 Disclaimer: Opinions like mileage, may vary. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110920165400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 18:53:45 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06576; Fri, 9 Nov 90 18:42:25 -0800 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 Nov 90 20:16:54 GMT From: julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sccsi.com!sugar!ficc!peter@apple.com (Peter da Silva) Organization: Xenix Support, FICC Subject: Re: Cost of Internet access Message-Id: References: <9011061147.AA20765@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011061147.AA20765@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET writes: > Dialup IP services are quite inexpensive, and if set up with care will > give all the advantages of a dedicated circuit only with an occasional > 30 second delay (those times when the line must be brought up.) Um, won't this cause problems with SMTP? What does SMTP do when the destination is only available for brief periods, or should you handle your mail via an MX? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110921133100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 14:23:57 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06444; Fri, 9 Nov 90 13:49:16 -0800 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 Nov 90 21:13:31 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Organization: Morning Star Technologies Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) Message-Id: References: <9011071458.AA25335@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil - Does tn3270 work with X-Windows(Openlook and Motif), Sunview and ASCII Terminals ? The curses output can be sent to a terminal emulator running in a window. Alternatively, get expo.lcs.mit.edu:contrib/x3270-1.2.tar.Z, Jeff Sparkes' X port of Robert Viduya's 3270tool. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110922193800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 10:02:45 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05231; Mon, 12 Nov 90 09:52:44 -0800 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 Nov 90 22:19:38 GMT From: ceco!jon@uunet.uu.net (Jon Castle) Organization: Commonwealth Edison Co., Chicago, IL Subject: Problem with Xmodem and Micom terminal server (was Re: Problem with Xmodem and 3Com terminal server) Message-Id: <222@ceco.ceco.com> References: <9011071849.AA21432@ain.ESD.3Com.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011071849.AA21432@ain.ESD.3Com.COM> rxk@ain.ESD.3Com.COM (Rajeev Kochhar) writes: }mmorse@Z.NSF.GOV ("Michael H. Morse") writes: } }>I am having a problem getting Xmodem to work between a Sun workstation }>and a PC running a terminal emulator. } }>The PC uses a modem and a dial-up line to communicate, but it cannot }>get to the workstation directly because the workstation has no serial }>ports. Instead, the PC logs on to some other host, and then uses }>telnet to get to the workstation. } }>I suspect this has something to do with parity, since the ASCII {>characters transmitted by Xmodem, and received by the PC are {>identical. Has anybody run into a similar problem? Any information on {>how telnet reacts when raw mode is selected would be appreciated. { {For a completely transparent session the terminal parameters should be set {as following: { {XmitBinary = ON {FlowControlTo = none {FlowControlFrom = none {ECMChar = disable {BreakChar = disable {DataBits = 8 {Parity = None { I have exactly the same problem only this is with a Micom terminal server (the InstaGate1500). I dial up from home to a modem at work through the terminal server, and then connect to a Sun. I tried seting up similar settings in the Micom InstaGate1500, but to no avail. I must be missing something. Does anyone have a Micom specific solution to this problem? Thanks. Jon Castle jon@ceco.com Commonwealth Edison Co. (312)294-2824 Chicago, IL ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27@uarthur.UUCP] <1990110922231300> From: rpcfod@uarthur.UUCP (Robert Patt-Corner) Newsgroups: comp.protocols.misc,news.software.nntp,comp.protocols.tcp-ip Subject: NNTP (Network News Transfer Protocol) Query Keywords: NNTP netnews billing administration Message-ID: <27@uarthur.UUCP> Date: 9 Nov 90 22:23:13 GMT Lines: 27 Posted: Fri Nov 9 23:23:13 1990 Our organization is looking to implement netnews -- we're at the beginning, where things can be started well or badly. I'm convinced we should implement NNTP (network news transfer protocol) and encourage users to use nntp front ends, such as the NetNews reader for the Mac done by Harry Chesley. This is a request for some help in: 1. Finding the appropriate newsgroup to start a discussion? It's not at all clear to me where NNTP discussions go. 2. Investigating the two big barriers that NNTP faces here: a. How can you charge back to support a service whose main virtue is that it does not require a user account to use? b. What front ends for NNTP are available for boxes other than Mac's, especially DOS boxes. 3. Finding Harry Chesley's email address? Please respond by mail ... I'll move the thread appropriately. Thanks - Robert ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990110923440900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 20:38:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08598; Fri, 9 Nov 90 20:26:55 -0800 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 Nov 90 23:44:09 GMT From: sdcc6!jclark@ucsd.edu (John Clark) Organization: University of California, San Diego Subject: ETHERNET Packet TYPES Message-Id: <14048@sdcc6.ucsd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need to know where to find the registered ethernet types which can occur in the ethernet packet type field. The standard '/usr/include/..." type files have what the local unix machine is capable of understanding but leave no clue as to what else one may expect when one is monitoring raw packets from the net. -- John Clark jclark@ucsd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011100152.AA05630@ucbvax.Berkeley.EDU] <1990111001523000> From: CHIS@PTEARN.BITNET Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9011100152.AA05630@ucbvax.Berkeley.EDU> Date: 10 Nov 90 01:52:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Posted: Sat Nov 10 02:52:30 1990 X-Unparsable-Date: Fri, 09 Nov 90 18:41:49 PRT Please, unsubcribe me. Ana Violante ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111002412900> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 10:52:38 PST Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA15440; Sat, 10 Nov 90 10:52:30 PST Received: by nms. (4.0/SMI-4.0) id AA19277; Sat, 10 Nov 90 09:41:30 PST From: salzman@nms.hls.com (Mike Salzman) Message-Id: <9011101741.AA19277@nms.> Subject: Re: Looking for SMB/NETBIOS/RFC1001/RFC1002 server product To: xxseub@osprey.lerc.nasa.gov Date: Sat, 10 Nov 90 9:41:29 PDT Cc: tcp-ip@nic.ddn.mil In-Reply-To: <1990Nov9.193949.23062@eagle.lerc.nasa.gov>; from "Steven Eubanks" at Nov 9, 90 7:39 pm Organization: Hughes Lan Systems, Mt View Ca X-Mailer: ELM [version 2.2 PL0] Steve, There is a company in the Seattle area, called Interconnections who developed the IPX stack and server for VMS. That product is primarily sold by Novell, as Novell for VMS. They had plans to branch out into the LAN MAN area with SMB services at some point. I last talked to them in 88. Anyway, they may be reached at (206) 881-5773 voice, or (206) 867-5022 fax. Address: InterConnections Inc. 14711 N.E. 29th Place, Suite 100 Bellevue, Wa 98007 -------------------- salzman@hls.com ---------------------- Michael M. Salzman Voice (415) 966-7479 Fax (415)960-3738 Hughes Lan Systems 1225 Charleston Road Mt View Ca 94043 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111002574900> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 08:25:06 PST To: Peter da Silva cc: tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET Subject: Re: Cost of Internet access In-reply-to: Your message of 09 Nov 90 20:16:54 +0000. Date: Sat, 10 Nov 90 11:17:49 -0500 From: jcurran@SH.CS.NET Regarding dialup IP services, Peter da Silva writes: > Um, won't this cause problems with SMTP? What does SMTP do when the > destination is only available for brief periods, or should you handle > your mail via an MX? As long your implementation automatically brings up the circuit when there is a packet queued (at either end), the application layer can not distinguish dialup IP services from dedicated. SMTP simply gets a long delay on the initial connection. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111005551400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 03:39:17 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15558; Sat, 10 Nov 90 03:28:06 -0800 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 Nov 90 05:55:14 GMT From: mintaka!olivea!oliveb!pyramid!cbmvax!grr@bloom-beacon.mit.edu (George Robbins) Organization: Commodore, West Chester, PA Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <15782@cbmvax.commodore.com> References: <90313.134117JHL1@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: > We're interested in encapsulating DECnet within a TCP-IP package. We > are looking primarily for a software solution... I believe TGV multinet can handle this... -- 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---- <1990111006182200> Received: from ICS.UCI.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 19:45:09 PST Received: from ics.uci.edu by ICS.UCI.EDU id aa24751; 10 Nov 90 19:38 PST To: halley!phil@cs.utexas.edu cc: webster_phil@tandem.COM, tcp-ip@nic.ddn.MIL Subject: Re: Simple Book In-reply-to: 09 Nov 90 16:56:55 GMT. Cc: Einar Stefferud Date: Sat, 10 Nov 90 19:38:22 -0800 Message-ID: <24749.658294702@ics.uci.edu> From: Einar Stefferud > Date: 09 Nov 90 16:56:55 +0000 > Subject: Simple Book > From: halley!phil@cs.utexas.edu >To: tcp-ip@nic.ddn.mil > I need information on the publisher of Marshall Rose's recent book on > SNMP entitiled, I believe, > "The Simple Book". > Thanks, > Phil Webster (Keep trying if halley bounces mail. It's flakey) > (cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com) > ^Preferred ^Most reliable (?) @book{Simple.Book, author = mtr, title = "{The Simple Book: An Introduction to Management of TCP/IP-based internets}", publisher= {Prentice-Hall}, address = {Englewood Cliffs, New Jersey}, series = {Prentice Hall Series in Innovative Computing}, year = 1990, note = {ISBN 0--13--812611--9} } ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111015440100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 11:10:04 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22101; Sat, 10 Nov 90 11:03:25 -0800 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 Nov 90 15:44:01 GMT From: sdd.hp.com!uakari.primate.wisc.edu!ra!emory!hubcap!ncrcae!ncr-sd!simasd!jadpc!jdeitch@ucsd.edu (Jim Deitch) Organization: Network Engineering Technologies Subject: Re: Cost of Internet access Message-Id: <1990Nov10.154401.274@jadpc.cts.com> References: <9011061147.AA20765@ucbvax.Berkeley.EDU>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <9011061147.AA20765@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET writes: >> Dialup IP services are quite inexpensive, and if set up with care will >> give all the advantages of a dedicated circuit only with an occasional >> 30 second delay (those times when the line must be brought up.) > >Um, won't this cause problems with SMTP? What does SMTP do when the >destination is only available for brief periods, or should you handle >your mail via an MX? >-- >Peter da Silva. `-_-' >+1 713 274 5180. 'U` >peter@ferranti.com Not at all. SMTP will just hold the message on queue until either sendmail or whatever you are using to smtp with wakes up and tries again to send it. If it can't connect within about 3 days or so then it is returned to the sender. This is the way it works for both directions. Once you have the link up you can invoke sendmail -q to run the queue and deliver what it can. Jim -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011101731.AA20352@ucbvax.Berkeley.EDU] <1990111016174900> From: jcurran@SH.CS.NET Newsgroups: comp.protocols.tcp-ip Subject: Re: Cost of Internet access Message-ID: <9011101731.AA20352@ucbvax.Berkeley.EDU> Date: 10 Nov 90 16:17:49 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Posted: Sat Nov 10 17:17:49 1990 Regarding dialup IP services, Peter da Silva writes: > Um, won't this cause problems with SMTP? What does SMTP do when the > destination is only available for brief periods, or should you handle > your mail via an MX? As long your implementation automatically brings up the circuit when there is a packet queued (at either end), the application layer can not distinguish dialup IP services from dedicated. SMTP simply gets a long delay on the initial connection. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111017511400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 11:09:50 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21928; Sat, 10 Nov 90 10:56:18 -0800 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 Nov 90 17:51:14 GMT From: rogue.llnl.gov!oberman@lll-winken.llnl.gov Subject: Re: ETHERNET Packet TYPESREAD/NEW/FOLLOWUP Message-Id: <1990Nov10.105114.1@rogue.llnl.gov> References: <14048@sdcc6.ucsd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <14048@sdcc6.ucsd.edu>, jclark@sdcc6.ucsd.edu (John Clark) writes: > > I need to know where to find the registered ethernet types > which can occur in the ethernet packet type field. The standard > '/usr/include/..." type files have what the local unix machine > is capable of understanding but leave no clue as to what else > one may expect when one is monitoring raw packets from the net. See RFC1060. It is available from NIC.DDN.MIL. FTP NIC.DDN.MIL ftp> Login anonymous Password: your-user-name ftp> cd rfc: (The ":" is CRITICAL!) ftp> get rfc1060.txt ftp> quit 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---- <1990111020094200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 13:39:52 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24877; Sat, 10 Nov 90 13:36:56 -0800 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 Nov 90 20:09:42 GMT From: sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino@decwrl.dec.com Organization: University of Kansas Academic Computing Services Subject: humanitarian request Message-Id: <26685.273c1836@kuhub.cc.ukans.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Dear NetFolks, We would appreciate your responding to the request of Craig Shergold who is a seven year old boy with an inoperable tumor on his brain. He has not been given a very long time to live and it is Craig's ambition to enter the Guiness Book of World Records for the largest number of get well cards ever received by an individual. Please send your card to: Craig Shergold % Children's Make-A-Wish Foundation 32 Parimeter Center East Atlanta, Georgia 30346 ------------------------------------- Letters similar to this have been sent out by traditional mail to large organizations all across the U.S. on Craigs behalf. Instead of passing it on by land-mail, I thought the net would be a great way of getting the word out to as many people as possible in as short a time as possible. Please pitch-in & send Craig a get well card, and by all means feel free to circulate this letter to local businesses/organizations, or other BBS's you may belong to. All your help and effort will certainly be appreciated! Thank you. Sincerely, Jack Petrino ---------------------------------------------------------------------- Jack Petrino (DRAGON) int: PETRINO@KUHUB.CC.UKANS.EDU Systems Testing bit: PETRINO@UKANVAX University of Kansas vox: (913)864-0443 Computer Center fax: (913)864-0485 ----------------------------------------------------------------------- PS - I apologize for the possible redundancy of posting this net-wide. I hope everyone can understand the necessity/urgency of the situation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111023063600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 12:09:45 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23278; Sat, 10 Nov 90 12:09:45 -0800 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 Nov 90 23:06:36 GMT From: world!bzs@decwrl.dec.com (Barry Shein) Organization: The World Subject: Re: Cost of Internet access Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >As long your implementation automatically brings up the circuit when there >is a packet queued (at either end), the application layer can not distinguish >dialup IP services from dedicated. SMTP simply gets a long delay on the >initial connection. That doesn't quite answer Peter's message. What about some random host out there with mail for you? He tries to connect, gets a timeout since you're not dialed in at the moment, and re-queues. Chances are slim that you'll be dialed in when he happens to retry unless you're dialed in a lot. Of course, if the other host will also dial you then that's a solution. But I'm pretty sure (due to voice network charges and the service relationship usually implied) this is not the model most people are thinking of, they are effectively a leaf node and dial a centralized host providing the SLIP service to them. One has to either use MX records so the centralized host accepts and forwards the mail (the easiest solution), or use something like POP. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111102531000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 21:42:43 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03706; Sat, 10 Nov 90 21:35:16 -0800 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 Nov 90 02:53:10 GMT From: stan!marvin!imp@boulder.colorado.edu (Warner Losh) Organization: Solbourne Computer, Inc. Subject: Re: Cost of Internet access Message-Id: <1990Nov11.025310.25098@Solbourne.COM> References: , <9011101731.AA20352@ucbvax.Berkeley.EDU>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Someone write: >>As long your implementation automatically brings up the circuit when there >>is a packet queued (at either end), the application layer can not distinguish >>dialup IP services from dedicated. SMTP simply gets a long delay on the >>initial connection. But most systems time out if they don't get a connection after 30 seconds or so. When I dial in to work from home, it takes at least that long to make the connection. Since a mailer will requeue to try later (anywhere from 10 minutes to a day depending on the mailer%), the line may well have disconnected by then to save charges. In article bzs@world.std.com (Barry Shein) writes: >Of course, if the other host will also dial you then that's a >solution. But I'm pretty sure (due to voice network charges and the >service relationship usually implied) this is not the model most >people are thinking of, they are effectively a leaf node and dial a >centralized host providing the SLIP service to them. However, SMTP doesn't work this way in practice. Sure, there is a command that tells the mail daemon on a remote machine to send mail down the line, but it isn't widely implemented. Unless my machine can connect to your machine, the mail usually doesn't go out. >One has to either use MX records so the centralized host accepts and >forwards the mail (the easiest solution), or use something like POP. This sounds like a good idea. But if you are going to do dialup already, why not just use uucp mail? It is simpler to setup than arranging slip lines. The whole idea of dialup access is good, if it can be done "fast" and on demand. TCP connection would show the line is still in use, but how do you work out things like UDP packets? There is no "connection" data or state associated with them. Warner -- %Mailers -- Sendmail is one mailer that is on the Internet. There are others that don't behave the same way that sendmail does, but are not the less just as standard conforming as sendmail. -- Warner Losh imp@Solbourne.COM How does someone declare moral bankruptcy? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111104350000> Received: from nusc.navy.mil by NIC.DDN.MIL with TCP; Sun, 11 Nov 90 06:39:32 PST Date: 11 Nov 90 09:35:00 EST From: "VSDEC::SHERMAN" Subject: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? To: "tcp-ip" Hi. I've had/seen an intermittent problem over the last 8 years, and I have yet to bump into anybody who can explain why I see this problem, or what it is. I'll be connected to some computer via modem doing my normal work when suddenly I'll get about 60 uppercase Us on my screen. From then on, everything I type gets echoed on my CRT but I get no responses back from the computer that I'm connected to. I've tried typing commands that would effect things on the computer that I'm dialed up to so that when I sign back on again I could tell if it was seeing what I typed, but the commands were never acted upon. But the modem is still off-hook and got a carrier- detect. I've seen the mysterious UUUUUUUs using different terminals and terminal emulators, when using different modems, when dialed up not only to different computers, but also different sites across the country. Does anybody there know what this is? I only happens perhaps 3 or 4 times a year, but it's always very annoying and extremely puzzling. Bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111108492900> Received: from alw.nih.gov by NIC.DDN.MIL with TCP; Sun, 11 Nov 90 10:49:56 PST Received: from cu.nih.gov by alw.nih.gov (5.61/alw-2.1) id AA09427; Sun, 11 Nov 90 13:45:58 -0500 Message-Id: <9011111845.AA09427@alw.nih.gov> To: tcp-ip@nic.ddn.mil From: "Roger Fajman" Date: Sun, 11 Nov 90 13:49:29 EST Subject: Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? This is rather off the subject of TCP/IP. Perhaps further discussion should be moved to Info-Modems Digest. There was a bug in the original Bell 212 modem that managed to make its way into some compatible modems. The modem would erroneously enter remote digital loop. On one end this appeared as a continuous stream of Us and on the other as a hung connection. The bug was fixed in later versions of the 212. The bypass was to disable remote digital loop. At NIH we were early users of the 212 and worked with AT&T (Bell Labs, as I recall) to assist them in tracking down the cause of the problem. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011111530.AA10882@ucbvax.Berkeley.EDU] <1990111114350000> From: sherman%vsdec.decnet@NUSC.NAVY.MIL ("VSDEC::SHERMAN") Newsgroups: comp.protocols.tcp-ip Subject: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? Message-ID: <9011111530.AA10882@ucbvax.Berkeley.EDU> Date: 11 Nov 90 14:35:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Posted: Sun Nov 11 15:35:00 1990 Hi. I've had/seen an intermittent problem over the last 8 years, and I have yet to bump into anybody who can explain why I see this problem, or what it is. I'll be connected to some computer via modem doing my normal work when suddenly I'll get about 60 uppercase Us on my screen. From then on, everything I type gets echoed on my CRT but I get no responses back from the computer that I'm connected to. I've tried typing commands that would effect things on the computer that I'm dialed up to so that when I sign back on again I could tell if it was seeing what I typed, but the commands were never acted upon. But the modem is still off-hook and got a carrier- detect. I've seen the mysterious UUUUUUUs using different terminals and terminal emulators, when using different modems, when dialed up not only to different computers, but also different sites across the country. Does anybody there know what this is? I only happens perhaps 3 or 4 times a year, but it's always very annoying and extremely puzzling. Bill ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111117085800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 11 Nov 90 09:25:53 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12075; Sun, 11 Nov 90 09:20:08 -0800 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 Nov 90 17:08:58 GMT From: paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) Organization: University of Illinois at Urbana Subject: Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? Message-Id: <1990Nov11.170858.9657@ux1.cso.uiuc.edu> References: <9011111530.AA10882@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil sherman%vsdec.decnet@NUSC.NAVY.MIL ("VSDEC::SHERMAN") writes: >Hi. > >I've had/seen an intermittent problem over the last 8 years, and >I have yet to bump into anybody who can explain why I see this >problem, or what it is. > >I'll be connected to some computer via modem doing my normal work >when suddenly I'll get about 60 uppercase Us on my screen. From >then on, everything I type gets echoed on my CRT but I get no >responses back from the computer that I'm connected to. Some line noise is triggering the remote modem to go into a test mode and/or loopback. Upper case 'U' characters have an alternating 1-0 bit pattern useful for testing BER, etc. The fix is to disable remote toggling of test mode. /pbp -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111117335800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 11 Nov 90 10:10:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12382; Sun, 11 Nov 90 09:44:49 -0800 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 Nov 90 17:33:58 GMT From: usc!zaphod.mps.ohio-state.edu!ub!palter@ucsd.edu (Bill Palter) Organization: The Wollongong Group Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) Message-Id: <45583@eerie.acsu.Buffalo.EDU> References: <9011071458.AA25335@ftp.com>, <90312.114531CJS@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <90312.114531CJS@psuvm.psu.edu> CJS@psuvm.psu.edu writes: >In article <9011071458.AA25335@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen) >says: >We are using FTP Software's TN3270 to telnet to an AS/400. It works >pretty good; I wish it (TN3270) supported color or at least extended >attributes (like underscore). The default 3270-to-5250 keyboard mapping >(on the AS/400) is brain-damaged, but (somewhat) easily remedied with a >user command. Also, it only does 24 lines. I also use FAL's telnet to >log onto the AS/400. Extended color and highlighting work. > >Because of the weirdness in remapping the 3270->5250 keys, I wish I had a >TN3720 that allowed its keyboard remapping to define more than one 3270 >key to be transmitted with one PC key. The 5250 has 24 PF keys plus more >than the usual 3270 attention keys: help, page up (roll down) and page >down (roll up), some some functions have to be mapped to dual 3270 >attention keys (PA1+PFx or PA2+PFx). A TN5250 would be nice for this >reason. Can anyone point me to an IBM manual that describes a 5250 manual, or a list of differences it has from a 3270. I have just finished implementing a new tn3270 and I am thinking about doing 3179-G or 5250 emulation as well. Bill Palter Palter@twg.com The Wollongong Group 2010 Corporate Ridge Drive McLean VA. 22102 (703) 847-4570 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111119422800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sun, 11 Nov 90 09:10:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11841; Sun, 11 Nov 90 08:58:50 -0800 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 Nov 90 19:42:28 GMT From: world!bzs@decwrl.dec.com (Barry Shein) Organization: The World Subject: Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? Message-Id: References: <9011111530.AA10882@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In ASCII "U" is hex 55 or, in binary, your message is 01010101010101010101 Perhaps that's a clue. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111123501900> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 05:11:51 PST To: Warner Losh cc: tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET Subject: Re: Cost of Internet access In-reply-to: Your message of 11 Nov 90 02:53:10 +0000. <1990Nov11.025310.25098@Solbourne.COM> Date: Mon, 12 Nov 90 08:10:19 -0500 From: jcurran@SH.CS.NET > This sounds like a good idea. But if you are going to do dialup > already, why not just use uucp mail? It is simpler to setup than > arranging slip lines. > > The whole idea of dialup access is good, if it can be done "fast" and > on demand. TCP connection would show the line is still in use, but > how do you work out things like UDP packets? There is no "connection" > data or state associated with them. > > Warner Dialup IP provides a general transport service for mail, ftp, telnet, etc. Many people are using dialup IP with automatic initiation for this reason and it works quite well. Certainly a little care has to be used when setting up mail and DNS [kids, don't try this at home..], but it's worth it for those sites who can't afford the cost of a dedicated circuit. This line of conversation started regarding the high cost of connecting to the Internet; it's important to show there are alternatives to the direct line. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111200560300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 09:30:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03859; Mon, 12 Nov 90 09:18:31 -0800 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 Nov 90 00:56:03 GMT From: usc!samsung!munnari.oz.au!bruce!gdwb.oz.au!csb@apple.com (Craig Bishop) Subject: Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP) Message-Id: <552@rome.gdwb.oz.au> References: <9011071458.AA25335@ftp.com>, <90312.114531CJS@psuvm.psu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil CJS@psuvm.psu.edu writes: >Because of the weirdness in remapping the 3270->5250 keys, I wish I had a >TN3720 that allowed its keyboard remapping to define more than one 3270 >key to be transmitted with one PC key. The 5250 has 24 PF keys plus more >than the usual 3270 attention keys: help, page up (roll down) and page >down (roll up), some some functions have to be mapped to dual 3270 >attention keys (PA1+PFx or PA2+PFx). A TN5250 would be nice for this >reason. I also would like TN5250. But even better would be an implementation "x3270" which was "x5250". Anyone out there dong this? -- Craig Bishop Geelong & District Water Board Phone: +61 52 262506 61-67 Ryrie St Geelong Fax: +61 52 218236 Victoria 3220 Australia ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111200592600> Received: from NNSC.NSF.NET (WS6.NNSC.NSF.NET) by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 06:18:48 PST To: tcp-ip@nic.ddn.mil Subject: dial-up IP questions From: Craig Partridge Date: Mon, 12 Nov 90 09:19:26 -0500 Sender: craig@NNSC.NSF.NET There were a couple of questions about dial-up IP behavior that I'd like to respond to (by the way, all this stuff was covered in a paper on dial-up IP that Leo Lanzillo and I gave at the 1989 Winter USENIX). Connection set up time: Someone pointed out that many TCPs limit their open timeout to 30 seconds, which means dialing a link has to be done in less than 30 seconds. This is a known problem -- it turns out that you often find that dial-up IP connects the link just as your SYN times out (recall that 30 seconds includes delays before you get to the dial-up gateway, so even a dial-up IP that can connect, in say, 15 seconds, often loses). However Host Requirements now require TCPs to have a much longer timeout, so if your TCP still does 30 seconds, beat up on your vendor. SMTP: There was a question about j-random host trying to SMTP to your system which is behind a dial-up IP link. If the link can be brought up at any time, then assuming your TCP is HRRFC conformant, no problem. However, some sites limit the times their link can be brought up to minimize phone costs (e.g. only at evening and weekend rates). In these situations, people use MX records to forward their mail to a particular machine, and then have a program that tickles the remote mailer to deliver to them. (This is NOT done using TURN; rather the final destination machine telnets to a special port, which causes the SMTP daemon to start up -- this avoids the security problems of TURN). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111201000200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 09:00:36 PST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 12 Nov 90 09:00:34 -0800 Date: Mon, 12 Nov 90 09:00:02 PST From: postel@venera.isi.edu Posted-Date: Mon, 12 Nov 90 09:00:02 PST Message-Id: <9011121700.AA05977@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Mon, 12 Nov 90 09:00:02 PST To: jclark@ucsd.edu, sdcc6!jclark@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: ETHERNET Packet TYPES John Clark: See page 35 of RFC-1060. --jon. Date: 9 Nov 90 23:44:09 GMT From: sdcc6!jclark@ucsd.edu (John Clark) Subject: ETHERNET Packet TYPES To: tcp-ip@nic.ddn.mil I need to know where to find the registered ethernet types which can occur in the ethernet packet type field. The standard '/usr/include/..." type files have what the local unix machine is capable of understanding but leave no clue as to what else one may expect when one is monitoring raw packets from the net. John Clark jclark@ucsd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111201232100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 09:00:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02621; Mon, 12 Nov 90 08:48:23 -0800 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 Nov 90 01:23:21 GMT From: att!emory!utkcs2!eljazzar@ucbvax.Berkeley.EDU (Mohamad El Jazzar) Organization: University of Tennessee Computing Center, Knoxville Subject: Re: NCSA Telnet question Message-Id: <1990Nov12.012321.21447@cs.utk.edu> References: <16367@hydra.gatech.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file. >I've set an environment variable CONFIGTEL to point to this file (as >mentioned in the docs), but the programs still can't find it. Is the >environment variable different? > >Eric Try this: SET CONFIG.TEL=path-to-your-config.tel (not CONFIGTEL) It seems that this is a bug (feature?) in NCSA Telnet. Mohamad ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111201581900> Received: from cim-tune.Honeywell.COM by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 06:00:42 PST Received: by cim-tune.Honeywell.COM ( 5.52 (84)/25b-eef) id AA01901; Mon, 12 Nov 90 07:58:21 CST Message-Id: <9011121358.AA01901@cim-tune.Honeywell.COM> To: "VSDEC::SHERMAN" Cc: "tcp-ip" , bergum@cim-tune.Honeywell.COM Subject: Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? In-Reply-To: Your message of 11 Nov 90 09:35:00 EST. <9011111545.AA01650@cim-tune.Honeywell.COM> Date: Mon, 12 Nov 90 07:58:19 CST From: Dave Bergum > Date: 11 Nov 90 09:35:00 EST > From: "VSDEC::SHERMAN" > Subject: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? > To: "tcp-ip" > > Hi. > > I've had/seen an intermittent problem over the last 8 years, and > I have yet to bump into anybody who can explain why I see this > problem, or what it is. > > I'll be connected to some computer via modem doing my normal work > when suddenly I'll get about 60 uppercase Us on my screen. From > then on, everything I type gets echoed on my CRT but I get no > responses back from the computer that I'm connected to. I've > tried typing commands that would effect things on the computer > that I'm dialed up to so that when I sign back on again I could > tell if it was seeing what I typed, but the commands were never > acted upon. But the modem is still off-hook and got a carrier- > detect. > > I've seen the mysterious UUUUUUUs using different terminals and > terminal emulators, when using different modems, when dialed up > not only to different computers, but also different sites across > the country. > > Does anybody there know what this is? I only happens perhaps 3 > or 4 times a year, but it's always very annoying and extremely > puzzling. You'll probably get a million responses to this...your modem is going into remote digital loopback test mode with the modem at the other end. Occassionally you will get a burst of noise which looks to the modem at the other end to be the escape sequence to put it into remote digital loopback test mode. In this mode a continuous stream of test data is sent and compared with the known values. This is a test used to evaluate the connection between the modems. There are configuration straps in most modems that allow you do enable/disable the RDL test mode from line commands. Normally when a modem is put into RDL, its local interface goes into analog loop test mode. Sometimes you can get it out of test mode by putting your own modem into RDL and then setting it back to normal mode. Sometimes that just drops the line. A -----/|\---------------------------------------+ - / | \ Bergum@CIM-VAX.Honeywell.COM | - /__|__\ Dave Bergum [MN26-3190] | - t--'--/ 2701 4-th Ave. S., Mpls, MN 55408 | -~~~~~~~~~~ (612)870-5839 | -----------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111203080700> Received: from ftp.com by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 08:26:46 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA06647; Mon, 12 Nov 90 11:28:07 -0500 Date: Mon, 12 Nov 90 11:28:07 -0500 Message-Id: <9011121628.AA06647@ftp.com> To: world!bzs@decwrl.dec.com (Barry Shein) Subject: Re: Cost of Internet access From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com One has to either use MX records so the centralized host accepts and forwards the mail (the easiest solution), or use something like POP. -- -Barry Shein And thus my posting a while ago asserting that "the time has come for distributed mail protocols". The SMTP outbound queue is not the best place to hold messages while you wait for intermittent connectivity. POP or PCMAIL or IMAP are a tremendous improvement. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111208384900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 11:17:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08405; Mon, 12 Nov 90 11:11:01 -0800 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 Nov 90 08:38:49 GMT From: mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net (Daniel Huber) Organization: Ascom Autelca AG, CH-3073 Guemligen Switzerland Subject: PPP over ..... Does it work ? (HP) Message-Id: <1109@aut.autelca.ascom.ch> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Question to somebody with experience: Will that work? I'd like to connect two UNIX computers (HP9000/835 and HP9000/375, both with HP-UX 7.0) over a serial link. HP distributes PPP on a tape (X.25 software, fileset NETINET i think) for the 800 series. About 300 series, I don't know. Anybody knows ? The way of connection: 835 HP9000/835S, name "aut" ^ | v serial line, 19200Bd <30m, probably only 9600Bd ^ | v asynchron to synchron needed for multiplexer ^ (only able to mux synchron) | <2m v multiplexer 19200Bd -> AS/400 to 5394 (sync) ^ 19200Bd -> PPP | 9600Bd -> 6150 connection v 64kB/s modem \ ^ | > ~3km, digital link v 64kB/s modem / ^ | v multiplexer 19200Bd -> 5394 to AS/400 (sync) ^ 19200Bd -> PPP | 9600Bd -> 6150 connection v synchron to asynchron needed for multiplexer ^ (only able to mux synchron) | v serial line, 19200Bd <4m, probably only 9600Bd ^ | v 375 HP9000/375, name "oscad1" I want to start the connection at boot time. Programms running over this link: r-programms, telnet, ftp... What's happen if one machine goes down? Is this connection transparent to users? (if routing is correct) Is this connection usefull? (performance etc.) Is NFS possible? ;-) And the most important question: Does it work ? What would I need, to connect the two computers over a synchron line? Thanks for any responses. Daniel -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 53 01 CH-3073 Guemligen email: dhuber@autelca.ascom.ch Switzerland uucp: uunet!mcsun!chx400!hslrswi!aut!dhuber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111208472900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 18:27:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02179; Mon, 12 Nov 90 18:14:02 -0800 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 Nov 90 08:47:29 GMT From: cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!ab4@rutgers.edu (Andrew M. Boardman) Organization: Quiche Eaters Anonymous Subject: Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen? Message-Id: <1990Nov12.084729.16629@cunixf.cc.columbia.edu> References: <9011111530.AA10882@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil There was a an exhaustive discussion of this a while ago, in, I believe, comp.dcom.telecom. I seem to remember that this was caused by modems trying to resync -- they would send alternating 1's and 0's until they got back on speaking terms. /a ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111210002900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 20:15:01 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05503; Mon, 12 Nov 90 20:10:05 -0800 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 Nov 90 10:00:29 GMT From: eru!hagbard!sunic!mcsun!ukc!mucs!logitek!martino@bloom-beacon.mit.edu (Martin O'Nions) Organization: Logitek Plc. Subject: Re: Multiple subnets on same cable Message-Id: References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil freiss@nixdorf.de (the hacker) writes: >This might be a silly question, but it's been worrying me for some time. >What happens if different IP subnets live on the same ethernet cable? >I'm worried about excessive ICMP traffic (ICMP net_redirect packets); >I see some SGI workstations here react to some packets from a >different subnet with this ICMP message. >Could somebody tell me if this is a problem or what other >problems I haven't even thought of might arise? >Pointers to books, RFCs etc. on this subject are also welcome. Observe caution! RFC950 adds a couple of new ICMP types, including one to allow determination of subnet mask for this segment. This specifically states that a host may request the active subnet mask EVEN IF IT DOES NOT KNOW ITS OWN IP ADDRESS (IP 0.0.0.0 (!?**@!)). Therefore, even though it it is (hopefully) unlikely to occur, this section of the specification could cause prob's if someone chose to implement the RFC in this detail. (P.S. If anyone has any info. which updates/obsoletes/contradicts this, don't flame me - mail me!) -- +------------------------------------------------+-----------------------+ | I've got a little black book with my poems in, | Martin O'Nions | | I've got a bag with a toothbrush and a comb in,| Logitek Group Support | | When I'm a good dog they sometimes throw me a | martino@logitek.co.uk | | bone in (Roger Waters - The Wall) | 0257 426 644 | +------------------------------------------------+-----------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011121921.AA08826@ucbvax.Berkeley.EDU] <1990111213101900> From: jcurran@SH.CS.NET Newsgroups: comp.protocols.tcp-ip Subject: Re: Cost of Internet access Message-ID: <9011121921.AA08826@ucbvax.Berkeley.EDU> Date: 12 Nov 90 13:10:19 GMT References: <1990Nov11.025310.25098@Solbourne.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Posted: Mon Nov 12 14:10:19 1990 > This sounds like a good idea. But if you are going to do dialup > already, why not just use uucp mail? It is simpler to setup than > arranging slip lines. > > The whole idea of dialup access is good, if it can be done "fast" and > on demand. TCP connection would show the line is still in use, but > how do you work out things like UDP packets? There is no "connection" > data or state associated with them. > > Warner Dialup IP provides a general transport service for mail, ftp, telnet, etc. Many people are using dialup IP with automatic initiation for this reason and it works quite well. Certainly a little care has to be used when setting up mail and DNS [kids, don't try this at home..], but it's worth it for those sites who can't afford the cost of a dedicated circuit. This line of conversation started regarding the high cost of connecting to the Internet; it's important to show there are alternatives to the direct line. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011122007.AA10720@ucbvax.Berkeley.EDU] <1990111214192600> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: dial-up IP questions Message-ID: <9011122007.AA10720@ucbvax.Berkeley.EDU> Date: 12 Nov 90 14:19:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Posted: Mon Nov 12 15:19:26 1990 There were a couple of questions about dial-up IP behavior that I'd like to respond to (by the way, all this stuff was covered in a paper on dial-up IP that Leo Lanzillo and I gave at the 1989 Winter USENIX). Connection set up time: Someone pointed out that many TCPs limit their open timeout to 30 seconds, which means dialing a link has to be done in less than 30 seconds. This is a known problem -- it turns out that you often find that dial-up IP connects the link just as your SYN times out (recall that 30 seconds includes delays before you get to the dial-up gateway, so even a dial-up IP that can connect, in say, 15 seconds, often loses). However Host Requirements now require TCPs to have a much longer timeout, so if your TCP still does 30 seconds, beat up on your vendor. SMTP: There was a question about j-random host trying to SMTP to your system which is behind a dial-up IP link. If the link can be brought up at any time, then assuming your TCP is HRRFC conformant, no problem. However, some sites limit the times their link can be brought up to minimize phone costs (e.g. only at evening and weekend rates). In these situations, people use MX records to forward their mail to a particular machine, and then have a program that tickles the remote mailer to deliver to them. (This is NOT done using TURN; rather the final destination machine telnets to a special port, which causes the SMTP daemon to start up -- this avoids the security problems of TURN). Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111214200000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 06:37:45 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id aa21990; 12 Nov 90 9:30 EST Date: Mon, 12 Nov 90 14:20 GMT From: Bob Stine <0004219666@mcimail.com> To: tcp-ip Subject: Re: SNMP Packages via Anonymous ftp? Message-Id: <32901112142023/0004219666NB2EM@mcimail.com> >I'd love to see RFC 1147 - is there a site I can send mail to to get >a copy via their info-server? Yes. Send an empty email message to service@nic.ddn.mil. For the ASCII version of the RFC, use SUBJECT line RFC 1147 For the postscript version (which I recommend, if you have a postscript printer), use SUBJECT line RFC 1147.PS For more info on the NIC document server, use SUBJECT line HELP Regards, Bob Stine Applied Cybernetics, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Nov12.114605.10725@pbs.org] <1990111216460400> From: sdroppers@pbs.org Newsgroups: comp.unix.ultrix,comp.protocols.tcp-ip,comp.sys.pyramid Subject: SL/IP on Ultrix 4.0 or Pyramid Message-ID: <1990Nov12.114605.10725@pbs.org> Date: 12 Nov 90 16:46:04 GMT Reply-To: pbs.org!npri6!jhagen Organization: PBS:Public Broadcasting Service, Alexandria, VA Lines: 13 Posted: Mon Nov 12 17:46:04 1990 I have SL/IP software for genric VAX and SUN. Does anyone have any experience puttin SL/IP on RISC machines? I am looking for pointers especially for DEC 5400 (Ultrix 4.0) and AT&T 7020 (Pyramid OSx). Will what I have work in this environment? Jarom ------------------------------------------------------------------------------- *Not paid for and/or endorsed by National Political Resources Incorporated. (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jhagen) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CMM.0.88.658430295.ingea@svarte.ifi.uio.no] <1990111217181500> From: ingea@IFI.UIO.NO (Inge Arnesen) Newsgroups: comp.protocols.tcp-ip Subject: LPD and RFC 1179 Message-ID: Date: 12 Nov 90 17:18:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 34 Posted: Mon Nov 12 18:18:15 1990 While going through RFC 1179 (thanks to L.J. McLaughlin for writing it!), I've stumbled across a few points I need some help with: 1) In section 3.1 in RFC1179, it says: "The source port must be in the range 721 to 731 inclusive." I've looked through a two different implementations, and I cannot find any reference to specific client port numbers, expect that they must be in the reserved range (below 1024). RFC1060 does not list these port numbers as reserved for LPD client. Is this number range reserved for LPD ? Are checks made by different LPD's to verify client source number? 2) In section 6.3 in 1179, it says: "The total number of bytes in the stream may be sent as the first operand, otherwise the field should be cleared to 0" Note: The receive data file command. Once again I've looked at source code and done some testing, and I cannot understand the perpose of setting the "number of bytes" field to zero. If this this field is cleared, the LPD server part assumes that the data file has a zero length (as far as I can see from the BSD source and some other implementations). Are there implementations around that allow the client side to specify zero data file length to mean unknown length ? In that case, how does the server side know when the whole data file has been transfered ? If the file is pure ASCII it poses no problem, since the terminating NULL char can act as an EOF marker, but what about non-ASCII files ? Inge (BoB) { ingea@ifi.uio.no } ========================================================================= == Inge Arnesen, University of Oslo, Norway. == == == ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Nov12.224405.10835@grian.cps.altadena.ca.us] <1990111222440500> From: steve@grian.cps.altadena.ca.us (Steve Mitchell) Newsgroups: comp.dcom.lans,comp.windows.ms,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: need to synchronize PC to Sun over TCP/IP Message-ID: <1990Nov12.224405.10835@grian.cps.altadena.ca.us> Date: 12 Nov 90 22:44:05 GMT Organization: College Park Software, Altadena, CA Lines: 20 Posted: Mon Nov 12 23:44:05 1990 I'm running a PClone/386 diskless using Excelan TCP/IP and Beame & Whiteside NFS over an Ethernet. Quite often when attempting to save a file my word processor complains that someone has modified a file it is editing. I've been told by Carl Beame (our NFS vendor) the problem is that the clocks on the PClone and the Sun fileserver are out of synch. Since both clocks drift, and at different rates, I'm looking for a program which can be run by the PClone at boot to query the Sun for its time, and then set the local clock accordingly. Is there such a program? Is there a public domain version? If so, where can it be found? Please email any replies, as I can't cover all these groups very often. Thanks to all for your help. -- - Steve Mitchell steve@cps.altadena.ca.us grian!steve@elroy.jpl.nasa.gov ames!elroy!grian!steve "God is licht, an in him there is nae mirkness ava." -- 1 John 1:5 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111300223700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 04:58:07 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15102; Tue, 13 Nov 90 04:46:26 -0800 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 Nov 90 00:22:37 GMT From: logicon.com!tots!tep@nosc.mil (Tom Perrine) Organization: Logicon, Inc., San Diego, California Subject: Re: humanitarian request Message-Id: <197@tots.UUCP> References: <26685.273c1836@kuhub.cc.ukans.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <26685.273c1836@kuhub.cc.ukans.edu> decwrl.dec.com!sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino@ucsd.edu writes: > > >Dear NetFolks, > >We would appreciate your responding to the request of Craig Shergold who >is a seven year old boy with an inoperable tumor on his brain. > >He has not been given a very long time to live and it is Craig's ambition >to enter the Guiness Book of World Records for the largest number of get >well cards ever received by an individual. > >---------------------------------------------------------------------- > Jack Petrino (DRAGON) int: PETRINO@KUHUB.CC.UKANS.EDU > Systems Testing bit: PETRINO@UKANVAX > University of Kansas vox: (913)864-0443 > Computer Center fax: (913)864-0485 >----------------------------------------------------------------------- > >PS - I apologize for the possible redundancy of posting this net-wide. I > hope everyone can understand the necessity/urgency of the situation. NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! This situation is not urgent. This drivel has been circulating for over a year. Craig Shergold, the Guiness Book of World Records, the hospital, the post office and many others have been pleading for people to STOP sending cards. If I see this one more time, I'm going to devote the rest of my life to developing a /dev/cattleprod that works through a network connection. However, there is a FAX number :-) The *only* reason I am posting at all is to try to convince people to remove this dreck from any and all computer storage media. A blowtorch might be appropriate. PLEASE DO NOT PASS THIS ANY FURTHER! Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: sun!suntan!tots!tep Tactical and Training Systems Division | San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111300452900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 12 Nov 90 18:01:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01153; Mon, 12 Nov 90 17:49:03 -0800 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 Nov 90 00:45:29 GMT From: apple.com!fair@apple.com (Erik E. Fair) Organization: Apple Computer Inc, Cupertino, CA Subject: Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET Message-Id: <46523@apple.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am in the market for a device that will do two things: 1. Accept X.25 calls and then allow outbound connections to TELNET servers on an Internet. 2. Accept inbound TCP connections, and then allow outbound X.25 calls to destinations on an X.25 network. In effect, I want a protocol coverter for remote login protocols. It would also be nice to be able to restrict who can use this network resource through some kind of access control and/or password mechanism. I'd like the TCP implementation to behave well on the Internet, although the majority of time it will be used for local ethernet connections. I'd like the X.25 implementation to be as completely configurable as possible, given the rather wide variations in X.25 service providers in the U.S. I have two promising candidates so far: the cisco Systems Protocol Converter the Datability Vista VCP-1000 This posting is to request information from the assembled multitudes of the network: 1. If any of you have purchased either or both of the above named devices, I'd love to hear accolades, curses, etc. relating to your experiences with them. 2. Who have I missed? Are there other products which might fill my need in this area? Thanks for your time & trouble, Erik E. Fair apple!fair fair@apple.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111306035700> Received: from ftp.com by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 11:22:48 PST Received: from mrf.raspberry.ftp.com by ftp.com via PCMAIL with DMSP id AA19094; Tue, 13 Nov 90 14:23:57 -0500 Date: Tue, 13 Nov 90 14:23:57 -0500 Message-Id: <9011131923.AA19094@ftp.com> To: sdcc6!jclark@ucsd.edu (John Clark) Subject: Re: ETHERNET Packet TYPES From: mrf@ftp.com Reply-To: support@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: mrf@ftp.com Repository: babyoil.ftp.com Originating-Client: raspberry.ftp.com From: sdcc6!jclark@ucsd.edu (John Clark) Organization: University of California, San Diego Subject: ETHERNET Packet TYPES I need to know where to find the registered ethernet types which can occur in the ethernet packet type field. The standard '/usr/include/..." type files have what the local unix machine is capable of understanding but leave no clue as to what else one may expect when one is monitoring raw packets from the net. John Clark jclark@ucsd.edu This information can be found in RFC 1060 (Assigned Numbers). This RFC (and others) is available for anonymous FTP from the NIC (at nic.ddn.mil). Margaret Forsythe Technical Support FTP Software, Inc. (617) 246-0900 FAX: (617) 245-7943 E-mail: mrf@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111309594800> Received: from hub.eng.wayne.edu by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 11:56:03 PST Received: from alpha.eng.wayne.edu. by hub.eng.wayne.edu (4.1/SMI-4.2) id AA12057; Tue, 13 Nov 90 14:55:14 EST Received: by alpha.eng.wayne.edu. (4.0/SMI-4.0) id AA01379; Tue, 13 Nov 90 14:59:48 EST Date: Tue, 13 Nov 90 14:59:48 EST From: cliff@alpha.eng.wayne.edu (Cliff Stallings) Message-Id: <9011131959.AA01379@alpha.eng.wayne.edu.> To: tcp-ip@NIC.DDN.MIL Subject: removal from the users group Cc: cliff@wsu-eng.eng.wayne.edu Please remove me from this users group... Thank you... Cliff Stallings cliff@wsu-eng.eng.wayne.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Nov13.134658.14120@ifi.uio.no] <1990111313465800> From: hvoslef@ifi.uio.no (Hvoslef) Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc Subject: PD NFS client for read/write of remote files ? Keywords: NFS client only needed Message-ID: <1990Nov13.134658.14120@ifi.uio.no> Date: 13 Nov 90 13:46:58 GMT Organization: Dept. of Informatics, University in Oslo, Norway Lines: 12 Posted: Tue Nov 13 14:46:58 1990 Nntp-Posting-Host: kyrre.ifi.uio.no Originator: hvoslef@kyrre.ifi.uio.no I am looking for a public domain source doing the NFS client side. I only need a very stripped version doing reads/writes of remote files. The size of the resulting binary is important, as I have limited RAM. I am also using a hand-crafted real-time monitor which happens to have a few unix-like kernel calls. Do I have to jump on the NFS license wagon or can anybody help me ? ------------------------- hvoslef@ifi.uio.no ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111314351900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 08:28:25 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19756; Tue, 13 Nov 90 08:26:52 -0800 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 Nov 90 14:35:19 GMT From: snorkelwacker!ira.uka.de!fauern!tumuc!guug!ecrc!dave@bloom-beacon.mit.edu (Dave Morton) Organization: ecrc Subject: Re: Cost of Internet access Message-Id: <2026@ecrc.de> References: , <9011101731.AA20352@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011101731.AA20352@ucbvax.Berkeley.EDU>, jcurran@SH.CS.NET writes: |>Regarding dialup IP services, Peter da Silva writes: |>> Um, won't this cause problems with SMTP? What does SMTP do when the |>> destination is only available for brief periods, or should you handle |>> your mail via an MX? |> |>As long your implementation automatically brings up the circuit when there |>is a packet queued (at either end), the application layer can not distinguish |>dialup IP services from dedicated. SMTP simply gets a long delay on the |>initial connection. |> |>/John This is exactly how tund appears to work on X.25 links. If you're on a fixed cost X.25 net like the WiN then that's ok, if you're on a fee per packet X.25 net then you might end up paying even though the other site has established the call. Tund, for example, re-establishes it from your side. We ran into this situation recently - it can be expensive.... Dave Morton, European Computer Research Centre Tel. + (49) 89-92699-139 Arabellastr 17, 8000 Munich 81. Germany. Fax. + (49) 89-92699-170 E-mail: dave@ecrc.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111314462100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 12:46:29 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02158; Tue, 13 Nov 90 12:21:33 -0800 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 Nov 90 14:46:21 GMT From: encore!mperlman@husc6.harvard.edu (Mark Perlman) Organization: Independent Consultant Subject: Re: Multiple subnets on same cable Message-Id: <13241@encore.Encore.COM> References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article martino@logitek.co.uk (Martin O'Nions) writes: >freiss@nixdorf.de (the hacker) writes: > > >>This might be a silly question, but it's been worrying me for some time. >>What happens if different IP subnets live on the same ethernet cable? > >>I'm worried about excessive ICMP traffic (ICMP net_redirect packets); >>I see some SGI workstations here react to some packets from a >>different subnet with this ICMP message. > >>Could somebody tell me if this is a problem or what other >>problems I haven't even thought of might arise? >>Pointers to books, RFCs etc. on this subject are also welcome. I may have missed some of the previous posting in response, however, I'll put in my 2 cents for free. You can "turn off" subnetting by specifying a metric of 0 (zero) when you use the route command. E.G.: route add 0 You also need to consider broadcasting addresses on this multi-subnetted physical network. A broadcast address of xx.xx.xx.255 says "all hosts on subnet xx.xx.xx.0", whereas, a broadcast address of 255.255.255.255 says "all hosts an my local network". It requires some forethought on your part to assure a working broadcasts. I would reccommend getting your hands on Charles Hedrick's paper, "Introduction to Administration of an Internet-based Local Network", 3 October 1988. Hope this was useful. +----------------------------------------------------------------------+ | Mark R. Perlman | | Independent Consultant 301-206-2016 | | 14014 Oakpointe Dr. mperlman@encore.com | | Laurel, MD 20707 uunet!gould!mperlman | +----------------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111316323200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 10:14:55 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22659; Tue, 13 Nov 90 10:10:45 -0800 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 Nov 90 16:32:32 GMT From: mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net (Daniel Huber) Organization: Ascom Autelca AG, CH-3073 Guemligen Switzerland Subject: Re: How do you use Dial-up SLIP? Message-Id: <1113@aut.autelca.ascom.ch> References: , Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >All you need is a little program to detect the need for an outgoing >connection, dial up and establish the connection, and then drop it >when there is not traffic for some period. It's not hard (I've done >it). If I "ping" the machine on the other side of the outgoing connection (connection not yet established), does this work too? -- Daniel Huber Tel. +41 31 52 96 64 Ascom Autelca Fax. +41 31 52 53 01 CH-3073 Guemligen email: dhuber@autelca.ascom.ch Switzerland uucp: uunet!mcsun!chx400!hslrswi!aut!dhuber ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111316580700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 10:44:11 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA23232; Tue, 13 Nov 90 10:34:30 -0800 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 Nov 90 16:58:07 GMT From: unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU (Ruth Milner) Organization: National Radio Astronomy Observatory, Socorro NM Subject: SLIP/streams problems Message-Id: <1990Nov13.165807.15258@nmt.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have a Sun 3/260, running 4.0.3, which runs SLIP and has been running into problems with streams allocation. Usually this just consists of SLIP making "slip_output can't allocb" complaints, but today it spilled over into general terminal usage. The root of the problem is that we are running out of the larger streams buffers (excuse me if I haven't got the terminology correct; I don't know very much about streams internals). The number of NBLK512/1024/ 2048/4096 has already been increased once from the pathetically low values they had originally, but it made no noticeable difference to SLIP. Today we started seeing problems with the terminal driver being unable to allocate streams buffers. "cat" was unable to output files over about 1K directly to the screen (no problem with redirection to disk or any other command). The output from "netstat -m" is as follows: 372/448 mbufs in use: 19 mbufs allocated to data 12 mbufs allocated to packet headers 103 mbufs allocated to socket structures 137 mbufs allocated to protocol control blocks 94 mbufs allocated to routing table entries 2 mbufs allocated to socket names and addresses 5 mbufs allocated to interface addresses 0/32 mapped pages in use 88 Kbytes allocated to network (52% in use) 0 requests for memory denied streams allocation: cumulative allocation current maximum total failures streams 22 23 157 0 queues 80 84 621 0 mblks 140 176 215604 0 total dblks 140 176 215604 90715 size 4 dblks 0 20 78588 0 size 16 dblks 3 22 32774 0 size 64 dblks 0 34 98291 0 size 128 dblks 52 55 2850 0 size 256 dblks 1 11 2089 0 size 512 dblks 28 28 267 11794 size 1024 dblks 28 28 689 45369 size 2048 dblks 28 28 56 33530 size 4096 dblks 0 0 0 22 As you can see, the problem is definitely in the streams area, not with memory buffers or anything like that. Normally when this problem shows up, the number of allocation failures is an order of magnitude lower than this. So far all we have been able to do to cure this problem is reboot. Our version of SLIP is up-to-date. Does anyone have any idea what's going on, and/or how to fix it? It looks to me as though SLIP (or something, but it's the likeliest possibility) is allocating buffers and not letting go of them properly afterwards. Thank you very much. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM rmilner@zia.aoc.nrao.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111318083300> Received: from bells.cs.ucl.ac.uk by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 10:09:19 PST Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with SMTP inbound id <26750-0@bells.cs.ucl.ac.uk>; Tue, 13 Nov 1990 18:08:34 +0000 To: tcp-ip@nic.ddn.mil Subject: refile +archive Date: Tue, 13 Nov 90 18:08:33 +0000 From: Jon Crowcroft does anyone know of a third level to the mh mail interface program - refileing and folder +'ing to an archive - this would be jolly handy plus why, oh pray, has no-one done a level up from the folders folder +../bboards or some such...so we get (x)mh integrated support in a uniform way for e-mail & bboards... answers in a P2 envelope...:-) btw - is there a good bboard for discusion of mailsystem&bboard UA programs thanks jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111318160000> Received: from MVST.OAC.UCLA.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 02:16:47 PST Received: from UCLAMVS.BITNET by MVST.OAC.UCLA.EDU (IBM MVS SMTP R1.0.1) with BSMTP id 4993; Wed, 14 Nov 90 02:16:36 PDT Date: Wed, 14 Nov 90 02:16 PST To: tcp-ip@NIC.DDN.MIL From: Denis DeLaRoca (213) 825-4580 Subject: Re: CUTCP/CUTE This question is more appropiately placed in the cutcp@omnigate.clarkson.edu discussion list. Try setting splay=no in your config.tel file. Splay compression is a feature that Brad Clements, cutcp's author, was playing with in connection with Header Compression (the VJC parm which must also be set to no). -- Denis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111319105400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 11:49:01 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00636; Tue, 13 Nov 90 11:32:26 -0800 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 Nov 90 19:10:54 GMT From: wuccrc!dworkin!christos@louie.udel.edu (Chris Papadopoulos) Organization: Washington University, St Louis MO Subject: Looking for probes for TCP/IP Message-Id: <2081@olympus.wustl.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Let me first introduce myself. I am Christos Papadopoulos, a graduate student at Washington Univ working with Guru Parulkar. I am interested in remote visualization. I plan to implement an application which we think has characteristics typical of visualization applications and distribute it across our campus network using TCP/IP. Then tap in the protocols at different levels and take various measurements to identify where the bottlenecks are (if any). The application we picked is "Display of cell trajectories in 3D using Optical Sectioning Microscopy". This uses an optical microscope equipped with a CCD camera to collect images of planes in an organism. The big advantage of this method is that there is no physical slicing involved, thus the organism does not have to be killed. The CCD camera has variable pixel resolution of up to 1000 by 1000, at 4096 graylevels. The volumetric data will be in the range of 10-20 MBytes per image. To trace the trajectories of cells several images need to be collected to construct a short animation. There is a number of steps that need to be performed before the data can be rendered. These include elimination of noise due to the point spread function of the lens, edge enhancement, image segmentation and various geometric transformations. After distributing the application we would like to monitor the communication and take measurements on protocol overhead. The communication model we think may be appropriate is as follows: TCPq Networkq Networkq TCPq -------- ----| ----| ----| ----| ---------- |Sender|-----> |||-----> |||----------> |||-----> |||----->|Receiver| -------- ----| ----| Ethernet ----| ----| ---------- The measurements we would like to take include: (i) Dynamic queue length at the various queues (ii) Various delays a packet experiences The question I want to ask is the following: Are there probe and measurement utility programs which will allow us to take these measurements without any kernel modifications? Thanks in advance, Christos. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111319203200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 15:31:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07203; Tue, 13 Nov 90 15:20:55 -0800 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 Nov 90 19:20:32 GMT From: swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!news.cs.indiana.edu!news!german@ucsd.edu (Chad W. German) Organization: Univ. of Notre Dame Subject: CUTCP/CUTE Message-Id: <698@news.nd.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil is release D. I'm using the software with Netware 286. I unarchived it with the Zoo utilities and configured the config.tel file. When I fire up the program it recognizes by card and puts me in server mode. I have no problems with the software BUT I get a message: Server mode, press ESC to exit or Alt-A to begin a session Configfile: Warning, this version not compiled with Splay Compression Support Can anyone advise me on this error message?????? Thanks in advance for all info. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111320562300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 13:15:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03359; Tue, 13 Nov 90 13:05:34 -0800 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 Nov 90 20:56:23 GMT From: LA.TIS.COM!gds@apple.com (Greg Skinner) Organization: Trusted Information Systems, Inc., La-La Land Subject: ftp between IBM's secure xenix and SunOS 4.1 Message-Id: <9011132056.AA04698@la.tis.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil If anyone out there has experienced any kind of trouble with bogus IP options issued by IBM's secure xenix during ftp's with SunOS 4.1 machines (or for that matter, any other machines) please let me know by email. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111323360800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 17:16:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10297; Tue, 13 Nov 90 17:07:26 -0800 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 Nov 90 23:36:08 GMT From: usc!coh!rzelman@ucsd.edu (R. Zelman) Organization: City of Hope Nat'l Med. Ctr., Duarte, CA Subject: Macintosh & TCP/IP Message-Id: <255@coh.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Does anyone know of good TCP/IP software for the MAC? In our lab we have a number of online instruments connected to various systems (DECstation 2100's, SUN Sparc station, Compaq 386) that we wish to connect to a Macintosh 2 via ethernet. The Dec's are running ULTRIX. The Mac will have a CD Rom read/write optical drive to store the data from the instruments. What would be a suitable ethernet board to install in the Mac and what is the best software to purchase? Also, any ideas as to software and hardware to connect the Compaq 386? Please email to me direct. Thanks in advance. Ron Zelman Internet: rzelman%coh@usc.edu City of Hope Duarte, CA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111401441400> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 09:44:55 PST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Wed, 14 Nov 90 09:44:56 -0800 Date: Wed, 14 Nov 90 09:44:14 PST From: postel@venera.isi.edu Posted-Date: Wed, 14 Nov 90 09:44:14 PST Message-Id: <9011141744.AA14899@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Wed, 14 Nov 90 09:44:14 PST To: LA.TIS.COM!gds@apple.com, tcp-ip@nic.ddn.mil Subject: Re: ftp between IBM's secure xenix and SunOS 4.1 Greg: Maybe you mean Datagrams with protocol type = 91 (in the field where TCP = 6)? This is called LARP from Locus computing. Everyone should feel free to give Locus a very hard time about not documenting this in an RFC. --jon. From tcp-ip-RELAY@NIC.DDN.MIL Wed Nov 14 03:38:31 1990 Date: 13 Nov 90 20:56:23 GMT From: LA.TIS.COM!gds@apple.com (Greg Skinner) Subject: ftp between IBM's secure xenix and SunOS 4.1 Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil If anyone out there has experienced any kind of trouble with bogus IP options issued by IBM's secure xenix during ftp's with SunOS 4.1 machines (or for that matter, any other machines) please let me know by email. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111402005200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 07:16:57 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25552; Wed, 14 Nov 90 07:06:13 -0800 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 Nov 90 02:00:52 GMT From: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Organization: Mathematics, Carnegie Mellon, Pittsburgh, PA Subject: IP Router-Where to Start? Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm thinking about implementing an IP router, but I have no idea where to start. I've browsed through the RFC index and a few RFC's themselves, but there doesn't appear to be anything directly related to routers. I'm looking basically for 4 things: 1) Related RFC's 2) Books and other text that might help 3) Public Domain implementations, hopefully source, to test mine with 4) Advice Thanks. -John Kalucki ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111402342500> Received: from foralie.ics.Hawaii.Edu by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 14:35:53 PST Received: by foralie.ics.Hawaii.Edu id 2336; Wed, 14 Nov 90 12:34:33 HST From: Torben Nielsen To: tcp-ip@nic.ddn.mil Subject: PPP software.... Message-Id: <90Nov14.123433hst.2336@foralie.ics.Hawaii.Edu> Date: Wed, 14 Nov 90 12:34:25 HST My apologies in case I'm abusing this list. But in response to a recent note about a version of PPP we developed, I got so many requests for it that I'm not about to respond individually. I've made our version of PPP available for anonymous FTP. It's available on uhccux.uhcc.Hawaii.Edu in directory misc/ppp.tar.Z It's freely available to anyone who wants it. Subject to the requirement that you send bug reports/fixes back. It currently depends on Sun's INR software for a lower layer synch driver for the 85C30 which Sun uses for on-board serial ports. Roll your own if you like. We have one of our own too, but it's in a pretty poor state. Torben ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111402425100> Received: from george.arc.nasa.gov by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 16:31:06 PST Received: Wed, 14 Nov 90 16:02:51 -0800 by george.arc.nasa.gov (5.64+/1.2) Date: Wed, 14 Nov 90 16:02:51 -0800 From: Brian Gray RC Message-Id: <9011150002.AA22047@george.arc.nasa.gov> To: tcp-ip@nic.ddn.mil Subject: mailing list Please remove me from this mailing list: Brian Gray gray@yorktown.arc.nasa.gov NASA Ames Research Center 415-604-5013 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111403505700> Received: from mbunix.mitre.org by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 05:52:03 PST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: from localhost.mitre.org by ulana.mitre.org (4.1/SMI-4.0-MHS-6.0) id AA02327; Wed, 14 Nov 90 08:50:59 EST Message-Id: <9011141350.AA02327@ulana.mitre.org> To: LA.TIS.COM!gds@apple.com (Greg Skinner) Cc: tcp-ip@nic.ddn.mil, dtm@mbunix.mitre.org Subject: Re: ftp between IBM's secure xenix and SunOS 4.1 In-Reply-To: Your message of 13 Nov 90 20:56:23 +0000. Date: Wed, 14 Nov 90 08:50:57 EST From: David T. Miller >If anyone out there has experienced any kind of trouble with bogus IP >options issued by IBM's secure xenix during ftp's with SunOS 4.1 >machines (or for that matter, any other machines) please let me know >by email. > >--gregbo We discovered that our Sun's (SunOS 4.1) crash instantly when attempting an FTP to a secure xenix host. The secure xenix sends fixed length IP headers - 32 octets - 12 bytes of padded zeroes with no options. I have no idea why, but it causes the Suns to immediately reboot, and as the Sun is trying to reboot, the xenix machine begins retransmitting its last packet causing the Sun to begin rebooting again. This continues until you reboot the xenix machine. We contacted Sun and have received to patches which corrected the problem on the Sun end. I'm still not sure about the xenix 32 octet IP headers. The patches from Sun are #s: 100077-02 and 100149-01. Sun will mail these out to you if you report the problem. Our contact was Arlene at Sun Support (415) 336-6034. Dave Miller dtm@mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111403542900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 21:01:33 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15851; Tue, 13 Nov 90 20:54:27 -0800 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 Nov 90 03:54:29 GMT From: cert!netnews.upenn.edu!scotty.dccs.upenn.edu!kehoe@lll-winken.llnl.gov (Brendan Kehoe) Organization: University of Pennsylvania Subject: SLIP between a Sun & SCO Message-Id: <32821@netnews.upenn.edu> References: <9011131923.AA19094@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi there .. a friend of mine & I have been trying to devise a way for him to use SLIP to telnet over to my machine over a V.32 modem. I've got the stuff for my Sun (SS1 under SunOS 4.1). What we need to know is what it would take on his end (SCO Xenix on a 386) to make this happen. Would he have to fork out the $$ to get the TCP/IP implementation for SCO? (I'm not a Xenix expert; Suns are my bag.) Thanks! Brendan Kehoe | brendan@cs.widener.edu [ It's here, but it won't resolve yet ] For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu "The latest polls indicate you're in danger of losing touch with the common man." "Oh DEAR ... heaven forfend!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111404585500> Received: from SH.CS.NET by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 10:27:41 PST Received: by SH.CS.NET id aa10882; 14 Nov 90 13:28 EST To: "Erik E. Fair" cc: tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET Subject: Re: Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET In-reply-to: Your message of 13 Nov 90 00:45:29 +0000. <46523@apple.Apple.COM> Date: Wed, 14 Nov 90 13:18:55 -0500 From: George Williams In response to this portion of your query: ........ the cisco Systems Protocol Converter the Datability Vista VCP-1000 This posting is to request information from the assembled multitudes of the network: 1. If any of you have purchased either or both of the above named devices, I'd love to hear accolades, curses, etc. relating to your experiences with them. 2. Who have I missed? Are there other products which might fill my need in this area? >>> I believe xni-list@cs.net is the mailing list for additional info. >>> () Third party (b)router people have jumped on the bandwagon with board >>> and standalone router solutions to IP/x.25 that are based on RFC877. >>> >>> - Sun is one you didn't mention above. (RFC877 compliant) >>> >>> - Cisco is another as noted. (RFC877 ditto ) >>> () Cursory research I did in this area regarding interoperabilty between >>> cisco and the SUNLINK product resulted in following input (from cisco) >>> and observations to date: >>> The above information left >>> one to ask: 1) Is your IP over X.25 based on this RFC (877)? > Yes. 2) Will cisco routers talk to this SUN product and if so what has been the user feedback, if any? > Yes; we have customers doing this. Indeed, we will talk to any > machine that is RFC877 compliant. > The feedback is "rather quiet" because it generally works > (unfortunately, feedback is often only received when there > is a problem!) 3) Do you even recommend trying this or is it known there is no compatibility between the two router products ? > Yes -- you should be able to do this. --Joel >>> Thanks to jpbion@cisco.com for above ! >>> () Marketing people from cisco however do not take an official "supported" >>> position for the above. They do say they will talk to "anything" that is >>> DDN X25 compliant,however. >>> () CSNET work is in progress to bring up a SUN to CISCO connection of two ( international and domestic ) PDNs. It appears to be working with most of the problems technical administration ( being worked on ) of VC utilitazion. >>> BTW, there is a known problem with the sunlink product not clearing called "hung" VC's. This I think is being worked on. Good Luck, George Williams Technical Staff CSNET CIC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111406010100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 13 Nov 90 22:01:43 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17094; Tue, 13 Nov 90 21:51:34 -0800 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 Nov 90 06:01:01 GMT From: pacbell.com!tandem!mytardis!narayan@ucsd.edu (Narayan Mohanram) Subject: Any RFC for IP over ISDN? Message-Id: <122@mytardis.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for info if there is any RFC for IP over ISDN. If there is not one, are there any implementations out there?? Thanks in advance for info. Narayan Mohanaram -- E-Mail: narayan@mram.sunnyvale.ca.us ************************************ Phone: 408-738-4165 * Lifes a reach, then you Jibe * USnail: 908 W. Olive, Sunnyvale, CA 94086 ************************************ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111409223200> Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 11:31:05 PST Received: from masscomp.westford.ccur.com by RELAY.CS.NET id aa24290; 14 Nov 90 14:30 EST Received: from nexus by masscomp.westford.ccur.com via TCP/IP with SMTP id aa07213; 14 Nov 90 14:28 EST Received: from fmycroft by nexus.westford.ccur.com via TCP/IP with SMTP (local) id aa17458; 14 Nov 90 14:22 EST To: tcp-ip@NIC.DDN.MIL Subject: Mail list madness!!!!! Date: Wed, 14 Nov 90 14:22:32 EST From: David Rankin Message-ID: <9011141422.aa17458@nexus.westford.ccur.com> Hello, After being on the list for over a year, I have seen many requests from people wanting to get off of the mailing list. Usually these request are met with a less than constructive reply, along the lines of "Don't clutter up the mailing list with silly mail!". May I suggest that someone please post the procedure so that these poor souls (and the rest of us) can have some peace? David ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011141547.AA26553@ucbvax.Berkeley.EDU] <1990111410160000> From: CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca 825-4580, 213) Newsgroups: comp.protocols.tcp-ip Subject: Re: CUTCP/CUTE Message-ID: <9011141547.AA26553@ucbvax.Berkeley.EDU> Date: 14 Nov 90 10:16:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 This question is more appropiately placed in the cutcp@omnigate.clarkson.edu discussion list. Try setting splay=no in your config.tel file. Splay compression is a feature that Brad Clements, cutcp's author, was playing with in connection with Header Compression (the VJC parm which must also be set to no). -- Denis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1441@ria.ccs.uwo.ca] <1990111411095600> From: lrb@rrivax.rri.uwo.ca (Lance R. Bailey) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Re: MultiLan vs Wollongong for VAX/VMS ????? Message-ID: <1441@ria.ccs.uwo.ca> Date: 14 Nov 90 11:09:56 GMT References: <9611.2735a48f@ul.ie> Sender: news@ria.ccs.uwo.ca Reply-To: lrb@rrivax.rri.uwo.ca Followup-To: comp.protocols.tcp-ip Organization: Robarts Research Institute -- London Canada Earth Lines: 43 Posted: Wed Nov 14 12:09:56 1990 News-Software: VAX/VMS VNEWS 1.3-4 In article <9611.2735a48f@ul.ie>, bourkej@ul.ie writes... >Can anyone compare the relative merits of TGV MultiLan and the Wollongong >offering for VMX/VMS ? >I'm told MultiLan is the bees knees, but does Wollongong live up to it ? i use wollongong, and have tested multinet, i did not move to multinet because of a certain functionality i needed. when i mailed to ken adelman about this, he had a fix within a day. 1) for functionality i think you will have people argue both sides. 2) most of the net software i see is based on multinet, but more and more are getting wollongong ports (like the news reader i use) 3) for support, well.... the above example shows multinet, email a complaint and they act immediatly. i have complained about wollongong support before and the last time i did so, california phoned me to discuss the matter. I later got some EXCELLENT support in installing the secure ftp product, _however_ of the THREE modification requests i have sent in on their product, i received: three electronic acknowledgements of receipt only two paper acknowledgements of receipt "acknowledgement of receipt" is nothing more than "we got it, when it is resolved one way or the other, you will hear from us. bye." now, one of these mod. req. i labelled URGENT with a note that it adversely affects software which we use on top of the ftpd.exe program -- software that is integral to the running of our operation. in the last month i essentially have sat on my hands waiting for the wollongong god to grin upon me. to be fair, wollongong _does_ support many more platforms, so their resource people are stretched across many platforms. Lance R. Bailey, Systems Manager ================================ box: Robarts Research Institute email: lrb@rri.uwo.ca Clinical Trials Resources Group fax: 519.663.3789 P.O. Box 5015, 100 Perth Dr. vox: 519.663.3787 ext. 4108 London, Canada N6A 5K8 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111414040000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 06:29:20 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id ac04299; 14 Nov 90 9:18 EST Date: Wed, 14 Nov 90 14:04 GMT From: Bob Stine <0004219666@mcimail.com> To: Chris Papadopoulos Cc: tcp-ip Subject: Re: Looking for probes for TCP/IP Message-Id: <14901114140441/0004219666NB4EM@mcimail.com> >... I plan to implement an application which we think has characteristics >typical of visualization applications ...[t]hen tap in the protocols at >different levels and take various measurements to identify where the >bottlenecks are (if any). > ... > The measurements we would like to take include: > (i) Dynamic queue length at the various queues > (ii) Various delays a packet experiences > ... > >Are there probe and measurement utility programs which will allow us >to take these measurements without any kernel modifications? Christos, You might check RFC 1147, "A Network Management Tool Catalog," for a list of several tools. Unfortunately, to the best of my recollection, the only tools capable of monitoring actual queue lengths require some (well-documented) kernel mods. I could be wrong about this. My gut feeling, however, is that getting the queue lengths will require some special instrumentation, which in turn will require kernel mods. At any rate, I recommend that you take a look at the catalog entry describing NETMON and iptrace, developed by Allison Mankin, of MITRE. NETMON is essentially kernel instrumentation for BSD-UNIX. You might conclude that avoiding mods to the kernel is not a hard-and-fast requirement. For background on TCP/IP, I'd also recommend that you read RFC 1122, "Requirements for Internet hosts -- communication layers." - Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1994@tuvie] <1990111417542800> From: chytil@vlsivie.tuwien.ac.at (Chytil Georg) Newsgroups: comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.tcp-ip.domains Subject: bind 4.8.3. installation problems : help appreciated ! Summary: fails in getnetconf() on loopback : adress already used Message-ID: <1994@tuvie> Date: 14 Nov 90 17:54:28 GMT Sender: news@tuvie Followup-To: comp.protocols.tcp-ip Organization: Vienna University of Technology, Dept. of VLSI-Design Lines: 43 Posted: Wed Nov 14 18:54:28 1990 I'm currently in the frustrating process of installing bind 4.8.3 from ucbarpa.berkeley.edu on an Apollo DN3500 running Domain/OS 10.2.0.5, more or less BSD4.3 . After some minor hacks (thanks, Apollonians !) it finally compiled fine, and I'm now stuck in a runtime-problem : When configuring itself through getnetconf() named tries to open a socket on the net-interface (ok) and then on the local-loopback too --- and then fails with an 'Can't assign requested adress' . Sigh. While named's code is very readable as far as the how is concerned, I'm not always sure about the 'why' (Well, this may also be due to my inexperience, but I'm not that daring to admit this ). Why is the check_for_local_loopback situated _after_ the opensocket() in the code ? Why should local loopback interfere with the physical interface ? (Why can't I join the happy and drunk VMS-guys in the pub at 4pm sharp 1/2:-( 1/2;-) ). some debugging-information follows : Upon coming up named announces to syslog : Nov 13 17:11:55 walter named[287]: restarted Nov 13 17:11:55 walter named[287]: bind(dfd 6, 127.0.0.1[53]): Can't assign requested address /usr/tmp/named.run shows : Debug turned ON, Level 1000 Version = named 4.8.3 Wed Nov 7 19:07:03 MST 1990 chytil@vlsivie://vlsivie/users/chytil/named/named.new/named bootfile = /etc/named.boot dqp->dq_addr 128.130.40.5 d_dfd 5 dqp->dq_addr 127.0.0.1 d_dfd 6 point of failure is the call to bind() in opensocket -- should I add REUSE_ADDR (sp?) to socket-options or is this left out with purpose ? Thanx for Your help Georg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011142358.AA11549@ucbvax.Berkeley.EDU] <1990111418185500> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET Message-ID: <9011142358.AA11549@ucbvax.Berkeley.EDU> Date: 14 Nov 90 18:18:55 GMT References: <46523@apple.Apple.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 69 Posted: Wed Nov 14 19:18:55 1990 In response to this portion of your query: ........ the cisco Systems Protocol Converter the Datability Vista VCP-1000 This posting is to request information from the assembled multitudes of the network: 1. If any of you have purchased either or both of the above named devices, I'd love to hear accolades, curses, etc. relating to your experiences with them. 2. Who have I missed? Are there other products which might fill my need in this area? >>> I believe xni-list@cs.net is the mailing list for additional info. >>> () Third party (b)router people have jumped on the bandwagon with board >>> and standalone router solutions to IP/x.25 that are based on RFC877. >>> >>> - Sun is one you didn't mention above. (RFC877 compliant) >>> >>> - Cisco is another as noted. (RFC877 ditto ) >>> () Cursory research I did in this area regarding interoperabilty between >>> cisco and the SUNLINK product resulted in following input (from cisco) >>> and observations to date: >>> The above information left >>> one to ask: 1) Is your IP over X.25 based on this RFC (877)? > Yes. 2) Will cisco routers talk to this SUN product and if so what has been the user feedback, if any? > Yes; we have customers doing this. Indeed, we will talk to any > machine that is RFC877 compliant. > The feedback is "rather quiet" because it generally works > (unfortunately, feedback is often only received when there > is a problem!) 3) Do you even recommend trying this or is it known there is no compatibility between the two router products ? > Yes -- you should be able to do this. --Joel >>> Thanks to jpbion@cisco.com for above ! >>> () Marketing people from cisco however do not take an official "supported" >>> position for the above. They do say they will talk to "anything" that is >>> DDN X25 compliant,however. >>> () CSNET work is in progress to bring up a SUN to CISCO connection of two ( international and domestic ) PDNs. It appears to be working with most of the problems technical administration ( being worked on ) of VC utilitazion. >>> BTW, there is a known problem with the sunlink product not clearing called "hung" VC's. This I think is being worked on. Good Luck, George Williams Technical Staff CSNET CIC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111421003000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 13:40:06 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07364; Wed, 14 Nov 90 13:37:58 -0800 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 Nov 90 21:00:30 GMT From: smb@purdue.edu (Scott M. Ballew) Organization: Department of Computer Science, Purdue University Subject: Re: Why do I need multiple host names for the same host? Message-Id: <12480@medusa.cs.purdue.edu> References: <705@keele.keele.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <705@keele.keele.ac.uk> csd35@seq1.keele.ac.uk (Jonathan Knight) writes: >I have two questions. > >1) When a host on the 192.82.242 network tries to talk to > 'doc' is the packet addressed to 192.42.100.3? If not > is this packet unpacked by doc? If not does this packet > actually get placed on the 192.42.100 network and re-read > by doc? Ok, first it will send it to 192.42.100.3 since this is the only translation for the name doc. Doc will recognize it as its own and process it correctly (it does NOT go back out on the other net). If it were sent out on the other net, it is not guaranteed that doc could read it back in (some ethernet interfaces hear themselves talking, others do not). >2) Is there a way to indicate to each host that doc is local > on their ethernet? We do the following with our gateways: 128.10.2.8 gwen gwen-en 128.10.3.8 gwen gwen-xinu (I have deleted the fully qualified domain names). This seems to keep everyone who does not run DNS (a rapidly shrinking number) happy. I don't know about booting, however, since we generally do not make a file server a gateway. Running a nameserver is probably a better bet but you may have reasons not to do so. Scott Ballew Cypress Network Operations Center Purdue University Department of Computer Sciences ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111421473400> Received: from jessica.stanford.edu by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 11:08:34 PST Received: from LOCALHOST by jessica.stanford.edu (5.59/25-eef) id AA25987; Thu, 15 Nov 90 11:07:35 PDT Message-Id: <9011151907.AA25987@jessica.stanford.edu> To: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Cc: tcp-ip@nic.ddn.mil Subject: Re: IP Router-Where to Start? In-Reply-To: Your message of 14 Nov 90 02:00:52 +0000. Date: Thu, 15 Nov 90 11:07:34 -0800 From: "Philip Almquist" John, > I'm thinking about implementing an IP router, but I have no idea where > to start. I've browsed through the RFC index and a few RFC's themselves, > but there doesn't appear to be anything directly related to routers. > > I'm looking basically for 4 things: > 1) Related RFC's There are a lot of of relevant RFCs. In addition to the router standard (RFC1009) that Jon Postel mentioned, there are several RFCs on the network layer (791, 792, 922, 950, 1112, 1122). And of course there ARP, all of the IP over mumble networks RFCs, routing protocols, SNMP, ... There is also a draft successor to RFC1009 which is available via anonymous FTP from NIC.DDN.MIL. Its name is: internet-drafts:draft-ietf-rreq-iprouters-00.txt > 2) Books and other text that might help Various good books, such as Comer's, provide a reasonably good introduction to TCP/IP. None that I know of teach nearly all of the things you'd need to know to implement a router. > 3) Public Domain implementations, hopefully source, to test mine with PCROUTE, KA9Q, and Berkeley UNIX are all reasonably easy to obtain, though I don't have details for any of them on the tip of my fingers. Additionally, various universities (MIT, CMU, Stanford, and probably others) have developed routers whose code is likely to be available if you can figure out who at those institutions has the authority to give it to you. One caveat, however: most if not all of the above are not fully compliant with RFC1009. > 4) Advice Don't underestimate the effort involved in building a router from scratch. You're talking man-years of effort to build even a minimally reasonable one. Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111422584200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 15:26:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10196; Wed, 14 Nov 90 15:09:42 -0800 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 Nov 90 22:58:42 GMT From: news@apple.com (John Veizades) Organization: Apple Computer, Inc. Subject: Re: Macintosh & TCP/IP Message-Id: <11257@goofy.Apple.COM> References: <255@coh.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil This is a list of applications that run over MacTCP, Apple implementation of the TCP/IP protocols. The list is as complete as I could make it. If anyone has addition to the list please drop me a line. John Veizades... MacTCP Engineering Manager Apple Computer, Inc. ---------------------------- Terminal Emulators and File Transfer Tools SUMac/IP 4.0 - Stanford University NCSA Telnet - University of Illinois tn3270 - Brown University Net/One MacUWS - Ungermann Bass TCP/Connect II - Intercon HyperFTP - Cornell University TGraph - Grafpoint PacerLink - Pacer Software, Inc. Mac Samson - Stanford University Mail Tools POPStack - University of Minnesota MacMH 4.0 - Stanford University BeaverGate - University of Toronto Mews - University of Tasmania GatorMail - Cayman Mail*LInk - StarNine TCP/Connect II - Intercon NetNews - Apple Computer, Inc. MacPost - Lund University, Sweden IMap - Stanford University X Servers MacX - Apple Computer, Inc. eXcedos - White Pines Software Programming Libraries Stanford Streams - Stanford University Sockets - Novell Sockets - University of Toronto MacTCP XCMDS - Apple Computer, Inc. MacWorkstation Tool - University of Michigan Databases Wingz - Informix Oracle Sybase NFS The Wollongong Group InterCon GatorBox - Cayman Gateways (Hardware and Software) GatorBox - Cayman FastPath - Shiva MultiGate - NRC Cornell Ungermann Bass The Wollongong Group MultiGate - Webster Comm Toolbox TCPack - Advanced Software Concepts Pacer's CommToolbox interface Miscellaneous MacNix - List Mathematica - Wolfram Research Inc. SNMP Agent - CMU - Excel based MacTCP API in A/UX - Apple -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111500361300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 19:37:29 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17337; Wed, 14 Nov 90 19:31:48 -0800 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 Nov 90 00:36:13 GMT From: munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!maree@THEORY.TN.CORNELL.EDU (Maree Hegarty) Organization: Computer Science Department, The University of Queensland, Brisbane, Australia Subject: Re: bind 4.8.3. installation problems : help appreciated ! Message-Id: <5700@uqcspe.cs.uq.oz.au> References: <1994@tuvie> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1994@tuvie> chytil@vlsivie.tuwien.ac.at (Chytil Georg) writes: >I'm currently in the frustrating process of installing bind 4.8.3 from >ucbarpa.berkeley.edu on an Apollo DN3500 running Domain/OS 10.2.0.5, more >or less BSD4.3 . Talking about BIND 4.8.3... I haven't seen much discussion about this release since Dave Curry sent an article about 4.8.3 and SunOS 4.1 to sun-nets in early September. I also recall reading somewhere that BIND 4.8.2 wasn't actually official yet:-) Can anyone tell me what's the official release? What's the opinion about BIND4.8.3? What enhancements does it have over 4.8.2? Maree. -- ------------------------------------------------------------------ Maree Hegarty maree@uqcspe.cs.uq.oz.au Computer Science, University of Queensland, 4072, Australia Ph: +61 7 377 4270 Fax: +61 7 371 0783 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111501062200> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 09:07:30 PST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Thu, 15 Nov 90 09:07:29 -0800 Date: Thu, 15 Nov 90 09:06:22 PST From: postel@venera.isi.edu Posted-Date: Thu, 15 Nov 90 09:06:22 PST Message-Id: <9011151706.AA19455@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Thu, 15 Nov 90 09:06:22 PST To: jk3n+@andrew.cmu.edu Subject: Re: IP Router-Where to Start? Cc: tcp-ip@nic.ddn.mil Hi. Start with RFC-1009, and also get involved with the "router requirements working group" of the IETF. --jon. From tcp-ip-RELAY@NIC.DDN.MIL Wed Nov 14 20:53:27 1990 Date: 14 Nov 90 02:00:52 GMT From: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Subject: IP Router-Where to Start? Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm thinking about implementing an IP router, but I have no idea where to start. I've browsed through the RFC index and a few RFC's themselves but there doesn't appear to be anything directly related to routers. I'm looking basically for 4 things: 1) Related RFC's 2) Books and other text that might help 3) Public Domain implementations, hopefully source, to test mine with 4) Advice Thanks. -John Kalucki ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111502491100> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 11:56:02 PST Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA14624; Thu, 15 Nov 90 11:55:50 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA00363; 15 Nov 90 10:49:11 PST (Thu) To: tcp-ip@nic.ddn.mil Subject: Ruby tape from "Oddball Uses of the Internet" at Interop Reply-To: romkey@asylum.sf.ca.us Message-Id: <9011151049.AA00363@asylum.sf.ca.us> Date: 15 Nov 90 10:49:11 PST (Thu) From: romkey@asylum.sf.ca.us (John Romkey) I used a 5 minute clip from a tape called Ruby 2 during the "Oddball Uses of the Internet" panel at Interop (this is the one where the main character, Ruby, stays at a motel of the future full of talking appliances). After the panel several people asked me where to get the tapes, and I couldn't answer. They're published by a company called ZBS Foundation. You can reach them at ZBS Foundation RR #1 Box 1201 Fort Edward, NY 12828 800-662-3345 They have a catalog of their tapes. Sorry that I didn't have this info at the show; I hope this reaches some of the people who wanted to know. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 "Karma means getting caught. The secret to creating karma is getting even without getting caught." - Rodant Kapoor in RUBY 3 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111505585000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 14 Nov 90 23:09:40 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21379; Wed, 14 Nov 90 22:58:20 -0800 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 Nov 90 05:58:50 GMT From: simasd!jadpc!jdeitch@nosc.mil (Jim Deitch) Organization: Network Engineering Technologies Subject: Re: SLIP between a Sun & SCO Message-Id: <1990Nov15.055850.2184@jadpc.cts.com> References: <9011131923.AA19094@ftp.com>, <32821@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <32821@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes: > > Hi there .. a friend of mine & I have been trying to devise a way for >him to use SLIP to telnet over to my machine over a V.32 modem. I've >got the stuff for my Sun (SS1 under SunOS 4.1). What we need to know >is what it would take on his end (SCO Xenix on a 386) to make this >happen. Would he have to fork out the $$ to get the TCP/IP >implementation for SCO? (I'm not a Xenix expert; Suns are my bag.) > Thanks! > > >Brendan Kehoe | brendan@cs.widener.edu [ It's here, but it won't resolve yet ] >For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu > "The latest polls indicate you're in danger of losing touch with the > common man." "Oh DEAR ... heaven forfend!" Not only for the TCP/IP but the Streams stuff as well. -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.nosc.mil UUCP: nosc!jadpc!jdeitch ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111519151900> Received: from omnigate.clarkson.edu by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 21:24:55 PST Received: from sun.soe.clarkson.edu by omnigate.clarkson.edu id aa12578; 16 Nov 90 0:19 EST Received: by sun.soe.clarkson.edu (4.1/SMI-4.0) id AA04010; Fri, 16 Nov 90 00:15:19 EST Date: Fri, 16 Nov 90 00:15:19 EST From: Russ Nelson Message-Id: <9011160515.AA04010@sun.soe.clarkson.edu> To: tcp-ip@NIC.DDN.MIL Subject: At wits end with Xenix <--> SunOS Noninterop Reply-To: "aka NELSON@CLUTX.BITNET" Can anyone give me some hints as solve my problem with Xenix <--> SunOS NONinteroperability? I can always telnet between the two hosts, but when I try to ftp between them, I get big troubles. The transfer never gets more than 100 KB through. BUT, when I use KA9Q as a midpoint (do SunOS to KA9Q to Xenix), it works just fine. So clearly both systems are capable of transferring tens of megabytes over a single TCP connection. They just can't talk to anyone else. Now, I would look at the packets, but trpt says "tcp_debx=0", and the manual claims this is an "other message which should be self explanatory." Ha, programmers are such wags. The really strange part is that the problems aren't seen when transferring data *from* the Xenix system, it's when you try to transfer data *to* the Xenix system. There, I just went away and pushed 1.5 MB from the Xenix to the SunOS, and I can't even get 40 KB from the SunOS to the Xenix. Can someone please tell me what to look at? Oh, and please send me mail, as I normally read this group via news, and news is what's NOT running on the Xenix system. All the news junkies at Clarkson are on my back about it... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111521304500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 14:55:37 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12683; Thu, 15 Nov 90 14:45:10 -0800 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 Nov 90 21:30:45 GMT From: intercon!news@uunet.uu.net (Kurt Baumann) Organization: InterCon Systems Corporation, Herndon, VA Subject: Re: Macintosh & TCP/IP Message-Id: <27430905.6C2C@intercon.com> References: <255@coh.UUCP>, <11257@goofy.Apple.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <11257@goofy.Apple.COM>, veizades@apple.com (John Veizades) writes: > Comm Toolbox > TCPack - Advanced Software Concepts > Pacer's CommToolbox interface Gack. John, you missed our tool here. :-) InterCon has a tool as well, that allows both Telnet negotiation and raw TCP, and is much smaller than TCPack, I don't know about Pacer's, I haven't seen it. -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111600560600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 15 Nov 90 20:08:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20822; Thu, 15 Nov 90 20:02:19 -0800 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 Nov 90 00:56:06 GMT From: comp.vuw.ac.nz!badger!mark@uunet.uu.net (Mark Wright) Organization: Department of Survey and Land Information, New Zealand Subject: IP address assignment at boot time - for PCs Message-Id: <1990Nov16.005606.4679@dosli.govt.nz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have a network of diskless PCs that boot from a server running novell. On the same ethernet we have a tcp-ip network of unix workstations. I am currently in the process of installing NCSA telnet over the Clarkson packet drivers on these PCs. I want the PCs to get their IP address from a server when they boot. I would like the addresses to be assigned by the server as they are needed - e.g. a PC may not always get the same IP address, rather it is allocated from a "pool" of addresses upon request. I seem to recall reading of software to do this - can anyone point me in the right direction? What are the drawbacks of this approach? We have more PCs then I would like to configure RARP to handle, so I think it IS preferable. If I have to use RARP, can ultrix 3.1 ARP handle RARP requests - I can't find any reference to it in TFM. All pointers gratefully received. -- Mark Wright. Dept. of Survey and Land Information,NZ. email: mark@dosli.govt.nz phone: 64 4 710-380 ext 8688 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111609052900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 17:09:11 PST Received: from fji.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Fri, 16 Nov 90 17:10:22 -0800 Date: Fri, 16 Nov 90 17:05:29 PST From: prue@venera.isi.edu Posted-Date: Fri, 16 Nov 90 17:05:29 PST Message-Id: <9011170105.AA26797@fji.isi.edu> Received: by fji.isi.edu (4.1/4.0.3-4) id ; Fri, 16 Nov 90 17:05:29 PST To: guyton@rand.org Subject: Re: Internet/NSFNet proposal to be run by IBM -- call to action! Cc: tcp-ip@nic.ddn.mil >Fyi, our Los Nettos bill (T1) is $60k for 1st year, about $30k >per year after that. [initial estimates, we've been on for >a couple years now and I've not gone back to check to see >how accurate the estimates turned out] Los Nettos has relatively short T1 lines and has had two favorable T1 line tariff changes since Los Nettos initially gave cost estimates. The real cost to members is quite a bit less. Current estimates for membership are about $25k for intial equipment and telco T1 installation plus about $15k per year for line costs. This means it would cost about $40k for the first year. Walt Prue Los Nettos ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111609340900> Received: from omnigate.clarkson.edu by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 13:36:42 PST Received: from sun.soe.clarkson.edu by omnigate.clarkson.edu id aa15776; 16 Nov 90 14:38 EST Received: by sun.soe.clarkson.edu (4.1/SMI-4.0) id AA13530; Fri, 16 Nov 90 14:34:09 EST Date: Fri, 16 Nov 90 14:34:09 EST From: Russ Nelson Message-Id: <9011161934.AA13530@sun.soe.clarkson.edu> To: tcp-ip@NIC.DDN.MIL Subject: Diagnosis: Xenix <--> SunOS Noninterop Reply-To: "aka NELSON@CLUTX.BITNET" I said: I said: Can anyone give me some hints as solve my problem with Xenix <--> SunOS NONinteroperability? OR to make the window size smaller. SCO doesn't make that easy, but I've got a call in on it, and hopefully they'll deign to tell me how I can properly configure my TCP/IP. Hee hee. Hackers 1, SCO 0. I did a 'strings' on SCO's ifconfig program. Darned if it doesn't have an undocumented parameter, onepacket. "onepacket", "-onepacket" and "ioctl (set one-packet mode params)". What the heck, let's try it: "ifconfig 3comA0 onepacket". Hey! It works! Summary: If you're using a 3c501 in your Xenix system, you must put it in onepacket mode, otherwise you won't be able to talk to Suns. Thanks to all who offered assistance. -russ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111610434500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 16:25:09 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17371; Fri, 16 Nov 90 16:19:03 -0800 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 Nov 90 10:43:45 GMT From: mcsun!hp4nl!nikhefh!a38@uunet.uu.net (James Barr) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: Request for Generic Pinger software Message-Id: <1064@nikhefh.nikhef.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello, I wondered if anyone knew of a program that could concurrently ping multiple hosts or 'ping' using different protocols. Or failing this, give me some thoughts on how to construct one. Thanks, James Barr -- James Barr ............... ...... +31 20-592-5104 ........... .......... James.Barr@nikhef.nl ...... .............. NIKHEF, Kruislaan 409, 1009DB Amsterdam .. .................. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111612183700> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 14:29:05 PST Received: from ACADVM1.UOTTAWA.CA (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57502; Fri, 16 Nov 90 17:25:16 EST Received: by UOTTAWA (Mailer R2.07) id 3187; Fri, 16 Nov 90 17:22:03 EST Date: Fri, 16 Nov 90 17:18:37 EST From: Pete Hickey Subject: Re: Why not use SO_KEEPALIVE? To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Fri, 16 Nov 90 16:44:48 GMT from Message-Id: <90Nov16.172516est.57502@ugw.utcs.utoronto.ca> Why not use keep-alives? I'm no expert by any means, but in my opinion, it should be the job of a specific server/application how long they want to wait for their timeouts. Some applications may decide that if nothing came in from the socket for x seconds, they kill/close it. The application can decide on the time if and when it wants. It should not be the job of the lower levels of the protocol. -Pete ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111616444800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 09:12:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05527; Fri, 16 Nov 90 09:10:33 -0800 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 Nov 90 16:44:48 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet@ucbvax.Berkeley.EDU (Peter Whittaker) Organization: Bell-Northern Research, Ltd., Ottawa, Ontario, CANADA Subject: Why not use SO_KEEPALIVE? Message-Id: <1990Nov16.164448.9918@bwdls61.bnr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello, I've been hearing bad things about SO_KEEPALIVE recently, but these "bad things" have amounted to nothing more than opinion - no one has yet been able to give a substantive reason not to use it (with the possible exception of "no one uses it, so it has never been debugged, so it's probably flakey, so don't use it" - a la Catch-22). So, are there in fact substantive reasons not to use SO_KEEPALIVE? (This matter arose from an application that uses SO_KEEPALIVE, naturally enough, with apparent negative impact: the server application gets killed (KILL -9) but the TCP socket stays up, connected to the remote client, with the server side sending ACK packets every now and again, just enough of them to be annoying. When we eventually want to restart the server, we have to reboot or search and destroy all clients, because the address is in use. As a fix, we're going to use SO_REUSEADDR as well as SO_KEEPALIVE. If there are substantive reasons not to use SO_KEEPALIVE, we'll recommend that it be removed from the software). Thanks, -- Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111616592600> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 06:21:19 PST Received: from VM1.calc.ucl.ac.be by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8658; Fri, 16 Nov 90 09:21:35 EST Received: from BUCLLN11 by VM1.calc.ucl.ac.be (Mailer R2.07) with BSMTP id 2317; Fri, 16 Nov 90 15:20:58 +0100 Received: from srisme.sig.ucl.ac.be by VM1.calc.ucl.ac.be (IBM VM SMTP R1.2.2MX) with TCP; Fri, 16 Nov 90 15:20:52 +01 Received: by srisme.sig.ucl.ac.be (4.1/jpk-10.90) id AA02441; Fri, 16 Nov 90 15:19:26 +0100 Date: Fri, 16 Nov 90 15:19:26 +0100 From: jpk%slig.ucl.ac.be@CUNYVM.CUNY.EDU (J.P. Kuypers) Message-Id: <9011161419.AA02441@srisme.sig.ucl.ac.be> To: TCP-IP@NIC.DDN.MIL Subject: Re: Macintosh & TCP/IP We know to : Mail Tools TechMail - Massachusetts Institute of Technology (MIT Information Systems) MacPOP - NASA Ames Research Center Eudora - University of Illinois Board of Trustees (Steve Dorner) MailStop (an SMTP/POP2 mail-server) - University of Minnesota J.P. Kuypers Catholic University of Louvain UCL - SRI place des Sciences 4 B - 1348 Louvain la Neuve (Belgium) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111617440400> Received: from gaak.LCS.MIT.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 19:46:07 PST Received: by gaak.LCS.MIT.EDU id AA20268; Fri, 16 Nov 90 22:44:04 EST Date: Fri, 16 Nov 90 22:44:04 EST Message-Id: <9011170344.AA20268@gaak.LCS.MIT.EDU> To: pww@bnr.ca Cc: tcp-ip@nic.ddn.mil In-Reply-To: (Peter Whittaker's message of 16 Nov 90 16:44:48 GMT <1990Nov16.164448.9918@bwdls61.bnr.ca> Subject: Warning: Keep-Alive considered harmful From: Michael A. Patton Sender: map@gaak.LCS.MIT.EDU Warning: Keep-Alive considered harmful!!! Date: 16 Nov 90 16:44:48 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet@ucbvax.berkeley.edu (Peter Whittaker) (Boy, what a bogus address. Good thing you put one in your signature. You may not be able to help the enormous length, but could you try and get your mail service to put YOU, not your daemon, in the header?) So, are there in fact substantive reasons not to use SO_KEEPALIVE? Yes, indeed there are. The implementation of keep-alives in the TCP level is just WRONG. Although the actual details are (usually) not a strict violation of the spec, they do stretch it in interesting ways and I have seen at least one implementation that would sometimes RESET a connection in response to a keep-alive packet. If you want the functionality that you think you get automagically by setting this option, you should really think about the specifics more. Think about what functionality you really want. Do you just want it to free up the socket or kill a server? Why do you care? Are you attacking a symptom rather than the real problem? Usually, the application needs much better control over how it really works than just setting an option that causes it to crash if something goes wrong. You should think about the many effects that can influence this (I'll list a few presently) and consider whether you want these in your application domain. Beware that you may only intend to run your application in a limited context, but eventually someone will try it over a different domain. Please consider the different cases before going for options like this. One thing to consider is that there are links in the world where you occasionally get only a packet every 5-10 minutes to actually go through. Do you want to forbid the use of your service over such a link? Just this morning I had a user complaint that they couldn't FTP a file between two distant hosts. The problem resolved to a link that dropped out for several minutes every half hour or so, but the transfer time for the file they wanted was 45 minutes. When the link dropped out, they would get punted because of keep-alives, then they had to start over. If only they weren't running keep-alives on the FTP Server it would have worked, the person doing the transfer had enough patience, if only the computer had. Another thing to consider is that in any application with a person in control, they are usually a better watch-dog timer than any program you build. This might suggest building some user-interface feature to help. The hash marks in some versions of FTP are one example. Or you might build the high-level timeout, but rather than punting the operation, merely print out a message to the user explaining how they could do it. There are a few other general things to watch out for when building any distributed system, these are a few related to the keep-alive question. Never predefine a timeout, it will eventually be too small. As an example I have an FTP script that had a global timeout on a transfer that caused it to quit and go on to the next. I discovered that for one combination of server and file, FIVE HOURS was not enough, upping it to 10 got that file transferred (but wreaked havoc with my other assumptions :-). Well, there are several more things I could bring up, but I seem to have rambled on for over a page already so I'll cut it short here. I hope this helps to answer your questions and give you some ideas as to why keep-alive is considered harmful. Hopefully it will point you in a useful direction for developing what you really need as well. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111618480900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 17 Nov 90 15:57:05 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10921; Sat, 17 Nov 90 15:47:59 -0800 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 Nov 90 18:48:09 GMT From: ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!attcan!ncrcan!scocan!larryp@beaver.cs.washington.edu (Larry Philps) Organization: SCO Canada, Inc. (formerly HCR Corporation) Subject: Re: TCP/IP Source Code Search Message-Id: <1990Nov16.184809.18378@sco.com> References: <9011052355.AA28967@yuba.WRS.COM>, <1990Nov8.172640.13894@mdivax1.uucp> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov8.172640.13894@mdivax1.uucp> mdivax1!robinson (Jim Robinson) writes: > >One possible problem is the use of non-int bit fields in the tcp and ip >header structures. Pre-ANSI C requires only that unsigned int bit fields be >supported by a compiler and ANSI C requires only (*I believe*) signed or >unsigned bit fields be supported. Thus, if your compiler does not support, >say, unsigned char bit fields, which are indeed used in the BSD code, you >will have to do a bit of work to work around this problem. If you are >unlucky, as I was, your compiler will *not* complain, but merely generate >incorrect code. > >You will also run into a number of annoying problems if the sizes of ints >and pointers on your target machine are greater than 32 bits, since there >are several coding practices employed that assume 32 bit pointers and ints. >-- >Jim Robinson >{uunet,ubc-cs}!van-bc!mdivax1!robinson Hi Jim! That was a *fun* project wasn't it! (The machine did not have a 16 bit data type, and could not do 16 bit arithmetic!) Originally the compiler only supported int bitfields (8 bytes on that machine), but the standard IP and TCP header structures are both 20 bytes. This is not divisble by 8. Since the machine enforced alignment, it was impossible to reference both the IP and TCP headers of a packet without moving things around. We eventually had to change the compiler to support short bitfields. The BSD code also used an incredibly *portable* method of moving 16 bit quantities around (ie. tcp options) via *(u_short *) cp = something. which unfortunately did not work too well with our 32 bit u_shorts. --- Larry Philps, SCO Canada, Inc (Formerly: HCR Corporation) Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net UUCP: {uunet,utcsri,sco}!scocan!larryp Phone: (416) 922-1937 Fax: (416) 922-8397 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111621393500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 17 Nov 90 05:10:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29973; Sat, 17 Nov 90 05:00:31 -0800 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 Nov 90 21:39:35 GMT From: mcsun!unido!ira.uka.de!rusux1!rusux1.rus.uni-stuttgart.de@uunet.uu.net (Kurt Jaeger aka PI) Organization: Comp. Center (RUS) U of Stuttgart, FRG Subject: NCSA-Telnet 2.3b7, IBM TR Cards & Mod.50's, Mod.80 as router ? Message-Id: <331@rusux1.rus.uni-stuttgart.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi ! Here comes a problem I don't know any cheap (in terms of money) answer for: The PC-pool of our math. dep. consists of a few (20?) Mod.50 PS/2 with IBM Token Ring cards and a file server Mod.80. The server is connected to the Mod.50's with TR and with a ethernet card to the campus LAN. We want to provide all of the Mod.50's with IP-connectivity, to connect to the rest of the LAN. Preferably we want to use NCSA-Telnet (v2.3b7 aval.). As far as I see, ncsa-telnet can make use of TR-cards. So we would need some sort of router-sw for our Mod.80 ? Where can we get some ? Should we use AIX for that purpose ? The Mod.80 is a file server with some IBM-sw (dont know it personally ;). Will it work in combination with IP ? What about using PC-NFS afterwards/instead ?h In case someone just knows a bit about it, please reply via mail. I'll summarize if there's enough interest. Comments like "forget it", "will never work" etc are highly welcome, because it will give me some hint, too ! aTdHvAaNnKcSe, PI ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111622131800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 15:10:08 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15663; Fri, 16 Nov 90 15:05:57 -0800 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 Nov 90 22:13:18 GMT From: thorin!tigger!bmh@mcnc.org (Brad Hemminger) Subject: help with tcp/ip over high speed network... Message-Id: <17617@thorin.cs.unc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We will be participating in a project that will require running some already devleoped X Window System applications over a prototype high speed network. It appears that a good route for us is to get tcp/ip running over this network, so that X and other network stuff falls out for free (?). What I'm looking for is information on what is required in order to get tcp/ip running over an arbitrary network. I.e. is the source public domain and what parts would need changing? Are their commercial companies specialize in this? An alternative might be to just port X to run an alternative protocol. Any suggestions on what protocol or how much work this would be? This would run on a sun sparc server type machine. Thanks, Brad Hemminger bmh@rad.unc.edu Dept of Radiology (919) 966-2998 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111700113900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 16 Nov 90 17:40:36 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19141; Fri, 16 Nov 90 17:34:26 -0800 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 Nov 90 00:11:39 GMT From: envy!karn@bellcore.com (Phil Karn) Organization: Packet Communications Research Group (Bellcore) Subject: Re: Why not use SO_KEEPALIVE? Message-Id: <1990Nov16.191139@envy.bellcore.com> References: <1990Nov16.164448.9918@bwdls61.bnr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov16.164448.9918@bwdls61.bnr.ca>, pww@bwdls55.bnr.ca (Peter Whittaker) writes: |> So, are there in fact substantive reasons not to use SO_KEEPALIVE? Yes. |> the server application gets killed |> (KILL -9) but the TCP socket stays up, connected to the remote client, |> with the server side sending ACK packets every now and again, just enough |> of them to be annoying. This doesn't make sense. Under BSD UNIX, at least, when you kill a process you automatically close its file descriptors and sockets. So if an application has a TCP connection open, it will be closed. The idea behind SO_KEEPALIVE is to "send ACK packets every now and then". (Actually, it sends one-byte data packets that are just before the window, eliciting ACKs to indicate that the receiver is still there.) The thinking is that you want to detect when the REMOTE end has silently died. But there are some big problems with TCP keepalives: 1. They can generate a lot of unnecessary network traffic. It is perfectly legit for an application to hold open a TCP connection for weeks or months without sending any traffic, since TCP connections normally occupy no resources other than 100 bytes or so of RAM in each end host. But if you have them send pings to each other every 30 seconds, then your idle connections can cost you a bundle - especially if your path includes an X.25 network that charges you by the packet. 2. They reduce robustness by closing connections unnecessarily when there is a temporary network outage, since network outages are usually indistinguishable from remote host failures. And if the TCP connection is idle (which is the only time you be sending keepalives anyway) why should you care if the network goes down momentarily during that time? All that matters is that it be there when your application has some real data to send, but by gratuitously closing the connection for him you've made life for the application designer that much more difficult. If the *application* wants to give up after some interval, then *it* should make that decision, not TCP. 3. How do you set the keepalive interval? Remember that your TCP and application will have to work over arbitrary Internet paths. Who's to say that 30 seconds (or 1 minute or 1 hour) is a reasonable interval between keepalives? What's reasonable today might be very unreasonable tomorrow. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111716452200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 17 Nov 90 09:58:33 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04494; Sat, 17 Nov 90 09:49:47 -0800 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 Nov 90 16:45:22 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!sigyn.idt.unit.no!ugle.unit.no!spurv.runit.sintef.no!he@ucsd.edu (Havard Eidnes) Organization: Computing Center at the University of Trondheim, Norway Subject: Re: Warning: Keep-Alive considered harmful Message-Id: <1990Nov17.164522.9996@ugle.unit.no> References: <1990Nov16.164448.9918@bwdls61.bnr.ca>, <9011170344.AA20268@gaak.LCS.MIT.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I agree that using TCP keepalives is a bad idea. I just want to comment on the specific example Michael A. Patton mentioned, making me able "with Internet Hosts Requirements in hand" to point out one other area where traditional implementations of TCP should be changed to improve robustness in the case of temporary network failures. In article <9011170344.AA20268@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes: > >Just this morning I had a user complaint that they couldn't FTP >a file between two distant hosts. The problem resolved to a link that >dropped out for several minutes every half hour or so, but the transfer >time for the file they wanted was 45 minutes. When the link dropped >out, they would get punted because of keep-alives, then they had to >start over. If only they weren't running keep-alives on the FTP >Server it would have worked, the person doing the transfer had enough >patience, if only the computer had. It is of course possible that this connection was blown away by the server using TCP keepalives. However, one other possibility (perhaps more likely) is that an intermediate gateway issued ICMP net unreachable messages while the temporary network outage lasted. Traditional implementations (including the original BSD 4.3 version) of TCP blow away a live TCP connection when they receive an ICMP net unreachable message. The Host Requirements state that a host implementation of TCP MUST NOT do this (specifically: the ICMPs net unreachable, host unreachable or source route failed should be considered temporary failures and not permanent conditions). Some gateways have the ability to turn off the sending of ICMP net unreachables, but this is just a workaround for "broken" host implementations. - Havard ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111720012400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 17 Nov 90 12:11:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06928; Sat, 17 Nov 90 12:03:15 -0800 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 Nov 90 20:01:24 GMT From: usc!phad.hsc.usc.edu!mcitron@ucsd.edu (Mark Citron) Organization: University of Southern California, Los Angeles, CA Subject: 3270 emulation for SCO tcp/ip Message-Id: <28214@usc> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I posted this a while ago and got no responses but many requests for any info I might receive so I am posting again. Is there an IBM 3270 front end emulator for SCO tcp/ip for Unix? We want to do a 3270 emulation with telnet. Thanks for any help, Mark Citron mark@neurosci.usc.edi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [72608@iuvax.cs.indiana.edu] <1990111721464900> From: templon@copper.ucs.indiana.edu (jeffrey templon) Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: WANTED: SLIP/Ethernet conversion help Message-ID: <72608@iuvax.cs.indiana.edu> Date: 17 Nov 90 21:46:49 GMT Sender: news@iuvax.cs.indiana.edu Organization: Indiana University, Bloomington IN. Lines: 21 Posted: Sat Nov 17 22:46:49 1990 Hello, I have the problem of trying to use SLIP in an 'unsupported' environment. The specific SLIP speaker is an AT&T 3b1 running the ka9q package, and the network to which I'd like to connect is an ethernet full of machines running various flavors of tcp/ip. Purchasing some sort of bridge is not an option unless it is VERY inexpensive. Someone suggested that there might be some way to have a program running on one of the ethernet-connected computers which captured the incoming SLIP stuff from the serial (terminal) line and spewed it out onto the ethernet. It seems someone must have done this before or something similar. Any help or suggestions? I don't have the time to write the program myself (nor, probably the expertise.) The machines which would be available to host such a thing would be either VMS machines or unix machines. Please reply to templon@copper.ucs.indiana.edu People wanting a summary are also welcome to reply. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111809400500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 16:35:13 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03432; Mon, 19 Nov 90 16:31:50 -0800 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 Nov 90 09:40:05 GMT From: eru!hagbard!sunic!news.funet.fi!funic!santra!ngs!news@bloom-beacon.mit.edu (Pekka Nikander) Organization: Nixu Oy, Helsinki, Finland Subject: TCP/IP - SNA gateways -- information wanted Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil [This is a resending. Apparently the earlier attempts to send this did not reach the world. If you see this TWICE, let me know.] I am trying to put up an intelligent TCP/IP -- SNA gateway. Preferably the gateway should support TCP/IP + TN3270 --> LU2.0 + 3270 and TCP/IP + our own protocol --> LU6.2 + another own protocol conversions. I think the best solution would be an Unix machine with both TCP/IP and SNA. So, I am looking for information about any ready solutions or about SNA software for IBM RS/6000, Sun, DecStation etc. If you have done something like this, PLEASE LET ME KNOW. As usual, mail to me and I'll post a summary if enough interest. -- Pekka Nikander Internet: pnr@ngs.fi -tai- Finnish Unix systems User Group (FUUG) Pekka.Nikander@ngs.fi Helsinki Unixversity of Technology ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111813571300> Received: from ftp.com by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 19:14:21 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA02744; Sun, 18 Nov 90 22:17:13 -0500 Date: Sun, 18 Nov 90 22:17:13 -0500 Message-Id: <9011190317.AA02744@ftp.com> To: tcp-ip@nic.ddn.mil Subject: Re: NCSA-Telnet 2.3b7, IBM TR Cards & Mod.50's, Mod.80 as router ? From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com The 'from' address was incredibly bogus (no username), so I'm posting... If you want to use NCSA, you have to get the Clarkson Packet Driver collection and use the "ibmtoken" driver. This simulates Ethernet on 802.5, translating the headers for NCSA. It works for a while, but on the 17th different host you try to connect to its "RIF caching" logic will come into conflict with NCSA's ARP code and you won't be able to get through... FTP Software, IBM, Wollongong and Beame & Whiteside all offer commercial DOS TCP/IPs for 802.5. All can use drivers that conform to IBM's "ASI" spec (TOKREUI or the LAN Support Program), PC/TCP at least can use 802.5 NDIS drivers as well. Because the ASI or NDIS driver allows interface sharing, you ought to be able to use TCP/IP concurrently with mounting remote volumes on your server. You will need a router of some sort. Proteon, cisco and Wellfleet all offer high-performace routers with 802.5 interfaces. IBM and TWG will sell you low-performance PC-based routers. A Banyan VINES server can act as a router between Ether and 802.5. You can use a PC/RT (at least if it runs the "academic 4.3" Unix). If AIX supports routing, you could put that on a PS/2 with two interfaces as well. I don't know offhand if "PCRoute" can hack 802.5, or if it is too simple to handle RIFs (for bridged rings). I don't believe KA9Q does 802.5. Unless AIX can also act as a fileserver, you will need to put it on another machine... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111813573100> Received: from ftp.com by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 19:15:13 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA02752; Sun, 18 Nov 90 22:17:31 -0500 Date: Sun, 18 Nov 90 22:17:31 -0500 Message-Id: <9011190317.AA02752@ftp.com> To: mcsun!hp4nl!nikhefh!a38@uunet.uu.net (James Barr) Subject: Re: Request for Generic Pinger software From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Jerry Saltzer at MIT was the first person do do something of this sort; his used the MIT PCIP software as the lower layers, but I don't know if it is included in any of the distributions. We sell one (part of our "SNMP Toolkit" offering for DOS PCs), you could write your own on our API. Whether you'd be able to do it on any given OS depends on its offering an adequate programmatic interface to ICMP; 4bsd unix lets you at the ICMP, but I don't know if it can handle multiple simultaneous requests... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111815205200> Received: from genbank.bio.net by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 00:49:53 PST Received: from asylum.UUCP by genbank.bio.net (5.61/IG-2.0) with UUCP id AA26061; Mon, 19 Nov 90 00:51:10 -0800 Received: by asylum.sf.ca.us (smail2.5x) id AA01201; 18 Nov 90 23:20:52 PST (Sun) To: jbvb@ftp.com Cc: mcsun!hp4nl!nikhefh!a38@uunet.uu.net, tcp-ip@nic.ddn.mil In-Reply-To: (James B. Van Bokkelen's message of Sun, 18 Nov 90 22:17:31 -0500 <9011190317.AA02752@ftp.com> Subject: Request for Generic Pinger software Reply-To: romkey@asylum.sf.ca.us Message-Id: <9011182320.AA01201@asylum.sf.ca.us> Date: 18 Nov 90 23:20:52 PST (Sun) From: romkey@asylum.sf.ca.us (John Romkey) Date: Sun, 18 Nov 90 22:17:31 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) Jerry Saltzer at MIT was the first person do do something of this sort; his used the MIT PCIP software as the lower layers, but I don't know if it is included in any of the distributions. It's the 'monitor' program in the last MIT release of PC/IP; it's in all the later collections. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111816161600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 07:42:34 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06141; Thu, 22 Nov 90 07:18:14 -0800 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 Nov 90 16:16:16 GMT From: mcsun!ukc!mucs!logitek!martino@uunet.uu.net (Martin O'Nions) Organization: Logitek Plc. Subject: Re: Looking for SMB/NETBIOS/RFC1001/RFC1002 server product Message-Id: References: <1990Nov9.193949.23062@eagle.lerc.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil xxseub@osprey (Steven Eubanks) writes: > I am interested in examining NETBIOS/SMB servers for both *NIX >and VMS-based platforms. I'm aware of one company call Syntax Systems >having a product in this area. Are there others? Company names and phone >numbers would be appreciated as well as any experiences with this type of >product (good and/or bad). >Thanks in advance! >Steve Hewlett Packard now, SCO for Q1 '91 (they tell me), and a number of others for the near future have all committed to providing LM/X, running SMB/NB/TCP. We have tried the existing SCO client in-house, talking to a 3Com 3+ Open Lan Manager server over IP, and it seemed to work O.K...... On a general point, the number of PC LANS based around Lan Manager and the Server Message Block scheme seems to vindicate the technique - the testing time will be with the general availability of LM/X. (No, this does not represent an official statement on behalf of and Logitek Group company - I am to blame if anyone disagrees.) -- +------------------------------------------------+-----------------------+ | I've got a little black book with my poems in, | Martin O'Nions | | I've got a bag with a toothbrush and a comb in,| Logitek Group Support | | When I'm a good dog they sometimes throw me a | martino@logitek.co.uk | | bone in (Roger Waters - The Wall) | 0257 426 644 | +------------------------------------------------+-----------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111816273100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 17:35:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05616; Mon, 19 Nov 90 17:30:37 -0800 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 Nov 90 16:27:31 GMT From: bsu-cs!sam@iuvax.cs.indiana.edu (B. Sam Blanchard) Organization: Ball State University Subject: Request: SLIP on a Sequent S27 (info on SLIP in general) Message-Id: <12073@bsu-cs.bsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I would like to implement SLIP on a Sequent S27 running Dynix. Dynix is 4.2bsd with many 4.3bsd enhancements. (yes, Dynix is much more) Sequent Support told me that kernel support was required and Sequent did not support SLIP. I do not have source. I was told that adding 'options SLIP' might work. There appears to be an unsupported SLIP in Sequent's Dynix. Can anyone refer me to documentation on SLIP that would assist in using SLIP. I have "no idea" how to try SLIP out to see if anything works. -- B. Sam Blanchard UUCP: !{iuvax,pur-ee}!bsu-cs!sam ARPA: sam@bsu-cs.bsu.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111821323700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 04:41:52 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28504; Thu, 22 Nov 90 04:37:18 -0800 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 Nov 90 21:32:37 GMT From: rti!dg-rtp!bigben!bigben!philip@mcnc.org (Philip Gladstone) Organization: Data General, Development Lab Europe Subject: Re: Death on ICMP unreachable also harmful Message-Id: References: <1990Nov16.164448.9918@bwdls61.bnr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Havard Eidnes writes: > The Host Requirements state > that a host implementation of TCP MUST NOT do this (specifically: the ICMPs > net unreachable, host unreachable or source route failed should be > considered temporary failures and not permanent conditions). Some gateways > have the ability to turn off the sending of ICMP net unreachables, but this > is just a workaround for "broken" host implementations. I have found that most implementations of TCP/IP do not return net/host unreachable messages even when they know that the path to the net/host is not available. Is this due to the existence of the 'broken' implementations as mentioned above? For example, on a lan which uses ARP, the host 'knows' that the remote machine is not present when the ARP request times out. At this point, it tends to drop the datagram. I would prefer to get back 'net unreachable' messages rather than the ubiquitous 'timeout' message. -- Philip Gladstone Development Lab Europe Data General, Cambridge England. +44 223-67600 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111821591000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 22:54:42 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17259; Mon, 19 Nov 90 22:49:23 -0800 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 Nov 90 21:59:10 GMT From: mcsun!ukc!slxsys!ibmpcug!robobar!ronald@uunet.uu.net (Ronald S H Khoo) Organization: Robobar Ltd., Perivale, Middx., ENGLAND. Subject: Re: Request: SLIP on a Sequent S27 (info on SLIP in general) Message-Id: <1990Nov18.215910.796@robobar.co.uk> References: <12073@bsu-cs.bsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12073@bsu-cs.bsu.edu> sam@bsu-cs.bsu.edu (B. Sam Blanchard) writes: > I would like to implement SLIP on a Sequent S27 running Dynix. > Sequent Support told me that kernel support was required and Sequent did not > support SLIP. I do not have source. If you have a spare dusty PC XT or so and can fork out the $$ for a Western Digital ethernet card (or have a PC ethernet card supported by a packet driver -- there are lots, but native support for the WD card will give you better performance) you can do this with the aid of PC route 2.1 or any other router that supports SLIP: +-------------+ ethernet +---------+ RS-232 | sequent +------------+ router +----------> SLIP! +-------------+ +---------+ The PC software is FREE by FTP from accuvax.nwu.edu under pub/pcroute. This way, you will save your sequent from being hammered by the SLIP link too. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111901590100> Received: from aq.ssc.af.mil ([140.185.5.10]) by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 06:00:29 PST Received: from [140.185.160.62] by aq.ssc.af.mil (5.59/25-eef) id AA04907; Mon, 19 Nov 90 07:58:13 CST Subject: SCO TCP/IP and E-Mail Problems To: tcp-ip@nic.ddn.mil Date: Mon, 19 Nov 90 7:59:01 CST From: "Capt E. Lee Hutchins" X-Mailer: ELM [version 2.3 PL2] Message-Id: <9011190759.aa12077@ssmct62.ssc.af.mil> Source-Info: From (or Sender) name not authenticated. Greetings! I am running SCO Unix on a UNISYS PW2/800 otherwise known as the DoD Desktop III computer. I am having *LOTS* of problems configuring the mail system so that it interacts properly with the other mail systems in use at my location. First of all, SCO states in its documentation, that it provides sendmail but it does NOT support it. - I can see why, the "sendmail.cf" file has bugs in it which prohibit receipt of mail by users from remote machines. Any ideas on this would be of lots of use because the alternative is "MMDF". MMDF is the supported mail system for SCO UNIX. MMDF does not come with an ideal set of documentation. (At least I can't make heads or tails out of it). If any one has some ideas on Docs for this system which are NOT in troff form I'd appreciate them. Configuring MMDF without real documentation is a real *&^%$! I can recieve mail from other UNIX platforms, but we have another mail system running which is based on 10NET, called "COURIER MAIL". It has an "SMTP" gateway working and other UNIX boxes (AT&T 3B2 600G's) can receive and send mail fine. My box on the other hand, does not work with it. The mail ends up in a queue on the "COURIER SERVER" and is never returned to me or the originator. Anybody ever experienced this???? By the way my machine does not always accept: telnet machinename.domain 25 When tried manually from other hosts it often closes the connection before it askes for the identification. In fact it seems the more mail sent to my machine, the less I actually receive. I am on *several* mailing lists and I expected my mail volume to be much higher than it is. Finally, one other tidbit, I am running the latest version of "ELM" as my front end to mail. If you could send responses directly to me I'd appreciate it. I will be more than happy to post a summary later on. thanx - in advance E. Lee Hutchins e-mail: hutch@ssmct62.ssc.af.mil mule train: SSC/SSMCT Bld 325 % Capt Hutchins Gunter AFB, AL 36114 (205) 279-4555 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111904401500> Received: from sayshell.umd.edu by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 06:39:07 PST Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA08953; Mon, 19 Nov 90 09:40:15 EST Date: Mon, 19 Nov 90 09:40:15 EST From: louie@sayshell.umd.edu (Louis A. Mamakos) Message-Id: <9011191440.AA08953@sayshell.umd.edu> To: barmar@think.com, tcp-ip@nic.ddn.mil Subject: Re: Warning: Keep-Alive considered harmful Organization: The University of Maryland, College Park Cc: In article <1990Nov19.063111.21768@Think.COM> you write: >Unfortunately, keep-alives are sometimes needed to work around deficiencies >in application protocols. For instance, there's no way for a server telnet >to detect when the client host has crashed (it could send an IAC >Are-You-There, but there's no standard for the response, so it would >confuse the process receiving the input). The server telnet could periodically send TELNET NOP commands (IAC NOP) to the client. This should not cause any response to be generated, but will poke the TCP re-transmission machinary to make sure that the connection is intact. louie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111906225800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 22:25:42 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16108; Mon, 19 Nov 90 22:20:38 -0800 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 Nov 90 06:22:58 GMT From: ogicse!milton!mrc%Tomobiki-Cho.CAC.Washington.EDU@ucsd.edu (Mark Crispin) Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Subject: new IMAP distribution available Message-Id: <11360@milton.u.washington.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A new release of the IMAP2 multi-platform distributed e-mail system is now available via anonymous FTP from FTPHOST.CAC.WASHINGTON.EDU (IP address 128.95.112.1) as imap/imap.tar.Z. Inside the imap.tar.Z distribution are three new servers, all of which run under inetd. These are: a complete rewrite of the IMAP2 server, a POP2 server, and a POP3 server. Additionally, the POP2/POP3 servers are also IMAP clients, providing a POP->IMAP gateway to allow you to leverage on your existing POP-based PC clients yet still use IMAPware. Client programs include the NeXT MailManager and EasyMail programs, the Macintosh MacMS program, and the Unix MS program. We hope to have a version of the Unix Pine program available for distribution in the NeXT release. A PC client (Pine or other) is planned for the 2nd quarter of 1991 (= my boss has told me "enough waiting for someone else to do it, *you* do it"). Both clients and servers use the same c-client library for mailbox access, supporting local mailboxes in /usr/spool/mail and mail.txt format as well as remote IMAP mailboxes in a transparent fashion. Among other things, this ensures complete compatibility and interoperability between POP, IMAP, and local mailbox access in this release. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ MRC@CAC.Washington.EDU "Iie, boku ha nihonjin." / | \ | |__| / \ / \ Lumchan ga suki ja!! "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111906311100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 14:38:48 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06039; Mon, 19 Nov 90 13:55:54 -0800 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 Nov 90 06:31:11 GMT From: think.com!barmar@CS.YALE.EDU (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: Warning: Keep-Alive considered harmful Message-Id: <1990Nov19.063111.21768@Think.COM> References: <1990Nov16.164448.9918@bwdls61.bnr.ca>, <9011170344.AA20268@gaak.LCS.MIT.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Unfortunately, keep-alives are sometimes needed to work around deficiencies in application protocols. For instance, there's no way for a server telnet to detect when the client host has crashed (it could send an IAC Are-You-There, but there's no standard for the response, so it would confuse the process receiving the input). However, I think the common design of keep-alives is incorrect. The connection shouldn't be killed as a result of keep-alive timeouts. Instead, the purpose of keep-alives should be to elicit RSTs from the other host. Timeouts can be due to any number of reasons, but a RST indicates unambiguously that the connection is unusable, because the other end rebooted or closed the connection itself (perhaps network problems prevented the FIN from getting through). If a host crashes, the keepalive won't actually notice this until it comes back up, which is probably good enough. Yes, this will not catch all half-open connections. If the host dies for good, or crashes and is given a new address, the other hosts won't automatically kill their connections to it. But it's better to leave some useless connections open than to close some useful connections. Pinging for RSTs is fail-safe. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111908335900> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 18:48:26 PST Received: from braden.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 19 Nov 90 16:33:56 -0800 Date: Mon, 19 Nov 90 16:33:59 PST From: braden@venera.isi.edu Posted-Date: Mon, 19 Nov 90 16:33:59 PST Message-Id: <9011200033.AA04881@braden.isi.edu> Received: by braden.isi.edu (4.1/4.0.3-4) id ; Mon, 19 Nov 90 16:33:59 PST To: ietf@venera.isi.edu, tcp-ip@nic.ddn.mil Subject: IAB meeting minutes available Cc: iab@venera.isi.edu, iesg@venera.isi.edu Minutes of the October 1990 IAB meeting are now available for anonymous FTP from host venera.isi.edu with the pathname: pub/IABmins.oct90.txt Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111908350000> Received: from UDLAPVMS.PUE.UDLAP.MX by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 12:27:50 PST Date: Mon, 19 Nov 90 14:35 CST From: Armando Mac Beath Subject: Re: Request for Generic Pinger software To: TCP-IP@NIC.DDN.MIL Message-id: <00CBB9408F7F00073B@UDLAPVMS.PUE.UDLAP.MX> X-Envelope-to: TCP-IP@NIC.DDN.MIL X-VMS-To: IN%"TCP-IP@NIC.DDN.MIL" X-VMS-Cc: MACBEATH Date sent: 19-NOV-1990 14:33:20 > > >For VAX/VMS, there is NPRV -- IP Node/Protocol Reachability Verifier. NPRV is a >full-screen, keypad-oriented utility that runs under VAX/VMS. It allows the >user to quickly scan through a user-defined list of IP addresses (or domain >names) and verify a node's reachability. The node's reachability is determined >by performing an ICMP echo, UDP echo and a TCP echo at alternating three second >intervals. > >NPRV runs under VAX/VMS V5.1+ and TGV Incorporated's MultiNet version 2.0. >It can use any network interface supported by TGV Incorporated's MultiNet >software. > >NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV >(128.55.128.30). The distribution includes the following files: > > [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC (ASCII text) > [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE (binary) > [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA (ASCII text) > >Hope this helps. > >Bob Stine Bob, This host have a anonymous disallowed :( Do you know how can get this package in another host or can you send me all files !!!!!!!! Armando Mac Beath macbeath@udlapvms macbeath@udlapvms.pue.udlap.mx ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111911020800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 06:59:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04677; Thu, 22 Nov 90 06:48:31 -0800 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 Nov 90 11:02:08 GMT From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!solo!vaxb.acs.unt.edu!billy@ucbvax.Berkeley.EDU Subject: Internet library guide - additions requested Message-Id: <1990Nov19.110808.41235@vaxb.acs.unt.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, I edit an Internet/THENET library guide (UNT's Accessing On-line Bibliographic Databases). I am working on the next version. I would like anyone who is aware of how to access a card catalog system over the Internet (that is not listed below) to please send me mail directly with instructions on accessing that system. I will post a message to this newsgroup when I finish the update explaining how to get a copy of the new version. The current version (July 90) is available via anonymus FTP on VAXB.ACS.UNT.EDU. The file name is LIBRARIES.TXT. Numeric IP addresses are list in LIBRARIES.ADR. The libraries I currently have instructions for are: Auburn, Auraria University, Boston Univ., Boulder Public Library, Brown, Cal Poly State, California State Univ, Case Western, CARL, Clemson, CMU, Colorado School of the Mines, Columbia, Cornell, CWRU, Dartmouth, Deakin Univ., Denver Pulbic Library, Denver University, Emory, Florida A&M, Florida Atlantic, Florida State, Florida International, Harvard Univ, Indiana Univ., Kent State, Lehigh, Luther College, MARMOT library (Colorado Western Slopes), Monterrey, Mich State, Montegomery County (Rockville, MD), New Mexico St., New York Univ, Northeastern, Northwestern, Ohio State, Penn State, Pikes Peak Library, Princeton, Purdue, RPI, Rice, Rutgers, Sam Houston State University, SUNY -Binghamton, Texas A&M, TWU, Univ of Cal, UC Berkeley, U of Central Florida, U of Chicago., U of Colorado at Boulder, U of Delaware, U of Florida, U of Hawaii at Honolulu, U of Hawaii at Manoa, U of Ill. Champaign/Urbana, U of Ill/Chic, U of Kansas, U of Maine, U of Maryland, U of Michigan, U of Minnesota, U of Missouri, U of Nebraska, UNLV, U of New Mex., U of North Florida, U of North Texas, U of Northern Colorado, Notre Dame, U of Oregon, U of Penn, U of Pitt, U of South Florida, U of Tenn, U Tenn Memphis, U of UT Arlington, UT Austin, UT Dallas, UT Health Science Center at San Antonio, UT Health Center at Tyler, U of Toledo, U of Utah, U of Wash., U of West Florida, U of Wisconsin, U of Wyoming, Vanderbilt, Victoria U Wel, Virginia Commonwealth, Virginia Tech, Wash U at SL, Wayne State. Also, I have instructions that I can not get to work for John Hopkins, UNC, Duke, NC State, Australian National University, and University of Konstanz. Finally, if anyone knows the nodename (not numeric address) of the Virginia Tech library (128.173.5.4), please let me know. Thanks, ================================================================================ Billy Barron Bitnet : BILLY@UNTVAX VAX/Unix Systems Manager THENET : NTVAX::BILLY University of North Texas Internet : billy@vaxb.acs.unt.edu SPAN : UTSPAN::UTADNX::NTVAX::BILLY ================================================================================ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111915020000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 07:17:27 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id aj24679; 19 Nov 90 10:10 EST Date: Mon, 19 Nov 90 15:02 GMT From: Bob Stine <0004219666@mcimail.com> To: James Barr Cc: tcp ip Subject: Re: Request for Generic Pinger software Message-Id: <40901119150204/0004219666NB2EM@mcimail.com> >I wondered if anyone knew of a program that could concurrently >ping multiple hosts or 'ping' using different protocols. A cursory skim thru RFC 1147 shows 4 tools that might meet your requirements: 1. Internet Rover, 2. Map, 3. netmon, and 4. NPRV Quoting liberally from the RFC.... Internet Rover is a prototype network monitor that uses multiple protocol "modules" to test network functionality... Modules are included to test TELNET, FTP, and SMTP. The Internet Rover is known to run on Suns and IBM RTs. It requires curses, 4.xBSD UNIX socket programming libraries, and BSD ping. Full source for Internet Rover is available via anonymous FTP from merit.edu (35.1.1.42) in the ~ftp/pub/inetrover directory. Source and executables are public domain and can be freely distributed for non-commercial use. Map -- the Interactive Network Map -- draws a map of network connectivity and allows interactive examination of information about various components including whether hosts can be reached over the network. Net components are pinged by use of ICMP echo and, optionally, CHAOS status requests and SNMP "gets." Map requires an X display for interactive display of the map, although non-graphical interaction is available in non-display mode. For hardcopy output a PostScript or Tektronix 4692 printer is required. Map runs under BSD UNIX or related OS. IP/ICMP is required; CHAOS/STATUS and SNMP can be used but are optional. X-Windows is required for interactive display of the map. To obtain individual files or instructions on getting the full current release, send a request to: MAP-Request@LCS.MIT.Edu. Netmon is a DOS-based program that pings hosts on a monitored list at user-specified intervals. In addition, a user may optionally ping hosts not on the list. Netmon also performs domain lookups. Furthermore, a user may build and send a domain query to any desired DNS server. Netmon requires the DOS operating system, and the PC/TCP Kernel by FTP Software, Inc. The BYU modified version is available for anonymous FTP from Dcsprod.byu.edu, in directory "programs." It can be freely distributed for non-commercial use. For VAX/VMS, there is NPRV -- IP Node/Protocol Reachability Verifier. NPRV is a full-screen, keypad-oriented utility that runs under VAX/VMS. It allows the user to quickly scan through a user-defined list of IP addresses (or domain names) and verify a node's reachability. The node's reachability is determined by performing an ICMP echo, UDP echo and a TCP echo at alternating three second intervals. NPRV runs under VAX/VMS V5.1+ and TGV Incorporated's MultiNet version 2.0. It can use any network interface supported by TGV Incorporated's MultiNet software. NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV (128.55.128.30). The distribution includes the following files: [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC (ASCII text) [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE (binary) [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA (ASCII text) Hope this helps. Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111915452100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 21:50:38 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14889; Mon, 19 Nov 90 21:46:19 -0800 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 Nov 90 15:45:21 GMT From: mcsun!ukc!icdoc!syma!nickw@uunet.uu.net (Nick Watkins) Organization: University of Sussex Subject: tftp needed for HP9000/835 Message-Id: <3841@syma.sussex.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have an X terminal which needs to use trivial ftp to download the X binary from an HP9000/835. tftp is not included in the TCP-IP software suite provided with HP-UX (LAN 9000), has anybody got a suitable (source or binary) version of tftp that we could have ? Email to me, please. Thanks, Nick -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111916224500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 22:05:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15359; Mon, 19 Nov 90 21:59:01 -0800 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 Nov 90 16:22:45 GMT From: pasteur!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU (Henry Spencer) Organization: U of Toronto Zoology Subject: Re: Warning: Keep-Alive considered harmful Message-Id: <1990Nov19.162245.10683@zoo.toronto.edu> References: <1990Nov16.164448.9918@bwdls61.bnr.ca>, <9011170344.AA20268@gaak.LCS.MIT.EDU>, <1990Nov19.063111.21768@Think.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov19.063111.21768@Think.COM> barmar@think.com (Barry Margolin) writes: >Unfortunately, keep-alives are sometimes needed to work around deficiencies >in application protocols. For instance, there's no way for a server telnet >to detect when the client host has crashed ... I think this is a confusion of mechanism with policy. A server telnet needs a way to tell the TCP layer "ping the other end". That is not the same as having a wired-in policy that the TCP layer will ping the other end regularly and break the connection if there is no response. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111920015300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 03:49:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25147; Thu, 22 Nov 90 03:24:56 -0800 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 Nov 90 20:01:53 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!polygen!rbraun@ucsd.edu (Richard Braun) Organization: Polygen Corporation, Waltham, MA Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <897@fred.UUCP> References: <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil grr@cbmvax.commodore.com (George Robbins) writes: >In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: >> We're interested in encapsulating DECnet within a TCP-IP package. We >> are looking primarily for a software solution... > >I believe TGV multinet can handle this... MultiNet is, IMHO, far and away the best TCP/IP package available for VAX/VMS. (This after reviewing products ranging from Process Software to Fusion to Wollongong to...) It's a Stanford-bred product written in C with some TOPS-20'isms in it. But I fail to understand the original question: "encapsulating DECnet within TCP/IP". That just doesn't mean anything. It could mean buying a binary license to DECnet and one to TCP/IP and writing an application which calls both. Or it could mean buying a MultiNet source license for $megabucks plus a TCI "CommUnity" DECnet source license for $megabucks and integrating the two. Or it could mean going to DEC or Equinox or some other company and buying a LAT/TCP terminal server to hook onto your Ethernet. As you can see, you can come up with solutions that cost anywhere from $3,000 to $3,000,000. What's the need, anyway? And was it on VMS-only or does it have to be platform-independent? -rich ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990111923070000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 11:09:13 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17439; Thu, 22 Nov 90 11:06:52 -0800 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 Nov 90 23:07:00 GMT From: rti!mozart!MVS.SAS.COM!SNODDI@mcnc.org (Dale Ingold) Organization: SAS Institute Inc. Subject: Desperately Seeking MVS Netnews Reader Message-Id: <9011192305.AA28557@mozart.unx.sas.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are looking for any information on a news reader for MVS, preferably(?) using NNTP across a TCP/IP link via IBM's TCP/IP product for MVS. ------------------------------------------------------------------------ Dale Ingold Internet: snoddi@mvs.sas.com SAS Institute Inc. Phone: 919-677-8000 x7603 SAS Campus Drive Cary, NC 27513-2414 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112000195200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 23:34:49 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18666; Mon, 19 Nov 90 23:25:13 -0800 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 Nov 90 00:19:52 GMT From: rochester!rocksanne!sma@louie.udel.edu (Susie Armstrong) Organization: WRC, XEROX Subject: NFS over TCP? Message-Id: <640@rocksanne.WRC.XEROX.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi, A while back I posted (in the nfs group) looking for a user-space public domain implementation for NFS, and received some good replies, along with a suggestion that I be more specific about my reasons for wanting such a beast. What I'm really looking for is an NFS implementation over TCP instead of UDP. I'm aware of the BSD 4.3 Reno implementation - unfortunately, I really need something to run on a Sun 4. Any additional suggestions? Cheers, Susie Armstrong Xerox Webster Research Center armstrong.wbst128@xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [160rwmira01@ULKYVX.bitnet] <1990112002250000> From: rwmira01@ULKYVX.BITNET (NEWS_PERSONALNAME) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Looking for Info on TCP/IP packages (Novice here!) Message-ID: <160rwmira01@ULKYVX.bitnet> Date: 20 Nov 90 02:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of Louisville Lines: 45 Posted: Tue Nov 20 03:25:00 1990 I have some (what I hope are) simple questions about TCP/IP products. But before I get to that, here is my background and what I am attempting: I know what telnet and ftp do and I know how to basically use them. I know how to manage a Unix file server for StarLAN (and can program in 'C') but I have little expertise on the low-level networking. We are using AT&T StarGROUP 3.2 on a Unix file server (intel 386) with AT&T Unix Sys V R 3.2.2. I have a StarServer E with Sys V R4 on order. When we are done, we will be on a 10BASE-T network with other Unix boxes, as well as our VAX/VMS. Within the next 6 months we hope to become a real internet site and put our IBM Mainframe on Internet was well. Now for my question(s). I am looking for a Cheap (read free/public domain where applicable) implementation of both TCP/IP and NFS. My goals are: 1) Allow the StarGROUP PC Client to TELNET/FTP to our Unix File Server 2) Allow the StarGROUP PC Client to TELNET/FTP to any other TCP/IP host that I can reach. 3) Allow Macintosh's on the network to access the Unix file server as their file server (Apple tells me as long as NFS is on the Unix box their happy). 4) Allow the Unix server to be a TCP/IP host for the world 5) Multiple session via Windows 3.0 6) Possible Netnews at the PC desktop (low priority) 7) Mail at the desktop (if possible) Over the weekend I acquired the binaries to NCSA/Telnet and I was able to FTP between a couple of PCs today. I couldn't get it to work with the Packet Driver (AT&T.COM) for our network cards, but the Netbios version worked with StarGROUP loaded but I got some weird data on the screen, but the files seemed to transfer well. What do I need to get TCP/IP on my unix box, preferably public domain? Any advice in pulling this off would be of great help. Please respond by E-Mail, although I will subscribe to these groups for the next couple of weeks. Thanks in advance Rob Miracle LAN consultant University of Louisville "Kill Wesley! Kill Wesley!" -- Irate Star Trek:TNG Fans ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112003161900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 04:56:47 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29343; Thu, 22 Nov 90 04:54:55 -0800 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 Nov 90 03:16:19 GMT From: uhccux!munnari.oz.au!metro!solar.card.inpu.oz.au!brett@ames.arc.nasa.gov (Brett Sealey) Organization: Telecom Australia Subject: Looking for SLIP driver for HP-UX 9000/360 Message-Id: <1990Nov20.031619.2347@solar.card.inpu.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The box is a HP-UX 9000 series 360, version 7 Any information about such a beast (When, where, how ...) would be much appreciated. Thanks, Brett. ______________________________________________________________________________ __ __ ___ ____ ____ /__) /__) /_ / / brett@solar.card.inpu.oz.au /__) / \ /__ / / Brett Sealey ______________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112003283000> Received: from VAX.BBN.COM by NIC.DDN.MIL with TCP; Tue, 20 Nov 90 05:30:24 PST Date: Tue, 20 Nov 90 8:28:30 EST From: Charles Lynn To: Barry Margolin cc: tcp-ip@nic.ddn.mil Subject: Re: Warning: Keep-Alive considered harmful The old TOPS-20 TCP/IP used the RST method of probing for half-open connections, by sending an unacceptable "SYN-ACK". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112012203400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 02:31:17 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22083; Thu, 22 Nov 90 02:21:23 -0800 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 Nov 90 12:20:34 GMT From: templon@iuvax.cs.indiana.edu (jeffrey templon) Organization: Indiana University, Bloomington IN. Subject: SUMMARY: SLIP/Ethernet conversion help Message-Id: <73149@iuvax.cs.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi net.folk: Here is a summary of what I found out. I am posting since several people asked for the summary. Thanks to all who responded. Jeff From <@ugw.utcs.utoronto.ca:kieffer@uncanet> Sun Nov 18 02:37:27 1990 From: kieffer%uncanet.bitnet@ugw.utcs.utoronto.ca (Rom Kieffer, TransCanada PipeLines) Subject: slip routing > Someone suggested that there > might be some way to have a program running on one of the ethernet-connected > computers which captured the incoming SLIP stuff from the serial (terminal) > line and spewed it out onto the ethernet. > if you can dig up an old PC, then you can build your own bridge with PCRoute. Its is a pd package that can route between SLIP and TCP/IP ethernets. I cannot remember where it is housed for ftp, but a query to the ip community would be propbably get you an address. rom From vthrc%uqvax.cc.uq.oz.au@brolga.cc.uq.oz.au Sat Nov 17 22:19:01 1990 From: Danny Thomas Subject: Re: WANTED: SLIP/Ethernet conversion help Organization: VTHRC, University of Queensland I think you could use Vance Morrison's PC-ROUTE or PC_BRIDGE from acns.nwu.edu, running on a PC with an ethernet card. "What about SLIP Speeds? PCRoute also supports up to 2 serial lines in addition to the other interfaces. These lines can operate at all the common baud rates up to 19.2K. In PCRoute with a faster processor (10MHz XT or AT clone) can handle 38.4K or even 57.6K. Akll of this using the standard 8250 serial ports" You'll need a copy of Borland's Turbo Assembler to compile the source after you specified the configuration, but I was very happy with the ease of installation (network novice speaking). Ours is used to link two (Mac) LocalTalk nets onto the university ethernet. It only handles TCP/IP but I've been very happy with it, but there may better solutions to you problem, I don't know. From calford%psych.psy.uq.oz.au@vthrcmac.vthrc.uq.oz.au Sun Nov 18 15:55:44 1990 From: calford@psych.psy.uq.oz.au Hmm, I think I forgot to mention PC-ROUTE takes over the machine and is intended to run as a dedicated router. It is a good use for any old PC you may have sitting around unused; it only needs a single floppy to boot from and 128K RAM (certainly less than 256K), no hard disk, keyboard or video card. If you have to buy a PC, one from Jameco is recommended. I suppose if you only wanted occasional access you could run the software on one of the nearby PCs. You'd boot from a floppy with DOS and the configured PC-ROUTE, I don't think you'd have any problems with the ethernet also hosting the 3COM network as well as the machines you want to connect to with TCP/IP. Suggestion is to talk about it with your local network experts, perhaps after downloading the PC-ROUTE docs. Let us know how you get on, Danny Thomas. From calford%psych.psy.uq.oz.au@vthrcmac.vthrc.uq.oz.au Sun Nov 18 16:35:39 1990 From: calford@psych.psy.uq.oz.au Oops, another point I forgot to mention is PC-ROUTE only comes with drivers for Western Digital ethernet cards, i.e. WD8003E ethercard plus and corresponding starlan cards WD8003S & WD8003SH. This info is particularly significant if you're considering part-time use of an existing ethernetted PC, but still necessary if you're buying a card. From nickless@elrond.cs.andrews.edu Sun Nov 18 21:19:54 1990 From: nickless@elrond.cs.andrews.edu (Bill Nickless) If you have a terminal server connecting to the 3b1, you might check to see if it will talk SLIP. That's how we hooked up our 3b1, and in fact one of the graduate students is working on integrating sendmail with ka9q. If you have an el-cheapo IBM PC box floating around, you could put an inexpensive ethernet card into it for the network. Many BSD-derived systems provide SLIP support. Sometimes it's documented, sometimes not. If you have a Sun computer on your Ethernet it should handle the application properly. Various ftp sites have SLIP for the suns. Hope this helps. --- Bill Nickless nickless@peter.cs.andrews.edu or nickless@flash.ras.anl.gov (708) 972-7390 or (616) 927-0982 From: Mr. Antonio Querubin Organization: University of Hawaii Yes it should be possible to connect your 3b1 to the network via SLIP. You'll need to setup a SLIP port on one of your other machines (I believe Ultrix has built-in SLIP capability and Ultrix-Connections for VMS does too) that is also on your ethernet LAN. The gateway host MAY need to have it's routing tables adjusted depeding on what you're running on it. From gjc@mitech.com Mon Nov 19 11:09:19 1990 Status: OR > From: templon@copper.ucs.indiana.edu (jeffrey templon) > Subject:WANTED: SLIP/Ethernet conversion help > Date: 17 Nov 90 21:46:49 GMT > Message-ID:<72608@iuvax.cs.indiana.edu> > Hello, > > I have the problem of trying to use SLIP in an 'unsupported' environment. > The specific SLIP speaker is an AT&T 3b1 running the ka9q package, and > the network to which I'd like to connect is an ethernet full of machines > running various flavors of tcp/ip. Purchasing some sort of bridge is not > an option unless it is VERY inexpensive. You will probably get a few responses from people telling you about SLIP drivers for SUN microsystems machines. I use one of those myself on RILIAN.PARADIGM.COM (not yet registered). But you should know that KA9Q also runs on IBM-PC clone machines. So that would be one way to put together an inexpensive dedicated bridge (there being reliability and flexibility advantages to dedicated bridges). Northeastern University here in Boston MA runs KA9Q in this way. -gjc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011202147.AA26071@ucbvax.Berkeley.EDU] <1990112013283000> From: clynn@BBN.COM (Charles Lynn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Warning: Keep-Alive considered harmful Message-ID: <9011202147.AA26071@ucbvax.Berkeley.EDU> Date: 20 Nov 90 13:28:30 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Posted: Tue Nov 20 14:28:30 1990 The old TOPS-20 TCP/IP used the RST method of probing for half-open connections, by sending an unacceptable "SYN-ACK". ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112013553700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 04:08:05 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26606; Thu, 22 Nov 90 03:57:07 -0800 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 Nov 90 13:55:37 GMT From: eru!hagbard!sunic!news.funet.fi!kannel!Kimmo.Suominen@bloom-beacon.mit.edu (Kimmo Suominen) Organization: Lappeenranta University of Technology, Finland Subject: Re: Looking for SLIP driver for HP-UX 9000/360 Message-Id: References: <1990Nov20.031619.2347@solar.card.inpu.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil >>>>> On 20 Nov 90 03:16:19 GMT, brett@solar.card.inpu.oz.au (Brett Sealey) said: Brett> Any information about such a beast (When, where, how ...) would be much Brett> appreciated. Ask your local support for a free (!) distribution of SLIP. It is available for both the 800 and 300 series. It is also UNSUPPORTED but it should work. I already got mine, but I yet need to install it. -- Kim / Internet: Kimmo.Suominen@lut.fi "That's what I think." / Bitnet: KIM@FINFILES ----MESSAGE-END---- ----MESSAGE-BEGIN---- [47092@eerie.acsu.Buffalo.EDU] <1990112014175300> From: tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi) Newsgroups: comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.comm Subject: problems with NCSA Telnet 2.2 and EtherPortSE installer Message-ID: <47092@eerie.acsu.Buffalo.EDU> Date: 20 Nov 90 14:17:53 GMT Sender: news@acsu.Buffalo.EDU Followup-To: comp.protocols.tcp-ip Organization: State University of New York at Buffalo Lines: 14 Posted: Tue Nov 20 15:17:53 1990 Nntp-Posting-Host: sybil.cs.buffalo.edu Originator: tksjmi@sybil.cs.Buffalo.EDU There is no comp.protocols.tcp-ip.mac, so excuse the cross postings... I have a couple of MacSEs that I cannot get working with NCSA Telnet 2.2. I am using EtherPortSEs in both the machines, I have release 2.5, rev B of the EtherPortSE installation disk. The ethernet drivers install successfully, but when I invoke NCSA Telnet, I get a System ID of 12, and I have to restart the Mac. Has anyone encountered this before and can give me some tips? thanks JoAnn Illuzzi University of Buffalo Technical Services 716-636-3558 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112016473400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 03:00:59 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22607; Thu, 22 Nov 90 02:32:18 -0800 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 Nov 90 16:47:34 GMT From: psuvm!ysub!doug@psuvax1.cs.psu.edu (Doug Sewell) Organization: Youngstown State University VM system (YSUB) Subject: tn3270 for sysv/twg tcp (NCR Tower) ? Message-Id: <90324.114734DOUG@ysub.ysu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have a NCR Tower running System V with TWG tcp and sockets. I attempted to compile 'vanilla' tn3270 with no luck - missing includes, undefined symbols, etc. Including twg_config.h didn't seem to help (this was a few weeks ago, I don't remember what all of the errors were). Does anyone have a ftp-able version of tn3270 for System V/TWG ? Thanks in advance, Doug -- Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555 E-mail: doug@ysub.bitnet, doug@ysub.ysu.edu, ...!uunet!ysub.ysu.edu!doug You can believe me, because I never lie, and I'm always right (: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112017392100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 10:56:07 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16187; Thu, 22 Nov 90 10:41:12 -0800 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 Nov 90 17:39:21 GMT From: mvb.saic.com!dayton.saic.com!fac2@ucsd.edu (Earle Ake) Organization: Science Applications Intl. Corp., Dayton, Ohio Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <1990Nov20.133921.1332@dayton.saic.com> References: <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com>, <897@fred.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <897@fred.UUCP>, rbraun@polygen.uucp (Richard Braun) writes: > grr@cbmvax.commodore.com (George Robbins) writes: >>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: >>> We're interested in encapsulating DECnet within a TCP-IP package. We >>> are looking primarily for a software solution... >> >>I believe TGV multinet can handle this... > > MultiNet is, IMHO, far and away the best TCP/IP package available for > VAX/VMS. (This after reviewing products ranging from Process Software > to Fusion to Wollongong to...) It's a Stanford-bred product written > in C with some TOPS-20'isms in it. > > But I fail to understand the original question: "encapsulating DECnet > within TCP/IP". That just doesn't mean anything. I think what he means is sending DECnet packages inside of TCP/IP packets. I am using IP over DECnet right now. My TCP/IP packets are enclosed in DECnet packets, sent over our company DECnet and received by a machine that 'unwraps' them and then sends them off to the Internet. -- _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: fac2@dayton.saic.com uucp: dayvb!fac2 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112018065600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 03:12:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24041; Thu, 22 Nov 90 03:01:08 -0800 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 Nov 90 18:06:56 GMT From: cbmvax!grr@rutgers.edu (George Robbins) Organization: Commodore, West Chester, PA Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <15986@cbmvax.commodore.com> References: <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com>, <897@fred.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes: > grr@cbmvax.commodore.com (George Robbins) writes: > >In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: > >> We're interested in encapsulating DECnet within a TCP-IP package. We > >> are looking primarily for a software solution... > > > >I believe TGV multinet can handle this... > > But I fail to understand the original question: "encapsulating DECnet > within TCP/IP". That just doesn't mean anything. It could mean > buying... Usually enscapulation means that you have a network path that supports only one protocol, such as a point-to-point DECnet link, over which you would like to have packets for some other protocol such as TCP/IP pass transparently. This is pretty much the opposite of what a gateway does. Wollengong, Multinet and probably countless others handle the case of getting TCP through a VMS DECnet link, I assume that this person was interested in doing the opposite, trying to get a transparent DECnet link over an internet or other "TCP/IP" path. -- 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---- <1990112019090000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 03:58:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25941; Thu, 22 Nov 90 03:42:36 -0800 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 Nov 90 19:09:00 GMT From: csus.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!ut-emx!nic.the.net!don@ucdavis.ucdavis.edu (Donald L. Nash) Organization: University of Texas System Office of Telecommunication Services Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <1990Nov20.125225@nic.the.net> References: <897@fred.UUCP>, <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <897@fred.UUCP>, rbraun@polygen.uucp (Richard Braun) writes: >From: rbraun@polygen.uucp (Richard Braun) >Subject: Re: DECnet encapsulation in TCP-IP >Date: 19 Nov 90 20:01:53 GMT >Organization: Polygen Corporation, Waltham, MA > >grr@cbmvax.commodore.com (George Robbins) writes: >>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: >>> We're interested in encapsulating DECnet within a TCP-IP package. We >>> are looking primarily for a software solution... >> >>I believe TGV multinet can handle this... > >MultiNet is, IMHO, far and away the best TCP/IP package available for >VAX/VMS. (This after reviewing products ranging from Process Software >to Fusion to Wollongong to...) It's a Stanford-bred product written >in C with some TOPS-20'isms in it. I agree completely. We use MultiNet extensively here, and I couldn't get along without it. TGV also does a good job with technical support as well. But anyway, back to the business at hand: >But I fail to understand the original question: "encapsulating DECnet >within TCP/IP". That just doesn't mean anything. Perhaps a better way of saying this is "tunneling DECnet across an IP network". Here is an excerpt from the _MultiNet(tm)_System_Administrators'_Guide_ for MultiNet Version 2.2. This is the introductory paragraph for Chapter 5, found on page 5-1: A special DECnet device driver allows the MultiNet system manager to configure a DECnet line and circuit between two cooperating MultiNet systems across an arbitrary IP network. This special driver encapsulates DECnet packets in UDP datagrams for transportation via the IP protocols, much like VAX/PSI encapsulates DECnet packets in X.25 when doing Data Link Mapping. This was quoted without permission, but I'm sure the nice folks at TGV won't kill me for it. Hopefully, they won't sue me for it either. :-) I hope that clears the waters a bit. Donald L. Nash The University of Texas System Office of Telecommunication Services Internet: don@nic.the.net THEnet: THENIC::DON BITNET: DON@THENIC PSI Mail: 311051200131::DON ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112019351600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 04:43:05 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA28094; Thu, 22 Nov 90 04:28:52 -0800 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 Nov 90 19:35:16 GMT From: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Organization: Mathematics, Carnegie Mellon, Pittsburgh, PA Subject: SUMMARY:Router-Where to Start Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A public thanks to all who sent replies to my request for information on where to start researching an ip-router. Below are all of the replies: From: oleary@sura.net (dave o'leary) Date: Wed, 14 Nov 90 12:04:22 EST To: jk3n+@andrew.cmu.edu Subject: IP router implementation Hi - If you are interested in producing a true, full blown IP router, my advice is - don't. Unless you are willing to devote many man-months of your/your friend's/your employee's time. If you want basic functionality, i.e. RIP, read RFC 1058, and then RFC1009 (old router requirements) and then get the draft router requirements document and read that. Proxy arp is important, especially in the CMU environment, however if you are going to plug it into the real world you better talk to datacomm etc. first. (steve Waldbusser, walt wimer, tom holodnik). Also Matt Mathis can tell you a lot about proxy arp and how to do it right. Basically it is a lot of work, and there are more important problems that need to be solved beyond "yet another IP router".... hav efun dave ############################## Date: Wed, 14 Nov 90 11:12 PST From: rls@osa.com (Rich Scott) To: jk3n+@andrew.cmu.edu Subject: Re: IP Router-Where to Start? John, take a look at GateD - it's a PD IP routing daemon for Berkeley-type Unix machines, and is very well done. It handles multiple routing protocols (RIP, HELLO, EGP, BGP, and soon, OSPF), and is very well done. You can ftp it from devvax.tn.cornell.edu. There is also a "design notes" paper that talks about how it's designed to allow easy updates for new routing protocols. As far as RFCs go, rfc1058 is very good reading for learning RIP, and rfc1131 documents OSPF (the new replacement for RIP, and any other Interior Gateway Protocols). Uunet.uu.net has all the rfc's and a rfc-index in ~ftp/rfc. Finally, I highly recommend Douglas Comer's book "Internetworking with TCP/IP" - it describes the various routinog protocols very well, and is exceptionally well-written. Be sure to get the second edition - it has the white cover (the 1st ed. has a black cover). -rich --- rich scott rich@rx7.osa.com open systems architects 612 525-0000 minneapolis, mn ################### To: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Cc: barns@gateway.mitre.org Subject: Re: IP Router-Where to Start? Date: Wed, 14 Nov 90 15:37:13 -0500 From: barns@gateway.mitre.org RFC-wise, start with RFC 1009 "Requirements for Internet Gateways" and chase its references down. A revision of 1009 is in work in the IETF Router Requirements Working Group. There is a draft of the current state of the new document and it can be obtained through the normal Internet Drafts distribution sites. The specifics are attached below. The preface to the draft tells most of what you might want to know about the working group's plans and objectives and how one can have an influence on what is put into the document. This draft also has an updated list of references. The problem with it is that several sizable chunks have yet to be written. Bill Barns barns@gateway.mitre.org ######################## Date: Wed, 14 Nov 90 21:52 PST From: Denis DeLaRoca 825-4580 <@BITNET.CC.CMU.EDU:CSP1DWD@OAC.UCLA.EDU> (213) Subject: Re: IP Router-Where to Start? To: jk3n+@ANDREW.CMU.EDU (John Stephen Kalucki) Look at RFC-1009, it addresses the subject of routers directly, it is 2-3 years old and a lot of things have happened since. 1009 Braden, R.T.; Postel, J.B. Requirements for Internet gateways. 1987 June; 55 p. (Format: TXT=128173 bytes) (Obsoletes RFC 985) For packages that can do routing and you can test with, there are many, any BSD Unix host can do routing, look also at the PCROUTE, Ka9q, the CMU tcp/ip package, etc. -- Denis ##################### To: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Cc: barns@gateway.mitre.org Subject: Re: IP Router-Where to Start? Date: Thu, 15 Nov 90 07:45:00 -0500 From: barns@gateway.mitre.org Sorry, this got dropped from other message. /Bill ------- Forwarded Message Return-Path: Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2) id AA04720; Thu, 20 Sep 90 14:19:10 -0400 To: ietf@venera.isi.edu Subject: ID ACTION: draft-ietf-rreq-iprouters-00.txt Date: Thu, 20 Sep 90 10:04:32 -0400 From: mdavies@NRI.Reston.VA.US Message-Id: <9009201004.aa05617@NRI.NRI.Reston.VA.US> A New Internet Draft is available from the on-line internet-drafts directories. Title : Requirements for Internet IP Routers Author(s): Philip Almquist Filename : draft-ietf-rreq-iprouters-00.txt This draft attempts to define and discuss requirements for devices which perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as "routers". This document is intended to provide guidance for vendors, implementors, and purchasers of IP routers. Internet-Drafts are available by anonymous_ftp. Login with the username: anonymous and password: guest. After logging in, cd internet-drafts. Type "get " with the filename above to retrieve the draft. Internet-Drafts directories are located at: NSF Network Service Center Address: nnsc.nsf.net (192.31.103.6) Defense Data Network NIC Address: nic.ddn.mil (192.67.67.20) Pacific Rim Address: munnari.oz.au (128.250.1.21) Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are available by mail. Send a message to SERVICE@nic.ddn.mil with the subject: SEND INTERNET-DRAFTS:draft-ietf-rreq-iprouters-00.txt For questions, please mail to internet-drafts@nri.reston.va.us. ------- End of Forwarded Message ###################### Date: Thu, 15 Nov 90 08:53:10 PST From: postel@venera.isi.edu To: jk3n+@andrew.cmu.edu Subject: Re: IP Router-Where to Start? Cc: tcp-ip@venera.isi.edu Hi. Start with RFC-1009, and also get involved with the "router requirements working group" of the IETF. --jon. To: jk3n+@andrew.cmu.edu (John Stephen Kalucki) Cc: tcp-ip@nic.ddn.mil Subject: Re: IP Router-Where to Start? Date: Thu, 15 Nov 90 11:07:34 -0800 From: "Philip Almquist" John, > I'm thinking about implementing an IP router, but I have no idea where > to start. I've browsed through the RFC index and a few RFC's themselves, > but there doesn't appear to be anything directly related to routers. > > I'm looking basically for 4 things: > 1) Related RFC's There are a lot of of relevant RFCs. In addition to the router standard (RFC1009) that Jon Postel mentioned, there are several RFCs on the network layer (791, 792, 922, 950, 1112, 1122). And of course there ARP, all of the IP over mumble networks RFCs, routing protocols, SNMP, ... There is also a draft successor to RFC1009 which is available via anonymous FTP from NIC.DDN.MIL. Its name is: internet-drafts:draft-ietf-rreq-iprouters-00.txt > 2) Books and other text that might help Various good books, such as Comer's, provide a reasonably good introduction to TCP/IP. None that I know of teach nearly all of the things you'd need to know to implement a router. > 3) Public Domain implementations, hopefully source, to test mine with PCROUTE, KA9Q, and Berkeley UNIX are all reasonably easy to obtain, though I don't have details for any of them on the tip of my fingers. Additionally, various universities (MIT, CMU, Stanford, and probably others) have developed routers whose code is likely to be available if you can figure out who at those institutions has the authority to give it to you. One caveat, however: most if not all of the above are not fully compliant with RFC1009. > 4) Advice Don't underestimate the effort involved in building a router from scratch. You're talking man-years of effort to build even a minimally reasonable one. Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112021255200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 05:29:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00526; Thu, 22 Nov 90 05:19:34 -0800 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 Nov 90 21:25:52 GMT From: unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU (Ruth Milner) Organization: National Radio Astronomy Observatory, Socorro NM Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <1990Nov20.212552.2536@nmt.edu> References: <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com>, <897@fred.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes: >grr@cbmvax.commodore.com (George Robbins) writes: >>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: >>> We're interested in encapsulating DECnet within a TCP-IP package. We >>> are looking primarily for a software solution... >> >>I believe TGV multinet can handle this... > >MultiNet is, IMHO, far and away the best TCP/IP package available for >VAX/VMS. > >But I fail to understand the original question: "encapsulating DECnet >within TCP/IP". That just doesn't mean anything. > [...] >What's the need, anyway? Encapsulated DECnet is DECnet packets wrapped inside IP packets. To IP-only systems, the packets appear as normal TCP/IP and are routed accordingly. When they arrive at the destination (running MultiNet), the software strips off the TCP/IP stuff, finds a DECnet packet inside, and hands it off to DECnet for the real processing. As far as DECnet is concerned, a DECnet packet just came off the net. DECnet is very picky about nodes being "adjacent", i.e. directly reachable through some line or another. Under normal circumstances you would have to have DECnet nodes every step of the way to reach a remote system. With DECnet-over-IP, however, the IP-only node(s) in between are transparent to DECnet, and even though the two nodes could be miles apart, they appear to be adjacent. This can *enormously* simply configuring a wide-area DECnet, especially if there are existing links which only run TCP/IP. It also reduces the number of systems which must run DECnet; since most UNIX implementations (at least as of a year ago) cannot do routing between networks, encapsulating DECnet within IP can save your hide if you find you need to talk to some (DECnet) system a few UNIX routers/gateways away. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM rmilner@zia.aoc.nrao.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112022011600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 06:12:08 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02075; Thu, 22 Nov 90 05:54:15 -0800 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 Nov 90 22:01:16 GMT From: usc!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@apple.com (patrick k ferrick) Organization: SUNY Buffalo Subject: Looking for sources of mh V6.x Message-Id: <47199@eerie.acsu.Buffalo.EDU> References: <90324.114734DOUG@ysub.ysu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The subject, as they say, says it all: Anybody know where I can anonymously ftp the sources for mh? (Version 6.x would be nice) Thanks, Pat =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | ____ | | | /\T B\ Patrick K. Ferrick / KA2AYK | If Helen's beauty could | | / \E S\ ferrick@acsu.cc.buffalo.edu | launch 1000 ships, is one | | \ / / 219 Computing Center | millihelen enough beauty | | \/___/ State University of NY at Buffalo | to launch one ship????? | | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112022042800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 06:11:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02222; Thu, 22 Nov 90 05:58:02 -0800 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 Nov 90 22:04:28 GMT From: copper!hughes@iuvax.cs.indiana.edu (larry hughes) Organization: Indiana University, Bloomington IN. Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <73306@iuvax.cs.indiana.edu> References: <90313.134117JHL1@psuvm.psu.edu>, <15782@cbmvax.commodore.com>, <897@fred.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes: >grr@cbmvax.commodore.com (George Robbins) writes: >>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes: >>> We're interested in encapsulating DECnet within a TCP-IP package. We >>> are looking primarily for a software solution... >> >>I believe TGV multinet can handle this... > >MultiNet is, IMHO, far and away the best TCP/IP package available for >VAX/VMS. (This after reviewing products ranging from Process Software >to Fusion to Wollongong to...) It's a Stanford-bred product written >in C with some TOPS-20'isms in it. > >But I fail to understand the original question: "encapsulating DECnet >within TCP/IP". That just doesn't mean anything. It could mean > [etc.] DEC used to have a product called an "internet portal" which enveloped TCP/IP within DECnet. It was a hardware/software solution consisting of an Ultrix workstation at both ends (i.e. on two networks separated by a DECnet backbone) to handle the enveloping/de-enveloping. It's quite possible that they reversed this to envelope DECnet withing TCP/IP... //=========================================================================\\ || 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---- <1990112022295300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 05:08:55 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29844; Thu, 22 Nov 90 05:06:02 -0800 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 Nov 90 22:29:53 GMT From: ucivax!jromine@ucbvax.Berkeley.EDU (John Romine) Organization: UC Irvine Department of ICS Subject: Re: Looking for sources of mh V6.x Message-Id: <2749AE61.22009@ics.uci.edu> References: <90324.114734DOUG@ysub.ysu.edu>, <47199@eerie.acsu.Buffalo.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil ferrick@acsu.buffalo.edu (patrick k ferrick) writes: >The subject, as they say, says it all: Anybody know where I can anonymously >ftp the sources for mh? (Version 6.x would be nice) The short answer is ftp to ics.uci.edu:pub/mh and get mh-6.7.tar.Z. -- John Romine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112022392400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 05:29:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00785; Thu, 22 Nov 90 05:25:13 -0800 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 Nov 90 22:39:24 GMT From: nic.cerf.net!sss@ucsd.edu (Marlene M. Eckert) Organization: CERFnet, La Jolla, CA Subject: SLIP Help Message-Id: <229@nic.cerf.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello. My Task: Use a Sun 3/60 running Sun OS 4.1 to dial up to a regional net that connects to the Internet. Proposed solution: Use SLIP to permit me to telnet, ftp, and mail my heart out. Progress: I have SLIP installed and can start sliplogin. Netstat seems to see the connection, however I can't seem to ping any hosts. Questions: 1) The README distributed with SLIP mentions a special tip for SLIP that was not available. I am using Sun's standard version of tip to dial and establish the connection. I then start sliplogin in a second Suntools window. I assume (because I can't find it in any documentation) that the window that is running tip can be closed to an icon, and that I should be able to telnet, etc. from any other window. Is this correct or do I need another version of tip? 2) Obviously, I have not done this before. I think changes must be necessary to my Sun's databases and routing table. If so, what do I change? There is a ton of stuff that the Unix documentation discusses (/etc/hosts, /etc/networks, /etc/gateways, routed, etc.). Do I need to do anything special because the connection is not always up? I've tried experimenting (really hacking), now I'm askng the experts for help... All help would be appretiated. Thanks in advance. Please mail your responses directly to me at sss@cerf.net. If there seems to be interest I'll post a summary of the responses. Michael Reznick Structured Systems & Software (3S) Phone: (714) 830-3777 Mail : sss@cerf.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112022400000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Tue, 20 Nov 90 14:54:15 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id ae13382; 20 Nov 90 17:48 EST Date: Tue, 20 Nov 90 22:40 GMT From: Bob Stine <0004219666@mcimail.com> To: Armando Mac Beath Cc: TCP IP Subject: Re: Request for Generic Pinger software Message-Id: <52901120224025/0004219666NB1EM@mcimail.com> >>NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV >>(128.55.128.30). The distribution includes the following files: >> >> [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC (ASCII text) >> [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE (binary) >> [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA (ASCII text) > This host have a anonymous disallowed :( > Do you know how can get this package in another host or can you send me all > files !!!!!!!! Rats! Sorry, I don't have my own copy of the NPRV distribution. Thanks for the (unhappy) info. I'll investigate. - Bob Stine ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112118071600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 13:31:47 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02128; Fri, 23 Nov 90 13:21:27 -0800 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 Nov 90 18:07:16 GMT From: eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!dwight@bloom-beacon.mit.edu (Dwight Ernest) Organization: The IBM PC User Group, UK. Subject: Formation of the UK Internet Consortium Message-Id: <1990Nov21.180716.29399@ibmpcug.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Formation of the UK Internet Consortium London, 21 November 1990 Following years of mostly unfocused frustration about the lack of clear direction in the UK networking community toward the creation of a UK Internet, a group calling itself the UK Internet Consortium has been formed in the last few weeks. The group intends to either provide or to press for the timely and reasonable provision to UK customers of a network with connections to continental and inter- national Internets running the TCP/IP protocol suite. Consortium members said that the emphasis would be on UK management, UK-based service availability, reasonable prices, and cooperation with other network providers. All agreed that in the current climate of telecommunications deregulation, the time was ripe. Founding consortium members included representatives from the following UK firms: Unipalm Ltd., a Cambridge firm offering TCP/IP-based communications software; The Independent, a quality daily newspaper; Spider Systems Ltd., an Edinburgh-based company offering networking equipment; the Desktop Connection, a Manchester- based desktop publishing vendor and service provider; and Specialix Ltd., who design and manufacture third-party communi- cations equipment for the PC aftermarket. Both the Sun UK Users Group and the IBM PC Users Group were also represented, as were several private individuals with background and skills in computer networking. The consortium says it will be distributing a survey to gauge market potential and emphasized that all consortium members had signed an affidavit to the effect that responses would not be misused. They said that all aspects of the Data Protection Act would be strictly adhered to in the collection of responses. Approximately 30,000 survey copies would be printed, and they will be distributed through users groups mailings and company promotional mailings. Additionally, they said that surveys may be requested by sending email to ip-interest@independent.uucp or by posting a request to The UK Internet Consortium PO Box 360 Harrow HA1 4LQ They also mentioned that an electronic mailing list to facilitate discussion of the issues has been created. They have asked for subscription requests to be sent to ukipnet-request@independent.uucp -30- Please do not reply to the poster of this message, but to the ukipnet-request@independent.uucp address instead. -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. -- --Dwight Ernest (reply to dwight%independent.uucp@ukc.ac.uk) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112118122300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 07:27:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA06183; Thu, 22 Nov 90 07:19:04 -0800 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 Nov 90 18:12:23 GMT From: snorkelwacker.mit.edu!usc!samsung!munnari.oz.au!murdu!viccol!timcc@bloom-beacon.mit.edu (Tim Cook) Organization: Computer Services, Victoria College, Melbourne Subject: Re: Request: SLIP on a Sequent S27 (info on SLIP in general) Message-Id: <6492.274a7d38@csv.viccol.edu.au> References: <12073@bsu-cs.bsu.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <12073@bsu-cs.bsu.edu>, sam@bsu-cs.bsu.edu (B. Sam Blanchard) writes: > I would like to implement SLIP on a Sequent S27 running Dynix. > Dynix is 4.2bsd with many 4.3bsd enhancements. (yes, Dynix is much more) There is a freely available implementation of SLIP available for DYNIX. It does need to be built into the kernel, but instructions are supplied on how to do this, and you don't need DYNIX source code. We have been using it here for about 6 months, and it works fine, except it has crashed IP about a dozen times, which I think is another symptom of the poor terminal multiplexor drivers that are found on Sequents. You may have better luck than us, but we are going to start using a PC running PCroute soon. You can find the source to this in networking/Dynix.sl.tar.Z in uunet's anonymous FTP area, or send a message to info-sslip@riacs.edu for more information. -- The above message in no way represents the official opinion, policy or standing of Victoria College, or the Computer Services department of Victoria College. If things come unstuck, they will disavow any knowledge of my actions. This item will self-destruct in five disk-accesses. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112120192600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 12:26:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA21025; Thu, 22 Nov 90 12:15:48 -0800 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 Nov 90 20:19:26 GMT From: swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!samsung!umich!sharkey!ionic!gm@ucsd.edu (Greg Miller) Subject: Telnet's ECHO option Message-Id: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm in the midst of writing my own tcp/ip implementation, and have been caught up with what seems to be a problem - determining who exactly does any echoing in a telnet session. I've read the RFC covering the telnet ECHO option (RFC 857), and thought that I understood it. This explanation is an oversimplification, but shows the way I interpreted it: (There's no need to explain the need to respond to a "WILL/WONT" with a "DO/DONT" rather than the other-way-around; I'm fully aware of that, and make use of it. I don't include it here for simplification.) (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo each character I send to them. (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive an echo for each character sent. Part (1) above seems to fit properly. If I send the DO ECHO, the host happily echos everything back to me. However, part (2) doesn't seems to always apply - On varied pieces of equipment, it does what I expect - a DONT/WONT pair causes the host not to echo anything back. However, whenever I try this when I'm connected to a BSD machine, the host accepts my DONT ECHO, replies with WONT ECHO, and then procedes to continue echoing anyways. What gives? Am I interpreting things wrong? Is this option incorrectly implemented in some BSD revisions? -- +----------------------------------------------------------------+ | A sign of mismanagement, over- | Greg Miller | | complication and overall idiocy: | ..ames!sharkey!ionic!gm | | | gm@ionic.uucp | | "Designed By Committee" | | +----------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112201282300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 13:48:39 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25342; Thu, 22 Nov 90 13:41:15 -0800 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 Nov 90 01:28:23 GMT From: bacchus.pa.dec.com!mogul@decuac.dec.com (Jeffrey Mogul) Organization: DEC Western Research Subject: Re: DECnet encapsulation in TCP-IP Message-Id: <1990Nov22.012823.27507@wrl.dec.com> References: <15782@cbmvax.commodore.com>, <897@fred.UUCP>, <73306@iuvax.cs.indiana.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <73306@iuvax.cs.indiana.edu> hughes@copper.ucs.indiana.edu (larry hughes) writes: >DEC used to have a product called an "internet portal" which >enveloped TCP/IP within DECnet. It was a hardware/software >solution consisting of an Ultrix workstation at both ends >(i.e. on two networks separated by a DECnet backbone) to handle >the enveloping/de-enveloping. As far as I know, we still sell the Internet Portal. Quite a few are in use inside Digital. >It's quite possible that they reversed this to envelope DECnet >within TCP/IP... Not that I know of. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112203073600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 14:12:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26125; Thu, 22 Nov 90 13:56:22 -0800 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 Nov 90 03:07:36 GMT From: uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!nodecg!adrienne@ames.arc.nasa.gov (adrienne byrd 4208172) Organization: Network Computer Centre - Telecom WA Subject: Telnet option negotiation Message-Id: <1990Nov22.030736.9710@nodecg.ncc.telecomwa.oz.au> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil For some time now we have been curious about what we think are called "telnet options". We are using NCSA Telnet 2.2 to talk to Xenix boxes with Excelan's LAN WorkPlace package. I've noticed that when running NCSA Telnet I often get "telnet option 254 1" type messages. Further investigation in the Excelan manuals reveals that there is a "telnet command" iac n1 n2 ... where n1, n2 specifiy the decimal number of the command. The manual gives the example iac 254 1 as being the equivalent of telnet's DONT ECHO command. Could someone please post a list of these such numbers and what they mean in telnetese? Thank you in advance. Adrienne Byrd Network Computer Centre, Telecom Australia, WA ACSNET: adrienne@telecomwa.oz Internet: adrienne%telecomwa.oz@uunet.uu.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112203104100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 05:02:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA13047; Wed, 28 Nov 90 04:59:54 -0800 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 Nov 90 03:10:41 GMT From: eru!hagbard!sunic!mcsun!tuvie!edvvie!eliza!schweigl@bloom-beacon.mit.edu (Johnny Schweigl) Organization: Edv GesmbH, Austria/Europa Subject: need URGENT help with SCO UNIX TCP/IP - please Message-Id: <257@eliza.edvvie.at> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are currently encountering a major problem with no idea how to solve it. Machine configuration is as follows: Hardware: COMPAQ Systempro two 386/33 CPU boards 12 MB mem 1.6 GB Disk, configured for data guarding 3COM Etherlink II network adapter Adaptec SCSI controller GIGATAPE DAT streamer SCO UNIPATH SDLC comms board Computone controller with 1 Async feature box attached Software: SCO UNIX 3.2 Runtime TCP/IP 1.1.1 Runtime SCO (Corollary) MPX COMPAQ EISA supplement Operating environment: Machine serves as time accounting system with industrial terminals connected via RS232. Users (>25) telnet from WANG VS (great, BTW) to SCO box, using accounting software. 32 pty's are configured into the kernel (maximum allowed by TCP/IP). C2 security mode is relaxed (from sysadmsh). Error: After entering userid and passwd (telnet session is ok) SCO UNIX responds with "Cannot obtain database information on this terminal". when logging on as root on /dev/console, the system tells me that "The security databases are corrupt". No new logins are allowed after this error had occured. The error seems to have no systematic behaviour. It appears at random points in time, with 3 telnet sessions or 20, or something like that. RTFM: SCO TCP/IP release notes predict this error if pty's and vty's are not correctly configured. Nope. As far as I can see I did it right. Simply followed the instructions in the manual. No further reference to this error in the complete runtime docs. Also, the TCP/IP manual says, that if streams ressources are insufficient, unpredictable errors. Possible sources of error: Someone modified /etc/passwd manually. System will be reinstalled completely this weekend. If this was the only problem, shouldn't the error occur permanently? Quite contrary, it is not reproducible. Actions taken so far: Analyzed streams ressource usage with crash and strstat subcommand, reconfigured kernel. Should now be sufficient. Ran a brute force test with 32 concurrent telnets and some parallel ftp's. Error did not occur. Next day, error occured 8 times. One day later 3 times, and so on ... Problem: Angry users wanting to tear our heads off. So if you know any solution, or if this is a known error, corrected in release x.y.z pleeeaaase tell me. Thanks in advance, -- This does not reflect the | Johnny Schweigl opinions of my employer. | USENET: schweigl@edvvie.at I am busy enough by talking | about my own ... | EDVG Vienna/Europe, Tel (+43 222) 59907-0 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112208010200> Received: from csli.Stanford.EDU by NIC.DDN.MIL with TCP; Thu, 22 Nov 90 15:57:43 PST Received: by csli.Stanford.EDU (4.1/inc-1.0) id AA24015; Thu, 22 Nov 90 16:01:04 PST Date: Thu, 22 Nov 1990 16:01:02 PST From: Ole J. Jacobsen To: TCP-IP@NIC.DDN.MIL Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular) Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home) Subject: Re: High-Speed Networking Message-Id: Several articles on high speed networking appear in the October 1990 issue of ConneXions. There is an article on FDDI, one on SMDS (with references to ATM and SONET), and one on Gigabit Networking. Also, there is an article on ISDN, if you can call that "high speed" :-) Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, USA Phone: (415) 941-3399 FAX: (415) 949-1779 Email: ole@csli.stanford.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112214561600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 15:00:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05737; Fri, 23 Nov 90 14:34:23 -0800 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 Nov 90 14:56:16 GMT From: eru!hagbard!sunic!mcsun!tuvie!acmis!joe@bloom-beacon.mit.edu (Johannes Rupp) Organization: Coordinated Management Information Systems / NIELSEN Company Subject: Interlan TCP/IP Novell Gateway SMTP Problem Message-Id: <1990Nov22.145616.10175@acmis.cmis.co.at> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We have a problem getting the SMTP mail connection running between our INTERLAN TCP/IP Novell Gateway and any other computer running TCP/IP. Our Novell configuration is as: Advanced Netware 286 V2.15 Interlan TCP/IP gateway with the NP600G board installed Interlan TCP/IP gateway software V1.4 The Interlan TCP/IP gateway is installed in the Novell server. Our problem: 1.) Sending mails via SMTP from a UNIX host (also using TCP/IP) and an IBM host (again using TCP/IP via an IBM3172 controller) to the Novell server (via the Interlan TCP/IP gateway) works fine. 2.) Sending mails from a PC workstation in the Novell network using the Interlan MAILWS program (part of the Interlan TCP/IP gateway software distribution) to either the UNIX host or the IBM host fails. Watching the network traffic uncovers the following situation: Interlan TCP/IP gateway UNIX host sends TCP/IP packet sends TCP/IP packet ======================= ======================== initiates a connection to UNIX host 220 acmis.cmis.co.at Sendmail ready at ... HELO * ^ | | How can I change the Interlan TCP/IP gatway configuration to make the gateway sending out the actual TCP/IP gateway hostname instead of the '*' character? - In any mail received by the UNIX host the return address is always build up as username@* I guess the '*' in the domain name instead of the host name comes from the HELO * of above. - Sending mails to the IBM host is even impossible as the MAILSW program immediately returns with the messages: Trying to connect to dpcenter.cmis.co.at... Syntax Error. Start Domain with 'a'..'z' or 'A'..'Z' Connection to remote host failed. Mail saved in "SYS:MAIL/B70187\DEAD.LET" In this case it won't send no mail at all to the IBM host Also in this case the TCP/IP Interlan gatway sends a HELO * packet to the IBM host. The only difference is that the IBM implementation of TCP/IP refuses to accept the * instead of a hostname completely. Sending mails between the IBM and UNIX hosts works in both directions. My guess is that we have missed something during the installation of the Interlan TCP/IP gateway software. What I would like to know is just what we missed. Any help is welcome. Best regards, Johannes -- +------------------------------------------------------------------------+ | CMIS Austria | Voice: (++43-222) 98 109 Ext. 110 | | NIELSEN Austria | Voice: (++43-222) 98 110 Ext. 110 | | Moeringgasse 20 | Fax: (++43-222) 98 110 77 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112215523000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 14:40:04 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05595; Fri, 23 Nov 90 14:31:22 -0800 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 Nov 90 15:52:30 GMT From: eru!hagbard!sunic!mcsun!hp4nl!nikhefh!a20@bloom-beacon.mit.edu (Marten Terpstra) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: high speed networking Message-Id: <1067@nikhefh.nikhef.nl> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi all, Maybe this is not the most appropriate newsgroup but here goes. I am looking for any information on high speed networking products and projects. Possible names are : FDDI, UltraNet, HIPPI, ATM, SONET and projects like AURORA, CASA, JPL, VISTA, NECTAR. Any pointers, hints are appreciated. Preferably technical descriptions. Thanks, Marten -- Marten Terpstra National Institute for Nuclear Internet : terpstra@nikhef.nl and High Energy Physics Oldie-net: {....}mcsun!nikhefh!terpstra (NIKHEF-H), PO Box 41882, 1009 DB Phone : +31 20 592 5102 Amsterdam, The Netherlands ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112302371800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 16:10:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09282; Fri, 23 Nov 90 15:57:49 -0800 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 Nov 90 02:37:18 GMT From: usc!samsung!munnari.oz.au!mel.dit.csiro.au!latcs1!wcc!tom@ucsd.edu (Tom Evans) Organization: Webster Computer, Melbourne, Australia Subject: AMD LANCE - How to Tell Versions? Message-Id: <1178@wcc.oz> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I need to write some code that will detect and warn of old versions of the AMD AM7990 LANCE chip, particularly very old (1984) Rev A and Rev B versions. Does anyone have any code examples that can do this, or knows of any chip differences that can be detected from software? We've found that AppleTalk Phase 2 won't run on Rev A and B chips - a problem to do with Multicast address recognition. Loopback testing doesn't seem to show it however (dammit!). Please mail responses (as well/instead of posting - your choice). Thanks. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112308022500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 16:29:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10425; Fri, 23 Nov 90 16:25:48 -0800 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 Nov 90 08:02:25 GMT From: eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun7!conti@bloom-beacon.mit.edu (Giovanni Conti) Subject: Re: Telnet's ECHO option Message-Id: <1191@disuns2.epfl.ch> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , gm@ionic.UUCP (Greg Miller) writes: > > (There's no need to explain the need to respond to a "WILL/WONT" with a > "DO/DONT" rather than the other-way-around; I'm fully aware of that, and > make use of it. I don't include it here for simplification.) > > (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo > each character I send to them. I think there is a need to explain the WILL/WONT mechansim. The ECHO is LOCAL. So if you ask your partner to do echo, he will duplicate his output stream (from him to you) onto his input stream. That means that a UNIX system doing Telnet echo and sending you a "Username:" string will also read the same string in its input stream. So obviously, the UNIX system never does Telnet echo locally. On the other side, you (e.g. the terminal) are expected to do some local echo of the keyboard input to the screen (echo your input stream to your output stream). If the system does not want you to do that (e.g. when you type the password), it tells you DONT ECHO, which means "Just send me the characters, I will echo back what I think is reasonable". In that case you do not echo the characters locally on your screen. If you ask the host to do ECHO, and assuming he answers WILL ECHO, that means that when he sends you the string "Username:", telnet echoes him a copy as if you've typed "Username:", leading to wrong behaviours. So don't tell the host to do local echo (local to him) if you are a Telnet Client (or unless you know exactly what you're doing). > > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > an echo for each character sent. > So this is wrong. But fortunately, according to your request, the BSD host will not read in its input stream all the characters it sent to you. > Part (1) above seems to fit properly. If I send the DO ECHO, the host > happily echos everything back to me. However, part (2) doesn't seems to > always apply - > The fact of echoing everything back to you means: a) that you did not do local echo in the beginning (unless you received all duplicated characters. So there is an error in your Telnet implementation. b) That the Application echo (e.g. the login deamon on a host) has NOTHING to do with your Telnet echo commands. In fact, the application running on top of telnet (e.g. csh) may echo back things, asking you first NOT to do local echo (so you receive a DONT ECHO from the host). Good luck Giovanni Conti Ecole Polytechnique Federale de Lausanne Laboratoire de Teleinformatique EL-Ecublens CH-1015 Lausanne Switzerland Tel : +41 21 693.29.07 FAX : +41 21 693.46.60 E-mail: conti@ltisun.epfl.ch ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112311151500> Received: from hawk.nstn.ns.ca by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 07:19:17 PST Date: Fri, 23 Nov 90 11:15:15 GMT Message-Id: <1629@hawk.nstn.ns.ca> From: richards@hawk.nstn.ns.ca (Mark Richardson) Reply-To: richards@hawk.nstn.ns.ca To: tcp-ip@sri-nic.arpa Subject: Telnet, FTP, Mail and News for DOS My boss recently tasked me with locating the *optimal* package that would provide the following functionality to our customers on a dial-up basis: - Telnet - FTP - Mail reader service (a la POP, PCMAIL, IMAP) - News reader I realize that Telnet and FTP are no problem through dial-up; it is more of a concern for the other two. We want to run this 'package' over either SLIP or preferably a class 6 packet driver thus not neccesitating the use of a dedicated on-site server. The customers machines are DOS machines, which precludes a wide variety of choices. If there is anyone out there who has had to solve a similar problem or you think you have the answer (even if you sell the answer) please drop me a note. Any help would be greatly appreciated (I should warn you that I am rather new to networking, thus I may appear to be somewhat lacking in brain cells). You can get me at the E-mail address below. If there is lots of interest, I will be happy to summarize for the net. Good Day, Eh Mark ****************************************************************** * Mark Richardson Software Kinetics Ltd * * Project Engineer 101 Ilsley Ave * * E-mail - richards@hawk.nstn.ns.ca Suite 5 * * Phone (902)468-3680 Dartmouth N.S. Canada * * Fax (902)468-3679 B3B 1S8 * * * * If I should happen to be quoted, Software Kinetics Limted * * will disavow any knowledge of my existance and I shall self * * destruct ....... oh, I don't know .... maybe after lunch * * * ****************************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112314535800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 19:27:18 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15759; Fri, 23 Nov 90 19:26:46 -0800 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 Nov 90 14:53:58 GMT From: eru!hagbard!sunic!mcsun!ukc!stl!neil@bloom-beacon.mit.edu Organization: STC Technology Limited, London Road, Harlow, Essex, UK Subject: Reducing the risks when conencting to an internet Message-Id: <3768@stl.stc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We are starting the planning process to connect our large internal network to an internet. We wish to reduce the risk of unwanted external vistors as far as possible, whilst allowing our internal users access to other hosts. One possibility is to acquire a device to sit between our backbone and the outside world. This device would be programmable so that I could authorise connections on a per host, per port, per direction basis. So, for example I have network 128.199, I could have an authorisation file like:- # Source Dest Comment # host.port host.port *.smtp mymailgw.smtp Mail service inbound mymailgw.smtp *.smtp Mail service outbound 128.199.200.*.ftp *.ftp FTP 128.199.200.*.telnet *.telnet Telnet So, from the above, my mail gateway could send out to anybody, and anybody can send to my mail gateway (and no where else). Any machine on my local 200 subnet can ftp or telnet to anywhere, but no inbound conenctions are allowed. Is this possible, or are we thinking in completely the wrong way ? At this stage it isn't necessary that the device exists in the UK, we can import if necessary. The device probably needs to understand name servers as well. We also have an eye on the future, so the Vendor would need to offer support for OSI protocols. Neil Todd | ..In general, it is best to assume that the PSI%234237100122::neil | network is filled with malevolent entities neil@stl.stc.co.uk | that will send in packets designed to have STC Technology Ltd | the worst possible effect... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112315202200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 20:11:46 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16162; Fri, 23 Nov 90 19:48:51 -0800 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 Nov 90 15:20:22 GMT From: eru!hagbard!sunic!mcsun!ukc!icdoc!syma!nickw@bloom-beacon.mit.edu (Nick Watkins) Organization: University of Sussex Subject: Thanks [Re: tftp needed for HP9000/835] Message-Id: <3861@syma.sussex.ac.uk> References: <3841@syma.sussex.ac.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil From article <3841@syma.sussex.ac.uk>, by nickw@syma.sussex.ac.uk (Nick Watkins): > We have an X terminal which needs to use trivial ftp to download the X binary > from an HP9000/835. tftp is not included in the TCP-IP software suite > provided with HP-UX (LAN 9000), has anybody got a suitable (source or > binary) version of tftp that we could have ? Many thanks to all who responded, tftp now running on our HP. Nick -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112316560400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 17:13:15 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA11672; Fri, 23 Nov 90 16:54:22 -0800 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 Nov 90 16:56:04 GMT From: eagle!news@ucbvax.Berkeley.EDU (Steven Eubanks) Organization: NASA Lewis Research Center Subject: Netbios/TCP P/M-node implementations Message-Id: <1990Nov23.113158@osprey.lerc.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Continuing my quest for more NetBIOS over TCP information... (Sorry, I'm kind of new to this RFC1001/1002 business) Are there any commercially/PD implementations of P-node or M-node NetBIOS servers/clients?? All the implementations I've seen so far seem to use B-nodes. I suppose that I'm also interested in knowing about NetBIOS name server (NBNS) and datagram distribution (NBDD) implementations as well. Thanks in advance, Steve -- Steven W. Eubanks, EDS/LIMS NASA Lewis Research Center Internet:xxseub@osprey.lerc.nasa.gov 21000 Brookpark Rd. (216)433-8498 Cleveland, OH 44135 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112320011000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 23 Nov 90 17:25:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA12660; Fri, 23 Nov 90 17:14:52 -0800 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 Nov 90 20:01:10 GMT From: jpusa1.chi.il.us!stu@gargoyle.uchicago.edu (Stu Heiss) Organization: JPUSA - Chicago, IL Subject: advise on ethernet card for T5100 wanted Message-Id: <1990Nov23.200110.13223@jpusa1.chi.il.us> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I have SCO TCP/IP running on my toshiba T5100 and connect with slip to the office machine. I'm in need of advise on an ethernet card that will work with the toshiba. Toshiba does sell a card for the 5100, although I don't know whose it is. Does anyone have any experience with the T5100 and ethernet? SCO TCP/IP provides drivers for the wd8003e, 3c501, 3c503, and an unsupported one for the 3c523. Thanks in advance, Stu -- Stu Heiss - stu@jpusa1.chi.il.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112405201500> Received: from clouso.crim.ca by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 07:20:17 PST Received: by clouso.crim.ca (5.57/Ultrix3.0-C) id AA09204; Sat, 24 Nov 90 10:15:54 EST Received: from macgyver.crim.ca.crim.ca by bond.crim.ca (4.0/SMI-4.0) id AA03563; Sat, 24 Nov 90 10:20:15 EST Date: Sat, 24 Nov 90 10:20:15 EST From: boudreau@bond.crim.ca (Guy Boudreault) Message-Id: <9011241520.AA03563@bond.crim.ca> To: tcp-ip@nic.ddn.mil please remove my name from your mailing list. Thanks ------------------------------------------------------------------------------- Guy Boudreault | Centre de recherche informatique de Montreal (CRIM) Analyste de systeme (UNIX)| 3744 rue Jean-Brillant, bureau 500 | Montreal (Quebec) Canada H3T 1P1 | tel: +1 514 340 5754 / fax: +1 514 340 5777 ------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011241324.AA25175@ucbvax.Berkeley.EDU] <1990112411311900> From: BINGZHI%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU (Bingzhi Li) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP Channel Problem Message-ID: <9011241324.AA25175@ucbvax.Berkeley.EDU> Date: 24 Nov 90 11:31:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 Posted: Sat Nov 24 12:31:19 1990 Hi, all. I am working o TCP/IP, to develop the interactive file accessing system between IBM/VM and VAX/VMS hosts. The problem is how to deal with the virtual channel if the client process asking files from the remote hosts will take a long time. One solution is that client waits for the requested files coming after sending the request commands. Another is that the client don't wait for the files coming, and quit the interactive accessing state (but the channel is alive), after sending the request commands. How to deal with this problem if the waiting time is very long ? I think someone have the experience on this problem. Wish to hear from some good ideas. Thank you in advance ! Bingzhi LI +=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CCCCC N N U U CCCCC EEEEE C N N N U U C E ______ C N N N U U C EEEEE TTTTTT C N N U U C E :::::: CCCCC N N UUUUU CCCCC EEEEE ========== TTTTTTTTT ::::::::: Bingzhi Li ========== Institute of CNUCE TTTTTTTTT National Research Council ::::::::: 36 Via S. Maria, Pisa, Italy ========== Voice: +39 50 593343 TTTTTTTTT h =(1/2)*g*t**2 Fax: 50 576751 ::::::::: Email: bingzhi@icnucevm.cnuce. ============ cnr.it =-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=-=-=-=-=-=-=-=-==-=-=-===-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112413311900> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 03:32:10 PST Received: from ICNUCEVM.CNUCE.CNR.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4509; Sat, 24 Nov 90 06:31:24 EST Received: from ICNUCEVM.CNUCE.CNR.IT (BINGZHI) by ICNUCEVM.CNUCE.CNR.IT (Mailer R2.07) with BSMTP id 1341; Sat, 24 Nov 90 12:32:09 MET Date: Sat, 24 Nov 90 12:31:19 MET From: Bingzhi Li Subject: TCP/IP Channel Problem To: All Hi, all. I am working o TCP/IP, to develop the interactive file accessing system between IBM/VM and VAX/VMS hosts. The problem is how to deal with the virtual channel if the client process asking files from the remote hosts will take a long time. One solution is that client waits for the requested files coming after sending the request commands. Another is that the client don't wait for the files coming, and quit the interactive accessing state (but the channel is alive), after sending the request commands. How to deal with this problem if the waiting time is very long ? I think someone have the experience on this problem. Wish to hear from some good ideas. Thank you in advance ! Bingzhi LI +=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CCCCC N N U U CCCCC EEEEE C N N N U U C E ______ C N N N U U C EEEEE TTTTTT C N N U U C E :::::: CCCCC N N UUUUU CCCCC EEEEE ========== TTTTTTTTT ::::::::: Bingzhi Li ========== Institute of CNUCE TTTTTTTTT National Research Council ::::::::: 36 Via S. Maria, Pisa, Italy ========== Voice: +39 50 593343 TTTTTTTTT h =(1/2)*g*t**2 Fax: 50 576751 ::::::::: Email: bingzhi@icnucevm.cnuce. ============ cnr.it =-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=-=-=-=-=-=-=-=-==-=-=-===-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112416394100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 11:31:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29340; Sat, 24 Nov 90 11:21:20 -0800 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 Nov 90 16:39:41 GMT From: att!emory!stiatl!srchtec!srchtec.uucp@ucbvax.Berkeley.EDU (Michael Almond) Organization: search technology, inc. Subject: Internet Access Costs Message-Id: <315@srchtec.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We were recently discussing the cost of connecting to the internet. Someone mentioned a magic number of $100 per month to connect to the net. The lowest price I had found at the time was a SLIP connection to PSInet for $250. We'll David Smith from PSI gave me a call earlier this week to let me know, due to some cost reductions in hardware, they will be offering SLIP connections to PSInet for $150 a month. This deal will only last until the end of the year though. I suppose they are testing the water to see if price really does effect their market. Anyway, we are definitely going with PSInet. The Atlanta POP will be up sometime in January and I can let you everyone know what SLIPing is like on the internet. The only bad aspect of SLIPing I can see so far is that PSInet will not call us when they see packets with our address in them. However, our LAN will call PSInet because we're using a NetBlazer. One other item: PSI says we will not have a constant IP #. It supposedly changes each time we establish a connection with them. However, our address will remain constant (probably searchtech.com). I'm hoping this will not cause too many problem with our local setup, but I guess we're going to find out! --- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. emory!stiatl!srchtec!mra Atlanta, Georgia (404) 441-1457 (office) [search]: Systems Engineering Approaches to Research and Development ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112500115300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 16:27:25 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA04340; Sat, 24 Nov 90 16:13:34 -0800 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 Nov 90 00:11:53 GMT From: zaphod.mps.ohio-state.edu!think.com!barmar@tut.cis.ohio-state.edu (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Subject: Re: Reducing the risks when conencting to an internet Message-Id: <1990Nov25.001153.29911@Think.COM> References: <3768@stl.stc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3768@stl.stc.co.uk> neil@stl.stc.co.uk () writes: >So, for example I have network 128.199, I could have an authorisation >file like:- > ># Source Dest Comment ># host.port host.port > >*.smtp mymailgw.smtp Mail service inbound >mymailgw.smtp *.smtp Mail service outbound >128.199.200.*.ftp *.ftp FTP >128.199.200.*.telnet *.telnet Telnet The source port for connections is generally *not* the protocol's well-known port. The well-known port is normally only used as the destination port. The source port is usually a random port above 1024. >Is this possible, or are we thinking in completely the wrong way ? >At this stage it isn't necessary that the device exists in the UK, >we can import if necessary. cisco Gateway Servers can do packet filtering based on addresses and port numbers. >We also have an eye on the future, so the Vendor would need to offer >support for OSI protocols. cisco supports OSI protocols, although it doesn't yet seem to support them in its filtering specifications. It will probably come at some time, thoug. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112500564200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 17:43:46 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05568; Sat, 24 Nov 90 17:25:28 -0800 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 Nov 90 00:56:42 GMT From: sdcc6!jclark@ucsd.edu (John Clark) Organization: University of California, San Diego Subject: Re: Internet Access Costs (or SLIPped connections) Message-Id: <14453@sdcc6.ucsd.edu> References: <315@srchtec.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes: >We were recently discussing the cost of connecting to the internet. Someone >mentioned a magic number of $100 per month to connect to the net. The lowest >price I had found at the time was a SLIP connection to PSInet for $250. I have some questions about PSInet. Does anyone know the answer to the following: 1) Does it exist in Southern California? 2) If it does are there one time charges and then monthly plus connect charges? 3> Does one's SLIPped Internet number change from one connect to another. Or can one have an assigned Internet number for Mail etc. -- John Clark jclark@ucsd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112502024300> Received: from psi.com by NIC.DDN.MIL with TCP; Sun, 25 Nov 90 07:25:55 PST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA02279; Sun, 25 Nov 90 10:22:44 -0500 Message-Id: <9011251522.AA02279@psi.com> To: sdcc6!jclark@ucsd.edu (John Clark) Cc: tcp-ip@nic.ddn.mil Subject: Re: Internet Access Costs (or SLIPped connections) In-Reply-To: Your message of 25 Nov 90 00:56:42 +0000. <14453@sdcc6.ucsd.edu> Date: Sun, 25 Nov 90 10:22:43 -0500 From: "Martin Lee Schoffstall" In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes: >We were recently discussing the cost of connecting to the internet. Someone >mentioned a magic number of $100 per month to connect to the net. The lowest >price I had found at the time was a SLIP connection to PSInet for $250. I have some questions about PSInet. Does anyone know the answer to the following: 1) Does it exist in Southern California? LA 2) If it does are there one time charges and then monthly plus connect charges? One time charge of $150. 3> Does one's SLIPped Internet number change from one connect to another. Or can one have an assigned Internet number for Mail etc. Mail is handled by {uucp,pcmail,pop} protocols and MX records, its not an issue. John Clark jclark@ucsd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112503203500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 24 Nov 90 19:28:14 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07350; Sat, 24 Nov 90 19:23:30 -0800 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 Nov 90 03:20:35 GMT From: cs.utexas.edu!usc!jerico.usc.edu!kmeyer@tut.cis.ohio-state.edu (Kraig R. Meyer) Organization: University of Southern California, Los Angeles, CA Subject: Re: Reducing the risks when conencting to an internet Message-Id: <28376@usc> References: <3768@stl.stc.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <3768@stl.stc.co.uk>, neil@stl.stc.co.uk writes: |>...We wish to reduce the risk of unwanted external vistors |>as far as possible, whilst allowing our internal users access to other |>hosts. |> |>One possibility is to acquire a device to sit between our backbone and |>the outside world. This device would be programmable so that I could |>authorise connections on a per host, per port, per direction basis. Depending on how much isolation you want from the outside world, another option (besides using filtering at the TCP/IP level in a router) is to use a unix box as an application level gateway. This is definitely an inconvenience to your users, which may or may not be a good thing depending on what your isolation goals are and how paranoid you are. For example, you can configure sendmail to forward mail in both directions and then only give accounts on the gateway unix machine to those people who you want to allow ftp/telnet/etc access to the outside network. That makes access on a per-person basis, rather than on a per-IP-address basis. Filtering in the way you've described would not, for example, prevent an internal user from spoofing IP addresses (if that is an issue). --------------------------------------------------------------------------- | Kraig R. Meyer kmeyer@usc.edu | | University of Southern California Los Angeles | --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112518260000> Received: from srlvx0.srl.ford.com by NIC.DDN.MIL with TCP; Sun, 25 Nov 90 20:37:48 PST Date: 25 Nov 90 23:26:00 EST From: "Jerry Damian" Subject: Reducing the risks when connecting to an internet To: "tcp-ip" In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to filter on specific IP services such as TELNET, SMTP, FTP, etc. You can use Cisco routers to do this quite effectively. You can use their extended access controls to filter on source and destination address as well as port number. However, be aware that the Cisco ability to process packets without dropping any is proportional to the size of the access list. You can minimize the size of the lists by permitting/denying packets by subnet rather than by IP address. Better to put this burden on a router than a host that is probably used for something else... Jerry Damian Ford Motor Co. damian@srlvx0.srl.ford.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112522020000> Received: from relay.CDNnet.CA by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 13:46:43 PST Received: by relay.CDNnet.CA (4.1/1.14) id AA00770; Mon, 26 Nov 90 13:46:40 PST From: Date: 26 Nov 90 11:22 -0800 To: tcp-ip@nic.ddn.mil Message-Id: <9011261922.AA16501@cs.sfu.ca> Subject: R please remove my name from your mailing list ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112600052300> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 09:24:29 PST Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA29860; Mon, 26 Nov 90 09:24:09 PST Received: by nms. (4.0/SMI-4.0) id AA03141; Mon, 26 Nov 90 07:05:24 PST From: anthony@nms.hls.com (Anthony Chung) Message-Id: <9011261505.AA03141@nms.> Subject: TELNET Option To: tcp-ip@nic.ddn.mil Date: Mon, 26 Nov 90 7:05:23 PDT X-Mailer: ELM [version 2.2 PL0] Hughes LAN System Terminal server will negotiate TELNET option 222 to find out if the remote host is also Hughes LAN System Terminal server. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112600540700> Received: from hls.com (LANSLIDE.HLS.COM) by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 10:13:15 PST Received: from nms. (nms.hls.com) by hls.com (4.0/SMI-4.0) id AA00634; Mon, 26 Nov 90 10:12:54 PST Received: by nms. (4.0/SMI-4.0) id AA03379; Mon, 26 Nov 90 07:54:08 PST From: anthony@nms.hls.com (Anthony Chung) Message-Id: <9011261554.AA03379@nms.> Subject: TELNET ECHO option negotiation To: tcp-ip@nic.ddn.mil Date: Mon, 26 Nov 90 7:54:07 PDT X-Mailer: ELM [version 2.2 PL0] Most of TELNET implementations have implemented TELNET echo option correctly. But, interfaces between TELNET and applications which use TELNET are not implemented correctly. Echo may come from applications even TELNET WON't ECHO. For examples: 1. A word processor software which interfces with TELNET layer may not know about result of ECHO negotiation. 2. A host may not know anything about TELNET negotiations when TELNET code resides in a intelligent Ethernet controller. 3. A host does not even know about TELNET when it connnects to a TCP/IP terminal server over RS232. These problems exist for other options too, such as Binary option. I think all these problems are local implementation issue. I also have found problem which some TELNET implementations do not follow TELNET End-Of-Line convention. I also found SUN OS(at least version 4.0.3) still expects Supress Go Ahead negotiation to get out line mode. "Host Requirements" RFC specifies that server TELNET SHOULD NOT support sending GA commands. Sometimes I wonder that I should follow RFC or not. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112601115600> Received: from venera.isi.edu by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 09:12:28 PST Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Mon, 26 Nov 90 09:12:22 -0800 Date: Mon, 26 Nov 90 09:11:56 PST From: postel@venera.isi.edu Posted-Date: Mon, 26 Nov 90 09:11:56 PST Message-Id: <9011261711.AA06068@bel.isi.edu> Received: by bel.isi.edu (4.1/4.0.3-4) id ; Mon, 26 Nov 90 09:11:56 PST To: tcp-ip@nic.ddn.mil, uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!nodecg!adrienne@ames.arc.nasa.gov Subject: Re: Telnet option negotiation Re: Telnet Options Please see RFC 1060 page 51 for a list of Telnet Options and pointers to the other RFC that document them. --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112601132400> Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 09:13:48 PST Received: from berserkly.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY2.2) id AA15004; Mon, 26 Nov 90 11:13:46 CST Received: by berserkly.cray.com id AA00449; 5.64/CRI-4.9; Mon, 26 Nov 90 11:13:24 -0600 Date: Mon, 26 Nov 90 11:13:24 -0600 From: dab@berserkly.cray.com (David Borman) Message-Id: <9011261713.AA00449@berserkly.cray.com> To: eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun7!conti@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil Subject: Re: Telnet's ECHO option Before things get out of hand, here is some clarification about the telnet ECHO option. The response to the original question is WRONG!!!. From the original questions: > (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo > each character I send to them. This is exactly correct. > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > an echo for each character sent. This is also exactly correct. > Part (1) above seems to fit properly. If I send the DO ECHO, the host > happily echos everything back to me. However, part (2) doesn't seems to > always apply - The only reason that either part (1) or part (2) would not work is due to a broken telnet implementation. Now for some clarification about how the telnet ECHO option shoule be used, in the typical "terminal/client to server". First, there are two pieces of information involved: 1) should the users typed data be echoed to the users screen, and 2) is the server WILL ECHO or WONT ECHO. 1) The connection should NEVER be WILL ECHO in both directions. In the typical terminal/client to server application, there is no need for the client to ever be WILL ECHO. 2) When the server is WONT ECHO, then if the users typed data is to be echoed to the users screen, then that has to be done locally on the server side. 3) If the server is WILL ECHO, then the telnet client should not do any local echo of the users typed data, as the remote server will be echoing any data that needs to be echoed; if the client continues to do local echo, the user would see double echo of the typed characters. 4) When the server is WILL ECHO, it is not required to echo the incoming data verbatim, it may chose to not echo some of the data (like passwords) or may chose to echo data in a different format (like control characters as a two character sequence, e.g. "^A"). These diagrams represent the typical UNIX environment; your milage may vary. The "(tty)" and "CLIENT" boxes, and the "SERVER", "(pty)" and "Application" boxes may be combined as appropriatly for different systems, but the basic concept remains the same. The double-dashed line is the path where both normal data and echoed data is flowing. It is assumed that the users data is to be echoed. Server WONT ECHO: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|--+->|----->|---->|----->|---->|->(read) | | | | | | | | | | | | | | | | | | V | | | | | | screen <=|==+--|<-----|<----|<-----|<----|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ Server WILL ECHO: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|---->|----->|---->|----->|--+->|->(read) | | | | | | | | | | | | | | | | | | | | | | V | | screen <=|=====|<=====|<====|<=====|==+--|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ If the client was ever WILL ECHO (sever WONT ECHO), you would have something like: (tty) CLIENT SERVER (pty) Application +-----+------+ +------+-----+---------+ | | | | | | | terminal ->|---->|---+=>|====>|=====>|====>|=>(read) | | | ^ | | | | | | | | | | | | | | | | | | | | | screen <-|-----|<--+--|<----|<-----|-----|<-(write)| | | | | | | | +-----+------+ +------+-----+---------+ which would not be very useful. -David Borman, Chair of the IETF Telnet Working Group dab@cray.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011260544.AA01255@ucbvax.Berkeley.EDU] <1990112604260000> From: damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") Newsgroups: comp.protocols.tcp-ip Subject: Reducing the risks when connecting to an internet Message-ID: <9011260544.AA01255@ucbvax.Berkeley.EDU> Date: 26 Nov 90 04:26:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Posted: Mon Nov 26 05:26:00 1990 In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to filter on specific IP services such as TELNET, SMTP, FTP, etc. You can use Cisco routers to do this quite effectively. You can use their extended access controls to filter on source and destination address as well as port number. However, be aware that the Cisco ability to process packets without dropping any is proportional to the size of the access list. You can minimize the size of the lists by permitting/denying packets by subnet rather than by IP address. Better to put this burden on a router than a host that is probably used for something else... Jerry Damian Ford Motor Co. damian@srlvx0.srl.ford.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112606230000> Received: from vaxb.acs.unt.edu by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 09:24:37 PST Date: Mon, 26 Nov 90 11:23 CDT From: "Kevin W. Mullet, Univ. of N. Tx" Subject: IP Routing information needed To: cisco@spot.colorado.edu, protocols@rutgers.edu, tcp-ip@nic.ddn.mil, pcip@udel.edu X-VMS-To: @IPROUTE.TO I'm looking for as many on-line documents available through BITNET or the Internet reguarding IP Routing as possible. Any suggestions about appropriate RFCs, IENs, newsgroup/mailing list archives, Postscript docs, etc., would be greatly appreciated. (time is of the essence.) As usual netiquette dictates, please reply directly to me and I'll post a summary to the net if I get any substantive replies. Beau coup thanks in advance, -Kevin Mullet University of North Texas Internet: snms4@vaxb.acs.unt.edu BITNET: snms4@untvax ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112607320000> Received: from srlvx0.srl.ford.com by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 09:35:08 PST Date: 26 Nov 90 12:32:00 EST From: "Jerry Damian" Subject: Re: Reducing the risks when connecting to an Internet To: "tcp-ip" Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree completely with all comments regarding host based security rather than network imposed security. However, that is often not possible due to the internal politics of an enterprise network and who administers its hosts. The majority of hosts on my internet are administered by engineers NOT network managers or systems programmers. The reality of my situation is that I cannot dictate how individual hosts are to be configured because I do not own them. Yes, this does lead to MANY problems... Limiting the visibility of an internet via router/bridge filtering will buy time until you can get the job done right. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112609423700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 04:16:29 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08539; Tue, 27 Nov 90 04:08:07 -0800 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 Nov 90 09:42:37 GMT From: eru!hagbard!sunic!mcsun!ukc!tcdcs!swift.cs.tcd.ie!ccvax.ucd.ie!t_wade@bloom-beacon.mit.edu (Tom Wade, VMS Systems) Organization: University College Dublin Subject: domain ordering brings down British Leader (:-)) Message-Id: <13779.2750e38d@ccvax.ucd.ie> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil British Prime Minister quits over Domain Ordering. UPI 22-Nov-1990 In a dramatic twist to the "big-endian/little-endian" controversy raging on the European networks, the British Prime Minister Thatcher Margaret today announced that she is standing down as leader of the Conservative Party and government. After weathering many storms in which She Stood Alone against the European hordes on Exchange Rate Mechanism, European Monetary Union, European Political Union and German Reunification, the final straw was the insistence that the UK maintain its network addressing structure exactly the opposite way around from everyone else. Speaking from no 10, Downing Street (known within the UK of course as "Street Downing, 10"), she announced that she would quit rather than adopt the Internet standard. "We have our traditions and our standards", she said, "and though they are at variance with everyone else, I believe that it is the rest of the world that has got it wrong". Heseltine Michael, the man who put himself forward for the leadership would not confirm whether he would reverse the domain ordering if he were to succeed the Prime Minister, but it is well known that the decisive factor in his decision to stand was the many letters he received from domainless sources in Austria, urging him to "reverse the anti-European trend at the top". The JNT, who devised the UK addressing standard (Advanced Retroactive System for Expressing Worldwide Addresses in Yellowbook Standard or ARSEWAYS) were not available for comment; our requests for statements meeting with non-delivery messages in Czechoslovakian. ------------------------------------------------------------------------------ Tom Wade | Internet: T.Wade@cc.ucd.ie (all domain mailers). Speaker To VAXes | Bitnet: T_WADE@CCVAX EuroKom | PSI-Mail: PSI%27243154000712::T.WADE University College | DEC EASYnet: DECWRL::"t.wade@cc.ucd.ie" (VMS Mail) Belfield | JANET: t.wade%ie.ucd.cc@UK.AC.EARN-RELAY Dublin 4 | X400: [Address Exceeds 65536 byte buffer] Ireland | Telex: (0500) 91178 UCD EI ("TO: WADE" at start) --------------------+---------------------------------------------------------- Voice: +353-1-697890| Official Disclaimer: "This is not a disclaimer" Fax: +353-1-838605| ------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Tom Wade | Internet: T.Wade@cc.ucd.ie (all domain mailers). Speaker To VAXes | Bitnet: T_WADE@CCVAX EuroKom | PSI-Mail: PSI%27243154000712::T.WADE University College | DEC EASYnet: DECWRL::"t.wade@cc.ucd.ie" (VMS Mail) Belfield | JANET: t.wade%ie.ucd.cc@UK.AC.EARN-RELAY Dublin 4 | X400: [Address Exceeds 65536 byte buffer] Ireland | Telex: (0500) 91178 UCD EI ("TO: WADE" at start) --------------------+---------------------------------------------------------- Voice: +353-1-697890| Official Disclaimer: "This is not a disclaimer" Fax: +353-1-838605| ------------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112610070200> Received: from UMRVMB.UMR.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 14:08:39 PST Received: from UMRVMB.UMR.EDU by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7385; Mon, 26 Nov 90 16:07:35 CST Received: from UMRVMB (C0017) by UMRVMB.UMR.EDU (Mailer R2.07) with BSMTP id 5711; Mon, 26 Nov 90 16:07:33 CST Date: Mon, 26 Nov 90 16:07:02 CST From: "A. Meg Brady, Mgr. of User Services" Subject: Re: Internet library guide - additions requested Message-Id: <901126.160702.CST.C0017@UMRVMB> To: TCP-IP@NIC.DDN.MIL In-Reply-To: <901125.200810.CST.C0001@UMRVMB> Can I assume you want me to send them our info for accessing LUMIN through the Internet? Meg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112610100900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 06:29:28 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09614; Mon, 26 Nov 90 06:20:31 -0800 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 Nov 90 10:10:09 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cs.columbia.edu!close.columbia.edu!ji@ucsd.edu (John Ioannidis) Organization: Columbia University Department of Computer Science Subject: Re: Reducing the risks when connecting to an internet Message-Id: <1990Nov26.101009.9680@cs.columbia.edu> References: <9011260544.AA01255@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011260544.AA01255@ucbvax.Berkeley.EDU> damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") writes: >In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to >filter on specific IP services such as TELNET, SMTP, FTP, etc. > >You can use Cisco routers to do this quite effectively. You can use their >extended access controls to filter on source and destination address as >well as port number. However, be aware that the Cisco ability to process And remember that this should only be a temporary measure, while you plug holes in your individual hosts. Do not get lulled into a false sense of security. Protections and security should be enforced at the host level. If you suspect that your networking daemons are buggy, get your vendors (or your systems programmer) to fix them. /ji PS: Hi Phil! In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 854 8120 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112612025400> Received: from hawk.nstn.ns.ca by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 08:07:19 PST Date: Mon, 26 Nov 90 12:02:54 GMT Message-Id: <1852@hawk.nstn.ns.ca> From: bushell@hawk.nstn.ns.ca (Tom Bushell) Reply-To: bushell@hawk.nstn.ns.ca To: tcp-ip@nic.ddn.mil Subject: SLIP modem autodialing and idle line detection Hello, We're about to offer dial in Internet access over SLIP for NSTN (the Nova Scotia Technology Network). Our plan is to let our customers use public domain packages like NSCD Telnet with the Clarkson SLIP packet driver to dial in to a central teminal server, using Hayes compatable modems with their PCs. I've been able to dial the modem from Phil Karn's KA9Q using the "tip" command, but we want to automate this process for our dial in customers, so they just run their applications (Telnet, FTP, whatever) and the connection will be automatically established. We have three main requirements: 1) Must be able to automatically establish a SLIP connection over a modem. 2) Must be able to automatically accept an IP number assigned by the terminal server being dialed into, and run public domain applications like KA9Q and NCSD Telnet with this IP number. 3) To try to minimize connect charges for the users, we want to monitor the line for user activity, and drop it after a specified period if there is none, even if he/she is still in the application. We want to reconnect when activity is detected. I'm currently in the process of coding to solve #1 and #2. Our approach is to use a standalone C program to establish a connection, get the IP number from the terminal server, and use it to modify the configuration file for NSCA Telnet. I'll probably have this working soon, but if someone were to hand me an existing solution on a silver platter, I'd be happy to take it. Requirement #3 looks like a bit of a bitch. Looks like we'll have to write a TSR that grabs the PC's system timer, and decrements a counter for the line idle timeout. If this counter reaches 0, the line is dropped. We'll also have to modify the SLIP packet driver so it resets this counter every time a packet is sent by the user. My questions are: Is this a good approach to meet our three requirements? Has anyone out there already met any or all of these goals? If so, can you share what you did? Thanks in advance to all who take the time to reply. I will post response to the net if interest is sufficient. As an incentive to code sharing, I've been given tenative permission to make the code I'm working on available. Thanks Tom ************************************************************* * Tom Bushell Software Kinetics Ltd * * 101 Ilsley Ave * * E-mail - bushell@hawk.nstn.ns.ca Suite 5 * * Phone (902)468-3680 Dartmouth N.S., Canada * * Fax (902)468-3679 B3B 1S8 * ************************************************************* ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112615101700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 07:15:04 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA10690; Mon, 26 Nov 90 07:13:18 -0800 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 Nov 90 15:10:17 GMT From: sdd.hp.com!samsung!know!pluto.hemel.bull.co.uk!pmoore@ucsd.edu (Paul Moore) Organization: Bull HN UK Subject: Re: Reducing the risks when connecting to an internet Message-Id: <1990Nov26.151017.2023@hemel.bull.co.uk> References: <9011260544.AA01255@ucbvax.Berkeley.EDU>, <1990Nov26.101009.9680@cs.columbia.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil ji@close.columbia.edu (John Ioannidis) writes: >And remember that this should only be a temporary measure, while you >plug holes in your individual hosts. Do not get lulled into a false >sense of security. Protections and security should be enforced at the >host level. If you suspect that your networking daemons are buggy, get >your vendors (or your systems programmer) to fix them. Gosh, I am glad to see somebody making that point, ("security is a host problem not a net problem"). There is an almost Pavlovian response to networks. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112616133800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 11:52:22 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA20187; Wed, 28 Nov 90 10:27:43 -0800 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 Nov 90 16:13:38 GMT From: att!mcdchg!ddsw1!bbs!karl@ucbvax.Berkeley.EDU (Karl Denninger) Organization: A.C. Nielsen Co. Subject: Tn3270 with option code 0x11 - Write Structured Fields Message-Id: <1990Nov26.161338.1698@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi there! We have grabbed the tn3270 off of UUNET, and gotten it to compile. Now we have a problem -- the tn3270 we have here doesn't support the write command 0x11, which is "Write structured field". The tn3270.h file does have this definition in it, but there is no code to back it up. Does anyone have a tn3270 which supports this? Our mainframe is rather insistant about sending these commands.... Any help appreciated. --- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011270243.AA28471@ucbvax.Berkeley.EDU] <1990112616230000> From: SNMS4@VAXB.ACS.UNT.EDU ("Kevin W. Mullet, Univ. of N. Tx") Newsgroups: comp.protocols.tcp-ip Subject: IP Routing information needed Message-ID: <9011270243.AA28471@ucbvax.Berkeley.EDU> Date: 26 Nov 90 16:23:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Posted: Mon Nov 26 17:23:00 1990 I'm looking for as many on-line documents available through BITNET or the Internet reguarding IP Routing as possible. Any suggestions about appropriate RFCs, IENs, newsgroup/mailing list archives, Postscript docs, etc., would be greatly appreciated. (time is of the essence.) As usual netiquette dictates, please reply directly to me and I'll post a summary to the net if I get any substantive replies. Beau coup thanks in advance, -Kevin Mullet University of North Texas Internet: snms4@vaxb.acs.unt.edu BITNET: snms4@untvax ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011270314.AA29123@ucbvax.Berkeley.EDU] <1990112617320000> From: damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") Newsgroups: comp.protocols.tcp-ip Subject: Re: Reducing the risks when connecting to an Internet Message-ID: <9011270314.AA29123@ucbvax.Berkeley.EDU> Date: 26 Nov 90 17:32:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Posted: Mon Nov 26 18:32:00 1990 Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree completely with all comments regarding host based security rather than network imposed security. However, that is often not possible due to the internal politics of an enterprise network and who administers its hosts. The majority of hosts on my internet are administered by engineers NOT network managers or systems programmers. The reality of my situation is that I cannot dictate how individual hosts are to be configured because I do not own them. Yes, this does lead to MANY problems... Limiting the visibility of an internet via router/bridge filtering will buy time until you can get the job done right. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112619451800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 13:04:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19350; Mon, 26 Nov 90 12:47:28 -0800 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 Nov 90 19:45:18 GMT From: swrinde!mips!twg.com!david@ucsd.edu (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Subject: Re: SCO TCP/IP and E-Mail Problems Message-Id: <8357@gollum.twg.com> References: <9011190759.aa12077@ssmct62.ssc.af.mil> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil [Cross-posted & followups-to comp.mail.misc since this isn't TCP/IP specific] In article <9011190759.aa12077@ssmct62.ssc.af.mil> hutch@ssmct62.ssc.af.mil ("Capt E. Lee Hutchins") writes: > MMDF is the supported mail system for SCO UNIX. MMDF does not come >with an ideal set of documentation. (At least I >can't make heads or tails out of it). If any one has some ideas on Docs for >this system which are NOT in troff form I'd appreciate them. Configuring MMDF >without real documentation is a real *&^%$! Yes, I agree .. that would be rather hard. Docs for MMDF IIb update 43 (as well as sources) are available via anonymous ftp from louie.udel.edu. Both uunet.uu.net & gatekeeper.dec.com keep the sources available. I don't remember path names, but it was pretty obvious .. There's two mailing lists you should be interested in: eurmmdf@zweibrucken-emh1.army.mil is Army people (I suppose that since they let me be on the list, they'll let Air Force people be on it ;-)) working with MMDF. Though the discussion seems to be more generic Unix problems than MMDF problems .. eurmmdf-request@zweibrucken-emh1.army.mil, of course, for administrivia mmdf2@relay.cs.net The "official" mailing list for MMDF support. It manages to focus on MMDF pretty well. mmdf2-request@relay.cs.net, of course, for administrivia > I can recieve mail from other UNIX platforms, but we have another >mail system running which is based on 10NET, called "COURIER MAIL". It has >an "SMTP" gateway working and other UNIX boxes (AT&T 3B2 600G's) can >receive and send mail fine. My box on the other hand, does >not work with it. The mail ends up in a queue on the "COURIER SERVER" and is >never returned to me or the originator. Anybody ever experienced this???? This sounds like the "no background deliver" as described below .. > By the way my machine does not always accept: > > telnet machinename.domain 25 > >When tried manually from other hosts it often closes the connection before it >askes for the identification. The MMDF SMTP server can be configured to do this if the IP address does not have a known IP->host_name mapping. Usually, though, it's configured to give the "foo, you are a charlatan" message .. >In fact it seems the more mail sent to my >machine, the less I actually receive. I am on *several* mailing lists and I >expected my mail volume to be much higher than it is. This sounds like the SCO fumble where they made some bad suggestions in their manuals. Specifically -- that channels be configured for "immediate" delivery & that no deliver daemon be run to handle background delivery. Theoretically it sounds nice .. if it gets delivered immediately then it doesn't make sense to have a deliver running since it will "never" see any mail. But in practice -- if lots of mail arrives at once -- then some of the messages will drop into a queue and then never get delivered. This is especially noticeable with the local channel. If the mailbox is locked (for instance, it's being delivered to by another local channel process) the channel will exit with a "temporary failure" status & the deliver controlling that channel will go away. The assumption was that a background channel would take up the slack. Rather than simply wait around for a little while -- you don't know how long this "temporary" condition will exist -- exiting works given a background deliver. But SCO recommended *against* using a background deliver. Fortunately they've seen the error of their ways and currently suggest using "mod=reg", which pushes all delivery through the background deliver, and run deliver -b -clocal & or deliver -b -clocal,list,uucp,smtp & In update 43 you can abbreviate that to deliver -b -c & and that daemon will work with *all* channels in the system. > Finally, one other tidbit, I am running the latest version of "ELM" as >my front end to mail. This shouldn't make any difference -- unless ELM keeps the mailbox locked all the time. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Use the force Wes! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112620501600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 13:14:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19992; Mon, 26 Nov 90 13:09:34 -0800 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 Nov 90 20:50:16 GMT From: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Organization: Morning Star Technologies Subject: Re: SLIP Message-Id: References: <570@wjh12.harvard.edu>, <1990Nov26.162533.5418@engin.umich.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov26.162533.5418@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: Does anybody have a version of SLIP or PPP with SLFP (Serial Line Framing Protocol) support in it? Merit ... does SLFP. Is SLFP HDLC? If not, is SLFP documented in a readily-accessible place? RFC1171 (section 3) specifies that PPP uses HDLC-style framing unless LCP negotiates otherwise. Is it PPP if it's not basically HDLC? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112622021200> Received: from okeeffe.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 11:22:23 PST Received: by okeeffe.Berkeley.EDU (5.65/1.41) id AA02820; Tue, 27 Nov 90 11:22:12 -0800 Date: Tue, 27 Nov 90 11:22:12 -0800 From: dot12@okeeffe.Berkeley.EDU (P1003.12 Committee) Message-Id: <9011271922.AA02820@okeeffe.Berkeley.EDU> To: tcp-ip@nic.ddn.mil Subject: Your Chance to Influence POSIX! The POSIX process-to-process communications working group (P1003.12) would like to solicit outside comment. The committee wishes to publish an interface at the level of exposed detail exhibited by both sockets and XTI. Previously, the committee had been of the opinion that although both sets of existing practice were relatively similar, each had technical flaws. Furthermore, each had a user community unwilling to give theirs up and adopt the other. The working solution the commitee had been pursuing was to combine the the best features of the two interfaces, changing the names and semantics of the primitives, so that some amount of re-coding would be necessary. The committee was using as its model the level of modification done to the job control and termios facilities of P1003.1 There has recently been vociferous opposition to this plan, arguing that vendors would have to support THREE interfaces (sockets, XTI and POSIX) and it would be better to have the P1003.12 committee issue IEEE standard versions of the existing two, with possible backwards compatible extensions and improvements. We invite you to submit your reactions to dot12@okeeffe.Berkeley.EDU for consideration by the committee. It would be helpful to some of us if you would say something about your background or experience with either of XTI or sockets. (Please note that comments sent only to the tcp-ip mailing list may not necessarily be forwarded to the committee). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112623384800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 17:00:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25776; Mon, 26 Nov 90 16:47:51 -0800 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 Nov 90 23:38:48 GMT From: unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU (NRAO Array Operations Center) Organization: National Radio Astronomy Observatory, Socorro NM Subject: Re: Internet Access Costs Message-Id: <1990Nov26.233848.20828@nmt.edu> References: <315@srchtec.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes: >[...] >One other item: PSI says we will not have a constant IP #. It supposedly >changes each time we establish a connection with them. However, our address >will remain constant (probably searchtech.com). I'm hoping this will not cause >too many problem with our local setup, but I guess we're going to find out! Say what????? I fail to see how this can be the case. Granted they can change their tables any time they want, *but* they have the following restrictions: a) they have to use an Internet number assigned to them/you by the NIC b) the rest of the Internet has to understand the routing (if it's advertised, and if it isn't no-one can reach you) c) your system has to know *before establishing the connection* what its own Internet address is Are you sure that they meant your "IP #" changes? If you are connecting through SLIP, then your circuit number might change each time, depending how many other connections are being made at the same time. But your own actual Internet address should stay the same. Even if it *could* be done, it would be such an administrative nightmare trying to figure out "who's 123.456.789.10 this morning?" that I can't think why they *would* do it. I dunno, maybe the connections are volatile enough that they just assign an IP address in sequence or something every time a connections comes up, but it sounds pretty weird to me. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM rmilner@zia.aoc.nrao.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112700462100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 17:20:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26127; Mon, 26 Nov 90 17:04:45 -0800 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 Nov 90 00:46:21 GMT From: milton!Tomobiki-Cho!mrc@beaver.cs.washington.edu (Mark Crispin) Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Subject: Re: Telnet's ECHO option Message-Id: <11717@milton.u.washington.edu> References: , <1191@disuns2.epfl.ch> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1191@disuns2.epfl.ch> conti@ltisun7.epfl.ch (Giovanni Conti) writes: >I think there is a need to explain the WILL/WONT mechansim. Yes, someone should explain it to you, since not only don't you understand it, but worse, you don't know that you don't understand it and you are spreading misinformation. Please don't do so in the future. There are enough people around here who have written Telnet software -- I've written several servers and clients for different operating systems, going back to 1976 -- who can answer Telnet protocol questions correctly. The Telnet ECHO option, in a server/client environment, refers to echoing done by the server of data from the client back to the client. In other words, it is only meaningful for a client to send: IAC DO ECHO (requesting/confirming that the server echo) IAC DONT ECHO (demanding/confirming that the server not echo) and for a server to send: IAC WILL ECHO (requesting/confirming that it will echo) IAC WONT ECHO (refusing/confirming that it will not echo) In a bilateral Telnet (e.g. station-to-station) where there is no clear server or client than it may be reasonable for echoing in both directions. >The ECHO is LOCAL. So if you ask your partner to do echo, >he will duplicate his output stream (from him to you) onto >his input stream. Totally wrong. The Telnet ECHO option controls remote echoing; local echoing is only implicit. An echo is never "a duplication by an agent of his output stream onto his input stream." An echo is a "duplication by an agent of his input stream onto his output stream." >If you ask the host to do ECHO, and assuming he answers WILL ECHO, >that means that when he sends you the string "Username:", telnet echoes >him a copy as if you've typed "Username:", leading to wrong behaviours. No, no, no, 1000 times no. That is what "IAC WILL ECHO" from the Telnet client means. I didn't see the original question, but it seems that you have sent some poor guy on a wild goose chase. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ FAX: (206) 543-3909 "Iie, boku ha nihonjin." / | \ | |__| / \ / \MRC@CAC.Washington.EDU "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112701491500> Received: from WSUVM1.CSC.WSU.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 09:50:33 PST Received: from WSUVM1.BITNET by WSUVM1.CSC.WSU.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2394; Tue, 27 Nov 90 09:49:30 PLT Received: from WSUVM1 (IRVINMJ) by WSUVM1.BITNET (Mailer R2.07) with BSMTP id 1805; Tue, 27 Nov 90 09:49:30 PLT Date: Tue, 27 Nov 90 09:49:15 PLT From: "Michael J. Irvin, WSU, 509/335-0437" Subject: Re: domain ordering brings down British Leader (:-)) To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Tue, 27 Nov 90 07:35:04 PLT from THAT explains it! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112703454800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 20:16:24 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00419; Mon, 26 Nov 90 20:02:33 -0800 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 Nov 90 03:45:48 GMT From: nic.cerf.net!pushp@ucsd.edu (Pushpendra Mohta) Organization: CERFnet, La Jolla, CA Subject: Fixed IP addresses ( Was Re: Internet Access Costs ) Message-Id: <238@nic.cerf.net> References: <315@srchtec.UUCP>, <1990Nov26.233848.20828@nmt.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov26.233848.20828@nmt.edu> rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: >In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes: >>[...] >>One other item: PSI says we will not have a constant IP #. It supposedly >>changes each time we establish a connection with them. However, our address >>will remain constant (probably searchtech.com). I'm hoping this will not cause >>too many problem with our local setup, but I guess we're going to find out! > >Say what????? > From what the original poster has described, I suspect PSI is using the same terminal server as CERFnet uses for its dial up Internet Access Service, DIAL n' CERF . ( from cisco Systems) >I fail to see how this can be the case. Granted they can change their tables >any time they want, *but* they have the following restrictions: > > a) they have to use an Internet number assigned to them/you by the NIC The address assigned to the calling party is one on the subnet on which the terminal server resides. The network address is indeed one assigned by SRI-NIC. > b) the rest of the Internet has to understand the routing (if it's > advertised, and if it isn't no-one can reach you) See above. The route to the subnet/net is advertized to the rest of the Internet . > c) your system has to know *before establishing the connection* what > its own Internet address is > Not true. Your system has to know its IP address before estabilishing a *IP* connection. However, for example on a cisco terminal server, you may use BOOTP over the dial up connection to determine your IP address. >Are you sure that they meant your "IP #" changes? If you are connecting >through SLIP, then your circuit number might change each time, depending >how many other connections are being made at the same time. But your own >actual Internet address should stay the same. > >Even if it *could* be done, it would be such an administrative nightmare >trying to figure out "who's 123.456.789.10 this morning?" that I can't think >why they *would* do it. > There are ways to log correspondences between port numbers, IP numbers and user names. You can then use unix utilities like "last" etc on this data to find out who is what this morning. Not too difficult. I can't answer for PSI but here is why CERFnet does this. Dial-Up services are primarily targeted at the occasional user. Where IP address spaces are limited, it makes sense to recycle addresses from a small pool. This is not a problem for outgoing FTP or Telnet connections but it does make SMTP mail difficult. However as has been pointed out earlier , there are ways to get over this problem (UUCP, POP etc ) (In any case if you cannot do without an IP address of your own, with DIAL n' CERF it is possible to dynamically assign a password protected legal IP address of your choice .) Remember, the above applies to the occasional user.If someone is using their Internet connection often they should consider a ( perhaps slow speed ) leased line connection where their line would be hard wired into a port on the terminal server with a fixed IP address with the " same subnet as terminal server " proviso mentioned earlier. However pricing issues come into play here. >I dunno, maybe the connections are volatile enough that they just assign an >IP address in sequence or something every time a connections comes up, but >it sounds pretty weird to me. >-- I think you have the "gateway server model" of SLIP in mind where each end of the link has two different addresses and you can have a IP network at the remote end whose reachability may be advertized over the serial link. The services described above use the " terminal server model " of SLIP (cisco jargon) where there can only be *one* host and *one* IP address at the remote end. This host then appears to operate as a host on the same subnet as the terminal server. If the terminal server is on an ethernet, the remote host appears to the rest of the world as also on the same ethernet. There are terminal servers available in the market which follow the "gateway server model" on the dial-up link. So most of the above decribed features have come about because of the choice of terminal server provided by a rather popular vendor. >Ruth Milner >Systems Manager NRAO/VLA Socorro NM --pushpendra ---------------------------------------------------------------------- Pushpendra Mohta Network Co-ordinator CERFNet 1-800-876-CERF ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112704174200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Mon, 26 Nov 90 21:47:30 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02307; Mon, 26 Nov 90 21:32:06 -0800 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 Nov 90 04:17:42 GMT From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!umich!sharkey!ionic!gm@ucsd.edu (Greg Miller) Subject: Re: Telnet's ECHO option Message-Id: References: , <1191@disuns2.epfl.ch> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1191@disuns2.epfl.ch>, conti@ltisun7.epfl.ch (Giovanni Conti) writes: > In article , gm@ionic.UUCP (Greg Miller) writes: {Parts of my previous question deleted} > > I think there is a need to explain the WILL/WONT mechansim. > The ECHO is LOCAL. So if you ask your partner to do echo, > he will duplicate his output stream (from him to you) onto > his input stream. That means that a UNIX system doing Telnet echo > and sending you a "Username:" string will also read the same string > in its input stream. So obviously, the UNIX system never does Telnet > echo locally. On the other side, you (e.g. the terminal) are expected > to do some local echo of the keyboard input to the screen (echo > your input stream to your output stream). If the system does not > want you to do that (e.g. when you type the password), it tells > you DONT ECHO, which means "Just send me the characters, I will echo > back what I think is reasonable". In that case you do not > echo the characters locally on your screen. > > If you ask the host to do ECHO, and assuming he answers WILL ECHO, > that means that when he sends you the string "Username:", telnet echoes > him a copy as if you've typed "Username:", leading to wrong behaviours. > > So don't tell the host to do local echo (local to him) if you are > a Telnet Client (or unless you know exactly what you're doing). Here's the important piece of RFC 857: - cut - 2. Command Meanings IAC WILL ECHO The sender of this command REQUESTS to begin, or confirms that it will now begin, echoing data characters it receives over the TELNET connection back to the sender of the data characters. IAC WON'T ECHO The sender of this command DEMANDS to stop, or refuses to start, echoing the data characters it receives over the TELNET connection back to the sender of the data characters. IAC DO ECHO The sender of this command REQUESTS that the receiver of this command begin echoing, or confirms that the receiver of this command is expected to echo, data characters it receives over the TELNET connection back to the sender. IAC DON'T ECHO The sender of this command DEMANDS the receiver of this command stop, or not start, echoing data characters it receives over the TELNET connection. - cut - Calling my system the "client", the remote system (a BSD system) the "host", and using the above chunk of the RFC: My sending a DO ECHO should request that the host begin echoing all data characters it receives back to the sender (me). A reply of WILL ECHO should stand as a confirmation that the host will indeed begin echoing all data characters back to the sender. I don't see how this creates the situation you described. You claimed that this would cause the host to echo it's output back into it's input path (which infers an infinite loop). That's the exact opposite of what I interpret the above as stating. > > > > > (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive > > an echo for each character sent. > > > > So this is wrong. But fortunately, according to your request, the BSD host > will not read in its input stream all the characters it sent to you. See above. > > > Part (1) above seems to fit properly. If I send the DO ECHO, the host > > happily echos everything back to me. However, part (2) doesn't seems to > > always apply - > > > > The fact of echoing everything back to you means: > > a) that you did not do local echo in the beginning (unless you received > all duplicated characters. So there is an error in your Telnet > implementation. > > b) That the Application echo (e.g. the login deamon on a host) has > NOTHING to do with your Telnet echo commands. In fact, the application > running on top of telnet (e.g. csh) may echo back things, asking > you first NOT to do local echo (so you receive a DONT ECHO from the host). > > Good luck Thanks. I'm going to need it. > > Giovanni Conti > Ecole Polytechnique Federale de Lausanne > Laboratoire de Teleinformatique > EL-Ecublens > CH-1015 Lausanne > Switzerland > Tel : +41 21 693.29.07 > FAX : +41 21 693.46.60 > E-mail: conti@ltisun.epfl.ch One last comment - are you by chance reading the RFC from the perspective of the host, rather than the client? That would lead to the interpretation that you gave. Thanks. -- +----------------------------------------------------------------+ | A sign of mismanagement, over- | Greg Miller | | complication and overall idiocy: | ..ames!sharkey!ionic!gm | | | gm@ionic.uucp | | "Designed By Committee" | | +----------------------------------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112706281300> Received: from UMRVMB.UMR.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 10:29:52 PST Received: from UMRVMB.UMR.EDU by UMRVMB.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7626; Tue, 27 Nov 90 12:28:43 CST Received: from UMRVMB (C0001) by UMRVMB.UMR.EDU (Mailer R2.07) with BSMTP id 7573; Tue, 27 Nov 90 12:28:41 CST Date: Tue, 27 Nov 90 12:28:13 CST From: "David W. Dearth, Director" Subject: Re: Internet library guide - additions requested Message-Id: <901127.122813.CST.C0001@UMRVMB> To: TCP-IP@NIC.DDN.MIL In-Reply-To: Message of Mon, 26 Nov 90 16:07:02 CST from X-Acknowledge-To: No. It was for your information or for Terri or maybe Jean Eisenman. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112706481900> Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 08:52:54 PST Received: from unb.ca (stdin) by ugw.utcs.utoronto.ca with SMTP id 57441; Tue, 27 Nov 90 11:48:01 EST Received: by UNBMVS1 (Mailer 14.79) id 3887; Tue, 27 Nov 90 12:48:19 AST Date: Tue, 27 Nov 90 11:48:19 EST From: BDK@unb.ca To: TCP-IP@NIC.DDN.MIL Subject: Re: routing in a subnet (come on all you wizards!) In-Reply-To: Message of Tue, 27 Nov 90 12:20:45 GMT from <@TUT.CIS.OHIO-STATE.EDU> Message-ID: On Tue, 27 Nov 90 12:20:45 GMT Paul Moore writes: I think the route you have given boxb are insufficent. One simple solution is to give boxb a default route: route add default boxa 1 Another solution is to get boxb to listen to whatever routing info (e.g RIP) is broadcast by boxa which is a router of some flavor (i.e a UNIX box running gated or routed or a real router). > I am trying to get the following to work and cannot, it seems it > should to me. It is on Lachman and HP-UX. > > All this is on a class B net (123.456 for example). The net is > subnetted on 8 bits ( a not uncommon situation , I imagine). > Some boxes don't do RIP so I need static routing tables. > I don't want a global default installed for security reasons. > > boxa knows where all the subnets are (123.456.1 , 123.456.2 etc) > > boxb is installed on 123.456.1 and I want to tell it that all 123.456 > traffic that it cannot reslove should go to boxa. > > so i do > > route add net 123.456 boxa 2 > > The route installs OK but is ignored, I must do > route add net 123.456.2 boxa 2 > route add net 123.456.3 boxa 2 > etc.. > > Am I being stupid? Or what ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112707334800> Received: from desktalk.desktalk.com by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 15:32:31 PST Received: by desktalk.desktalk.com (5.61/1.35) id AA01754; Tue, 27 Nov 90 15:33:49 -0800 To: tcp-ip@nic.ddn.mil Subject: Interoperating with HP Message-Id: <9011271533.AA01752@desktalkdesktalk.com> Date: 27 Nov 90 15:33:48 PST (Tue) From: rlg@desktalkdesktalk.com (Richard L. Gralnik) Hi gang, We are on the verge of great things, but I figure I'm better off forewarned so... Does anyone have experience connecting a Sequent (Dynix 3.0.17) to an HP 3000 (MPE/V Delta 5) with HP's LANIC board and TCP/IP software Wollongong ARPA Services for MPE TCP/IP I have been warned off telneting from the HP, but any other gotchas would be appreciated. Also, we are going to try some print sharing from the HP and the Sequent to a serial printer on a Xyplex terminal server. We are debating having both systems print to the same port and using DTR/DSR to check port availability, or using one machine as a print server and ftp'ing files to it from the second machine with a script on the first to watch a spool directory for new print files. If anyone has any scripts for something like this, or ideas/suggestions we'd appreciate it. Thanks, Richard rlg@biobio.desktalk.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112710334100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 04:31:41 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08887; Tue, 27 Nov 90 04:28:20 -0800 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 Nov 90 10:33:41 GMT From: eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun!conti@bloom-beacon.mit.edu (Giovanni Conti) Subject: Re: Telnet's ECHO option Message-Id: <1200@disuns2.epfl.ch> References: , <1191@disuns2.epfl.ch>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article gm@ionic.UUCP (Greg Miller) writes: > > > One last comment - are you by chance reading the RFC from the perspective >of the host, rather than the client? That would lead to the interpretation >that you gave. 1) The first time I read it (about 2 years ago) I misunderstood it, merely triggered by questions like yours. I then got the correct understanding of it by looking at our local net. However, when I read your mail, I remembered my first understanding (which was wrong). So I apologize for leading to confusion. 2) Thanks to Mark ("Gaijin") Crispin for correcting me. Giovanni Conti Ecole Polytechnique Federale de Lausanne Laboratoire de Teleinformatique EL-Ecublens CH-1015 Lausanne Switzerland Tel : +41 21 693.29.07 FAX : +41 21 693.46.60 E-mail: conti@ltisun.epfl.ch ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112712204500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 04:31:06 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA08803; Tue, 27 Nov 90 04:23:04 -0800 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 Nov 90 12:20:45 GMT From: zaphod.mps.ohio-state.edu!know!pluto.hemel.bull.co.uk!pmoore@tut.cis.ohio-state.edu (Paul Moore) Organization: Bull HN UK Subject: routing in a subnet (come on all you wizards!) Message-Id: <1990Nov27.122045.5238@hemel.bull.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am trying to get the following to work and cannot, it seems it should to me. It is on Lachman and HP-UX. All this is on a class B net (123.456 for example). The net is subnetted on 8 bits ( a not uncommon situation , I imagine). Some boxes don't do RIP so I need static routing tables. I don't want a global default installed for security reasons. boxa knows where all the subnets are (123.456.1 , 123.456.2 etc) boxb is installed on 123.456.1 and I want to tell it that all 123.456 traffic that it cannot reslove should go to boxa. so i do route add net 123.456 boxa 2 The route installs OK but is ignored, I must do route add net 123.456.2 boxa 2 route add net 123.456.3 boxa 2 etc.. Am I being stupid? Or what ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112714552600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 06:48:18 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14815; Wed, 28 Nov 90 06:43:53 -0800 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 Nov 90 14:55:26 GMT From: rti!dg-rtp!bigben!bigben!philip@mcnc.org (Philip Gladstone) Organization: Data General, Development Lab Europe Subject: Re: Reducing the risks when connecting to an internet Message-Id: References: <9011260544.AA01255@ucbvax.Berkeley.EDU> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov26.151017.2023@hemel.bull.co.uk> pmoore@hemel.bull.co.uk (Paul Moore) writes: pmoore> Gosh, I am glad to see somebody making that point, ("security is a host pmoore> problem not a net problem"). Security is both a network and a host problem. The more defences you have, the better protected you are. Compare with a military base (a network). Even though they think that the safe (the host) holding the codebooks is secure, they still don't let you anywhere near it! Similarly, even though the Bank of England beleives that their vaults are secure, they still don't hand out the plans. The other key advantage of network security is that (if the network is organised correctly), all traffic passes through a small number of points. These points can be carefully controlled. Again: I would prefer that the Bank of England control the people entering the Bank, rather than relying solely on the security of the vault. -- Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK Listen three eyes, don't you try and outweird me, I get stranger things that you free with my breakfast cereal. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112716210500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 17:01:41 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27877; Tue, 27 Nov 90 16:56:42 -0800 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 Nov 90 16:21:05 GMT From: usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!cbmehq!cbmger!acdhq!kaba@ucsd.edu (Kai Bartels) Organization: ACD Advanced Computer Design GmbH Subject: IP on a serial line -- which RFC? Message-Id: <18466181.ARN13a9@acdhq.north.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hy! I'm currently workin on an implementation of tcp-ip an during this work i realised that i really don't know how fragments are representated on a serial line. I don't think it's possible to have it in the same way as it is on ethernet, 'cause on a serial line you have to know the length of the fragment BEFORE you get it, so you don'y miss the end. So the question is: can anybody tell me which RFC to look at? Thanks in advance, Kai -------------------- Kai Bartels | kaba@acdhq.UUCP | Where do you get your information Hudemuehler 37 | kaba@acdhq.north.de | From a dream or a 24-inch-screen? D-2800 HB 41 | G14B@DHBRRZ41.BITNET | ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112719335100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 12:16:40 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19551; Tue, 27 Nov 90 12:11:19 -0800 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 Nov 90 19:33:51 GMT From: snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@bloom-beacon.mit.edu (Peter Murray) Subject: Limited version of telnet Message-Id: <2974.27527950@miavx1.acs.muohio.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for a limited version of TELNET. This program would only allow connections to one host or a list of hosts in a text file. What I don't want is this program to is to domain lookups. We would use this program to publish a LAT service for a Unix box that does not support LAT. Regular TELNET allows a person to enter a command mode and connect to another host (ie, anonymous telnet). But I really don't want to disable the command mode. Thanks for your help. Peter -- Peter Murray Neat UNIX Stunts #4: pemurray@miavx1.bitnet 176 Thompson Hall csh> \(- pmurray@apsvax.aps.muohio.edu Oxford, OH 45056 NeXT Mail: pmurray@next4.acs.muohio.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112720010700> Received: from inria.inria.fr by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 09:49:49 PST Received: from isis.u-strasbg.fr by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA23697; Tue, 27 Nov 90 18:19:10 +0100 (MET) Received: by isis.u-strasbg.fr (3.2/(JJP 15/11/90)) id AA06559; Tue, 27 Nov 90 18:21:07 +0100 Date: Tue, 27 Nov 90 18:21:07 +0100 From: pansiot@isis.u-strasbg.fr (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) Message-Id: <9011271721.AA06559@isis.u-strasbg.fr> To: tcpipl@inria.inria.fr Subject: X25 over IP Is there a standard way to run X25 over IP ( not the other way around, Ip over X25 ). We would like to use our IP network to carry non Ip traffic over X25. I assume that either UDP or TCP would be between IP and X25 ? Is there any product like some kind of terminal server with X25 lines and ethernet attachment that would permit X25 virtual circuit between two (distant )ports and over IP ? Obviously, I assume some IP-only routers along the path. Thank you for any information Jean-Jacques Pansiot, Universite Louis Pasteur, Strasbourg, FRANCE 7, rue Descartes 67084 STRASBOURG CEDEX FRANCE Email: pansiot@isis.u-strasbg.fr Tel: (33) 88 41 64 28 Fax: (33) 88 61 90 69 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112722524300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 16:01:42 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26139; Tue, 27 Nov 90 15:56:13 -0800 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 Nov 90 22:52:43 GMT From: netnews.upenn.edu!grad1.cis.upenn.edu!menqjuh@rutgers.edu (Menq J. Lee) Organization: University of Pennsylvania Subject: Question about Socket Message-Id: <33562@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi everybody, I am new to this field, and I am using DGRAM Socket (UDP) to build a remote copy utility. This utility supports both ascii and binary file transfers. I have no problem in handling binary transfer. But when it comes to ascii transfer, the reference I read told me that I must take care of some critical cases. Specifically, I have to do some conversion between newline <---> CR,LF (Carriage Return, Line Feed) CR <---> CR,NULL I have the following questions about this issue: 1. Why is this necessary? In other words, under what situations will this conversion be employed to avoid foreseeable errors? 2. Do I have to do the same conversion if I use STREAM Socket (TCP) instead of DGRAM Socket? Any help will be highly appreciated. --Menq ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112800024000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 16:19:44 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26644; Tue, 27 Nov 90 16:14:46 -0800 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 Nov 90 00:02:40 GMT From: usc!wuarchive!emory!ospwd@ucsd.edu (Peter Day {EUCC}) Organization: Emory University Information Technology Division Subject: protocol support Message-Id: <6581@emory.mathcs.emory.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil For our network planning effort, I would like to know what protocols other universities support on their campus networks and how these protocols were chosen. Also, what does that "support" entail? Finally, any advice you would like to give on the subject of supported protocols would be appreciated. Please reply directly to me and I will summarize. Thanks, Peter Day Research and Planning, Information Technology Division, Uppergate House, Emory University, Atlanta, GA 30322 DOMAIN: ospwd@emoryu1.cc.emory.edu UUCP: gatech!emoryu1!ospwd PHONE: +1 404 727-7678 BITNET: ospwd@emoryu1 FAX: +1 404 727-2599 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112800051000> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 16:18:50 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26680; Tue, 27 Nov 90 16:15:47 -0800 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 Nov 90 00:05:10 GMT From: usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@ucsd.edu (Mark Eggers) Subject: Cabletron Mailing list correction Message-Id: <2752FF36.26318@orion.oac.uci.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Please note that the cabltron mailing list has changed addresses. The proper addresses are: Mailing list: cabletron-users@uci.edu cbltrn@uci.edu Requests to be added: cabletron-request@uci.edu ct-rqst@uci.edu Please report problems to ucinet-noc@uci.edu. /mde/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112800162200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 16:46:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA26967; Tue, 27 Nov 90 16:25:39 -0800 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 Nov 90 00:16:22 GMT From: usc!elroy.jpl.nasa.gov!euclid.jpl.nasa.gov!pjs@ucsd.edu (Peter Scott) Organization: Jet Propulsion Laboratory, NASA/Caltech Subject: TCP/IP equivalent of Manufacturing Message Specification? Message-Id: <1990Nov28.001622.555@elroy.jpl.nasa.gov> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi. I've been asked to explore possible solutions to a problem an area I know little about, networking protocols, so please bear with me. A colleague is working with a group whose aim is to network together various lab measurement devices plugged into PCs and workstations. These devices are currently in operation at Goldstone, California (some of them are pretty big, e.g. 70m dish antenna :-)). Anyway, another person working on the problem has proposed the Hewlett Packard MMS (Manufacturing Message Specification) as a tool for accomplishing it. Features of this product, just released, include automatic data conversion between machines, i.e., if transferring floating point data between a PC and a Sun it will convert between formats, flip bytes where necessary, etc. However it is also based on OSI, and that causes my colleague a few problems, to wit, OSI is rather new, harder to obtain software for than TCP/IP, and in order to perform testing he would have to buy another two computers just to talk OSI to each other. He would prefer to use TCP/IP. Obviously a lot of custom software has to be written to make all these devices talk to hosts and servers, but it would be nice to avoid reinventing too many wheels. Okay, My Question: does anyone have any suggestions for any software product, commercial or otherwise, which would simplify the task of data communication, runs on TCP/IP, and generally provides the same benefits as we would find useful in MMS? -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@euclid.jpl.nasa.gov) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112800330200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 16:47:06 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27530; Tue, 27 Nov 90 16:41:52 -0800 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 Nov 90 00:33:02 GMT From: lll-crg.llnl.gov@lll-winken.llnl.gov (Dave Wiltzius) Organization: Lawrence Livermore National Laboratory Subject: TCP trace buffer formatter? Message-Id: <86857@lll-winken.LLNL.GOV> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil The BSD TCP/IP networking code has a TCP level circular trace buffer (filled by routine tcp_trace). Does anyone have a tool that would read this buffer from memory and format the information? We want this only for internal use and are willing to accept all liability, etc. If someone did a *really* nice job (i.e. allow filters on IP addresses, TCP ports, etc), perhaps the response should be posted. I would be glad to consider anything, however. Thanks much. Dave Wiltzius Lawrence Livermore Nat'l Lab Livermore, CA 94550 (415) 422-1551 wiltzius@lll-crg.llnl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011280107.AA28177@ucbvax.Berkeley.EDU] <1990112801075000> From: IRVINMJ@WSUVM1.CSC.WSU.EDU ("Michael J. Irvin, WSU, 509/335-0437") Newsgroups: comp.protocols.tcp-ip Subject: Re: domain ordering brings down British Leader (:-)) Message-ID: <9011280107.AA28177@ucbvax.Berkeley.EDU> Date: 28 Nov 90 01:07:50 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 1 X-Unparsable-Date: Tue, 27 Nov 90 09:49:15 PLT THAT explains it! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112801454300> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 18:02:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29468; Tue, 27 Nov 90 17:53:55 -0800 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 Nov 90 01:45:43 GMT From: usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens) Organization: PUCC UNIX Group Subject: Re: IP on a serial line -- which RFC? Message-Id: <1882@mentor.cc.purdue.edu> References: <18466181.ARN13a9@acdhq.north.de> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <18466181.ARN13a9@acdhq.north.de>, kaba@acdhq.north.de (Kai Bartels) writes: > Hy! > I'm currently workin on an implementation of tcp-ip an during this work > i realised that i really don't know how fragments are representated on a > serial line. I don't think it's possible to have it in the same way as > it is on ethernet, 'cause on a serial line you have to know the length of > the fragment BEFORE you get it, so you don'y miss the end. > > So the question is: can anybody tell me which RFC to look at? RFC 791. :-) The IP "length" field is the length of the packet, not the datagram. That is, for a fragment, the "length" field tells you how big the fragment is, but you don't know how big the datagram is until you've received the last of its fragments (RFC 791, page 27, line 1). So, for individual packets, you can read the min header (20 octets) and it tells you how much header & data is there. But, if you want to make your life easier, you can also add your own (or someone else's) link-level protocol and encapsulate IP and whatever else in that. You *will* need this if you do more than just IP stuff on the line. ARP doesn't make much sense on a 2-node network, but if it's more than just a toy implementation, it's better to provide self-identifying packets and while you have that, you might as well add a length field. If you like Ethernet, just send Ethernet "frames" serially. You probably will also want to check out RFC 1055 and maybe 1144. 1055 Romkey, J.L. Nonstandard for transmission of IP datagrams over serial lines: SLIP. 1988 June; 6 p. (Format: TXT=12911 bytes) 1144 Jacobson, V. Compressing TCP/IP headers for low-speed serial links. 1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes) -- +-DLS (dls@mentor.cc.purdue.edu) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112801544200> Received: from alpha.xerox.com by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 12:39:58 PST Received: from AE_Mail_Service_5.ES_AE.Xerox.xns by alpha.xerox.com via XNS id <16419>; Wed, 28 Nov 1990 12:39:05 PST X-NS-Transport-ID: 0000AA009056FB902B14 Date: Wed, 28 Nov 1990 09:54:42 PST From: Paul_S._Lei.El_Segundo@xerox.com Subject: TCP/IP over Macs To: tcp-ip@nic.ddn.mil cc: SKwok.ES_CP8@xerox.com, Paul_S._Lei.El_Segundo@xerox.com Reply-to: PLei.El_Segundo@xerox.com Message-ID: <"28-Nov-90 9:54:42 PST".*.Paul_S._Lei.El_Segundo@Xerox.com> Hello, Is anyone familiar with connection hardware and software available to make Apple Macs talk TCP/IP over ethernet. I'm particularly interested in how such a Mac would print to a network printer or even talk to a line printer deamon. Any info on this and related topics would be very much appreciated. Thanks very much. /Paul Lei PLei.ElSegundo@Xerox.com Lei@arisia.xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112804143700> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 10:16:29 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA16031; Wed, 28 Nov 90 12:34:37 -0500 Date: Wed, 28 Nov 90 12:34:37 -0500 Message-Id: <9011281734.AA16031@ftp.com> To: mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu (Bob Sutterfield) Subject: Re: SLIP From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com Does anybody have a version of SLIP or PPP with SLFP (Serial Line Framing Protocol) support in it? Merit ... does SLFP. Is SLFP HDLC? If not, is SLFP documented in a readily-accessible place? SLFP is another way of encapsulating IP on serial lines that is neither SLIP nor PPP. It has never been written up in an RFC, and if anything exists besides the source code, it is probably an internal MIT LCS document (John? Jerry?). In any case, it was originally supported in the MIT PCIP, but may not have been maintained since 1985 or so. Last summer, Merit asked me for a Packet Driver "class" for SLFP, and I assigned 15 decimal. I haven't seen any drivers yet, nor any patches for existing DOS TCP/IP packages. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112805020400> Received: from clouso.crim.ca by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 07:02:39 PST Received: by clouso.crim.ca (5.57/Ultrix3.0-C) id AA04482; Wed, 28 Nov 90 09:56:31 EST Received: from macgyver.crim.ca.crim.ca by bond.crim.ca (4.0/SMI-4.0) id AA29180; Wed, 28 Nov 90 10:02:04 EST Date: Wed, 28 Nov 90 10:02:04 EST From: boudreau@bond.crim.ca (Guy Boudreault) Message-Id: <9011281502.AA29180@bond.crim.ca> To: tcp-ip@nic.ddn.mil Subject: R please remove my name from your mailing list ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011271626.AA13400@ucbvax.Berkeley.EDU] <1990112805400000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: BSD getsockname() is broken in WIN/TCP for 3B4000??? Message-ID: <9011271626.AA13400@ucbvax.Berkeley.EDU> Date: 28 Nov 90 05:40:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Posted: Wed Nov 28 06:40:00 1990 Hi, Hi, did anybody try to use BSD getsockname() b4? I tried very hard and cannot get it to work. It alswyas return -1, giving t_errno = 4, saying that socket operation on Non-socket. However, the same program I try it on Vax and Sun-3/Sun-4, all of them are working properly. I need this routine to tell what is actual port number return after binding the sock with port number 0. Thanks a lot. - Beng Hang Tay (email: taybengh@nusdiscs.bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011271933.AA18467@ucbvax.Berkeley.EDU] <1990112807100000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: how to get the local port# assigned without using getsockname() Message-ID: <9011271933.AA18467@ucbvax.Berkeley.EDU> Date: 28 Nov 90 07:10:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 10 Posted: Wed Nov 28 08:10:00 1990 Hi Netlander, I am doing socket programming on WIN/TCP for 3B4000. I would like to know how to get back the local port number assigned by system WITHOUT using getsockname(). The getsockname() in WIN/TCP seems NOT working. I need to know the local port number assigned after bind() with port 0. Please reply to me. I am desparate for this. Thanks. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112809010100> Received: from ftp.com by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 14:31:34 PST Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA21073; Wed, 28 Nov 90 17:21:01 -0500 Date: Wed, 28 Nov 90 17:21:01 -0500 Message-Id: <9011282221.AA21073@ftp.com> To: xxseub@osprey.lerc.nasa.gov Subject: Re: Netbios/TCP P/M-node implementations From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: tcp-ip@nic.ddn.mil Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com I have only heard of one P-node/NBNS/NBDD (you can't have one without the others) implementation, done by somebody up in New Hampshire a year or two ago. I got one message from a developer and never have seen it in the market, so it may have died aborning. I don't know what platform they were going to put the NBNS/NBDD on, either... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112810421400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 07:32:38 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15527; Wed, 28 Nov 90 07:21:04 -0800 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 Nov 90 10:42:14 GMT From: usc!samsung!dali.cs.montana.edu!milton!ogicse!intelhf!ichips!inews!intelca!mipos3!scdt!echan@ucsd.edu (Eldon Chan ~ ) Organization: Intel Coporation Subject: Latest proxy-arp daemon on Ultrix and SunOS 4.X Message-Id: <1131@inews.intel.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Can somebody tell me where can I get (FTP) a copy of the latest version of proxy-arp daemon ? In particular the Ultrix version. I have a old version for SunOS, it probably out of date already. Any pointers are appreciated. Thanks Eldon Chan echan@scdt.intel.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112811000000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 05:37:16 PST Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2035; Tue, 27 Nov 90 08:36:27 EST Date: Tue, 27 Nov 90 21:40 H From: Subject: BSD getsockname() is broken in WIN/TCP for 3B4000??? To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH Hi, Hi, did anybody try to use BSD getsockname() b4? I tried very hard and cannot get it to work. It alswyas return -1, giving t_errno = 4, saying that socket operation on Non-socket. However, the same program I try it on Vax and Sun-3/Sun-4, all of them are working properly. I need this routine to tell what is actual port number return after binding the sock with port number 0. Thanks a lot. - Beng Hang Tay (email: taybengh@nusdiscs.bitnet) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112812300000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 08:04:49 PST Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3725; Tue, 27 Nov 90 10:55:49 EST Date: Tue, 27 Nov 90 23:10 H From: Subject: how to get the local port# assigned without using getsockname() To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH Hi Netlander, I am doing socket programming on WIN/TCP for 3B4000. I would like to know how to get back the local port number assigned by system WITHOUT using getsockname(). The getsockname() in WIN/TCP seems NOT working. I need to know the local port number assigned after bind() with port 0. Please reply to me. I am desparate for this. Thanks. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112815543800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 12:02:49 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03775; Thu, 29 Nov 90 09:39:17 -0800 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 Nov 90 15:54:38 GMT From: n8emr!vlink01!root@tut.cis.ohio-state.edu (Superuser) Organization: V-Link Subject: cisco routers Message-Id: <45@vlink01.UUCP> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Could someone tell me the phone number/address for cisco for their routers? Thanks in advance. -- V-Link | System Administration V-Link 1828 Darrow Drive |--------------------------------------- Powell OH 43065-9261 | Local : root 614-365-3056 | Remote: root@vlink01.UUCP ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112816073800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 10:04:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA17655; Wed, 28 Nov 90 08:52:12 -0800 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 Nov 90 16:07:38 GMT From: well!osmana@apple.com (Osman Arslaner) Subject: IBM System 38 TCP/IP Connection. Message-Id: <21854@well.sf.ca.us> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil We would like to connect an IBM System 38 to our TCP/IP backbone ethernet through a terminal server. On the PC side, we would need a 5250 Emulator package which would support INT 14 or BAPI interface. Does such a product exist ? Any help will be appreciated.... Osman Arslaner CN Rail, MONTREAL. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112816230200> Received: from twg.com by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 00:23:02 PST Received: from TWG.COM by twg.com with SMTP ; Wed, 28 Nov 90 18:58:28 PST Received: from leosmac.twg.com by Mercury.TWG.COM id aa22400; 28 Nov 90 17:11 PST To: tcp-ip@nic.ddn.mil From: ljm@TWG.COM Subject: Re: Netbios/TCP P/M-node implementations Message-ID: <9011281711.aa22400@Mercury.TWG.COM> > Are there any commercially/PD implementations of P-node or M-node >NetBIOS servers/clients??... I believe UB, TRW, and CMC have M-node NetBIOS with their onboard TCP/IP products. The big problem with M-node (rather definitionally) is that it doesn't interoperate with all of the B-node implementations which are out there. A number of folk, including ourselves, have implemented NetBIOS to DNS name mapping and/or aliasing to allow NetBIOS over TCP/IP B-node hosts to work over the Internet. To my knowledge, we are the only ones currently shipping product (though I kind of hope James will tell me I'm wrong given his latest release -- that most NetBIOS over TCP/IP implementations provide worse interconnectivity than XNS or NetBEUI is a major embarrassment). enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112817500000> Received: from srlvx0.srl.ford.com by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 21:32:42 PST Date: 28 Nov 90 22:50:00 EST From: "Jerry Damian" Subject: 802.4 conformance testing To: "tcp-ip" Networkers, Does anyone out there know what organizations do 802.4 standards conformance and interoperability testing? A name or organization contact would be greatly appreciated. Jerry Damian - damian@srlvx0.srl.ford.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- ["28-Nov-90..9:54:42.PST".*.Paul_S._Lei.El_Segundo@Xerox.com] <1990112817544200> From: Paul_S._Lei.El_Segundo@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP over Macs Message-ID: <"28-Nov-90..9:54:42.PST".*.Paul_S._Lei.El_Segundo@Xerox.com> Date: 28 Nov 90 17:54:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: PLei.El_Segundo@xerox.com Organization: The Internet Lines: 13 Posted: Wed Nov 28 18:54:42 1990 Hello, Is anyone familiar with connection hardware and software available to make Apple Macs talk TCP/IP over ethernet. I'm particularly interested in how such a Mac would print to a network printer or even talk to a line printer deamon. Any info on this and related topics would be very much appreciated. Thanks very much. /Paul Lei PLei.ElSegundo@Xerox.com Lei@arisia.xerox.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011281205.AA12209@ucbvax.Berkeley.EDU] <1990112819110000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: RE: BSD getsockname() broken in WIN/TCP for AT&T3B4000 (Sys V)??? Message-ID: <9011281205.AA12209@ucbvax.Berkeley.EDU> Date: 28 Nov 90 19:11:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 106 Posted: Wed Nov 28 20:11:00 1990 I received two responses and some further query on this topic. Thanks for the responses. I apologize for not being clear on some aspects. I re-post this coz I have not found any solution yet. Below are the response: From: mni@techops.cray.com (Michael Nittmann) Message-Id: <9011271706.AA26409@techops.cray.com> Subject: Re: BSD getsockname() is broken in WIN/TCP for 3B4000??? >Hi, >so on what machine does it NOT work? As the title suggested, the machine is an AT&T 3B4000 multiprocessor (I think it is under 3B2 family). The TCP is an WIN product for 3B series. >Maybe you have a wild horse of a machine that has a broken view of >file systems and sockets. Are you on a localhost connection? >Is your socket may be a UNIX domain socket (some broken implementations >implicit unix domain for localhost sockets) and can your machine The domain of the socket is AF_INET, NOT AF_UNIX. I am aware of the problem of the UNIX domain scoket. >(better it's system programmers) find no other kernel hook than an >inode (this case the kernel thinks your socket is a file and may if >broken give up too soon when you want to have the socket's address >structure back). could u please tell me how check on it? >Maybe also your error number is wrong and you did not specify >for namelength how much buffer you allocated? I am using perror(), am I missing any thing? >Sounds like you should scrap that machine. I hope so if I have the the say on it. I am just an user/programmer, not a decision maker. From: "Michael J. Saletnik - Local Unix Wizard's Apprentice" Subject: Re: BSD getsockname() is broken in WIN/TCP for 3B4000??? To: TAYBENGH@NUSDISCS.BITNET Message-id: <9011271616.AA01750@jupiter.end.tufts.edu> >What exactly are you trying to do? I am actually writing higher-level Inter-machine-communication interfaces based on socket. One of the routine is socket creation which is: int inet_crt(protype, local_port) int protype; /* protocol type */ u_short *local_port; /* local port number, if 0 is given, it will give a unique port number and assigned to local_port */ { int id, len; struct sockaddr_in local_sock; if ((id = socket(AF_INET, protype, 0)) < 0) inet_err("inet_crt(): socket()") ....... /* * bind the socket */ if (bind(id, &local_sock, sizeof(local_sock)) < 0) inet_err("inet_crt(): bind()") /* * get the actual port number assigned */ len = sizeof(local_sock); -> if (getsockname(id, &local_sock, &len)) -> inet_err("inet_crt(): getsockname()") ->Remark: getsockname() works in both Sun-3 and Sun-4 (SunOS 4.0 & 4.1). -> However, it did not work on TCP/IP WIN/3B for an AT&T3B4000!!! -> WHY??? *local_port = ntohs(local_sock.sin_port); return(sock); } >If you have a sockaddr_in structure associated with the socket, which you >should > , >after the bind look at >struct sockaddr_in fubar; >unsigned long port; >port = fubar.sin_port; >If I'm totally clueless as to what you're doing, possibly a more detailed >description or a code fragment.... Well, I did tried using your method b4, but it simply return 0 :-(. Before bind(), the port=0; After bind(); I tried to print out the port number, it is still 0 at both Sun-4 and AT&T machines. That's mean the bind() did not modify the struct sockaddr_in. Am I rite? Thanks. Hope to hear from all of you soon. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112821105700> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 14:30:33 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14043; Thu, 29 Nov 90 14:07:34 -0800 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 Nov 90 21:10:57 GMT From: mstan!jordan@uunet.uu.net (Jordan Hayes) Organization: Morgan Stanley, & Co., Inc. / New York City, NY Subject: Re: Formation of the UK Internet Consortium Message-Id: <2276@s5.Morgan.COM> References: <1990Nov21.180716.29399@ibmpcug.co.uk> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > ip-interest@independent.uucp ~~~~ Indeed! /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112822194800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 11:23:29 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05791; Thu, 29 Nov 90 10:28:43 -0800 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 Nov 90 22:19:48 GMT From: eru!hagbard!sunic!mcsun!corton!litp!inria!dupont@bloom-beacon.mit.edu (Francis Dupont) Organization: INRIA, Rocquencourt, France. Subject: Re: X25 over IP Message-Id: <1900@inria.inria.fr> References: <9011271721.AA06559@isis.u-strasbg.fr> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011271721.AA06559@isis.u-strasbg.fr>, pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes: > > Is there a standard way to run X25 over IP (not the other way around, IP > over X25 ). We would like to use our IP network to carry non IP traffic > over X25. > ... Cisco has a X.25 over TCP. It is useful for instance for PAD (X.3/X.28/X.29). (OSI applications can use RFC 1086 "ISO-TP0 bridge between TCP and X.25" but it is not possible for native usage of X.25 like PAD). The transport of X.25 packets over TCP connections is very simple, I've implemented it for Suns and I'm writing a description of it. Francis.Dupont@inria.fr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112823161400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 13:49:28 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01457; Wed, 28 Nov 90 16:53:41 -0800 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 Nov 90 23:16:14 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Re: Limited version of telnet Message-Id: References: <2974.27527950@miavx1.acs.muohio.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <2974.27527950@miavx1.acs.muohio.edu> pemurray@miavx1.acs.muohio.edu (Peter Murray) writes: I'm looking for a limited version of TELNET. This program would only allow connections to one host or a list of hosts in a text file. What I don't want is this program to is to domain lookups. May I suggest that it looks up the name of the host to connect to in a table to find if it's acceptable, and then do the domain name lookup to find the address? You don't want to reconfigure more than you have to when addresses change, and you don't want the text table to contain errors. Morale: Always use the DNS. -- [Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY Mail: , My opinions. Wail: +47-2-836-863 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112823510400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 12:23:26 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03531; Wed, 28 Nov 90 18:20:44 -0800 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 Nov 90 23:51:04 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Re: Question about Socket Message-Id: References: <33562@netnews.upenn.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <33562@netnews.upenn.edu>, Menq J. Lee writes: I am new to this field, and I am using DGRAM Socket (UDP) to build a remote copy utility. This utility supports both ascii and binary file transfers. You may find that FTP [1] does what you need, albeit with a little more overhead. FTP uses TCP, because it doesn't want to bother with retransmission, congestion problems, etc. Neither should you. For a local area network remote copy utility, there exists the Berkeley Unix system rcp(1). I believe it's freely available from Berkeley source repositories like UUNET.UU.NET via anonymous FTP. It's not recommended between different users because of security related deficiencies. You may also look into NFS [2] if this is part of a file system design. You may want to look at TFTP [3] for a very simple approach to file transfer and remote file copying. I have no problem in handling binary transfer. But when it comes to ascii transfer, the reference I read told me that I must take care of some critical cases. Specifically, I have to do some conversion between newline <---> CR,LF (Carriage Return, Line Feed) CR <---> CR,NULL I have the following questions about this issue: 1. Why is this necessary? In other words, under what situations will this conversion be employed to avoid foreseeable errors? It is necessary because you want to relieve your client under operating system X from knowing about the line termination conventions of operating system Y. This becomes progressively more pressing for large sets of operating systems and conventions. 2. Do I have to do the same conversion if I use STREAM Socket (TCP) instead of DGRAM Socket? Yes. You have to do a lot less work if you start using TCP, though. ----- [1] RFC 959 File Transfer Protocol. (See also RFC 1068 Background File Transfer Program.) [2] RFC 1094 NFS: Network File System Protocol Specification [3] RFC 783 TFTP Protocol (revision 2) -- [Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY Mail: , My opinions. Wail: +47-2-836-863 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112823554100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 13:50:18 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA29812; Wed, 28 Nov 90 15:57:25 -0800 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 Nov 90 23:55:41 GMT From: virga.rap.ucar.edu!tres@handies.ucar.edu (Tres Hofmeister) Organization: Research Applications Program/NCAR, Boulder, CO Subject: Reliability of SLIP Message-Id: <9330@ncar.ucar.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm interested in finding a source of information for SLIP. I'm interested in issues such as reliability, ease of installation (under SunOS 4.1, specifically), phone line requirements, etc. Any information would be appreciated. Please respond via email, I rarely get the chance to read the group... -- Tres Hofmeister tres@ncar.ucar.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112823582100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 09:01:12 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA03569; Wed, 28 Nov 90 18:21:13 -0800 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 Nov 90 23:58:21 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu (Erik Naggum) Organization: Naggum Software, Oslo, Norway Subject: Re: IP on a serial line -- which RFC? Message-Id: References: <18466181.ARN13a9@acdhq.north.de>, <1882@mentor.cc.purdue.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1882@mentor.cc.purdue.edu>, David L Stevens writes: You probably will also want to check out RFC 1055 and maybe 1144. 1055 Romkey, J.L. Nonstandard for transmission of IP datagrams over serial lines: SLIP. 1988 June; 6 p. (Format: TXT=12911 bytes) 1144 Jacobson, V. Compressing TCP/IP headers for low-speed serial links. 1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes) In addition to these two documents, a full-blown point-to-point protocol has been developed. (Serial lines is the archetypical point-to-point link...) 1172 Perkins, D.; Hobby, R. Point-to-Point Protocol (PPP) initial configuration options. 1990 July; 38 p. (Format: TXT=76132 bytes) You may also find this document interesting. -- [Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY Mail: , My opinions. Wail: +47-2-836-863 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112900162600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 13:50:08 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA00641; Wed, 28 Nov 90 16:21:34 -0800 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 Nov 90 00:16:26 GMT From: sdd.hp.com!caen!ox.com!b-tech!zeeff@ucsd.edu (Jon Zeeff) Organization: Branch Technology Subject: Re: SLIP Message-Id: <$8Y_27+@b-tech.uucp> References: <9011281734.AA16031@ftp.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil > Is SLFP HDLC? If not, is SLFP documented in a readily-accessible > place? > >SLFP is another way of encapsulating IP on serial lines that is neither SLIP "slfp.info" is available for anon ftp in ais.org:/pub. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112900310000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Tue, 27 Nov 90 21:08:39 PST Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6103; Wed, 28 Nov 90 00:07:04 EST Date: Wed, 28 Nov 90 11:11 H From: Subject: RE: BSD getsockname() broken in WIN/TCP for AT&T3B4000 (Sys V)??? To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH I received two responses and some further query on this topic. Thanks for the responses. I apologize for not being clear on some aspects. I re-post this coz I have not found any solution yet. Below are the response: From: mni@techops.cray.com (Michael Nittmann) Message-Id: <9011271706.AA26409@techops.cray.com> Subject: Re: BSD getsockname() is broken in WIN/TCP for 3B4000??? >Hi, >so on what machine does it NOT work? As the title suggested, the machine is an AT&T 3B4000 multiprocessor (I think it is under 3B2 family). The TCP is an WIN product for 3B series. >Maybe you have a wild horse of a machine that has a broken view of >file systems and sockets. Are you on a localhost connection? >Is your socket may be a UNIX domain socket (some broken implementations >implicit unix domain for localhost sockets) and can your machine The domain of the socket is AF_INET, NOT AF_UNIX. I am aware of the problem of the UNIX domain scoket. >(better it's system programmers) find no other kernel hook than an >inode (this case the kernel thinks your socket is a file and may if >broken give up too soon when you want to have the socket's address >structure back). could u please tell me how check on it? >Maybe also your error number is wrong and you did not specify >for namelength how much buffer you allocated? I am using perror(), am I missing any thing? >Sounds like you should scrap that machine. I hope so if I have the the say on it. I am just an user/programmer, not a decision maker. From: "Michael J. Saletnik - Local Unix Wizard's Apprentice" Subject: Re: BSD getsockname() is broken in WIN/TCP for 3B4000??? To: TAYBENGH@NUSDISCS.BITNET Message-id: <9011271616.AA01750@jupiter.end.tufts.edu> >What exactly are you trying to do? I am actually writing higher-level Inter-machine-communication interfaces based on socket. One of the routine is socket creation which is: int inet_crt(protype, local_port) int protype; /* protocol type */ u_short *local_port; /* local port number, if 0 is given, it will give a unique port number and assigned to local_port */ { int id, len; struct sockaddr_in local_sock; if ((id = socket(AF_INET, protype, 0)) < 0) inet_err("inet_crt(): socket()") ....... /* * bind the socket */ if (bind(id, &local_sock, sizeof(local_sock)) < 0) inet_err("inet_crt(): bind()") /* * get the actual port number assigned */ len = sizeof(local_sock); -> if (getsockname(id, &local_sock, &len)) -> inet_err("inet_crt(): getsockname()") ->Remark: getsockname() works in both Sun-3 and Sun-4 (SunOS 4.0 & 4.1). -> However, it did not work on TCP/IP WIN/3B for an AT&T3B4000!!! -> WHY??? *local_port = ntohs(local_sock.sin_port); return(sock); } >If you have a sockaddr_in structure associated with the socket, which you >should > , >after the bind look at >struct sockaddr_in fubar; >unsigned long port; >port = fubar.sin_port; >If I'm totally clueless as to what you're doing, possibly a more detailed >description or a code fragment.... Well, I did tried using your method b4, but it simply return 0 :-(. Before bind(), the port=0; After bind(); I tried to print out the port number, it is still 0 at both Sun-4 and AT&T machines. That's mean the bind() did not modify the struct sockaddr_in. Am I rite? Thanks. Hope to hear from all of you soon. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9011281344.AA13706@ucbvax.Berkeley.EDU] <1990112902050000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: anybody use ioctl() with /netinclude/inetioctl.h in TCP/IP WIN3B? Message-ID: <9011281344.AA13706@ucbvax.Berkeley.EDU> Date: 29 Nov 90 02:05:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Posted: Thu Nov 29 03:05:00 1990 hi, netlander, I read through the WIN/TCP for 3B series, and can NOT any documntation about ioctl() call on socket. As a result, I read the /netinclude/inetioctl.h and found out WIN has defined several control blocks and options for IP, TCP and UDP such as strcut tcpioctl. Did anybody use the ioctl() call with various options such as TCPIOC_GETMYPORT, TCPIOC_GETSOCKNAME? If so, what is the parameters that I can pass in for the third arguments for ioctl()??? Could somebody point me any reference that I can use the ioctl() on socket? Thanks a lot. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112903295600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 12:03:06 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA02912; Thu, 29 Nov 90 09:21:33 -0800 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 Nov 90 03:29:56 GMT From: munnari.oz.au!cs.mu.OZ.AU!kre@THEORY.TN.CORNELL.EDU (Robert Elz) Subject: Re: Telnet's ECHO option Message-Id: <6131@munnari.oz.au> References: Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , gm@ionic.UUCP (Greg Miller) writes: > However, whenever I try this > when I'm connected to a BSD machine, the host accepts my DONT ECHO, > replies with WONT ECHO, and then procedes to continue echoing anyways. There's been a lot of discussion on the nature of DO ECHO / DONT ECHO, etc, in response to this, but I don't recall much discussion on the actual problem being reported. I believe that BSD systems get "DONT ECHO" right, when you ask for them to not echo, they don't. But note that "DONT ECHO" is not "DONT OUTPUT" - ie: you still get any output that processes want to generate (of course). The perceived problem is really that some of what seems to be echo is really program output - it just appears as if it may be echo. In particular, the "login" program outputs the login name that you enter (character by character). This is not "echo", its program output, and as such, the telnet echo options have nothing to do with it whatever. kre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9012011014.AA29054@ucbvax.Berkeley.EDU] <1990112903500000> From: damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") Newsgroups: comp.protocols.tcp-ip Subject: 802.4 conformance testing Message-ID: <9012011014.AA29054@ucbvax.Berkeley.EDU> Date: 29 Nov 90 03:50:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Posted: Thu Nov 29 04:50:00 1990 Networkers, Does anyone out there know what organizations do 802.4 standards conformance and interoperability testing? A name or organization contact would be greatly appreciated. Jerry Damian - damian@srlvx0.srl.ford.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112907250000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Wed, 28 Nov 90 02:02:47 PST Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0831; Wed, 28 Nov 90 05:02:07 EST Date: Wed, 28 Nov 90 18:05 H From: Subject: anybody use ioctl() with /netinclude/inetioctl.h in TCP/IP WIN3B? To: tcp-ip@nic.ddn.mil X-Original-To: tcp-ip@nic.ddn.mil, TAYBENGH hi, netlander, I read through the WIN/TCP for 3B series, and can NOT any documntation about ioctl() call on socket. As a result, I read the /netinclude/inetioctl.h and found out WIN has defined several control blocks and options for IP, TCP and UDP such as strcut tcpioctl. Did anybody use the ioctl() call with various options such as TCPIOC_GETMYPORT, TCPIOC_GETSOCKNAME? If so, what is the parameters that I can pass in for the third arguments for ioctl()??? Could somebody point me any reference that I can use the ioctl() on socket? Thanks a lot. - Beng Hang Tay (email: taybengh@nusdiscs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112907500200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 12:01:09 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05049; Thu, 29 Nov 90 10:10:38 -0800 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 Nov 90 07:50:02 GMT From: eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu (Ricard Wolf) Organization: Lund Institute of Technology, Sweden Subject: Re: Question about Socket Message-Id: <1990Nov29.075002.6996@lth.se> References: <33562@netnews.upenn.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article enag@ifi.uio.no (Erik Naggum) writes: >In article <33562@netnews.upenn.edu>, Menq J. Lee writes: .... > > I have no problem in handling binary transfer. But when it comes to > ascii transfer, the reference I read told me that I must take care > of some critical cases. Specifically, I have to do some conversion > between > > newline <---> CR,LF (Carriage Return, Line Feed) > CR <---> CR,NULL > > I have the following questions about this issue: > > 1. Why is this necessary? In other words, under what > situations will this conversion be employed to avoid > foreseeable errors? > >It is necessary because you want to relieve your client under operating >system X from knowing about the line termination conventions of >operating system Y. This becomes progressively more pressing for large >sets of operating systems and conventions. If you use FTP in the ascii transfer mode (whcih is the default) this is taken care of automagically. -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112909561000> Received: from sun2.nsfnet-relay.ac.uk by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 09:56:05 PST Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <12780-22@sun2.nsfnet-relay.ac.uk>; Thu, 29 Nov 1990 11:43:21 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa04058; 29 Nov 90 9:42 GMT Via: dcs.leeds.ac.uk (csvax1.ARPA); Thu, 29 Nov 90 09:58:08 GMT Received: from csunb0.dcs.leeds.ac.uk (csunb0.ARPA) by dcs.leeds.ac.uk; Thu, 29 Nov 90 09:55:45 GMT From: J Jackson Date: Thu, 29 Nov 90 09:56:10 GMT Message-Id: <7084.9011290956@csunb0.dcs.leeds.ac.uk> Received: from csunb6.dcs.leeds.ac.uk by csunb0.dcs.leeds.ac.uk; Thu, 29 Nov 90 09:56:10 GMT To: tcp-ip@nic.ddn.mil Subject: Re: Reducing the risks when connecting to an internet > > In article <1990Nov26.151017.2023@hemel.bull.co.uk> pmoore@hemel.bull.co.uk (Paul Moore) writes: > > pmoore> Gosh, I am glad to see somebody making that point, ("security is a host > pmoore> problem not a net problem"). > > Security is both a network and a host problem. The more defences you > have, the better protected you are. > > Compare with a military base (a network). Even though they think that > the safe (the host) holding the codebooks is secure, they still don't > let you anywhere near it! > > Similarly, even though the Bank of England beleives that their vaults > are secure, they still don't hand out the plans. > > ....stuff deleted..... > > -- > Philip Gladstone Dev Lab Europe, Data General, Cambridge, UK I prefer to make the analogy between the transport system (the network) and the bank (the host). I sure as hell would object to being stopped at major highway junctions and told to identify myself. However I'd object if I wasn't asked to identify myself at the bank. ======================================================================= Jim Jackson Email : School of Computer Studies UK - JANET : jj@uk.ac.leeds.dcs Leeds University Internet : jj@dcs.leeds.ac.uk Leeds LS2 9JT UK Phone : +44 532 335451 ======================================================================= Opinions! What Opinions? I just wield the brush round here. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112912070000> Received: from CUNYVM.CUNY.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 14:54:26 PST Received: from GBURG.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1790; Thu, 29 Nov 90 17:53:39 EST Date: Thu, 29 Nov 90 16:07 EDT From: Jonathan Kruger Subject: whoisd To: tcp-ip@nic.ddn.mil Message-id: X-Envelope-to: tcp-ip@nic.ddn.mil X-VMS-To: IN%"tcp-ip@nic.ddn.mil" Hi, I'm trying to get a campus wide whois server going on our Sun 4. I'd like to avoid re-inventing the wheel, but the only whoisd program I found out in anonymous FTPland was the one written at the University of Virginia. While it seems to work rather well for them, it's thoroughly undocumented, and is geared for supporting 60K+ users, while we have only about 3K users here. If anyone can point me in the right direction I will be most grateful... Jonathan Kruger Computing Services Gettysburg College ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112919174400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 16:18:00 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16286; Thu, 29 Nov 90 15:07:48 -0800 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 Nov 90 19:17:44 GMT From: sgi!shinobu!odin!speaker!coolidge@ucbvax.Berkeley.EDU (Don Coolidge) Organization: Silicon Graphics Inc., Mtn. View, CA Subject: Re: Interoperating with HP Message-Id: <1990Nov29.191744.7372@odin.corp.sgi.com> References: <9011271533.AA01752@desktalkdesktalk.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <9011271533.AA01752@desktalkdesktalk.com> rlg@desktalkdesktalk.com (Richard L. Gralnik) writes: >Hi gang, >We are on the verge of great things, but I figure I'm better off forewarned >so... > >Does anyone have experience connecting a > > Sequent (Dynix 3.0.17) > >to an > > HP 3000 (MPE/V Delta 5) with > HP's LANIC board and TCP/IP software > Wollongong ARPA Services for MPE TCP/IP > >I have been warned off telneting from the HP, but any other gotchas would >be appreciated. The only real gotcha you have to watch out for is that native MPE doesn't support either ARP or Ethernet - it encapsulates in 802.3 and does address resolution with HP's Probe protocol. So, there's no way for the Sequent to communicate with the MPE box on its own, if native MPE/V is all that's on the HP. However, there are two ways to deal with this: 1) ARP and Ethernet can be bought for the latest Delta of MPE/V (sorry, I don't know if Delta 5 is the latest). Contact your HP rep. 2) If that won't work for you, you can put a cisco gateway between the two - cisco speaks Probe and 802.3. I also suspect (but don't know for sure) that some Wellfleet routers have the same capability. Finally, at InterOp I saw gateways at the HP booth with the HP logo on them. I'm sure that they, too, can translate. Once you get over that hurdle, you'll be able to use the Wollongong services to talk with their un*x cousins on the Sequent without much further ado. - Don Coolidge coolidge@speaker.wpd.sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112921255900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 16:18:11 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16010; Thu, 29 Nov 90 14:59:58 -0800 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 Nov 90 21:25:59 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) Organization: Rockwell CMC Subject: Re: Internet Access Costs Message-Id: <1990Nov29.212559.7284@spectrum.CMC.COM> References: <315@srchtec.UUCP>, <1990Nov26.233848.20828@nmt.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes: >>One other item: PSI says we will not have a constant IP #. It supposedly >>changes each time we establish a connection with them. However, our address >>will remain constant (probably searchtech.com). In article <1990Nov26.233848.20828@nmt.edu> rmilner@zia.aoc.nrao.edu (Ruth Milner) writes: >I fail to see how this can be the case. Granted they can change their tables >any time they want, *but* they have the following restrictions: > > a) they have to use an Internet number assigned to them/you by the NIC > b) the rest of the Internet has to understand the routing (if it's > advertised, and if it isn't no-one can reach you) > c) your system has to know *before establishing the connection* what > its own Internet address is > ... >Even if it *could* be done, it would be such an administrative nightmare >trying to figure out "who's 123.456.789.10 this morning?" that I can't think >why they *would* do it. > >Ruth Milner >Systems Manager NRAO/VLA Socorro NM Ruth, The network number stays constant, the IP address changes. (The confusion seems to have been caused by a bad choice of words: The posting says "internet number" for "IP address" and "address" for "fully qualified domain name".) Crazy as it seems at first glance, dynamic IP addresses are not actually all that unusual. Client-only PC's often do this. And with domain name service, it is doable even to handle incoming connections. Yes, it does create a few management hassles. You need to have a name server with a transaction interface to change the name/address mappings on the fly (where the run-of-the-mill BIND just reads a table when it is reloaded) and you cannot have management utilities that assume that name/address mappings are constant. But technically, at the low level, it is no harder than ARP. You need an ARP-like handshake before you switch to IP mode. Most SLIP interfaces already have a handshake (unix login !) before turning into IP interfaces, so there definitely is a mechanism to do that. As to WHY one wants to do this ? When you have a couple hundred PC's around, it is easier to just declare them to be generic than to try to keep track of locations and owners for all of them. Likewise, network providers may have only allocated class C network numbers for a routing cluster, and may prefer the dynamic addresses over changing backbone routing implementations with hardcoded netmasks. / Lars -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112922011200> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 15:47:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16956; Thu, 29 Nov 90 15:23:39 -0800 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 Nov 90 22:01:12 GMT From: snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@bloom-beacon.mit.edu (Peter Murray) Subject: Re: Limited version of telnet Message-Id: <3003.27553ed9@miavx1.acs.muohio.edu> References: <2974.27527950@miavx1.acs.muohio.edu>, Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article , enag@ifi.uio.no (Erik Naggum) writes: > In article <2974.27527950@miavx1.acs.muohio.edu> pemurray@miavx1.acs.muohio.edu (Peter Murray) writes: > > I'm looking for a limited version of TELNET. This program would > only allow connections to one host or a list of hosts in a text > file. What I don't want is this program to is to domain lookups. > > May I suggest that it looks up the name of the host to connect to in a > table to find if it's acceptable, and then do the domain name lookup > to find the address? > > You don't want to reconfigure more than you have to when addresses > change, and you don't want the text table to contain errors. > > Morale: Always use the DNS. Excellent suggestion. Thank you. If/when I have to write this, it will have this function. If no one has seen any software to do this, can someone please e-mail me a site that has the telnet source. Thanks. Peter -- Peter Murray Neat UNIX Stunts #5: pemurray@miavx1.bitnet 176 Thompson Hall sh> drink Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 15:28:56 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16760; Thu, 29 Nov 90 15:18:59 -0800 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 Nov 90 22:06:36 GMT From: mintaka!think.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu@bloom-beacon.mit.edu (Dana A. Bunner) Organization: University of Wisconsin Academic Computing Center Subject: Looking for DOS Windows 3 TELNET Message-Id: <4855@dogie.macc.wisc.edu> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for an MS/DOS Windows 3.0 compatible version of TELNET. We would prefer somewhat capable of running in a window. We are currently using the Clarkson product but it's limited data capture and "cut and paste" capabilities are inconvenient. If someone has knowledge of such a product please E-Mail me. Thanks, Dana Alan Bunner, Asst Dir, UW-Madison Academic Computing Center 1210 W. Dayton St. Madison, WI 53706 (608) 262-4418 ARPANET: bunner@macc.wisc.edu BITNET: bunner@wiscmacc.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990112922494900> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 18:43:11 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA22200; Thu, 29 Nov 90 18:30:14 -0800 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 Nov 90 22:49:49 GMT From: bbs!karl@uunet.uu.net (Karl Denninger) Organization: A.C. Nielsen Bannockburn, IL Subject: IBM Mainframe SNA to TCP/IP Hosts; X-windows, etc Message-Id: <1990Nov29.224949.16610@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hello net.oracle. We're in desparate need of the following: o) An X-based solution to 3270 emulation and file transfer, which can run over something similar to (or actually a) Mitek gateway or o) Unix and PC (under B&W NFS, or NETBIOS) solutions to the above. So far we have been spectacularly unsuccessful in doing this. We NEED to get from our environments here (BWNFS and Workstation) based to the mainframe environment! Any help or pointers appreciated. Pay-for software and harware are fine, ads are fine, free stuff is fine, anything we can get our hands on that WORKS. The tn3270 application does not work AT ALL, since our host system insists on sending "write structured field" calls, and we can't reply to them (the defines are there in the code source, but there's no code to back them up). We've been unsuccessful in locating a more recent version of the code. CUTCP (ie: Clarkson's CUTE Telnet 3270) doesn't work either, for the same reason. We're about to run out of options here; any help is GREATLY appreciated. We can do X11 on all the platforms, but we need a way to do the mainframe connectivity. Thanks in advance. Ads and all advice welcome. -- -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113000015100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 29 Nov 90 16:42:53 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA19270; Thu, 29 Nov 90 16:35:29 -0800 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 Nov 90 00:01:51 GMT From: lll-crg.llnl.gov@lll-winken.llnl.gov (Mark Boolootian) Organization: Lawrence Livermore National Laboratory Subject: reuse of addresses when calling bind() Message-Id: <86984@lll-winken.LLNL.GOV> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I've got a meeting in a couple minutes so I'm going to try and ask this quickly. If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able to issue a bind() for a ip/port address that is already in use. However, it appears that it is still possible for bind() to return the error EADDRINUSE (for example, look at routine getdatasock() in ftpd.c where they have a loop that retries the bind() several times before giving up, all the while checking for EADDRINUSE). What I'd like to know is why this happens, in lieu of the call to setsockopt(). Thanks in advance. Email would be nice but I'll wade through stuff if need be. regards, mb booloo@lll-crg.llnl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113002040600> Received: from NNSC.NSF.NET by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 07:24:59 PST To: tcp-ip@nic.ddn.mil Subject: Call for Papers SIGCOMM '91 From: Craig Partridge Date: Fri, 30 Nov 90 10:24:06 -0500 Sender: craig@NNSC.NSF.NET Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presenta- tion and discussion of communication network applications and technologies, as well as recent advances and proposals on commun- ication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its confer- ence outside of North America. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innova- tive results in local area networks, computer-supported coopera- tive work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in North America, to the North American program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: or The North American program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: g_f_wetzel@att.com Naperville, IL 60566 For more information about the conference, e-mail to sigcomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visu- alization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstand- ing student papers will be awarded (1) one full conference regis- tration and (2) a travel grant of US $1000. To be eligible, student(s) must be the primary contributor(s) to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113003501800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 12:26:16 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA05226; Fri, 30 Nov 90 11:57:32 -0800 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 Nov 90 03:50:18 GMT From: bbs!karl@uunet.uu.net (Karl Denninger) Organization: A.C. Nielsen Bannockburn, IL Subject: Packet Drivers and 3COM coexistance; we need 3COM Netbios Message-Id: <1990Nov30.035018.28695@naitc.naitc.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Hi Usenet.oracle. Again, I come to the well. We have an interesting situation here. We have a 3COM Netbios application (the Maxess gateway) which we would like to use with TCP/IP. We have a Netbios-over-TCP implementation, but it doesn't seem to work with that. Thus, our next attack point: We are using packet drivers. Does anyone know how to get the packet drivers to work with someone's TCP/IP (ie: B&Ws) and 3COM's 3+OPEN Netbios drivers at the same time? We don't care about redirectors or other 3COM services at this point -- only NETBIOS. Two adapters in a machine is not an acceptable alternative. If anyone has made this work, please let us know how you did it! I haven't seen any references to this feat of magic yet... but perhaps it can be done. Email or posts appreciated. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113004004600> Received: from ASNTSU.asn.net by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 07:58:55 PST Received: from ASNTSU.asn.net by ASNTSU.asn.net (IBM VM SMTP R1.2.1) with BSMTP id 1372; Fri, 30 Nov 90 10:00:58 CST Date: Fri, 30 Nov 90 10:00:46 CST From: MAINT@ASNTSU.asn.net To: tcp-ip@nic.ddn.mil I am interested in SLIP and need the RFC for it. Can some one tell me what the RFC for it is and where I can get it? Please respond directly to me as I am not a regular subscriber to this list. Thanks in advance. -------------------------------------------------------------------------------- Dennis Putnam, Service Manager Boeing Computer Services Alabama Supercomputer Network +---------------------+ |UNA A&M | |NFDC-------C--UAH | | / \ | | | | JSU| | _____UAB-+----/ | | UA | | | | ____AU | | DSMD | | ASU | \ | | / TSU | | / | | / | | / | | _USA---------------+ |/ \_| ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113004430000> Received: from uc.msc.edu by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 05:43:26 PST Received: from win1.ce.com by uc.msc.edu (5.59/MSC-2.01/900718) id AA15278; Fri, 30 Nov 90 07:43:35 CST Message-Id: <9011301343.AA15278@uc.msc.edu> Date: 30 Nov 90 08:43:00 EDT From: "SDAV01::ZENTELIS" Subject: Looking for SPIDER's address To: "tcp-ip" Hi I'm looking for SPIDER:s address in Great Britain or SPIDERS:s reseller in Sweden. My mailing address is : ZENTELIS%SDAV01.DECnet@WIN1.IMS.ABB.COM Nicolas Zentelis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113005591600> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 13:34:46 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA01603; Fri, 30 Nov 90 10:35:51 -0800 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 Nov 90 05:59:16 GMT From: wuarchive!zaphod.mps.ohio-state.edu!usc!barnard.usc.edu!jconti@eddie.mit.edu (John Conti) Subject: wanted: snmp mib compiler Message-Id: <28523@usc> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I'm looking for the program used to manipulate SNMP MIBs (usually called a mib compiler). I have a general ASN.1 compiler but I need to maim my mib.txt. Email is probably the best way to reply, I'll resend to whoever wishes it. TIA. -- ,John John Conti { jconti@usc.edu | jconti@xenon.usc.edu (NeXT mail) } Computing Services, University of Southern California, (213)740-2957 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113008375700> Received: from mathom.cisco.com by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 17:30:56 PST Date: Fri 30 Nov 90 16:37:57-PST From: William "Chops" Westfield Subject: TCP options... To: tcp-ip@nic.ddn.mil Message-ID: <12642163454.13.BILLW@mathom.cisco.com> TCP options are apparently not included in the sequence space - At least, all the implementations I see have the first datagram after the syn/mss packet with a sequence number 1 greater than the syn (which covers the syn, but not the 4 bytes of tcp options that make up the mss option.) HR rfc requires that TCPs accept options in any packet - does this actually mean that in order to ensure reliable delivery of an option, it has to be sent in a packet that also contains data? Sure seems that way... BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113009151500> Received: from psi.com by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 15:33:07 PST Received: from localhost by psi.com (5.61/2.1-Performance Systems International) id AA26040; Fri, 30 Nov 90 17:35:16 -0500 Message-Id: <9011302235.AA26040@psi.com> To: Jonathan Kruger Cc: tcp-ip@nic.ddn.mil Subject: Re: whoisd In-Reply-To: Your message of Thu, 29 Nov 90 16:07:00 -0400. Date: Fri, 30 Nov 90 17:35:15 -0500 From: "Martin Lee Schoffstall" Johathan, While you do not yet appear to be on the Internet, you may want to take a look at the WhitePages service that is available using X.500, it is a much larger protocol/implementation means to use, but it's utility is much greater. Send email to wp-info@psi.com and it will point you to technical reports, software, instructions, etc.. Marty ------------ Hi, I'm trying to get a campus wide whois server going on our Sun 4. I'd like to avoid re-inventing the wheel, but the only whoisd program I found out in anonymous FTPland was the one written at the University of Virginia. While it seems to work rather well for them, it's thoroughly undocumented, and is geared for supporting 60K+ users, while we have only about 3K users here. If anyone can point me in the right direction I will be most grateful... Jonathan Kruger Computing Services Gettysburg College ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1990Nov30.130305.20835@lavaca.uh.edu] <1990113013030500> From: dinah@karazm.math.uh.edu (Dinah McNutt) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk Subject: Product Informatation Message-ID: <1990Nov30.130305.20835@lavaca.uh.edu> Date: 30 Nov 90 13:03:05 GMT Sender: nntppost@lavaca.uh.edu (NNTP Posting Service) Distribution: usa Organization: Technology Transfer Associates Lines: 26 I am interested in information on different ways to connect MACs, PCs (386 and 486 types), and UNIX systems. Functionality requirements include mail, remote login, file sharing, file transfer, printer sharing, and net news. I am particularly interested in software that provides all the above plus can handle PC-PC communications well. Also, some of the systems I am dealing with are already on a Novell or Appletalk network. (Some of the PCs and MACs are currently standalone as well.) I would also like information on the following: Beam and Whiteside's PC-NFS product Intercom's Netnews and TN3270 products MacPathway from The Wollongong Group Star*9 and anything else that might be available. Thanks, Dinah -- Dinah McNutt Senior Staff Scientist Technology Transfer Associates Houston, Texas internet: dinah@bcm.tmc.edu uucp: {rutgers,mailrus}!bcm!dinah ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113013422800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 14:20:51 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA09380; Fri, 30 Nov 90 13:36:59 -0800 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 Nov 90 13:42:28 GMT From: eru!hagbard!sunic!mcsun!ukc!slxsys!jpp@bloom-beacon.mit.edu (John Pettitt) Organization: Specialix International, London Subject: Re: Formation of the UK Internet Consortium Message-Id: <1990Nov30.134228.11758@specialix.co.uk> References: <1990Nov21.180716.29399@ibmpcug.co.uk>, <2276@s5.Morgan.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil jordan@Morgan.COM (Jordan Hayes) writes: >> ip-interest@independent.uucp > ~~~~ >Indeed! >/jordan Exactly our point ! There is (or rather was) no IP offering in the UK hence the .uucp (getting a .co.uk or .ac.uk takes ages due to the organizations involved). John Pettitt Specialix International (One of the founder members, UK Internet Consortium) john.pettitt@specialix.co.uk or john.pettitt@specialix.com -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting ! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113014340000> Received: from NRI.Reston.VA.US by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 08:42:03 PST Received: from mcimail.com by NRI.NRI.Reston.VA.US id ac04881; 30 Nov 90 9:32 EST Date: Fri, 30 Nov 90 14:34 GMT From: Bob Stine <0004219666@mcimail.com> To: Dave Wiltzius Cc: tcp ip Subject: Re: TCP trace buffer formatter? Message-Id: <71901130143417/0004219666NB1EM@mcimail.com> >The BSD TCP/IP networking code has a TCP level circular trace >buffer (filled by routine tcp_trace). Does anyone have a tool >that would read this buffer from memory and format the information? Have you looked at TRPT? Its description, from RFC 1147, follows: Regards, Bob Stine ------cut here ------------------------------------------------------- Internet Tool Catalog TRPT NAME TRPT -- transliterate protocol trace KEYWORDS traffic; IP; eavesdrop; UNIX; free. ABSTRACT TRPT displays a trace of a TCP socket events. When no options are supplied, TRPT prints all the trace records found in a system, grouped according to TCP connection protocol control block (PCB). An example of TRPT output is: 38241 ESTABLISHED:input [e0531003..e0531203)@6cc5b402(win=4000) -> ESTA- BLISHED 38241 ESTABLISHED:user RCVD -> ESTABLISHED 38266 ESTABLISHED:output 6cc5b402@e0531203(win=4000) -> ESTABLISHED 38331 ESTABLISHED:input [e0531203..e0531403)@6cc5b402(win=4000) -> CLOSE_WAIT 38331 CLOSE_WAIT:output 6cc5b402@e0531404(win=3dff) -> CLOSE_WAIT 38331 CLOSE_WAIT:user RCVD -> CLOSE_WAIT 38343 LAST_ACK:output 6cc5b402@e0531404(win=4000) -> LAST_ACK 38343 CLOSE_WAIT:user DISCONNECT -> LAST_ACK 38343 LAST_ACK:user DETACH -> LAST_ACK MECHANISM TRPT interrogates the buffer of TCP trace records that is created when a TCP socket is marked for debugging. CAVEATS Prior to using TRPT, an analyst should take steps to isolate the problem connection and find the address of its protocol control blocks. BUGS None reported. LIMITATIONS A socket must have the debugging option set for TRPT to operate. Another problem is that the output format of TRPT is difficult. HARDWARE REQUIRED No restrictions. SOFTWARE REQUIRED BSD UNIX or related OS. AVAILABILITY Included with BSD and SunOS distributions. Available via anonymous FTP from uunet.uu.net, in file bsd- sources/src/etc/trpt.tar.Z.  ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9012011859.AA06446@ucbvax.Berkeley.EDU] <1990113015240600> From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: Call for Papers SIGCOMM '91 Message-ID: <9012011859.AA06446@ucbvax.Berkeley.EDU> Date: 30 Nov 90 15:24:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 85 Posted: Fri Nov 30 16:24:06 1990 Call For Papers ACM SIGCOMM '91 CONFERENCE Communications Applications, Architectures and Protocols ETH Zurich, Zurich, Switzerland September 4-6, 1991 (Tutorials September 3, 1991) The conference provides an international forum for the presenta- tion and discussion of communication network applications and technologies, as well as recent advances and proposals on commun- ication architectures, protocols, algorithms, and performance models. It is the first time that SIGCOMM will hold its confer- ence outside of North America. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the conference include, but are not limited to the following: Analysis and design of computer network architectures and algorithms, innova- tive results in local area networks, computer-supported coopera- tive work, network interconnection and mixed-media networks, high-speed networks, resource sharing in distributed systems, network management, distributed operating systems and databases, protocol specification, verification, and analysis. Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of accepted papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the conference and published as a special issue of ACM SIGCOMM Computer Communication Review. Notable papers will be considered for publication in ACM Transactions on Computer Systems. Submit 5 copies of each paper to the program chairman (or in North America, to the North American program committee contact): Prof. Bernhard Plattner Technische Informatik und Kommunikationsnetze Telephone: +41 1 254 7000 ETH-Zentrum (IFW) Fax: +41 1 262 3973 8092 Zurich, Switzerland EMAIL: or The North American program committee contact is: Greg Wetzel AT&T Bell Laboratories Telephone: +1 (708) 979-4782 M/S IH 1B-213 Fax: +1 (708) 979-2350 2000 N. Naperville Road E-Mail: g_f_wetzel@att.com Naperville, IL 60566 For more information about the conference, e-mail to sigcomm91@nri.reston.va.us Special session: Applications of High Speed Networks One or more sessions of the conference will be devoted to the subject of applications of high speed networks. Papers in these sessions will focus on concepts, implementation and experience of applications that need the performance that future high speed networks will offer. Topics include, but are not limited to new approaches to computer-supported cooperative work, graphic visu- alization, and access to supercomputers. Papers submitted for these topics should address applications and their communications requirements. Student Paper Award Papers submitted by students will enter a student-paper award contest. Among the accepted papers, a maximum of four outstand- ing student papers will be awarded (1) one full conference regis- tration and (2) a travel grant of US $1000. To be eligible, student(s) must be the primary contributor(s) to the paper. IMPORTANT DATES Deadline for paper submission: March 2, 1991. Notification of acceptance: April 30, 1991. Camera ready papers due: May 31, 1991. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9012011924.AA06850@ucbvax.Berkeley.EDU] <1990113016004600> From: MAINT@ASNTSU.ASN.NET Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9012011924.AA06850@ucbvax.Berkeley.EDU> Date: 30 Nov 90 16:00:46 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Posted: Fri Nov 30 17:00:46 1990 I am interested in SLIP and need the RFC for it. Can some one tell me what the RFC for it is and where I can get it? Please respond directly to me as I am not a regular subscriber to this list. Thanks in advance. -------------------------------------------------------------------------------- Dennis Putnam, Service Manager Boeing Computer Services Alabama Supercomputer Network +---------------------+ |UNA A&M | |NFDC-------C--UAH | | / \ | | | | JSU| | _____UAB-+----/ | | UA | | | | ____AU | | DSMD | | ASU | \ | | / TSU | | / | | / | | / | | _USA---------------+ |/ \_| ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113018311100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 1 Dec 90 00:57:10 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA27722; Sat, 1 Dec 90 00:50:33 -0800 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 Nov 90 18:31:11 GMT From: hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU (Rick Jones) Organization: Hewlett-Packard, Cupertino CA Subject: Re: Interoperating with HP Message-Id: <36540016@hpindwa.cup.hp.com> References: <9011271533.AA01752@desktalkdesktalk.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil On the subject of connecting MPE's with the rest of the networking world... Don was correct, the latest version of MPE/V supports ethernet. So does the next oldest release, and the next, and all the way back to VDelta-5 ;-) However, you would probably be well advised to upgrade to at later release to get subnet support and accumulated fixes - VDelta-5 is a rather old release. rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | MPE/XL Networking Engineer | \_/ \_/ Hewlett-Packard Co. | XL has Ethernet too ;-) ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113020215500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 18:22:47 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA15362; Fri, 30 Nov 90 16:08:20 -0800 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 Nov 90 20:21:55 GMT From: ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!pww@beaver.cs.washington.edu (Peter Whittaker) Organization: Bell-Northern Research, Ltd., Ottawa, Ontario, CANADA Subject: Re: reuse of addresses when calling bind() Message-Id: <1990Nov30.202155.8253@bwdls61.bnr.ca> References: <86984@lll-winken.LLNL.GOV> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <86984@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes: >I've got a meeting in a couple minutes so I'm going to try and ask this quickly. >If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able >to issue a bind() for a ip/port address that is already in use. However, it >appears that it is still possible for bind() to return the error EADDRINUSE (for >example, look at routine getdatasock() in ftpd.c where they have a loop that >retries the bind() several times before giving up, all the while checking for >EADDRINUSE). > >What I'd like to know is why this happens, in lieu of the call to setsockopt(). >Thanks in advance. Email would be nice but I'll wade through stuff if need be. I'm posting instead of e-mailing you directly in order to check my answer against the combined wisdom of the net... First, the original socket must have set SO_REUSEADDR - you cannot set it retroactively. Second, two independent processes cannot bind to the same port no matter what options are set. SO_REUSEADDR allows the same process, or children of that process, to bind to same port (this is how ftp works: one server binds its children to the same port, so all data flows from the same port). Finally, under certain conditions (notably the use of SO_KEEPALIVE in an HP-UX 6.5 client), connections never disppear when the server dies/exits; the kernel tells the server that the socket is closed, but never manages to close it, because the HPUS 6.5 client interferes with the shutdown. Result: regardless of any options, the socket cannot reused until the client shuts down or the machine is rebooted. -- Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113020264100> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 18:22:58 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA14357; Fri, 30 Nov 90 15:42:26 -0800 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 Nov 90 20:26:41 GMT From: rock.concert.net!sunvis.rtpnc.epa.gov!fty@mcnc.org (Frank Terhaar-Yonkers) Organization: U.S. Environmental Protection Agency Subject: DNS for SUN 386i Message-Id: <1990Nov30.202641.9308@rock.concert.net> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil Howdy, Anyone out in net land have a lib_pic.a for a SUN 386i running 4.0.2? I've been trying to get one from Sun so I could install bind 4.8.3 but they can't seem to find one. They did find a shared libc with some sort of resolver in in but it doesn't work very well .. -- thanks - Frank T-Y ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113021273400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 16:37:47 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16297; Fri, 30 Nov 90 16:32:44 -0800 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 Nov 90 21:27:34 GMT From: ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bigsur!bcars53!mussar@beaver.cs.washington.edu (G. Mussar) Organization: Bell-Northern Research, Ottawa, Canada Subject: Re: X25 over IP Message-Id: <1990Nov30.212734.26941@bigsur.uucp> References: <9011271721.AA06559@isis.u-strasbg.fr>, <1900@inria.inria.fr> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1900@inria.inria.fr> dupont@inria.inria.fr (Francis Dupont) writes: >In article <9011271721.AA06559@isis.u-strasbg.fr>, pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes: >> >> Is there a standard way to run X25 over IP (not the other way around, IP >> over X25 ). We would like to use our IP network to carry non IP traffic >> over X25. >> ... > >Cisco has a X.25 over TCP. It is useful for instance for PAD (X.3/X.28/X.29). >(OSI applications can use RFC 1086 "ISO-TP0 bridge between TCP and X.25" >but it is not possible for native usage of X.25 like PAD). >The transport of X.25 packets over TCP connections is very simple, >I've implemented it for Suns and I'm writing a description of it. > >Francis.Dupont@inria.fr I would be interested in seeing some "standard" for carrying X.25 on TCP/IP. It would be useful being able to have multiple vendors X.25/IP products talking the same language. I have my own version which I use when remote applications wish to access my X.25 port on my Sun across the LAN. Does your implementation allow for M/D/Q bits set in packets? Has Cisco documented how their implementation works? -- ------------------------------------------------------------------------------- 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---- [9012021343.AA05169@uunet.UU.NET] <1990113021440700> From: root%shiva@SHAKTI.ERNET.IN Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9012021343.AA05169@uunet.UU.NET> Date: 30 Nov 90 21:44:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 Posted: Fri Nov 30 22:44:07 1990 >From NIC.DDN.MIL!tcp-ip-RELAY Mon Nov 12 06:32:11 1990 remote from shakti Received: by shakti.ernet.in (1.2/Ultrix2.0-B) for ernet.in id AA00523; Mon, 12 Nov 90 06:32:17+0530 Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP id AA21066; Sun, 11 Nov 90 19:54:53 -0500 Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 13:39:52 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA24877; Sat, 10 Nov 90 13:36:56 -0800 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 Nov 90 20:09:42 GMT From: shakti!decwrl.dec.com!sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino Organization: University of Kansas Academic Computing Services Subject: humanitarian request Message-Id: <26685.273c1836@kuhub.cc.ukans.edu> Sender: shakti!nic.ddn.mil!tcp-ip-relay To: shakti!nic.ddn.mil!tcp-ip Dear NetFolks, We would appreciate your responding to the request of Craig Shergold who is a seven year old boy with an inoperable tumor on his brain. He has not been given a very long time to live and it is Craig's ambition to enter the Guiness Book of World Records for the largest number of get well cards ever received by an individual. Please send your card to: Craig Shergold % Children's Make-A-Wish Foundation 32 Parimeter Center East Atlanta, Georgia 30346 ------------------------------------- Letters similar to this have been sent out by traditional mail to large organizations all across the U.S. on Craigs behalf. Instead of passing it on by land-mail, I thought the net would be a great way of getting the word out to as many people as possible in as short a time as possible. Please pitch-in & send Craig a get well card, and by all means feel free to circulate this letter to local businesses/organizations, or other BBS's you may belong to. All your help and effort will certainly be appreciated! Thank you. Sincerely, Jack Petrino ---------------------------------------------------------------------- Jack Petrino (DRAGON) int: PETRINO@KUHUB.CC.UKANS.EDU Systems Testing bit: PETRINO@UKANVAX University of Kansas vox: (913)864-0443 Computer Center fax: (913)864-0485 ----------------------------------------------------------------------- PS - I apologize for the possible redundancy of posting this net-wide. I hope everyone can understand the necessity/urgency of the situation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113023002400> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 17:52:53 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18087; Fri, 30 Nov 90 17:24:33 -0800 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 Nov 90 23:00:24 GMT From: shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com (Paul Ciarfella) Organization: Digital Equipment Corporation Subject: ICMP Time Exceeded sent on non-initial fragments? Message-Id: <17727@shlump.nac.dec.com> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil RFC 1122 says that ICMP messages must not be generated as a result of receiving non-initial fragments of a datagram. But, what happens if reassembly of a datagram times out and the initial fragment was never received. Does this mean that I cannot send an ICMP Time Exceeded given that I don't have the initial fragment? Thanks, Paul C --------------------------------------------------------------------------- Paul Ciarfella Digital Equipment Corporation Littleton, MA --------------------------------------------------------------------------- Disclaimer : My opinions are my own. | When in doubt, mumble. Address : ciarfella@shug.dec.com --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113023133500> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 18:07:30 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA16443; Fri, 30 Nov 90 16:36:36 -0800 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 Nov 90 23:13:35 GMT From: lll-crg.llnl.gov!booloo@lll-winken.llnl.gov (Mark Boolootian) Organization: Lawrence Livermore National Laboratory Subject: Re: reuse of addresses when calling bind() Message-Id: <87047@lll-winken.LLNL.GOV> References: <86984@lll-winken.LLNL.GOV>, <1990Nov30.202155.8253@bwdls61.bnr.ca> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <1990Nov30.202155.8253@bwdls61.bnr.ca> pww@bnr.ca (Peter Whittaker) writes: >In article <86984@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes: >>If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able >>to issue a bind() for a ip/port address that is already in use. However, it >>appears that it is still possible for bind() to return the error EADDRINUSE > > >First, the original socket must have set SO_REUSEADDR - you cannot set it >retroactively. This is the case. Each socket wishing to bind to the same port number must issue a setsockopt() for SO_REUSEADDR. > >Second, two independent processes cannot bind to the same port no matter >what options are set. SO_REUSEADDR allows the same process, or children of >that process, to bind to same port (this is how ftp works: one server binds >its children to the same port, so all data flows from the same port). > This certainly isn't true. The FTP server always binds to local port 20 for data connections. The uniqueness of the connection must be guaranteed by the client's selection of a remote port. Since it is possible for there to be multiple instances of the ftp server running at one time, it is necessary to set the data socket with the SO_REUSEADDR option. This issue is talked about in the Unix Programmer's Manual on page 8-31 (PS1). Unfortunately, I still don't see how this particular error can occur once the socket has been correctly setsockopt()'ed. Thanks for the reply but I'm still confused. mb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990113023430800> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 30 Nov 90 18:07:02 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18964; Fri, 30 Nov 90 17:51:00 -0800 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 Nov 90 23:43:08 GMT From: sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@lll-winken.llnl.gov (Matthias Urlichs) Organization: University of Karlsruhe, FRG Subject: Re: Internet Access Costs Message-Id: References: <315@srchtec.UUCP>, <1990Nov26.233848.20828@nmt.edu>, <1990Nov29.212559.7284@spectrum.CMC.COM> Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In comp.protocols.tcp-ip, article <1990Nov29.212559.7284@spectrum.CMC.COM>, < < Crazy as it seems at first glance, dynamic IP addresses are < not actually all that unusual. Client-only PC's often do this. And with < domain name service, it is doable even to handle incoming connections. < < Yes, it does create a few management hassles. You need to have a < name server with a transaction interface to change the name/address < mappings on the fly (where the run-of-the-mill BIND just reads a table < when it is reloaded) and you cannot have management utilities that < assume that name/address mappings are constant. < Problem 1: Name server records get cached. A TTL of five minutes is probably not a good idea. Problem 2: What if my connection breaks (noisy phone line, idle connection timeout) and I have to reconnect? Suddenly my IP number is different: and the existing connection is broken for good. Not good either. < As to WHY one wants to do this ? When you have a couple hundred < PC's around, it is easier to just declare them to be generic than to try < to keep track of locations and owners for all of them. Likewise, network < providers may have only allocated class C network numbers for a routing < cluster, and may prefer the dynamic addresses over changing backbone < routing implementations with hardcoded netmasks. < That might work for PCs or similar clients, but for external SLIP/PPP connections (which might even have their own Class C network hanging off the remote end) it seems to be preferable to give each client its own IP address. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/ ----MESSAGE-END----