----MESSAGE-BEGIN---- [20949@hydra.gatech.EDU] <1991020101443900> From: ce1zzes@prism.gatech.EDU (Eric Sheppard) Newsgroups: comp.protocols.tcp-ip Subject: Problems with NCSA Telnet 2.3b14 Message-ID: <20949@hydra.gatech.EDU> Date: 1 Feb 91 01:44:39 GMT Sender: ce1zzes@prism.gatech.EDU Organization: Georgia Institute of Technology Lines: 23 I just can't seem to get Telnet to work directly with my ethernet card. The best I could get was a connection to a remote host. If I called telnet without a hostname (which should start server mode), the machine locks up or reboots. What am I doing wrong? I suspect an interrupt conflict, but the same thing happens with no other cards in the machine. playing with the specification section of the config.tel file almost always locks the machine. Particulars: 80286 machine, 3Com 3c503 Ethernet card. Also installed are a memory board, serial/parallel board, 2nd serial card, and bus mouse board (set to IRQ5). Pertinent portion of config.tel file: hardware=3c503 address=dc000 interrupt=3 ioaddr=310 wire=thick Any pointers appreciated. Eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- [52067@sequent.UUCP] <1991020101542800> From: djk@sequent.uucp (Darin Klaas) Newsgroups: comp.protocols.tcp-ip Subject: Re: connect "collisions" in TCP Message-ID: <52067@sequent.UUCP> Date: 1 Feb 91 01:54:28 GMT Sender: djk@sequent.UUCP Organization: The Hard Rock Cubicle Lines: 13 calvert@cs.utexas.edu (Kenneth L. Calvert) writes: >0. My impression is that the Berkeley Unix sockets interface (to TCP) >precludes deliberate use of this "feature". Have I missed something? >(The implementation does the right thing when SYN is received in state >SYN_SENT). In fact it doesn't do the right thing (at least 4.3-tahoe doesn't) -- follow the incoming SYN ACK and you'll see that the two sides of the connection eventually SYN ACK each other for ever and ever... -- darin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21910201015512.0004219666NB1EM@mcimail.com] <1991020101550000> From: 0004219666@MCIMAIL.COM (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: Re: PC version of tcpdump? Message-ID: <21910201015512.0004219666NB1EM@mcimail.com> Date: 1 Feb 91 01:55:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 >Does anyone know where I can get a PD version of a PC netwatch or tcpdump program available for home use? If so, please respond to me via email, if >possible. To the best of my recollection, netwatch _IS_ PD, or at least free. Check RFC 1147 for instructions on how to get it (I'd tell you, but my copy of RFC 1147 is at the office, and I'm not). Regards, Bob Stine bstine@MCIMail.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [63910201015636.0004219666NB1EM@mcimail.com] <1991020101560000> From: 0004219666@MCIMAIL.COM (Bob Stine) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problems between Wolligong ftp on VMS and ftp on Sun Message-ID: <63910201015636.0004219666NB1EM@mcimail.com> Date: 1 Feb 91 01:56:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 >Does anyone know of any problems between Wolligong on VMS and Sun's ftp. >... If >I log in just as a user then I get the user name but no prompt for password. >It just sits there after the carraige return. Just a wild guess... are you running over ethernet, and if so, are all your hosts consistent in their "trailer" declarations of the interfaces? (Check with ifconfig...) - Bob Stine bstine@MCIMail.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1287@ap542.uucp] <1991020111164600> From: mike@ap542.uucp (Mike Hoffmann) Newsgroups: comp.protocols.tcp-ip Subject: SL/IP question Keywords: Ultrix 4.1 only one direction works Message-ID: <1287@ap542.uucp> Date: 1 Feb 91 11:16:46 GMT Sender: news@ap542.uucp Organization: Siemens-Nixdorf AG, AP 712 Lines: 38 Hi! We are trying to establish a SL/IP connection between our system (a Siemens MX-500 with Sinix 5.22) and a DEC MIPS machine running Ultrix 4.1. hosta ist our machine hostb is the DEC MIPS On our own machine, a SLIP conn is initialized by doing: slattach ifconfig sl0 mtu 256 up The MIPS machine uses a syntax like: slattach and this gets it's information from /etc/sliphosts, where the entry looks like: ... and so on ... like it says in the manual. Funnily though, only hosta can call hostb, but we have found no way to call our machine from the DEC machine. Let me add, that there is one other SL/IP connection running on the DEC machine with no problems whatsoever, bi-directional. Is only one possible? Is something wrong in the manual entries? I could understand if it wouldn't work at all, but only in one direction is ridiculous. BTW, DEC can't help, their office here states that SL/IP is unsupported. Thanks for any pointers! Mike Mike Hoffmann, Siemens-Nixdorf AG, SNI AP 712 UUCP: mike@ap542.uucp | INTERNET: mike%ap542@ztivax.siemens.com "For the new year I resolved, not to be offended by human nature. But I think I blew it already." (Hobbes) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4967@mentor.cc.purdue.edu] <1991020113264600> From: wilker@gauss.math.purdue.edu (Clarence Wilkerson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problems with NCSA Telnet 2.3b14 Message-ID: <4967@mentor.cc.purdue.edu> Date: 1 Feb 91 13:26:46 GMT References: <20949@hydra.gatech.EDU> Sender: news@mentor.cc.purdue.edu Reply-To: wilker@gauss.math.purdue.edu.UUCP (Clarence Wilkerson) Organization: Purdue University, West Lafayette Lines: 8 This may sound silly, but earlier copies of Telenet came with a batch file TELNET.BAT, which defaulted with blank input to some local machine address at NCSA. This causes telnet to try that address, which means a long wait for timeout. FTP.BAT on the other hand will just sit quitly after giving the FTP> prompt. Telnet does seem to have the command line interface that unix telnet has. Clarence Wilkerson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [61@wrdis01.af.mil] <1991020114380500> From: cheek@wrdis01.af.mil (Charles Cheek) Newsgroups: comp.protocols.tcp-ip Subject: VM TCP-IP communication setup Message-ID: <61@wrdis01.af.mil> Date: 1 Feb 91 14:38:05 GMT Sender: cheek@wrdis01.af.mil Organization: 1926CCSG Robins AFB Lines: 2 I have an 8232 with an Ethernet connection attached to 3081. I have two virtual lines defined for TCP-IP. Why only two lines and can I add more? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb1.155557.10041@rice.edu] <1991020115555700> From: dboyes@brazos.rice.edu (David Boyes) Newsgroups: comp.protocols.tcp-ip Subject: Re: VM TCP-IP communication setup Message-ID: <1991Feb1.155557.10041@rice.edu> Date: 1 Feb 91 15:55:57 GMT References: <61@wrdis01.af.mil> Sender: news@rice.edu (News) Organization: Rice University, Houston, Texas Lines: 30 In article <61@wrdis01.af.mil> cheek@wrdis01.af.mil (Charles Cheek) writes: >I have an 8232 with an Ethernet connection attached to 3081. I have >two virtual lines defined for TCP-IP. Why only two lines and can I add more? Two CTC definitions are all you need; the bandwidth provided by the CTC connection is much higher than the 8232 can drive anyway. One is used as the base device for data transfer and the other CTC is used for control purposes. Logical terminal devices created by FAL aren't like VTAM or BTAM in that "ports" or "connections" are not pre-defined and centrally managed. FAL receives a dynamic connection request from a tn3270 client and creates an LDEV on the fly, no intervention or configuration on your part necessary. If you're running SP or HPO, the number of connections is limited by the 16M VM size; about 400-500 connections. If you're running in XA mode and have VM/TCP rel 2 (yes, it's available!) and get the XA-exploitative version from IBM level 1, the number of connections goes up quite a bit. I haven't received my V2 tapes yet, so I haven't gotten a chance to mess with it yet. Now, if you're running MVS TCP, all of the above may be wrong; I don't have one of those to play with. -- David Boyes |The three most dangerous things in the world: dboyes@rice.edu | 1) a programmer with a soldering iron, | 2) a hardware type with a program patch, and "Delays, delays!" | 3) a user with an idea. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb01.163826.11939@micromuse.co.uk] <1991020116382600> From: peter@micromuse.co.uk (Peter Galbavy) Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.sources.wanted Subject: Wanted - PPP for ISC 2.2 Keywords: PPP Message-ID: <1991Feb01.163826.11939@micromuse.co.uk> Date: 1 Feb 91 16:38:26 GMT Sender: peter@micromuse.co.uk (Peter Galbavy) Organization: Micromuse Ltd, London Lines: 19 I have been trying to hack at the ppp-streams code for SunOS for a while to get it working under ISC Sys V 3.2 streams for a while - and I will probably get it going soon. However, it will probably not work, because I do not understand enough about streams (or ppp for that matter). So - has anyone out there got ppp going for Interactive ? If I get the SunOS version ported before anyone tells me otherwise, I will pass it back to the world in general, but I do not want to reinvent the whell. Replies by e-mail please - I will post a summary of there is interest. Regards, -- Peter Galbavy Tech Support, Micromuse Ltd Phone: +44 71 352 7774 E-Mail: P.Galbavy@micromuse.co.uk Disclaimer: Time flies like an arrow... Fruit flies like a banana ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7470.27a94c19@zeus.unomaha.edu] <1991020117080900> From: gerke@zeus.unomaha.edu Newsgroups: comp.protocols.tcp-ip Subject: PUSH bit in the TCP header question... Message-ID: <7470.27a94c19@zeus.unomaha.edu> Date: 1 Feb 91 17:08:09 GMT Lines: 6 I need to know how to force the PUSH bit in the TCP header using the Berkeley Sockets implementation. I have seen vague references but no definitive answer. I'd be a happy camper if someone could point me in the right direction... Thanks! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [29776@usc] <1991020118350400> From: rpinder@phad.hsc.usc.edu (Rich Pinder) Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.periphs Subject: 32 bit ethernet adapters Message-ID: <29776@usc> Date: 1 Feb 91 18:35:04 GMT Sender: news@usc Followup-To: comp.protocols.tcp-ip Organization: University of Southern California, Los Angeles, CA Lines: 14 Nntp-Posting-Host: phad.hsc.usc.edu Originator: rpinder@phad.hsc.usc.edu I'm looking for a 32 bit, Micro-Channel, Ethernet adapter, that has (working) drivers for SCO. I'd appreciate any leads. (I know about Cogent - drivers lacking) thanks Rich Pinder USC School of Medicine (213) 342-1640 rpinder@usc.edu |||||||||||||||||||||||||||||||||||||||||||||||||| ----MESSAGE-END---- ----MESSAGE-BEGIN---- [huston.665436365@tiger1] <1991020119260500> From: huston@prime.com (Steve Huston) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC 1108 and IP Security options? Message-ID: Date: 1 Feb 91 19:26:05 GMT References: Lines: 13 Nntp-Posting-Host: tiger1 bob@MorningStar.Com (Bob Sutterfield) writes: >What is the current authoritative reference in this area? Must an >implementor order the revised MIL-STD 1777 from Navy Publications (as >suggested in RFC 1038), or is it available on-line in RFC form? RFC 1108 is still being worked on by it's author(s) (not me) and is rumored to be available "soon". If you plan to operate over military networks, maybe worth ordering MIL-STD 1777, else probably better to wait for RFC 1108. Steve Huston huston@relay.prime.com Prime Computer, Inc. +1 508 620 2800 ext 3099 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb1.215832.21340@mccc.edu] <1991020121583200> From: pjh@mccc.edu (Pete Holsberg) Newsgroups: comp.protocols.tcp-ip Subject: SVR4 and FTP's software Message-ID: <1991Feb1.215832.21340@mccc.edu> Date: 1 Feb 91 21:58:32 GMT Organization: The College On The Other Side Of Route One Lines: 13 It was suggested to me the other day that the POP servers available in the P.D. and the POP[23] mail software that FTP supplies with PC-TCP Plus may not work under the TCP/IP support provided with UNIX System V Release 4.x. Could an experienced person please try to shed some light on this? Thanks, Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb2.231741.27824@odin.diku.dk] <1991020223174100> From: thorinn@diku.dk (Lars Henrik Mathiesen) Newsgroups: comp.protocols.tcp-ip Subject: Re: PUSH bit in the TCP header question... Message-ID: <1991Feb2.231741.27824@odin.diku.dk> Date: 2 Feb 91 23:17:41 GMT References: <7470.27a94c19@zeus.unomaha.edu> Sender: news@odin.diku.dk (Netnews System) Organization: Department of Computer Science, U of Copenhagen Lines: 19 gerke@zeus.unomaha.edu writes: >I need to know how to force the PUSH bit in the TCP header using the Berkeley >Sockets implementation. I have seen vague references but no definitive >answer. I'd be a happy camper if someone could point me in the right >direction... You cannot explicitly force it. It will be set when the output buffer drains (i.e., when the sent-but-not-ack'ed mark reaches the end of the buffer). Depending on the relative speeds of reader, writer and network, that can be on every packet sent, or never. However, if your program writes some stuff to the socket and waits for the other end to acknowledge, the last TCP packet will have been sent with a PUSH bit. Short of kernel gropery, that is the only way to be sure. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk ----MESSAGE-END---- ----MESSAGE-BEGIN---- [90696@lll-winken.LLNL.GOV] <1991020223391900> From: casey@gauss.llnl.gov (Casey Leedom) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <90696@lll-winken.LLNL.GOV> Date: 2 Feb 91 23:39:19 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> <14127@scorn.sco.COM> Sender: usenet@lll-winken.LLNL.GOV Reply-To: casey@gauss.llnl.gov (Casey Leedom) Organization: Lawrence Livermore National Laboratory Lines: 36 Nntp-Posting-Host: gauss.llnl.gov | From: ericd@sco.COM (Eric Davis) | | Some of the information in this post is incorrect. I do not want to use | network bandwidth to explain the issues, however I would be more than | willing to email concerned individuals directly about the the copy | protection scheme and how it affects system adminstration and users. | From a techinical and adminstrative point of view SCO's implementation of | a copy protection scheme it is not the limiting monster that it is | thought to be. Please take time to understand the facts. You didn't help your case in the least with those two incredibly large and redundant postings. First, all the material you quoted had already hit TCP-IP. You didn't add any new information in your posting. If all you wanted to do was to take the discussion out of a public forum by offering to discuss the issues privately with individuals, that's all you should have said. Including the vast amount of already posted material is just going to piss people off. Second you sent the note out twice, but I'll assume that was merely a mistake on your part. As for wanting to take the discussion off of TCP-IP, there have been a few complaints about the appropriateness of discussing network copy protection / licensing on TCP-IP from a few people, but since it really *IS* a network issue, I think that a majority of TCP-IP readers are probably tolerant of, if not actively interested, the subject. I for one would like to see SCO defend its use of network licensing via broadcast messages. I have to admit being biased towards disliking it intensively, but I'd like to hear SCO's arguments. It may result in some very productive discussion and decisions. Casey ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb3.053341.5064@tcsc3b2.tcsc.com] <1991020305334100> From: tcsc@tcsc3b2.tcsc.com (The Computer Solution Co.) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <1991Feb3.053341.5064@tcsc3b2.tcsc.com> Date: 3 Feb 91 05:33:41 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> Organization: The Computer Solution Company, Inc. Lines: 60 jgd@Dixie.Com (John G. DeArmond) writes: >rlg@BIOBIO.DESKTALK.COM (Richard L. Gralnik) writes: >>Fellow networkers, [ much good stuff deleted ... hope you already saw it ] >Customer Service will make or break your product. You'd damn well better >plan for it as an integral feature of your product, fully as important >as the software not crashing. Here's an example of how to and how not to >do customer support. I have used 2 brands of intelligent async cards in >Unix systems for my customers. One brand is Comtrol and the other is >Stargate. I no longer use Stargate because of customer support. >When I opened the first Comtrol box, the first thing I saw was a plastic gold >card just like a credit card. On this card was printed the 800 toll free >support number AND the names and direct dial numbers for the General Manager, >the Engineering Manager, the Hardware Tech Support manager, the Software >Tech Support manager, the Production manager, the Marketing manager and >the Sales manager. Above this list of numbers is this statement: > "Our committment to you doesn't stop with our products. We give > you the support and the extra service you want. IT's because your > satisfaction is our #1 priority. COMTROL is only a phone call away. > You have full access to all COMTROL personnel. For your convenience, > primary department contacts are listed below:" [ more deletions for brevity ] >Now both boards work pretty well equally. But I'll never fool with >Stargate again while I recommend COMTROL whenever the opportunity arises. >The difference is service. I perceived a better value from COMTROL even >though it cost more. I have used Comtrol boards for several years now for exactly the same reason. When I provide support to my customers, I hope to do as well as Comtrol. I hope I'm not allowing the feline to escape the confinement when I say that I am consulting with Comtrol to develop integrated electronic delivery of customer support. Customers will be provided with a BBS, primarily for DOS and Pick users. They will also provide uunet and mailserver access for us networkers. Fellow networkers ... we should support such companies who really are trying to do it right at least as strongly as we flame those who botch it up. I have no connection with Comtrol, except as a very satisfied customer for nearly 4 years. Our consulting engagement for provision of electronic customer support delivery nets no financial gain to our company. _______________________________________________________________________________ David P. Romig INTERNET: tcsc@tcsc3b2.tcsc.com The Computer Solution Co. USENET: ...!tcsc3b2!tcsc P.O. Box 716 ATTMAIL: attmail!tcsc3b2!tcsc 831 Grove Road CompuServe: 74116,2345 Midlothian, VA 23113-0716 UUCP: tcsc3b2!tcsc (804)794-1514 Voice: 804-794-3491 x31 Fax: (804)794-6194 _______________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [DANJ1.91Feb2235539@cbnewse.ATT.COM] <1991020305554800> From: Dan_Jacobson@ATT.COM Newsgroups: comp.unix.misc,comp.protocols.tcp-ip Subject: Re: Will telnet do VT100 translation for other term types? Message-ID: Date: 3 Feb 91 05:55:48 GMT References: <1049@opac.uucp> Sender: danj1@cbnewse.att.com (Dan Jacobson) Reply-To: Dan_Jacobson@ATT.COM Organization: AT&T-BL, Naperville IL, USA Lines: 11 In-Reply-To: brianop@opac.uucp's message of 30 Jan 91 16:11:36 GMT >>>>> On 30 Jan 91 16:11:36 GMT, brianop@opac.uucp (BRIAN MCBEE) said: B> going to buy), but we have people that will be logging in from all B> kinds of different terminals. We would then like to be able to B> telnet from the unix system to a VAX running VMS, and run an B> application that REQUIRES vt100 terminal emulation. Perhaps get "screen2" from the comp.sources.unix archive e.g., on uunet.uu.net. Only works on BSD/Sun unix though. -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15702@milton.u.washington.edu] <1991020317393600> From: mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <15702@milton.u.washington.edu> Date: 3 Feb 91 17:39:36 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> <14127@scorn.sco.COM> <90696@lll-winken.LLNL.GOV> Sender: news@milton.u.washington.edu Organization: Mendou Zaibatsu, Tomobiki-Cho, Butsumetsu-Shi Lines: 10 Posted: Sun Feb 3 11:39:36 1991 Can copy-protection or license-protection systems such as SCO's be used for a denial-of-service and/or harassment type of attack? _____ | ____ ___|___ /__ 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---- [1991Feb3.193317.18716@NCoast.ORG] <1991020319331700> From: adnan@NCoast.ORG (Adnan Yaqub) Newsgroups: comp.protocols.tcp-ip Subject: Customer Support (was Re: copy protection) Summary: You get what you pay for. Message-ID: <1991Feb3.193317.18716@NCoast.ORG> Date: 3 Feb 91 19:33:17 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> Organization: North Coast Public Access Un*x (ncoast) Lines: 33 In article <6207@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >Customer Service will make or break your product. You'd damn well better I agree. >plan for it as an integral feature of your product, fully as important >as the software not crashing. Here's an example of how to and how not to >do customer support. I have used 2 brands of intelligent async cards in >Unix systems for my customers. One brand is Comtrol and the other is >Stargate. I no longer use Stargate because of customer support. > >When I opened the first Comtrol box, the first thing I saw was a plastic gold >card just like a credit card. On this card was printed the 800 toll free This sounds like you bought the box from Comtrol. [stuff about Comtrol's good support deleted.] >My Stargate experience was a bit different. I inherited my first card >in some surplus stock I bought. The card uses address decode PALs that This sounds like you got Stargate's board at a garage sale. While I believe that customer support is important and a company should strive to support all its products, I don't expect the same support from a company whose product I inherited with one whose product I bought and is still under warranty. Do you? [stuff about Stargate's bad customer support deleted] I suggest that this thread be moved to another newsgroup. (Which one, I don't know.) Adnan Yaqub (adnan@ncoast) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [jim.665613330@remtech] <1991020320353000> From: jim@remtech.com (Jim Levie) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problems with NCSA Telnet 2.3b14 Message-ID: Date: 3 Feb 91 20:35:30 GMT References: <20949@hydra.gatech.EDU> Organization: Remtech Inc. Lines: 34 ce1zzes@prism.gatech.EDU (Eric Sheppard) writes: >I just can't seem to get Telnet to work directly with my ethernet card. >The best I could get was a connection to a remote host. If I called >telnet without a hostname (which should start server mode), the machine >locks up or reboots. What am I doing wrong? I suspect an interrupt >conflict, but the same thing happens with no other cards in the machine. >playing with the specification section of the config.tel file almost >always locks the machine. ...stuff deleted... >Eric I've recently encountered the same problem and found a solution. Initially I also thought that it was an interrupt/address clash. Further investigation revealed that it appears that there is a bug in the 3c503 routines in telnet and ftp utilities. Sometimes telnet would work, sometimes not and sometimes the PC would lock up during or after a successful connection. PC's with other ethernet cards didn't have the problem. There is a solution... Installing the packet driver for the 3c503 card appears to have eliminated the problem for us. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Jim Levie email: jim@chimera.remtech.com REMTECH Inc Huntsville, Al (or) ...uunet!remtech!chimera!jim The opinions expressed above are just that Ph. (205) 536-8581 -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Jim Levie email: jim@chimera.remtech.com REMTECH Inc Huntsville, Al (or) ...uunet!remtech!chimera!jim The opinions expressed above are just that Ph. (205) 536-8581 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [38836@cup.portal.com] <1991020402092900> From: Will@cup.portal.com (Will E Estes) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip Subject: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: <38836@cup.portal.com> Date: 4 Feb 91 02:09:29 GMT Organization: The Portal System (TM) Lines: 22 I would like to get opinions on pros and cons for setting up an Internet. The two setups are: 1) All sites on the internet have routers that attach to a public data network, like UUNET's Alternet, and use TCP/IP to communicate between nodes on the net. To the extent that X.25 might be used underneath TCP between the routers, this is invisible to the applications. 2) All sites on the internet connect directly to an X.25 network, and any client-server applications between two sites are written directly to an X.25 API or to some software abstraction that is written on top of X.25. What are the advantages to either approach? Clearly 2) is going to be more efficient since you don't have the extra error-checking of TCP and you don't have the extra data bandwidth of the router headers being attached to each packet. This advantage aside, are there any decisive advantages that argue for approach 1)? Thanks, Will Estes (apple!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910203192209.27a009bb@TGV.COM] <1991020403233700> From: adelman@TGV.COM (Kenneth Adelman) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <910203192209.27a009bb@TGV.COM> Date: 4 Feb 91 03:23:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Adelman@TGV.COM (Kenneth Adelman) Organization: The Internet Lines: 8 > Can copy-protection or license-protection systems such as SCO's be > used for a denial-of-service and/or harassment type of attack? Presumably yes, and very easily. Just run a UDP ECHO server on port 60000. This might also be a good way of "suppressing" machines which do these broadcasts from ever getting on your network. Ken ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102031925.AA21599@asylum.sf.ca.us] <1991020403255100> From: romkey@ASYLUM.SF.CA.US (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: PC version of tcpdump? Message-ID: <9102031925.AA21599@asylum.sf.ca.us> Date: 4 Feb 91 03:25:51 GMT References: <21910201015512.0004219666NB1EM@mcimail.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: romkey@asylum.sf.ca.us Organization: The Internet Lines: 5 Netwatch is *not* public domain. It's under a copyright that allows you to do anything you want with it provided that you credit MIT with its original creation. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102040541.AA23731@sutro.SFSU.EDU] <1991020405411300> From: eps@SUTRO.SFSU.EDU (Eric P. Scott) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <9102040541.AA23731@sutro.SFSU.EDU> Date: 4 Feb 91 05:41:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 In article <15702@milton.u.washington.edu> MRC@CAC.Washington.EDU (Mark Crispin) writes: >Can copy-protection or license-protection systems such as SCO's be >used for a denial-of-service and/or harassment type of attack? Do I detect a missing smiley-face? -=EPS=- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb4.074656.13601@ciba-geigy.ch] <1991020407465600> From: whwb@ciba-geigy.ch (Hans W. Barz) Newsgroups: comp.protocols.tcp-ip Subject: Re: LM/X and RFC1001 Message-ID: <1991Feb4.074656.13601@ciba-geigy.ch> Date: 4 Feb 91 07:46:56 GMT References: Sender: news@ciba-geigy.ch (USENET News Agent) Organization: Ciba-Geigy AG, Basel, Switzerland Lines: 18 Nntp-Posting-Host: cgchf1 Since we are interested in LM/X I tried to find out, who has really implemented the RFC1001 correctly. RFC1001 has some nice mechanism build in to avoid broadcast over internets. The interface on the 'otherwise broadcasting' client sends a request to the domain server instead. New servers announce their server capabilities to the domain server as well - this is kind of a new feature for DNS (interactive update from client). As a matter of fact no one seems to have implemented it. Only Ungermann/Bass seems to have plans to do it and they are also delivering an interface to LAN Manager. Has somebody more information on that ? Hans W. Barz, R.1045.3.34, CIBA-GEIGY, 4002 Basel, Switzerland Internet/uucp-Mail: whwb@CIBA-GEIGY.CH X.400: C=CH;A=ARCOM;P=CIBA-GEIGY;OU=CHCGBS30;S=BARZ;G=HANS;I=W phone: +41/61/6974520 fax: +41/61/6973288 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb4.095500.10722@robobar.co.uk] <1991020409550000> From: ronald@robobar.co.uk (Ronald S H Khoo) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <1991Feb4.095500.10722@robobar.co.uk> Date: 4 Feb 91 09:55:00 GMT References: <14127@scorn.sco.COM> <90696@lll-winken.LLNL.GOV> <15702@milton.u.washington.edu> Organization: Robobar Ltd., Perivale, Middx., ENGLAND. Lines: 15 mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > Can copy-protection or license-protection systems such as SCO's be > used for a denial-of-service and/or harassment type of attack? Should be. The serial numbers are broadcast in cleartext. Just log all udp broadcasts to port 60000 on any net with SCO stuff on it and see ... You need to just look at the format of the udp packets, broadcast the same serial numbers from your own ip address, and that should have the desired effect of making you extremely unpopular. Repeat this process at enough Government sites where SCO have their big moneymaking contracts and /etc/cpd will disappear from the next release :-) -- Ronald Khoo +44 81 991 1142 (O) +44 71 229 7741 (H) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102041220.aa06705@delmarva.delmarva.COM] <1991020412204300> From: scoggin@delmarva.delmarva.COM (John Scoggin) Newsgroups: comp.protocols.tcp-ip Subject: Promiscuous Mode - RS/6000 Ethernet Adapter Message-ID: <9102041220.aa06705@delmarva.delmarva.COM> Date: 4 Feb 91 12:20:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 I am getting an IBM RS/6000 Real Soon Now, and will be using it for some LAN monitoring studies. I need to place the IEEE 802.3 adapter into "promiscuous" mode, so that it will forward all traffic to my software. I am aware that this has been done on various Sun and DEC platforms - has anyone seen any PD code for RS/6000 AIX? Thanks in advance. ---------------------------------------------------------------------- John K. Scoggin, Jr. Supervisor, Network Operations Phone: (302) 451-5200 Delmarva Power & Light Company Fax: (302) 451-5321 500 N. Wakefield Drive Email: scoggin@delmarva.com Newark, DE 19714 "Never underestimate the bandwidth of a station wagon load of magnetic tapes screaming down the interstate!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102041401.AA06126@gateway.mitre.org] <1991020413591500> From: barns@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: When is a link saturated? Message-ID: <9102041401.AA06126@gateway.mitre.org> Date: 4 Feb 91 13:59:15 GMT References: <40@prang.TEST.Vitalink.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 I have been trying to interest people in using the Precedence field where appropriate, as well as TOS. There are some words in the draft update of Router Requirements RFC on what the router should do about precedence (along with what it should do about everything else). (This document is available as an Internet Draft at the usual places.) This, too, gets around the problem of the routers having to be told in advance which protocols are considered important. It also allows for the possibility that (for example) some SNMP traffic is considered very important and other SNMP traffic is considered expendable. I also drafted a qualitative description of what facilities a host should have for dealing with the precedence field. This hasn't been published anywhere but I'll send it to anyone who asks. Bill Barns / MITRE-Washington / barns@gateway.mitre.org ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102041451.AA06559@ftp.com] <1991020414513500> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: SVR4 and FTP's software Message-ID: <9102041451.AA06559@ftp.com> Date: 4 Feb 91 14:51:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 10 PC/TCP only includes POP[23] clients. There are at least three freeware POP3 servers available via the Internet, but I believe they all assume a Berkeley 'sockets' API for TCP. If your particular SysV has a reasonably complete 'sockets' implementation, you shouldn't have any trouble with the network side of the server, but at least some SysVs only support AT&T's 'streams' API for TCP. If you have one of these, you've got some coding to do... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [789@tiamat.fsc.com] <1991020416545400> From: jim@tiamat.fsc.com (Jim O'Connor) Newsgroups: comp.protocols.tcp-ip Subject: Re: SCO TCP/IP copy protection Message-ID: <789@tiamat.fsc.com> Date: 4 Feb 91 16:54:54 GMT References: <9101221000.AA21610@aprm> <670009@gore.com> <1991Jan29.232326.4284@anomaly.SBS.COM> Organization: Ahlstrom Filtration - Chattanooga,TN Lines: 25 In article <1991Jan29.232326.4284@anomaly.SBS.COM>, mpd@anomaly.SBS.COM (Michael P. Deignan) writes: > jacob@gore.com (Jacob Gore) writes: > > >Which is still a pain in the neck for the legitimate user: if you have a > >hundred machines, you need to keep a hundred sets of floppies for the times > >when the software on one of the machines needs to restored, and then you > >need to find the right set of floppies. > > Only one set of floppies, with multiple serialization numbers and > activation keys, would be necessary. Since this is true, I know I would be a whole lot happier with SCO if they would sell TCP/IP licenses, i.e. a piece of paper with an additional serial number/activation key combination. My job as a sysadmin would be much easier if I could buy one full product, including documentation and media, and then buy X additional licenses (hopefully, at a somewhat reduced price, since there is no media or docs involved) to use when installing on machines 2 to X. The same would be true of the ODT packages (which falls under the same topic since the TCP/IP is bundled in). Can you imagine proposing a site with 100 ODT workstations, and have to figure out what to do with 4400 floppy disks? ------------- James B. O'Connor jim@tiamat.fsc.com Ahlstrom Filtration, Inc. 615/821-4022 x. 651 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb04.181129.16606@nstar.rn.com] <1991020418112900> From: larry@nstar.rn.com (Larry Snyder) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp,comp.unix.sysv386 Subject: uucp over tcpip Message-ID: <1991Feb04.181129.16606@nstar.rn.com> Date: 4 Feb 91 18:11:29 GMT Organization: Northern Star Communications, Limited Lines: 10 I am having problems getting a uucp session going with another site connected via tcp-ip what do I need to put as a device in my Systems file? how do I map the raw device in my Devices file? -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} ----MESSAGE-END---- ----MESSAGE-BEGIN---- [jsparkes.665720047@bwdls49] <1991020502140700> Newsgroups: comp.protocols.tcp-ip From: jsparkes@bwdls49.bnr.ca (Jeff Sparkes) Subject: SCO <-> Sun == molasses Message-ID: Sender: usenet@bwdls61.bnr.ca (Use Net) Organization: Bell-Northern Research, Ottawa, Canada Date: 5 Feb 91 02:14:07 GMT I've set up a PC running SCO Unix 3.2.1. It mostly runs fine, but FTP and NFS traffic between it and a SparcStation 1+ running SunOS 4.1.1 is um, pathetic. FTP transfers of 0.5 K/s. NFS reads that (almost) never complete. I suspect the window size negotiation breaks down, since telnet works fine. Anybody know any workarounds/bugfixes? -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 Another feature is that the seats float, so that the airline can recover them if the plane crashes into the ocean. -- Dave Barry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb5.021603.29846@tmsoft.uucp] <1991020502160300> From: mshiels@tmsoft.uucp (Michael A. Shiels) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: SNMP code available? Message-ID: <1991Feb5.021603.29846@tmsoft.uucp> Date: 5 Feb 91 02:16:03 GMT Reply-To: mshiels@tmsoft.UUCP (Michael A. Shiels) Followup-To: comp.protocols.tcp-ip Organization: MaS Network Software and Consulting Lines: 3 I have some code which can be run on a PC for gathering SNMP data from other machines/routers etc. Is there any code available to manage/respond to data requests. Ie the server portion. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4605@softway.sw.oz.au] <1991020503064100> From: chris@softway.sw.oz.au (Chris Maltby) Newsgroups: comp.unix.xenix.sco,comp.protocols.tcp-ip Subject: SCO Xenix TCP/IP and nameserver problems Message-ID: <4605@softway.sw.oz.au> Date: 5 Feb 91 03:06:41 GMT Followup-To: comp.unix.xenix.sco Organization: Softway Pty Ltd, Sydney, Australia Lines: 41 We have a Xenix 2.3.2 system with SCO TCP/IP ver 1.0 acting as a server for our UUCP and other dial-up connections. As we are running BIND nameservers on other network hosts it seemed reasonable to enable the named on the Xenix system as a secondary. We then encountered the following problems. 1) named would cope with several requests ok, say for a few minutes then it would fail to respond again. Killing it and restarting would repeat the cycle. Sending it the signal which dumps the database works fine and the data is ok too. Note that they fail to document the requirement for the DOMAIN environment variable to be set to your local domain name for named and requesters to even work at all! 2) setting up resolv.conf to point at another machine for nameserver requests got around problem 1 at the expense of slightly longer delays. However, now rlogind (under Xenix) refuses to service requests from any of our local machines (and probably elsewhere). Depending on the requesting host the error message returned is : Address already in use EOF on input Error 0 which I assume means that rlogind can't cope with domain specified addresses being returned by gethostbyaddr() - though it could be a problem with the DOMAIN environment variable also. The problem goes away if you don't run named or use resolv.conf. Does anyone have any light to shed on this? We can cope without named for now, but forthcoming Internet connectivity will strain things a little. Chris -- Chris Maltby - Softway Pty Ltd (chris@softway.sw.oz.au) PHONE: +61-2-698-2322 UUCP: uunet!softway.sw.oz.au!chris FAX: +61-2-699-9174 INTERNET: chris@softway.sw.oz.au ----MESSAGE-END---- ----MESSAGE-BEGIN---- [38892@cup.portal.com] <1991020506545100> From: FelineGrace@cup.portal.com (Dana B Bourgeois) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <38892@cup.portal.com> Date: 5 Feb 91 06:54:51 GMT References: <14127@scorn.sco.COM> <90696@lll-winken.LLNL.GOV> <15702@milton.u.washington.edu> <1991Feb4.095500.10722@robobar.co.uk> Distribution: na Organization: The Portal System (TM) Lines: 15 This question is about application licensing. I am in the process of planning a 35 node network with PCs running Sun PC-NFS. One thing I would really like to do is to buy 5-10 copies of the popular PC applications like Microsoft Word and Lotus 123. I want to put just one copy on the network server and let users download/execute the application via PC-NFS. The problem is with potential licet(n}it(cS~e violations. Is there a way to enforce the maximum number of simultaneous users? On Novell Networks there is a product that does this from Rainbow Software. But they don't have anything for Unix/TCP/IP networks.{_ Anybody know of a solution so I can satisfy the software license restrictions? Dana Bourgeois @ cup.portal.com o ----MESSAGE-END---- ----MESSAGE-BEGIN---- [91036.130514EETD2777@Ryerson.Ca] <1991020508051400> Organization: Ryerson - Academic Computing Services Date: Tuesday, 5 Feb 1991 13:05:14 EST From: Message-ID: <91036.130514EETD2777@Ryerson.Ca> Newsgroups: comp.protocols.tcp-ip Subject: Using Kermit on VM_TELNET I've used Kermit while Telnetted from a VAX to another VAX machine. It's alot slower than downloading from the Host machine straight down the my PC but it wo rks at about half the speed. I can't use Kermit when telnetting from my VM account to a Vax or a VM it doesn 't work. Is there any way I can get this to work. Thanks Kevin Coutinho (KISEMAN@YORKVM1, EETD2777@RYERSON) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12316.27ae98c0@ecs.umass.edu] <1991020511363200> From: ucc@ecs.umass.edu Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: UCX and CDCnet problem Message-ID: <12316.27ae98c0@ecs.umass.edu> Date: 5 Feb 91 11:36:32 GMT Lines: 12 We are running UCX v1.3A. (The "A" if for a patch recommended by CSC that was applied). Our hardware is 2 6210s running VMS 5.4, clustered. We have an elusive problem, where at times, and not always on the same node, when a user tries to access the VAXcluster with a telnet process from a CDCnet device, (TDI) the user gets the message "USER AUTHERIZATION FAILURE", after typing in the password. However the password is correct and not expired, or preexpired. Has any body any ideas about this situation? Thank you! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb5.131333.2047@isavax.isa.com] <1991020513133300> From: cliffb@isavax.isa.com (cliff bedore*) Newsgroups: comp.protocols.tcp-ip Subject: Re: What is the voltage spec for thinnet? Message-ID: <1991Feb5.131333.2047@isavax.isa.com> Date: 5 Feb 91 13:13:33 GMT References: <1991Jan30.155606.21529@dartvax.dartmouth.edu> Reply-To: cliffb@isavax.isa.com (cliff bedore*) Distribution: usa Organization: ISA Inc. Arlington, VA Lines: 41 In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes: > > >What should the voltage be on thinnet? - I get readings of >-1.8 to -2.0 volts and .2 to .3 volts - is this in the >range? is 1.2 volts ok? > > Wayne At the risk of stepping into something soft and gooey, I thought I'd put on my engineers hat for a while and comment on this. First. It will be very traffic dependent (assuming you're using a voltmeter that does some averaging). Having stated that and not knowing the details of an ethernet board, but knowing something about transmission lines, we can get a wag of ranges for the voltages. The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine is cause I did it myself and haven't had problems). Power (watts) = voltage ^2 / resistance or voltage = sqrt( power * resistance) voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power These are for steady state DC levels. Ethernet is 10mbit/sec square waves +- distortion from the coax. This means the the voltage measures via some sort of averaging/rms/other meter would be something less (depending upon the actual waveform, activity on the cable etc. (This is true for thick or thinnet. the impedance on the cable is the same) This the voltages you measure will probably be in the range for correct operation, but without looking at the waveform, you could have a short with some DC voltage giving you the same result. Cliff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [huston.665763871@tiger1] <1991020514243100> From: huston@prime.com (Steve Huston) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: Date: 5 Feb 91 14:24:31 GMT References: <38836@cup.portal.com> Lines: 38 Nntp-Posting-Host: tiger1 Will@cup.portal.com (Will E Estes) writes: >I would like to get opinions on pros and cons for setting up an >Internet. The two setups are: You didn't say what sort of sites you're connecting, but from your mentioning connecting sites to a PDN, I'm thinking you've got clusters of machines, with the clusters connected by X.25 over PDN...if that's a bad assumption, sorry. >1) All sites on the internet have routers that attach to a public >data network, like UUNET's Alternet, and use TCP/IP to communicate >between nodes on the net. To the extent that X.25 might be used >underneath TCP between the routers, this is invisible to the >applications. >2) All sites on the internet connect directly to an X.25 network, >and any client-server applications between two sites are written >directly to an X.25 API or to some software abstraction that is >written on top of X.25. >What are the advantages to either approach? Clearly 2) is going >to be more efficient since you don't have the extra error-checking >of TCP and you don't have the extra data bandwidth of the router >headers being attached to each packet. This advantage aside, are >there any decisive advantages that argue for approach 1)? Approach 1 (TCP) buys you the flexibility of using a standard API (sockets, streams, etc.) while retaining the flexibility of changing/adding to your underlying network technology as your network grows, changes shape, etc. and communications technology improves. You can mix/match non-X.25 network elements with your existing X.25 parts, and your applications just keep working. Steve Huston +1 508 620 2800 ext 3099 Huston@Relay.Prime.COM Prime Computer, Inc. The opinions expressed above are not necessarily those of Prime Computer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb5.152919.7614@ns.network.com] <1991020515291900> From: robp@gumby.network.com (Rob Peglar) Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.unix.xenix.sco Subject: Re: Comtrol Summary: sigh Message-ID: <1991Feb5.152919.7614@ns.network.com> Date: 5 Feb 91 15:29:19 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> <1991Feb3.053341.5064@tcsc3b2.tcsc.com> Sender: news@ns.network.com Followup-To: poster Organization: Network Systems Corporation Lines: 243 Nntp-Posting-Host: gumby I am posting this as a warning to those of you who previously have or are considering purchasing products from Comtrol Corporation. This article is being cross-posted. The entire article represents the opinion of the author only and not any other person or organization. If you don't know about the multiport serial market and/or Comtrol, just hit "n" now. This is a very sad story. The year 1990 was a very tumultuous one for Comtrol. When I began 1990, taking the position of Manager, Software R&D, things weren't looking so good. I had four programmers and two tech support people working for me, and while their work was quite good, the overall perception of the company was, as our customers and competitors put it, "asleep at the wheel". And so it was; Comtrol's sales were far and away based on very old, non-intelligent (aka dumb) product; although Comtrol had one (the Smart Hostess line) intelligent product, the competition had, by far, the lion's share of the intelligent market. (note, the Ultra 186 was considered part of the Smart Hostess line, and was in the process of being phased out by the (then unavailable) Ultra 8/16) At that time, Comtrol was around 35 people. It was fairly profitable, since it tended to preserve 60% gross margins as a business priority. However, the competition was overwhelming Comtrol in terms of market share; while the pie was growing bigger, Comtrol was not growing as fast as the stockholders would like. So, the board decided to make two things happen (at once); grow the R&D staff, to design and deliver new products during 1990, and also concentrate on (hopefully) growing the international market by opening offices in Europe, using local (European) personnel. Comtrol had previously controlled all international operations from St. Paul. (in case you're confused by the terminology, Comtrol is privately held; the stockholders and the board are one and the same family) The first strategy, upgrade products/services, worked very well during 1990. In software, I added three programmers (net), and one tech support person. Thus, by August, Comtrol had seven programmers and two tech support people. The hardware R&D group added three engineers and one lab technician. Customers and competitors had noticed the new products (e.g. Ultra 8/16, Multivision, etc.etc.) hitting the market; and here's a testimonial from a real live UseNetter (John DeArmond) about Comtrol service. --cut-- From ns!noc.MR.NET!msi.umn.edu!umeecs!umich!ox.com!caen!sol.ctr.columbia.edu!emory!rsiatl!jgd Tue Jan 29 12:53:13 CST 1991 Article 7341 of comp.protocols.tcp-ip: Path: ns!noc.MR.NET!msi.umn.edu!umeecs!umich!ox.com!caen!sol.ctr.columbia.edu!emory!rsiatl!jgd >From: jgd@Dixie.Com (John G. DeArmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <6207@rsiatl.Dixie.Com> Date: 29 Jan 91 09:04:38 GMT References: <9101272223.AA08327@desktalk.com> Organization: Rapid Deployment Systems (making go-fast things and things that-go fast) Lines: 190 (lots of copy-protection argument stuff deleted) Customer Service will make or break your product. You'd damn well better plan for it as an integral feature of your product, fully as important as the software not crashing. Here's an example of how to and how not to do customer support. I have used 2 brands of intelligent async cards in Unix systems for my customers. One brand is Comtrol and the other is Stargate. I no longer use Stargate because of customer support. When I opened the first Comtrol box, the first thing I saw was a plastic gold card just like a credit card. On this card was printed the 800 toll free support number AND the names and direct dial numbers for the General Manager, the Engineering Manager, the Hardware Tech Support manager, the Software Tech Support manager, the Production manager, the Marketing manager and the Sales manager. Above this list of numbers is this statement: "Our committment to you doesn't stop with our products. We give you the support and the extra service you want. IT's because your satisfaction is our #1 priority. COMTROL is only a phone call away. You have full access to all COMTROL personnel. For your convenience, primary department contacts are listed below:" I've had one occasion to use the support number. A board arrived one evening DOA. I called just at closing time. COMTROL had someone drive a board down to Delta DASH and I got it in a few hours. They told me to return the DOA one when convenient and not to worry about shipping back the (very good) documentation. My Stargate experience was a bit different. I inherited my first card in some surplus stock I bought. The card uses address decode PALs that are specific for each OS. My card was equipped for Xenix and I needed a PAL for ISC Unix. I called up Stargate and reached a rather sullen tech support technician. I was told that a new PAL cost $150!!! I passed on the PAL and obtained one from a friend but ordered a driver disk for ISC. When it got here, it was accompanied by some Nth-generation xeroxed dot-matrix printed documentation that was practically unreadable and it would not install. It did not meet the specifications of ISC's installpkg facility. I copied the disk onto the system and installed it manually. Later, I needed to get an upgraded driver for a new version of the OS. I called Stargate for the upgrade, somewhat expecting to pay for it. I was told that I would either have to write (!) to the sales department who would investigate me as a customer and if I passed, would give me the secret password to their BBS where I could download the upgrade. Or I could write and include some money and get a disk. Write a letter in order to access a BBS indeed! Could they have been afraid that I had wirewrapped a board in my basement and wanted to steal the driver to make it work? Who knows. Now both boards work pretty well equally. But I'll never fool with Stargate again while I recommend COMTROL whenever the opportunity arises. The difference is service. I perceived a better value from COMTROL even though it cost more. (more deletions) -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it --cut-- Well. As I said, the first strategy was working out. However - the second was not, and between it and one heckuva bad decision by the GM of Comtrol during the spring of 1990 led Comtrol on an ugly downward balance sheet spiral. The Europe strategy was a complete fiasco. In terms of sales, the sales numbers were almost dead flat from the international sector, while the expenses increased by two orders of magnitude. Despite the board's insistent cry that "it's good, don't worry, it will be just peachy in long run" the balance sheet was overwhelmed by the cash flowing out of the company. The board turned a blind eye toward this, prefering to think that somehow, a miracle would turn it around. In fact, things just got worse. The GM was replaced in July, but that was too late. It's hard to perform major surgery when you cannot stop the flow of blood from the patient. As the European office took more and more cash out - in fact, the office space alone for the eight employees there was larger than the space for the entire US operation ! - and the marketing expenses went through the roof - and the vendors got stretched out to 90, 100, 120, >120 days - and the credit holds started appearing - and the line of bank credit was maxed out - and on and on. It was the classic snowball effect. Are you getting the picture? Comtrol was going through the classic small business phenomenon of having increased sales (around 10 percent overall CY 1990) and going nearly bankrupt at the same time. The bad decision in spring 1990 was to order and build up a huge (2 times more than Comtrol had ever spent in one month) product inventory, hoping that sales would magically take off in 2H90. The former GM failed to realize that the summer is just the wrong time to rely on increased sales, especially when you've only got three salesmen. (US) Well, the cash out was heavy. The products built in the spring did not sell (as fast as wanted). Inventory carrying costs became a burden. Most US and international distributors took a "wait-and-see" attitude, preferring to take normal quantities of dumb and/or Smart Hostess product. Cash flew out the door as marketing bonanzas (like exhibition at Comdex) and $150/night Las Vegas hotel rooms took their toll. All the while, R&D costs were held steady as a percentage of net sales, +- <5 percent. Even though the company was running in the red - bigtime - since July, the board continued taking cash out of the company in the form of "contributions" at the same pace that they always had. So, in late November 1990, in a classic, uncreative, knee-jerk, Control Data-type reaction, the board forced the GM to "eliminate positions" (the phrase that was used on me), a.k.a. chop heads. Of course, the R&D groups were hit hardest; no marketing heads rolled. Although never stated, the board clearly took the tactic of eliminating senior (read: decently paid) people. Three hardware people were gone. One SW person (the most senior in terms of career) was axed; three more (SW) were transferred to different divisions; the entire production group, whose only flaw was obeying orders, was dismissed; one (of the two) tech support people was booted. In all, around 15 people (out of 55) were chopped. Ironically, these changes leave Comtrol almost exactly where it was to start 1990, as we start 1991. Thus, a whole years' work was discarded. Sure, the new products are "there" - but there is hardly anyone left to continue. In no way can the current staff maintain the 1990 pace. Comtrol is certain to revert back to its "sleepy" posture in the market. The R&D engine was gutted. To continue the automobile analogy, the car is now coasting. 1990's rapid acceleration is now lost; the car will slow down. It may take a few months, but it is inevitable. Comtrol is still in the red, according to internal sources. The board lacks either the foresight, gumption, or ability to raise the necessary working capital from either themselves, a public equity or debt offering, or third-party financing. Without these sources of working capital - the banks are now quite wary (side story - the bankers were in the building on November 26, 1990 "Black Monday". anytime you see the bankers in on such a day, it is not a good thing) - Comtrol cannot continue to provide the level of products and services that Mr. DeArmond came to know and enjoy. To use a well-worn cliche, "the party's over" for Comtrol. From a customer point of view, I would heartily recommend products and services from either DigiBoard, Equinox, or (esp. internationally) Specialix Ltd. All have proven themselves to have directors that realize the value of employees and know how to run a business. In fact, Digi stock has recently soared; they are splitting 2 for 1 (in the form of a dividend); their revenues are up 71 % for the most recent FY quarter relative to last years' same quarter. There is talk of Digi buying Arnet. This is not an accident. People like Gene Olson at Digi, John Pettit at Specialix, and Craig "Wolf" Kozel at Equinox are fine people. They won't steer you wrong. In contrast, hear a (paraphrased) quote from a current Comtrol employee about the Comtrol GM: "every time I talk to (him/her), I feel like I'm getting the big run- around". If this happens with employees, what about you, the customer? Don't get me wrong, now. The people that are left, for the most part, at Comtrol are wonderful. I especially want to tribute the remaining engineering people - both HW and SW - as their work is top shelf. There just isn't enough of them now to maintain what was, what is, and what should be. The tech support is one person. The people that Mr. DeArmond mentioned in his testimonial - the "gold card" people - are for the most part now gone. Five out of the seven. A HW engineer is trying to manage the SW group. The entire production load has been transferred to Artist Graphics, where one can only assume that Comtrol product will get not just second, but Nth banana. All in all, it is a true shame. Now, if you are lucky enough to enjoy the tradition of superior Comtrol service, now and in the future, terrific. I am quite happy for you. I am only saying that the probability of such service is rapidly diminishing. Moral? When business turns south - and expenses rise - act immediately. Use your people creatively. People are not one-dimensional. Engineers can be great salesmen. If what you need is increased sales, make everyone a salesman. Flexible organizations can always survive business downturns - if the board has the fortitude and foresight to let change occur. Chopping 30% of your payroll does not solve the problem when the payroll is only 30% of the problem. Go after the 70% first - like high inventory, slow sales, super- fluous plant, offices, and equipment, unnecessary marketing campaigns. Find the necessary working capital to finance growth, People will almost always accept pay cuts rather than layoffs. An across-the-board 30% pay cut would have been much more effective than a 30% reduction in staff. The customer ends up suffering. Absolute truth - don't expand faster than your cash flow allows. QED. -- Rob Peglar Network Systems Corporation Internetwork Group 7600 Boone Avenue North robp@anubis.network.com Minneapolis MN 55428 (612)424-4888 x1028 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102060053.AA18076@ucbvax.Berkeley.EDU] <1991020515570000> From: boland@ECF.NCSL.NIST.GOV ("Boland, Tim") Newsgroups: comp.protocols.tcp-ip Subject: NIST Ordering Information Message-ID: <9102060053.AA18076@ucbvax.Berkeley.EDU> Date: 5 Feb 91 15:57:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 232 ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- November 14, 1990 Below is the information needed to obtain the U.S. GOSIP and NIST/OSI Implemen- tors Workshop (OIW) documents. All prices are in U.S. dollars and represent the most up-to-date information available at this time; for further pricing information and ordering details, contact the seller (all addresses and tele- phone numbers are to be found at the end). +-------+ | GOSIP | +-------+ GOSIP Version 1. ---------------- GOSIP Version 1 (Federal Information Processing Standard 146) was published in August 1988. It became mandatory in applicable federal procurements in August 1990. Addenda to Version 1 of GOSIP have been published in the Federal Register and are included in Version 2 of GOSIP. Users should obtain Version 2. GOSIP Version 2. ---------------- GOSIP Version 2 was issued as a draft early in 1989. It has undergone public review and comment. Version 2 was revised to address the comments received from industry and government; the revisions were subsequently reviewed and approved by the GOSIP Advanced Requirements Committee in March, 1990. Version 2 of GOSIP supersedes Version 1 of GOSIP. Version 2 of GOSIP makes clear what protocols apply to the GOSIP Version 1 mandate and what protocols are new for Version 2. The final text is now available via anonymous ftp. Version 2 is expected to become a Federal Information Processing Standard (FIPS) in early 1991. NIST Point of Contact: Jerry Mulvenna hardcopy: NIST Standards Processing Coordinator (ADP) on-line: available through anonymous ftp from osi.ncsl.nist.gov (129.6.48.100) as ./pub/gosip/gosip_v2.txt -- ascii ./pub/gosip/gosip_v2.txt.Z -- ...compressed ./pub/gosip/gosip_v2.ps -- PostScript ./pub/gosip/gosip_v2.ps.Z -- ...compressed available through anonymous ftp from nic.ddn.mil (192.67.67.20) as GOSIP-V2.TXT -- ascii GOSIP-V2.PS -- PostScript +-------------------------------------------------+ | NIST Workshop for Implementors of OSI Documents | +-------------------------------------------------+ The output of the NIST Workshop for Implementors of OSI (OIW) is a pair of aligned documents, one representing Stable Implementation Agreements (SIA), the other containing Working Implementation Agreements (WIA) that have not yet gone into the stable document. Material is in either one or the other of these documents, but not both, and the documents have the same index structure. The SIA is reproduced in its entirety at the beginning of each calendar year, with an incremented version number. Replacement page sets are distributed subsequently three times during each year (after each Workshop), reflecting errata to the stable material. The replacement pages constitute the next edition of that year's version. The WIA is reproduced in its entirety after each Workshop (held in March, June, September and December). OIW attendees automatically receive the WIA. The final 1990 meeting was on December 10-14; 1991 meeting dates are March 11-15, June 10-14, September 9-13, and December 9-13, all at NIST. SIA documentation is available from the U.S. Government Printing Office (GPO), National Technical Information Service (NTIS), and the IEEE Computer Society. In the future NIST intends to put SIA documentation on-line; watch this space for details. WIA documentation is available from NTIS and the IEEE Computer Society, as described below. NIST Points of Contact for the OIW: Tim Boland --management information Chairman, OIW Brenda Gray --administrative information OIW Registrar SIA, Version 3. -------------- This is the appropriate reference for GOSIP Version 1 (FIPS 146) and GOSIP Version 2 (FIPS 146-1). SIA, Version 3, Edition 1 (Dec, 1989). The SIA, V3E1 is published as NIST Special Publication 500-177. It is available from the GPO, NTIS, and the IEEE Computer Society. Change pages for March 1990 and for June 1990 are available from GPO. Use the stock number below when ordering these from GPO. Change pages for March 1990 are available from NTIS. hardcopy: GPO U.S. Government Printing Office GPO Stock Number: 903-015-00000-4 Price: $51.00 (base document + change pages) $21.00 (change pages for June and beyond only) $63.75 (base document + change pages) (Foreign) NTIS (base document) Order Number: PB 90-212192 Price: $60.00 (paper); $17.00 (microfiche) NTIS (March 90 Change Pages) NIST/SP-500/177-SUP Order Number: PB 90-257627/WCC IEEE Computer Society Press ISBN 0-8186-2075-7 Catalog No. 2075 Price: $75.00, $60.00 (Member) WIA (June, 1990). ------------------ The June, 1990 WIA, published as a NIST Interagency Report (NISTIR-4382), is the most recent copy of the WIA that is available to order. It is available in hardcopy from: NTIS Order Number: NISTIR-4382 NTIS Order #: PB 90-259-763 Price: $45.00 (paper); $11.00 (microfiche) (prices approximate; request pricing information when ordering) IEEE Computer Sociey Press (Call for Ordering Information) +--------------------+ | GOSIP Users' Guide | +--------------------+ GOSIP Users's Guide for GOSIP Version 1 --------------------------------------- This publication assists federal agencies in planning for and procuring OSI, especially for GOSIP Version 1. It provides tutorial information on OSI protocols as well as information on OSI registration, GOSIP technical evaluation, and GOSIP transition strategies. hardcopy: NTIS Order Number: PB 90-111212 Price: $23 (paper); $8 (microfiche) GOSIP Users's Guide for GOSIP Version 2 --------------------------------------- The companion Users' Guide for GOSIP Version 2 is in preparation. It should be available in draft form by February 1991. +-----------------------------+ | Addresses/Telephone Numbers | +-----------------------------+ Jerry Mulvenna Technology, B217 Gaithersburg, MD 20899 (301) 975-3631 mulvenna@ecf.ncsl.nist.gov Tim Boland --management information Chairman, OIW Technology, B217 Gaithersburg, MD 20899 (301) 975-3608 boland@ecf.ncsl.nist.gov Brenda Gray --administrative information OIW Registrar Technology, B217 Gaithersburg, MD 20899 (301) 975-3664 National Technical Information Service (NTIS) U.S. Department of Commerce 5285 Port Royal Road Springfield, VA 22161 (703)487-4650 IEEE Computer Society Press Order Department 10662 Los Vaqueros Circle Los Alamitos, CA 90720 1-800-272-6657 U.S. Government Printing Office Washington, DC 20402 (202) 783-3238 Standards Processing Coordinator (ADP) National Institute of Standards and Technology Technology Building, Room B-64 Gaithersburg, MD 20899 (301) 975-2816 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5737@auspex.auspex.com] <1991020518515300> From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: SVR4 and FTP's software Message-ID: <5737@auspex.auspex.com> Date: 5 Feb 91 18:51:53 GMT References: <9102041451.AA06559@ftp.com> Organization: Auspex Systems, Santa Clara Lines: 9 >If your particular SysV has a reasonably complete 'sockets' >implementation, you shouldn't have any trouble with the network >side of the server, but at least some SysVs only support AT&T's >'streams' API for TCP. If you have one of these, you've got some >coding to do... Or, if it's S5R4 and it's one of those, you've got some yelling-at-the-vendor to do, 'cuz S5R4 systems are *supposed* to come with a reasonably complete sockets implementation.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [NELSON.91Feb5145001@sun.clarkson.edu] <1991020520500100> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,comp.unix.xenix.misc,comp.unix.sysv386,comp.unix.sysv286 Subject: 3c501 users please read this Message-ID: Date: 5 Feb 91 20:50:01 GMT Sender: @grape.ecs.clarkson.edu Reply-To: nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) Organization: Clarkson University, Potsdam NY Lines: 19 Sorry to post this so widely, but since the question has come up recently twice on the net, and twice locally to Clarkson, people should be aware of this problem. The 3c501 cannot receive back-to-back packets (two packets addressed to the same host with no intervening packet). BSD Unix (well, SunOS and NeXTos at least) will attempt to fill your TCP window by sending back-to-back packets. Therefore, your TCP Window must not be larger than your TCP MSS. o Under KA9Q, use "tcp window 1024" and "tcp mss 1024". o Under SCO Xenix, use the UNDOCUMENTED ifconfig option -onepacket. o Under NCSA Telnet, use "maxseg=1024" and "rwin=1024". o Under FTP Software's PC/TCP, use "ipconfig window 1024". -- --russ Humble Quaker, and damned proud of it. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102051202.aa11630@Mercury.TWG.COM] <1991020601450500> From: oldera@MERCURY.TWG.COM Newsgroups: comp.protocols.tcp-ip Subject: Software Partners 32 Message-ID: <9102051202.aa11630@Mercury.TWG.COM> Date: 6 Feb 91 01:45:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Greetings, I am looking for a contact, marketing-type preferably, at the above company. At the least, a telephone number would be nice. Thanks in advance, Regards, Ed Alcoff Product Manager The Wollongong Group, Inc. 1129 San Antonio Rd. Palo Alto, Ca. 94303 e-mail: oldera@twg.com voice: (415) 962-7240 fax: (415) 962-5547 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.033424.21632@usenet.ins.cwru.edu] <1991020603342400> From: jb@falstaff.mae.cwru.edu (Jim Berilla) Newsgroups: comp.protocols.tcp-ip Subject: Re: What is the voltage spec for thinnet? Summary: What *are* you talking about? Message-ID: <1991Feb6.033424.21632@usenet.ins.cwru.edu> Date: 6 Feb 91 03:34:24 GMT References: <1991Jan30.155606.21529@dartvax.dartmouth.edu> <1991Feb5.131333.2047@isavax.isa.com> Sender: news@usenet.ins.cwru.edu Distribution: usa Organization: Case Western Reserve University Lines: 73 Nntp-Posting-Host: falstaff.mae.cwru.edu In article <1991Feb5.131333.2047@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes: >In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes: >> >> >>What should the voltage be on thinnet? - I get readings of >>-1.8 to -2.0 volts and .2 to .3 volts - is this in the >>range? is 1.2 volts ok? >> >> Wayne > >At the risk of stepping into something soft and gooey, I thought I'd put on >my engineers hat for a while and comment on this. > >First. It will be very traffic dependent (assuming you're using a voltmeter >that does some averaging). True. Don't use a voltmeter, use an oscilloscope. You'll see many interesting things. >Having stated that and not knowing the details of an ethernet board, but >knowing something about transmission lines, we can get a wag of ranges for >the voltages. Not true. The voltages on the ethernet are clearly defined. >The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine >is cause I did it myself and haven't had problems). > >Power (watts) = voltage ^2 / resistance or > >voltage = sqrt( power * resistance) > >voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power > >voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power What *are* you talking about? (And take off that silly hat.) In the case of ethernet, the voltage depends on the amount of current pulled out of the tap. It's independant of the power rating of the terminating resistors. Remember that the tap appears as a 25 ohm load, i.e. it's connected to two 50 ohm transmission lines. For the AM7996 transceiver (common in a lot of Sun's), the voltages are specified as follows: High level is between 0 and -.1 volts, low level is between -1.625 and -2.2 volts. As stated above, this voltage is generated by a current sink (to -9V) by the chip. An ideal current sink has infinite impedance, and doesn't load the transmission line. If two or more stations transmit at the same time, the voltage on the line goes below -2.2 volts. The chip detects collisions on this basis. >These are for steady state DC levels. Ethernet is 10mbit/sec square waves >+- distortion from the coax. This means the the voltage measures via some >sort of averaging/rms/other meter would be something less (depending upon >the actual waveform, activity on the cable etc. (This is true for thick or >thinnet. the impedance on the cable is the same) > >This the voltages you measure will probably be in the range for correct >operation, but without looking at the waveform, you could have a short with >some DC voltage giving you the same result. You can use a meter for a few tests on the ethernet, but it's very limited. On an inactive network, an ohmmeter accross the tap will read 25 ohms. If there are any stations transmitting, the reading will be jittery. If the network is shorted, it will read close to zero ohms. If a terminator is bad, or there is a break in the line, it will read 50 ohms. A voltmeter might tell you something, but I wouldn't use it if there's a scope around. -- Jim Berilla / jb@falstaff.cwru.edu / 216-368-6776 "My opinions are my own, except on Wednesday mornings at 9 AM, when my opinions are those of my boss." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [k2.665828184@woodstock] <1991020608162400> From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Re: UCX and CDCnet problem Message-ID: Date: 6 Feb 91 08:16:24 GMT References: <12316.27ae98c0@ecs.umass.edu> Organization: The Internet Lines: 45 ucc@ecs.umass.edu writes: >We are running UCX v1.3A. (The "A" if for a patch recommended >by CSC that was applied). Our hardware is 2 6210s running >VMS 5.4, clustered. >We have an elusive problem, where at times, and not always >on the same node, when a user tries to access the VAXcluster with a >telnet process from a CDCnet device, (TDI) the user >gets the message "USER AUTHERIZATION FAILURE", after typing >in the password. However the password is correct and not expired, >or preexpired. >Has any body any ideas about this situation? I have no idea on the "USER AUTHORIZATIOn FAILURE", but we also have trouble with CDCnet -> UCX1.3A Our problem: If somebody trys to connect from a CDCnet node to our VAX, the connection sets up, but he get no prompt, until he/she types in a Break-character. With some debugging, we found out, that the VAX doesn't respond immediately with a login prompt, if the other side doesn't support the Terminal Type option (as in CDCnet!). The prompt appears after some input, like a local terminal. That dolt CDCnet isn't able to send a character at this stage, only BREAK got it to send something! So there are two problems, one side is UCX which barfs on a missing Terminal Type Option, and CDCnet which isn't able to send at this stage. Sincerely, Klaus Steinberger -- Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende FAX: (+49 89)3209 4280 D-8046 Garching, Germany BITNET: K2@DGABLG5P Internet: k2@bl.physik.tu-muenchen.de ----MESSAGE-END---- ----MESSAGE-BEGIN---- [martino.665848297@krypton] <1991020613513700> From: martino@logitek.co.uk (Martin O'Nions) Newsgroups: comp.protocols.tcp-ip Subject: Re: LM/X Message-ID: Date: 6 Feb 91 13:51:37 GMT References: Organization: Logitek Plc. Lines: 26 WARD@CC.UMontreal.CA writes: >BTW, anyone one the net is running LAN Manager/packet driver combination ? >We would like to do so (and then use NCSA Telnet with LAN Manager). >We are also interested in adding a mail service in this configuration. >Any experience someone ? We don't use the packet drivers regularly with LM, largely because we have the 3+ Open TCP software kicking around everywhere, but we did run PC/TCP with LM for test purposes. There is a Packet Driver to NDIS TSR which feeds the packet driver requests into the NDIS stack, and feeds the response back up the chain. We had problems with early versions of this when doing repeated loads/unloads of the driver, (it crashed the machine) but I believe that this has been addressed (comments anybody?) Martin -- DISCLAIMER: All My Own Work (Unless stated otherwise) -------------------------------------------------------------------------- Martin O'Nions Logitek Group Support martino@logitek.co.uk -------------------------------------------------------------------------- Auntie did you feel no pain / Falling from that willow tree? Could you do it, please again / 'Cos my friend here didn't see. (Harry Graham - Ruthless Rhymes for Heartless Homes) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.140207.25450@bronze.ucs.indiana.edu] <1991020614020700> Newsgroups: comp.protocols.tcp-ip From: Zhen Li Subject: summary on transferring motion picture over IP Message-ID: <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Sender: daemon@bronze.ucs.indiana.edu (Mr Background) Organization: Indiana University Date: Wed, 6 Feb 91 14:02:07 GMT Lines: 69 Since I posted inquiry about transferring video over IP I have received more requests for summary than answers to the question. Following is what I have got so far. Many thanks to those who provided helpful information. I appreciate all of your help. Thanks! Jane -------------------------------------------------------------------------- From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston) I've seen experimental products that can handle about 1 4x5 inch 8-bit color image every 2 seconds. The problem is not the TCP/IP protocols per se, but the fact that they "typically" run over network media that are one or two orders of magnitude too slow for animated/video images. Count up the number of pixels in one frame, multiply by the number of bits behind each pixel, then compare to the 10 Mbits/sec serial bit rate of Ethernet. I think you'll find a major mismatch. -------------------------------------------------------------------------- Claudio Topolcic I don't have exactly the answer for you, but we routinely send live video across a DARPA-sponsored network in support of video conferencing. The network is called the Terrestrial Wideband Network, and we have multi-protoc ol routers that implement the ST protocol (formerly IEN 119, and now RFC 1190) as well as IP. This is a connection oriented internet protocol intended to support real-time applications such as voice and video. We use commercial video codecs to compress the video down to about 128 Kbps -------------------------------------------------------------------------- From: I.Wakeman@cs.ucl.ac.uk in reply to your request about video over IP, a fair amount of work is currently going on in this area, between UCL, BBN and others, using the ST protocol in the ARPA Wideband Terrestial Network (SIGCOMM90 paper). Currently ST is running separately from IP traffic, but real soon now, ST will be running over IP in the BBN gateways, and in BSD socket code that Craig Partridge is writing. Other work of interest is at UCB on DIstributed Continuous Media, David Anderson. There's also been an RFC on time critical constraints on data networks - something like 91 in the current series.The BSD people are interested in producing a UDP variant that can carry time critical data using time stamps. ... anyway, two rfcs of interest are: 1193: client requirements for real-time communications services 1192 Experimental Internet Stream Protocol (ST 2) THe work at UCB has at least 3 tech reports on Meta-Scheduling, UCB TR 90/597 Meta-scheduling for Distributed continuous media - Anderson TR 90/596 Abstractions for Continuous media in a network window system Anderson, Govindan, Homsy TR 90/599 Implementation Issues for a Network Continuous Media IO Server as above. These three deal with general issues for synchronous data over packet networks, as do many, many other papers Specific to IP, I don't know of any specific papers, other than experimental efforts to put ST inside IP. -------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [3213@ux.acs.umn.edu] <1991020614373800> From: acm@ux.acs.umn.edu (Acm) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip Subject: TCP-IP source for the AT&T 3B2 Summary: Help..Help..Help Keywords: AT&T, 3B2, TCP, IP, Network, Old, Monsters Message-ID: <3213@ux.acs.umn.edu> Date: 6 Feb 91 14:37:38 GMT Reply-To: acm@ux.acs.umn.edu (Acm) Followup-To: comp.dcom.lans Organization: University of Minnesota, ACSS Lines: 21 Does anyone know where we can get TCP-IP for the AT&T-3B2. We have 2 3B2 machines that were donated to us (association for computing machinery) by our most generous department of forestry...without the TCP-IP protocol OF COURSE. These two machines have ethernet cards and 5 1/4 inch floppy drives. If anyone has TCP-IP on a 3B2 floppy format please send it to us. If you have any brilliant ideas..please contact me at any of the email addresses mentioned below. Your help is most appreciated. Thank you. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ / ACM@mermaid.micro.umn.edu |If Your Nose RUNS and Your Feet Smell \ \ marcus@donald.cs.umn.edu |You Are Built UPSIDE-DOWN !! / / marcus@ai.mit.edu |-----------------------------------------\ \ marcus@a.system.near.you | Yes, My other Terminal IS a Z19 !! / /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102061621.AA11846@ftp.com] <1991020616213700> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <9102061621.AA11846@ftp.com> Date: 6 Feb 91 16:21:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 17 mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > Can copy-protection or license-protection systems such as SCO's be > used for a denial-of-service and/or harassment type of attack? You need to just look at the format of the udp packets, broadcast the same serial numbers from your own ip address, and that should have the desired effect of making you extremely unpopular. The big question is whether 'cpd' checks the source IP address - if it doesn't (and the check would have to be complicated due to 0 vs. 1 and subnet issues), then you can do this from anywhere in the Internet, but you can only hack one machine at a time. Of course, you'd need to know (or probe for) the relevant serial numbers... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [C-!-ZL%26@irie.ais.org] <1991020616260900> From: mbax@ais.org (Mark Baxter) Newsgroups: comp.protocols.tcp-ip Subject: Source routing info needed Message-ID: Date: 6 Feb 91 16:26:09 GMT Sender: mbax@ais.org Organization: UMCC, Ann Arbor, MI Lines: 8 Can someone provide me with some information on source routing (or a pointer)? Is source routing implemented at most sites? Is there a way to specify source routes in typical unix systems? If a source route is used to initiate a connection, will it automatically be reversed for replies? Does source routing cause a security problem (ie, one cannot trust an ip address to connect to a given site)? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.172144.12605@nmt.edu] <1991020617214400> From: nraoaoc@nmt.edu (NRAO Array Operations Center) Newsgroups: comp.protocols.tcp-ip Subject: SLIP documents Message-ID: <1991Feb6.172144.12605@nmt.edu> Date: 6 Feb 91 17:21:44 GMT Organization: National Radio Astronomy Observatory, Socorro NM Lines: 24 Where can I get some good documentation on SLIP? I have RFC1055, but it does not state which of the actual protocols it uses (presumably because it can use more than one). Now, I thought it used UDP in most implementations, and I'm trying to convince someone that he's not getting much, if any, error correction on his SLIP connections, but he wants actual written proof. He thinks it's using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links. I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is there such a beast? Our particular implementation is Rayan Zachariassen's streams SLIP for Suns. The closest thing I can find in the source code is that it includes the TCP header definition from /usr/include/netinet/tcp.h if SLIP_FASTECHO is defined (to give rlogin/telnet better response). But what about ftp? Does that use udp instead, or does SLIP just use raw IP in this case? And what implications does that have for error correction? While enough personal testimonials would help, more formal-looking documents would be better :-). Thank you all. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM rmilner@zia.aoc.nrao.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [74027@bu.edu.bu.edu] <1991020617301000> From: kwe@bu-it.bu.edu (Kent England) Newsgroups: comp.protocols.tcp-ip Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: <74027@bu.edu.bu.edu> Date: 6 Feb 91 17:30:10 GMT References: <38836@cup.portal.com> Sender: news@bu.edu.bu.edu Reply-To: kwe@bu.edu Organization: Boston University Information Technology Lines: 56 In article <38836@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes: > Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip > Subject: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 > Date: 4 Feb 91 02:09:29 GMT > > I would like to get opinions on pros and cons for setting up an > Internet. The two setups are: > > 1) All sites on the internet have routers that attach to a public > data network and use TCP/IP to communicate between nodes on the net. > > 2) All sites on the internet connect directly to an X.25 network, > and any client-server applications between two sites are written > directly to an X.25 API or to some software abstraction that is > written on top of X.25. > The wording is kind of hard to interpret, since I think "site" is used when "host" might be what is meant, but nonetheless ... I would decouple internet issues from application API issues and loosen up on the "either/or" tone and take an attitude of "one or more". If I had the choice of APIs to write to for client-server applications, it would be a session-style API and/or an RPC API that offers me virtual circuit streams-of-data service, simple unreliable messaging, and a robust transaction protocol that would be able to run on TCP/IP or OSI-IP or 802.2 as part of the operating system I was using. If I didn't have an OS that offered me a good session or RPC API, then I would still write that interface myself and write a lower level interface to TCP/IP and one to X.25. Then if I wanted more transport options in future, I wouldn't have to rewrite my client-server code, only yet another transport option for my session. The idea is to layer intelligently, hide what lower level information can be hidden, but write the API such that it anticipates the wide variety of transport services that it might have to use (connectionless, connection-oriented, high-bandwidth/low-latency, low-bandwidth/hi-latency, ...). As far as internet architectures go, allow for multiple protocols and overlapping transition periods. Keep your LAN and WAN technologies decoupled by using routers or capable bridges. Design with multi-protocol hosts and servers in mind. Give your users options, not mandates. X.25 is a WAN option to use public nets over the use of private lines, nothing more. I don't care for it as an alternative for available LAN technology. It has been more than four years since I heard anyone seriously talk about doing that. :-) --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.184300@sicsun.epfl.ch] <1991020617430000> From: goud@sicsun.epfl.ch (Mireille Goud) Newsgroups: comp.protocols.tcp-ip Subject: problem with ftp Message-ID: <1991Feb6.184300@sicsun.epfl.ch> Date: 6 Feb 91 17:43:00 GMT Sender: news@sicsun.epfl.ch Reply-To: goud@sicsun.epfl.ch (Mireille Goud) Organization: Ecole Polytechnique Federale de Lausanne Lines: 23 Keywords:ftp tcp I have a problem with ftp : I noticed that the packets size depends on the address of the hosts : - If the 2 hosts are on the same network (same B class address) the size of the packets is negociated between the 2 hosts. - If the 2 hosts are not on the same network (they don't have the same class address) the size of the packets is 512 bytes. 1. Is this a ftp problem or a tcp problem ? 2. Is there a solution to have big packets (4K bytes on fddi) even if the 2 hosts are not on the same network ? Thanks. Mireille ---------------------------------------------------------------------- Mireille Goud SIC EPFL Switzerland INET : goud@sic.epfl.ch ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5131@media-lab.MEDIA.MIT.EDU] <1991020618534800> From: hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky) Newsgroups: comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio Subject: Reed Solomon Code code Keywords: error-correcting codes Message-ID: <5131@media-lab.MEDIA.MIT.EDU> Date: 6 Feb 91 18:53:48 GMT Organization: MIT Media Lab, Cambridge, MA Lines: 13 Sorry for the wide distribution, but I'm not sure which newsgroup is appropriate for this query; I am trying to find source code or descriptions of software (or hardware) algorithms for Reed Solomon encoding/decoding. Specifically, I am interested in something which emulates the Cross Interleaved Reed-Solomon coding found on CDs, and the double encoding found on CD-ROMS. Any references (journals, conferences, books) would also be helpful. Thanks, Henry Minsky ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4132@zaphod.UUCP] <1991020620083100> From: bradg@zaphod.UUCP (Brad Gorzitza) Newsgroups: comp.protocols.tcp-ip Subject: Two TCP Queries Message-ID: <4132@zaphod.UUCP> Date: 6 Feb 91 20:08:31 GMT Distribution: na Organization: Develcon Electronics Limited,Saskatoon, SK, Canada Lines: 66 I have two tcp questions for this news group. My apo- logies if the answers appear in the RFC's somewhere or if these questions have been answered here before. Anyway, here goes. First question: consider the following setup. --------------- ------- ------- --------------- | Application | | TCP |==================| TCP | | Application | | A |+++++| A | Lan | B |++++| B | _______________ _______ Connection _______ _______________ Application A stops accepting data from TCP A. Appli- cation B continues sending data via TCP B until TCP A runs out of buffers and advertises window of 0. After a while, Application B closes the connection. What should TCP B do? According to RFC 793, SYN and FIN are included in the window (to give them retransmission protection). Hence, TCP B supposedly cannot send a FIN until TCP A opens its window again. Is this the case? If I want TCP B to exit could I simply have it do so, perhaps after sending a RST? Or am I bound by the RFC's to let things run their course? Second question: consider the following. TCP A is sending data to TCP B. *No* data is being sent the other way. TCP A TCP B ----- ----- send X bytes of data ---> seq # = Y ack # = Z <----- seq # = Z ack = X+Y send X bytes of data ---> . . . . . . . . . . . . My question is should TCP B retransmit its ack upon receiving a retransmission of data? Anyway, thanks in advance to any and all who reply. As this might be of interest to others, it might be an idea to reply to this newsgroup. -- ____________________________________________________________________________ Brad Gorzitza bradg@zaphod.uucp Develcon Electronics "If this is the road we take to our dreams, Saskatoon, Sask. do we walk in vain?" T'Pau ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.210842.5967@Think.COM] <1991020621084200> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: summary on transferring motion picture over IP Message-ID: <1991Feb6.210842.5967@Think.COM> Date: 6 Feb 91 21:08:42 GMT References: <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 44 In article <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Zhen Li writes: >From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston) > >Count up the number of pixels in one frame, multiply by the >number of bits behind each pixel, then compare to the 10 Mbits/sec >serial bit rate of Ethernet. I think you'll find a major >mismatch. Assuming 1k by 1k pixels per frame, 24 bits per pixel, 30 frames per second, that's 720 Mbps, apparently about two orders of magnitude off Ethernet speeds. However, this is not really a fair comparison. I think it is safe to expect that a protocol for real-time digital video transmission would use compression techniques. I'm no expert in data compression, but it seems like it should be possible to get very high compression ratios for motion pictures. First of all, within a frame you can do quite well with techniques based on run-length encoding and/or extrapolation. And the differences between successive frames are generally very small, so I would expect the protocol to only send the changes, rather than entire frames. And if the compression algorithm makes use of good image processing techniques, it could even recognize shifts of the entire background (very common, due to camera panning) and send a short encoding to compensate for it, rather than sending all the pixel-by-pixel differences. Colors can be encoded in fewer bits, using color maps (sending only the changes as they occur) and/or Huffman coding. Of course, all this compression requires lots of compute power. I'm not sure it could currently be done in real time, so I don't think you could put an Ethernet between a video camera and monitor. However, if the goal is to allow downloading from a server, this wouldn't be a problem. The video could be compressed in batch, and this compressed version would be stored in the database and downloaded directly to the monitor. Decompression is generally much easier than compression, so it can probably be done in real time There's a guy claiming to have developed technology to send videos over voice-grade phone lines, which are several orders of magnitude slower than Ethernet. He must be using techniques like these, and more. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.213527.29396@pa.dec.com] <1991020621352700> From: mcguckin@decwrl.dec.com (Joe McGuckin) Newsgroups: comp.protocols.tcp-ip Subject: Multiple modems w- PPP??? Message-ID: <1991Feb6.213527.29396@pa.dec.com> Date: 6 Feb 91 21:35:27 GMT Sender: news@pa.dec.com (News) Reply-To: mcguckin@decwrl.dec.com (Joe McGuckin) Organization: Digital Equipment Corporation Lines: 7 Does PPP support a link using 2 or more modems to increase bandwidth (like the NetBlazer)? Thanks, joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [21377@hydra.gatech.EDU] <1991020622182100> From: ce1zzes@prism.gatech.EDU (Eric Sheppard) Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip Subject: NCSA Telnet doesn't like PC-NFS Message-ID: <21377@hydra.gatech.EDU> Date: 6 Feb 91 22:18:21 GMT Sender: ce1zzes@prism.gatech.EDU Followup-To: comp.protocols.nfs Organization: Georgia Institute of Technology Lines: 16 I've gotten Sun's PC-NFS to work with the Clarkson packet driver. I have developed extreme disgust with Sun's Telnet and FTP, so I would like to use NCSA's Telnet and FTP. Unfortunately, Telnet and FTP won't work with PC-NFS. I get: Packet Access Type Error 10 Can't access IP handle interface to type 1 Packet driver probably not loaded Error code: -2 Telnet/FTP with the packet driver works very well when PC-NFS is not active. Are Telnet/FTP and PC-NFS doomed to be mutually exclusive? Is it possible to get them to cooperate? If so, how? I'm using a 3Com 3C503 card on a 286 machine. Eric ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb7.000327.15642@intellistor.com] <1991020700032700> From: warner@intellistor.com (Dave Warner) Newsgroups: comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio Subject: Re: Reed Solomon Code code Keywords: error-correcting codes Message-ID: <1991Feb7.000327.15642@intellistor.com> Date: 7 Feb 91 00:03:27 GMT References: <5131@media-lab.MEDIA.MIT.EDU> Distribution: usa Organization: Intellistor Lines: 22 In <5131@media-lab.MEDIA.MIT.EDU> hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky) writes: >Sorry for the wide distribution, but I'm not sure which newsgroup is >appropriate for this query; >I am trying to find source code or descriptions of software (or >hardware) algorithms for Reed Solomon encoding/decoding. Specifically, >I am interested in something which emulates the Cross Interleaved >Reed-Solomon coding found on CDs, and the double encoding found on >CD-ROMS. Try Neal Glover's book "Practical Error Correction Design for Engineers." It was published privately and I don't see an ISBN number but Neal I think can still be reached at (303)466-5228/5482. His company was bought out by Cirrus a while ago but I think the number is still good. Excellent book. -- _____________________________________________________________________ | Dave Warner | e-mail address: warner@intellistor.com | | Intellistor, Inc. | USmail address: 2402 Clover Basin Dr. | | (303)682-6555 | Longmont, CO 80503 | --------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [58278@eerie.acsu.Buffalo.EDU] <1991020700081300> From: opnrhen@acsu.buffalo.edu (Steve Rhen) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.xenix.sco,comp.unix.xenix.misc,comp.unix.sysv386,comp.unix.sysv286 Subject: Re: 3c501 users please read this Message-ID: <58278@eerie.acsu.Buffalo.EDU> Date: 7 Feb 91 00:08:13 GMT References: Sender: news@acsu.Buffalo.EDU Followup-To: comp.protocols.tcp-ip Organization: SUNY Buffalo Lines: 30 Nntp-Posting-Host: autarch.acsu.buffalo.edu In article nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: >Sorry to post this so widely, but since the question has come up >recently twice on the net, and twice locally to Clarkson, people >should be aware of this problem. > >The 3c501 cannot receive back-to-back packets (two packets addressed >to the same host with no intervening packet). BSD Unix (well, SunOS >and NeXTos at least) will attempt to fill your TCP window by sending >back-to-back packets. Therefore, your TCP Window must not be larger >than your TCP MSS. > > o Under KA9Q, use "tcp window 1024" and "tcp mss 1024". > o Under SCO Xenix, use the UNDOCUMENTED ifconfig option -onepacket. > o Under NCSA Telnet, use "maxseg=1024" and "rwin=1024". > o Under FTP Software's PC/TCP, use "ipconfig window 1024". > I've run into situations where it may be necessary to reduce the tcp and mss window sizes down as low as 512 to prevent excessive retransmits. Many TCP implimentations will use 512 mss packets if they think that the packet is leaving the local network. (This is recommended based on 576 MTU in gateway requirements in the absense of MTU discovery.) With local subnetting and high performance routers two short back to back back packets can be generated within the available the the receive window, causing the same poor performance. Stephen Rhen University at Buffalo opnrhen@ubvms.cc.buffalo.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb6.170053@thor.claremont.edu] <1991020701025300> From: kvc@thor.claremont.edu (Kevin V. Carosso) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Re: UCX and CDCnet problem Message-ID: <1991Feb6.170053@thor.claremont.edu> Date: 7 Feb 91 01:02:53 GMT References: <12316.27ae98c0@ecs.umass.edu> Sender: news@jarthur.Claremont.EDU Reply-To: kvc@thor.claremont.edu (Kevin V. Carosso) Followup-To: comp.protocols.tcp-ip Organization: Innosoft International, Inc. Lines: 22 In article <12316.27ae98c0@ecs.umass.edu>, ucc@ecs.umass.edu writes: >We have an elusive problem, where at times, and not always >on the same node, when a user tries to access the VAXcluster with a >telnet process from a CDCnet device, (TDI) the user >gets the message "USER AUTHERIZATION FAILURE", after typing >in the password. However the password is correct and not expired, >or preexpired. In the past I've had exactly this problem when the client TELNET sends line-feeds for end-of-line. Implementations of TELNET client based on the old Berkeley 4.2 code have a bug when binary mode is negotiated whereby they end the line with LF instead of CR. This causes your VMS username and password to never validate. This is not noticed on UNIX servers but for a few editors that run in raw mode and get confused by such clients. I've not experienced this problem with UCX, but that was because the broken Berkeley TELNETs have all been replaced around here long before UCX ever existed. /Kevin Carosso Innosoft ----MESSAGE-END---- ----MESSAGE-BEGIN---- [38975@cup.portal.com] <1991020701375000> From: Will@cup.portal.com (Will E Estes) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp Subject: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <38975@cup.portal.com> Date: 7 Feb 91 01:37:50 GMT Organization: The Portal System (TM) Lines: 7 Can someone briefly discuss any standards that might exist, or be in the process of development, for the sending of secure mail via SMTP or via the Internet. Also, are there any relevant RFCs on this topic? Thanks, Will Estes (apple!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [90901@lll-winken.LLNL.GOV] <1991020702552600> From: cabral@lll-crg.llnl.gov (Brian Cabral) Newsgroups: comp.protocols.tcp-ip Subject: Looking for a portable IPC subroutine package Message-ID: <90901@lll-winken.LLNL.GOV> Date: 7 Feb 91 02:55:26 GMT Sender: usenet@lll-winken.LLNL.GOV Reply-To: cabral@lll-crg.llnl.gov (Brian Cabral) Organization: Lawrence Livermore National Laboratory Lines: 17 Nntp-Posting-Host: gauss.llnl.gov [[I'm posting this for my friend Brian who doesn't have convenient access to the outside world. Please send replies directly to him. He'll summarize back to the group. Thanks! Casey]] I'm looking for a portable (BSD socket based) IPC subroutine package which will allow me to send a stream of data to multiple processes (possibly on different machines). Ultimately these data streams need to support multiple readers and writers. I know I can directly do this with sockets, however the resulting programs that use a hand coded implementation using sockets would be ugly. The key is to have a subroutine interace that is nearly as simple as open, read, write, and close for multiplexed distributed communication. Thanks in advance, Brian Cabral cabral@lll-crg.llnl.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb7.030423.4237@blilly.UUCP] <1991020703042300> From: bruce@balilly.UUCP (Bruce Lilly) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: UPS's with EThernet TCP/IP interface for UNIX -- are there any? Message-ID: <1991Feb7.030423.4237@blilly.UUCP> Date: 7 Feb 91 03:04:23 GMT Sender: news@blilly.UUCP (News Administrator) Organization: Bruce Lilly, Flushing, NY Lines: 18 There are a number of UPS's available with RS-232 interfaces to initiate an orderly shutdown of a system upon power failure. I would much prefer an UPS with an Ethernet interface, which could be used to initiate orderly shutdown of several systems. In this way, one would only need one such intelligent UPS for each independent power source, with other systems which are being fed from the same source connected to simple UPS's (no interface). No serial ports would be tied up on any of the machines. 1) Does such a unit exist (I'm only interested in TCP/IP over Ethernet, not Brand N network or Brand 3 network or anything else)? 2) If so, what specific protocol is used? / If not, has anybody developed a protocol which might be used for this application? Thanks for any pointers, Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8418@dmshq.mn.org] <1991020703400200> From: pnessutt@dmshq.mn.org (Bob Monio) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems Subject: Bi-directional Modems and Terminal Servers Keywords: telebit bidirectional xyplex servers Message-ID: <8418@dmshq.mn.org> Date: 7 Feb 91 03:40:02 GMT Reply-To: pnessutt@dmshq.UUCP (Bob Monio) Organization: Death Fleet Command Lines: 22 Our organization has recently purchased a Xyplex Terminal Server for use on our inhouse network. Because of some problems that we are currently having with our Telebit and our host, we are thinking about the possibility of moving the Telebit to the Xyplex and running it from there. Has anyone experienced connecting Telebits to Terminal Servers and if so, could you forward some of the experiences and/or helpful hints that you may have concerning it? To be more specific, we are running a T2500 on a MIPS RC3240 under Risc/OS 4.51. Any help and/or insight would be appreciated. Please respond to me via email. Thanks! -Bob -- Robert A. Monio International Quality Institute, Inc. "Rommel, you magnificent Bastard! pnessutt@dmshq.mn.org I read your book!" ..uunet!rosevax!sialis!dmshq!pnessutt -- George S. Patton, Jr. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BARNETT.91Feb7095228@grymoire.crd.ge.com] <1991020714522800> From: barnett@grymoire.crd.ge.com (Bruce Barnett) Newsgroups: comp.unix.misc,comp.protocols.tcp-ip Subject: Re: Will telnet do VT100 translation for other term types? Message-ID: Date: 7 Feb 91 14:52:28 GMT References: <1049@opac.uucp> Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.ge.com Followup-To: comp.unix.misc Organization: GE Corp. R & D, Schenectady, NY Lines: 21 In-reply-to: Dan_Jacobson@ATT.COM's message of 3 Feb 91 05:55:48 GMT >>>>> On 30 Jan 91 16:11:36 GMT, brianop@opac.uucp (BRIAN MCBEE) said: B> going to buy), but we have people that will be logging in from all B> kinds of different terminals. We would then like to be able to B> telnet from the unix system to a VAX running VMS, and run an B> application that REQUIRES vt100 terminal emulation. You can also use the program "vtem", which is somewhere in a comp.source archive. A newer version, updated by jqj@hogg.cc.uoregon.edu, is included in in my vttool program (available via ftp on titan.rice.edu, ~/sun-sources/vttool.shar.?) This program should run on almost any terminal, and it passed the vttest program. It does use pty's and is written for berkeley unix. If you are running X or SunView - the rest of the vttool package can provide a window-based panel for clicking function keys your terminal might not have. It also does keyboard remapping. It requires SunView or XView libraries. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb7.152839.8262@ux1.cso.uiuc.edu] <1991020715283900> From: klefstad@ux1.cso.uiuc.edu (Sue Klefstad) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problems with NCSA Telnet 2.3b14 Message-ID: <1991Feb7.152839.8262@ux1.cso.uiuc.edu> Date: 7 Feb 91 15:28:39 GMT References: <20949@hydra.gatech.EDU> Organization: University of Illinois at Urbana Lines: 15 ce1zzes@prism.gatech.EDU (Eric Sheppard) writes: >I just can't seem to get Telnet to work directly with my ethernet card. >... >Particulars: 80286 machine, 3Com 3c503 Ethernet card. Also installed I second the recommendation to use the Clarkson packet drivers. Telnet 2.3bxx is supposed to work directly with the 3c503 card but I've yet to find a machine in which it does. -- -- Sue -- ========================================================================= Sue Klefstad Ill. Natural History Survey klefstad@uiuc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [martino.665945174@krypton] <1991020716461400> From: martino@logitek.co.uk (Martin O'Nions) Newsgroups: comp.protocols.tcp-ip Subject: Re: LM/X and RFC1001 Message-ID: Date: 7 Feb 91 16:46:14 GMT References: <1991Feb4.074656.13601@ciba-geigy.ch> Organization: Logitek Plc. Lines: 39 whwb@ciba-geigy.ch (Hans W. Barz) writes: >Since we are interested in LM/X I tried to find out, who has really >implemented the RFC1001 correctly. RFC1001 has some nice mechanism build in to >avoid broadcast over internets. The interface on the 'otherwise broadcasting' >client sends a request to the domain server instead. New servers announce >their server capabilities to the domain server as well - this is kind of a new >feature for DNS (interactive update from client). >As a matter of fact no one seems to have implemented it. Only Ungermann/Bass >seems to have plans to do it and they are also delivering an interface to LAN >Manager. >Has somebody more information on that ? I could be wrong, but if I remember correctly, RFC1001 does allow for only a subset of the three transmission types to be implemented (although the usefulness of such a system could be questioned). A recent post stating that Hewlett-Packard's implementation worked across different logical IP networks would appear to imply that HP do provide the Datagram and Name Service handlers necessary for P and M type topologies - it was on this point that our attempts to link 3Com's RFC NetBIOS LAN Manager server, and SCO's ODT client failed, despite attempts to configure a NetBIOS agent. We still don't know if either of the implementations supports the agent, or if we simply couldn't find out how to use it properly...... I look forward to a full implementation from somebody. Martin -- DISCLAIMER: All My Own Work (Unless stated otherwise) -------------------------------------------------------------------------- Martin O'Nions Logitek Group Support martino@logitek.co.uk -------------------------------------------------------------------------- Auntie did you feel no pain / Falling from that willow tree? Could you do it, please again / 'Cos my friend here didn't see. (Harry Graham - Ruthless Rhymes for Heartless Homes) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [74148@bu.edu.bu.edu] <1991020717344800> From: kwe@bu-it.bu.edu (Kent England) Newsgroups: comp.protocols.tcp-ip Subject: Compressed Video Transport Requirements Message-ID: <74148@bu.edu.bu.edu> Date: 7 Feb 91 17:34:48 GMT References: <1991Feb6.140207.25450@bronze.ucs.indiana.edu> <1991Feb6.210842.5967@Think.COM> Sender: news@bu.edu.bu.edu Reply-To: kwe@bu.edu Organization: Boston University Information Technology Lines: 40 > From: barmar@think.com (Barry Margolin) > Newsgroups: comp.protocols.tcp-ip > Subject: Re: summary on transferring motion picture over IP > Date: 6 Feb 91 21:08:42 GMT > > I think > it is safe to expect that a protocol for real-time digital video > transmission would use compression techniques. ... within a frame you > can do quite well with techniques based on run-length encoding and/or > extrapolation. And the differences between successive frames are generally > very small, so I would expect the protocol to only send the changes, rather > than entire frames. And if the compression algorithm makes use of good > image processing techniques, it could even recognize shifts of the entire > background (very common, due to camera panning) and send a short encoding > to compensate for it, rather than sending all the pixel-by-pixel > differences. Colors can be encoded in fewer bits, using color maps > (sending only the changes as they occur) and/or Huffman coding. > I was impressed by Van Jacobson's 40-to-1 compression of TCP, using detailed information about the structure of TCP. I'm sure that something similar is possible for video sequences, using detailed information about the structure of video. The fascinating thing to me about compressed video is that real-time compressed video transfer dynamics will probably be nothing like uncompressed video or voice data streams. What is the maximum instantaneous bandwidth required to support these efficient real-time compression techniques? Do efficiently compressed video datastreams require reliable transport or minimum latency variation? What maximum latency and delay variance can they accept and still work acceptably in real time? What effect does lossage or error have on the final image? I would be interested in leads to research on what expected real-time compressed video technology will minimally demand of the underlying network. Does efficiently compressed video still require ST, for instance? --Kent ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb7.173536.8883@src.honeywell.com] <1991020717353600> From: dahl@SRC.Honeywell.COM (Peter Dahl) Newsgroups: comp.arch,comp.protocols.tcp-ip,comp.dsp,rec.audio Subject: Re: Reed Solomon Code code Keywords: error-correcting codes Message-ID: <1991Feb7.173536.8883@src.honeywell.com> Date: 7 Feb 91 17:35:36 GMT References: <5131@media-lab.MEDIA.MIT.EDU> <1991Feb7.000327.15642@intellistor.com> Sender: news@src.honeywell.com (News interface) Distribution: usa Organization: Honeywell Systems & Research Center Lines: 22 Nntp-Posting-Host: doip.src.honeywell.com In article <1991Feb7.000327.15642@intellistor.com> warner@intellistor.com (Dave Warner) writes: >In <5131@media-lab.MEDIA.MIT.EDU> hqm@media-lab.MEDIA.MIT.EDU (Henry Minsky) writes: >>I am trying to find source code or descriptions of software (or >>hardware) algorithms for Reed Solomon encoding/decoding. Specifically, >>I am interested in something which emulates the Cross Interleaved >>Reed-Solomon coding found on CDs, and the double encoding found on >>CD-ROMS. >Try Neal Glover's book "Practical Error Correction Design for Engineers." >It was published privately and I don't see an ISBN number but Neal >I think can still be reached at (303)466-5228/5482. His company >was bought out by Cirrus a while ago but I think the number is still >good. Excellent book. Also try this one: "Error-Control Coding for Computer Systems", T. Rao and E. Fujiwara, Prentice-Hall, 1989, ISBN 0-13-283953-9. This has a good description of RS coding, but not the discussion is not specific to CDs so you may have to figure it out. peter dahl@src.honeywell.com I had fun once, and it wasn't anything like this ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4320@ns-mx.uiowa.edu] <1991020718482600> From: jnford@handlebar.weeg.uiowa.edu (Jay Ford) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <4320@ns-mx.uiowa.edu> Date: 7 Feb 91 18:48:26 GMT References: <1991Feb6.172144.12605@nmt.edu> Sender: news@ns-mx.uiowa.edu Reply-To: jnford@handlebar.weeg.uiowa.edu (Jay Ford) Organization: Weeg Computing Center, University of Iowa, Iowa City, IA, USA Lines: 32 In article <1991Feb6.172144.12605@nmt.edu>, nraoaoc@nmt.edu writes: |> Where can I get some good documentation on SLIP? I have RFC1055, but it does |> not state which of the actual protocols it uses (presumably because it can use |> more than one). Now, I thought it used UDP in most implementations, and I'm |> trying to convince someone that he's not getting much, if any, error correction |> on his SLIP connections, but he wants actual written proof. He thinks it's |> using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links. |> I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is |> there such a beast? SLIP does not "use" any transport or application protocols. SLIP simply provides a way to transmit IP traffic over a serial line. In effect, it gives you a link layer over a serial line functionally similar to that provided by Ethernet for use on coax (or fiber, or twisted pair, or microwave...). Once you have a working link layer to run IP over, you can run any transport (UDP, TCP, etc) over IP on that link. The upper layers don't care what the medium is. That's the point of a layered approach to networking! Applications use whatever transport protocol is appropriate, independent of the link layer. TELNET, FTP, SMTP and others use TCP; NFS, DNS, and others use UDP. Basically, the only difference you should see between an Ethernet Internet connection and a SLIP Internet connection is the speed and throughput. ------------------------------------------------------------------------ Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242 jnford@handlebar.weeg.uiowa.edu, 319-335-5555 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102071854.AA14699@uh.msc.umn.edu] <1991020718545400> From: tjs@MSC.EDU (Tim Salo) Newsgroups: comp.protocols.tcp-ip Subject: Re: Pros/Cons of TCP+Router vs. X.25 Message-ID: <9102071854.AA14699@uh.msc.umn.edu> Date: 7 Feb 91 18:54:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 > However, the original question did not indicate whether the proposed > solution was a public X.25 network or a private X.25 network. I am about to stand corrected, (the proposed solution was a public X.25 network). > If the proposed solution is a private, (rather than public), X.25 network, > then per-packet charges are most likely not an issue. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7566@exodus.Eng.Sun.COM] <1991020719161100> From: karl@lvs.Eng.Sun.COM (Karl Auerbach) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: <7566@exodus.Eng.Sun.COM> Date: 7 Feb 91 19:16:11 GMT References: <38836@cup.portal.com> Sender: news@exodus.Eng.Sun.COM Followup-To: comp.protocols.iso Organization: Sun Microsystems, Mt. View, Ca. Lines: 42 In article <38836@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >I would like to get opinions on pros and cons for setting up an >Internet. The two setups are: > >1) All sites on the internet have routers that attach to a public >data network, like UUNET's Alternet, and use TCP/IP to communicate >between nodes on the net. To the extent that X.25 might be used >underneath TCP between the routers, this is invisible to the >applications. > >2) All sites on the internet connect directly to an X.25 network, >and any client-server applications between two sites are written >directly to an X.25 API or to some software abstraction that is >written on top of X.25. > >What are the advantages to either approach? Clearly 2) is going >to be more efficient since you don't have the extra error-checking >of TCP and you don't have the extra data bandwidth of the router >headers being attached to each packet. This advantage aside, are >there any decisive advantages that argue for approach 1)? Don't bet on approach #2 being automatically more efficient. A router can run a number of parallal X.25 connections and spread the traffic across those. (You may find some X.25 providers will constipate a given X.25 virtual circuit well before you exhaust the interface circuit bandwidth, so by using multiple VCs you can push more packets.) And I doubt that you will reach data rates over the typical X.25 (or TCP or OSI over X.25) that will even begin to make the TCP/IP or OSI checksumming, etc increase to a noticable level. (This is not to say that some networks may offer high performance X.25 service. It's just that most of the providers that I see don't. If they did then your overhead concern would begin to be meaningful. But I suggest that you might find that the burden of dealing with X.25, even at low data rates, greatly exceeds the cost of TCP/IP or OSI connectionless network and transport layer.) Approach #1 will give you more portable code (assuming you are programming to a fairly standard interface like "sockets".) --karl-- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27b1bd10.20dc@uop.uop.edu] <1991020720481600> From: nsayer@uop.edu (Nick Sayer) Newsgroups: comp.protocols.tcp-ip Subject: How widespread is RFC931 on the internet? Message-ID: <27b1bd10.20dc@uop.uop.edu> Date: 7 Feb 91 20:48:16 GMT Organization: University of the Pacific, Stockton, CA [138.9.200.1] Lines: 26 We've just put in an RFC931 authd daemon on our system. Some experimental connection attempts to other sites' auth ports resulted in refused connections, which leads me to believe that not many sites have authd set up. Is this the case? For those of you unfamiliar with the concept, it allows a system on one end of a TCP stream to ask the system on the other end what user (by user ID string) is responsible for the stream. For example, if a user telnets to some site and manages to break into someone's account, a record could be made not only of the site from where he came, but the account he came from. This makes the potential audit trail a little easier to follow. I am considering hacking the in.telnetd at our site so that it will insist on having authd set up at sites telneting in, but if not many sites have an auth daemon running, there's not much point. -- Nick Sayer | Disclaimer: "Don't try this at home, | RIP: Mel Blanc mrapple@quack.sac.ca.us | kids. This should only be done by | 1908-1989 N6QQQ [44.2.1.17] | trained, professional idiots." | May he never 209-952-5347 (Telebit) | --Plucky Duck | be silenced. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb07.214707.16739@ecst.csuchico.edu] <1991020721470700> From: madams@ecst.csuchico.edu (Michael E. Adams) Newsgroups: comp.protocols.tcp-ip Subject: have you compiled NCSA Telnet w/Turbo C? Keywords: Turbo C NCSA Telnet Message-ID: <1991Feb07.214707.16739@ecst.csuchico.edu> Date: 7 Feb 91 21:47:07 GMT Sender: news@ecst.csuchico.edu (USENET) Organization: California State University, Chico Lines: 19 I won't waste your time detailing the aggravation I experienced sorting out the tel23src.zip rats nest of files from NCSA. Still, I would love to hear from anyone who has successfully compiled the Telnet programs with Turbo C. The idea that I'm wasting my time on a dead end project really makes me ill. Just knowing it "has" be done would be comforting. -Thank you for your support. (___) | Michael E. Adams (o o) | Custom Computer Programming /-------\ / | P.O. Box 5027 / | ||O | Chico, California 95927-5025 U.S.A. * ||,---|| | ~~ ~~ | internet: madams@cscihp.ecst.csuchico.edu No BULL bandwidth | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb7.235137.2411@sapphire.idbsu.edu] <1991020723513700> From: alex@sapphire.idbsu.edu (Alex Feldman) Newsgroups: comp.protocols.tcp-ip Subject: UDP (RFC 768) Message-ID: <1991Feb7.235137.2411@sapphire.idbsu.edu> Date: 7 Feb 91 23:51:37 GMT Sender: alex@sapphire.idbsu.edu (Alex Feldman) Distribution: na Organization: Boise State University Lines: 18 I have read RFC 768, but I don't understand the psuedo header, viz: Is UDP Length in the psuedo header the same as Length in the header? If so, why do that, and if not, what is the difference? Is the protocol field always 17? Again, why bother or what else is it? Why the source IP address? Help. --alex alex@opal.idbsu.edu -- --alex alex@opal.idbsu.edu Boise State University doesn't have any opinions. Therefore, these are not the opinions of Boise State University. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [b0i6uk.l59@wang.com] <1991020801302000> From: fitz@wang.com (Tom Fitzgerald) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: Date: 8 Feb 91 01:30:20 GMT References: <9102061621.AA11846@ftp.com> Organization: Wang Labs, Lowell MA, USA Lines: 19 > You need to just look at the format of the udp packets, broadcast the > same serial numbers from your own ip address, and that should have the > desired effect of making you extremely unpopular. jbvb@FTP.COM (James B. Van Bokkelen) writes: > The big question is whether 'cpd' checks the source IP address - if it > doesn't (and the check would have to be complicated due to 0 vs. 1 and > subnet issues), then you can do this from anywhere in the Internet... ??? Isn't it possible to forge the source IP address to be a random node on the same subnet as the victim? The destination certainly won't be sending any responses back.... On the other hand, don't most routers across the Internet disable directed broadcasts? --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz ----MESSAGE-END---- ----MESSAGE-BEGIN---- [NETMAILR11020720343CCO1376@MVS.DRAPER.COM] <1991020801340000> From: CCO1376@mvs.draper.COM Newsgroups: comp.protocols.tcp-ip Subject: SUBNET DIRECTED BROADCASTS Message-ID: Date: 8 Feb 91 01:34:00 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 57 We have discovered a problem on our network and would like to know if other sites have seen this problem. Solutions will be cheerfully accepted, also. We are running a subnetted class B network with a mixed bag of PCs, workstations, minis and mainframes: IBM, Apple, Sun, HP, DEC, etc. In order to better localize broadcast traffic to the originating subnet, we have configured most of this equipment to use the Subnet Directed Broadcast address: {,,-1} as described in RFC 1122, Section 3.3.6. Due to the need to support B-node NETBIOS over TCP (ala RFC 1001, 1002), the PCs using this protocol use the All-Subnets Directed Broadcast address: {,-1,-1}. Since our routers (Wellfleet) will pass All-Subnets Directed Broadcasts, we are able to provide the connectivity required for this service. Note, the routers themselves use Subnet Directed Broadcasts for RIP. So far, so good. We did notice, however, that there was a large number of ICMP Destination Unreachable (Port Unreachable) messages being generated. We traced this activity to the ULTRIX, UCX, AIX, A/UX, and OS/2 (but not SunOS) systems responding to the UDP All-Subnets Directed Broadcast from the NETBIOS machines. Apparently a lower layer of software in these machines accepts this traffic and passes it to a higher layer that is then unable to recognize it as a broadcast. It would seem that, recognizing the broadcast nature of the message, the higher layer should drop it quietly. (Imagine all hosts on a network, except one, responding to ARP with "not me" messages.) :-) One supporting piece of evidence of the underlying pathology is that the offending machines can be silenced by configuring them to use All-Subnets Directed Broadcasts, but that then loses the advantage of localizing these broadcasts. Furthermore, these offending machines now complain about the RIP packets, which use Subnet Directed Broadcasts. Reading in RFC1122 is enlightening. First, referring to the above mentioned broadcast address definitions in Section 3.3.6 it says, "A host MUST recognize any of these forms in the destination address of an incoming datagram." Earlier, in Section 3.2.2 it says, "An ICMP error message MUST NOT be sent as the result of receiving: ... a datagram destined to an IP broacast or an IP multicast address, ..." Lest there be any misunderstanding, it goes on to say, "THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES." The subsequent "discussion" goes on to describe the *exact* problem we observed, that is, a UDP broadcast to a non-existent port that triggers a flood of ICMP Destination Unreachable datagrams! ------------------------------------------------------------------------ Cecil C. Ogren cogren@draper.com C.S.Draper Laboratory (617)258-1655 555 Technology Square Mail Station: 33 Cambridge MA 02139 ------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12660266244.22.PADLIPSKY@A.ISI.EDU] <1991020801593300> From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: <12660266244.22.PADLIPSKY@A.ISI.EDU> Date: 8 Feb 91 01:59:33 GMT References: <38836@cup.portal.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Will Estes-- Although I could, if I were willing to risk the Wrath of Postel, offer a semi-reputable definition of "datagram" that would render the notion of "reliable datagram" non-oxymoronic, even I know of no definition of "Internet" that would salvage the notion of an X.25-only Internet. Indeed, by definition an X.25 communications subnetwork is a single net, not an inter-net; that is, "Internet" is not a contraction of "intercomputer network", it's a replacement for the earlier, but apparently too subtle, term, "catenet" (originally meant to convey a concatenation of sundry individual/single comm subnets). On second thought, considering what happened to the term "gateway" once the heffalumpers got at it, perhaps I should say that "Internet" was never INTENDED to be a mere contraction for "intercomputer network", though IFF it were used in that solecistic sense I suppose your second alternative would at least be lexically licit. It would still be a bad idea, however, since it's precisely to allow Host computers attached to various/"all" comm subnet "technologies" to interoperate that the proper sense of Internet (and Catenet before it) was invented for--and it's precisely that breadth of attachment options which X.25 precludes, almost by definition and certainly in practice (since even "X.75"'s presence to connect independent X.25 instances does not cover the very common case of Local Area Networks which are not attached to via X.25, Host-to-LAN; thus, there can't/couldn't be a REAL X.25 Internet until and unless the world went mad enough to force LANs to present almost utterly inappropriate to LAN interfaces). cheers, map P.S. Lest any of the usual X.25 apologists be tempted to argue that X.25 SHOULD be the required interface to all LANs, I'd observe that such matters should only be discussed on the CCITT1996 and/or CCITT2000 mailing lists, not here--and I'd wish them the best of luck in getting it adhered to even if they do get it voted for.... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [746@sulaco.Sigma.COM] <1991020802194400> From: merlin@sulaco.Sigma.COM (David Hayes) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 Message-ID: <746@sulaco.Sigma.COM> Date: 8 Feb 91 02:19:44 GMT References: <38836@cup.portal.com> Reply-To: merlin@sulaco.sigma.com (David Hayes) Organization: /u/lib/news/organization Lines: 7 One question which I have not seen addressed is the cost of the media. X.25 lines are typically charged by the (X.25) packet. Therefore, your monthly cost can vary widely, depending on how much data is sent. All of the present IP network providers sell you a pipe of a given size, say, 56k bits per second, for a flat rate regardless of actual usage. David Hayes ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.022256.10641@evax.arl.utexas.edu] <1991020802225600> From: goldstn@evax.arl.utexas.edu (David Goldstein) Newsgroups: comp.protocols.tcp-ip Subject: Problems with heterogeneous networks Message-ID: <1991Feb8.022256.10641@evax.arl.utexas.edu> Date: 8 Feb 91 02:22:56 GMT Distribution: na Organization: Computer Science Engineering Univ. of Texas at Arlington Lines: 195 For quite some time I've been unable to debug TCP/IP code that behaves as follows: sockets are used to communicate at port #2700. the same code is used on each machine. sun4 -> sun4 fine sun4 -> sun3 fine sun3 -> sun4 connects properly, but sending gets bad address on the Unix "write".. seems as if the socket # is correct though sun3 -> sun3 " VAX (Ultrix) and Sun4 -> does not connect Can anyone give me some insight on this problem? Enclosed is some of the relevent source code, loaded with print statements for debugging. Thanks very much for even reading! David /********************************************************************** Name: Setup sockets Abstract: This routine sets up sockets for the interactive workstations. The white workstation connects at a reserved port. A server port is set up for the other workstations. The ports are set to be non-blocking so that an "accept" can be done in a loop without hanging. Revision History: 06/06/90 D. Goldstein ***********************************************************************/ #include /* #include */ #include #include /* #include */ #include #define SETUP_SOCKETS #include #include "my_sockets.h" #include "tcmipc.h" #include "icm.h" #include "stats.h" #define TRUE 1 #define FALSE 0 /* extern int have_told_tcm_quitting; */ extern long int timer[20]; /* Make a socket and listen for connections */ int make_server_socket(serv_port) int serv_port; /* server port */ { extern struct hostent *gethostbyname(); struct hostent *rhp; int s, on =0; struct sockaddr_in raddress; s = socket(AF_INET, SOCK_STREAM, 0); if (s < 0) give_error("socket in make_server_socket"); /* look up address of the destination machine */ if ((rhp = gethostbyname(my_host_name)) == NULL) give_error("gethostbyname make_server_socket"); bzero((char *)&raddress, sizeof(raddress)); bcopy(rhp->h_addr,(char *)&raddress.sin_addr,rhp->h_length); raddress.sin_family = AF_INET; /* raddress.sin_addr.s_addr = INADDR_ANY; */ raddress.sin_port = serv_port; /* server port */ if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) give_error("setsocketopt in make_server_socket"); if (bind(s, (struct sockaddr *) &raddress, sizeof(struct sockaddr_in))) give_error("bind_socket"); if (listen(s, 10) < 0) give_error("listen make_server_socket"); return(s); } look_for_host(i,count) int i,count; { struct hostent *hp; extern struct sockaddr_in Host_addr; extern struct hostent *gethostbyname(); int sock; printf("Establishing connection to workstation on host |%s|\n",ws[i].name); hp = gethostbyname(ws[i].name); if (hp == (struct hostent *) 0) give_error("gethostbyname"); /* Get local host address */ bzero((char *)&Host_addr, sizeof(Host_addr)); bcopy(hp->h_addr, (char *)&Host_addr.sin_addr, hp->h_length); Host_addr.sin_family = AF_INET; Host_addr.sin_port = ws[i].adrs; printf("will accept %s at #%d\n",ws[i].name,ws[i].adrs); if ((sock=socket(AF_INET,SOCK_STREAM,0))<0) give_error("socket"); while (connect(sock,(struct sockaddr *)&Host_addr,sizeof(Host_addr))<0); printf("%s connected %d = TRUE at socket %d\n",ws[i].name,i,sock); connected[i] = TRUE; who_head = insert(ws[i].name,who_head,sock,TCP); return(sock); } b4accepting(i,count) int i,count; { sock[i] = make_server_socket(ws[i].adrs); if (dont_block(sock[i]) < 0) perror("Creating non-blocking pilot socket"); fprintf(stderr,"%s: B4listening, listening for %s at socket# %d.\n", my_host_name,ws[i].name,ws[i].adrs); } accepting(i) int i; { int g; g = accept(sock[i],0,0); /* modifies a copied socket */ if (g > 0) { sock[i] = g; fprintf(stderr,"%s: Connected at socket # %d: %s\n", progname,g,my_host_name); if (dont_block(sock[i])< 0) perror("Resetting non-blocking attributes"); connected[i] = TRUE; who_head = insert(ws[i].name,who_head,sock[i],TCP); printf("connected to proc %d= TRUE, %s uses socket %d\n", i,ws[i].name,sock[i]); } else if ( g < 0 && errno != EWOULDBLOCK) { fprintf(stderr,"%s: Error connecting %s\n", progname,my_host_name); perror("accepting connection"); } else { sleep(1); printf("in never-never land?\n"); /* Terminate(1); */ } } setup_sockets(count,vars) int count; char *vars[]; { int length,msgsock, connecting=0; struct sockaddr_in server; int g,i,j,c, iterat = 0; struct hostent *hp; extern struct sockaddr_in Host_addr; extern struct hostent *gethostbyname(); extern give_error(); /* NOTE: all 'C' arrays are 0-based, but command-line args 1-based, hence arrays are indices are compensated for */ last_ws = count; gethostname(my_host_name,HOST_NAME_LENGTH); printf("Hostname is %s of %d workstations\n",my_host_name, last_ws); for (i=0; i0) { /* printf("look for host\n"); */ sock[i]=look_for_host(i,count); if (connected[i]) connecting++; else sleep(1); } if (!(iterat%10000)) printf("can't form a connection\n"); } printf("exiting setup sockets"); fact_message.type = FACTS; fact_message.num_facts = 0; } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [morrison.665986295@herodotus.cs.uiuc.edu] <1991020804113500> From: morrison@cs.uiuc.edu (Vance Morrison) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Beta testers from PCroute 2.2 needed Message-ID: Date: 8 Feb 91 04:11:35 GMT Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 58 Call for Beta-Testers for PCBridge I have just completed the next version (2.2) of PCRoute and now need beta testers to help exercise the new features. For those who don't know PCroute is a simple but very useful piece of software that can convert a IBM-PC with networking cards into an IP router. Thus it is possible to assemble for under $1000 a router that has performance like commercial routers costing $5000 or more. Since Version 2.0, I have not had the equipment or time to do very much with PCroute. Nevertheless, I was able to add some things that were needed and relatively easy to do. In particular Support for the WD8003EBT and WD8013EBT cards. These cards have more buffer memory, so they will not exhibit the problem with NFS that can be a problem with the WD8003E card. Also the WD8013 is a 16 bit card and should speed up packet forwarding 2-4 times over the WD8003E card. Packet Driver Support Packet drivers allow PCroute to use a variety of ethernet boards besides the WD800X family. Performance is not as good, but if you are on a tight budget and have old ethernet cards handy, it is likely you can make PCroute run with what you have. New serial code. Although the code has changed significantly, the outside effects are minimal at his point. Basically the only new features is the ability to handle > 2 serial interfaces and the ability to do CTS-RTS hardware flow control (useful if you are using smart modems that do compression). This new code also is designed to make adding PPP, compression or synchronous support easy. The beta-test software is available on accuvax.nwu.edu (129.105.49.1) in the directory pub/pcroute/exp. The files are called pcroute2.2b.tar.Z and pcroute2.2b.src.tar.Z and are compressed TAR archives. Please remember this is BETA test code. It should work, but may not. If you are inexperienced in networking or PCroute, you may want to use the old version or wait a couple of weeks until we have more confidence that everything works as it should. If you are going to beta-test this software please let me know. Also I am interested in any feedback on the software as well as the documentation. So don't be shy. Please send your feedback to morrison@accuvax.nwu.edu. I wanted to add support for a 56K synchronous board, but I have neither the hardware or the information needed to write the code. If anyone out there wants this capability badly enough to invest a small amount of hardware/money I could probably write it in about 1 month. Vance Morrison ----MESSAGE-END---- ----MESSAGE-BEGIN---- [91038.121146KOEHLER@awiwuw11.wu-wien.ac.at] <1991020805180400> From: KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi) Newsgroups: comp.protocols.tcp-ip Subject: Loooking for lpd for DOS w/packet drivers Message-ID: <91038.121146KOEHLER@awiwuw11.wu-wien.ac.at> Date: 8 Feb 91 05:18:04 GMT Organization: Wirtschaftsuniversitaet Wien, Vienna, Austria Lines: 10 Has anyone seen a public domain version of the UNIX lpd program as an implementation on a DOS PC which works together with packet drivers and/or PC/T CP from FTP Software ? Please send me a note. Many thanks in advance. Wolfgang Koehler (Koehler at AWIWUW11.BITNET) Computer Center University of Economics and Business Administration Vienna, Austria, Europe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102080825.AA12076@techops.cray.com] <1991020808250400> From: mni@techops.cray.com (Michael Nittmann) Newsgroups: comp.protocols.tcp-ip Subject: Re: Pros/Cons of TCP+Router vs. X.25 Message-ID: <9102080825.AA12076@techops.cray.com> Date: 8 Feb 91 08:25:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 you cannot say "public X.25 networks charge per packet": all of them are different in their charging structures. Most charge by packet, some add connection establishment charges, some have additional connection duration charges, some have distance dependent charges some all of the above, some have flat rates per month. PLEASE: if YOU YOURSELF did not enquiredo net disseminate incorect information! michael ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.083450.26039@Think.COM] <1991020808345000> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: How widespread is RFC931 on the internet? Message-ID: <1991Feb8.083450.26039@Think.COM> Date: 8 Feb 91 08:34:50 GMT References: <27b1bd10.20dc@uop.uop.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article <27b1bd10.20dc@uop.uop.edu> nsayer@uop.edu (Nick Sayer) writes: >We've just put in an RFC931 authd daemon on our system. >Some experimental connection attempts to other sites' >auth ports resulted in refused connections, which >leads me to believe that not many sites have authd >set up. Is this the case? Seems pretty likely. Authd may not be trivial to implement without modifying the TCP implementation. For instance, on BSD Unix it would have to grovel through the kernel's socket table, then search through all the process file tables looking for references to the socket; also, more than one process may have the same socket open, and the processes may be running under different userids, so it's not clear which userid should be returned. >I am considering hacking the in.telnetd at our site >so that it will insist on having authd set up at >sites telneting in, but if not many sites have an >auth daemon running, there's not much point. I think this idea is misguided. The RFC931 protocol is extremely insecure; if the remote host isn't secure, the returned information isn't very reliable. This is probably another reason why no one implements RFC931. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102082241.AA00744@ucbvax.Berkeley.EDU] <1991020809595300> From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: Re: When is a link saturated? Message-ID: <9102082241.AA00744@ucbvax.Berkeley.EDU> Date: 8 Feb 91 09:59:53 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 Up to recently, my opinion was that slower interfaces should have larger amount of buffers in their output queues (or that a minimum reserved number should be defined with a scheme for picking additional ones from a common pool using up unallocated memory). Now I read from Cisco's doc: "For slow links, use a small output queue hold limit.". The only reason I see is avoiding retransmissions making the congestion problem worse with duplicate packets. But I am not sure that, as soon as a buffer of a congested small output queue becomes free, the next datagram to fill it will not be retransmission anyway. What is true? Are routers able to use techniques to match retransmissions waiting in an output queue and discard the duplicate of a waiting datagram? 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---- [1991Feb8.105721.3753@unipalm.uucp] <1991020810572100> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: 32 bit ethernet adapters Message-ID: <1991Feb8.105721.3753@unipalm.uucp> Date: 8 Feb 91 10:57:21 GMT References: <29776@usc> Organization: Unipalm Ltd., Cambridge, England Lines: 24 rpinder@phad.hsc.usc.edu (Rich Pinder) writes: >I'm looking for a 32 bit, Micro-Channel, Ethernet adapter, that has >(working) drivers for SCO. >I'd appreciate any leads. (I know about Cogent - drivers lacking) >thanks > Rich Pinder > USC School of Medicine > (213) 342-1640 > rpinder@usc.edu > |||||||||||||||||||||||||||||||||||||||||||||||||| Try Trend Datalink (Torus Division) Unit 208 Cambridge Science Park Milton Road Cambridge United Kingdom +44 223 423131 for a blindingly fast MCA card: Definitely SCO Unix support. Good stuff. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.110317.3949@unipalm.uucp] <1991020811031700> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <1991Feb8.110317.3949@unipalm.uucp> Date: 8 Feb 91 11:03:17 GMT References: <38975@cup.portal.com> Organization: Unipalm Ltd., Cambridge, England Lines: 15 Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? >Thanks, >Will Estes (apple!cup.portal.com!Will) Do you mean secure as in - 'I know the guy got it', or secure as in 'if someone else got it they need 20 years on a Cray to decrypt it?' Surely encryption/decryption of data is not a tcp/ip issue? Or is it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.111625.23635@isavax.isa.com] <1991020811162500> From: cliffb@isavax.isa.com (cliff bedore*) Newsgroups: comp.protocols.tcp-ip Subject: Re: What is the voltage spec for thinnet? Message-ID: <1991Feb8.111625.23635@isavax.isa.com> Date: 8 Feb 91 11:16:25 GMT References: <1991Jan30.155606.21529@dartvax.dartmouth.edu> <1991Feb5.131333.2047@isavax.isa.com> <1991Feb6.033424.21632@usenet.ins.cwru.edu> Reply-To: cliffb@isavax.isa.com (cliff bedore*) Distribution: usa Organization: ISA Inc. Arlington, VA Lines: 87 In article <1991Feb6.033424.21632@usenet.ins.cwru.edu> jb@falstaff.mae.cwru.edu (Jim Berilla) writes: >In article <1991Feb5.131333.2047@isavax.isa.com> cliffb@isavax.isa.com (cliff bedore*) writes: >>In article <1991Jan30.155606.21529@dartvax.dartmouth.edu> wbc@moose.dartmouth.edu (Wayne B. Cripps) writes: >>> >>> >>>What should the voltage be on thinnet? - I get readings of >>>-1.8 to -2.0 volts and .2 to .3 volts - is this in the >>>range? is 1.2 volts ok? >>> >>> Wayne >> >>At the risk of stepping into something soft and gooey, I thought I'd put on >>my engineers hat for a while and comment on this. >> >>First. It will be very traffic dependent (assuming you're using a voltmeter >>that does some averaging). > >True. Don't use a voltmeter, use an oscilloscope. You'll see many interesting >things. > >>Having stated that and not knowing the details of an ethernet board, but >>knowing something about transmission lines, we can get a wag of ranges for >>the voltages. > >Not true. The voltages on the ethernet are clearly defined. I didn't say they weren't clearly defined. I said we could get a range of what was reasonable. We engineers call this a worst case analysis. > >>The lines are 50 ohms and are terminated in 1/4 or 1/2 watt resistors. (Mine >>is cause I did it myself and haven't had problems). >> >>Power (watts) = voltage ^2 / resistance or >> >>voltage = sqrt( power * resistance) >> >>voltage = sqrt ( 1/4) * 50 ) or 3.5 volts. for 1/4 watt power >> >>voltage = sqrt ( 1/2 * 50 ) or 5 volts for 1/2 watt power > >What *are* you talking about? (And take off that silly hat.) >In the case of ethernet, the voltage depends on the amount of current >pulled out of the tap. It's independant of the power rating of the >terminating resistors. Remember that the tap appears as a 25 ohm load, >i.e. it's connected to two 50 ohm transmission lines. > What I am talking about is how much voltage you can put through a 1/4 watt 50 ohm resistor without exceeding its power limits. Not circuit impedance! The above analysis is true. If you put 2 50 ohm 1/4 watt resistors in parallel,you get a 25 ohm 1/2 watt resistor. This reduces the resistance but keeps the power dissipation the same so the maximum voltage will be the same. (Ohms Law; He was a hero to us engineers) The 2nd calculation was assuming the specs call for 1/2 watt terminators. The idea of this was to get an idea of what would be the max voltage you should see on an ethernet line using a voltmeter. Given that the above calculations do that, I'll keep my hat on; thank you very much. The point is sometimes circuits don't pull current, they get pushed voltage. If the voltage-current combination (power) exceeds the rating of the resistor, it will burn up. If you think this isn't important get a 50 ohm resistor (47) from Radio Shack and plug it into your 110 outlet (but wear eye protection and gloves). Or run 15-20 volts down your thinnet and be prepared to look for a new job >For the AM7996 transceiver (common in a lot of Sun's), the voltages are >specified as follows: High level is between 0 and -.1 volts, low level >is between -1.625 and -2.2 volts. As stated above, this voltage is >generated by a current sink (to -9V) by the chip. An ideal current sink >has infinite impedance, and doesn't load the transmission line. If two >or more stations transmit at the same time, the voltage on the line goes >below -2.2 volts. The chip detects collisions on this basis. Had you been as quick to answer the original question as you were to critcize my answer, we could have saved a lot of bandwidth on the net. I waited 4 days to see if someone would post an answer. Since no one did, I gave the above estimate of what would be reasonable. . . > Jim Berilla / jb@falstaff.cwru.edu / 216-368-6776 >"My opinions are my own, except on Wednesday mornings at 9 AM, > when my opinions are those of my boss." In spite of my above comments, I do appreciate knowing what the true voltages are for ethernet. I've filed them away for the next time the question comes up. Cliff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.113404.4173@unipalm.uucp] <1991020811340400> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: copy protection Message-ID: <1991Feb8.113404.4173@unipalm.uucp> Date: 8 Feb 91 11:34:04 GMT References: <9101272223.AA08327@desktalk.com> <6207@rsiatl.Dixie.Com> <14127@scorn.sco.COM> <90696@lll-winken.LLNL.GOV> Organization: Unipalm Ltd., Cambridge, England Lines: 61 As a director of a company taht makes its entire revenue from reselling (mainly TCP/IP) software, I think I have some valid input:- 1/. If it were just the odd copy, at the odd educational site - no problem. 2/. The worst offenders are large corporates and small dealers. 3/. I have been on a site where 100 users were running software supplied by us on a 20 copy licence basis - we were unable to 'prove' this legally - since by the time we contacted the user 'officially' he declared that the 'software was faulty and had been thrown out'. Sideways contact into the company indicated that this was not the case.... 4/. Software Piracy cost the end user. Particularly the small end user. If every copy of Wordstar in use was paid for, I reckon they could knock it out at about $50 per copy. 5/. I LIKE the way SUN chose to copy protect PC-NFS - you can copy as many times as you like - you just can't get two copies up on the same LAN simultaneously. 6/. I have come late into this discussion (news only just up inhouse) but if SCO are using the same mechanism - good luck. 7/. I am also definittely in favour of the scheme that a company called Phase II in boston use - to limit either( customers choice) total number of logins allowed OR concurrent users. This seems a very fair way. SOMEONE has to pay for the man years invested in software: Network policing sreems a very good way of ensuring that people only use what they have contracted to use, and that inadvertent over use of a product results in clear signalling of that fact. I would welcome any solution that ensures that :- (a) Thew customer is not penalised by any copy prootection scheme in any way. (b) Unless he knowingly or unknowingly exceeds the USE TO WHICH HE HAS CONTRACTED WITH THE VENDOR. That is the crux: If a copy protection makes the product (effectively and/or practically) unuseable, then people will not buy it. Conversely if it is widely copied, the only way the vendor and manufacturer can control it is by constantly bringing out new releases/bug fixes, then you will get maybe a lot of buggy code released, so that at least you have to quote your serial number before they will support you! Not a good idea:-) What I as a vendor like to see is time bombed evaluation code - You can give it away, knowing that it won't last - and copy protected software that will restrict multiple copies on a single network to the licenced maximum. That is until we get a government grant to sell and support software :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.113838.4253@unipalm.uucp] <1991020811383800> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: LM/X Message-ID: <1991Feb8.113838.4253@unipalm.uucp> Date: 8 Feb 91 11:38:38 GMT References: Organization: Unipalm Ltd., Cambridge, England Lines: 12 martino@logitek.co.uk (Martin O'Nions) writes: >We don't use the packet drivers regularly with LM, largely because we have >the 3+ Open TCP software kicking around everywhere, but we did run PC/TCP >with LM for test purposes. There is a Packet Driver to NDIS TSR which feeds >the packet driver requests into the NDIS stack, and feeds the response >back up the chain. We had problems with early versions of this when doing >repeated loads/unloads of the driver, (it crashed the machine) but I believe >that this has been addressed (comments anybody?) It has Martin - long time no hear? Perhaps that 3COM TCP/IP is the reason! leo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.114916.4428@unipalm.uucp] <1991020811491600> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: SVR4 and FTP's software Message-ID: <1991Feb8.114916.4428@unipalm.uucp> Date: 8 Feb 91 11:49:16 GMT References: <1991Feb1.215832.21340@mccc.edu> Organization: Unipalm Ltd., Cambridge, England Lines: 21 pjh@mccc.edu (Pete Holsberg) writes: >It was suggested to me the other day that the POP servers available in >the P.D. and the POP[23] mail software that FTP supplies with PC-TCP >Plus may not work under the TCP/IP support provided with UNIX System V >Release 4.x. Could an experienced person please try to shed some light >on this? >Thanks, >Pete >-- >Prof. Peter J. Holsberg Mercer County Community College >Voice: 609-586-4800 Engineering Technology, Computers and Math >UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 >Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91 I have ported a POP2 server starting from P.D. code to INTEL system V.4 it is not too bad a port: there are still a few minor problems associated with the mail system rather than the POP daemon itself. It is a LOT easier to port BSD/ULtrix code to V.4 thatn it is to V.3 tho. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1000@tuura.UUCP] <1991020812273200> From: jel@tuura.UUCP (Jerry Lahti) Newsgroups: comp.protocols.tcp-ip Subject: Re: SCO <-> Sun == molasses Message-ID: <1000@tuura.UUCP> Date: 8 Feb 91 12:27:32 GMT References: Organization: Nokia Data Systems Oy Lines: 28 jsparkes@bwdls49.bnr.ca (Jeff Sparkes) writes: > I've set up a PC running SCO Unix 3.2.1. It mostly runs fine, but >FTP and NFS traffic between it and a SparcStation 1+ running SunOS 4.1.1 is >um, pathetic. FTP transfers of 0.5 K/s. NFS reads that (almost) never >complete. > I suspect the window size negotiation breaks down, since telnet >works fine. Anybody know any workarounds/bugfixes? >-- I have had similar problems and there is a workaround. In my case the problem was that the default SCO TCP window and NFS request size are 4 KB. Unfortunately when the SparcStation behaves accordingly and pumps out three or four Ethernet frames in rapid succession the poor PC Ethernet adapter can not keep up and drops all but the first frame. The workaround with TCP is to give the -onepacket flag to ifconfig (see manual for details). With NFS you have to give mount options which make the read and write sizes small enough so that the request will fit into a single Ethernet frame. An alternative is buying a better Ethernet adapter. I saw the problem with Etherlink II but the Western Digital cards do quite a bit better. At least our 486 machine with WD8013EBT seems to keep up quite well with our SPARCserver 330 without any parameter tweaking. Jerry Lahti Nokia Data Systems Oy Domains: jel@xerver.data.nokia.fi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.134112.365@rock.concert.net] <1991020813411200> From: abc@rock.concert.net (Alan Clegg) Newsgroups: comp.protocols.tcp-ip Subject: slip-4.1-beta and sliplogin Message-ID: <1991Feb8.134112.365@rock.concert.net> Date: 8 Feb 91 13:41:12 GMT Organization: MCNC Center for Communications Lines: 16 I have recently installed the slip-4.1-beta code into the kernel of a SparcStation 1+, and am trying to get the sliplogin code from the slip-4.0 release working. There were a couple of places where I had to change SLIPIFNAME from slip to stream, but other than that, I see nothing too different (I did change the push of "slip" to "slipen" and added the push of "str_ip"). Now, when I use sliplogin, I get a kernel panic shortly thereafter from totally unrelated processes (BAD TRAP). If I use slip-attach (supplied in 4.1-beta), everything stays up. Has anyone successfully gotten sliplogin working under 4.1-beta? Thanks, -abc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102081410.AA05381@ftp.com] <1991020814101600> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC 1108 and IP Security options? Message-ID: <9102081410.AA05381@ftp.com> Date: 8 Feb 91 14:10:16 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 34 Since nobody's answered this, I'll try. Note that my information may be out of date... RFC 1122 section 3.2.1.8(a) refers to an RFC 1108, "Internet Protocol Security Options," by one B. Schofield, dated October 1989. RFC 1122 also specifically warns that RFCs 1038 and 791 are obsolete, though it cites 791 as the source of its MUSTs and MAYs. What this means is that nobody in the DoD wants the IP Security Option as defined in either RFC 791 (the same as in Mil Std 1777) or RFC 1038 (major changes from the original RFC 791). However, RFC 1038 is a *lot* closer to the mark. RFC 1108 was intended to replace 1038, with a bunch of constants changed for the Blacker people, and the 'right' exception handling procedure for both single-level hosts, multi-level hosts and routers. However, it seems to have fallen into some interdepartmental black hole since 1989 (I believe the person doing it got moved, and I don't think anyone inherited both the responsibility and the authority. What is the current authoritative reference in this area? I don't know of one. What we implement in our current production version of PC/TCP is a mid-89 draft of what was intended to become RFC 1108. Nobody in the DoD has complained about this, but that could simply indicate that noone is using our IPSO - I know they have PC/TCP... At the time I was in touch with people at Cray, but I don't know exactly what they implemented, and the only other mention of IPSO that I've seen recently was Wollongong (VMS and SysV). Their glossy only mentions RFC 1038 and I don't have a copy to play with. The matter has come up at at least one IETF I attended, but no answer was at hand. If you somehow become enlightened, let us know... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102081410.AA05383@ftp.com] <1991020814101800> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: When is a link saturated? Message-ID: <9102081410.AA05383@ftp.com> Date: 8 Feb 91 14:10:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 14 I have been trying to interest people in using the Precedence field where appropriate, as well as TOS. Note that current production PC/TCP allows the setting of the Precedence field on a per-PC basis (The API also allows it on a per-connection basis, but none of our applications set it). A separate configuration item allows the user to enable Precedence checking as defined in the Mil Std for TCP (1776?), so you can use it for either router traffic identification, or to let a general override the ranks, as it was originally designed to. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.162556.6584@jpusa1.chi.il.us] <1991020816255600> From: stu@jpusa1.chi.il.us (Stu Heiss) Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: why is 386 tcp limmited to one slip session? Keywords: 386,slip Message-ID: <1991Feb8.162556.6584@jpusa1.chi.il.us> Date: 8 Feb 91 16:25:56 GMT Reply-To: stu@jpusa1.UUCP (Stu Heiss,925,6326,none) Organization: JPUSA - Chicago, IL Lines: 5 Someone posted that most 386 tcp implementations are limmited to one slip. This is true for the Lachman port on Xenix that we use. Why is this and is there any way to support more than one slip? -- Stu Heiss - stu@jpusa1.chi.il.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- [C13C5DEE293FE00507@ROSEVC.Rose-Hulman.Edu] <1991020816500000> From: MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager") Newsgroups: comp.protocols.tcp-ip Subject: Certified SMTP mail Message-ID: Date: 8 Feb 91 16:50:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 We have recently installed a new NOVELL mail system called PMAIL. One of the features allows you to request a confirmation once the mail message is delivered. I think this is an EXCELLENT idea. I had previously thought of this before, so when I saw it I was happy. This is accomplished by putting a line in the headers that only PMAIL recognizes. Now to the point. What would other people think of making some sort of standard header line that other mailers can act on? It's not hard to understand, and is easy to implement. So, let's hear what you think. If people choose to reply to me, I will count the votes and summarize to the net and take appropriate action. Thank. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= jerrod t. carter, networking manager | my employer has no opinions rose-hulman institute of technology | MGRJTC@RoseVC.Rose-Hulman.Edu | "may all your faults be soft." MGRJTC@RHIT.BITNET | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [37165@netnews.upenn.edu] <1991020816521400> From: theall@rm105serve.sas.upenn.edu (George A. Theall) Newsgroups: comp.protocols.tcp-ip Subject: Re: Loooking for lpd for DOS w/packet drivers Summary: At least three implementations exist. Keywords: lpd, packet drivers, dos Message-ID: <37165@netnews.upenn.edu> Date: 8 Feb 91 16:52:14 GMT References: <91038.121146KOEHLER@awiwuw11.wu-wien.ac.at> Sender: news@netnews.upenn.edu Organization: University of Pennsylvania Lines: 24 In article <91038.121146KOEHLER@awiwuw11.wu-wien.ac.at> KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi) writes: >Has anyone seen a public domain version of the UNIX lpd program as an >implementation on a DOS PC which works together with packet drivers and/or PC/T >CP from FTP Software ? An implementation written by Dave Johnson (dave@cs.olemiss.edu) is available, I believe, in beta release. It works with the Clarkson packet driver collection but is *not* public domain. At present I don't have a machine name from where it can be obtained via FTP but if you contact me I'll dig around for it. There is also an lpd server available from ogre.cica.indiana.edu (129.79.22.178) as part of tn3270iu.zip in directory ~/pub. I have not examined this; it is probably not public domain either. Also, I hear FTP Software markets an LPD server for DOS. While you do say "public domain", consider the value of support which comes with commercial products. George --- theall@rm105serve.sas.upenn.edu Dept. of Economics theall@ssctemp.sas.upenn.edu Univ. of Pennsylvania gtheall@penndrls.upenn.edu Philadelphia, PA 19104 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.180500.11290@Solbourne.COM] <1991020818050000> From: imp@Solbourne.COM (Warner Losh) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <1991Feb8.180500.11290@Solbourne.COM> Date: 8 Feb 91 18:05:00 GMT References: <38975@cup.portal.com> <1991Feb8.110317.3949@unipalm.uucp> Organization: Solbourne Computer, Inc., Longmont, CO Lines: 35 Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? There are a couple of RFC's (1113, 1114, 1115) on something called "Privacy enhancment for Internet electronic mail", which is mail that has been encrypted. There are some provisions for authenticating the sending user, but they are "weak". While there is an account called "root" with all the privs that it has, there will be no way to have "totally secure, authenticated mail". After all, if I wanted to send mail from Joe Hothead to his boss calling him a jerk, then I could su, then su jhothed and flame away. And it could be done w/o a way to trace it back it me (after all, root can nuke accounting files). User authentication is a difficult problem to solve completely. Also, while there are sites on the Internet with older mailers (and can't be upgraded to the latest sendmail since they aren't running Unix), there will be a problem with mailer spoofing. Even with the latest sendmail, I could send mail to Joe's boss as Joe w/o any privs. Or, in other words, you can't trust your mail 100%, since it is relatively easy to forge. However, I encourage all reasonable steps that can be taken to authenticate a connection. There are many hueristics that can be used to detect clumsy forgeries. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5827@auspex.auspex.com] <1991020818411800> From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <5827@auspex.auspex.com> Date: 8 Feb 91 18:41:18 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> Organization: Auspex Systems, Santa Clara Lines: 6 >Basically, the only difference you should see between an Ethernet Internet >connection and a SLIP Internet connection is the speed and throughput. Well, I might not go *that* far. Ethernet has a checksum, and SLIP doesn't, so if you're, say, using UDP without checksums, Ethernet may be more reliable than SLIP.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.185044.22132@mp.cs.niu.edu] <1991020818504400> From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <1991Feb8.185044.22132@mp.cs.niu.edu> Date: 8 Feb 91 18:50:44 GMT References: <38975@cup.portal.com> <1991Feb8.110317.3949@unipalm.uucp> <1991Feb8.180500.11290@Solbourne.COM> Organization: Northern Illinois University Lines: 23 Posted: Fri Feb 8 12:50:44 1991 In article <1991Feb8.180500.11290@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes: >While there is an account called "root" with all the privs that it >has, there will be no way to have "totally secure, authenticated >mail". After all, if I wanted to send mail from Joe Hothead to his >boss calling him a jerk, then I could su, then su jhothed and flame >away. And it could be done w/o a way to trace it back it me (after >all, root can nuke accounting files). Forget about root. Sure root can violate privacy. But what does that matter when anybody with a terminal server can telnet to the SMTP port of any host, and start entering an SMTP mail transaction. In this case even the 'Received:' headers won't be of much help in narrowing down the source of the message. If you want 100 percent secure communication, talk face to face with the person intended. Actually, even that is not 100% foolproof, or else there would be little point in having agencies such as the CIA. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [658@bcstec.boeing.com] <1991020818584000> From: ced@bcstec.uucp (Charles Derykus) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: using DNS and YP/NIS together Message-ID: <658@bcstec.boeing.com> Date: 8 Feb 91 18:58:40 GMT Sender: ced@bcstec.boeing.com Followup-To: comp.protocols.tcp-ip Distribution: na Organization: Boeing Computer Services Lines: 17 I have a few questions regarding using DNS and NIS/YP concurrently: When must host names be fully qualified in files, (/etc/netgroup, /etc/exports, etc.) in order for the two to work together? I was informed that if any hosts were built into the YP maps, that the lookup would consult YP, not DNS, for those hosts. Are there any other dire consequences than this? Are there any other caveats to be heeded? Any help will be much appreciated. Charles DeRykus Internet: ced@bcstec.boeing.com Boeing Computer Services UUCP: ...!uunet!bcstec!ced Renton, WA. M/S 6R-37 (206) 234-9223 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.192749.1743@murdoch.acc.Virginia.EDU] <1991020819274900> From: randall@Virginia.EDU (Ran Atkinson) Newsgroups: comp.protocols.tcp-ip Subject: Re: have you compiled NCSA Telnet w/Turbo C? Keywords: Turbo C NCSA Telnet Message-ID: <1991Feb8.192749.1743@murdoch.acc.Virginia.EDU> Date: 8 Feb 91 19:27:49 GMT References: <1991Feb07.214707.16739@ecst.csuchico.edu> Sender: usenet@murdoch.acc.Virginia.EDU Reply-To: Ran Atkinson Followup-To: comp.protocols.tcp-ip Organization: Computer Networks Laboratory, University of Virginia Lines: 43 In article <1991Feb07.214707.16739@ecst.csuchico.edu>, madams@ecst.csuchico.edu (Michael E. Adams) writes: >I won't waste your time detailing the aggravation I >experienced sorting out the tel23src.zip rats nest of files >from NCSA. > >Still, I would love to hear from anyone who has successfully >compiled the Telnet programs with Turbo C. For several months late last spring and summer, I was working with the NCSA Telnet 2.3 Beta sources under TC/TC++. The folks at NCSA should have changed some of the sources by now based on my comments back then and a fairly recent 2.3 Beta shouldn't require too much effort to compile with TC. Back then, the main problems were that the sources were laden with non-ANSI header files that are unique to MS C. In many cases, the header should replace one or more MS C headers. Also, there were some incorrectly placed #defines that kept TC from seeing headers that it needed to see and caused it to see headers that it shouldn't see. I think that most of the actual C source will be fine, but the headers and #defines will take some tweaking. You might also want to turn off the "no prototype" warning since the order of declaration of the functions in some of the files causes them to be defined after all other references to them. I think that if/when the NCSA folks switch to a newer compiler than MS C 5.1, it will be easier for them to make NCSA more ANSI conforming and hence TC/TC++ compatible. (This might already have happened.) I'm not actively working on the NCSA sources at the moment due to other projects, but I think that all would benefit if problems with getting the NCSA Telnet sources to compile with mainstream (Borland, Watcom, Microsoft, Zortech, etc.) compilers were reported with suitable fixes. I've been impressed with the quality of response from the NCSA folks to technical problems and questions. I've posted rather than replied because I think that this might be of more general interest. Ran Atkinson randall@Virginia.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.203703.25654@zoo.toronto.edu] <1991020820370300> From: henry@zoo.toronto.edu (Henry Spencer) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb8.203703.25654@zoo.toronto.edu> Date: 8 Feb 91 20:37:03 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> <5827@auspex.auspex.com> Organization: U of Toronto Zoology Lines: 12 In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Well, I might not go *that* far. Ethernet has a checksum, and SLIP >doesn't, so if you're, say, using UDP without checksums, Ethernet may be >more reliable than SLIP.... Surely nobody would be so stupid as to use UDP without checksums. :-) :-) (For those who don't get the point of the ":-) :-)", NFS uses UDP without checksums. And people wonder why NFS is so unreliable...) -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.215141.25456@visix.com] <1991020821514100> From: amanda@visix.com (Amanda Walker) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb8.215141.25456@visix.com> Date: 8 Feb 91 21:51:41 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> <5827@auspex.auspex.com> Organization: Visix Software Inc., Reston, VA Lines: 18 In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Well, I might not go *that* far. Ethernet has a checksum, and SLIP >doesn't, so if you're, say, using UDP without checksums, Ethernet may be >more reliable than SLIP.... On the other hand, if you're running NFS (the only common use I know of for UDP without checksums) over SLIP, you may have worse problems :). Of course, I'm firmly in the end-to-end-reliability-check camp, and thus I think that running UDP without checksums is just a way of asking for trouble. I still fail to understand why it was done in NFS. Sigh. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- If you know what you're doing, how long it will take, or how much it will cost, it isn't research. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb8.223539.18629@Solbourne.COM] <1991020822353900> From: imp@Solbourne.COM (Warner Losh) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <1991Feb8.223539.18629@Solbourne.COM> Date: 8 Feb 91 22:35:39 GMT References: Organization: Solbourne Computer, Inc., Longmont, CO Lines: 23 In article MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager") writes: >This is accomplished by putting a line in the headers that only PMAIL >recognizes. Now to the point. What would other people think of making some sort >of standard header line that other mailers can act on? There is a header called Return-Receipt: that various sendmail versions seem to grok. Maybe that is the way to go.... Note that delivering the mail doesn't actually mean that the person will read the mail. Every month or two around here a couple of people loose mail because of a disk crash w/no backup since the incoming mail was sent. I don't know what PMAIL does, but unless return receipt is integrated into the mail reading program, it too would suffer from this problem. Also, I didn't think NOVELL used TCP/IP at all. Don't they use IPX? Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8963@hub.ucsb.edu] <1991020822501400> From: raj@pollux.geog.ucsb.edu (Richard A Johnson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Promiscuous Mode - RS/6000 Ethernet Adapter Message-ID: <8963@hub.ucsb.edu> Date: 8 Feb 91 22:50:14 GMT References: <9102041220.aa06705@delmarva.delmarva.COM> Sender: news@hub.ucsb.edu Reply-To: raj@pollux.geog.ucsb.edu () Organization: U. C. Santa Barbara, Geography Department Lines: 13 Posted: Fri Feb 8 14:50:14 1991 If you look at /usr/include/net/if.h on the RS/6000 you find a note that promiscuous mode doesn't work currently. I'm trying to find out from IBM if they will EVER get it. No answer yet. (Text from /usr/include/net/if.h:) /* next two not supported now, but reserved: */ #define IFF_PROMISC 0x100 /* receive all packets */ #define IFF_ALLMULTI 0x200 /* receive all multicast packets */ ----------------------------------------------------------------------------- Richard A. Johnson raj@topdog.ucsb.edu (Internet) NCGIA Computing Resources Manager ucbvax!ucivax!raj (UUCP) U. C. Santa Barbara raj@ncgia.ucsb.edu (via Nameservers) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [84702@sgi.sgi.com] <1991020823310100> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Summary: UPD cksums are used in modern NFS Message-ID: <84702@sgi.sgi.com> Date: 8 Feb 91 23:31:01 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> <1991Feb8.203703.25654@zoo.toronto.edu> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 27 In article <1991Feb8.203703.25654@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > > (For those who don't get the point of the ":-) :-)", NFS uses UDP without > checksums. And people wonder why NFS is so unreliable...) Everyone! Please stop repeating this complaint. It doesn't take much perception or knowledge to find many real and inconvenient differences between NFS and other UNIX file systems. If complaining about NFS brings you joy, then complain about open-unlink, caching, security, ownership & UID's, dates, and idempotency holes. If you don't like using NFS, then use something else like AFS or "the emerging standard, RFS" (AT&T press release, 1986). Anyone with an NFS implementation that does not use UDP checksums should either fix or enjoy it. The NFS on common and current workstations does use UDP checksums by default. Ours do. I'm told that Sun's does as of the NFS 3.2 source release. I personally think the choice made in 1984 (85?) was correct for 1982 thru 1988. The fact that for years (!) NFS has used UDP with checksums turned on makes our disagreement about the correctness of the original decision almost as interesting today as the old arguments whether "HLL's will replace assembly language". Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102082349.AA12165@braden.isi.edu] <1991020823494700> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC 1108 and IP Security options? Message-ID: <9102082349.AA12165@braden.isi.edu> Date: 8 Feb 91 23:49:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 The problem of RFC-1108 has been receiving a great deal of back-room attention recently, and people who should know keep telling me "next month". Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102082059.aa16414@NRI.NRI.Reston.VA.US] <1991020901594300> From: vcerf@NRI.RESTON.VA.US Newsgroups: comp.protocols.tcp-ip Subject: RFC1108/IP Security Option Status Message-ID: <9102082059.aa16414@NRI.NRI.Reston.VA.US> Date: 9 Feb 91 01:59:43 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 24 Folks, just to update you on this matter, there is urgent effort underway (since last November) to put the final touches on RFC1108. It did fall into a black hole for most of the last half of 1990 owing to various personnel shifting but has been resurrected and is being debated by key parties. With any luck we should have the final go around in late February and can report it out to IESG/IAB at that time. The focus of RFC1108 is quite US specific and there is strong need to consider a broader framework for document markings for the bulk of the Internet community. To that end, effort is under way to develop a "commercial" option which would tackle the non-military case (indications are that a sufficiently general formulation might work for military and non-military cases, but this remains to be seen). The topic will probably surface at the next IETF meeting, in any event, so stay tuned. Steve Crocker has the IETF action. Steve Kent has been working the RFC1108 problem with the assistance of an ad hoc group of government representatives whose needs RFC1108 has to satisfy. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102082128.aa16873@NRI.NRI.Reston.VA.US] <1991020902283100> From: vcerf@NRI.RESTON.VA.US Newsgroups: comp.protocols.tcp-ip Subject: SLIP for NeXT Message-ID: <9102082128.aa16873@NRI.NRI.Reston.VA.US> Date: 9 Feb 91 02:28:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Does NeXT have SLIP or PPP support? Please respond to vcerf@nri.reston.va.us to avoid bothering the list. thanks, Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8480.27b30f1d@jetson.uh.edu] <1991020902503600> From: cscc12@jetson.uh.edu Newsgroups: comp.protocols.tcp-ip Subject: Seek help on how to load PC NCSA & driver(s) to Ext. or Exp. Memory Message-ID: <8480.27b30f1d@jetson.uh.edu> Date: 9 Feb 91 02:50:36 GMT Organization: University of Houston Lines: 9 Hello everybody, Can any of you please show me how to load PC NCSA Telnet and its driver(s) into extended or expanded memory if this is possible. Thanks in advance. Loc Thanh Le cscc12@menudo.uh.edu cscc12@elroy.uh.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [PEIFFER.91Feb8222715@umn-cs.cs.umn.edu] <1991020904271500> From: peiffer@umn-cs.cs.umn.edu (Tim Peiffer (the net guy)) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: Date: 9 Feb 91 04:27:15 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> <5827@auspex.auspex.com> Sender: news@cs.umn.edu (News administrator) Reply-To: peiffer@cs.umn.edu Organization: computer science labs Lines: 35 In-Reply-To: guy@auspex.auspex.com's message of 8 Feb 91 18:41:18 GMT Nntp-Posting-Host: cs.umn.edu In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: Well, I might not go *that* far. Ethernet has a checksum, and SLIP doesn't, so if you're, say, using UDP without checksums, Ethernet may be more reliable than SLIP.... This sounds like you are willing to compare apples to oranges. IP differs not at all whether it originates on a coaxial Ethernet, or a slow speed serial line. UDP without checksums is only mentioning that you are willing to disallow checksums at the transport level. This option exists under both Ethernet and SLIP connections. The network level (IP) still has a checksum that resides at byte 12. I believe that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum will be accomplished at byte 5. RFC1055 refers one back to the IP document for the content of the IP header. Tim Peiffer ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota MPLS MN 55455 ** Internet Protocol A summary of the contents of the internet header follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb9.042842.20027@athena.mit.edu] <1991020904284200> From: dyim@athena.mit.edu (Derrick H. Yim) Newsgroups: comp.protocols.tcp-ip Subject: Socket Library for MacTCP Message-ID: <1991Feb9.042842.20027@athena.mit.edu> Date: 9 Feb 91 04:28:42 GMT Sender: news@athena.mit.edu (News system) Reply-To: dyim@athena.mit.edu (Derrick H. Yim) Organization: Massachusetts Institute of Technology Lines: 12 I am looking for a UNIX Socket library for the Macintosh implemented using MacTCP. I would like to write a program which would allow me to exchange data between a Macintosh and a UNIX box using stream sockets. I'm working in MPW C, so libraries written for MPW would be preferred. Can anyone help me out? Please send e-mail, since I'm not a regular netnews reader. Derrick Yim dyim@athena.mit.edu dyim@media-lab.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb9.051623.29415@Think.COM] <1991020905162300> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb9.051623.29415@Think.COM> Date: 9 Feb 91 05:16:23 GMT References: <4320@ns-mx.uiowa.edu> <1991Feb8.203703.25654@zoo.toronto.edu> <84702@sgi.sgi.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 34 In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> (For those who don't get the point of the ":-) :-)", NFS uses UDP without >> checksums. And people wonder why NFS is so unreliable...) >Everyone! Please stop repeating this complaint. I agree that the complaint is wrong, but not for the same reason you do. It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in general (in its default configuration). In fact, SunOS doesn't provide a way for a UDP-based application protocol to control whether it uses checksums -- it's a single, system-wide parameter. Even worse, this one parameter controls both whether checksums are generated during sending and whether they are checked when receiving. >Anyone with an NFS implementation that does not use UDP checksums should >either fix or enjoy it. The NFS on common and current workstations does >use UDP checksums by default. I think Suns would count as "common and current workstations", and by default SunOS doesn't enable UDP checksums. In fact, until SunOS 4.1.1, enabling UDP checksums required patching the kernel; in the latest release they've finally moved it into a configuration file used during the kernel build process. > Ours do. I'm told that Sun's does as >of the NFS 3.2 source release. Since the socket library doesn't provide a way to enable or disable UDP checksums (I could be wrong -- I simply searched for "checksum" in the setsockopt man page), I don't see how the NFS source release can do this. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb09.143548.11116@jadpc.cts.com] <1991020914354800> From: jdeitch@jadpc.cts.com (Jim Deitch) Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: Re: why is 386 tcp limmited to one slip session? Keywords: 386,slip Message-ID: <1991Feb09.143548.11116@jadpc.cts.com> Date: 9 Feb 91 14:35:48 GMT References: <1991Feb8.162556.6584@jpusa1.chi.il.us> Organization: Network Engineering Technologies, San Diego, CA. Lines: 17 Posted: Sat Feb 9 08:35:48 1991 In article <1991Feb8.162556.6584@jpusa1.chi.il.us> stu@jpusa1.UUCP (Stu Heiss,925,6326,none) writes: >Someone posted that most 386 tcp implementations are limmited to >one slip. This is true for the Lachman port on Xenix that we use. >Why is this and is there any way to support more than one slip? >-- >Stu Heiss - stu@jpusa1.chi.il.us You know what is really interesting, I just got done doing some work on a Altos 1000, it is a 386 box that is using a modified SCO Unix, running Lachman tcp. They can support more than 1 concurrent slip. I wonder if the altos tcp can be laid down into sco unix and work? Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb9.190400.6078@Think.COM] <1991020919040000> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Keywords: ftp tcp Message-ID: <1991Feb9.190400.6078@Think.COM> Date: 9 Feb 91 19:04:00 GMT References: <1991Feb6.184300@sicsun.epfl.ch> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 30 In article <1991Feb6.184300@sicsun.epfl.ch> goud@sicsun.epfl.ch (Mireille Goud) writes: > - If the 2 hosts are on the same network (same B class >address) the size of the packets is negociated between the 2 hosts. > - If the 2 hosts are not on the same network (they don't have >the same class address) the size of the packets is 512 bytes. >1. Is this a ftp problem or a tcp problem ? It's a problem/feature of many TCP implementations. The reason it is done is that the goal is to prevent fragmentation of datagrams. Hosts on the same network can agree to base the max segment size (MSS) on the maximum packet size (called the MTU -- Max Transmission Unit) of the network. If they are on different networks, though, they don't know what the smallest MTU is of all the intervening networks, except that all networks in a TCP/IP internet are required to support at least 512-byte packets (actually, I think the number is something like 568, to allow 512-byte TCP segments plus IP and TCP headers). >2. Is there a solution to have big packets (4K bytes on fddi) even if >the 2 hosts are not on the same network ? There is work going on to develop "path MTU discovery" mechanisms. Also, some TCP implementations use a larger MSS for subnet that are part of the same subnetted network than for outside networks (on the assumption that local area media are faster than wide area media, so the consequences of greater retransmission due to loss of a fragment are less severe). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb9.195258.26117@DMI.USherb.CA] <1991020919525800> From: protocom@terre (protocom-Laurent turcotte) Newsgroups: comp.protocols.tcp-ip Subject: SLIP (Performance/reliablity) Message-ID: <1991Feb9.195258.26117@DMI.USherb.CA> Date: 9 Feb 91 19:52:58 GMT Sender: usenet@DMI.USherb.CA (Pour Courrier usenet) Organization: Universite de Sherbrooke, Quebec Lines: 22 Nntp-Posting-Host: terre I'm considering using (SLIP) via FTP to transfer files from a Macintosh to Sun Sparc station. I know 4.3BSD unix implements SLIP. I would be using TCP/Connect II 1.0 from Intercon Systems Corporation on the Macintosh side. The Sun would call the Macintosh via modem (SLIP) and establish an FTP session. (1) is SLIP reliable enough over noisy modem lines? (I know that the TCP and IP layers contains checksum block validations) or should I use something like ZMODEM or KERMIT. (2) is the question of speed which would be faster (SLIP/FTP, XMODEM or KERMIT) (3) which is the most flexible? I think SLIP since you can almost do anything with IP but send me your opinions. Thanks (any feedback can help...) Larry Turcotte -- Larry Turcotte Internet:protocom@dmi.usherb.ca computer science student/consultant consulting company:Protocom Is there anybody out there..... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102092011.AA00805@gibbs.sfsu.edu] <1991020920110200> From: jliv@GIBBS.SFSU.EDU (John Loiacono) Newsgroups: comp.protocols.tcp-ip Subject: HP's TCP/IP under MPE Message-ID: <9102092011.AA00805@gibbs.sfsu.edu> Date: 9 Feb 91 20:11:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 22 Posted: Sat Feb 9 14:11:02 1991 I would like to hear from those of you who have set up MPE hosts to interact with other MPE hosts and/or PCs running HP's virtual terminal software, accross TCP/IP routers. I have been told that this is difficult or impossible, at best. I hope to dispute this comment, and solve some problems. Things to keep in mind... 1. I am not experienced with MPE. 2. I am experienced with TCP/IP, but not HP's under MPE. 3. The routers support HP-Probe, and ARP. 4. Hosts are HP 3000s and PCs are mixed variety. 5. PCs talk with local hosts just fine. 6. Remote hosts are accross 56Kb links. 7. All local traffic is on Ethernet. Please respond directly to me at jliv@gibbs.sfsu.edu, and I will summarize upon request. jliv ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102092334.AA17529@osiris.MIT.EDU] <1991020923341100> From: jis@MIT.EDU (Jeffrey I. Schiller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <9102092334.AA17529@osiris.MIT.EDU> Date: 9 Feb 91 23:34:11 GMT References: <1991Feb8.180500.11290@Solbourne.COM> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 86 Date: 8 Feb 91 18:05:00 GMT From: stan!imp@uunet.uu.net (Warner Losh) Organization: Solbourne Computer, Inc., Longmont, CO References: <38975@cup.portal.com>, <1991Feb8.110317.3949@unipalm.uucp> Sender: tcp-ip-relay@nic.ddn.mil Will@cup.portal.com (Will E Estes) writes: >Can someone briefly discuss any standards that might exist, or be >in the process of development, for the sending of secure mail via >SMTP or via the Internet. Also, are there any relevant RFCs on >this topic? There are a couple of RFC's (1113, 1114, 1115) on something called "Privacy enhancment for Internet electronic mail", which is mail that has been encrypted. There are some provisions for authenticating the sending user, but they are "weak". Actually the provisions for authenticating the sending user are quite strong. Each sender must have a "Certificate" to send privacy enhanced mail. A Certificate is a signed (via public key technology) piece of information that binds the senders name (as an X.500 distinguished name, separate from any concept of "login" name) and their public key. There will be at least three ways of obtaining a Certificate. The direct (and most expensive) way will be to get one issued directly from RSADSI (the company that is managing the authentication hierarchy) for $25.00. This method will also require that you submit a notarized statement of your identity (ie. a Notary Public will have to notarize a piece of paper that you send to RSADSI, testifying that the notary was shown sufficient evidence that you are who you claim to be). The cheaper mechanism (and more efficient one because no paperwork is required) will involve someone in your company acting as an "Organizational Notary" (ON). ONs will vouch for people in the company. However ONs will be under contract to only issue Certificates legitimately. While there is an account called "root" with all the privs that it has, there will be no way to have "totally secure, authenticated mail". After all, if I wanted to send mail from Joe Hothead to his boss calling him a jerk, then I could su, then su jhothed and flame away. And it could be done w/o a way to trace it back it me (after all, root can nuke accounting files). Not quite as easy as that. To send mail as me, will require knowledge of my private encryption key (the "secret" key that corresponds to the public key embedded in my Certificate). In my implementation of Privacy Enhanced Mail, the secret key is stored not only in a file readable only to me, but is also encrypted by a password that only I know. "root" (or others) can still steal my private key, however to do so will require either stealing my keyboard input when I am sending private mail, or otherwise installing a trojan horse in the Privacy Enhanced Mail software to steal my key. Although both of these steps are doable by one who has sufficient privileges and/or skill, it is a *lot* harder then merely "su" and then "su jhothed". User authentication is a difficult problem to solve completely. Also, while there are sites on the Internet with older mailers (and can't be upgraded to the latest sendmail since they aren't running Unix), there will be a problem with mailer spoofing. Even with the latest sendmail, I could send mail to Joe's boss as Joe w/o any privs. Privacy Enhanced Mail is not a function of the mail transport system, it is a step you take prior to sending mail or after having received the mail. My implementation is in fact done as an editing step. First you format your message in an editor, then you transform it to the "enhanced" form and only then do you mail the message. In fact I have a version which is implemented as a UNIX filter. You can pipe the unenhanced message in, and get the enhanced message out. Or, in other words, you can't trust your mail 100%, since it is relatively easy to forge. The goal of privacy enhanced mail is to allow you to trust your mail closer to 100% then to 0%. The whole point is to make it hard to forge. However, I encourage all reasonable steps that can be taken to authenticate a connection. There are many hueristics that can be used to detect clumsy forgeries. The problem with using heuristics is that they often will flag a legitimate message as a forgery! My strategy is to not trust any information provided by the IP layer, as all of it can be forged. The mechanisms in Privacy Enhanced Mail are designed to be trusted, and were designed by people who know their business. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4234@eastapps.East.Sun.COM] <1991021000135100> From: brian@ganglion.Canada.Sun.Com (Brian Onn) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <4234@eastapps.East.Sun.COM> Date: 10 Feb 91 00:13:51 GMT References: <1991Feb6.172144.12605@nmt.edu> <4320@ns-mx.uiowa.edu> Sender: news@East.Sun.COM Reply-To: Brian.Onn@Canada.Sun.Com Organization: Sun Microsystems of Canada Inc. Lines: 40 Tim Peiffer (the net guy) writes: |> In article <5827@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: |> Well, I might not go *that* far. Ethernet has a checksum, and SLIP |> doesn't, so if you're, say, using UDP without checksums, Ethernet may be |> more reliable than SLIP.... |> |> This sounds like you are willing to compare apples to oranges. IP |> differs not at all whether it originates on a coaxial Ethernet, or a |> slow speed serial line. UDP without checksums is only mentioning that |> you are willing to disallow checksums at the transport level. This |> option exists under both Ethernet and SLIP connections. The network |> level (IP) still has a checksum that resides at byte 12. I believe |> that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum |> will be accomplished at byte 5. RFC1055 refers one back to the |> IP document for the content of the IP header. *sigh* . The net guy should read the RFC he mentions. The IP checksum is only for the IP header, and does not include the *data*. IP relies on the upper layer protocols (UDP, TCP) to provide checksumming of the data. What Guy is saying is that running UDP without checksums is more reliable on an Ethernet due to the fact that the Ethernet frame includes a checksum (CRC, actually) for all of the frame. A SLIP frame does not include a frame checksum, and this will allow bad data to be passed up the protocol stack. If the SLIP layer doesn't catch bad data (ie, a bad SLIP frame), and the IP layer also doesn't checksum the data, and higher up the UDP layer doesn't checksum the data, you've just received bad data. Brian. -- _____________________________________________________________________ Brian Onn. Inet : Brian.Onn@Canada.Sun.Com Sun Microsystems of Canada. Uucp : uunet!sun!suncan!brian Product Support Specialist. Voice : (416) 477-6745. --------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102101415.AA27088@ucbvax.Berkeley.EDU] <1991021014155300> From: HANK@VM.BIU.AC.IL (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: SNMP comparison Message-ID: <9102101415.AA27088@ucbvax.Berkeley.EDU> Date: 10 Feb 91 14:15:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 X-Unparsable-Date: Sun, 10 Feb 91 15:01:30 IST I am in need of a product comparison between various SNMP management products. I am aware of the following products: Product name Company Name ------------ ------------ ACS4800 NMS ACC Dual Manager Netlabs Netmon III SNMP Research LAN Systems 9100 NMC Hughes LANCE/NMS Micro Technology OverVIEW Proteon NCC Unisys NetCentral cisco SNMP Tools FTP Software SNMP Nysernet SunNet Manager Sun Watchtower Intercon Systems WIN/MGT Wollongong XNETMON III SNMP Research I have heard that Datapro has recently conducted a comparison - does anyone know where I can buy that study? Any other comparisons available? My personal checklist includes the following points (leaving off the more common ones): - able to run on a b/w X-terminal - able to connect via 5-6 X-windows sessions to the SNMP management system so that more than one person can manage the network - able to click on a network icon and telnet over immediately to that box - able to generate statistical reports based on IP port divisions These requirements are in addition to the standard SNMP features one would expect from an SNMP package. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [16381:Feb1015:07:5791@kramden.acf.nyu.edu] <1991021015075700> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip,comp.mail.uucp Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <16381:Feb1015:07:5791@kramden.acf.nyu.edu> Date: 10 Feb 91 15:07:57 GMT References: <1991Feb8.110317.3949@unipalm.uucp> <1991Feb8.180500.11290@Solbourne.COM> <1991Feb8.185044.22132@mp.cs.niu.edu> Organization: IR Lines: 20 Apologies for the advertisement, but it seems appropriate to point out that I just posted a public-domain RFC 931 implementation under BSD to alt.sources, along with patches to sendmail (5.65, 5.61, et al.) that let you use $F in sendmail.cf for the remote user as per RFC 931. I recommend that you add ``, auth $F'' to one of the Received: lines, preferably the second, as a semi-standard format. Sure, RFC 931 isn't a panacea. But it does turn mail into a secure protocol, provided that TCP is made secure. Any university sysadmin knows that 99% of all sendmail forgers don't have any resources other than a telnet connection. Now we can close that hole for good. authd 3.01 has been reported to work under SunOS 4.0 on a Sun 2/170, SunOS 4.0.3 on a Sun 4/280, SunOS 4.1 on Sun 3/80, 3/160, 3/180, 4/60, and 4/330, Ultrix 4.0 on a DECsystem-5820, Ultrix 4.1 on DECsystem-5820, DECstation-5400, and VAX 8650, BSD 4.3 on some VAX, and Convex UNIX 8.0 on a Convex C210. It does peek in a few kernel data structures, but it seems perfectly portable so far. ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb10.1070.3165@canrem.uucp] <1991021020024900> From: john.lorenc@canrem.uucp (john lorenc) Newsgroups: comp.protocols.tcp-ip Subject: copy protection Message-ID: <1991Feb10.1070.3165@canrem.uucp> Date: 10 Feb 91 20:02:49 GMT Reply-To: "john lorenc" Organization: Canada Remote Systems Lines: 19 To: ericd@sco.COM ED>Some of the information, regarding TCP/IP from SCO, in this post is incorrect. ED>I do not want to use network bandwidth to explain the issues, however I ED>would be more than willing to Email concerned individuals directly about the ED>the copy protection scheme and how it affects system adminstration and users. I am cursious to see your explanation. I do find it a nuisance to use those "activation keys" john.lorenc@canrem.uucp John Lorenc --- ~ DeLuxe}ab #1061 ~ Live Long and Prosper.. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102102022.AA26112@osiris.MIT.EDU] <1991021020224200> From: jis@MIT.EDU (Jeffrey I. Schiller) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <9102102022.AA26112@osiris.MIT.EDU> Date: 10 Feb 91 20:22:42 GMT References: <16381:Feb1015:07:5791@kramden.acf.nyu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 Date: 10 Feb 91 15:07:57 GMT From: kramden.acf.nyu.edu!brnstnd@nyu.edu (Dan Bernstein) Organization: IR References: <1991Feb8.110317.3949@unipalm.uucp>, <1991Feb8.180500.11290@Solbourne.COM>, <1991Feb8.185044.22132@mp.cs.niu.edu> Sender: tcp-ip-relay@nic.ddn.mil ... Sure, RFC 931 isn't a panacea. But it does turn mail into a secure protocol, provided that TCP is made secure. Any university sysadmin knows that 99% of all sendmail forgers don't have any resources other than a telnet connection. Now we can close that hole for good. I wouldn't go so far as to say it makes mail a "secure" protocol. Though it does help. However for it to be really useful, all the mail relays between sender and receiver need to implement it. This is not only unlikely, but is also beyond the control of the individual sender and receiver. Furthermore even if all the hosts on the Internet adopted it tomorrow, you still need to trust the administrations of all the way points your mail is relayed through. This doesn't lend itself well to anything but the weakest definition of the term "authentication." The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself here!) define an end-to-end mechanism exactly so that sender and recipient need have no trust in the intermediate mail relays (and no requirements on the software that they run). This permits me for example to route an encrypted, signed mail message to you via Iraq and the Soviet Union and when you receive it (if you receive it, but that is a different problem :-) ) know that only you can decrypt its contents and also know that only I could have originated the message. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb10.205047.2217@oilean.uucp] <1991021020504700> From: joe@oilean.uucp (Joe McGuckin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <1991Feb10.205047.2217@oilean.uucp> Date: 10 Feb 91 20:50:47 GMT References: Organization: Island Software Lines: 9 I think it's a great idea. But why stop there? Why not have an additional confirmation that informs you when the message was actually read... -- Joe McGuckin oilean!joe@sgi.com Island Software joe@parcplace.com (415) 969-5453 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5847@auspex.auspex.com] <1991021100322000> From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <5847@auspex.auspex.com> Date: 11 Feb 91 00:32:20 GMT References: <1991Feb8.203703.25654@zoo.toronto.edu> <84702@sgi.sgi.com> <1991Feb9.051623.29415@Think.COM> Organization: Auspex Systems, Santa Clara Lines: 30 >It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in >general (in its default configuration). In fact, SunOS doesn't provide a >way for a UDP-based application protocol to control whether it uses >checksums -- it's a single, system-wide parameter. Even worse, this one >parameter controls both whether checksums are generated during sending and >whether they are checked when receiving. The latter two statements are true of BSD, as it comes from Berkeley, from 4.3BSD to 4.3-reno. Whether UDP checksumming is enabled or not in BSD as it comes from Berkeley is, by default, under the control of the COMPAT_42 #define; that doesn't seem to be on in most of the configuration files, so I don't think the first statement is true of BSD, although it is true of SunOS (SunOS != BSD). >> Ours do. I'm told that Sun's does as >>of the NFS 3.2 source release. > >Since the socket library doesn't provide a way to enable or disable UDP >checksums (I could be wrong -- I simply searched for "checksum" in the >setsockopt man page), I don't see how the NFS source release can do this. It can if the default configuration of the NFS source release turns the system-wide parameter on; he didn't say the NFS 3.2 source release lets you arbitrary control whether UDP checksumming is done, he just said that he was told that it *DID* UDP checksumming as of the NFS 3.2 source release. The NFS 4.0 source release is derived from 4.3BSD, and behaves like 4.3BSD in this regard - "udpcksum" is turned on only if COMPAT_42 is defined, and it's not defined in the GENERIC configuration file. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5848@auspex.auspex.com] <1991021100420200> From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <5848@auspex.auspex.com> Date: 11 Feb 91 00:42:02 GMT References: <4320@ns-mx.uiowa.edu> <5827@auspex.auspex.com> Organization: Auspex Systems, Santa Clara Lines: 39 >This sounds like you are willing to compare apples to oranges. IP >differs not at all whether it originates on a coaxial Ethernet, or a >slow speed serial line. Yes, I know IP doesn't differ, but how reliably the link level checks the link-level packets in which IP packets are wrapped *DOES* differ - Ethernet has a checksum, and SLIP doesn't, as I said. >UDP without checksums is only mentioning that you are willing to disallow >checksums at the transport level. This option exists under both Ethernet >and SLIP connections. If you disable UDP checksumming, the transmission of your UDP datagrams will be checked by checksum when the transmission goes over Ethernet, but not when it goes over SLIP, so if the transmission includes a SLIP connection, that connection won't have any checksumming other than the IP checksum you mention, which does *NOT* checksum the entire packet, just the IP header. If the transmission includes only Ethernet connections, it will be checksummed on each one of those hops. (It won't necessarily be checksummed as it's moved internally to any of the intermediate machines, of course....) >The network level (IP) still has a checksum that resides at byte 12. Which only checksums IP headers; it doesn't check the entire datagram. >I believe that V. Jacobsen (RFC 1144) states that the COMPRESSED_IP checksum >will be accomplished at byte 5. He also states that: This compression is specific to TCP/IP datagrams./2/ The author investigated compressing UDP/IP datagrams but found that they were too infrequent to be worth the bother and either there was insufficient datagram-to-datagram coherence for good compression (e.g., name server queries) or the higher level protocol headers overwhelmed the cost of the UDP/IP header (e.g., Sun's RPC/NFS). so it's irrelevant to the discussion of UDP anyway. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [36540021@hpindwa.cup.hp.com] <1991021102333500> From: raj@hpindwa.cup.hp.com (Rick Jones) Newsgroups: comp.protocols.tcp-ip Subject: Why Fewer Buffers (was Changing TCP port) Message-ID: <36540021@hpindwa.cup.hp.com> Date: 11 Feb 91 02:33:35 GMT Organization: Hewlett-Packard, Cupertino CA Lines: 40 Posted: Sun Feb 10 20:33:35 1991 >In a different string, it was asked why cisco might suggest using >fewer buffers on slower links... There is probably a more fundamental reason for cisco's statement about using fewer buffers on slow-links: Keeping response time (RTT/SRT/etc) small. If you give a TCP the space, it will use it in an effort to maximize thruput - perhaps not 'consciously' ;-) but by always sending as many packets at a time as it can/is 'allowed.' While this is desirable for your file transfers, it might very well make the telnet/vt users a triffle peeved ;-) Of course, in this case, 'truth' is a relative thing. For example, if you 'know' that you never get a burst of traffic through your router greater that N packets, you might want to configure that many buffers so as to avoid retransmissions. However, that value of N is not only difficult to determine, it is also unlikely to remain static. As congestion controlled TCP's are becomming all the rage ;-), configuring fewer buffers is probably a good thing - the TCP's will still try to use 'all' the bandwidth/buffers, but you won't allow them to build-up such an enormous delay. File transfers go through, and interactive goes through. Of course, tuning the relative bandwidths given each is a further, related matter - perhaps some info on how OS schedulers go about sharing a CPU amongst processes would be enlightening ;-) Then we could think of all those bits in the IP header(s) as specifying 'process priorities' on a pkt/pkt basis... rick jones ___ _ ___ |__) /_\ | Richard Anders Jones | HP-UX Networking Performance | \_/ \_/ Hewlett-Packard Co. | "It's so fast, that _______" ;-) ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102110842.AA02908@holmenkollen.ifi.uio.no] <1991021108420400> From: enag@ifi.uio.no (Erik Naggum, the Internet Purist) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102110842.AA02908@holmenkollen.ifi.uio.no> Date: 11 Feb 91 08:42:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 68 In article <1991Feb10.205047.2217@oilean.uucp>, Joe McGuckin writes: > I think it's a great idea. But why stop there? Why not have an > additional confirmation that informs you when the message was > actually read... I think (yet another) reality check on this topic is needed. It can be exemplified by the question: How often do you send registered mail? If that is every time you send a letter, I sympathize with your need to do the same with e-mail. If not, I claim that you're going to do it every time if it were possible, for a large number of "you". The second, corollary problem is that even for a limited number of users who request receipts on any of the events "message received", "message read", "message understood", "mission completed", etc, on all messages sent, the volume of mail will likely escalate exponentially. Also, see below for a related volume problem. The third problem is the Three Armies problem, where two allies A and B are separated by an Enemy controlled area. A can communicate with B only _through_ the Enemy controlled area. Say A plans to do a two-flank attack on E, and this requires the cooperation of B, since a one-flank attack is close to suicide. A sends B a message: "Will attack from W at 0430. Pls ACK." The following occurs: (1) B doesn't get the message (ordonance caught, shot, drown...) (2) B gets the message, and ACKs, but needs an ACK. (1) A doesn't get the ACK. (2) A gets the ACK, ACKs, but needs an ACK. (1) B doesn't get the ACKed ACK. (2) B gets the ACKed ACK, ACKS, needs ACK. ... As should be obvious, a lack of ACK is not a NAK. An ACK is not guaranteed to be delivered, and thus must be ACKed, ad infinitum. Also, in the absence of an ACK, should A retransmit until an ACK is received? Should each party retransmit ACKs until properly ACKed? What is the terminating condition of this recursion? Consider what options exist in the absence of a "secure" ACK. Either party may not get the message or the ACK, but believe that the other party has got it, for any iteration of the above process. This may be suicide, and may not be a viable option. What would you do? Or rephrased: If you don't get an ACK "message received, read, understood, mission completed", which of the four possible NAK conditions is true, or did the ACK fail to get delivered? The corollary to this third problem is that the network will become saturated with ACKed ACKs, or retransmitted messages. The latter will also occur if the recipient is not equipped to reply, or chooses not to for any number of reasons. So, the summary of this rather elaborate exposition of this one problem of basic network technology, is: You don't want that. -- [Erik Naggum] Naggum Software, Oslo, Norway ----MESSAGE-END---- ----MESSAGE-BEGIN---- [09F0D6D7E020051A@crl.aecl.ca] <1991021114190000> From: TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) Newsgroups: comp.protocols.tcp-ip Subject: Problem with WIN/TCP's secure FTP Message-ID: <09F0D6D7E020051A@crl.aecl.ca> Date: 11 Feb 91 14:19:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Hi all We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of FTP as recommended by Wollongong. One problem that we have seen is that when I am FTP'ing from VMS to another machine, the 'ls' command is actually sent as 'ls' (ls followed by 2 blanks). This causes unknown directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP from FTP. (The command 'ls directory' works properly). Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE being too fussy? Thanks in advance for your help. Chris Tanner TANNERC@CRL.AECL.CA AECL Research ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102111520.AA18191@telesys.ncsc.navy.mil] <1991021115205700> From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) Newsgroups: comp.protocols.tcp-ip Subject: "certified" mail Message-ID: <9102111520.AA18191@telesys.ncsc.navy.mil> Date: 11 Feb 91 15:20:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Re: SMTP offering "certification" capabilities: Count me as one vote representing many users that would like to see SMTP include a "return receipt requested" feature that would send a notice to the originator when the addressee reads the registered message. Mark L. Williams Head, Telecommunications Branch Code 7630 Naval Coastal Systems Center Panama City, FL 32407-5000 (mark@telesys.ncsc.navy.mil) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102111542.AA18194@telesys.ncsc.navy.mil] <1991021115424700> From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102111542.AA18194@telesys.ncsc.navy.mil> Date: 11 Feb 91 15:42:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 Erik Naggum, Naggum Software, Oslo, Norway, offered a thoughtful rebuttal to the idea of certified/registered mailers. However, I believe that his arguments overlook several issues: 1) Many organizations do use registered mail, or some other feedback mechanism, to verify that deliveries have been made. The absence of comparable mechanisms in SMTP is perceived as a shortcoming that must be tolerated, at best. 2) Many non-SMTP mail systems, especially those running on PCs and LANs, offer registered mail capabilities, making the absence of those capabilities in SMTP more obvious and irritating than they might be otherwise. 3) The ACK/NAK problem can be as troublesome on LANs as it would be on the Internet. The fact that LANs supporting registered mail schemes do not typically collapse due to ACK/NAK cascades indicates that the real world can cope with mail registration successfully. 4) E-mail is certainly not the only means of communications available to most Internet users. The lack of a receipt notice usually prompts our users to call the intended recipient to alert him/her to the presence of the mail. This feedback opportunity can assist network administrators in identifying the existence of network problems if, for instance, the mail was never received. Registered mail is certainly no panacea for assuring effective communications. It can, however, provide important information for users and is in appreciable demand in some environments. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb11.164855.22742@zoo.toronto.edu] <1991021116485500> From: henry@zoo.toronto.edu (Henry Spencer) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <1991Feb11.164855.22742@zoo.toronto.edu> Date: 11 Feb 91 16:48:55 GMT References: <1991Feb10.205047.2217@oilean.uucp> Organization: U of Toronto Zoology Lines: 9 In article <1991Feb10.205047.2217@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes: >I think it's a great idea. But why stop there? Why not have an additional confirmation >that informs you when the message was actually read... That would be a good trick. Unless by "read" you mean "displayed on the user's screen, whether he actually read it or not"... -- "Read the OSI protocol specifications? | Henry Spencer @ U of Toronto Zoology I can't even *lift* them!" | henry@zoo.toronto.edu utzoo!henry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7791@exodus.Eng.Sun.COM] <1991021117473600> From: iv@sun.Eng.Sun.COM (Ian Vessey) Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso Subject: IEEE P1003.12 Seeks Input on Sockets and XTI (TLI). Keywords: sockets XTI TLI networking IEEE P1003.12 Message-ID: <7791@exodus.Eng.Sun.COM> Date: 11 Feb 91 17:47:36 GMT Sender: news@exodus.Eng.Sun.COM Followup-To: comp.protocols.tcp-ip Lines: 35 The POSIX process-to-process communications working group (P1003.12) would like to solicit outside comment. Between November 1990 and January 1991, we asked your opinions as to whether this working group should a) Develop a 3rd interface akin to sockets and XTI, b) Standardize either Berkeley sockets or XTI, c) Standardize both sockets and XTI. The results of the poll indicated that a) The working group should not adopt a new third interface b) The working group should adopt both sockets and XTI. These poll results were endorsed by the committee and we are currently pursuing a plan that provides a single language independent standard which has two `C' bindings, one for sockets and one for XTI. These two bindings will constitute our DNI(Detailed Network Interface). We are also working on an SNI(Simple Network Interface) which views the network from a far simpler standpoint and operates over the DNI. The purpose of this mail is to not only feed back the results of the poll and it's impact on our work, but to ask for further input. Specifically, we would like comments on perceived problems with either of the interfaces together with suggestions for additional features that you believe would be useful to add to one or both of them. Please keep in mind that backwards compatibility is very important in any change requests proposed. As before, please submit your comments to dot12@okeeffe.Berkeley.EDU. It would be helpful if you could indicate on which news group you read this article. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [569@phcoms.seri.philips.nl] <1991021117572800> From: roes@phcoms.seri.philips.nl (Aloys Roes) Newsgroups: comp.os.vms,comp.protocols.tcp-ip Subject: LAN-service TCP/IP Keywords: Novell Message-ID: <569@phcoms.seri.philips.nl> Date: 11 Feb 91 17:57:28 GMT Organization: Philips Components - SERI, Eindhoven, The Netherlands Lines: 28 A few weeks a go I posted a request for an update for various versions of TCP/IP. I got several replies for the CMU TCP/IP problem but none for the LAN-service. Either noone is running that software or people are too embarrassed to admit that they do. Anyway, we are facing the problem that since VMS 5.3 the rsh is no longer working (crashes the system). Now that we want to upgrade to VMS 5.4 we will run into the problem with the new password hashing algorithm that DEC introduced. We have been in touch with Novell who have taken over the Excelan (LAN-service) hardware and software but they can only inform us that the software will be in the public domain 'real soon now'. But there are some legal problems to be solved first they claim. They suggest that a transition to Multinet is a preferred solution but since we are phasing out our VMS systems we don't want to do any new investments in VMS software. And since we have a service contract we feel we have the right to request an updated version. We would like to know if others are or have been in this situation as well. If you have a solution or a good suggestion please contact us, Thanks, Aloys Roes, Philips Components, Building BC-136, | Tel. : + 31 40 72 30 62 P.O.Box 218, 5600 MD Eindhoven, The Netherlands | Email: roes@seri.philips.nl -- regards, Aloys Roes, Philips Components, Building BC-136, | Tel. : + 31 40 72 30 62 P.O.Box 218, 5600 MD Eindhoven, The Netherlands | Email: roes@seri.philips.nl ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb11.182119.3253@Solbourne.COM] <1991021118211900> From: imp@Solbourne.COM (Warner Losh) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problem with WIN/TCP's secure FTP Message-ID: <1991Feb11.182119.3253@Solbourne.COM> Date: 11 Feb 91 18:21:19 GMT References: <09F0D6D7E020051A@crl.aecl.ca> Organization: Solbourne Computer, Inc., Longmont, CO Lines: 44 In article <09F0D6D7E020051A@crl.aecl.ca> TANNERC@CRL.AECL.CA (CHRISTOPHER TANNER) writes: >I am FTP'ing from VMS to another machine, the 'ls' command is actually sent >as 'ls' (ls followed by 2 blanks). Are you sure? I'm about 99% positive that it sends out an NLST command when you type 'ls' to the prompt and a LIST command when you type 'dir'. I wouldn't doubt that it is putting an extra space at the end, however. >Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE >being too fussy? SGI and NOS/VE appear to be not conforming to the standard. To quote RFC 959, page 46: "The command codes and the argument fields are separated by ONE OR MORE spaces." (emphasis mine) So, the path name doesn't begin until after the second space[*]. Since there should be a pair after the second space, this makes the pathname argument NULL, so the implementation should list the current directory. This is due to the following in the description of LIST(pp 32, ibid): "If the pathname specifies a directory [...] If the pathname specifies a file [...]. A null argument implies the user's current working or default directory." and in NLST (p 33 ibid): "A null argument implies the current directory" If it was me, I'd file this as an MR to TWG, none the less, since it is causing interoperability problems. Warner -- [*] I guess a case could be made here that if there are to be no arguments, then the command should be immediately followed by a . However, other places call this argument a NULL argument, rather than a missing argument. -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [49563@ricerca.UUCP] <1991021118502600> From: giamma@orc.olivetti.com Newsgroups: comp.protocols.tcp-ip Subject: snmp agent MIB-II Message-ID: <49563@ricerca.UUCP> Date: 11 Feb 91 18:50:26 GMT Sender: news@orc.Olivetti.Com Reply-To: giamma@orc.olivetti.com () Organization: Olivetti Research California (Menlo Park) Lines: 10 Do you know if there are new free implementations of SNMP agent that are MIB-II compatible ???? (like CMU, MIT and ISODE). Thanks in advance, giamma@orc.olivetti.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [84878@sgi.sgi.com] <1991021119241900> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Summary: I'm wrong Message-ID: <84878@sgi.sgi.com> Date: 11 Feb 91 19:24:19 GMT References: <4320@ns-mx.uiowa.edu> <1991Feb8.203703.25654@zoo.toronto.edu> <1991Feb9.051623.29415@Think.COM> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 64 In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <84702@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >> (For those who don't get the point of the ":-) :-)", NFS uses UDP without > >> checksums. And people wonder why NFS is so unreliable...) > >Everyone! Please stop repeating this complaint. > > I agree that the complaint is wrong, but not for the same reason you do. > It isn't NFS that uses unchecksummed UDP, it's SunOS (or maybe BSD Unix) in > general (in its default configuration). In fact, SunOS doesn't provide a > way for a UDP-based application protocol to control whether it uses > checksums -- it's a single, system-wide parameter. Even worse, this one > parameter controls both whether checksums are generated during sending and > whether they are checked when receiving. Isn't this the right way to do it? With a "single, system-wide parameter" controlling whether UDP is checksummed or not? We argued among ourselves years ago whether the NFS switch should be the same as the global UDP switch. Ultimately, we decided that those who want no UDP checksums on NFS would not want them on anything else, including RPC, and conversely. Some might like a per-link switch, turning it on for SLIP lines and off for Ethernet and FDDI. (Having seen many checksums errors in FDDI frames with good CRC and E-bit, I'm not one.) Unfortunately, that idea does not work with routers; you'd need a UDP-cksum-is-a-good-idea-discovery protocol. The source from BSD has UDP checksums turned on by default. I haven't looked at the Reno NFS, but would be surprised if it's off there. > >Anyone with an NFS implementation that does not use UDP checksums should > >either fix or enjoy it. The NFS on common and current workstations does > >use UDP checksums by default. > > I think Suns would count as "common and current workstations", and by > default SunOS doesn't enable UDP checksums. In fact, until SunOS 4.1.1, > enabling UDP checksums required patching the kernel; in the latest release > they've finally moved it into a configuration file used during the kernel > build process. I finally used the source, and found I'm wrong about NFS3.2, which still set the checksum=0. In the NFS4.0 reference code, they follow the 4.3BSD convention of obeying "udpcksum". Poking around with `adb /vmunix` on a vanilla Sun that says "SunOS Release 4.1-GFX-Rev.1 (GFXRev1)" finds the horrifying fact that udp_cksum=0. Thus, Sun appears to be disabling all UDP checksums, not just NFS. I hope someone from Sun will dispute this, since I'd hate to have to tell everyone to sell their solar hardware and buy flowers.*** > > Ours do. I'm told that Sun's does as > >of the NFS 3.2 source release. > > Since the socket library doesn't provide a way to enable or disable UDP > checksums (I could be wrong -- I simply searched for "checksum" in the > setsockopt man page), I don't see how the NFS source release can do this. The NFS 3.2 source I meant was the kernel code received by NFS vendors who pay maintenance or royalties to Sun. It is in lib/libc/rpc/kdup_fastsend.c Vernon Schryver, vjs@sgi.com *** Silicon Graphics has called our products "IRIS" for about as long as other machines have had solar labels. That I feel compelled to append this says a lot about the validity of my claim about "common and current workstations." Oh, well. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102111926.AA09697@jessica.stanford.edu] <1991021119262900> From: almquist@JESSICA.STANFORD.EDU ("Philip Almquist") Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <9102111926.AA09697@jessica.stanford.edu> Date: 11 Feb 91 19:26:29 GMT References: <1991Feb9.190400.6078@Think.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 Barry, > It's a problem/feature of many TCP implementations. The reason it is done > is that the goal is to prevent fragmentation of datagrams. Hosts on the > same network can agree to base the max segment size (MSS) on the maximum > packet size (called the MTU -- Max Transmission Unit) of the network. If > they are on different networks, though, they don't know what the smallest > MTU is of all the intervening networks, correct so far, but > except that all networks in a > TCP/IP internet are required to support at least 512-byte packets > (actually, I think the number is something like 568, to allow 512-byte TCP > segments plus IP and TCP headers). IP networks are required to support 68 octet packets without network layer (IP) fragmentation (RFC 791 page 25). The Internet folklore that says that this number is 576 is erroneous. Every IP host must be able to receive (and reassemble if necessary) 576 octet datagrams (RFC 791 page 25). Thus, it is technically a protocol error to send a datagram larger than 576 to any host unless the sending host knows (perhaps because of a TCP maximum segment size negotiation or an agreement between the system managers) that the receiving host can accept larger datagrams. Historically (and arguably still today) it has been unwise to send larger datagrams to hosts on distant networks (even when the remote host was prepared to receive larger datagrams), since larger datagrams increase the likelihood that intermediate networks will perform fragmentation, causing degraded performance. It is recommended (but, surprisingly, not required) that a host be able to receive (and reassemble if necessary) a datagram at least as large as the MTU of its connected network (RFC 1122 page 56). Because most hosts follow this recommendation, it usually works to send MTU-sized datagrams to other hosts on the same (sub)net. However, as described above, there are no guarantees. The default TCP maximum segment size is 536 (not 512) octets, for the reasons you gave (to allow 40 octets for IP and TCP headers - RFC 1122 page 85). Finally, a minor nit: the standards talk about octets rather than bytes. Octets are eight bit quantities. Bytes are also eight bit quantities on most most modern computers, but computer architecture is beyond the scope of the TCP/IP standards. Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [122372@uunet.UU.NET] <1991021119375900> From: rick@uunet.uu.net (Rick Adams) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Summary: cant reliably tell if a message was read Message-ID: <122372@uunet.UU.NET> Date: 11 Feb 91 19:37:59 GMT References: <1991Feb11.164855.22742@zoo.toronto.edu> Sender: usenet@uunet.UU.NET Lines: 21 Nntp-Posting-Host: uunet.uu.net > >I think it's a great idea. But why stop there? Why not have an additional confirmation > >that informs you when the message was actually read... > > That would be a good trick. Unless by "read" you mean "displayed on the > user's screen, whether he actually read it or not"... Even thats not good enough. A company I used to work for had an office autmoation system that allowed you to give messages a "confirm on read" status. So many people at the company applied it to everything that I used to run a text editor directly on the mail box to "read" the mail, then within the system, I "deleted unread" the messages. So, no confirmation... (Just my way of playing with their minds I guess.) Message confirmation is a great way to increase revenues if you charge per message. Its a lousy way to run a mail system. It basicaly replicates the received ok handshakes from lower levels and is not necessarily a useful indication. (I.e. what about all of the unacknowledged messages I read?) ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [84890@sgi.sgi.com] <1991021119403800> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Keywords: ftp tcp Message-ID: <84890@sgi.sgi.com> Date: 11 Feb 91 19:40:38 GMT References: <1991Feb6.184300@sicsun.epfl.ch> <1991Feb9.190400.6078@Think.COM> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 24 In article <1991Feb9.190400.6078@Think.COM>, barmar@think.com (Barry Margolin) writes: > .... Also, > some TCP implementations use a larger MSS for subnet that are part of the > same subnetted network than for outside networks (on the assumption that > local area media are faster than wide area media, so the consequences of > greater retransmission due to loss of a fragment are less severe). Some might fear worse consequences of IP fragementation in such an environment, because the routers are likely to be general purpose systems which just happen to have additional ethernet interfaces, and may not have an abundance of buffering. The justification I've heard most often for such switches is that the MTU in the local internet is at least as large as the MTU on local ethernet, 1500 bytes. In such a case, 1500 causes no more fragmentation than 576. I have seen large commerical, production networks where using 1500 instead of the approved 576 improved FTP performance 3X. The default configuration on an IRIS is "allsubnetsarelocal=true". Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks? Vernon Schryver, Silicon Graphics, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb11.205402.12401@b11.ingr.com] <1991021120540200> From: Ed Sale Newsgroups: comp.protocols.tcp-ip Subject: TCP Urgent Pointer *Standard* Keywords: standard, urgent pointer Message-ID: <1991Feb11.205402.12401@b11.ingr.com> Date: 11 Feb 91 20:54:02 GMT Sender: @b11.ingr.com Reply-To: b11!ed!sale@ingr.com Followup-To: comp.protocols.tcp-ip Organization: Intergraph Lines: 56 After reading the sections of the TCP and Host Requirements RFC's (included below), it is still unclear to me how a standard TCP should set the Urgent Pointer field of the TCP header in segments with the URG control bit set. My problems with the descriptions in the RFC's are: What does "positive offset" mean, precisely? What does "points to" mean, precisely? My question boils down to this: If a TCP segment is carrying just one byte of data, and that one byte is urgent data, what value should the TCP header's Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.) Also, in my experience with many TCP implementations, there is apparently confusion about the value that the Urgent Pointer should have, as they do not appear to all be setting this field the same way. I guess even if I choose to implement *STANDARD* Urgent Pointer processing I'm still not going to be able to converse effectively with every TCP implementation out there :-(. Thanks in advance for any insight you may provide into this problem. My apologies if this question has been asked and answered here previously. Please reply to me by mail, and I will post a summary of the responses I get. rfc793 (TCP), page 17, lines 1204-10 "Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be (sic) interpreted in segments with the URG control bit set." rfc793 (TCP), page 56, lines 3523-4 "If the urgent flag is set, then SND.UP <- SND.NXT - 1 and set the urgent pointer in the outgoing segments" rfc1122 (Host Requirements), page 84, lines 4917-22 "4.2.2.4 Urgent Pointer: RFC-793 Section 3.1 The second sentence is in error: the urgent pointer points to the sequence number of the LAST octet (not LAST+1) in a sequence of urgent data. The description on page 56 (last sentence) is correct." ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Ed Sale Intergraph Corp. Huntsville, AL 35894-0001 (205)730-2000 b11!ed!sale@ingr.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102120858.AA14961@ucbvax.Berkeley.EDU] <1991021121002500> From: 08071TCP@MSU.BITNET (Doug Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problem with WIN/TCP's secure FTP Message-ID: <9102120858.AA14961@ucbvax.Berkeley.EDU> Date: 11 Feb 91 21:00:25 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: Doug Nelson Organization: The Internet Lines: 31 >We are running WIN/TCP vs 5.1 on VMS 5.4 and are using the secure vs of >FTP as recommended by Wollongong. One problem that we have seen is that when >I am FTP'ing from VMS to another machine, the 'ls' command is actually sent >as 'ls' (ls followed by 2 blanks). This causes unknown >directory errors on NOS/VE, IRIS (r3.3), but not on SUN, Ultrix or PC/TCP >from FTP. (The command 'ls directory' works properly). > >Who is in error here. Is Wollongong violating the standard, or SGI and NOS/VE >being too fussy? According to my reading of the spec, it's Wollongong's problem. The spec clearly states that a keyword (NLST in this case) is followed either by CR/LF if there are no parameters, or SP if there are parameters. Also, the syntax of the LIST and NLST commands is shown as having one optional parameter: LIST [ ] "" is defined as "", which is defined as one or more occurrences of , which is defined as any ASCII char from 0 to 127 excluding CR and LF, but including space. This implies that "LIST " is a request to list a file or directory with a single blank as its name. Now, the semantics of recognizing a pathname require the treatment of a null path as being "the current directory", but nothing prevents or requires a server to strip white space from the pathname before any further interpretation. Doug Nelson Michigan State University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102111609.aa03681@Note.NSF.GOV] <1991021121094700> From: mmorse@NSF.GOV (Michael Morse) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102111609.aa03681@Note.NSF.GOV> Date: 11 Feb 91 21:09:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 83 > We have recently installed a new NOVELL mail system called PMAIL. One of the > features allows you to request a confirmation once the mail message is > delivered. I think this is an EXCELLENT idea. I had previously thought of this > before, so when I saw it I was happy. > This is accomplished by putting a line in the headers that only PMAIL > recognizes.Now to the point. What would other people think of making some sort > of standard header line that other mailers can act on? It's not hard to > understand, and is easy to implement. Despite the popularity of this feature in the commercial world, and in commercial (proprietary) mail systems, it is surprisingly difficult to implement in SMTP/Unix based mail systems. Here are just some of the reasons: 1. Most Unix mail systems do not really have the concept of "when the user *reads* the mail." If you talk to people who want this feature it turns out that they're not really interested that some machine has accepted responsibility for the message, they want to know that the recipient "got it" which means, "has looked at it." Unix mail systems tend to stick mail in a file and let the user get to it by whatever method they choose. If you're actually talking about accepting responsibility, then most Unix systems that run sendmail already do this (just add "return-receipt-to: your_name" to the message header and send it to a Unix box). Again, this is *not* what most people mean by certified mail, but if it is what you mean, I suggest you just use the sendmail convention (and skip the rest of this message). 2. In SMTP, the header of the message is really not much more than text. That makes it difficult to implement a "when read" receipt. The reason is that you only want to send the receipt once. That means you must modify the header after you read it once. Technically this is difficult to do in a relatively robust fashion on current Unix mail systems. One of the reasons is that a large number of messages are usually contained in a single file, meaning you have to completely re-write the file, keeping it locked the whole while. 3. There is a problem with mailing lists. If someone addresses mail to a mailing list (such as this one) and requests certified mail, do they want a receipt from the list maintainer, or from everyone that receives a copy of the message? Depending on how you answer this question, many other problems result, since it's very difficult to determine when a message has reached its final destination. If you don't choose final destination as the point to generate the certified mail, then you must design a method of specifying where to generate the receipt. 4. However, the real problem is social: there are many people on the Internet that consider this concept an invasion of their privacy (I should send you the flames I received when I proposed it a couple of years ago.) The reasoning is that "my mail is my mail" and you have no right to know when I read it, if I read it, and you certainly can't use CPU resources on my machine to send a receipt. The existance of this large group of people means that given the technical limitations listed above, a lot of people will subvert the feature, making it *much* less useful to the senders. This attitude is not limited to the Internet, but it is rare in the commercial world, where everything is considered by many to be the property of the company or organization. However, my experience is that it is a common attitude in the U.K. This attitude resulted in the bizarre implementation of All-In-One for DEC, in which a user could configure things so that all mail he sent asked for a return receipt, but could also configure his mailbox so that no return receipts were ever sent to incoming mail. Allowing a user to "turn off" receipts makes the feature less useful to an organization since users never know why they didn't get a receipt. Again, in the commercial world you can simply decree "It's illegal to turn off receipts". You just can't decree that in the Internet. The bottom line is that this feature will be easy to implement in a closed, proprietary mail system, and almost impossible in SMTP. I believe it is a feature of X.400, so it'll be interesting to see how it is implemented (or not implemented) in the Internet/Unix world. --Mike Michael Morse Internet: mmorse@note.nsf.gov National Science Foundation BITNET: mmorse@NSF 1800 G St. N.W. Room 401 Telephone: (202) 357-7659 Washington, D.C. 20550 FAX: (202) 357-7663 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19910211212243.8.BARMAR@OCCAM.THINK.COM] <1991021121220000> From: barmar@THINK.COM (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <19910211212243.8.BARMAR@OCCAM.THINK.COM> Date: 11 Feb 91 21:22:00 GMT References: <9102111926.AA09697@jessica.stanford.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Date: Mon, 11 Feb 91 11:26:29 -0800 From: "Philip Almquist" IP networks are required to support 68 octet packets without network layer (IP) fragmentation (RFC 791 page 25). The Internet folklore that says that this number is 576 is erroneous. Thanks for the correction. However, it's reasonably safe to assume that most media have an MTU of at least 512. I can't think of any that don't, and I would be surprised if anyone invented a new medium with a smaller MTU (the current direction is generally towards larger packet sizes). Finally, a minor nit: the standards talk about octets rather than bytes. Octets are eight bit quantities. Bytes are also eight bit quantities on most most modern computers, but computer architecture is beyond the scope of the TCP/IP standards. I know that, and I debated using "octet" in my message. I chose to use terminology consistent with the question. It's rarely necessary to make this fine distinction outside standards documents (people on systems with non-8-bit-bytes generally know how to translate to their own frame of reference). barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27b71bf9@omega.UUPC] <1991021122343000> From: ash@uupc.omega (Andrew Hardie) Newsgroups: comp.protocols.tcp-ip Subject: NS DP8390 ethernet chip Message-ID: <27b71bf9@omega.UUPC> Date: 11 Feb 91 22:34:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 I seem to remember some months ago talk about problems (dropped packets?) with the A and B versions of the DP8390 chip as fitted to the WD8003E. I notice that the new boards have the DP8390C chip. Can someone remind me what the problem was and whether it (and any others that may have existed in the A and/or B versions) were fixed in the C revision. Thanks -- Andrew Hardie ash@omega.uucp London, England ukc!cctal!omega!ash No is merely a negotiating position; yes is always final. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb11.233102.24222@Think.COM] <1991021123310200> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb11.233102.24222@Think.COM> Date: 11 Feb 91 23:31:02 GMT References: <1991Feb8.203703.25654@zoo.toronto.edu> <1991Feb9.051623.29415@Think.COM> <84878@sgi.sgi.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 35 In article <84878@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <1991Feb9.051623.29415@Think.COM>, barmar@think.com (Barry Margolin) writes: >> Even worse, this one >> parameter controls both whether checksums are generated during sending and >> whether they are checked when receiving. >Isn't this the right way to do it? With a "single, system-wide parameter" >controlling whether UDP is checksummed or not? From p.78 of RFC1122: An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on. If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram. 4.2BSD-based UDP implementations violate both these requirements. First, it is supposed to be the application that decides whether it wants checksumming; in BSD, either all applications get it or none do. Second, it is not permitted to disable checking of received packets. > We argued among ourselves >years ago whether the NFS switch should be the same as the global UDP >switch. I wasn't only complaining about the fact that it affects all applications. I was complaining about the fact that you can't disable generation of checksums but still enable checking of checksums. Thus, even though my client does checksumming correctly, errors will still get through if the server has them disabled. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [543@mermaid.Litle.Com] <1991021123520600> From: tom@mermaid.Litle.Com (Tom Hampton) Newsgroups: comp.protocols.tcp-ip Subject: Anyone using Stratus TCP/IP with Wellfleet Router? Message-ID: <543@mermaid.Litle.Com> Date: 11 Feb 91 23:52:06 GMT Reply-To: tom@mermaid.litle.com (Tom Hampton) Organization: Litle & Co. Lines: 14 We are experiencing strange behavior between our Stratus computer and our Wellfleet router. The Stratus times out too fast (10 sec) and the Wellfleet seems bent on reporting "system not available." Anyone else using this combo with success? -- =============================================================================== Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755 | +1 603 643 1832 ------------------------------------------------------------------------------- Design is figuring out what you won't be able to do. ------------------------------------------------------------------------------- tom@mermaid.litle.com {backbone}!dartvax!mermaid!tom =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27915:Feb1200:07:5191@kramden.acf.nyu.edu] <1991021200075100> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <27915:Feb1200:07:5191@kramden.acf.nyu.edu> Date: 12 Feb 91 00:07:51 GMT References: <1991Feb11.164855.22742@zoo.toronto.edu> <122372@uunet.UU.NET> Organization: IR Lines: 11 There is a different kind of mail system where return receipts are perfectly natural. All messages are very short, but can be accompanied by one or more files that aren't sent at first but are held on the sender's system. The recipient of the message can retrieve the files---possibly compressed, encrypted, checksummed, whatever---with a command or two. (When the initial message isn't required, this turns into a BITNET-style file transfer system.) The sender is told when the files are picked up, so he can use them as a (voluntary) return-receipt system. ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [28229:Feb1200:29:5391@kramden.acf.nyu.edu] <1991021200295300> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <28229:Feb1200:29:5391@kramden.acf.nyu.edu> Date: 12 Feb 91 00:29:53 GMT References: <16381:Feb1015:07:5791@kramden.acf.nyu.edu> <9102102022.AA26112@osiris.MIT.EDU> Organization: IR Lines: 34 In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes: [ RFC 931 ] > I wouldn't go so far as to say it makes mail a "secure" protocol. But it does---again, provided that TCP is made secure. The problem until now is that mail introduced its own security holes over and above those of TCP: it didn't even try to verify the remote username. Now at least we can reduce the problem to TCP. > However for it to be really useful, all the mail relays > between sender and receiver need to implement it. I'm not convinced that this is such a problem. The Internet mail I send rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com. If sending organization and receiving organization support RFC 931, that's enough. > The Privacy Enhanced Mail RFCs (sorry to sound like a salesman myself > here!) define an end-to-end mechanism exactly so that sender and > recipient need have no trust in the intermediate mail relays (and no > requirements on the software that they run). I have no objection to end-to-end security (although I don't like the current fashion of putting it into every single protocol instead of making the link level secure). But we don't have the software yet. I also hope that if NYU decides to spend any money on RSA Inc., it starts by putting a few thousand dollars into challenging the RSA patent. Furthermore, mail encryption doesn't do anything for news, telnet, rlogin, talk, or any of the other services people use. RFC 931 helps all of them the same way it helps mail. ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102120205.AA12117@jessica.stanford.edu] <1991021202054900> From: almquist@JESSICA.STANFORD.EDU ("Philip Almquist") Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <9102120205.AA12117@jessica.stanford.edu> Date: 12 Feb 91 02:05:49 GMT References: <19910211212243.8.BARMAR@OCCAM.THINK.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Barry, > However, it's reasonably safe to assume that > most media have an MTU of at least 512. I can't think of any that > don't, and I would be surprised if anyone invented a new medium with a > smaller MTU (the current direction is generally towards larger packet > sizes). SATNET had an MTU of somewhere around 250, if I recall correctly, but I'm pretty sure it's now defunct. I also seem to recall that Van uses a similar MTU over his compressed SLIP dialup line (since he doesn't preempt an FTP data packet that is being transmitted when a Telnet packet is queued for transmission, he wants to ensure that the FTP data packet is short enough that its transmission can be completed without noticeably delaying the transmission of the Telnet packet). I don't know what sorts of MTUs are used for packet radio, but they may be pretty small for similar reasons. ATM networks will also use very small packets, but I guess the expectation is that they will do Link Layer fragmentation to present the appearance of a reasonably large MTU to the Network Layer. In general, I agree that the trend is for new kinds of networks to have much larger MTUs. >> Finally, a minor nit: the standards talk about octets rather than bytes. > I know that, and I debated using "octet" in my message. I chose to use > terminology consistent with the question. It's rarely necessary to make > this fine distinction outside standards documents... Like I said, it was a minor nit, and I almost omitted it. You should probably chalk it up to fond memories of the days when I worked on computers which have a far more flexible concept of what a "byte" is. Philip ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13304@life.ai.mit.edu] <1991021203213000> From: lee@gdc.portal.com (Seng-Poh Lee, Speedy) Newsgroups: comp.sources.wanted,comp.protocols.tcp-ip Subject: Source/binaries for talk/d, rwho/d, finger/d for HP-UX Keywords: HP-UX, talk, rwho, finger Message-ID: <13304@life.ai.mit.edu> Date: 12 Feb 91 03:21:30 GMT Sender: news@ai.mit.edu Followup-To: lee@gdc.portal.com Organization: General DataComm Ind. Inc Lines: 17 Hello, I am looking for binaries (or source that will compile on HP-UX 5.5) for the following BSD network utilities; talk and talkd rwho and rwhod finger and fingerd I am currently running inetd with ftp, telnet, and rlogin (which came with the system) but I would like those other utilities. If anyone has them running, please let me know. I have access to ftp or can receive them in uuencoded compressed/tar format by mail Thanks in advance Seng-Poh Lee lee@gdc.portal.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb12.042501.6758@cec1.wustl.edu] <1991021204250100> From: brown@wucs1.wustl.edu (Mike Brown) Newsgroups: comp.protocols.tcp-ip Subject: SNMP "manageability" ?!? Message-ID: <1991Feb12.042501.6758@cec1.wustl.edu> Date: 12 Feb 91 04:25:01 GMT Sender: news@cec1.wustl.edu (USENET News System) Organization: Washington University, St. Louis MO Lines: 20 I recently learned that a major U.S. router vendor defines SNMP management as the ability to "monitor" their equipment via SNMP and not the configuration of the equipment via SNMP. I believe that I understand the security problems related to SNMP and why caution must be exercised with the use of SNMP to configure network elements. I still believe that SNMP can be an effective configuration mechanism in certain networks. My question is: Does any router vendor support configuration via SNMP? If you think I am naive for using SNMP to configure network elements then please let me know... Regards, Mike Brown Corporate Telecommunications Information Systems One Bell Center, Rm 24-V-5 Southwestern Bell Telephone Co. St. Louis, MO 63101 (314) 235-7863 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14517@scorn.sco.COM] <1991021206140800> From: ericd@sco.COM (Eric Davis) Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: Re: why is 386 tcp limmited to one slip session? Keywords: 386,slip Message-ID: <14517@scorn.sco.COM> Date: 12 Feb 91 06:14:08 GMT References: <1991Feb8.162556.6584@jpusa1.chi.il.us> <1991Feb09.143548.11116@jadpc.cts.com> Sender: news@sco.COM Organization: The Santa Cruz Operation, Inc. Lines: 15 In article <1991Feb09.143548.11116@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: >They (altos) can support more than 1 concurrent slip. I >wonder if the altos tcp can be laid down into sco unix and work? SCO TCP/IP for Unix can have more than one SLIP connection. As for Xenix TCP/IP, not sure. I can check an post when I find out. Ericd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Eric Davis () INTERNET -=> ericd@sco.COM Technical Support Engineer II () UUCP -=> {uunet|sun|att|ucsc}!sco!ericd The Santa Cruz Operation Inc. () =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ----MESSAGE-END---- ----MESSAGE-BEGIN---- [947@nrm6.UUCP] <1991021208072900> From: pedrotti@nrm6.UUCP (PEDROTTI) Newsgroups: comp.protocols.misc,comp.protocols.tcp-ip Subject: Looking for PD source for ftp,tftp,telnet. Keywords: ftp tftp telnet public domain Message-ID: <947@nrm6.UUCP> Date: 12 Feb 91 08:07:29 GMT Followup-To: comp.protocols.misc Organization: SIEMENS AG, Abt. AUT V151 STSK, 8012 Ottobrunn Lines: 6 If anyone has information how to get public domain sources for ftp, tftp and telnet (client AND server), please send mail. Thanks a lot in advance! Philippe Pedrotti @ SIEMENS Corp., Munich, Germany. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb12.091028.4733@oilean.uucp] <1991021209102800> From: joe@oilean.uucp (Joe McGuckin) Newsgroups: comp.protocols.tcp-ip Subject: Ethernet based serial port expanders? Message-ID: <1991Feb12.091028.4733@oilean.uucp> Date: 12 Feb 91 09:10:28 GMT Organization: Island Software Lines: 11 Has anyone ever seen such a gadget? I know there are terminal servers, but they usually lack full control of the serial port. I'm looking for something that looks (software-wise) and acts just like a serial port on a Sun and hooks up via ethernet. -joe -- Joe McGuckin oilean!joe@sgi.com Island Software joe@parcplace.com (415) 969-5453 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102120847.aa05309@NRI.NRI.Reston.VA.US] <1991021213471200> From: vcerf@NRI.RESTON.VA.US Newsgroups: comp.protocols.tcp-ip Subject: SLIP and PPP for NeXt Message-ID: <9102120847.aa05309@NRI.NRI.Reston.VA.US> Date: 12 Feb 91 13:47:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 162 Thanks to all who have taken time to respond. I enclose the summary for anyone else who is interested. Vint Cerf ---------- ------- Forwarded Messages Date: Sat, 9 Feb 91 21:19:02 -0500 (EST) From: "Douglas F. DeJulio" To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT The company NeXT doesn't support it, but individuals have ported "dial up ip" to the NeXT. I've got it installed and will be shortly setting it up to replace my Sun2 as our house's SLIP router, if I can. - -- Doug DeJulio dd26+@andrew.cmu.edu (ATK/AMS) ddj@zardoz.club.cc.cmu.edu (NeXT) ------- Message 2 To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT Date: Sat, 09 Feb 91 11:22:16 PST From: Van Jacobson Vint, I don't know if they're distributing their versions but I've heard of two NeXT cslip ports, one by Louie Mamakos (louie@sayshell.umd.edu) and one by Morris Meyer (Morris_Meyer@NeXT.COM). - Van ------- Message 3 Date: Sat, 9 Feb 91 22:17:36 EST From: Pat Barron To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT Newsgroups: comp.protocols.tcp-ip Organization: Pat's Sun-2/120 In article <9102082128.aa16873@NRI.NRI.Reston.VA.US> you write: >Does NeXT have SLIP or PPP support? There is a dial-up SLIP package available for the NeXT. It can be FTP'ed from next.com (or some machine in that domain - I'm not sure, since I don't use it myself). As I remember, it was either written or ported by Cal Thixton at the NeXT Pittsburgh sales office. You might try calling him for more details (I don't have the number handy, but you can get it from Directory Assistance in area code 412). - --Pat. ------- Message 4 Date: Sat, 9 Feb 91 9:53:06 MST From: Jacob Gore To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT Newsgroups: comp.protocols.tcp-ip / comp.protocols.tcp-ip / vcerf@NRI.RESTON.VA.US / Feb 8, 1991 / > Does NeXT have SLIP or PPP support? Not yet. Jacob - -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob ------- Message 5 Date: Sat, 9 Feb 91 14:26:14 EST From: bob@morningstar.com To: vcerf@NRI.Reston.VA.US Subject: SLIP for NeXT Cc: Jamey Laskey We have a PPP product under development for the NeXT, among others, and due out Real Soon Now. We're reluctantly considering adding optional SLIP support - how important is that to you? Contact Jamey Laskey of Morning Star Technologies at +1 800 558 7827 or +1 614 451 1883. ------- Message 6 Date: Mon, 11 Feb 91 23:22:58 PST From: "Eric P. Scott" To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT >Does NeXT have SLIP or PPP support? Not officially, but [129.18.18.3]:pub/Slip/* suggests that this may change. -=EPS=- ------- Message 7 Date: Mon, 11 Feb 91 13:23:38 -0500 From: Rick Adams To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT I put some of the NeXT engineers in touch with the Telebit engineers who are doing the NetBlazer. NeXT was very interested and in fact got an early beta test NetBlazer. - --rick ------- Message 8 Date: Mon, 11 Feb 91 07:43:18 MST From: "Mitchel W. Sukalski" To: vcerf@NRI.Reston.VA.US Subject: Re: SLIP for NeXT Vint- I've asked that same question on comp.sys.next and of our NeXT gurus here. No, there is no SLIP or PPP support for 2.0; moreover, there is no System V STREAMS support to port more conventional implementations. One of our folks here, though, has been told by some folks at NeXT that they are working on a PPP implementation. Mitch Sukalski LANL ------- Message 9 To: vcerf@NRI.Reston.VA.US Cc: mts@terminator.cc.umich.edu Subject: Re: SLIP for NeXT Date: Sun, 10 Feb 91 19:27:38 -0500 From: "Michael T. Stolarchuk" I'm asking the same question right now. If you get any answers about PPP please let me know. I can already answer the question about slip. Someone from NeXT ought to answer directly, but who knows what they read. The slip changes are kern-loader loadable; they can be integrated without making direct kernel modifications. If you get no answer from next, I'll send you the names (mail addresses) of people you can bug. ... you can have what I've got (slip). mts. michael t. stolarchuk U of Michigan Ann Arbor, Mi. 48105 ------- End of Forwarded Messages ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102121419.AA12238@chance.mitre.org] <1991021214193200> From: mckee@chance.mitre.org (H. Craig McKee) Newsgroups: comp.protocols.tcp-ip Subject: PSE info request Message-ID: <9102121419.AA12238@chance.mitre.org> Date: 12 Feb 91 14:19:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Last Spring or Summer there was a note to the list about a book: ASN.1 The Tutorial and Reference. The book was available from a firm named PSE. I've lost the address and phone number; I would appreciate a pointer to either. Thanks - Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2661@bdrc.bdrc.bd.com] <1991021215095400> From: jackson@bdrc.bd.com (Gene Jackson) Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP for MAC Message-ID: <2661@bdrc.bdrc.bd.com> Date: 12 Feb 91 15:09:54 GMT Organization: Becton Dickinson Rsrch Cntr, RTP, NC Lines: 8 We are interested in finding a good tcp-ip system for Macintosh computers using ethernet. We would like for the Macs to be NFS clients using a SUN as an NFS server. We also need mail running on the Macs that can send and receive from SMTP. Thanks for any suggestions. We are particularly interested in hearing from users who have successful systems running. Gene Jackson jackson@bdrc.bd.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102121539.AA00240@snow-white.lanl.gov] <1991021215395900> From: cpw@SNOW-WHITE.LANL.GOV (C. Philip Wood) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <9102121539.AA00240@snow-white.lanl.gov> Date: 12 Feb 91 15:39:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Vernon, >The default configuration on an IRIS is "allsubnetsarelocal=true". >Do you guys consider this Evil, Wrong, and Grounds for Belittling Remarks? No, but some subnets are more equal than others. :^) Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102121543.AA09706@sonny.proteon.com] <1991021215433500> From: jas@proteon.com (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: SunOS UDP checksums Message-ID: <9102121543.AA09706@sonny.proteon.com> Date: 12 Feb 91 15:43:35 GMT References: <84878@sgi.sgi.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 In SunOS 4.1.1, udp_cksum is still off. The only progress towards any sort of intelligence on Sun's part is that they finally *document* it, and even cover how to set it by editing one C file when building a kernel. And it finally does affect NFS! (It never did in SunOS 3.X!) We've recently had serious NFS file corruption problems because of the absolute impossibility of enabling NFS/UDP checksums on SunOS 3.5.2, which we still use on a key development machine. (It was due to a bug in a development router corrupting packets.) At least when I upgrade it (someday) to SunOS 4.1.1, I'll get checksums. Presumably, Sun chooses to ignore RFC 1122 (Requirements for Internet Hosts -- Communication Layers). It is dated October 1989, so I seriously doubt that SunOS 4.1.1 had a feature freeze that long ago. (However, we have heard that the path from the TCP/IP group at Sun to SunOS is very long, and fraught with delays, so it may well be that the fix has been in the pipeline for a year. If that is the case, kudos to the TCP/IP group, and would the SunOS group get off their tails!) It would be nice to hope that SVR4 will conform to the host requirements RFC's... To re-quote the section of UDP checksums: 4.1.3.4 UDP Checksums A host MUST implement the facility to generate and validate UDP checksums. An application MAY optionally be able to control whether a UDP checksum will be generated, but it MUST default to checksumming on. If a UDP datagram is received with a checksum that is non- zero and invalid, UDP MUST silently discard the datagram. An application MAY optionally be able to control whether UDP datagrams without checksums should be discarded or passed to the application. I have no idea if Sun would reply to a bid that required RFC 1122 conformance and claim conformance. They don't conform. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102151311.AA18132@ucbvax.Berkeley.EDU] <1991021217104800> From: jcurran@SH.CS.NET (John Curran) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problem with WIN/TCP's secure FTP Message-ID: <9102151311.AA18132@ucbvax.Berkeley.EDU> Date: 12 Feb 91 17:10:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 40 -------- Hmm.. RFC959 is slightly contradictory regarding the spaces between the command and argument fields: pg. 46 > LIST [ ] > NLST [ ] where is NVT-ASCII notation for space and hence does not allow multiple spaces. is defined to allow a leading space. versus pg. 45 > The command codes and the argument fields are separated by one or more > spaces. The host requirement application layer rfc (1123) has this on the subject: > 4.1.4.1 Pathname Specification > > Since FTP is intended for use in a heterogeneous > environment, User-FTP implementations MUST support remote > pathnames as arbitrary character strings, so that their form > and content are not limited by the conventions of the local > operating system. > > DISCUSSION: > In particular, remote pathnames can be of arbitrary > length, and all the printing ASCII characters as well > as space (0x20) must be allowed. RFC-959 allows a > pathname to contain any 7-bit ASCII character except CR > or LF. Since the specification is inexact, I'd let each vendor (WG, CDC, and SGI) know about the interoperability issue, so that they all have the option of "fixing" their s/w. Of course, as a side issue, the next round of clarifications should be tightened to allow leading spaces in filenames (of questionable value) or multiple spaces as a delimiter. /John ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb12.172631.27860@Solbourne.COM] <1991021217263100> From: imp@Solbourne.COM (Warner Losh) Newsgroups: comp.protocols.tcp-ip Subject: Re: Problem with WIN/TCP's secure FTP Message-ID: <1991Feb12.172631.27860@Solbourne.COM> Date: 12 Feb 91 17:26:31 GMT References: <9102120858.AA14961@ucbvax.Berkeley.EDU> Organization: Solbourne Computer, Inc., Longmont, CO Lines: 34 In article <9102120858.AA14961@ucbvax.Berkeley.EDU> Doug Nelson writes: >This implies that "LIST > " is a request to list a file or directory with a single >blank as its name. No, I must disagree with your reading of the RFC. On page 46 of RFC 959 states: "The command codes and the argument fields are separated by one or more spaces" LIST is a list command that has a NULL pathname argument (since it starts after the last and ends before the ). It is clear from reading RFC 1123 that the ftp daemon should be able to accept any string that doesn't have a or a in it. However, in light of the text I sighted above, it would appear that the path name can't start with a space. This would seem to indicate a small hole in the FTP spec. I just noticed that the SunOS 4.0.3 ftpd insists on having just one space between the command and the arguments. Checking the source makes this reason rather obvious. The reason that "LIST" works on the sun (and I guess other BSD machines) is that this turns into a popen ("ls -lg ") which will list the current directory. However, like I said before, I'd file a bug with Wollongong since it is an interoperability issue. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [85079@sgi.sgi.com] <1991021217325100> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Summary: fooey Message-ID: <85079@sgi.sgi.com> Date: 12 Feb 91 17:32:51 GMT References: <1991Feb8.203703.25654@zoo.toronto.edu> <1991Feb11.233102.24222@Think.COM> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 46 In article <1991Feb11.233102.24222@Think.COM>, barmar@think.com (Barry Margolin) writes: > > From p.78 of RFC1122: > > An application MAY optionally be able to control whether a UDP checksum > will be generated, but it MUST default to checksumming on. > > If a UDP datagram is received with a checksum that is non-zero and > invalid, UDP MUST silently discard the datagram. > > 4.2BSD-based UDP implementations violate both these requirements. First, > it is supposed to be the application that decides whether it wants > checksumming; in BSD, either all applications get it or none do. Second, > it is not permitted to disable checking of received packets. The important word in the first paragraph is "MAY". 1122 does not require that an application be able to disable UDP checksumming. 4.3BSD does not have such a switch, and does not violate 1122 by not having it. As long as you don't break it by changing udpcksum, 4.3BSD does not violate the second paragraph. The fact that 4.3BSD has additional characteristics cannot rationally be considered a violation of the standard. If the characteristic of being able to change to non-conforming behavior is sufficient to be non-standard, then only ROM based systems can be standard, since there are always bozos--err--valued customers who can, will, and do change things in ways you and I consider obviously stupid and non-conforming. Does the fact that many people installed their own implementations of TCP/IP (often BSD derived) on popular workstations by itself make those systems non-1122 compliant even when running the vendor supplied system? If the answer to that question were yes, then 1122 and 1123 would be uninteresting to workstation vendors and our customers. Please keep standards carping rational. It appears that some common workstations (not my employer's) violate the above quoted part of 1122. Their "feet should be held to the fire". You are putting out the flame when you lump 4.3BSD checksumming behavior with theirs. (I'm assuming you mean 4.3BSD base UDP implementations, which follow the rules you criticize, not 4.2 BSD.) Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb12.135915.1@rogue.llnl.gov] <1991021220591500> From: oberman@rogue.llnl.gov Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP?READ/NEW/FOLLOWUP Message-ID: <1991Feb12.135915.1@rogue.llnl.gov> Date: 12 Feb 91 20:59:15 GMT References: <16381:Feb1015:07:5791@kramden.acf.nyu.edu> <9102102022.AA26112@osiris.MIT.EDU> <28229:Feb1200:29:5391@kramden.acf.nyu.edu> Sender: usenet@lll-winken.LLNL.GOV Lines: 35 Nntp-Posting-Host: rogue.llnl.gov In article <28229:Feb1200:29:5391@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > In article <9102102022.AA26112@osiris.MIT.EDU> jis@MIT.EDU (Jeffrey I. Schiller) writes: > [ RFC 931 ] >> I wouldn't go so far as to say it makes mail a "secure" protocol. > > But it does---again, provided that TCP is made secure. > > I'm not convinced that this is such a problem. The Internet mail I send > rarely goes through more than three hops: nyu.edu, bar.com, foo.bar.com. > If sending organization and receiving organization support RFC 931, > that's enough. This is a rather parochial point of view. My site has over 1000 nodes which are not on the Internet, They get thier mail through various gateways and the use of 931 doesn't appear to do me a bit of good. And I'm hardly exclusive. There's BITNET, Usenet, HEPnet, SPAN, ATTmail, Compuserve, MCImail, and a nearly endless list of other mail systems which make 931 an impractical solution to the problem. I agree quite strongly that the only real way to do the job is with public key end to end encryption or with digital signatures (as appropriate). I admit that I'm still a bit unsure of how x.509 cetificates will be issued in "the real world", but that gets into philosophy and is not germain. I do think it's a bad idea to espouse a method because "it will be good enough for me". A real solution should be good enough for everyone. 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---- [%26%3F3G%26$rl@cs.psu.edu] <1991021221140900> From: ehrlich@cs.psu.edu (Dan Ehrlich) Newsgroups: comp.protocols.tcp-ip Subject: Using a Hayes modem for SLIP? Message-ID: <&?3G&$rl@cs.psu.edu> Date: 12 Feb 91 21:14:09 GMT Sender: news@cs.psu.edu (Usenet) Followup-To: sender Organization: Computer Science Department, Penn State University Lines: 15 Posted: Tue Feb 12 15:14:09 1991 Nntp-Posting-Host: colossus.cs.psu.edu (Please no flames. My boss is making me do this.) We need to run SLIP through a Hayes Smartmodem compatible from Packard-Bell. Does anyone know if this is possible? Does anyone have any suggestions for what the modem settings should look like? Is it even possible to do? Yes I realize it is painfully slow, but we are just trying for a proof of concept and do not really care to much about the performance. Thanks in advance. -- Dan Ehrlich - Sr. Systems Programmer - Penn State Computer Science /Voice: +1 814 863 1142/FAX: +1 814 865 3176 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BZS.91Feb12162042@world.std.com] <1991021221204200> From: bzs@world.std.com (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: Date: 12 Feb 91 21:20:42 GMT References: <9102110842.AA02908@holmenkollen.ifi.uio.no> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 41 In-Reply-To: enag@ifi.uio.no's message of 11 Feb 91 08:42:04 GMT Re: ack'd mail The hard cases, as has been pointed out, are very hard indeed. The easy cases, however, are quite easy. If we assume that these receipts, read and other returns are voluntary then they belong in the mail user interface. Perhaps the transport agents would be aware of these to the extent that avoiding loops and handling errors might be within its purview. So, we add a field like: Mail-Options: Reply-When-Read to request one and Mail-Options: Read-Reply To mark one. and the mail user agent is free to ignore it, send a reply, or even ask the person what to do at that point. Systems which sell as "secure" closed systems can assure that this will be handled in some specified manner. Systems which don't, don't. If it's popular then it probably will become fairly reliable, if not, then not. We can standardize a field and string for doing this sort of thing and just leave it to the implementors to decide how strictly to try to implement it. But, at least, we've provided one common way that the concept is expressed (mechanism, not policy.) The worst case is every mail subsystem builder deciding this is needed and doing it differently. -b -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD ----MESSAGE-END---- ----MESSAGE-BEGIN---- [NELSON.91Feb12135228@sun.clarkson.edu] <1991021221522800> From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: Date: 12 Feb 91 21:52:28 GMT References: <1991Feb9.190400.6078@Think.COM> <9102111926.AA09697@jessica.stanford.edu> Sender: @grape.ecs.clarkson.edu Reply-To: nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) Organization: Clarkson University, Potsdam NY Lines: 24 Posted: Tue Feb 12 15:52:28 1991 In-Reply-To: almquist@JESSICA.STANFORD.EDU's message of 11 Feb 91 19:26:29 GMT In article <9102111926.AA09697@jessica.stanford.edu> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes: IP networks are required to support 68 octet packets without network layer (IP) fragmentation (RFC 791 page 25). The Internet folklore that says that this number is 576 is erroneous. Every IP host must be able to receive (and reassemble if necessary) 576 octet datagrams (RFC 791 page 25). Historically (and arguably still today) it has been unwise to send larger datagrams to hosts on distant networks (even when the remote host was prepared to receive larger datagrams), since larger datagrams increase the likelihood that intermediate networks will perform fragmentation, causing degraded performance. Or worse. A few years ago a user at a certain unnamed milnet host was unable to FTP to a PC under my purview running KA9Q. I had set the PC's MTU to 1024. When I set the MTU down to 576, he had no troubles. Hopefully his software has been fixed by now, but I'll take the hit in efficiency rather than spend time answering questions. -- --russ I'm proud to be a humble Quaker. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb12.234608.14604@ccu.umanitoba.ca] <1991021223460800> From: mills@ccu.umanitoba.ca (Gary Mills) Newsgroups: comp.protocols.tcp-ip Subject: KEEPALIVE does not work Message-ID: <1991Feb12.234608.14604@ccu.umanitoba.ca> Date: 12 Feb 91 23:46:08 GMT Organization: University of Manitoba, Winnipeg, Canada Lines: 30 I attempted to modify a network daemon to enable `keepalive' on a TCP socket. A code fragment is included below, with my addition inside an ifdef. I removed the error returns to shorten this article. The code appears to work, but when I watch the packets with etherfind on another machine, I can't see the keepalive packets. Should they be visible? Did I miss something? Does SunOS 4.1 not suport keepalive? In case anyone wonders, the non-blocking i/o is disabled later in the code, after a select(). The TCP read is always interrupted by an alarm. Could this interfere with keepalive? I would like to use keepalive so my daemon can detect when the remote host breaks its TCP connection. On an idle connection, my daemon spends most of its time in the TCP read. sc = socket(AF_INET, SOCK_STREAM, 0); if (sc < 0) { } #ifdef UOFMCC if (setsockopt(sc, SOL_SOCKET, SO_KEEPALIVE, (char *)(n=1, &n), sizeof(n)) < 0) { } #endif if (ioctl(sc, FIONBIO, (char *)(n=1, &n)) < 0) { } if (connect(sc, (struct sockaddr *)&toaddr, sizeof(toaddr)) < 0) { if (errno != EINPROGRESS && errno != EWOULDBLOCK) { } } -- -Gary Mills- -Networking Group- -U of M Computer Services- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [ariel.666407312@tiger1] <1991021301083200> From: ariel@prime.com (Rob Ullmann) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: Date: 13 Feb 91 01:08:32 GMT References: <9102110842.AA02908@holmenkollen.ifi.uio.no> Lines: 15 Nntp-Posting-Host: tiger1 Hi, there is already a de facto standard for "certified mail". Include a header field Return-Receipt-To:
(the exact syntax identical to Reply-To:) You will get a delivery report from the mailer doing final delivery, if it supports receipts. If the user "reads" it with an interface that supports it, you will get a "read receipt". Rob Ullmann Prime Computer, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102130119.AA27161@copsw33.teradata.com] <1991021301193600> From: mbh@copsw33.UUCP (Marc Hasson) Newsgroups: comp.protocols.tcp-ip Subject: Tcp/Ip on Token-ring (VMEbus) Message-ID: <9102130119.AA27161@copsw33.teradata.com> Date: 13 Feb 91 01:19:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 Does anyone know of a vendor which manufactures Token-ring cards for a VMEbus machine? So far I've confirmed (verbally only) that Interphase and CMC both have intelligent Token-ring VMEbus cards but I'd really prefer a "dumb" card, if possible. A 6U form factor is a requirement. ANY leads appreciated, intelligent or dumb. :-) --Marc Hasson UUCP mail: suntzu!tdat!mbh@sun.com U.S. mail: Teradata 100 N. Sepulveda Blvd. El Segundo, Ca. 90245 Phones: 213-524-6062 (direct) 213-524-5000 (main) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.015310.27301@pa.dec.com] <1991021301531000> From: mogul@wrl.dec.com (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <1991Feb13.015310.27301@pa.dec.com> Date: 13 Feb 91 01:53:10 GMT References: <9102111926.AA09697@jessica.stanford.edu> <19910211212243.8.BARMAR@OCCAM.THINK.COM> Sender: news@pa.dec.com (News) Organization: DEC Western Research Lines: 33 In article <19910211212243.8.BARMAR@OCCAM.THINK.COM> barmar@THINK.COM (Barry Margolin) writes: > From: "Philip Almquist" > > IP networks are required to support 68 octet packets without network > layer (IP) fragmentation (RFC 791 page 25). The Internet folklore that > says that this number is 576 is erroneous. > >Thanks for the correction. However, it's reasonably safe to assume that >most media have an MTU of at least 512. I can't think of any that >don't, and I would be surprised if anyone invented a new medium with a >smaller MTU (the current direction is generally towards larger packet >sizes). RFC1191 ("Path MTU Discovery Protocol") lists all the MTUs I could track down when I was writing it. Several networks have MTU == 508, and in RFC1144, Van Jacobson points out that on low-speed links (like telephone lines) the use of too large an MTU may increase the delays encountered to the point where they become unpleasant. To quote: From the discussion in sec. 2, it seems desirable to limit the maximum packet size (MTU) on any line where there might be interactive traffic and multiple active connections (to maintain good interactive response between the different connections competing for the line). The obvious question is `how much does this hurt throughput?' It doesn't. However, when Chris Kent invented the old "use 576 if non-local" rule, he was attempting to avoid fragmentation-induced communication failure without unduly reducing throughput. 576 is a compromise; it is essentially an arbitrary number that was chosen because it seemed less arbitrary than any other choice. Until you can rely on PMTU Discovery, the 576-rule works pretty well, but it does not guarantee non-fragmentation. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102130158.AA04006@hal.cs.wisc.edu] <1991021301582600> From: tasman@CS.WISC.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP Urgent Pointer *Standard* Message-ID: <9102130158.AA04006@hal.cs.wisc.edu> Date: 13 Feb 91 01:58:26 GMT References: <1991Feb11.205402.12401@b11.ingr.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Ed Sale writes: > My question boils down to this: > > If a TCP segment is carrying just one byte of data, and that > one byte is urgent data, what value should the TCP header's > Urgent Pointer field contain, 0 or 1? (In a *STANDARD* TCP.) > > Also, in my experience with many TCP implementations, there is > apparently confusion about the value that the Urgent Pointer should > have, as they do not appear to all be setting this field the same way. > I guess even if I choose to implement *STANDARD* Urgent Pointer > processing I'm still not going to be able to converse effectively > with every TCP implementation out there :-(. A brief answer to Ed's question is that the Urgent Pointer field should contain 0. For a more detailed treatment of the philosophy and implementation of TCP Urgent, you may wish to read an article that I wrote last summer: Tasman, M., "Telnet Output Discard Processing," ConneXions: The Interoperability Report, Volume 4, No. 6, June 1990. A footnote to the article addresses the compatibility issue. Due to the specification confusion concerning TCP Urgent, some early implementations contained an "off by one" calculation error. Rather than alter the behavior of their TCP implementation, at least one supplier chose instead to compensate in the application programs. The preceding will make more sense if you read the article. Mitchell Tasman UW-Madison Computer Sciences Dept. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SPIDER.91Feb12220041@peano.zk3.dec.com] <1991021303004100> From: spider@peano.zk3.dec.com (Spider Boardman OSG/CSSE) Newsgroups: comp.protocols.tcp-ip,comp.os.vms Subject: Re: UCX and CDCnet problem Message-ID: Date: 13 Feb 91 03:00:41 GMT References: <12316.27ae98c0@ecs.umass.edu> Sender: news@decvax.dec.com.UUCP Followup-To: comp.protocols.tcp-ip Organization: DEC Open Systems Group Customer Service Lines: 20 In-reply-to: k2@bl.physik.tu-muenchen.de's message of 6 Feb 91 08:16:24 GMT In article k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes: >Our problem: >If somebody trys to connect from a CDCnet node to our VAX, the connection >sets up, but he get no prompt, until he/she types in a Break-character. >With some debugging, we found out, that the VAX doesn't respond immediately >with a login prompt, if the other side doesn't support the Terminal Type option >(as in CDCnet!). The prompt appears after some input, like a local >terminal. That dolt CDCnet isn't able to send a character at this stage, >only BREAK got it to send something! So there are two problems, >one side is UCX which barfs on a missing Terminal Type Option, >and CDCnet which isn't able to send at this stage. There is a patch available for this particular problem in UCX, which you should be able to get from your Customer Support Center (CSC). CDCnet I can't help you with. -- Spider Boardman spider@decvax.dec.com DEC OSG/CSSE ...!decvax!spider I don't speak for DEC, and vice versa. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5131@vela.acs.oakland.edu] <1991021306070600> From: srodawa@vela.acs.oakland.edu (Ron Srodawa) Newsgroups: comp.protocols.tcp-ip Subject: Re: have you compiled NCSA Telnet w/Turbo C? Keywords: Turbo C NCSA Telnet Message-ID: <5131@vela.acs.oakland.edu> Date: 13 Feb 91 06:07:06 GMT References: <1991Feb07.214707.16739@ecst.csuchico.edu> Reply-To: srodawa@vela.acs.oakland.edu (Ron Srodawa) Organization: Oakland University, Rochester MI Lines: 11 Brad Clements at Clarkston University has modified NCSA Telnet et al to be compilable both with Microsoft C and Borland Turbo C. He can't release the source to the current version right now, but I think there is still old source on their archives. As far as I know, NCSA never fit these changes back into their version. Ron. -- | Ronald J. Srodawa | Internet: srodawa@vela.secs.oakland.edu | | School of Engineering and CS | UUCP: srodawa@vela.UUCP | | Oakland University | Voice: (313) 370-2247 | | Rochester, Michigan 48309-4401 | | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.062435.23866@Think.COM] <1991021306243500> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP "manageability" ?!? Message-ID: <1991Feb13.062435.23866@Think.COM> Date: 13 Feb 91 06:24:35 GMT References: <1991Feb12.042501.6758@cec1.wustl.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article <1991Feb12.042501.6758@cec1.wustl.edu> brown@wucs1.wustl.edu (Mike Brown) writes: >My question is: Does any router vendor support configuration via SNMP? cisco routers appear to, although I haven't actually tried it. When you enable SNMP you can specify read-only or read-write on a per-community basis, and also specify an access list to restrict addresses from which each community name is valid. >If you think I am naive for using SNMP to configure network elements then >please let me know... It's still pretty early in the network management business, and many vendors are just starting to provide SNMP facilities. Some have jumped in feet first, while others are still unsure how it fits in. For instance, I don't think any Unix systems are yet shipping with SNMP support (luckily there are publically-available snmpd implementations, of various levels of quality). By the way, I've seen a couple of SNMP posts here recently. There is a mailing list snmp@nisc.psi.net on which SNMP is discussed; it includes both users and implementors. Send mail to snmp-request@nisc.psi.net to ask to be added. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.063759.24753@Think.COM] <1991021306375900> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb13.063759.24753@Think.COM> Date: 13 Feb 91 06:37:59 GMT References: <1991Feb8.203703.25654@zoo.toronto.edu> <1991Feb11.233102.24222@Think.COM> <85079@sgi.sgi.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 21 In article <85079@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >> 4.2BSD-based UDP implementations violate both these requirements. >(I'm assuming you mean 4.3BSD base UDP implementations, which follow the >rules you criticize, not 4.2 BSD.) No, I meant 4.2BSD, since that is the release whose default value of udpcksum is wrong. Since the latest release of SunOS has this default wrong, I assumed it is 4.2-based (but perhaps they changed the default in the process of porting 4.3 TCP/IP, due to another of their misguided ideas about backward-compatibility (the same misguidedness that causes them to continue to default the broadcast address wrong)). I'm not sure what the latest Ultrix does, but I think 3.5 had the wrong default. These are the only BSD-based systems I have access to (we've got an SGI box, but it won't let me login because it doesn't mount my home directory (I've never before used a Unix system that didn't say something like "can't access home directory, using /"). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.114436.29647@issun3.stc.nl] <1991021311443600> From: koelman@issun3.stc.nl (Ton Koelman) Newsgroups: comp.protocols.tcp-ip Subject: tcp/ip for the Mac Message-ID: <1991Feb13.114436.29647@issun3.stc.nl> Date: 13 Feb 91 11:44:36 GMT Organization: SHAPE Technical Centre, NL Lines: 5 Hello there, Can anyone recommend a tcp/ip implementation for a Mac II? Ton Koelman, SHAPE Technical Centre. The Hague (koelman@stc.nl) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [14569:Feb1315:15:4791@kramden.acf.nyu.edu] <1991021315154700> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <14569:Feb1315:15:4791@kramden.acf.nyu.edu> Date: 13 Feb 91 15:15:47 GMT References: <9102102022.AA26112@osiris.MIT.EDU> <28229:Feb1200:29:5391@kramden.acf.nyu.edu> <1991Feb12.135915.1@rogue.llnl.gov> Organization: IR Lines: 74 In article <1991Feb12.135915.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes: [ RFC 931 doesn't help him, and it doesn't help on any non-TCP/IP net ] > I do think it's a bad idea to espouse a method because "it will be good enough > for me". A real solution should be good enough for everyone. Dave Borman told me the same thing about RFC 1143. ``It isn't the only way to stop TELNET's option negotiation loops,'' he said (paraphrased), ``and I don't like its approach. So it must not become a standard.'' There's one missing step. Why does a solution have to be perfect for everyone? Why can't all solutions be published in parallel? People who like one solution will use it. People who like another will use that. I've never said that RFC 1143 is the *only* way to fix TELNET, and I'm not saying now that RFC 931 is the *only* way to improve mail security. RFC 931 would, however, prevent many---if not most---of the SMTP forgeries that go on now. So it is worthwhile for many Internet sites, even if not for LLNL or BITNET or the United States Postal Service. Below is a typescript of compiling, installing, and testing authd 3.01 on a Sun 4. Sure, RFC 931 is limited to the Internet. Sure, RFC 931 doesn't fix TCP's security holes. But it's a damn sight better than nothing, it's hellishly easy to get going, it helps Internet security for more than just mail, it will help CERT track network intruders, and I don't understand the mindset of anyone who would recommend that it *not* be installed. (For the people who don't get alt.sources, I've made authd 3.01, my sendmail and talk patches, and Nick Sayer's nntpd patches available for anonymous ftp from 128.122.128.22 in pub/hier/inet/rfc931. More coming.) ---Dan Script started on Wed Feb 13 10:05:04 1991 csh> make cc -g -o authd authd.c rm -f tcpuid ln authd tcpuid rm -f tcpuname ln authd tcpuname cc -g -c authuser.c cc -g -o test test.c authuser.o csh> ./INSTALL Each action will be printed before it is run. Press return to proceed. 1. Install authd, tcpuid, and tcpuname. ! install -c -g kmem -m 02755 authd /etc/authd: ! rm -f /etc/tcpuid; ln /etc/authd /etc/tcpuid: ! rm -f /etc/tcpuname; ln /etc/authd /etc/tcpuname: 2. Install the authuser library. ! install -c -m 0444 authuser.h /usr/include/authuser.h: ! ar rv /usr/lib/libauthuser.a authuser.o: r - authuser.o ! ranlib /usr/lib/libauthuser.a: ! chmod 644 /usr/lib/libauthuser.a: 3. Make the man pages available. ! install -c -m 0444 authuser.3 /usr/man/man3/authuser.3: ! install -c -m 0444 authd.8 /usr/man/man8/authd.8: ! install -c -m 0444 tcpuid.8 /usr/man/man8/tcpuid.8: ! install -c -m 0444 tcpuname.8 /usr/man/man8/tcpuname.8: 4. Make sure an auth port is in /etc/services. Let me glance at /etc/services for you... Okay, you have it already. Let's continue. 5. Enable auth in /etc/inetd.conf. Let me glance at /etc/inetd.conf for you... Okay, it's already there. That's it! csh> ./test system says host is 127.0.0.1 authuser says host is 127.0.0.1 system says username is root authd says username is root Everything looks okay to me. csh> exit csh> script done on Wed Feb 13 10:05:50 1991 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.160045.7947@eagle.lerc.nasa.gov] <1991021316004500> From: xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) Newsgroups: comp.protocols.ibm,comp.protocols.tcp-ip,alt.sys.sun Subject: RPC application programming Message-ID: <1991Feb13.160045.7947@eagle.lerc.nasa.gov> Date: 13 Feb 91 16:00:45 GMT Sender: news@eagle.lerc.nasa.gov Reply-To: xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) Organization: NASA/Lewis Research Center, Cleveland Lines: 15 In John Corbin's excellent book "The Art of Distributed Applications: Programming Techniques for Remote Procedure Calls", he hints that one can write multithreaded RPC (tcp not udp) applications. Perhaps I am dense, but I don't quite understand how this is done. In particular I am interested in providing an RPC type server on MVS, using IBM's RPC software. If anyone has any sample applications showing how one handles multithreads/streams using RPC please send me mail xxbja@csduts1.lerc.nasa.gov I will be glad to summarize any responses. By the way any other references on RPC programming would also be appreciated. -- Betty Jo Armstead SVERDRUP Technology Inc. 21000 Brookpark Rd.Ms 142-2 Nasa Lewis Research Center Cleveland Ohio 44135 From: xxbja@csduts1.lerc.nasa.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102131634.AA05042@ftp.com] <1991021316345100> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP code available? Message-ID: <9102131634.AA05042@ftp.com> Date: 13 Feb 91 16:34:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 7 PC/TCP as it presently ships (v2.05) includes an SNMP agent. I believe that current production WIN/PC from Wollongong also has one. I'm not sure that any other DOS SNMP agents exist. I believe that both the MIT and CMU freeware SNMP for Unix packages include an agent. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102131746.AA01796@phaedrus.psi.com] <1991021317465700> From: kolb@PHAEDRUS.PSI.COM Newsgroups: comp.protocols.tcp-ip Subject: Looking for Router and/or Terminal Server Vendors Message-ID: <9102131746.AA01796@phaedrus.psi.com> Date: 13 Feb 91 17:46:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 PSI is issuing an RFP for hardware and software to expand and enhance it's network and service offering in 1991 and 1992. Any router and/or terminal server vendor wishing to participate in this RFP program should contact me by 21 February 1991. Please send all electronic responses directly to me. Do *not* post them back to the tcp-ip mail list or the comp.protocols.tcp-ip news group. christopher kolb kolb@psi.com (703)620-6651 Performance Systems International, Inc. 11800 Sunrise Valley Drive, Suite 1100 Reston, Virginia, 22091 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [287@nic.cerf.net] <1991021318212700> From: sss@nic.cerf.net (Marlene M. Eckert) Newsgroups: comp.protocols.tcp-ip Subject: SLIP & FTP Message-ID: <287@nic.cerf.net> Date: 13 Feb 91 18:21:27 GMT Distribution: comp.protocols.tcp-ip Organization: CERFnet, La Jolla, CA Lines: 15 Hello. I need help from the experts... I have SLIP installed on a Sun3 under SunOS 4.1.1. We are having problems FTPing large files. FTP likes to hang up - usually in the same place in the file. I do set the file type to binary for binary file transfers. Any solutions or debugging hints will be most appreciated. Please e-mail your responses to me. I'll summarize for the net if there is interest... Thanks in advance. Michael Reznick Structured Systems & Software (3S) sss@cerf.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.103034@Valinor.Stanford.EDU] <1991021318303400> From: vaf@Valinor.Stanford.EDU (Vince Fuller) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP "manageability" ?!? Message-ID: <1991Feb13.103034@Valinor.Stanford.EDU> Date: 13 Feb 91 18:30:34 GMT References: <1991Feb12.042501.6758@cec1.wustl.edu> <1991Feb13.062435.23866@Think.COM> Sender: news@Neon.Stanford.EDU (USENET News System) Reply-To: vaf@Valinor.Stanford.EDU (Vince Fuller) Organization: Stanford University Networking Systems Lines: 19 In article <1991Feb13.062435.23866@Think.COM>, barmar@think.com (Barry Margolin) writes: |> It's still pretty early in the network management business, and many |> vendors are just starting to provide SNMP facilities. Some have jumped in |> feet first, while others are still unsure how it fits in. For instance, I |> don't think any Unix systems are yet shipping with SNMP support (luckily |> there are publically-available snmpd implementations, of various levels of |> quality). The last part of this paragraph is no longer true - at least one Unix vendor, DEC, is shipping an SNMP agent as a standard daemon on all current systems (as of at least Ultrix 4.1, possibly since Ultrix 4.0). --Vince ----MESSAGE-END---- ----MESSAGE-BEGIN---- [85285@sgi.sgi.com] <1991021318520100> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: RFC-1122 and 1123 Keywords: conformance bids Message-ID: <85285@sgi.sgi.com> Date: 13 Feb 91 18:52:01 GMT Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 52 In the discussion about UDP checksums, someone wrote to me: > I have no idea if [name censored] would reply to a bid that required RFC 1122 > conformance and claim conformance. They don't conform. As you might guess from my return address, I've no shortage of bids, RFQ's and RFP's that have either checklist items for "conforms to RFC 112[23]" or copies of the entire checklists from the RFCs. Not long ago, a room full of people concerned with such things sat down to determine the company's official answer. We started at the beginning, considering each SHOULD, MAY, CAN, WILL, WON'T, OUGHT, COULD, and ONLY-IDIOTS-WOULD-DO-OTHERWISE. We filled many hours with "gee, of course we do/don't/would/wouldn't do that, but let's check...see the code there ...but look...ok, add to the list for verification." After lots of this powerful fun, we paused to estimate when we'd be finished making the list and how long the list would be. The encouraging answer was that the list would be finished in only a few months and would be only a little bigger than the RFC's. We thought about the effort and considered the size of the existing bug lists for the areas covered by the RFCs. We individually compared the personal satisfaction to be gained from completing the list with other pursuits like making TCP/IP/FDDI run 30% faster. Then we considered the gain to our customers from having less fast, less feature-full, buggier but "conforming" implementations. The result is that we will make an honest effort to perpetually look through the RFCs for real and potential problems, and to add discovered or reported conflicts to the bug lists to be fixed with the other bugs. However, we won't claim conformance. We'll just provide the linage of our source. This decision did not make our sales people cry with joy. In other words, RFC-1122 and RFC-1123 are interesting reading, great guides for writing or fixing code, and wonderful tools for adjudicating blame among vendors. They are terrible conformance standards, at least at this non-military-standards sort of shop. I know the response many will have is that 27 gov. agencies and 63 industrial consortia are developing test facilities. Old and new experience with test suites such as SVVS and POSIX, to name only two, make me skeptical of that panacea. Are there different perspectives from others, outside the gov. agencies, consortia, etc who want to sell us and our customers their seals of approval? Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [626@deere.com] <1991021319280800> From: paulf@deere.com (Paul A. Fisher) Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc Subject: Tandem 6530 terminal emulator (tn6530?) Keywords: tandem 6530 terminal Message-ID: <626@deere.com> Date: 13 Feb 91 19:28:08 GMT Organization: Deere & Company, Moline, IL 61265 Lines: 19 We are looking for a product similar to tn3270, except it emulates a Tandem 6530 terminal instead of an IBM 3270 terminal. We now have TCP/IP running on our Tandems, but we don't have good terminal access across the network. We need to run this product on a Sun workstation (Sunview). We have heard that this product does exist, but so far we have found no leads. Any information or pointers would be very helpful. Thanks. -- Paul A. Fisher paulf@deere.com Deere Tech Services ...uunet!deere!paulf John Deere Road (309) 765-4547 Moline, Illinois 61265 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BARNETT.91Feb13143343@grymoire.crd.ge.com] <1991021319334300> From: barnett@grymoire.crd.ge.com (Bruce Barnett) Newsgroups: comp.protocols.tcp-ip Subject: How can I prevent wrong route queries to a default router? Message-ID: Date: 13 Feb 91 19:33:43 GMT Sender: news@crdgw1.crd.ge.com Reply-To: barnett@crdgw1.ge.com Organization: GE Corp. R & D, Schenectady, NY Lines: 10 We have a multi-homed host (doesn't route packets). On one side in the Internet. On the other side is an internal network that is not connected to the Internet. How can I prevent the host from querying the default router (to the internet) about unknown subnets on the internal networks? -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett ----MESSAGE-END---- ----MESSAGE-BEGIN---- [62720@bbn.BBN.COM] <1991021320262800> From: fkittred@bbn.com (Fletcher Kittredge) Newsgroups: comp.protocols.tcp-ip Subject: Re: RPC application programming Message-ID: <62720@bbn.BBN.COM> Date: 13 Feb 91 20:26:28 GMT References: <1991Feb13.160045.7947@eagle.lerc.nasa.gov> Sender: news@bbn.com Reply-To: fkittred@spca.bbn.com (Fletcher Kittredge) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 43 In article <1991Feb13.160045.7947@eagle.lerc.nasa.gov> xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) writes: >In John Corbin's excellent book "The Art of Distributed Applications: >Programming Techniques for Remote Procedure Calls", he hints that one >can write multithreaded RPC (tcp not udp) applications. Perhaps I am >dense, but I don't quite understand how this is done. In particular >I am interested in providing an RPC type server on MVS, using >IBM's RPC software. If anyone has any sample applications showing >how one handles multithreads/streams using RPC please send me mail > xxbja@csduts1.lerc.nasa.gov TCP is a protocol definition; support for multi-threaded programs is a operating system service (if the support is worthwhile). There is nothing about TCP that makes it possible to write multi-threaded applications. So your sense of the world is correct. In the distributed applications domain, multi-threaded programs are seen as a beneficial tool. The advantage of multi-threaded programs is that they offer a method of taking inherently asynchroneous processes and allow programmers to treat functional sections as synchroneous. Most current distributed bases provide thread support: mach, amoeba, OSF DCE, etc. Older distributed bases such as Sun O/S or VMS are planning to add (real) thread services in the future. >I will be glad to summarize any responses. By the way any other >references on RPC programming would also be appreciated. There are so many I don't know where to begin. "Distributed Systems" Ed. Sape Mullender, 1989, ACM Press is a start. All of the OSF DEC, Mach, ISIS, Camelot and Amoeba documentation is relevant. Of course, you need the Sun O/S documentation and XDR/RPC sources (available on uunet.u.net). >-- >Betty Jo Armstead SVERDRUP Technology Inc. >21000 Brookpark Rd.Ms 142-2 >Nasa Lewis Research Center >Cleveland Ohio 44135 From: xxbja@csduts1.lerc.nasa.gov Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [CHRIS.91Feb13165923@endgame.gsfc.nasa.gov] <1991021321592300> From: chris@endgame.gsfc.nasa.gov (Chris Shenton) Newsgroups: comp.protocols.tcp-ip Subject: traffic monitoring by net snooping Message-ID: Date: 13 Feb 91 21:59:23 GMT Sender: news@dftsrv.gsfc.nasa.gov Organization: none Lines: 16 I recently saw this clever program from Silicon Graphics which watches traffic (of a specified protocol, I think) on the ether, and draws lines connecting machine names -- kind of like a dynamic traffic mapper. They called it netsnoop or netlook or some such... I'd like to try writing something like this but need pointers to the TCP/IP calls. I assume I'd be interested in the packet level stuff, just reading the TO and FROM addresses from the ip headers... Any pointers? Thanks in advance. Mail and I'll summarize. -- chris@asylum.gsfc.nasa.gov, ...!uunet!asylum.gsfc.nasa.gov!chris, PITCH::CHRIS ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102132212.AA02668@leo.md.interlink.com] <1991021322123000> From: fab@md.interlink.com (Fred Bohle) Newsgroups: comp.protocols.tcp-ip Subject: sequence number bug Message-ID: <9102132212.AA02668@leo.md.interlink.com> Date: 13 Feb 91 22:12:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 17 Has anyone experienced a bug in any tcp implementation when the sequence number crosses xxxx0000? That is it gets stuck when the low order bits go to all zeros. A user has experienced this with another implementation and we want to know if others have seen this before. The other implementation is Lachmann, UTS, but I want to know if it has been seen with -this- one or with ---other--- implementations. Please reply if you have seen or heard of this bug in ---any--- implementation. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910213222818.739698@DOCKMASTER.NCSC.MIL] <1991021322280000> From: Sabo@DOCKMASTER.NCSC.MIL Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP comparison Message-ID: <910213222818.739698@DOCKMASTER.NCSC.MIL> Date: 13 Feb 91 22:28:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Yes, Datapro has completed a study of SNMP-based management stations and will soon release a report on SNMP-based agent. The SNMP manager report is often given away free of charge. Contact Jill Huntington-Lee at (800) DATAPRO ex 2444. L. Michael Sabo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6008@auspex.auspex.com] <1991021322495000> From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <6008@auspex.auspex.com> Date: 13 Feb 91 22:49:50 GMT References: <1991Feb11.233102.24222@Think.COM> <85079@sgi.sgi.com> <1991Feb13.063759.24753@Think.COM> Organization: Auspex Systems, Santa Clara Lines: 6 >Since the latest release of SunOS has this default wrong, I assumed it >is 4.2-based (but perhaps they changed the default in the process of >porting 4.3 TCP/IP, They did change the default; SunOS 4.0's networking is somewhere between 4.3BSD and 4.3-tahoe based, and 4.1's networking is closer to tahoe. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb13.231653.20211@spectrum.CMC.COM] <1991021323165300> From: lars@spectrum.CMC.COM (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP documents Message-ID: <1991Feb13.231653.20211@spectrum.CMC.COM> Date: 13 Feb 91 23:16:53 GMT References: <1991Feb6.172144.12605@nmt.edu> Organization: Rockwell CMC Lines: 26 In article <1991Feb6.172144.12605@nmt.edu> Ruth Milner (NRAO Array Operations Center) writes: >Where can I get some good documentation on SLIP? I have RFC1055, but it does >not state which of the actual protocols it uses (presumably because it can use >more than one). Now, I thought it used UDP in most implementations, and I'm >trying to convince someone that he's not getting much, if any, error correction >on his SLIP connections, but he wants actual written proof. He thinks it's >using TCP (as in "TCP/IP"), the same as Internet connections on Ethernet links. >I can't remember where I read (ages ago) that SLIP (generally) uses UDP; is >there such a beast? SLIP sits *UNDER* IP, and will carry any and all IP traffic that the router sends to the SLIP interface. The user executes the FTP client program. The FTP specification (RFC-959) will tell you that FTP uses two simultaneous TCP connections to do the work. It is possible to use a UDP based protocol to transfer files. Two examples of UDP based file transfer protocols are TFTP (RFC-783) and NFS. Be aware, however, that the error detection capabilites of SLIP are somewhat weaker than those of Ethernet (or HDLC). -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102150155.AA04233@ucbvax.Berkeley.EDU] <1991021400073900> From: gwilliam@SH.CS.NET (George Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: fax data over ip anyone? Message-ID: <9102150155.AA04233@ucbvax.Berkeley.EDU> Date: 14 Feb 91 00:07:39 GMT References: <90345.130709PECAMPBE@MTUS5.BITNET> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 More info would be appreciated. Thanks in advance. George Williams gwilliam@sh.cs.net - email (617) 873- 3395 - phone Date: 11 Dec 90 18:07:09 GMT From: ndsuvm1!mtus5!pecampbe@cunyvm.cuny.edu Subject: Re: fax data over ip anyone? In my TCP-IP software, there is an unused code segment to do fax transfers of some sort. Judging by the looks of it, I think it works through the mailer. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb14.043514.5729@Think.COM] <1991021404351400> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC-1122 and 1123 Keywords: conformance bids Message-ID: <1991Feb14.043514.5729@Think.COM> Date: 14 Feb 91 04:35:14 GMT References: <85285@sgi.sgi.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 33 In article <85285@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >As you might guess from my return address, I've no shortage of bids, RFQ's >and RFP's that have either checklist items for "conforms to RFC 112[23]" or >copies of the entire checklists from the RFCs. From my minimal experience with RFQ's (one big project about seven years ago), I don't think such items are a critical factor. An RFQ typically contains quite a few requirements for a facility, and it's rare that any vendor can meet all of them. For instance, a TCP/IP RFQ might specify conditions on performance, usability, and conformance to a standard. Some respondents will do better jobs than others on various pieces of the requirements; implementation A may conform to the standard completely, implementation B may have a more complete API, while implementation C may perform better. The customer will have to decide which aspects are more important, and decide among the respondents on this basis. A vendor should look upon host requirements RFCs as additional guidelines, and add them to their to-do lists. They must still reconcile these with the problems and suggestions from users, marketing requirements, etc., and prioritize the list. When responding to the RFQ, all you can do is hope that your strengths in other areas outweigh your deficiencies in others. Of course, if there *is* a vendor that meets all the requirements, you may be out of luck, but that's the nature of competitive bidding and the free market. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [36@cheops.UUCP] <1991021406472900> From: archx@cheops.UUCP (archx) Newsgroups: comp.protocols.tcp-ip,comp.unix.misc Subject: RCP Socket Usage Keywords: RCP Socket TCP/IP Message-ID: <36@cheops.UUCP> Date: 14 Feb 91 06:47:29 GMT Lines: 18 We are currently doing a port of NCSA telnet to 3+open sockets. Having heaps of trouble getting RCP to work. Can anybody help with a spec/RFC or whatever that might tell us how the internals of unix RCP works. RCP appears to call out on Socket 514, sends "login names" and "rcp -t destination filename" Then it closes Socket 514What happerns after this we don't know !! Any assistance greatly appreciated. Thanks in advance Arch Murphy EMAIL: archx@cheops.qld.tne.oz.au ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5455@s3.ireq.hydro.qc.ca] <1991021413321600> From: vaillan@ireq.hydro.qc.ca (Clement Vaillancourt) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subject: traffic monitoring by net snooping Message-ID: <5455@s3.ireq.hydro.qc.ca> Date: 14 Feb 91 13:32:16 GMT References: Sender: root@s3.ireq.hydro.qc.ca Organization: Hydro-Quebec Lines: 29 In article chris@endgame.gsfc.nasa.gov (Chris Shenton) writes: >I recently saw this clever program from Silicon Graphics which watches >traffic (of a specified protocol, I think) on the ether, and draws lines >connecting machine names -- kind of like a dynamic traffic mapper. They >called it netsnoop or netlook or some such... > >I'd like to try writing something like this but need pointers to the TCP/IP >calls. I assume I'd be interested in the packet level stuff, just reading >the TO and FROM addresses from the ip headers... Any pointers? I have the real NetVisualyzer package (including netsnoop, netlook, analyzer) running on an SGI workstation. It is a great package to watch networks in action. My SGI machine is the only SGI on this research campus watching the traffic of about 300 Suns... I had to buy the SGI workstation to be able to run this great package. I never found something as good for the money running on a Sun. I just don't understand why SGI don't port this package to Sun and sell it with a good profit? Again, a very good package to see and debug networks, no statistics or snmp in version 1.0 but I heard it is comming. Clem. -- Clement Vaillancourt, Analyste, | Institut de Recherche d'Hydro-Quebec Responsable du Reseau Ethernet | 1800 Montee Ste-Julie, Varennes (Analyst, Network Manager) | P. Quebec, Canada, J3X 1S1 vaillan@ireq.hydro.qc.ca |Tel:+1 514 652 8238 Fax:+1 514 652 8309 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb14.145713.5635@unipalm.uucp] <1991021414571300> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <1991Feb14.145713.5635@unipalm.uucp> Date: 14 Feb 91 14:57:13 GMT References: <9102110842.AA02908@holmenkollen.ifi.uio.no> Organization: Unipalm Ltd., Cambridge, England Lines: 12 have a simple way of sending 'registered' mail. I include in it a line If you recieve this, will you tell me? This enables me to determine that not only has the message got there, but also that a human the other end has actually understood it, and was sufficiently civilised to inform me of the fact. A very powerful protocol indeed! :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb14.150021.5723@unipalm.uucp] <1991021415002100> From: leo@unipalm.uucp (E.J. Leoni-Smith) Newsgroups: comp.protocols.tcp-ip Subject: Re: NS DP8390 ethernet chip Message-ID: <1991Feb14.150021.5723@unipalm.uucp> Date: 14 Feb 91 15:00:21 GMT References: <27b71bf9@omega.UUPC> Organization: Unipalm Ltd., Cambridge, England Lines: 14 ash@uupc.omega (Andrew Hardie) writes: >I seem to remember some months ago talk about problems (dropped packets?) >with the A and B versions of the DP8390 chip as fitted to the WD8003E. >I notice that the new boards have the DP8390C chip. Can someone remind >me what the problem was and whether it (and any others that may have >existed in the A and/or B versions) were fixed in the C revision. >Thanks >-- >Andrew Hardie ash@omega.uucp >London, England ukc!cctal!omega!ash Include me in your mailing lists too - Russ? James? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102141500.AA14166@nscultrix1.network.com] <1991021415004100> From: dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102141500.AA14166@nscultrix1.network.com> Date: 14 Feb 91 15:00:41 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 52 Mike Brown receintly asked (<1991Feb12.042501.6758@cec1.wustl.edu>) >I recently learned that a major U.S. router vendor defines SNMP management >as the ability to "monitor" their equipment via SNMP and not the >configuration of the equipment via SNMP. I believe that I understand >the security problems related to SNMP and why caution must be exercised >with the use of SNMP to configure network elements. I still believe that >SNMP can be an effective configuration mechanism in certain networks. > > >My question is: Does any router vendor support configuration via SNMP? > >If you think I am naive for using SNMP to configure network elements then >please let me know... > > Regards, > Mike Brown Corporate Telecommunications > Information Systems > One Bell Center, Rm 24-V-5 > Southwestern Bell Telephone Co. > St. Louis, MO 63101 > (314) 235-7863 I'm not speaking for Network Systems, but I do have a little information you can use as you will. In theory, SET allows a client to manipulate variables that could control router parameters. In fact, RFC 1157 (I think that's the right number) gives an example of using a "NumSecondsToReboot" variable to perform this kind of task, rather than having to implement a "Reboot" command in the agent. So the theoretical answer to your question is yes. However, there are a number of security issues here (I know that security isn't a popular topic with a lot of people, but I invite you to read Cliff Stoll's "The Cuckoo's Egg" before skoffing in my direction). People I talk to in development don't think that the community mechanism provides enough security, and say that developers in other companies feel the same. In any case, I havn't heard of anyone who lets you muck with their router configuration via SNMP. I hear that there's an SNMP Authentication RFC somewhere in the mill. Perhaps someone else can shed some light on that. As a practical solution for you, can't you use Telnet? Everyone supports it, and this way your door isn't COMPLETELY unlocked (just mostly unlocked). ----------------------------------------------------------------------------- Ted Doty | tel. +1 301 596-2270 Network Systems Corp. | voice mail (800) 233-1485 x4436 ted.doty@network.com | fax: +1 301 381 3320 ----------------------------------------------------------------------------- These views are my own, not Network Systems'. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Feb.14.10.17.51.1991.21090@remus.rutgers.edu] <1991021415175200> From: rauscher@remus.rutgers.edu (Trott ++) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP-IP for MAC Message-ID: Date: 14 Feb 91 15:17:52 GMT References: <2661@bdrc.bdrc.bd.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 36 >We are interested in finding a good tcp-ip system for Macintosh computers >using ethernet. Try a product called MacTCP. It's commercial, but it seems to be quickly becoming the standard for TCP/IP with Macintoshes. > We would like for the Macs to be NFS clients using a SUN >as an NFS server. Does it have to be NFS? There is a popular package call AUFS (Apple-Unix File Server) which allows you to mount Sun files on your Macintosh. Besides, if it were true NFS, you may run into problems with the differences between file formats of Macintosh and unix files( Mac files are split into data and resource forks, etc.). AUFS is part of a large package that allows your unix boxes and Macintosh to talk nicely. It is available via anonymous ftp to rutgers.edu. It is in src/ru-cap2.tar.Z. It is based on the Columbia Appletalk Protocol (CAP). Rutgers has been successfully running this for a couple years. > We also need mail running on the Macs that can send and >receive from SMTP. Thanks for any sugestions. We are particularly interested >in hearing from users who have successful systems running. A possible solution to this is POP Mail. (please refer to the rfc for it -- I don't know the number off the top of my head). In short, mail would be delivered to your unix box and sit there until your macintosh user asked for it (all done with some sort of nice interface). > Gene Jackson > jackson@bdrc.bd.com -Rich Rauscher ----MESSAGE-END---- ----MESSAGE-BEGIN---- [109@penril.UUCP] <1991021415590000> From: wayne@penril.UUCP (Wayne Chuu) Newsgroups: comp.protocols.tcp-ip Subject: Looking for Telnet Course Keywords: Telnet, Course Message-ID: <109@penril.UUCP> Date: 14 Feb 91 15:59:00 GMT Distribution: usa Lines: 13 I am desperately looking for some TELNET courses. Whoever knows such information, please let me know. Your help is appreciated. Wayne Chuu Please reply to one of the addresses below: uunet!penril!louis!wayne penril!louis!wayne@uunet.UU.NET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102141624.AA01275@telesys.ncsc.navy.mil] <1991021416242900> From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) Newsgroups: comp.protocols.tcp-ip Subject: Registered SMTP Message-ID: <9102141624.AA01275@telesys.ncsc.navy.mil> Date: 14 Feb 91 16:24:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 I dropped off a couple of messages supporting a "return receipt" registration feature for SMTP a while ago. In thinking about the issue some more, and reviewing people's worries about excess flurries of acknowledgements being generated by mailers along the line, it has occurred to me that the return message should not be part of SMTP but rather be part of the user's mail interface. The only thing that SMTP should support is some sort of header line that the mail application can use to determine whether or not a return message should be sent when the user displays (ok, we can't tell whether it's actually READ or not) the received message. I think this approach is more logical; SMTP almost certainly should not get involved in sending "I got it" messages anywhere on its own. Thoughts? BTW, I still think the capability is needed -- it just needs to be identified in the right category. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb14.170436.7587@tandem.com] <1991021417043600> From: kevinr@tandem.Tandem.COM (Kevin J. Rowett) Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc Subject: Re: Tandem 6530 terminal emulator (tn6530?) Keywords: tandem 6530 terminal Message-ID: <1991Feb14.170436.7587@tandem.com> Date: 14 Feb 91 17:04:36 GMT References: <626@deere.com> Sender: news@tandem.com Reply-To: kevinr@Tandem.COM Organization: Tandem Computers, Comm Development Lines: 10 Nntp-Posting-Host: moe.tandem.com In article <626@deere.com>, paulf@deere.com (Paul A. Fisher) writes: |> |> We are looking for a product similar to tn3270, except it emulates a Tandem |> 6530 terminal instead of an IBM 3270 terminal. We now have TCP/IP running on |> We have heard that this product does exist, but so far we have found no leads. One exists. It's called TN6530. It comes with the TCP/IP S/W you order from Tandem. kevinr@tandem.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [22030@hydra.gatech.EDU] <1991021418104000> From: ken@dali.gatech.edu (Ken Seefried iii) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP "manageability" ?!? Message-ID: <22030@hydra.gatech.EDU> Date: 14 Feb 91 18:10:40 GMT References: <1991Feb12.042501.6758@cec1.wustl.edu> <1991Feb13.062435.23866@Think.COM> <1991Feb13.103034@Valinor.Stanford.EDU> Sender: news@prism.gatech.EDU Reply-To: ken@dali.gatech.edu (Ken Seefried iii) Organization: The House Of Fun Lines: 13 Posted: Thu Feb 14 12:10:40 1991 In article <1991Feb13.103034@Valinor.Stanford.EDU> vaf@Valinor.Stanford.EDU (Vince Fuller) writes: > >The last part of this paragraph is no longer true - at least one Unix >vendor, DEC, is shipping an SNMP agent as a standard daemon on all >current systems (as of at least Ultrix 4.1, possibly since Ultrix 4.0). > IBM ships SNMP for AIX on the RS/6000's. -- ken seefried iii "Specialization is for insects." ken@dali.cc.gatech.edu - Robert A. Heinlein (1916-1988) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102141820.AA01941@hns.com] <1991021418204400> From: c_rstine@HNS.COM (Robert Stine) Newsgroups: comp.protocols.tcp-ip Subject: ioctl() and getsockopt() Message-ID: <9102141820.AA01941@hns.com> Date: 14 Feb 91 18:20:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Sorry if this is too BSD-centric, but is there a way to get the value of SO_SNDBUF and SO_RCVBUF by using ioctl(), instead of getsockopt()? If so, what are the ioctl commands? Thanks, Bob Stine (w) c_rstine@hns.com (h) bstine@MCIMail.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8968@sail.LABS.TEK.COM] <1991021418360900> From: russ@sail.LABS.TEK.COM (russ) Newsgroups: comp.protocols.tcp-ip Subject: PPP for bsdOS Keywords: PPP Message-ID: <8968@sail.LABS.TEK.COM> Date: 14 Feb 91 18:36:09 GMT Organization: Tektronix Inc., Beaverton, Or. Lines: 17 Posted: Thu Feb 14 10:36:09 1991 I've been attempting to bring up the PPP package on our sun3 running MtXinu MSD2.6. Reading the Jan 7 issue of UNIX Today gave an FTPable source for PPP on bsdOS - namely lancaster.andrew.cmu.edu Unfortunately the PPP.shar file that you get seems to be incomplete. logwtmp.c is missing. The kernel side of it is complete, and installed in our system already, but this module is missing for building the user level 'ppp' program. I haven't been able to get the needed module from the author, so I'm looking for other FTPable sites that have a PPP kit for bsdOS. Or if perchance one of you have this kit and can direct me to a copy of the needed module. I of course could write my own, but that would take longer than writing this letter. Any information would be helpful, but please don't direct me to omnigate or uunet for SunOS sources. Thanks heaps, -russ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102141933.AA13058@desktalk.desktalk.com] <1991021419332100> From: rlg@desktalk.com (Richard L. Gralnik) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102141933.AA13058@desktalk.desktalk.com> Date: 14 Feb 91 19:33:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Anyone care to take a shot at this one ? In the Host Requirements RFC (Section 4.2.3.8. Page 103) it says, "When a TCP connection is OPENed passively and a packet arrives with a completed IP Source Route option (containing a return route), TCP MUST save the return route and use it for all segments sent on this connection..." Ok, fine. But does this mean the passive end of the connection cannot issue a source route of its own? Note that the preceding paragraph of the RFC says "An application MUST be able to specify a source route when it actively opens a TCP connection, and this MUST take precedence over a source route received in a datagram." Where did this received source route come from if the passive end has to save a received return route (presumably received from the actively opened end) and 'use it for ALL segments sent on this connection' ? Thanks in advance, Richard Gralnik (rlg@desktalk.desktalk.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10304@ncar.ucar.edu] <1991021420152500> From: woods@ncar.ucar.edu (Greg Woods) Newsgroups: comp.protocols.tcp-ip Subject: third-party traceroute Message-ID: <10304@ncar.ucar.edu> Date: 14 Feb 91 20:15:25 GMT Reply-To: woods@ncar.UCAR.EDU (Greg Woods) Organization: Scientific Computing Division/NCAR, Boulder CO Lines: 6 Posted: Thu Feb 14 14:15:25 1991 I have heard that there is a third-party version of "traceroute" available (third-party traceroute means the ability to find out how a packet travels from point A to point B when you are at neither point A nor point B). Is this true, and if so, where can I obtain it? --Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2027@lot.ACA.MCC.COM] <1991021423221600> From: ables@lot.ACA.MCC.COM (King Ables) Newsgroups: comp.protocols.tcp-ip Subject: rudp Message-ID: <2027@lot.ACA.MCC.COM> Date: 14 Feb 91 23:22:16 GMT Distribution: usa Organization: MCC ACT Program, Austin, TX Lines: 10 Can someone give me a pointer to info about rudp? I hear it's a reliable implementation of UDP developed at Berkeley, but that's all I know... a pointer to an ftpable paper or something would be appreciated. Thanks. ----------------------------------------------------------------------------- King Ables Micro Electronics and Computer Technology Corp. ables@mcc.com 3500 W. Balcones Center Drive +1 512 338 3749 Austin, TX 78759 ----------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.000414.5199@javelin.es.com] <1991021500041400> From: lwallace@javelin.es.com (Lynn Wallace) Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards Subject: How to get remote ethernet address? Keywords: ethernet address remote Message-ID: <1991Feb15.000414.5199@javelin.es.com> Date: 15 Feb 91 00:04:14 GMT Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah Lines: 16 We use dedicated ethernet connections between machines, meaning a machine on each end of a cable with no other connections. The system I am writing (or attempting to :-) a driver for will be connected to various machines, sometimes "right off the assembly line". Is there a way to obtain the remote's ethernet address (vs. internet address; it's a low-level protocol) from software so the user doesn't have to flip through a manual, eyeball a card or peek memory to get it? Reply via e-mail please, as I don't usually follow these groups. Thanks! -- Lynn Wallace |I am not an official representative of Evans and Sutherland Computer Corp.| <- E&S. Or for that matter, unofficial. Salt Lake City, UT 84108 |Internet: lwallace@javelin.sim.es.com War not make one great! -- Yoda ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7109.27bba3a9@cc.curtin.edu.au] <1991021501023300> From: Murray_RJ@cc.curtin.edu.au (Ron Murray) Newsgroups: comp.protocols.tcp-ip Subject: PPP Documentation wanted Message-ID: <7109.27bba3a9@cc.curtin.edu.au> Date: 15 Feb 91 01:02:33 GMT Organization: Curtin University of Technology Lines: 16 I'd like to get the specs for PPP. RFC number (if any) or other help would be appreciated. Thanks, ....Ron -- =============================================================================== Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.065610.1371@ncsu.edu] <1991021506561000> From: dbjoyner@eos.ncsu.edu (David Joyner) Newsgroups: comp.protocols.tcp-ip Subject: Re: traffic monitoring by net snooping Keywords: Promiscuous ethernet Message-ID: <1991Feb15.065610.1371@ncsu.edu> Date: 15 Feb 91 06:56:10 GMT References: Sender: news@ncsu.edu (USENET News System) Reply-To: dbjoyner@eos.ncsu.edu (David Joyner) Organization: North Carolina State University Lines: 28 In article , chris@endgame.gsfc.nasa.gov (Chris Shenton) writes: > I recently saw this clever program from Silicon Graphics which watches > traffic (of a specified protocol, I think) on the ether, and draws lines > connecting machine names -- kind of like a dynamic traffic mapper. They > called it netsnoop or netlook or some such... > > I'd like to try writing something like this but need pointers to the TCP/IP > calls. I assume I'd be interested in the packet level stuff, just reading > the TO and FROM addresses from the ip headers... Any pointers? > > Thanks in advance. Mail and I'll summarize. > I am also interested in this subject. I do know that it is possible to put an ethernet adapter into "promiscuous mode" where it receives all packets on the network. I do not know exactly how this is done (I think via ioctl calls) or where the packets are queued/stored by the ethernet adapter. This doesn't exactly seem like the best newsgroup for information on ethernet, but what is??? +===========================================================================+ | David B. Joyner (dbjoyner@eos.ncsu.edu) | North Carolina State University | +---------------------------------------------------------------------------+ | "Typically supercomputers use a single microprocessor." -Boston Globe | +===========================================================================+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [ENAG.91Feb15091403@holmenkollen.ifi.uio.no] <1991021508141600> From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: Date: 15 Feb 91 08:14:16 GMT References: <9102111542.AA18194@telesys.ncsc.navy.mil> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 104 In-Reply-To: mark@TELESYS.NCSC.NAVY.MIL's message of 11 Feb 91 15:42:47 GMT > Erik Naggum, Naggum Software, Oslo, Norway, offered a thoughtful > rebuttal to the idea of certified/registered mailers. However, I > believe that his arguments overlook several issues: Let me try to reply to the overlooked issues. > 1) Many organizations do use registered mail, or some other feedback > mechanism, to verify that deliveries have been made. The absence > of comparable mechanisms in SMTP is perceived as a shortcoming > that must be tolerated, at best. The postal service is paid to deliver your mail. When you buy the service of registered mail, the postal service is required by law to deliver it and record the delivery in a way which you can rely on, legally. You can request return receipts from the postal service as well, and the postal service has a big problem if you don't get a return receipt when the letter was received. There is no one who can assume this responsibility in the Internet. Thus, the "shortcoming" stems from the nature of the service provider involved, and SMTP reflects this. > 2) Many non-SMTP mail systems, especially those running on PCs and > LANs, offer registered mail capabilities, making the absence of > those capabilities in SMTP more obvious and irritating than they > might be otherwise. I've seen systems which do this, but they are in no way legally binding, which registered mail is in its postal implementation they try to mimic. In particular, you can't guarantee that non-delivery of a delivery notification is equivalent to non-delivery of the message, which I spent some time indicating. The other problem is that a confirmed delivery may not be equivalent to confirmed receipt by the intended recipient: the recipient may have elected to "share" his account with somebody else, the mail reading program may have crashed before he had a chance to read the message, he only read the header of your message and accidentally deleted it, he used the editor to read his mailbox and deleted it before any mail reader had a chance to send a delivery notification back. The list goes on. None of these apply to postal registered mail, because the recipient actually has to sign a form which agrees that he has received it, and the person requesting such signature may also request proof that the signer is the intended recipient. Another technicality is that the intended recipient may refuse to accept the letter. Also, registered mail is returned to the sender if the recipient has not been able to receive it within a certain time. To successfully mimic the registered mail option of postal services, a whole new system has to be implemented wherein some special recipient on the target system receives the message, sends a message to the intended recipient informing him of the message, with a copy of the envelope and possibly headers, whereupon the intended recipient has to submit a privacy-enhanced request to receive it, which is construed to be evidence that the message has been received and presumably read by the intended recipient. Some amount of authentication and confirmable action to receive the message is needed. > 3) The ACK/NAK problem can be as troublesome on LANs as it would be > on the Internet. The fact that LANs supporting registered mail > schemes do not typically collapse due to ACK/NAK cascades > indicates that the real world can cope with mail registration > successfully. True, they can. All major protocols also cope with the Three Armies problem, but I've come across unilaterally hung X.25 connections so often that I believe it's a real problem. TCP connections time out after too many retries, but retries is a central part of it all. The question remains that in the absence of confirmable delivery and a confirmed delivery notification, should the sender resubmit the message until such is received? Of course, often it will work, but it's the cases where it doesn't that you really need the services of registered mail. > 4) E-mail is certainly not the only means of communications > available to most Internet users. The lack of a receipt notice > usually prompts our users to call the intended recipient to alert > him/her to the presence of the mail. This feedback opportunity > can assist network administrators in identifying the existence of > network problems if, for instance, the mail was never received. Exactly right! Therefore, since it's intractable to solve the problem of registered mail in the Internet, the services of the telephone, the telefax, and the postal registered mail may be used with more success than that with which we may try to implement registered mail in the Internet. With the advent of Privacy Enhanced Mail, I think we will attain a higher level of certainty with respect to authenticity, but the problem of confirmed delivery remains to be solved. As I alluded to above, a registered mail daemon using PEM may be a viable solution where PEM is available. > Registered mail is certainly no panacea for assuring effective > communications. It can, however, provide important information for > users and is in appreciable demand in some environments. I don't disagree with this, I just think it's technically infeasable at the moment and will remain so for a long time. Especially as long as we don't have a contractual agreement between service provider and service user as to the delivery status of mail. Personally, I call people, or ask them to call me when an important issue has to be resolved. This invariably works well. -- [Erik Naggum] Naggum Software, Oslo, Norway ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.130700.10552@linus.mitre.org] <1991021513070000> From: jfjr@mbunix.mitre.org (Freedman) Newsgroups: comp.protocols.tcp-ip Subject: Re: traffic monitoring by net snooping Keywords: Promiscuous ethernet Message-ID: <1991Feb15.130700.10552@linus.mitre.org> Date: 15 Feb 91 13:07:00 GMT References: <1991Feb15.065610.1371@ncsu.edu> Sender: news@linus.mitre.org (News Service) Organization: The MITRE Corp., Bedford MA Lines: 22 Posted: Fri Feb 15 07:07:00 1991 Nntp-Posting-Host: mbunix.mitre.org In article <1991Feb15.065610.1371@ncsu.edu> dbjoyner@eos.ncsu.edu (David Joyner) writes: >In article , >chris@endgame.gsfc.nasa.gov (Chris Shenton) writes: >> I recently saw this clever program from Silicon Graphics which watches >> traffic (of a specified protocol, I think) on the ether, and draws lines >> connecting machine names -- kind of like a dynamic traffic mapper. They >> called it netsnoop or netlook or some such... >> >> I'd like to try writing something like this but need pointers to the TCP/IP >> calls. I assume I'd be interested in the packet level stuff, just reading >> the TO and FROM addresses from the ip headers... Any pointers? >> >> Thanks in advance. Mail and I'll summarize. >> > I too am interested in any kind of ethernet snooping with a Unix preferably BSD flavor machine - promiscuousness (sp?) is right up my alley. Jerry Freedman,Jr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102151447.AA01609@ucbvax.Berkeley.EDU] <1991021514473500> From: NELSON@MSU.BITNET ("Doug.Nelson") Newsgroups: comp.protocols.tcp-ip Subject: Re: Problem with WIN/TCP's secure FTP Message-ID: <9102151447.AA01609@ucbvax.Berkeley.EDU> Date: 15 Feb 91 14:47:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 20 X-Unparsable-Date: Tuesday, 12 February 1991 12:24pm ET From Merton Campbell Crockett: > The copy of RFC959 that I have indicates that a command is a "TELNET string" > and that the command verb is terminated by a space. It also states that > command arguments or parameters are separated by one or more spaces. I didn > find any explicit comments on trailing spaces. Leading spaces, on the other > hand, are addressed and permitted. > > While one might argue that Wollongong's construction of the command is shodd > the NOS/VE and IRIS command parsers err in not being "robust". I'll (gladly) stand corrected. I had looked for any reference to multiple spaces, and read right over the sentence that says it (in section 5.3) at least twice. Now that I see that, I would say that such a command should be treated as giving a null pathname, which is equivalent to the default. I was originally going to make the same statement about the NOS/VE and IRIS implementations, but without the "or more" clause there, they would have been correct. Doug ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102151539.AA16457@ftp.com] <1991021515393700> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: NS DP8390 ethernet chip Message-ID: <9102151539.AA16457@ftp.com> Date: 15 Feb 91 15:39:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 12 I would have sent this privately, but I didn't feel any real optimism about the return address given... The worst problem that early DP8390 LAN chips had was a tendency to glitch their byte-order control register, and change byte-orders in the middle of a packet. A bit destructive to one's data, that. The C chips are better than the A and B, but I think E or F is current these days. You have to get the old errata sheets for full details, since the newer ones only list problems found since C or so. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4046@stl.stc.co.uk] <1991021516172000> From: scott@stl.stc.co.uk (Mike Scott) Newsgroups: comp.protocols.tcp-ip,comp.lang.c,comp.lang.c++,comp.os.os2.misc,comp.os.os2.programmer Subject: problem using ftp's pc/tcp with zortech C Keywords: pc/tcp zortech Message-ID: <4046@stl.stc.co.uk> Date: 15 Feb 91 16:17:20 GMT Sender: news@stl.stc.co.uk Reply-To: "Mike Scott" Organization: STC Technology Limited, London Road, Harlow, Essex, UK Lines: 24 References: We recently purchased pc/tcp for os/2 intending to use it in conjunction with the zortech c/c++ compiler. What the advertising literature (and salesman) failed to mention was that using the supplied pc/tcp libraries with anything other than microsoft C isn't supported - and indeed it won't work with the zortech system :-(. The distributors in the UK (Unipalm) have been somewhat unhelpful (they did offer us a refund though!) Has anyone tried using this combination and got it to work? We need help urgently as success of a project depends on it! (I should add that the implementation is very complete, and the supplied utilities - ftp(d), routed, telnet(d), etc) seem to work well.) -- Regards. Mike Scott STL, London Road, Harlow, Essex CM17 9NA, UK scott@stl.stc.co.uk ...uunet!mcsun!ukc!stl!scott PSI%234237100122::SCOTT phone +44-279-429531 xtn 3133. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102151632.AA18674@monk.proteon.com] <1991021516210000> From: axw@RELAY.PROTEON.COM Newsgroups: comp.protocols.tcp-ip Subject: re: SNMP Authentication Message-ID: <9102151632.AA18674@monk.proteon.com> Date: 15 Feb 91 16:21:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Proteon, Inc., Westborough, MA 01581 [(508)898-2800] Lines: 31 Ted Doty commented about SNMP authentication: > However, there are a number of security issues here (I know > that security isn't a popular topic with a lot of people, > but I invite you to read Cliff Stoll's "The Cuckoo's Egg" > before skoffing in my direction). People I talk to in > development don't think that the community mechanism > provides enough security, and say that developers in other > companies feel the same. In any case, I havn't heard of > anyone who lets you muck with their router configuration > via SNMP. > I hear that there's an SNMP Authentication RFC somewhere in > the mill. Perhaps someone else can shed some light on > that. > As a practical solution for you, can't you use Telnet? > Everyone supports it, and this way your door isn't > COMPLETELY unlocked (just mostly unlocked). It's interesting that SNMP authentication is considered too weak, while telnet authentication is strong enough. SNMP and telnet protocols both authenticate with ASCII plaintext passwords. telnet authentication appears stronger since it's harder to read a password on a typical host computer. But once you get an analyzer on the network, there's no difference! Asher Waldfogel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.163253.20951@sunee.waterloo.edu] <1991021516325300> From: erick@sunee.waterloo.edu (Erick Engelke) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP comparison Message-ID: <1991Feb15.163253.20951@sunee.waterloo.edu> Date: 15 Feb 91 16:32:53 GMT References: <910213222818.739698@DOCKMASTER.NCSC.MIL> Organization: University of Waterloo Lines: 15 In article <910213222818.739698@DOCKMASTER.NCSC.MIL> Sabo@DOCKMASTER.NCSC.MIL writes: >Yes, Datapro has completed a study of SNMP-based management stations and >will soon release a report on SNMP-based agent. The SNMP manager report >is often given away free of charge. Contact Jill Huntington-Lee at >(800) DATAPRO ex 2444. > A non-800 number or E-mail address would be nice for non US sites. Erick -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Network Watstar Network Guy University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15173@uudell.dell.com] <1991021517523000> From: mjhammel@Kepler.dell.com (Michael J. Hammel) Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: what cards supported with Netwatch? Message-ID: <15173@uudell.dell.com> Date: 15 Feb 91 17:52:30 GMT Sender: news@uudell.dell.com Reply-To: mjhammel@Kepler.dell.com (Michael J. Hammel) Followup-To: comp.protocols.tcp-ip.ibmpc Organization: Dell Computer Corp. Lines: 15 I fetched both the sources and binaries for Netwatch (the latter from windom.ucar.edu). The binaries seem to work but don't seem to be seeing any traffic. I ran custom and set the IP address and ethernet address (good thing I had the docs from MIT's source distribution, its not plainly obvious the ethernet value has to be in octal!). I'm using a wd8003E. Is this card not supported by Netwatch? I couldn't find any reference as to what cards it does support? My I/O, base memory, and IRQ values have all been set correctly too (280, d0000, and 5). Any ideas out there? Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [390@dwerger.UUCP] <1991021518230400> From: jeff@dwerger.UUCP (Jeffrey E. Finucane) Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix.sco Subject: Blocking read() using SCO Xenix 2.3.2 and Racal/Interlan NP621-386 Keywords: blocking read xenix racal interlan Message-ID: <390@dwerger.UUCP> Date: 15 Feb 91 18:23:04 GMT Reply-To: jeff@dwerger.UUCP (Jeffrey E. Finucane) Followup-To: comp.protocols.tcp-ip Organization: Custom Tailored Systems, Inc. Lines: 15 I open a tcp socket using Racal's socket library and later do a read on that socket. I expect the read to block indefinitely, but after a few minutes, the read returns leaving errno == ECONNRESET. The other end of the socket is not being manipulated -- that program is awaiting user input. Is this poor behavior or am I missing somthing? Has anyone else experienced this? Thanks, Jeff -- Jeffrey E. Finucane Custom Tailored Systems nshore!dwerger!jeff Data Phone: (216) 935-2712 Telebit Trailblazer Voice: (216) 935-0252 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [529@trux.UUCP] <1991021518345000> From: car@trux.UUCP (Chris Rende) Newsgroups: comp.protocols.tcp-ip Subject: Testing if a host is up Message-ID: <529@trux.UUCP> Date: 15 Feb 91 18:34:50 GMT Organization: Central Cartage, Sterling Hgts., MI Lines: 31 I have a shell script which does a FTP of a file over to another host. I need a way to put a test ahead of the FTP that will determine whether or not the other host is "up". Here is what I have so far: -------------------------------------------------------------------- # hostup - Written 01/30/91 by Chris Rende # Last change: 01/30/91 by Chris Rende x=`ping HOST 56 1 | fgrep packets | cut -c24` if [ $x = 0 ]; then echo "HOST is down" exit 1 fi echo "HOST is up" exit 0 -------------------------------------------------------------------- Is there a better way? (I.e., more robust, less kludgy). C program(s) welcome. car. -- Christopher A. Rende Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3) uunet!edsews!rphroy!trux!car Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1 trux!car@uunet.uu.net Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF trux!ramecs!car "I don't ever remember forgetting anything." - Chris Rende ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102151947.AA02094@europa.clearpoint.com] <1991021519470200> From: kasten@europa.clearpoint.COM (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Are There Standards For Secure Mail Transfer Via SMTP? Message-ID: <9102151947.AA02094@europa.clearpoint.com> Date: 15 Feb 91 19:47:02 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 > From tcp-ip-RELAY@NIC.DDN.MIL Fri Feb 15 01:02:31 1991 > From: portal!cup.portal.com!Will@apple.com (Will E Estes) > Organization: The Portal System (TM) > Subject: Are There Standards For Secure Mail Transfer Via SMTP? > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > Can someone briefly discuss any standards that might exist, or be > in the process of development, for the sending of secure mail via > SMTP or via the Internet. Also, are there any relevant RFCs on > this topic? > > Thanks, > Will Estes (apple!cup.portal.com!Will) > Will, Try the following RFC's Frank Kastenholz Clearpoint Research ------- 1115 Linn, J. Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers [Draft]. 1989 August; 8 p. (Format: TXT=18226 bytes) 1114 Kent, S.T.; Linn, J. Privacy enhancement for Internet electronic mail: Part II - certificate-based key management [Draft]. 1989 August; 25 p. (Format: TXT=69661 bytes) 1113 Linn, J. Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures [Draft]. 1989 August; 34 p. (Format: TXT=89293 bytes) (Obsoletes RFC 989, RFC 1040) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102152000.AA02102@europa.clearpoint.com] <1991021520003400> From: kasten@europa.clearpoint.COM (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102152000.AA02102@europa.clearpoint.com> Date: 15 Feb 91 20:00:34 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 > > [stuff deleted about sucrity in SNMP, sets, and the like] > > I hear that there's an SNMP Authentication RFC somewhere in the mill. > Perhaps someone else can shed some light on that. > There are four documents under development by the SNMP security working group. They are currently available as INTERNET-DRAFTS. The names are: draft-ietf-snmpauth-authsnmp-02.txt draft-ietf-snmpauth-communities-01.txt draft-ietf-snmpauth-manageobject-02.txt draft-ietf-snmpauth-uu-00.txt These documents describe three schemes for SNMP security: 1 - trivial -- the current scheme 2 - authenticated -- provides assurance that the SNMP PDU came from who it purports to come from and that it has not been tampered with along the way, and 3 - Private -- like authenticated, but is also encrypted so as to provide privacy. Every effort is being made to complete these documents as soon as possible and have them sent up to the IAB for publication as an RFC with "Proposed Standard" status. There is some expectation that this will be accomplished at the next IETF meeting (in about a month). Cheers Frank Kastenholz Clearpoint Research Corp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1117@sppy00.UUCP] <1991021520035400> From: rah@sppy00.UUCP (MOORE ROBIN) Newsgroups: comp.protocols.tcp-ip Subject: Telnet and CR/LF Keywords: return linefeed Message-ID: <1117@sppy00.UUCP> Date: 15 Feb 91 20:03:54 GMT Distribution: na Organization: Online Computer Library Center, Dublin, Ohio. Lines: 41 Can anyone help me understand this problem, and hopefully correct it? We have an application running on an IBM 3090, which is accessed via IBM's Telnet server software. The application typically outputs an entire 24 x 80 screen of data at a time. Occasionally, a line of text towards the bottom of the screen will write over the previous line. The problem has been experienced running a Telnet client from both Pyramid and Sun 3 systems. Placing a LAN analyzer on the net, we have determined two things; I'm not sure if both of them pertain to the problem, or just the second one. 1) It appears that the IBM Telnet software is changing every occurance of CR LF in the output into the sequence CR NUL CR LF. Reading over RFC 854, it sounds like it would not be unusual to convert CR LF to CR NUL, but including both seems strange. Perhaps this is because the IBM typically negotiates the terminal type of the connection down to the simplest, line-by-line type terminal available? 2) The problem of the overwritten line is seen when segmentation of the message occurs between the 2nd CR and the LF. In other words: First packet: ... Text_of_line_x CR NUL CR Second packet: LF Text_of_line_y CR NUL CR LF ... Line y is overwritten by line x. Should IBM's software be refusing to split the message between these characters? This seems unlikely, since I would expect the act of segmentation to be done in the Transport layer by TCP. On the other hand, are the Pyramid and Sun Telnet clients both faulty in their handling of the CR LF when it crosses message boundaries? Thanks in advance for your assistance, Robin -- { % Robin A. Hermance-Moore OCLC Inc. } { %%% %%% %% %%%%% sppy00!rah@cis.ohio-state.edu <== 1st 6565 Frantz Road } { % % % % % % OR: rah@rsch.oclc.org <== 2nd Dublin, OH 43017 } { % % % % % % OCLC => "Services for Libraries" (614) 764-6215 } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BOGAART.91Feb15151217@lager.serc.nl] <1991021520121700> From: bogaart@lager.serc.nl (Eugene Bogaart) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP over X25 Message-ID: Date: 15 Feb 91 20:12:17 GMT Sender: bogaart@serc.nl Distribution: comp.protocols.tcp-ip, comp.sys.dec, comp.sys.sun, comp.sys.hp Organization: SERC Lines: 36 I am wondering if there are sofware products which can route tcp/ip into X.25 package over an asynchronous communication port (RS232C or like wise) following the RFC 877 standard. Several questions: Are there any products which function known. I am particularly interested in software for DEC/Ultrix, SunOS, HP9000 architectures ? What is the maximum speed that is supported by such a product ? Most kernels donot support very high speeds. Ultrix for instance does not allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates ! Descriptions of actual working configurations are of my interest. Am I not interested in machine independent hardware solution such as a Cisco box. Thanks, Eugene Bogaart -- Name: Eugene Bogaart | Software Engineering Research Centre Email: bogaart@serc.nl | Lange Viestraat 365 3511 BK Utrecht Phone: +31 30 32 26 40 | P.box 424 3500 AK Utrecht Fax: +31 30 34 12 49 | The Netherlands --------------------------------------------------------------- Home phone:+31 838051889 | De Wiek 93, 6712 JC Ede ----MESSAGE-END---- ----MESSAGE-BEGIN---- [85756@sgi.sgi.com] <1991021520404800> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subject: traffic monitoring by net snooping Message-ID: <85756@sgi.sgi.com> Date: 15 Feb 91 20:40:48 GMT References: <5455@s3.ireq.hydro.qc.ca> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 20 In article <5455@s3.ireq.hydro.qc.ca>, vaillan@ireq.hydro.qc.ca (Clement Vaillancourt) writes: > ...[very nice, kind words deleted]... > > I just don't understand why SGI don't port this package to Sun and sell it > with a good profit? The software business is much harder to survive than the hardware business. It is particularly difficult to start doing software only products in a hardware company. It would very difficult to convince the majority of this company to support a port to compeating hardware. Trying to keep up with and properly filter network traffic from an Ethernet or FDDI MAC in promiscuous mode requires substantial support below the application. Such support, if present, is not currently likely to be sufficiently similar on products from hardware vendors. Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6988@bgsuvax.UUCP] <1991021521161000> From: rama@bgsuvax.UUCP (Sub Ramakrishnan) Newsgroups: comp.protocols.tcp-ip Subject: How to find directory of rpc services? Keywords: rpc, portmapper, client, server Message-ID: <6988@bgsuvax.UUCP> Date: 15 Feb 91 21:16:10 GMT Distribution: na Organization: Bowling Green State University B.G., Oh. Lines: 17 I have a question for those SUN rpc gurus. Background: The portmapper daemon (on port # 111) helps clients find server programs. Servers register their services with the portmapper. The client call goes to port # 111; portmapper returns the port # of the server in its reply message. The client can then sends rpc messages to this port #. Question: How does a client find the "directory" of services (service name, port # and a description) offered on a machine. The client knows neither the name nor the server port #. Two ways that I don't like: (1). The client can exhaustively poll all possible port #s. (2) Read /etc/services file; does'nt give you services that "come & go". I am looking for ways to find the services at run time. Much appreciated. sub ramakrishnan rama@truth.bgsu.edu Voice: 419 372 2337 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.230522.18764@Think.COM] <1991021523052200> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Configuration via SNMP Message-ID: <1991Feb15.230522.18764@Think.COM> Date: 15 Feb 91 23:05:22 GMT References: <9102141500.AA14166@nscultrix1.network.com> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 19 In article <9102141500.AA14166@nscultrix1.network.com> dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) writes: > In any case, I havn't heard of anyone who lets you muck >with their router configuration via SNMP. I believe cisco routers support this. When enabling SNMP, you can specify which communities are allowed read-write access. Further, you may specify an access list, which restricts which hosts may send SNMP commands using a particular community name. I think Cabletron repeaters and bridges can also be configured using SNMP. I don't know what kind of access control they use. Their non-SNMP remote configuration software (Remote LanView) requests a password, but I think it is only used to authenticate the user locally by the PC running the management software, not between the PC and the network devices. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102152346.AA04371@ganges.ucop.edu] <1991021523460300> From: spgdrp@GANGES.UCOP.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: third-party traceroute Message-ID: <9102152346.AA04371@ganges.ucop.edu> Date: 15 Feb 91 23:46:03 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 I have heard that there is a third-party version of "traceroute" available (third-party traceroute means the ability to find out how a packet travels from point A to point B when you are at neither point A nor point B). Is this true, and if so, where can I obtain it? There is a public domain version of traceroute posted on zerkalo.harvard.edu. I don't know if this is the canonical source. You should know that this program requires modifying your kernel. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb15.235715.21152@Think.COM] <1991021523571500> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP over X25 Message-ID: <1991Feb15.235715.21152@Think.COM> Date: 15 Feb 91 23:57:15 GMT References: Sender: news@Think.COM Distribution: comp.protocols.tcp-ip, comp.sys.dec, comp.sys.sun, comp.sys.hp Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article bogaart@lager.serc.nl (Eugene Bogaart) writes: >I am wondering if there are sofware products which can route tcp/ip >into X.25 package over an asynchronous communication port (RS232C or >like wise) following the RFC 877 standard. > >Several questions: > >Are there any products which function known. I am particularly >interested in software for DEC/Ultrix, SunOS, HP9000 architectures ? SunLink X.25 implements RFC877 for SunOS. The manual mentions one minor difference between its implementation and the RFC, though. Rather than creating and clearing X.25 virtual circuits dynamically, they must be created and cleared explicitly by using the x25enable and x25disable commands. >What is the maximum speed that is supported by such a product ? Most >kernels donot support very high speeds. Ultrix for instance does not >allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates ! According to the manual, 19.2Kbps is the maximum speed using the CPU board serial ports, but you can go up to 64Kbps using an MCP or SCP. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [183342.17950@timbuk.cray.com] <1991021601033000> From: bstrand@poplar13.cray.com (Brad Strand) Newsgroups: comp.protocols.tcp-ip Subject: Re: How to find directory of rpc services? Keywords: rpc, portmapper, client, server Message-ID: <183342.17950@timbuk.cray.com> Date: 16 Feb 91 01:03:30 GMT References: <6988@bgsuvax.UUCP> Distribution: na Organization: Cray Research, Inc., Eagan, MN Lines: 24 In article <6988@bgsuvax.UUCP> rama@bgsuvax.UUCP (Sub Ramakrishnan) writes: > >Question: How does a client find the "directory" of services >(service name, port # and a description) offered on a machine. >The client knows neither the name nor the server port #. >Two ways that I don't like: >(1). The client can exhaustively poll all possible port #s. >(2) Read /etc/services file; does'nt give you services that "come & go". >I am looking for ways to find the services at run time. Use "pmap_getmaps()". It takes a pointer to a sockaddr_in structure for the remote host, and returns a pointer to a pmaplist structure. If you've got source for rpcinfo, look how that program does it. >Much appreciated. >sub ramakrishnan rama@truth.bgsu.edu Voice: 419 372 2337 BDS -- Brad Strand bstrand@cray.com (DOMAIN) uunet!cray!bstrand (UUCP) Cray Research, Inc. Networking and Communications Development 655F Lone Oak Drive #include Eagan, MN 55121 "No gnu taxes." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb16.014841.10155@pa.dec.com] <1991021601484100> From: mogul@wrl.dec.com (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subject: traffic monitoring by net snooping Message-ID: <1991Feb16.014841.10155@pa.dec.com> Date: 16 Feb 91 01:48:41 GMT References: <5455@s3.ireq.hydro.qc.ca> <85756@sgi.sgi.com> Sender: news@pa.dec.com (News) Organization: DEC Western Research Lines: 28 In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >Trying to keep up with and properly filter network traffic from an Ethernet >or FDDI MAC in promiscuous mode requires substantial support below the >application. Such support, if present, is not currently likely to be >sufficiently similar on products from hardware vendors. I've ported a number of such programs, and (if the program structure is at all modular) it turns out to be pretty easy to get a program (e.g., tcpdump, nfswatch, statspy) to run on the following systems: Ultrix + Ultrix packet filter SunOs + NIT 4.xBSD + new "Berkeley Packet Filter" (BPF) and possibly the IBM RT using the modified Stanford packet filter done by some folks at Merit. True, all of these facilities have evolved from the same base (even NIT seems to be based on the Stanford packet filter), but that base did not support promiscuous mode, and all those evolved versions do. Admittedly, it becomes a little trickier if your application does fancy filtering, since the filter languages are slightly different (the BPF language is entirely different). However, most statistical network monitors (as opposed to a trace-program such as tcpdump) general want to see all (or almost all) the packets, so filtering isn't an issue. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [Abj_H6W00WBw45Mkpt@andrew.cmu.edu] <1991021603193400> From: dd26+@andrew.cmu.edu (Douglas F. DeJulio) Newsgroups: comp.protocols.tcp-ip Subject: Re: Registered SMTP Message-ID: Date: 16 Feb 91 03:19:34 GMT References: <9102141624.AA01275@telesys.ncsc.navy.mil> Organization: Chemistry, Carnegie Mellon, Pittsburgh, PA Lines: 14 In-Reply-To: <9102141624.AA01275@telesys.ncsc.navy.mil> mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) writes: > In thinking about the issue some more, and reviewing people's worries > about excess flurries of acknowledgements being generated by mailers > along the line, it has occurred to me that the return message should > not be part of SMTP but rather be part of the user's mail interface. Two mail interfaces that currently provide this feature are the Andrew Message System and NeXT Mail. Both provide multimedia mail as well. AMS is somewhat better IMHO (and I think it's free), but you need the Andrew Tool Kit to get the multimedia features. -- Doug DeJulio ddj@zardoz.club.cc.cmu.edu (NeXT) dd26+@andrew.cmu.edu (AMS/ATK) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb16.041439.1038@Think.COM] <1991021604143900> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Testing if a host is up Message-ID: <1991Feb16.041439.1038@Think.COM> Date: 16 Feb 91 04:14:39 GMT References: <529@trux.UUCP> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 18 In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >I need a way to put a test ahead of the FTP that will determine whether >or not the other host is "up". >Here is what I have so far: ># hostup - Written 01/30/91 by Chris Rende [Script omitted] Except for the exact text of the message printed, the ping command does exactly what your shell script does. It returns 0 status if the host is up, and non-zero when the host is down. This is on SunOS 4.0.3. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [EMV.91Feb16014229@poe.aa.ox.com] <1991021606422900> From: emv@ox.com (Ed Vielmetti) Newsgroups: comp.protocols.tcp-ip Subject: Re: Testing if a host is up Message-ID: Date: 16 Feb 91 06:42:29 GMT References: <529@trux.UUCP> Sender: usenet@ox.com (Usenet News Administrator) Organization: OTA Limited Partnership, Ann Arbor MI. Lines: 22 Posted: Sat Feb 16 00:42:29 1991 In-Reply-To: car@trux.UUCP's message of 15 Feb 91 18:34:50 GMT In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes: I have a shell script which does a FTP of a file over to another host. I need a way to put a test ahead of the FTP that will determine whether or not the other host is "up". Just an observation -- just because a host answers pings doesn't necessarily mean it's up. Consider that it might be in single user mode doing backups, with the network interface up but no inetd services running and the partition you want to FTP to unmounted. Not to say that noticing that a few pings don't come back isn't a good idea, but it's not sufficient to guarantee service availability. Depending on your application, it might be enough. --Ed -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102160656.AA05349@holmenkollen.ifi.uio.no] <1991021606562800> From: enag@IFI.UIO.NO (Erik Naggum, the Internet Purist) Newsgroups: comp.protocols.tcp-ip Subject: Re: Registered SMTP Message-ID: <9102160656.AA05349@holmenkollen.ifi.uio.no> Date: 16 Feb 91 06:56:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 In article <9102141624.AA01275@telesys.ncsc.navy.mil>, Mark L. Williams writes: > I dropped off a couple of messages supporting a "return receipt" > registration feature for SMTP a while ago. In thinking about the > issue some more, and reviewing people's worries about excess > flurries of acknowledgements being generated by mailers along the > line, it has occurred to me that the return message should not be > part of SMTP but rather be part of the user's mail interface. The > only thing that SMTP should support is some sort of header line that > the mail application can use to determine whether or not a return > message should be sent when the user displays (ok, we can't tell > whether it's actually READ or not) the received message. I think > this approach is more logical; SMTP almost certainly should not get > involved in sending "I got it" messages anywhere on its own. Mark, SMTP is a protocol. Simple Mail Transfer Protocol. It's not a piece of software. It can't do anything on its own. Neither, might I add, has there ever been any discussion of adding some feature to SMTP to make it do anything differently. You seem to ignore the problems that relate to the semantics of a return receipt, and that this semantics is not supported by the network technology (model) involved. For instance, the "excess acknowledgements" is a real problem, not because you implement it at some layer N, but because ACKs may not get to their intended recipient. That has nothing whatsoever to do with which layer or which program or whatever actually does the ACK'ing. -- [Erik Naggum] Naggum Software, Oslo, Norway ----MESSAGE-END---- ----MESSAGE-BEGIN---- [666690965.417931.VANCE@TGV.COM] <1991021607560500> From: VANCE@TGV.COM (Icarus) Newsgroups: comp.protocols.tcp-ip Subject: Re: DNS on VAX and TCP/IP on OS/2? Message-ID: <666690965.417931.VANCE@TGV.COM> Date: 16 Feb 91 07:56:05 GMT References: <9102151245.AA00895@frodo.jdssc.dca.mil> Sender: daemon@ucbvax.BERKELEY.EDU Organization: TGV, Incorporated Lines: 36 > This is *damn* embarassing, but I just got a request for information >regarding the availability of DNS server software on VAXen -- I *know* I saw >something about this within the last couple of days, but since I wasn't >interested in the topic at the time (I thought we had solved all of our DNS >problems), I didn't keep a copy of the information. > > Could someone refresh my memory as to what is available on VAXen for DNS >server software? Mind you, it will have to interoperate with Suns (3, 4, & >386i) running various versions of the OS (4.0.1 through 4.1.1), and PCs running >3Com Ether+ software & (probably) cc:mail (hmmm... Kind of sounds like we need >to start our own mailing list for those of us that have VAXen, Suns, and PCs >with cc:mail and having to make them interact -- Let me know what you think of >this idea), etc.... I'm assuming from your comments later in the message that you mean VAXen running VMS. Several IP for VMS vendors ship with ports of the 4.3 BSD BIND DNS server, including: Company Product ------- ------- TGV MultiNet Wollongong WIN/TCP Network Research Fusion CMU CMU/Tek I think that CMU/Tek either now has or soon will have (Bruce, am I lying?) a BIND server. I know the others do. If you need contacts at any of the above, I can forward them to you. I think that you'll find that most of the vendors who have ported BIND will state that they are "bug-compatible" with the 4.3 BSD UNIX version. This should make the versions interoperate with any other implementation that is bug-compatible. Regards, -----Stuart ----MESSAGE-END---- ----MESSAGE-BEGIN---- [.666699528@dutepp0] <1991021610184800> From: etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot) Newsgroups: comp.protocols.tcp-ip Subject: Free Ethernet Snooper !!! Summary: Free Ethernet Snooper NetCapt at dutepp0.et.tudelft.nl Keywords: ethernet spy Message-ID: <.666699528@dutepp0> Date: 16 Feb 91 10:18:48 GMT Sender: news@duteca Lines: 21 Hi, We, at the Technical University Delft in the Netherlands have developed an ethernet snooper NetCapt. You can get is free with anonymous FTP from: dutepp0.et.tudelft.nl in pub/NetCapt Documentation is very sparce, but you can ask questions to JPMvOorschot@et.tudelft.nl We're developing a new version with SNMP support. If anyone wants to be beta-site, let me know. Greetings Jan JPMvOorschot@et.tudelft.nl ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1091@pemcom.pem-stuttgart.de] <1991021611220800> From: basien@pemcom.pem-stuttgart.de (Tillman Basien) Newsgroups: comp.unix.questions,comp.unix.msdos,comp.protocols.nfs,comp.protocols.tcp-ip,comp.unix.xenix.sco,comp.unix.sysv386 Subject: Is the a Source of a DOS-Telnet Message-ID: <1091@pemcom.pem-stuttgart.de> Date: 16 Feb 91 11:22:08 GMT Followup-To: comp.unix.questions Organization: PEM Stuttgart Lines: 11 I want to write my own telnet under PC-NFS, because I need a PC-TERM-Emulation. There a severel steps: What must I do in C to get a TCP/IP connection under PC-NFS to my hosts? Does anybody has an example software ? Thanks for every response Tillmann ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102161206.AA01453@goodall] <1991021612060500> From: doug@goodall.UUCP (Douglas Wade Goodall) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102161206.AA01453@goodall> Date: 16 Feb 91 12:06:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Regarding Token Ring for VME Bus In the latest VMEbus Systems magazine, two vendors were mentioned, INTERPHASE with their V/TOKEN-RING 4212OWL and SBE with their Model VCOM-33 ( 415-680-7722) Good Luck. Regards from Petaluma, California. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7002@rsiatl.Dixie.Com] <1991021703421500> From: jgd@Dixie.Com (John G. DeArmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: Free Ethernet Snooper !!! Keywords: ethernet spy Message-ID: <7002@rsiatl.Dixie.Com> Date: 17 Feb 91 03:42:15 GMT References: <.666699528@dutepp0> Organization: Rapid Deployment Systems (making go-fast things and things that-go fast) Lines: 21 etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot) writes: >an ethernet snooper NetCapt. You can get is free with anonymous FTP from: > dutepp0.et.tudelft.nl >in > pub/NetCapt Hi Jan, Thanks for the software. It is ftp'ing even as I type. One small correction. I found the file in /pub/NetCure/NetCapt.zip. This will make it a bit easier for those who have to use ftp servers. John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19047@paperboy.OSF.ORG] <1991021704391400> From: vijay@nixdorf2.osf.org (Vijay Kumar) Newsgroups: comp.protocols.tcp-ip Subject: Thinnet, Thicknet Keywords: Thinnet, Thicknet, Ethernet, Message-ID: <19047@paperboy.OSF.ORG> Date: 17 Feb 91 04:39:14 GMT Sender: news@OSF.ORG Reply-To: vijay@nixdorf2.osf.org (Vijay Kumar) Organization: OSF Lines: 9 Posted: Sat Feb 16 22:39:14 1991 Hi, Can someone tell me the difference between Thinnet and Thicknet. I would also like to know the advantages and disadvantages of one against another. Thanks in advance. Vijay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [.666786602@dutepp0] <1991021710300200> From: etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot) Newsgroups: comp.protocols.tcp-ip Subject: NetCure, Free Ethernet Snooper, more Keywords: NetCure ethernet snooper Message-ID: <.666786602@dutepp0> Date: 17 Feb 91 10:30:02 GMT Sender: news@duteca Lines: 44 Hi, I have quit a few reactions on my posting about our free Ethernet Snooper developed at the Technical University Delft in the Netherlands. My first posting did have some bugs in it, so here i go again: NetCure is a PC based ethernet snooper that reports about traffic, packet distributions, packet-types, and a top-ten list of hosts. FurtherMore, it has a seperate packet dumper plus a packet displayer with a protocol formatter. The NetCure package uses packet-device drivers to handle the network hardware, so you will need a packet-driver for your ethernet card ! After loading your packet driver, you can run one of the network components NetMon (monitoring), NetCapt (dumping), and NetView (packet viewing). The package is full-screen, with lots of fancy windows, but the documentation is lacking, so hackers-only ! You can get the package from dutepp0.et.tudelft.nl with anonymous ftp, it is in the directory NetCure and consists of a number of ".zip" files: ReadMe : very sparce docu netcapt.zip : dumping and viewing netmon.zip : monitoring pkt7com.zip : packet driver distribution, : just to be complete ! Unpack the files netcapt.zip and netmon.zip in one directory, load your packet-driver and run netmon.exe. The rest should be clear (;-) ) Jan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910217125307.00002A27@MARVIN.CTSS.CO.UK] <1991021712530700> From: VERKADE@CTSS.CO.UK (Herman Verkade) Newsgroups: comp.unix.misc,comp.protocols.tcp-ip,comp.windows.x Subject: Advise needed Message-ID: <910217125307.00002A27@MARVIN.CTSS.CO.UK> Date: 17 Feb 91 12:53:07 GMT Followup-To: poster Organization: CompuThoughts Software Solutions (UK) Ltd. Lines: 17 I am thinking of changing my old IBM-clone to a Unix machine, since I never use it with it's current MS-DOS. It's a 286 system with a Herculus-compatible graphics card, 640K main memory and an 80Mb Seagate hard disk. I would like to run some form of Unix, TCP/IP over Ethernet and SLIP, X windows, GCC, GC++ and news. Could some kind people answer one or more of the following questions: 1) What Unix should I go for? 2) What sort of Ethernet board should I go for? 3) Can I run X windows on the Hercules board? (If not I'll only use it as a client). 4) If TCP/IP doesn't come with the Unix, where do I get it from? 5) Do I need more memory? 6) Is the machine actually up to anything of the above? Please, reply by e-mail. Thanks in advance ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1917@fallst.UUCP] <1991021713093700> From: tkevans@fallst.UUCP (Tim Evans) Newsgroups: comp.protocols.tcp-ip Subject: Re: Testing if a host is up Message-ID: <1917@fallst.UUCP> Date: 17 Feb 91 13:09:37 GMT References: <529@trux.UUCP> Organization: Fallston, MD Lines: 20 In emv@ox.com (Ed Vielmetti) writes: >In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes: > I need a way to put a test ahead of the FTP that will determine whether > or not the other host is "up". >Just an observation -- just because a host answers pings doesn't >necessarily mean it's up. Assuming you have appropriate /etc/hosts.equiv and/or .rhosts set up, you could 'rsh' something like /bin/echo on the remote: if rsh remote [ -l user ] /bin/echo > /dev/null then whatever fi -- UUCP: {rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans INTERNET: tkevans%fallst@wb3ffv.ampr.org Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb17.163237.17152@informatik.uni-erlangen.de] <1991021716323700> From: eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP over X25 Message-ID: <1991Feb17.163237.17152@informatik.uni-erlangen.de> Date: 17 Feb 91 16:32:37 GMT References: <1991Feb15.235715.21152@Think.COM> Distribution: comp.protocols.tcp-ip, comp.sys.dec, comp.sys.sun, comp.sys.hp Organization: CSD., University of Erlangen, Germany Lines: 39 From article <1991Feb15.235715.21152@Think.COM>, by barmar@think.com (Barry Margolin): - SunLink X.25 implements RFC877 for SunOS. The manual mentions one minor - difference between its implementation and the RFC, though. Rather than - creating and clearing X.25 virtual circuits dynamically, they must be - created and cleared explicitly by using the x25enable and x25disable - commands. - ->What is the maximum speed that is supported by such a product ? Most ->kernels donot support very high speeds. Ultrix for instance does not ->allow 19Kb or higher. Sun and HP do allow 19Kb transfer rates ! - - According to the manual, 19.2Kbps is the maximum speed using the CPU board - serial ports, but you can go up to 64Kbps using an MCP or SCP. Real life experience: Sun3/50: 9.6kbps, Sun3/xx(other than 3/50): 19.2kbps, Sun4/xxx: 64kbps - all over CPU ports. MCP ports 64kbps each, HSI 2Mbps. The timing for asynchronuous operation is normally irrelevant for HDLC, as the clock will normally be generated by the modem. Even if generated by the Sun itself, the timing does not depend on the usual baud rate table for the asynchronuous interfaces, so it's no problem running the interfaces at higher speeds. The real problem is overrun, as all the CPU board serial interfaces generate one interrupt for every 'character' (i.e: 8 bit), so that's why a 3/50 can only achieve 9.600kbps. If you try something higher, you'll get massive problems with HDLC RESETS, as the interface looses interrupts and the HDLC link will constantly reset. On the other hand, the MCP board is (in my opinion) quite useless as the guaranteed linkrate is only 64kbps, which you can aesily achieve with the CPU ports of every sparc (except those cripled IPC's, if you don't start soldering on the CPU board for the clock lines ;-)). --- Toerless.Eckert@informatik.uni-erlangen.de /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless "unsupported configuration", "user misunderstanding", "not a bug, but a feature" -- hotlines of the world unite -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2091:Feb1722:50:4991@kramden.acf.nyu.edu] <1991021722504900> From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Testing if a host is up Message-ID: <2091:Feb1722:50:4991@kramden.acf.nyu.edu> Date: 17 Feb 91 22:50:49 GMT References: <529@trux.UUCP> <1917@fallst.UUCP> Organization: IR Lines: 10 Posted: Sun Feb 17 16:50:49 1991 In article <1917@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes: > Assuming you have appropriate /etc/hosts.equiv and/or .rhosts set up, > you could 'rsh' something like /bin/echo on the remote: That still wouldn't prove that ftp is available. What's wrong with simply connecting to the service in question and seeing whether it responds? ---Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1176@tesla.njit.edu] <1991021809155300> From: njl5453@tesla.njit.edu Newsgroups: comp.protocols.tcp-ip Subject: ===>> Seeking help with MICROCONTROLLERS................... Message-ID: <1176@tesla.njit.edu> Date: 18 Feb 91 09:15:53 GMT Organization: New Jersey Institute of Technology Lines: 23 any body familiar with MICROCONTROLLERS. following: Motorola MC68HC11 Intel 386 also, available LCDs. if yes, i need info on its operations and cost, etc... please give me your e-mail address at: nitin@mars.njit.edu i am undergrad senior at New Jersey Institute of Technology Newark, NJ. I am working on Senior project which requires designing of device using the Single Chip Computers. Thank you in advance.. -nitin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [853@volvo.vd.volvo.se] <1991021812481500> From: martin@vd.volvo.se (Martin B|rjesson) Newsgroups: comp.protocols.tcp-ip Subject: Commercial 3270 emulator?? Message-ID: <853@volvo.vd.volvo.se> Date: 18 Feb 91 12:48:15 GMT Reply-To: martin@volvo.se (Martin B|rjesson) Organization: Volvo Data AB Lines: 16 I'm looking for good 3270 (i.e. 3179 or someting similar) emulators, for use with Suns, HPs, RS/6000 and Decstations in one end and IBM's TCP/IP running on the MVS end. GDDM and color support is a must. We prefer commercial products. Thanks in advance! /martin -- &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Martin Borjesson, |Snail Mail: |E-mail: martin@[cae.]volvo.se Volvo Data |405 08, Goteborg |Phone: (46) 31 667182 (work) Dept 2610, Geogr: DLI |Sweden | (46) 31 233409 (home) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102181435.AA05874@nscultrix1.network.com] <1991021814352000> From: dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102181435.AA05874@nscultrix1.network.com> Date: 18 Feb 91 14:35:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 Erik Naggum raises a host of interesting points in his comparison of email to the postal service's registered/certified mail. I tend to support his conclusion that "registered" email will be a long time comming, but for social, rather than technical reasons. While I'm not a lawyer, my understanding of the legal status of email is that it does not have any of the protections accorded to paper (Post Office) mail. While it is a crime for the post office to tamper with your letters, there appears to be nothing preventing any mail relay from reading/modifying/deleting your mail at will. A recent case against Epson America, where an employee was fired (and frogmarched out of the building by the police, no less!) for objecting to Epson's policy of reading employee's email, was dismissed because it Epson has not violated either the Electronic Communications Privacy Act or California wiretaping statutes. The judge ruled flat out that wiretaping does not apply to email. (Note that a similar suit has been files against Nissan USA). So what does this mean (rather than don't buy Epson or Nissan products)? Email appears to have absolutely no legal protections, or any standing in a court of law (don't tell me about Ollie North - that was no court, that was the congress). I would suggest that email providers will not venture into this field until the LEGAL status of email is established. Imagine the liability of (for example) MCI if they offer a "Certified" email that can be manhandled by any system administrator on the net ... This may be a case of a solvable (eventually) *technical* problem but an insoluable social one. ------------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Rd./Suite 250 | fax: +1 301 381-3320 Columbia, MD 21046 USA | voice mail: (800) 233-1485 ------------------------------------------------------------------------------- "These views are my own, and do not necessarially represent those of Network Systems Corporation" "The first thing we do, it to kill all the lawyers." -Wm. Shakespeare ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851@nddsun1.sps.mot.com] <1991021815243100> From: markm@nddsun1.sps.mot.com (Mark Monninger) Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc Subject: Re: Tandem 6530 terminal emulator (tn6530?) Keywords: tandem 6530 terminal Message-ID: <851@nddsun1.sps.mot.com> Date: 18 Feb 91 15:24:31 GMT References: <626@deere.com> <1991Feb14.170436.7587@tandem.com> Followup-To: comp.protocols.tcp-ip Organization: Motorola, Inc., Semiconductor Products Sector Lines: 21 In article <1991Feb14.170436.7587@tandem.com> kevinr@Tandem.COM writes: >In article <626@deere.com>, paulf@deere.com (Paul A. Fisher) writes: >|> >|> We are looking for a product similar to tn3270, except it emulates a Tandem >|> 6530 terminal instead of an IBM 3270 terminal. We now have TCP/IP running on >|> We have heard that this product does exist, but so far we have found no leads. > >One exists. It's called TN6530. It comes with the TCP/IP S/W you order from >Tandem. > >kevinr@tandem.com That's true, but it's only the server. The original release included a TN6530 client for the Sun workstation. How about a TN6530 client for DOS machines? Seems like that would be a helluva lot more useful to most people than a Sun version, esp. since the PC's with Tandem's name on them are DOS machines. I understand that there are TN6530 clients for Mac's and even an X-Windows version but so far I haven't heard of a DOS version. If anyone knows of one, please let me know. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102181526.AA06447@nscultrix1.network.com] <1991021815265100> From: dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) Newsgroups: comp.protocols.tcp-ip Subject: Re: Compressed Video Transport Requirements Message-ID: <9102181526.AA06447@nscultrix1.network.com> Date: 18 Feb 91 15:26:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 I think that there are two problems with *REAL TIME* video: variation of delay and synchronization. If the delay between packets varries too much, the picture would jump (like the strobe lights at your old disco parties) like crazy, causing Excedrin headache #423. if you have synchronization problems (voice and video arriving out of sync), it looks like a badly dubbed movie (remember the Hercules skitt on Saturday Night Live?). Either way you irritate the users. Note that ethernet doesn't look good for problem #1. Maybe nothing is (FDDI II? Now how much would you pay ...). I think these problems are not so severe if you're not going real-time. I don't have references about video, but I do have some performance modeling results of FDDI synchronous token stuff. Send me your U.S. Postal address if you want 'em (I only have hard copy). - Ted ----------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Rd./Suite 250 | fax: +1 301 381-3320 Columbia, MD 21046 USA | voice mail: (800) 233-1485 x4436 ----------------------------------------------------------------------------- "These opinions are my own, and not necessarially those of Network Systems Corporation." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102181541.AA06605@nscultrix1.network.com] <1991021815415200> From: dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102181541.AA06605@nscultrix1.network.com> Date: 18 Feb 91 15:41:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 Erik Naggum raises a host of interesting points in his comparison of email to the postal service's registered/certified mail. I tend to support his conclusion that "registered" email will be a long time comming, but for social, rather than technical reasons. While I'm not a lawyer, my understanding of the legal status of email is that it does not have any of the protections accorded to paper (Post Office) mail. While it is a crime for the post office to tamper with your letters, there appears to be nothing preventing any mail relay from reading/modifying/deleting your mail at will. A recent case against Epson America, where an employee was fired (and frogmarched out of the building by the police, no less!) for objecting to Epson's policy of reading employee's email, was dismissed because it Epson has not violated either the Electronic Communications Privacy Act or California wiretaping statutes. The judge ruled flat out that wiretaping does not apply to email. (Note that a similar suit has been files against Nissan USA). So what does this mean (rather than don't buy Epson or Nissan products)? Email appears to have absolutely no legal protections, or any standing in a court of law (don't tell me about Ollie North - that was no court, that was the congress). I would suggest that email providers will not venture into this field until the LEGAL status of email is established. Imagine the liability of (for example) MCI if they offer a "Certified" email that can be manhandled by any system administrator on the net ... This may be a case of a solvable (eventually) *technical* problem but an insoluable social one. ------------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Rd./Suite 250 | fax: +1 301 381-3320 Columbia, MD 21046 USA | voice mail: (800) 233-1485 ------------------------------------------------------------------------------- "These views are my own, and do not necessarially represent those of Network Systems Corporation" "The first thing we do, it to kill all the lawyers." -Wm. Shakespeare ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102181547.AA06656@nscultrix1.network.com] <1991021815473200> From: dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <9102181547.AA06656@nscultrix1.network.com> Date: 18 Feb 91 15:47:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 well!bnox%well.sf.ca.us@apple.com posted a message about problems with TCP configuration on a PC running SCO. I tried responding to him only, but the mailer barfed on the address. So here it is (sorry for cluttering the ether ...): Your problem is in the mkdev tcp statement. The Internet Address is *NOT* the same as the address printed on the ethernet card (in short, Xerox is the keeper of the sacred ethernet address space - if you want to sell ethernet stuff, you buy a block of addresses from them; however, you can assign your own IP addresses at will (unless you are connecting tothe Internet)). Fortunately, the solution looks pretty easy - use an IP address like : 192.1.164. where is a one-byte address that is not duplicated by any other host on that net. Note that *ALL* hosts on that net will have an address of the form 192.1.164. There is this magic thing called ARP that takes care of mapping IP addresses to ethernet addresses, so don't worry about it. Things should work after this. OBTW, if you are new to the wonderful world of TCP/IP, run don't walk to your nearest technical bookstore and score yourself a copy of "Internetworking with TCP/IP" by Douglas Comer (2nd Ed.) (Prentice-Hall, 1990, ISBN 0-13-468505-9). While you'll find that you outgrow it pretty quickly, it's the best introduction it TCP/IP that I've seen. - Ted Doty, Network Systems Corporation phone: +1 301-596-2270 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb18.113952@mathcs.emory.edu] <1991021816395200> From: km@mathcs.emory.edu (Ken Mandelberg) Newsgroups: comp.protocols.tcp-ip Subject: SLIP with an ANNEX Message-ID: <1991Feb18.113952@mathcs.emory.edu> Date: 18 Feb 91 16:39:52 GMT Sender: news@mathcs.emory.edu Reply-To: km@mathcs.emory.edu (Ken Mandelberg) Organization: Emory University, Dept of Math and CS Lines: 27 The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme where the remote and local IP address for each port have to be preset. This means on the remote SLIP node (a Sun in my case), the local side of the SLIP interface will vary and in no way identify the workstation. Also in my case the SLIP is the only local interface other than the loopback. Does anyone see a way for me to assign a permanent IP address to the workstation, and have the connections from the workstation appear to come from that address, not the variable Annex chosen address. Unless I'm missing something, this is exactly what would happen if I had a second remote workstation connected by ethernet to the first, and routing through it accross the SLIP link. Frankly, the Annex scheme seems a bit out of date. The host based SLIPs seem to handle this with a sliplogin program that can set the IP address of the SLIP link from an id keyed database. Its a little surprising that Xylogics hasn't done something like this, they do have host based support for other data. -- Ken Mandelberg | km@mathcs.emory.edu PREFERRED Emory University | {rutgers,gatech}!emory!km UUCP Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET Atlanta, GA 30322 | Phone: Voice (404) 727-7963, FAX 727-5611 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910218111930.20204164@SSCVX1.SSC.GOV] <1991021817193000> From: JAFFE@SSCVX1.SSC.GOV Newsgroups: comp.protocols.tcp-ip Subject: Modify Subscription Message-ID: <910218111930.20204164@SSCVX1.SSC.GOV> Date: 18 Feb 91 17:19:30 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Please change my subscription address to jaffe@sscvx1.ssc.gov. Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb18.182416.180@bwdls61.bnr.ca] <1991021818241600> From: pww@bnr.ca (Peter Whittaker) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <1991Feb18.182416.180@bwdls61.bnr.ca> Date: 18 Feb 91 18:24:16 GMT References: <9102181435.AA05874@nscultrix1.network.com> Sender: usenet@bwdls61.bnr.ca (Use Net) Organization: Bell-Northern Research, Ltd., Ottawa, Ontario, Canada Lines: 24 In article <9102181435.AA05874@nscultrix1.network.com> dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) writes: >While I'm not a lawyer, my understanding of the legal status of email is that >it does not have any of the protections accorded to paper (Post Office) mail. > >This may be a case of a solvable (eventually) *technical* problem but an >insoluable social one. One solution is to send only encrypted mail, preferably something encrypted using the intended recipient's public key: the recipient is therefore the only person who can decrypt it. (For more information, check out articles or books on Privacy Enhanced Mail (PEM) or Public Key CryptoSystems (PKCS). See also CCITT X.509). The solution ends up being technical rather than social.:-> Of course, an employer might disallow encrypted mail on corporate systems.... -- 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---- [1991Feb18.183909.2610@grape.ecs.clarkson.edu] <1991021818390900> From: shaikh@image.soe.clarkson.edu (Asad Shaikh) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP using Phil Karan code Message-ID: <1991Feb18.183909.2610@grape.ecs.clarkson.edu> Date: 18 Feb 91 18:39:09 GMT Sender: @grape.ecs.clarkson.edu Organization: Clarkson University Lines: 18 I am using Phil Karan code and designing a protocol for data transfer. my problem is rece_mbuf is working more than once. Client Server send_mbuf recv_mbuf recv_mbuf send_mbuf send_mbuf recv_mbuf(Not working). recv_mbuf is sitting and can not get out from loop I mean from pawit(). My question is can some one use recv_mbuf more than once. Thanks asad ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb18.192721.5747@unx2.ucc.okstate.edu] <1991021819272100> From: uccxmgm@unx2.ucc.okstate.edu (Martin McCormick) Newsgroups: comp.protocols.tcp-ip Subject: DOS-Based Name Server Message-ID: <1991Feb18.192721.5747@unx2.ucc.okstate.edu> Date: 18 Feb 91 19:27:21 GMT Organization: Oklahoma State University Computer Center Lines: 12 Posted: Mon Feb 18 13:27:21 1991 I hear that there is a DOS-based domain name server produced by a company called "FTP Software." If anybody has experience with it, please reply to u1906ad@unx.ucc.okstate.edu Thanks. Martin McCormick WB5AGZ Oklahoma State University Stillwater, Oklahoma 74078 405-744-6301 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7005@rossignol.Princeton.EDU] <1991021819325800> From: tr@samadams.princeton.edu (Tom Reingold) Newsgroups: comp.protocols.tcp-ip Subject: load average for System V Message-ID: <7005@rossignol.Princeton.EDU> Date: 18 Feb 91 19:32:58 GMT Sender: news@cs.Princeton.EDU Distribution: na Organization: Noo Joizy -- The Cultural Mecca Lines: 10 In Wollongong's tcp/ip package for System V, you get rwhod and ruptime. So apparently, they know how to compute load average. Now, I'd like to compute it too, in the hope that I can dispose of the use of rwhod. How is it computed? I find it odd that uptime is not included while ruptime is. -- 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---- [1991Feb18.215704.10313@ns.network.com] <1991021821570400> From: hgv@daphne.network.com (Harry G. Varnis) Newsgroups: comp.protocols.tcp-ip Subject: Requirements for Hosts and BSD Message-ID: <1991Feb18.215704.10313@ns.network.com> Date: 18 Feb 91 21:57:04 GMT Sender: news@ns.network.com Organization: Network Systems Corporation Lines: 5 Originator: hgv@daphne Nntp-Posting-Host: daphne Could someone point me to a statement of conformance to RFC1122/1123 for the BSD-tahoe TCP/IP stack, please? -- Harry Varnis (612) 424-4888 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10338@ncar.ucar.edu] <1991021823274400> From: woods@ncar.ucar.edu (Greg Woods) Newsgroups: comp.protocols.tcp-ip Subject: Re: third-party traceroute Message-ID: <10338@ncar.ucar.edu> Date: 18 Feb 91 23:27:44 GMT References: <9102152346.AA04371@ganges.ucop.edu> Reply-To: woods@handies.UCAR.EDU (Greg Woods) Organization: Scientific Computing Division/NCAR, Boulder CO Lines: 11 In article <9102152346.AA04371@ganges.ucop.edu> spgdrp@GANGES.UCOP.EDU writes: >There is a public domain version of traceroute posted on zerkalo.harvard.edu. >I don't know if this is the canonical source. >You should know that this program requires modifying your kernel. I found it on ftp.cc.berkeley.edu. Whether or not it requires kernel mods depends on what OS you are running. We run SunOS 4.1 here and I was able to compile and run third party traceroute without any kernel mods. Thanks to all who responded. --Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910219021919.682435@DOCKMASTER.NCSC.MIL] <1991021902190000> From: Sabo@DOCKMASTER.NCSC.MIL Newsgroups: comp.protocols.tcp-ip Subject: Re: SNMP comparison Message-ID: <910219021919.682435@DOCKMASTER.NCSC.MIL> Date: 19 Feb 91 02:19:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 >>Yes, Datapro has completed a study of SNMP-based management stations and >>will soon release a report on SNMP-based agent. The SNMP manager report >>is often given away free of charge. Contact Jill Huntington-Lee at >>(800) DATAPRO ex 2444. >> > >A non-800 number or E-mail address would be nice for non US sites. > >Erick > MCIMAIL.COM L. Michael Sabo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102190310.AA13500@alw.nih.gov] <1991021903090400> From: RAF@CU.NIH.GOV ("Roger Fajman") Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102190310.AA13500@alw.nih.gov> Date: 19 Feb 91 03:09:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 > The postal service is paid to deliver your mail. When you buy the > service of registered mail, the postal service is required by law to > deliver it and record the delivery in a way which you can rely on, > legally. You can request return receipts from the postal service as > well, and the postal service has a big problem if you don't get a > return receipt when the letter was received. There is no one who can > assume this responsibility in the Internet. Thus, the "shortcoming" > stems from the nature of the service provider involved, and SMTP > reflects this. At least in the US there is something called certified mail, which is less stringent than registered mail. It does not guarantee that the letter will arrive, but simply keeps a record if it does. You can also request a return receipt, which can also get lost along the way back. Even with registered mail, there is no assurance that the return receipt will make it back to you. Only the original letter is safeguarded while enroute. There is no such safeguarding for certified mail. We have email acknowledgements on some of our internal systems. They aren't used extensively, so the extra traffic is minimal. The normal reason for using them is to get some reasonable assurance that the message did make it to the addressee. The idea is to follow up if the acknowledgement is not received in a reasonable time. I don't think that anyone believes that it is legally binding in any way. Regardless of what you think of acknowledgements, they are a feature that many people want. This discussion more properly belongs on the header-people list. Also, there is now an IETF working group considering enhancements to RFCs 821 and 822. 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---- [1991Feb19.122235.868@uni2a.unige.ch] <1991021910223400> From: nanchen@uni2a.unige.ch Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP <--> IBM network (link?) Message-ID: <1991Feb19.122235.868@uni2a.unige.ch> Date: 19 Feb 91 10:22:34 GMT Organization: University of Geneva, Switzerland Lines: 13 Hello! I've just a simple question: a friend of mine, who's working at IBM and uses the IBM-network, wonders if there is a way for him to access this network we are all using directly from his IBM-terminal (he's working in under VM/CMS and MVS/TSO-E and uses IBMtype adresses: NAME at NODE)? How, if the physical link between the two networks actually exists, should he write the adresses to be understood by TCP/IP? Does anybody know anything about this? Joel (MARGOT@eldp.epfl.ch - I'm using a friend's account for posting this letter). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1019@pe.dk] <1991021912473700> From: ms@pe.dk (Mogens Soerensen) Newsgroups: comp.protocols.tcp-ip Subject: Is there a protocol for remote printing ? Keywords: protocol printing Message-ID: <1019@pe.dk> Date: 19 Feb 91 12:47:37 GMT Organization: Purup Electronics A/S, Denmark Lines: 20 Does a standard protocol exist for remote printing on tcp/ip ? I have been looking in RFC's and in different litterature for a specification, but haven't found one. I am also interested in specifications for the protocol used by the BSD lpd daemon, and if such a protocol exists for SYSV also the protocol used by the lpsched. Please email any pointers or protocol specifications, I will post a summary if there are interest. Thanks in advance. +--------------------------------+---------------------------------+ | Purup Electronics a/s | Email: ms@pe.dk | | Att: Mogens Soerensen, R&D | Uucp.: ...!mcsun!dkuug!pe!ms | | Sonderskovvej 5 | Phone: +45 8622 2522 | | DK-8520 Lystrup | Fax..: +45 8622 2511 | | DENMARK | Telex: 68242 purel dk | +--------------------------------+---------------------------------+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102191343.AA03146@telesys.ncsc.navy.mil] <1991021913434200> From: mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) Newsgroups: comp.protocols.tcp-ip Subject: Re: DNS on VAX and TCP/IP on OS/2? Message-ID: <9102191343.AA03146@telesys.ncsc.navy.mil> Date: 19 Feb 91 13:43:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 Brad Knowles asks... > Could someone refresh my memory as to what is available on VAXen for DNS > server software? Don't know for sure offhand, but it seems like our Wollongong stuff uses DNS on VAXen. > Kind of sounds like we need to start our own mailing list for those > of us that have VAXen, Suns, and PCs with cc:mail and having to > make them interact -- Let me know what you think of this idea I'd like to know more about cc:mail capabilities in the environment you describe... > BTW, does anyone know of a full suite of TCP/IP applications written to run > on OS/2 (with the 3Com Ethernet software)? 3Com's 3+Open TCP/IP includes an OS/2 version as well as a DOS version. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102191514.AA02903@europa.clearpoint.com] <1991021915145000> From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: PPP Documentation wanted Message-ID: <9102191514.AA02903@europa.clearpoint.com> Date: 19 Feb 91 15:14:50 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 47 > From tcp-ip-RELAY@NIC.DDN.MIL Fri Feb 15 23:14:40 1991 > From: swrinde!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7!nmurrayr@ucsd.edu (Ron Murray) > Organization: Curtin University of Technology > Subject: PPP Documentation wanted > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > > I'd like to get the specs for PPP. RFC number (if any) or other help > would be appreciated. > Thanks, > ....Ron > > -- > > =============================================================================== > Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to > ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can > Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his > UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got > Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" > TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I > =============================================================================== > From the latest rfc-index.txt (available at most RFC repositories): 1172 Perkins, D.; Hobby, R. Point-to-Point Protocol (PPP) initial configuration options. 1990 July; 38 p. (Format: TXT=76132 bytes) 1171 Perkins, D. Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links. 1990 July; 48 p. (Format: TXT=92321 bytes) (Obsoletes RFC 1134) There are also a couple of internet drafts which may be of interest: draft-ietf-ppp-multidatagrams-02.txt draft-ietf-ppp-options-03.txt draft-ietf-ppp-pppmib-00.txt draft-ietf-ppp-pppmib-01.txt draft-ietf-pppext-bridging-00 draft-ietf-pppext-pppmib-00.txt draft-ietf-pppext-pppmib-01.txt Frank Kastenholz Clearpoint Research ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb19.164314.4901@mmc.mmmg.com] <1991021916431400> From: us267388@mmc.mmmg.com (Bradley D. Rhoades) Newsgroups: comp.protocols.tcp-ip Subject: RFC 931 - Authentication Server? Keywords: authd, rfc931 Message-ID: <1991Feb19.164314.4901@mmc.mmmg.com> Date: 19 Feb 91 16:43:14 GMT Sender: us267388@mmc.mmmg.com (Bradley D. Rhoades) Reply-To: us267388@mmc.mmmg.com (Bradley D. Rhoades) Organization: 3M/Metal Matrix Composites Department Lines: 13 Recently an rfc931 implementation of an authentication server was made available. I understand the basics of the protocol after reading the RFC and author notes, but I am curious why I should use it now. Do any utilities available today utilize the authentication server? What good does it do for me to run it now? -- Bradley D. Rhoades E/Mail: bdrhoades@mmc.mmmg.com 3M, 2465 Lexington Ave So NIC: BR79 Building 60-1N-01 WRK: +1 (612) 736 2874 Mendota Heights, MN 55120 FAX: +1 (612) 736-0431 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102191653.AA20496@ftp.com] <1991021916531600> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Whose source route wins in TCP connections? Message-ID: <9102191653.AA20496@ftp.com> Date: 19 Feb 91 16:53:16 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 28 "When a TCP connection is OPENed passively and a packet arrives with a completed IP Source Route option (containing a return route), TCP MUST save the return route and use it for all segments sent on this connection..." Ok, fine. But does this mean the passive end of the connection cannot issue a source route of its own? Note that the preceding paragraph of the RFC says "An application MUST be able to specify a source route when it actively opens a TCP connection, and this MUST take precedence over a source route received in a datagram." Where did this received source route come from if the passive end has to save a received return route (presumably received from the actively opened end) and 'use it for ALL segments sent on this connection' ? At the passive end, the active's source route is known to work (it got the packet there, after all), and so the incoming source route should override anything the application specified. If the active end got a response, their initial route worked, and they should ignore anything that comes back, in case some really quirky asymmetric routing situation required that humans intervene on the passive side to make it work... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb19.172248.15431@unx2.ucc.okstate.edu] <1991021917224800> From: uccxmgm@unx2.ucc.okstate.edu (Martin McCormick) Newsgroups: comp.protocols.tcp-ip Subject: IBM3270-VT100 Emulator Message-ID: <1991Feb19.172248.15431@unx2.ucc.okstate.edu> Date: 19 Feb 91 17:22:48 GMT Organization: Oklahoma State University Computer Center Lines: 21 Our data communications operation is looking for a TCP- IP based IBM3270 to VT-100 protocol converter capable of handling at least 64 terminal sessions. We are looking for something much like the Mitek product only hopefully less expensive. The device should be channel-attached on the IBM side and communicate over Ethernet on the TCP-IP side. Our present IBM3270 emulators are part of our asynchronous network and appear to the IBM side of the connection as remote controllers. Any information, either good or bad about IBM3270 emulators you have known would be appreciated. Please Email to u1906ad@unx.ucc.okstate.edu Many thanks. Martin McCormick Data Communications Group Oklahoma State University Stillwater, Oklahoma 74078 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102191901.AA01021@braden.isi.edu] <1991021919010400> From: braden@VENERA.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Whose source route wins in TCP connections? Message-ID: <9102191901.AA01021@braden.isi.edu> Date: 19 Feb 91 19:01:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 15 At the passive end, the active's source route is known to work (it got the packet there, after all), and so the incoming source route should override anything the application specified. If the active end got a response, their initial route worked, and they should ignore anything that comes back, in case some really quirky asymmetric routing situation required that humans intervene on the passive side to make it work... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 Thanks, James, as always you said it better than I did! Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [10832@xenna.Xylogics.COM] <1991021919482300> From: griff@Xylogics.COM (Scott Griffiths) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP with an ANNEX Message-ID: <10832@xenna.Xylogics.COM> Date: 19 Feb 91 19:48:23 GMT References: <1991Feb18.113952@mathcs.emory.edu> Reply-To: griff@Xylogics.COM (Scott Griffiths) Organization: Xylogics, Inc., Burlington MA Lines: 83 In article <1991Feb18.113952@mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes: >The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme >where the remote and local IP address for each port have to be preset. > >This means on the remote SLIP node (a Sun in my case), the local side of >the SLIP interface will vary and in no way identify the workstation. Also >in my case the SLIP is the only local interface other than the loopback. > --- deleted -- > >Frankly, the Annex scheme seems a bit out of date. The host based SLIPs >seem to handle this with a sliplogin program that can set the IP address >of the SLIP link from an id keyed database. Its a little surprising that >Xylogics hasn't done something like this, they do have host based support >for other data. > Xylogics has available an unsupported version of our erpcd program which supports dial-up slip as you request. You supply a simple user lookup routine. After identifying the user to the annex security subsystem, the incoming port is re-configured as a slip port with the user matched IP address. Upon modem hangup, the port is configured back to CLI mode. This code is ftp-able via anonymous ftp to xylogics.com in ~ftp/annex/unsupported/acp or by requesting it via email to annex-support@xylogics.com. Scott Griffiths phone: (617) 272-8140 x332 Xylogics Annex Technical Support email: griff@xylogics.com Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP with an ANNEX Summary: Expires: References: <1991Feb18.113952@mathcs.emory.edu> Sender: Reply-To: griff@Xylogics.COM (Scott Griffiths) Followup-To: Distribution: Organization: Xylogics, Inc., Burlington MA Keywords: In article <1991Feb18.113952@mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes: >The Annex terminal servers run SLIP (and soon CSLIP), but employ a scheme >where the remote and local IP address for each port have to be preset. > >This means on the remote SLIP node (a Sun in my case), the local side of >the SLIP interface will vary and in no way identify the workstation. Also >in my case the SLIP is the only local interface other than the loopback. > >Does anyone see a way for me to assign a permanent IP address to the >workstation, and have the connections from the workstation appear to >come from that address, not the variable Annex chosen address. Unless >I'm missing something, this is exactly what would happen if I had a second >remote workstation connected by ethernet to the first, and routing >through it accross the SLIP link. > >Frankly, the Annex scheme seems a bit out of date. The host based SLIPs >seem to handle this with a sliplogin program that can set the IP address >of the SLIP link from an id keyed database. Its a little surprising that >Xylogics hasn't done something like this, they do have host based support >for other data. > Xylogics has available an unsupported version of our erpcd program which supports dial-up slip as you request. You supply a simple user lookup routine. After identifying the user to the annex security subsystem, the incoming port is re-configured as a slip port with the user matched IP address. Upon modem hangup, the port is configured back to CLI mode. This code is ftp-able via anonymous ftp to xylogics.com in ~ftp/annex/unsupported/acp or by requesting it via email to annex-support@xylogics.com. Scott Griffiths phone: (617) 272-8140 x332 Xylogics Annex Technical Support email: griff@xylogics.com -- Scott Griffiths phone: (617) 272-8140 Xylogics Annex Technical Support email: griff@xylogics.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [284@platypus.uofs.edu] <1991021920153800> From: cml8@robin.cs.uofs.edu (Chris M. Little) Newsgroups: comp.mail.misc,comp.mail.elm,comp.protocols.tcp-ip Subject: How to receive mail on all stations in our Sun network. ??? Keywords: network, mail, receive Message-ID: <284@platypus.uofs.edu> Date: 19 Feb 91 20:15:38 GMT Sender: news@platypus.uofs.edu Followup-To: comp.mail.misc Organization: Computer Science Dept., University of Scranton, PA. Lines: 14 Nntp-Posting-Host: robin.cs.uofs.edu Originator: cml8@robin.cs.uofs.edu We have a network of about 12 Sun SPARCstations. I can log in to any station and be in my home directory. I guess we have a single fileserver fo all the stations. However, is someone sends me mail to on station, I can only read it on that station. Is there any way that I could be notified of new mail on any station in the network and also read the new mail on any station? E-mail responses would be appreciated. Thanks. -- Chris Little, Graduate Asstistant - CML8@JAGUAR.UOFS.EDU (VMS) Department of Computing Sciences - CML8@SCRANTON.BITNET (VMS) University of Scranton, Pennsylvania. - CML8@SPARROW.CS.UOFS.EDU (UNIX) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [36540022@hpindwa.cup.hp.com] <1991021920482400> From: raj@hpindwa.cup.hp.com (Rick Jones) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <36540022@hpindwa.cup.hp.com> Date: 19 Feb 91 20:48:24 GMT References: <1991Feb6.184300@sicsun.epfl.ch> Organization: Hewlett-Packard, Cupertino CA Lines: 5 A bit of drift, but which routers support MINMTU (RFC 1191) at this point?... rick jones ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb19.220153.28244@shl.com] <1991021922015300> From: phil@shl.com (Phil Trubey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Tandem 6530 terminal emulator (tn6530?) Keywords: tandem 6530 terminal Message-ID: <1991Feb19.220153.28244@shl.com> Date: 19 Feb 91 22:01:53 GMT References: <626@deere.com> <1991Feb14.170436.7587@tandem.com> <851@nddsun1.sps.mot.com> Organization: SHL Systemhouse Inc. Lines: 13 In article <851@nddsun1.sps.mot.com> markm@nddsun1.sps.mot.com (Mark Monninger) writes: >How about a TN6530 client for >DOS machines? Failsafe Systems has one for DOS. They can be reached at 708-390-6660. They also sell an alternative to Tandem's TCP/IP. I might be able to answer some more questions if you have any... -- Phil Trubey SHL Systemhouse Inc. (Internet: phil@shl.com UUCP: ...!uunet!shl!phil) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [46@prang.TEST.Vitalink.COM] <1991021922101800> From: ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) Newsgroups: comp.protocols.tcp-ip Subject: Re: Testing if a host is up Message-ID: <46@prang.TEST.Vitalink.COM> Date: 19 Feb 91 22:10:18 GMT References: <1991Feb16.041439.1038@Think.COM> <529@trux.UUCP> Sender: usenet@prang.TEST.Vitalink.COM Reply-To: ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey) Lines: 25 Nntp-Posting-Host: riscit.noc.vitalink.com In article <1991Feb16.041439.1038@Think.COM>, barmar@think.com (Barry Margolin) writes: > In article <529@trux.UUCP> car@trux.UUCP (Chris Rende) writes: > >I need a way to put a test ahead of the FTP that will determine whether > >or not the other host is "up". > >Here is what I have so far: > ># hostup - Written 01/30/91 by Chris Rende > [Script omitted] > > Except for the exact text of the message printed, the ping command does > exactly what your shell script does. It returns 0 status if the host is > up, and non-zero when the host is down. > Also, more as a heads up... Some SLIP-ed or PPP-ed hosts have ICMP messages filetered out specifically to prevent pings from clogging low-speed links. Although I don't necessarily agree with this, I do see that the SLIP/PPP code allows this. ... Erik --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15136@lanl.gov] <1991021922173100> From: jrr@lanl.gov (John R. Red-horse) Newsgroups: comp.protocols.tcp-ip Subject: telnet and ftp for DEC's SysV UN*X Message-ID: <15136@lanl.gov> Date: 19 Feb 91 22:17:31 GMT Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 7 We are running a DEC version of System V (I believe it's r3) on a VAX 8540. The version of ftp imposes a hard limit on file sizes somewhere in the neighborhood of 1Mbyte. I assume that this is a parameter that can be changed, but I don't have the source to do the fix. Does anyone out there know where I might obtain such an animal? Better yet, how about a version that's already fixed? Cheers, ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BOB.91Feb19180852@volitans.MorningStar.Com] <1991021923090100> From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.protocols.tcp-ip Subject: SNA tunneling? Message-ID: Date: 19 Feb 91 23:09:01 GMT Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 6 Is anyone working on a standard for IP tunneling over SNA networks? That is, given an existing SNA network, and a desire to use it for IP transport, is there an equivalent to any of RFCs 1201, 1188, 1171, 1149, 1088, 1042, and 877? (OK, I just mentioned 1149 to see if you were really watching :-) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MEB.91Feb20105117@orac.ee.mu.OZ.AU] <1991021923511700> From: meb@ee.mu.OZ.AU (Matthew Barry) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP using streams? Message-ID: Date: 19 Feb 91 23:51:17 GMT Sender: news@cs.mu.oz.au Reply-To: meb@ee.mu.OZ.AU Distribution: comp Organization: Computer Science, University of Melbourne, Australia Lines: 8 Can anyone tell me which operating systems have implementions of TCP/IP using streams modules? Thanks in advance, Matthew Barry ----MESSAGE-END---- ----MESSAGE-BEGIN---- [19FEB91194919@uazhe0.physics.arizona.edu] <1991022000491900> From: zazula@uazhe0.physics.arizona.edu (RALPH ZAZULA) Newsgroups: comp.protocols.tcp-ip Subject: Help needed getting KA9Q running on PC... Message-ID: <19FEB91194919@uazhe0.physics.arizona.edu> Date: 20 Feb 91 00:49:19 GMT Reply-To: zazula@uazhe0.physics.arizona.edu Distribution: usa,local Organization: University of Arizona Physics Department Lines: 16 Nntp-Posting-Host: uazhe0.physics.arizona.edu News-Software: VAX/VMS VNEWS 1.3-4 Lines: 16 I'm trying to get a SLIP connection working from my PC. I am trying to use KA9 but the manual is giving me no help at all. Does anyone out there use or know how to use this program? IS there a better program to use a SLIP connection? Thanks, Ralph |----------------------------------------------------------------------| | Ralph Zazula "Computer Addict!" | | University of Arizona --- Department of Physics | | UAZHEP::ZAZULA (DecNet/HEPNet) | | zazula@uazhe0.physics.arizona.edu (Internet) | |----------------------------------------------------------------------| | "You can twist perceptions, reality won't budge." - Neil Peart | |----------------------------------------------------------------------| ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102200056.AA00350@seka.scc.com] <1991022000560500> From: enger@SEKA.SCC.COM (Robert M. Enger) Newsgroups: comp.protocols.tcp-ip Subject: RE: Third party traceroute (source-route traceroute) Message-ID: <9102200056.AA00350@seka.scc.com> Date: 20 Feb 91 00:56:05 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 The version of traceroute on Zerkalo.harvard.edu is a composite of the various available sources and enhancements (including source-route ability). IF THE VERSION OF TRACEROUTE ON ZERKALO IS NOT THE MOST COMPLETE, I WOULD APPRECIATE IT IF SOMEONE WOULD SET US STRAIGHT. THANKS!! Also, some machines' operating systems no longer require kernel modification to support traceroute. Happy debugging, Bob Enger ----MESSAGE-END---- ----MESSAGE-BEGIN---- [EMV.91Feb20005703@poe.aa.ox.com] <1991022000570300> From: emv@ox.com (Ed Vielmetti) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third party traceroute (source-route traceroute) Message-ID: Date: 20 Feb 91 00:57:03 GMT References: <9102200056.AA00350@seka.scc.com> Sender: usenet@ox.com (Usenet News Administrator) Organization: OTA Limited Partnership, Ann Arbor MI. Lines: 27 In-Reply-To: enger@SEKA.SCC.COM's message of 20 Feb 91 00:56:05 GMT In article <9102200056.AA00350@seka.scc.com> enger@SEKA.SCC.COM (Robert M. Enger) writes: The version of traceroute on Zerkalo.harvard.edu is a composite of the various available sources and enhancements (including source-route ability). IF THE VERSION OF TRACEROUTE ON ZERKALO IS NOT THE MOST COMPLETE, I WOULD APPRECIATE IT IF SOMEONE WOULD SET US STRAIGHT. THANKS!! As far as I know, the traceroute package on zerkalo and the 4.3 bsd-reno traceroute on (e.g.) wuarchive.wustl.edu are the latest of the publically available traceroute implementations for BSD Unix. There is no way to know what all else other people might have hacked into the code, in their own effort to make it complete. If someone has done this they haven't spoken up. By the way, how's the "noctool2" group's efforts coming along? Send me some mail (if you can read my mangled address), I have some contributions to make. --Ed Edward Vielmetti emv@ox.com (note: the gateway may be mangling my address. please advise if you get this by mail and the From: line is weird.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [45172@nigel.ee.udel.edu] <1991022002445800> From: rbaliga@udel.edu (Rajesh Baliga) Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.iso.dev-environ Subject: APPLICATION LAYER Message-ID: <45172@nigel.ee.udel.edu> Date: 20 Feb 91 02:44:58 GMT Sender: usenet@ee.udel.edu Reply-To: rbaliga@udel.edu (Rajesh Baliga) Followup-To: comp.protocols.iso Organization: University of Delaware Lines: 21 Nntp-Posting-Host: dewey.udel.edu I WOULD BE THANKFUL IF SOMEONE IN THIS NEWS GROUP ENLIGHTENS ME ON WHAT THE FOLLOWING ABBREVATIONS STAND FOR.THE ONLY THING I KNOW ABOUT THESE ABBREVATIONS IS THAT THESE CORRESPOND TO DIFFERENT SERVICE ELEMENTS IN THE APPLICATION LAYER OF THE 7-LAYERED OSI REFERENCE MODEL.THE ABOVE-MENTIONED ABBREVATIONS ARE THE FOLLOWING: DPSE, TPSE, CCRSE, JMTSE, DCSSE, DCRSE, DMSE, DSSE, DRSE, DCMSE, DCSSE, MSSE, MDSE, MASE. MY EMAIL ADDRESS IS RBALIGA @SOL.CIS.UDEL.EDU THANKS IN ADVANCE. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1019@tuura.UUCP] <1991022011523100> From: jel@tuura.UUCP (Jerry Lahti) Newsgroups: comp.protocols.tcp-ip Subject: Re: Tcp/Ip on Token-ring (VMEbus) Message-ID: <1019@tuura.UUCP> Date: 20 Feb 91 11:52:31 GMT References: <9102130119.AA27161@copsw33.teradata.com> Organization: Nokia Data Systems Oy Lines: 35 mbh@copsw33.UUCP (Marc Hasson) writes: >Does anyone know of a vendor which manufactures Token-ring cards for a >VMEbus machine? So far I've confirmed (verbally only) that Interphase >and CMC both have intelligent Token-ring VMEbus cards but I'd really >prefer a "dumb" card, if possible. A 6U form factor is a requirement. One alternative might be the Formation fv1600 adapter: - single 6U VME board - operates at 4 or 16 Mbps (jumper selectable) - uses TI TMS380C16 COMMprocessor and TMS38053 ring interface chipset - 512 KB of Token Ring buffer memory - uses shared memory to communicate with host - driver software for SunOS 4.x with RFC 1042 compatible IP and NIT access (no promiscuous mode or multicasts, though). A pretty nice product; our company is likely to begin to sell it. Contact information for the company: Formation, Inc. 121 Whittendale Drive Moorestown, NJ 08057 Tel: (609) 234 5020 FAX: (609) 234 8543 Our contact person has been Roger M. Wyer but I do not know if he is the right one for you. Best regrards, Jerry Lahti Nokia Data Systems Oy, Systems Division/Network Operating Systems Domains: jel@xerver.data.nokia.fi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb20.144514.17769@unipalm.uucp] <1991022014451400> From: ian@unipalm.uucp (Ian Phillipps) Newsgroups: comp.protocols.tcp-ip Subject: Re: DNS on VAX and TCP/IP on OS/2? Message-ID: <1991Feb20.144514.17769@unipalm.uucp> Date: 20 Feb 91 14:45:14 GMT References: <9102191343.AA03146@telesys.ncsc.navy.mil> Organization: Unipalm Ltd., Cambridge, England Lines: 25 mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) writes: >Brad Knowles asks... >> Could someone refresh my memory as to what is available on VAXen for DNS >> server software? >Don't know for sure offhand, but it seems like our Wollongong stuff uses >DNS on VAXen. MultiNet from TGV and Fusion from Network Research both have DNS servers. >> BTW, does anyone know of a full suite of TCP/IP applications written to run >> on OS/2 (with the 3Com Ethernet software)? >3Com's 3+Open TCP/IP includes an OS/2 version as well as a DOS version. FTP Software do, and this little firm called IBM have had a go as well, although their latest effort involves yet another standard adapter interface, so I don't know of the support for 3com cards. Disclaimer: we sell some of the software mentioned above (guess which :-) Ian ... what's a .signature file? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [46944@vrdxhq.verdix.com] <1991022015091800> From: williams@vrdxhq.verdix.com (Tim Williams) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs Subject: Novell and packet drivers Keywords: NOVELL packet driver NDIS PC FTP Message-ID: <46944@vrdxhq.verdix.com> Date: 20 Feb 91 15:09:18 GMT Followup-To: poster Organization: Verdix Corporation, Chantilly, VA Lines: 13 Has anyone out there been successful in using NOVELL netware 386 with a driver using the packet driver spec or the NDIS spec (for both client and server). Also is it possible to use something like PC TCP from FTP software at the same time that the NOVELL stuff is running on the client systems. Thanks in advance Tim Williams ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb20.153222.12685@searchtech.com] <1991022015322200> From: mra@srchtec.searchtech.com (Michael Almond) Newsgroups: comp.protocols.tcp-ip Subject: Shutdown problems Message-ID: <1991Feb20.153222.12685@searchtech.com> Date: 20 Feb 91 15:32:22 GMT Sender: mra@searchtech.com (Michael Almond) Organization: search technology, inc. Lines: 16 We are currently connected with PSINet via SL/IP and every day or so I get the followin error when I try pinging: ping: wrote 192.33.4.100 64 chars, ret=-1 ping: wrote 192.33.4.100 64 chars, ret=-1 ping: sendto: No buffer space available Once these errors show up, nothing seems to be going over the SL/IP connection. Does anyone know what buffer this error is refering too? -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra@searchtech.com 4725 peachtree corners cir., suite 200 {uupsi,stiatl}!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb20.182538.6043@agate.berkeley.edu] <1991022018253800> From: cliff@garnet.berkeley.edu (Cliff Frost) Newsgroups: comp.protocols.tcp-ip Subject: Re: Third party traceroute (source-route traceroute) Message-ID: <1991Feb20.182538.6043@agate.berkeley.edu> Date: 20 Feb 91 18:25:38 GMT References: <9102200056.AA00350@seka.scc.com> Sender: usenet@agate.berkeley.edu (USENET Administrator) Reply-To: cliff@garnet.berkeley.edu (Cliff Frost) Organization: ucb Lines: 28 In article , emv@ox.com (Ed Vielmetti) writes: |> |> As far as I know, the traceroute package on zerkalo and the 4.3 |> bsd-reno traceroute on (e.g.) wuarchive.wustl.edu are the latest of |> the publically available traceroute implementations for BSD Unix. |> |> There is no way to know what all else other people might have hacked |> into the code, in their own effort to make it complete. If someone has |> done this they haven't spoken up. |> OK, I'll speak up. The Zerkalo package is wonderful. It is also available on ftp.cc.berkeley.edu, along with my two trivial hacks: 1) The -n option now works. 2) It attempts to detect assymetric routes (the Open Jaw routing problem). It does this by examining the TTL in the ICMP Time Exceeded messages returned by each hop. It turns out that this method is flawed because there are at least 6 commonly used initial values for TTL in ICMP messages (29, 30, 59, 60, 255, and TTL_in_packet_received). So far I have found this second feature useful exactly once. Other times it has been interesting, but nothing more. Cliff Frost UC Berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- [efeustel.667084932@tiger1] <1991022021221200> From: efeustel@prime.com (Ed Feustel) Newsgroups: comp.protocols.tcp-ip Subject: Re: DNS on VAX and TCP/IP on OS/2? Message-ID: Date: 20 Feb 91 21:22:12 GMT References: <9102191343.AA03146@telesys.ncsc.navy.mil> <1991Feb20.144514.17769@unipalm.uucp> Lines: 11 Nntp-Posting-Host: tiger1 IBM TCP/IP 1.0 and 1.1 for OS/2 EE supports 3Com Ethernet cards including the 3C523 and I believe the 3C503. It supports DIX2.0 and IEEE 802.3 packet formats. It has client and demon for telnet, tftp ftp, rexec, sendmail, and a number of other standard utilities. At version 1.1 it supports NFS but with some security holes. It provides Kerberos support, an RPC package, a sockets package, terminal emulation for VT100, IBM3101, ANSI, and 3270 terminals. It seems to work well on my PS/2 80-111. I use the packages to work with Prime, MIPS, Sun, Apollo, and IBM. Ed ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7093@rossignol.Princeton.EDU] <1991022022571900> From: tr@samadams.princeton.edu (Tom Reingold) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet and ftp for DEC's SysV UN*X Summary: I suspect it's ulimit, not ftp Message-ID: <7093@rossignol.Princeton.EDU> Date: 20 Feb 91 22:57:19 GMT References: <15136@lanl.gov> Sender: news@cs.Princeton.EDU Organization: Noo Joizy -- The Cultural Mecca Lines: 29 In article <15136@lanl.gov> jrr@lanl.gov (John R. Red-horse) writes: $ We are running a DEC version of System V (I believe it's r3) on a VAX $ 8540. The version of ftp imposes a hard limit on file sizes somewhere $ in the neighborhood of 1Mbyte. I assume that this is a parameter that $ can be changed, but I don't have the source to do the fix. Does $ anyone out there know where I might obtain such an animal? Better $ yet, how about a version that's already fixed? $ Cheers, I suspect that this is not a limitation imposed by ftp but rather a parameter in the kernel called the ulimit. The ulimit limits the size of a file of a process and its children. This is often set at one megabyte. This supposed to prevent runaway processes from eating up available filesystem space. My feeling is that it causes more problems than it prevents. If you are root, type "ulimit 8192" and you will be able to create files of up to 8192 blocks in your current shell. This does not set anything for other users or for root at a later time. To change the system-wide ulimit value, you have to reconfigure your kernel. The above information is for System V. It has nothing to do with Berkeley UNIX. -- 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---- [285@iscden.jbsys.com] <1991022104172200> From: jbev@iscden.jbsys.com (Jim Bevier - J B Systems) Newsgroups: comp.protocols.tcp-ip Subject: unix driver for ka9q tcp/ip Message-ID: <285@iscden.jbsys.com> Date: 21 Feb 91 04:17:22 GMT Sender: jbev@iscden.jbsys.com Organization: J B Systems on HiPeak, Morrison, Co. Lines: 13 I have downloaded the UNIX (sys5) version of ka9q. It seems it only works with slip or ax25 interface. There is not an ethernet handler included. I would like to add a Western Digital 8 bit ethernet board to my system to talk to other standard tcp/ip systems. I need some sort of a bare driver. There are all kinds of DOS drivers, but no UNIX driver. Anybody know where I can get one? Even something close to use as a prototype would be useful. I have ftp access. Thanks in advance. Jim Bevier jbev@jbsys.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [172@rand.mel.cocam.oz.au] <1991022107212700> From: sgs@rand.mel.cocam.oz.au (Stuart Szabo) Newsgroups: comp.protocols.tcp-ip Subject: Looking for source for CUTP Keywords: Clarkson CUTP tcpip ncsa Message-ID: <172@rand.mel.cocam.oz.au> Date: 21 Feb 91 07:21:27 GMT Organization: Co-Cam Computer Group, Melbourne, OZ Lines: 2 Does anyone know where I can file request the Clarkson University's version of NCSA's telnet and ftp? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [THOMAS.91Feb21100709@mozart.nexus.se] <1991022109070900> From: thomas@nexus.se Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP using streams? Message-ID: Date: 21 Feb 91 09:07:09 GMT References: Sender: news@uppsala.telesoft.se (news) Distribution: comp Organization: Communicator Nexus AB Lines: 23 In-Reply-To: meb@ee.mu.OZ.AU's message of 19 Feb 91 23:51:17 GMT In article meb@ee.mu.OZ.AU (Matthew Barry) writes: Can anyone tell me which operating systems have implementions of TCP/IP using streams modules? I have a related question. I'm in dire need of a TCP/IP streams implementation where I can separate TCP and IP. I've been checking WIN/TCP 3.1.0 for the 386 and it is streams only above TCP. The WIN/TCP drivers seems to be layered much like a streams stack. Are the interfaces between the layers open and would it be feasible to put a packet level module between TCP and IP in these drivers? Znks. Thomas -- Real life: Thomas Tornblom Email: thomas@nexus.se Snail mail: Communicator Nexus Phone: +46 18 171814 Box 857 Fax: +46 18 696516 S - 751 08 Uppsala, Sweden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.133256.2179@ida.liu.se] <1991022113325600> From: mikoh@IDA.LiU.SE (Mikael Ohlsson) Newsgroups: comp.protocols.tcp-ip Subject: Socket problems Keywords: sockets, sparc, network programming Message-ID: <1991Feb21.133256.2179@ida.liu.se> Date: 21 Feb 91 13:32:56 GMT Sender: news@ida.liu.se (News Subsystem) Organization: CIS Dept, Univ of Linkoping, Sweden Lines: 21 I have some problems with a socket connection. To read and write a character from a socket takes about 1ms each. To write an integer takes about 1ms, but to read an integer takes about 180ms. My question is: Why does it take so long time to read an integer from a socket? Has it something to do with setting up the socket? The processes communicates via a stream-socket connection between two Sparcstations and the underlying protocol is TCP. I don't know wery much about network programming so I would really appreciate if somebody could give me a clue. -- --------- Mikael Ohlsson, IISLAB, Department of Computer and Information Science, Linkoeping University, Sweden Internet: mikoh@ida.liu.se, UUCP: enea!liuida!mikoh, BITNET: mikoh@seliuida ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.161808.44799@vaxb.acs.unt.edu] <1991022116120800> From: billy@vaxb.acs.unt.edu Newsgroups: comp.misc,comp.protocols.tcp-ip Subject: Internet Library Guide Summary: New Internet Library Guide Keywords: library internet Message-ID: <1991Feb21.161808.44799@vaxb.acs.unt.edu> Date: 21 Feb 91 16:12:08 GMT Followup-To: comp.misc Lines: 88 Hi, The latest version of "UNT's Accessing On-line Bibliographic Databases" handout is now complete. It now contains 168 library systems covering 220 sites. Credit for most of the new information goes to Dana Noonan, Metro State University (for all the UK info) and Peter Scott, University of Saskatchewan. Included at the end of this letter is the answer to some questions that have popped up on numerous occasions. Further discussion should take place on preferably the PACS-L or LIB_HYTELNET mailing lists. ================================================================================ 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 ================================================================================ Some commonly asked questions: How do I acquire the files? The files are available on vaxb.acs.unt.edu (129.120.1.4) via anonymous FTP. The files are: LIBRARIES.TXT - ASCII version LIBRARIES.PS - Postscript version LIBRARIES.WP5 - WordPrefect 5.1 source (transfer in binary mode) LIBRARIES.ADR - Numeric IP addresses of Internet libraries LIBRARIES.CONTACTS - Contacts for some of the Internet libraries NETWORKS.HLP - VMS help file source for a wide area networks help topic, which includes a section on library systems. BITNET only users should use the BITFTP service to acquire the files. I do not personally know how to use BITFTP. However, it is definitely not accessed by sending mail to BITFTP@UNTVAX. As an absolute last resort, the files may be requested via email (note: some networks such as UUCP may file size limits that may prohibit the transfer of these documents through electronic mail). Why is there UNT's guide and the Art St. George/Ron Larsen guide? Art St. George and I have some differences of opinion in the area of formatting and what should be included in an Internet library guide. Though I could just use the St. George guide, I need to format the information into a easy to use for novice computer users for my on-campus users. It is not much harder to provide it to the Internet at large and also gather my own information. Joe St. Sauver, the author of the VAXbook, on PACS-L put forth a rather good argument for the case that two guides are actually a benefical thing. By the way, I think Art St. George's claim of FIRST, BEST, and MOST AUTHORITATIVE is incorrect. If anybody deserves FIRST, it is Joe St. Sauver. MOST AUTHORITATIVE is without a doubt the Internet Resources Guide. BEST is a matter of opinion. I will not make any claims about my guide besides that many people find it useful. Are there some other useful sources of information? 1. HYTELNET - A Hypertext database for MS-DOS systems on Internet Resources including Library systems. Available via anonymous FTP on WUARCHIVE.WUSTL.EDU, WSMR-SIMTEL20.ARMY.MIL, or VAXB.ACS.UNT.EDU. Written by Peter Scott, University of Saskatchewan. A new version should be released in the near future. 2. LIBTEL - A TELNET front-end for VMS and Unix system to access Library Systems. Available via anonymous FTP on VAXB.ACS.UNT.EDU. Written by D. Mahone. Where do I send updates? Send all new information, updates, and deletions to BILLY@VAXB.ACS.UNT.EDU (more details on first page of guide). If you are using a TELNET/TN3270 package not listed in the appendix, please send me the information on it. Also, if you have instructions for a library software package not yet described, please send them to me and give me at least one example where it is in use. Sorry about the Appendices on some library software that are not yet completed. I will complete as time permits. Why don't you use a smaller font size to save paper? To keep 80 characters or less per line is the major reason. Also, a smaller font will not save that much paper (I've looked at it). I have problems printing the PostScript file. I'm pretty clueless on this one. I have printed the PS file from a PC to an Apple Laserwriter II without a problem. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [65738@brunix.UUCP] <1991022117315100> From: lr@cs.brown.edu (Luigi Rizzo) Newsgroups: comp.protocols.tcp-ip Subject: Simple nameserver source ? Message-ID: <65738@brunix.UUCP> Date: 21 Feb 91 17:31:51 GMT Sender: news@brunix.UUCP Reply-To: lr@cs.brown.edu (Luigi Rizzo) Distribution: usa Organization: Brown University Department of Computer Science Lines: 10 Where can I find the sources for a simple nameserver for Ultrix 2.2 ? Need nothing special, just something that reads the local /etc/host file - the machine is only connected to a local network with other Unix, Mac and MSDOS machines running NCSA Telnet. Thanks Luigi ================================================================== Luigi Rizzo Brown University & Univ. di Pisa e-mail: lr@cs.brown.edu, luigi@iet.unipi.it ================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.114831@siihp1.epfl.ch] <1991022118483100> From: root@siihp1.epfl.ch Newsgroups: comp.protocols.tcp-ip Subject: tcpdump Message-ID: <1991Feb21.114831@siihp1.epfl.ch> Date: 21 Feb 91 18:48:31 GMT Sender: news@sicsun.epfl.ch Reply-To: root@siihp1.epfl.ch () Organization: Ecole Polytechnique Federale de Lausanne Lines: 11 Does anybody knows about a program like etherfind or tcpdump for hpux systems. thanks for your answers. Claude Lecommandeur Service Informatique Central Ecole Polytechnique Federale de Lausanne 1015 LAUSANNE (SWITZERLAND) E-Mail : lecom@sic.epfl.ch Tel : (41 21) 693-45-86 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4432@se-sd.SanDiego.NCR.COM] <1991022119440200> From: nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) Newsgroups: comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Looking for OS/2 TCP/IP products with RFC 1001/1002 Message-ID: <4432@se-sd.SanDiego.NCR.COM> Date: 21 Feb 91 19:44:02 GMT Reply-To: nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) Organization: NCR Corp., Systems Engineering - San Diego Lines: 18 Hello OS/2 Users or Programmers! We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via RFC 1001/1002. Can you offer any recommendations? I understand that 3Com offers a TCP/IP product for OS/2, but I don't know any details. I would be most interested in the "more popular" TCP/IP-for-OS/2 products on the market. Thanks for your help! /******************************************************/ /* Jason Nolet */ /* Network Products Div. - San Diego, NCR Corporation */ /* email: Jason.Nolet@SanDiego.NCR.COM */ /* Phone: (619) 578-9000 */ /* Fax: (619) 693-5705 */ /******************************************************/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [627@oss670.UUCP] <1991022119452900> From: tkevans@oss670.UUCP (Tim Evans) Newsgroups: comp.protocols.tcp-ip Subject: Curious Behavior of 4.2BSD TCP/IP Keywords: subnetting Message-ID: <627@oss670.UUCP> Date: 21 Feb 91 19:45:29 GMT Organization: Social Security Admin., Baltimore/Washington Lines: 62 I have a VAX 11/750, with 4.2BSD (NOTE: 4.2, not 4.3), which I'm trying to place onto my network and am having curious results. (Before describing them, I have to say that I cannot upgrade to 4.BSD, so must deal with the situation as is.) Our network formerly consisted of 6 separate networks, which have only recently been bridged with hardware bridges into a single spanning tree network. Prior to the bridging, I'd implemented subnetting in our class B address space, with a netmask of 255.255.255.0. Each of the 6 networks was a subnet. Now, I still maintain the fiction of having 6 subnets, even though they're all the same cable. (I'd really rather not have to go back to all machines and rip out the subnetting stuff.) I set up /etc/networks showing the 6 "subnets." Here's what it looks like: loopback 127 oss-lan 137.200 lan1 137.200.1 localnet # VAX is on this subnet lan2 137.200.2 lan3 137.200.3 lan4 137.200.4 lan5 137.200.5 lan6 137.200.6 In addition, the VAX's rc.local installs routes to each of the 5 "subnets" outside its own, as shown below: route add lan2 `hostname` 0 route add lan3 `hostname` 0 route add lan4 `hostname` 0 route add lan5 `hostname` 0 route add lan6 `hostname` 0 The VAX, which is on "subnet" 1 can see and access all machines on "subnets" 1, 2, and 3, but not on 4, 5, and 6. Similarly, machines on "subnets" 1-3 can telnet/ftp to the VAX, but those on 4-6 cannot. The next curious thing is that even after installing the routes to the "subnets," 'netstat -r' doesn't report them. All that's reported is the route to "osslan" (see networks file above). More interestingly, if I reassign the VAX's IP address to one in another "subnet" (say, "subnet" 5, one that's *not* reachable) and modify the /etc/networks and installed routes accordingly, I have the same results as before! That is, even with an IP address in "subnet" 5, the VAX can see *only* "subnets" 1-3, and not 4-6. Now, I could understand it if the VAX couldn't see *anything* outside its own "subnet" (4.2BSD doesn't know about subnets, right?), but the fact that it can see some but not others is really confusing. And, that it can see/not see the same subnets, regardless of its own "subnet," makes it even more curious. Comments? Suggestions? (That is, other than upgrading the BSD.) Thanks. -- INTERNET tkevans%woodb@mimsy.umd.edu UUCP ...!{rutgers|ames|uunet}!mimsy!woodb!tkevans US MAIL 6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD 21235 PHONE (301) 965-3286 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.211534.772@ulkyvx.bitnet] <1991022121153400> From: rwmira01@ulkyvx.bitnet (Rob Miracle) Newsgroups: comp.unix.sysv386,comp.protocols.tcp-ip Subject: Help with Anonymous FTP Message-ID: <1991Feb21.211534.772@ulkyvx.bitnet> Date: 21 Feb 91 21:15:34 GMT Organization: University of Louisville Lines: 47 Good Day! I know this question has been asked here before, but since I have just started recently reading these groups I thought I would ask. I am trying to set up an anonymous FTP account on my AT&T box. We are running System V R 3.2.2 from AT&T and the AT&T ENHANCED TCP/IP WIN/386 package (Wollongong). In the Installation and Administration Guide it says: "If the username is "anonymous" or "ftp" and an "anonymous" account is present if /etc/passwd, the user is allowed to log in by specifying any password. Since anyone can log in under "anonymous," it is wise to restrict the access privileges of this account." Problem #1, AT&T SVR3.2.2 only allows 8 character file names, thus "anonymous" can not be created. By hand editing /etc/passwd and /etc/shadow, I added the account as: anonymous:x:1000:100:FTP Anonymous Account: and put the proper enter in /etc/shadow. Now I can FTP to a real account and it works find (had to get that one out). When I try to login, it barfs saying that it can't login to anonymous. I try various tricks, such as logging in as ftp and anonymou but to no avail. I try the next logical thing. I remove the anonymous account and add an account called ftp. Now I can log in, but any access other than CD barfs with a message: PORT 136,165,2,12,8,17 200 PORT command okay NLST 425 Data Socket not created [0.0.0.0,0] (This is from a VMS host), and from an unix host: 200 PORT command okay 425 Data Socket not created [0.0.0.0,0] Now I can log in as a real person and it works. CD commands seem to work fine, but I can't test them beyond not getting an error message. I tried it with and without a password of the ftp account. Problem #2 It seems that the CD command can get anywhere on the system. How do I restrict it to just the tree that I want it in? Thanks in Advance Rob -- Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 Programmer/Analyst-II | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 "Revenge is a dish best served cold. It is very cold in space" -- Ancient Klingon Proverb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.215233.26519@ncsu.edu] <1991022121523300> From: dbjoyner@eos.ncsu.edu (David Joyner) Newsgroups: comp.protocols.tcp-ip Subject: Cisco information needed Keywords: Cisco Message-ID: <1991Feb21.215233.26519@ncsu.edu> Date: 21 Feb 91 21:52:33 GMT Sender: news@ncsu.edu (USENET News System) Reply-To: dbjoyner@eos.ncsu.edu (David Joyner) Organization: North Carolina State University Lines: 12 I need some information regarding Cisco routers. Specifically, how can I query the Cisco with SNMP (or some other protocol) and get information about subnets that the router services as well as what machines are on these subnets? The technical information that I have available is lacking. I would appreciate it if a programmer from Cisco could mail me... +===========================================================================+ | David B. Joyner (dbjoyner@eos.ncsu.edu) | North Carolina State University | +---------------------------------------------------------------------------+ | "Typically supercomputers use a single microprocessor." -Boston Globe | +===========================================================================+ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [.667173635@dutepp0] <1991022122003500> From: etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot) Newsgroups: comp.protocols.tcp-ip Subject: SNMP test Summary: test with SNMP ethernet spy Keywords: SNMP ethernet-spy Message-ID: <.667173635@dutepp0> Date: 21 Feb 91 22:00:35 GMT Sender: news@duteca Lines: 25 Hi, Could some SNMP-able person on the net help me with a test of our ethernet spy debugging ? We have a beta version of out ethernet spy Beholder running on: beholder1.et.tudelft.nl This spy can report it's findings through SNMP. We have developed our own UDP/IP stack with a SNMP library. Our in-house testings work ok, but I would like some external testing. Could somebody try to reach the above host, and request the SNMP variables in the 'public' community ? Thanks for the trouble Jan -- Ir. Jan van Oorschot. --- Email: JPMvOorschot@et.tudelft.nl -- -- Data Network Performance Analysis Project -- -- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 -- -- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 -- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb21.222825.4217@elroy.jpl.nasa.gov] <1991022122282500> From: pjs@euclid.jpl.nasa.gov (Peter Scott) Newsgroups: comp.protocols.tcp-ip Subject: Novice questions on TCP programming Message-ID: <1991Feb21.222825.4217@elroy.jpl.nasa.gov> Date: 21 Feb 91 22:28:25 GMT Sender: news@elroy.jpl.nasa.gov (Usenet) Reply-To: pjs@euclid.jpl.nasa.gov Followup-To: comp.protocols.tcp-ip Organization: Jet Propulsion Laboratory, NASA/Caltech Lines: 32 Nntp-Posting-Host: euclid.jpl.nasa.gov I have just started programming in TCP and am up to my ears in manuals. I'm trying to get the basic concepts I need with the aid of Douglas Comer's book, but it's hard to see the wood for the trees; there's so much information there that I don't need, it's hard to tell what I do need. I have a simple application to complete: a server running on SunOS catches binary records sent from a MicroVAX running Multinet on VMS, which records are from a file on a machine available via DECNET to the Microvax but not the Sun. The idea is to mirror the file on the Sun; hence I have a detached process on the MicroVAX checking it at appropriate intervals. I have been able to figure out how to create sockets and make connections and have transferred data. So far so good. The problems come in trying to handle failure modes, e.g., one machine up, one down. I haven't been able to find out what happens when the VAX attempts a socket_write() but the Sun has gone down in the meantime; is there a timeout for the write? How long is it and how do I change it? Or are there timeouts only on connect()s, and ditto? Would I get an ENXIO error if the write failed? I'm trying to determine what's fatal and what isn't, both when I'm trying to make a connection and after it's been made; would any error on the write() call mean that I'd have to go back to trying to reconnect? I realize that I may be hopelessly lost; I've seen enough novice questions in areas I do know something about to know what kinds of mistakes can be made. Thanks in advance. -- 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---- [1991Feb21.234604.20577@athena.mit.edu] <1991022123460400> From: macfreak@athena.mit.edu (Gene P Sohn) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.sys.mac.apps,comp.unix.questions,comp.protocols.nfs Subject: Info on filesystem for Mac network connected to UNIX Summary: Need filesystem for Mac-UNIX network Keywords: Gatorbox, TOPS, Kerberos, NFS, filesystem, MAC/UNIX Message-ID: <1991Feb21.234604.20577@athena.mit.edu> Date: 21 Feb 91 23:46:04 GMT Sender: news@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology Lines: 39 Hi, I've never used the news net before, so I apologize beforehand for any and all etiquette violations and whatever else I'm not supposed to do, including sending this to newsgroups to which this message doesn't apply. Anyway, I'm researching the different possibilities for filesystems for a Mac-UNIX configuration. The catch is that the UNIX we're connecting to is non-standard--that is, we use Kerberos authentication on a 4.3 bsd UNIX. Frankly, I'm pretty new to networking and so I really have little idea where to start. My advisor has given me a couple of programs to research, and also hunt for any public-domain programs which might do the trick. Therefore I'll ask about Gatorbox, and TOPS. Does anyone see a problem with using either of these programs, or even better, does anyone have a running Mac/UNIX net using Gatorbox or TOPS? Opinions concerning the relative merits of Gatorbox, TOPS, and just about any other MAC fileserver program would be appreciated, in addition to what Kerberos can do to these programs' ability to run effectively, if it has an effect. I know this is, at best, a rough wording of the problem, but I hope someone can help me. Feel free to educate me on any aspect of networking in the process--I really feel pretty ignorant. :-) Again, the basic objective is a fileserver program which allows the Mac to access an existing (that might be important) UNIX network which uses Kerberos. Please reply to me directly, if possible. I only check news infrequently and irregularly. Thanks!! Gene Sohn macfreak@athena.mit.edu Compuserve: 72427,2602 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15381@uudell.dell.com] <1991022200373100> From: mjhammel@Kepler.dell.com (Michael J. Hammel) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP using streams? Message-ID: <15381@uudell.dell.com> Date: 22 Feb 91 00:37:31 GMT References: Sender: news@uudell.dell.com Reply-To: mjhammel@Kepler.dell.com (Michael J. Hammel) Distribution: comp Organization: Dell Computer Corp. Lines: 15 In article , meb@ee.mu.OZ.AU (Matthew Barry) writes: > Can anyone tell me which operating systems have implementions of > TCP/IP using streams modules? The sockets implementation of TCP/IP is done in a STREAMS framework (as stated in the AT&T System V Release 4 Programmer's Guide: Networking Interfaces) for System V Release 4. I believe ISC's TCP/IP (1.1.2 and 1.2 that I know of) package is also done over streams, but am not completely sure of that. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [5445@gara.une.oz.au] <1991022205491100> From: david@gara.une.oz.au (David Macalpine) Newsgroups: comp.sys.mac.comm,comp.protocols.tcp-ip,comp.dcom.lans,comp.dcom.modems,comp.protocols.appletalk,aus.mac Subject: Help needed with AppleLink via network Message-ID: <5445@gara.une.oz.au> Date: 22 Feb 91 05:49:11 GMT Organization: University of New England, Armidale, Australia Lines: 35 I have a problem in connecting to AppleLink from my work computer. I am using a Mac SE30 and hoping to be able to use the AUSTPAC (X25) facilities available on a network SPARCServer 330 in place of the messy business of dialling out (or trying in the case of our phone system) and then connecting to the X25 network and thence to AL. My problem is in filling in the gap in the diagram below. X.25 network (AUSTPAC) | | The SUN with X.25 PAD | TCP/IP | | GatorBox | Localtalk | My Mac's serial port ? ? ? AppleLink 6.0 I currently use MacTCP version of NCSA Telnet (2.3) to connect to the SUN with no problem. Thanks in advance for any help that you may be able to offer. Please send replies by email. Thanks again. David ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102220655.AA22023@ucbvax.Berkeley.EDU] <1991022206550800> From: Z00EJR01%AWIUNI11@pucc.PRINCETON.EDU (Ewald Jenisch) Newsgroups: comp.protocols.tcp-ip Subject: Preventing zone transfers from nameservers Message-ID: <9102220655.AA22023@ucbvax.Berkeley.EDU> Date: 22 Feb 91 06:55:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 21 X-Unparsable-Date: Thu, 21 Feb 91 13:22:08 MEZ We're running a "bind" nameserver under Unix for some time now. I'm looking for a way to restrict zone-transfers from nameservers. Put in another way I only want certain hosts in the net to do a complete zone-transfer (namely official "secondary nameservers") - the rest of the nameservers/nslookups out there should be able to query our nameserver for IP-addresses or inverse queries but NOT a complete zone-transfer. Any ideas how I could get that working? Are there any modifications necessary in the "named"-sources? I've already looked at the "assigned numbers" but didn't find a dedicated TCP/UDP port for AXFER queries - seems all nameserver queries run over port 53 (both UDP and TCP). Thanks in advance for any information, Ewald JENISCH NIC-Handle: EJ51 University Computer Center; University of Vienna, Austria E-Mail: z00ejr01@awiuni11.bitnet or z00ejr01@helios.edvz.univie.ac.at Snail-Mail: Universitaetsstrasse 7; A-1010 Vienna, Austria, Europe ----MESSAGE-END---- ----MESSAGE-BEGIN---- [tb.667211155@elwood] <1991022208255500> From: tb@Materna.DE (Torsten Beyer) Newsgroups: comp.protocols.tcp-ip Subject: Need RPC-Library for PCs (MSDOS) Message-ID: Date: 22 Feb 91 08:25:55 GMT Sender: root@Materna.DE Lines: 16 Hi Netland, I'm desperatley seeking an RPC-Library (especially the RPC client stuff) for MS-DOS. I know that FTP offers such a library in the States but their German Distributors don't have it and can't get it fast. But I need this really fast. Any hints on other stuff greatly appreciated. Thanx in advance -Torsten -- Torsten Beyer e-mail : tb@Materna.DE Dr. Materna GmbH VOX : +49 231 5599 225 Vosskuhle 37 FAX : +49 231 5599 100 D-4600 Dortmund 1, West Germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- [20620001@hpsgm2.sgp.hp.com] <1991022209330800> From: chewcg@hpsgm2.sgp.hp.com (Chye Guan Chew) Newsgroups: comp.protocols.tcp-ip Subject: SNMP Offering? Message-ID: <20620001@hpsgm2.sgp.hp.com> Date: 22 Feb 91 09:33:08 GMT Organization: HP Singapore Lines: 11 hi, I am interested in knowing vendors such as IBM, DEC, Data General, Unisys and 3Com implementation of SNMP stack. Do they provide a programmer developer kit for accessing the SNMP stack? Do they have multiplexing SNMP capability? Any information about these vendors or any vendors' offerings are welcome. Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1155@nikhefh.nikhef.nl] <1991022209550900> From: a20@nikhefh.nikhef.nl (Marten Terpstra) Newsgroups: comp.protocols.tcp-ip Subject: ICMP source quench Keywords: icmp cisco busy interface ? Message-ID: <1155@nikhefh.nikhef.nl> Date: 22 Feb 91 09:55:09 GMT Sender: terpstra@nikhef.nl (Marten Terpstra) Organization: Nikhef-H, Amsterdam (the Netherlands). Lines: 20 Hi all, Can anyone tell me what causes an ICMP source quench message to be sent ? As far as I can tell this message has something to do with the load on an interface and tells a host to slow down the sending of packets. I notice a lot of these messages on my cisco with a heavily loaded serial interface (mostly 70-80% of the 64 Kbit/s). What do hosts that recieve this messages do with it ? Can it cause an ICMP Network is down ? Does it in any way have an effect on outstanding TCP connections ? Thanks for any hints, 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---- [6507@idunno.Princeton.EDU] <1991022218331000> From: tengi@princeton.edu (Christopher Tengi) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subject: traffic monitoring by net snooping Message-ID: <6507@idunno.Princeton.EDU> Date: 22 Feb 91 18:33:10 GMT References: <5455@s3.ireq.hydro.qc.ca> <85756@sgi.sgi.com> <1991Feb16.014841.10155@pa.dec.com> Sender: news@idunno.Princeton.EDU Reply-To: tengi@princeton.edu (Christopher Tengi) Organization: Princeton University - CIT Lines: 34 Jeff, In article <1991Feb16.014841.10155@pa.dec.com>, mogul@wrl.dec.com (Jeffrey Mogul) writes: |> In article <85756@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: |> >Trying to keep up with and properly filter network traffic from an Ethernet |> >or FDDI MAC in promiscuous mode requires substantial support below the |> >application. Such support, if present, is not currently likely to be |> >sufficiently similar on products from hardware vendors. |> |> I've ported a number of such programs, and (if the program structure |> is at all modular) it turns out to be pretty easy to get a program |> (e.g., tcpdump, nfswatch, statspy) to run on the following systems: |> Ultrix + Ultrix packet filter |> SunOs + NIT |> 4.xBSD + new "Berkeley Packet Filter" (BPF) |> and possibly the IBM RT using the modified Stanford packet filter done |> by some folks at Merit. |> I assume, from reading the above, that you did work on tcpdump and statspy to make them work with the Ultrix packet filter. If this is true, have your changes been melded back into the "original" sources for the rest of us to use? If not that, would you be willing to make patches available? /Chris -- ==========----------==========---------+---------==========----------========== UUCP: ...princeton!tengi VOICEnet: 609-258-6799 INTERNET: tengi@princeton.edu FAX: 609-258-3943 BITNET: TENGI@PUCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb22.214833.10898@Think.COM] <1991022221483300> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Cisco information needed Keywords: Cisco Message-ID: <1991Feb22.214833.10898@Think.COM> Date: 22 Feb 91 21:48:33 GMT References: <1991Feb21.215233.26519@ncsu.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 37 In article <1991Feb21.215233.26519@ncsu.edu> dbjoyner@eos.ncsu.edu (David Joyner) writes: >I need some information regarding Cisco routers. Specifically, how can I >query the Cisco with SNMP (or some other protocol) and get information >about subnets that the router services as well as what machines are on >these subnets? The technical information that I have available is lacking. Do you have "The Simple Book" by Marshall Rose, which describes SNMP? If you're going to be using SNMP much I suggest you run, don't walk, to a bookstore with a good technical section and get it. To find out the IP addresses of an interface, you find the rows in the ipAddrTable where the ipAdEntIfIndex is the interface number. The corresponding ipAdEntAddr is the address of that interface. You can also get the corresponding ipAdEntNetMask to get the subnet mask, and apply this to the address to get the subnet address. By doing this for all the interfaces, you can get a list of all the subnets connected to the router. If you want to get a list of all the subnets that the router knows about, you should dump the ipRoutingTable. I don't think the router maintains a list of all the machines on a subnet (how would it get such a list?), so there's no way to list it with SNMP. If you have accounting turned on you may be able to get a list of all the hosts that have used the router. You can also FTP cisco's enterprise MIB from ftp.cisco.com. This documents all of cisco's implementation-specific extensions to the MIB. >I would appreciate it if a programmer from Cisco could mail me... You should send mail to customer-support@cisco.com if you want response from cisco. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb23.024432.26937@pa.dec.com] <1991022302443200> From: mogul@wrl.dec.com (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: problem with ftp Message-ID: <1991Feb23.024432.26937@pa.dec.com> Date: 23 Feb 91 02:44:32 GMT References: <1991Feb6.184300@sicsun.epfl.ch> <36540022@hpindwa.cup.hp.com> Sender: news@pa.dec.com (News) Organization: DEC Western Research Lines: 17 In article <36540022@hpindwa.cup.hp.com> raj@hpindwa.cup.hp.com (Rick Jones) writes: >A bit of drift, but which routers support MINMTU (RFC 1191) at this >point?... I don't know of any routers which support the new form of ICMP message defined in RFC1191, but it is important to understand that the protocol was designed to work with any router that conforms to existing standards (for IP and ICMP). You just get faster results when the routers implement RFC1191. For 4.3BSD-based routers: I did a pilot implementation while writing the RFC, and I can provide the necessary changes. To be sure: if any router vendor does implement RFC1191, I probably wouldn't know about it. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb23.025102.27462@pa.dec.com] <1991022302510200> From: mogul@wrl.dec.com (Jeffrey Mogul) Newsgroups: comp.protocols.tcp-ip Subject: Re: Subject: traffic monitoring by net snooping Message-ID: <1991Feb23.025102.27462@pa.dec.com> Date: 23 Feb 91 02:51:02 GMT References: <85756@sgi.sgi.com> <1991Feb16.014841.10155@pa.dec.com> <6507@idunno.Princeton.EDU> Sender: news@pa.dec.com (News) Organization: DEC Western Research Lines: 19 In article <6507@idunno.Princeton.EDU> tengi@princeton.edu (Christopher Tengi) writes: >Jeff, >I assume, from reading the above, that you did work on tcpdump and >statspy to make them work with the Ultrix packet filter. If this is >true, have your changes been melded back into the "original" sources >for the rest of us to use? If not that, would you be willing to make >patches available? Your inference is correct. Tcpdump version 2.0 includes Ultrix support; you can get it from ftp.ee.lbl.gov:tcpdump-2.0.tar.Z (and see tcpdump-2.0.patch-1) gatekeeper.dec.com:pub/net/tcpdump-2.0.tar.Z I'm pretty sure that the gatekeeper version has the patch installed and has a Makefile which is ready-for-Ultrix. My changes to NNstat (statspy) have been provided to the folks at ISI, and I expect them to appear in the imminent release. -Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2669@inews.intel.com] <1991022303383100> From: echan@cadev6.intel.com (Eldon Chan ~ ) Newsgroups: comp.protocols.tcp-ip Subject: Timeout mechanism to invalidate ARP cache entries Keywords: ARP unix SunOS Ultrix Message-ID: <2669@inews.intel.com> Date: 23 Feb 91 03:38:31 GMT Sender: news@inews.intel.com Reply-To: echan@cadev6.intel.com (Eldon Chan ~ ) Organization: Intel Corporation Lines: 19 Posted: Fri Feb 22 21:38:31 1991 On page 23 of RFC1122 (Requirements for Internet Hosts--Communication Layers) under the DISCUSSION paragraph said this: " The ARP specification [LINK:2} suggests but "DOES NOT" require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses " Would someone tell me what are implemented and how it is done on SunOS, Ultrix and other UNIX machines ? The RFC mentioned four mechanisms-- timeout, unicast poll, link-layer advise and high-layer advice. So, which OS is using which mechanisms ? Thanks in advance for your input. Eldon Chan Design Technology Intel Corporation echan@scdt.intel.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1330@vaxeline.COM] <1991022306145700> From: ljm@vaxeline.COM (Leo J. McLaughlin) Newsgroups: comp.protocols.tcp-ip Subject: LPR as RFC 1179 (was: Is there a protocol for remote printing) Keywords: protocol printing Message-ID: <1330@vaxeline.COM> Date: 23 Feb 91 06:14:57 GMT Reply-To: ljm@ftp.com (leo j mclaughlin iii) Distribution: comp.protocols.tcp-ip Organization: FTP Software, Inc. Lines: 16 Posted: Sat Feb 23 00:14:57 1991 >Does a standard protocol exist for remote printing on tcp/ip ? I have >been looking in RFC's and in different litterature for a specification, >but haven't found one. >I am also interested in specifications for the protocol used by the BSD >lpd daemon, and if such a protocol exists for SYSV also the protocol >used by the lpsched. LPR is indeed what you are looking for, it is described in RFC 1179. It is a slight superset of the BSD implementation so as to make LPR useful for non-UNIX systems. enjoy, leo j mclaughlin iii ljm@ftp.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb23.080939.11046@Think.COM] <1991022308093900> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP source quench Keywords: icmp cisco busy interface ? Message-ID: <1991Feb23.080939.11046@Think.COM> Date: 23 Feb 91 08:09:39 GMT References: <1155@nikhefh.nikhef.nl> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 29 Posted: Sat Feb 23 02:09:39 1991 In article <1155@nikhefh.nikhef.nl> a20@nikhefh.nikhef.nl (Marten Terpstra) writes: >Can anyone tell me what causes an ICMP source quench message to be sent ? >As far as I can tell this message has something to do with the load on an >interface and tells a host to slow down the sending of packets. I notice a >lot of these messages on my cisco with a heavily loaded serial interface >(mostly 70-80% of the 64 Kbit/s). Your guess is pretty correct. A router sends a quench when it has to discard an IP datagram due to lack of buffer space. The hope is that this will cause the sender to slow down. It can easily happen when forwarding lots of data from a fast link to a slow link, if the packets are being received faster than they can be forwarded, since the router only has a finite amount of buffer space. >What do hosts that recieve this messages do with it ? Can it cause an ICMP >Network is down ? Does it in any way have an effect on outstanding TCP >connections ? The only thing a host should do when it receives a source quench is slow its rate of transmission to that router. It might do this by setting a delay on the TCP connection that the source quench came from, or by setting a delay attribute in the routing table entry to that destination. See the Host Requirements RFC for more information on Source Quench. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [11530.9102231520@forth.stir.ac.uk] <1991022315203400> From: gsb1@forth.stirling.ac.uk (Mr Gordon S Byron) Newsgroups: comp.protocols.tcp-ip Subject: Compressed Video Transport Requirements Message-ID: <11530.9102231520@forth.stir.ac.uk> Date: 23 Feb 91 15:20:34 GMT References: <74148@bu.edu.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 13 Could you summarise your responses please as I am very interested in where this technology is going, what we can reasonably expect from it within the next five years and how soon implementation would be advisable. we have fibre optic cabling put in and hope to use Compressed Video Transport as soon as it is finacially and technically feasible. Thanks for any responses ******************************************************************************* Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, University of Stirling,FK9 4LA Stirling, Scotland, UK. Voice: 0786 73171: Ext 7266 Fax: +78651335 ******************************************************************************* ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb23.154759.6918@dramba.neis.oz] <1991022315475900> From: janm@dramba.neis.oz (Jan Mikkelsen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Tandem 6530 terminal emulator (tn6530?) Keywords: tandem 6530 terminal Message-ID: <1991Feb23.154759.6918@dramba.neis.oz> Date: 23 Feb 91 15:47:59 GMT References: <626@deere.com> <1991Feb14.170436.7587@tandem.com> <851@nddsun1.sps.mot.com> Organization: Dramba Holdings, Lindfield, Australia Lines: 10 While on the subject of Tandem 6530 terminal emulators, does anyone know of a 6530 emulator with IXF file transfer for Unix? Any flavour, but preferably System V, rel 2 or 3. Thanks, -- Jan Mikkelsen janm@dramba.neis.oz.AU or janm%dramba.neis.oz@metro.ucc.su.oz.au "She really is." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [27094@dime.cs.umass.edu] <1991022318122000> From: VOLZ@process.com (Bernard E. Volz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Timeout mechanism to invalidate ARP cache entries Message-ID: <27094@dime.cs.umass.edu> Date: 23 Feb 91 18:12:20 GMT References: <2669@inews.intel.com> Sender: news@dime.cs.umass.edu Organization: Process Software Corporation Lines: 25 X-News-Reader: VMS NEWS 1.04 In-Reply-To: echan@cadev6.intel.com's message of 23 Feb 91 03:38:31 GMT In <2669@inews.intel.com> echan@cadev6.intel.com writes: > On page 23 of RFC1122 (Requirements for Internet Hosts--Communication > Layers) under the DISCUSSION paragraph said this: > > " The ARP specification [LINK:2} suggests but "DOES NOT" require a > timeout mechanism to invalidate cache entries when hosts change their > Ethernet addresses " > > Would someone tell me what are implemented and how it is done on SunOS, > Ultrix and other UNIX machines ? > > The RFC mentioned four mechanisms-- timeout, unicast poll, link-layer > advise and high-layer advice. So, which OS is using which mechanisms ? > > Thanks in advance for your input. > > Eldon Chan > Design Technology > Intel Corporation > echan@scdt.intel.com For Process Software Corporation's TCPware for VMS we flush an ARP cache entry if we haven't RECEIVED a packet from the , pair within a reasonable time period (typically 10 minutes). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [87193@sgi.sgi.com] <1991022320094500> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.tcp-ip Subject: Re: Timeout mechanism to invalidate ARP cache entries Summary: check the source Keywords: ARP unix SunOS Ultrix Message-ID: <87193@sgi.sgi.com> Date: 23 Feb 91 20:09:45 GMT References: <2669@inews.intel.com> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 18 In article <2669@inews.intel.com>, echan@cadev6.intel.com (Eldon Chan ~ ) writes: > Would someone tell me what [ARP cache timeout mechanisms] are implemented > and how it is done on SunOS, > Ultrix and other UNIX machines ? The most reliable way to answer such a question is to check the source, when possible. That way you don't rely on hearsay and rumor. I suspect 4.* BSD was influential in most versions of SunOs and Ultrix. (Take that statement as hearsay or rumor). The 4.3BSD-network-release code is in arptimer() in .../netinet/if_ether.c in your favorite public source repository, such as UUNET. An official tape of the 4.3BSD network source is cheap, and is required reading for any serious student of TCP/IP. If you want a rumor of how 4.3BSD does it, mine is that it uses simple timers which delete completed entries 20 minutes after creation. Vernon Schryver, vjs@sgi.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1331@vaxeline.COM] <1991022402282200> From: backman@vaxeline.COM (Larry Backman) Newsgroups: comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Looking for OS/2 TCP/IP products with RFC 1001/1002 Message-ID: <1331@vaxeline.COM> Date: 24 Feb 91 02:28:22 GMT References: <4432@se-sd.SanDiego.NCR.COM> Reply-To: backman@vaxeline.ftp.com.UUCP (Larry Backman) Organization: FTP Software, Inc. Lines: 28 In article <4432@se-sd.SanDiego.NCR.COM> nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) writes: > >Hello OS/2 Users or Programmers! > >We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via >RFC 1001/1002. Can you offer any recommendations? I understand that >3Com offers a TCP/IP product for OS/2, but I don't know any details. I >would be most interested in the "more popular" TCP/IP-for-OS/2 products >on the market. > TCP/IP's for OS/2 that I am aware of: FTP Software V1.1 (in beta right now) supports RFC 1001/2 NETBIOS 3Com's 3+TCP for LAN Mgr supports RFC 1001/2 Netbios. It has been shipping for a while. IBM TCP/IP for OS/2 V1.1 does not to my knowledge support Netbios. Ungermann-Bass is rumored to have an OS/2 TCP Netbios. I have not seen it. Excelan (now Novell) once shipped LAN Workplace for OS/2 w/ TCP & Netbios. I have no idea if it still is shipping. Racal-Interlan once shipped NP628, an intelligent card TCP/NETBIOS which ran under OS/2. I believe they have discontinued the product. Thats the list that I am aware of. Larry Backman ----MESSAGE-END---- ----MESSAGE-BEGIN---- [792@dynasys.UUCP] <1991022417441200> From: jessea@dynasys.UUCP (Jesse W. Asher) Newsgroups: comp.protocols.tcp-ip Subject: Can a forwardee be a forwarder? Message-ID: <792@dynasys.UUCP> Date: 24 Feb 91 17:44:12 GMT Reply-To: jessea@dynasys.UUCP (Jesse W. Asher) Organization: Dynasys: Consulting for the Future. Lines: 8 I'd like to know if a UUCP site that has a domain name and a forwarder can itself be a forwarder for another UUCP site so that site can get a domain name? It would seem like a reasonable assumption, but.... ---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*--- Jesse W. Asher Phone: (901)382-1609 6196-1 Macon Rd., Suite 200, Memphis, TN 38134 UUCP: {fedeva,chromc,rutgers}!dynasys!jessea ----MESSAGE-END---- ----MESSAGE-BEGIN---- [39557@cup.portal.com] <1991022421421000> From: Will@cup.portal.com (Will E Estes) Newsgroups: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: What Is Difference Between Internet And X.400 Style Names? Message-ID: <39557@cup.portal.com> Date: 24 Feb 91 21:42:10 GMT Organization: The Portal System (TM) Lines: 14 Can someone please explain the difference between X.400 and Internet-style names of the form: USER@SITE.DOMAIN? I had thought that X.400 names were of the form /THIS=,/THAT=,/ANDWHATEVER=. Recently, two things made me question this. First, someone told me that the USER@SITE.DOMAIN was an X.400 standard. Second, I noticed that PSI offers an X.500 service as part of their TCP/IP public data network PSInet. Their advertising literature seems to imply that the X.500 database holds addresses of the USER@SITE.DOMAIN type. I understand that "bang" style names are unique to UNIX (a derivative of UUCP), but are the USER@SITE.DOMAIN style names X.400 or UNIX standards, and what is the relationship to the longer addressing form /THIS=,/ETC=? Thanks, Will Estes (apple!cup.portal.com!Will) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [B47A485D5BFF012862@vax1.umkc.edu] <1991022423300000> From: PH461A04@VAX1.UMKC.EDU (Guerra de Bureau) Newsgroups: comp.protocols.tcp-ip Subject: Certified Mail Systems... Message-ID: Date: 24 Feb 91 23:30:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 29 Regarding a protocol for SMTP certified mail, can anyone suggest why the following procedure would not work?? 1) Local mail system encrypts mail with time-varying key 2) Local system forwards mail to remote system 3) Remote system delivers (encrypted) mail to designated user 4) Designated user requests key from remote system 5) Remote system requests key from local system 6) Local system indicates to message originator that message has been received and key requested. 7) Local forwards key to remote 8) If remote system does note recieve key withing (x) units, repeats request for (y) tries before informing recipient key unavailable 9) Remote delievers key to remote user/unencrypts original message The only failure that I see is if a) the remote system requests the key from the local system; b) the local system acknowledges the request, and c) the anknowlegment(key) never gets back to the remote, and finally d) the remote is not able to re-request the key within the designated time frame. Given the increasing network reliability and the decreasing network transfer time and a sufficient number of retries/length of time before discard this system would seem fairly secure. Any problems?? Jonathan E. Oberg ph461a04@vax1.umkc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb25.001103.20970@bigsur.uucp] <1991022500110300> From: mussar@bcars53.uucp (G. Mussar) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP/IP over X25 Message-ID: <1991Feb25.001103.20970@bigsur.uucp> Date: 25 Feb 91 00:11:03 GMT References: <1991Feb15.235715.21152@Think.COM> <1991Feb17.163237.17152@informatik.uni-erlangen.de> Sender: news@bigsur.uucp Reply-To: mussar@bnr.ca (G. Mussar) Organization: Bell-Northern Research, Ottawa, Canada Lines: 13 In article <1991Feb17.163237.17152@informatik.uni-erlangen.de> eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes: > >Real life experience: Sun3/50: 9.6kbps, Sun3/xx(other than 3/50): 19.2kbps, >Sun4/xxx: 64kbps - all over CPU ports. MCP ports 64kbps each, HSI 2Mbps. > I know the documentation for Sun4 ports indicates 64Kbps max, however, running the port at 19.2Kbps shows large numbers of underruns when various tasks are running. -- ------------------------------------------------------------------------------- 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---- [910225.140127.+0100.af@sei.ucl.ac.be] <1991022513012700> From: af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD) Newsgroups: comp.protocols.tcp-ip Subject: Re: LPR as RFC 1179 (was: Is there a protocol for remote printing) Message-ID: <910225.140127.+0100.af@sei.ucl.ac.be> Date: 25 Feb 91 13:01:27 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 On Sun, 24 Feb 91 14:46:18 EST Bruce Crabill said: > A true LPR spec needs to be done, but >RFC 1179 isn't it. > > Bruce I would say: a true remote printing protocol, useful in a scope a little larger than one operating system, needs to be defined, but lpr isn't it. /AF ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb25.153352.14063@engin.umich.edu] <1991022515335200> From: jaynes@med.umich.edu (William Jaynes) Newsgroups: comp.protocols.tcp-ip Subject: Sendmail/SMTP/TCP mystery? Message-ID: <1991Feb25.153352.14063@engin.umich.edu> Date: 25 Feb 91 15:33:52 GMT Sender: news@engin.umich.edu (CAEN Netnews) Reply-To: jaynes@med.umich.edu (William Jaynes) Organization: University of Michigan Health Sciences, Ann Arbor Lines: 44 Originator: jaynes@ives.itn.med.umich.edu Someone felt that this problem may be a more general TCP protocol discrepancy causing packets to be lost or ignored, so here is what I have posted elsewhere.. ---------- Last week I noticed that messages to a particular host were being queued on my mailhub. The sendmail message is (Deferred: Connection timed out during result wait with uv1.im.med.umich.edu) These messages never get delivered. All attempts fail until they time out and are bounced. The mailhub is a SunSLC. The host in question is a Vax running some Wollengong TCP-IP/SMTP etc. software. Up until last week there was not a problem. Both of us sys admins swear that we haven't changed anything. (of course) Here are some facts: - A short message (less then about 1100 bytes) will be delivered. A longer message will not. - I forced my Suns (4.1 and 4.1.1) to skip the mailhub and mail direct and got the same results: longer messages were queued with the same deferred message. - I forced my Decs (Ultrix 4.0) to skip the mailhub and mail direct and did NOT get the same results. Mail worked fine. - From my Suns, if I telnet to port 25 of the Vax and fake mail, I can send as big a message as I want. - From Suns that are not on my net (141.214) and which mail direct to the Vax, I can send as big a message as I want. (One is 4.0.3c) - This one Vax is the ONLY host with which there is a problem. Other Vaxen on the same ethernet don't have a problem. (I don't know if the other Vaxen use the same SMTP software.) - The data files are properly terminated with a 0x0a. Using a Sniffer, I looked at packets during delivery attempts that failed. The Suns simply aren't sending a . after the data is sent. Instead they send the data again and again until the connection times out. But they do send . on the short messages. Why this one Vax? Why the Suns and not the Decs? What's going on? ------- I have since seen that the SUNs and DECs are conifgured NOTRAILERS. Doing an ifconfig on the VAX doesn't give a reference to trailers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910225094159740-DSB*Wesley.R.Palmer@dsb.cpg.cdc.com] <1991022515441400> From: Wesley.R.Palmer@DSB.CPG.CDC.COM Newsgroups: comp.protocols.tcp-ip Subject: CDCCENTR BITNET subscriptions Message-ID: <910225094159740-DSB*Wesley.R.Palmer@dsb.cpg.cdc.com> Date: 25 Feb 91 15:44:14 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Please remove all subscriptions to users at BITNET node CDCCENTR. We are no longer BITNET members. Wes Palmer BITNET Tech Rep Control Data Corporation ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102262104.AA02685@ucbvax.Berkeley.EDU] <1991022515500400> From: dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton") Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP <--> IBM network (link?) Message-ID: <9102262104.AA02685@ucbvax.Berkeley.EDU> Date: 25 Feb 91 15:50:04 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 > I've just a simple question: a friend of mine, who's working at IBM > and uses the IBM-network, wonders if there is a way for him to access > this network we are all using directly from his IBM-terminal (he's > working in under VM/CMS and MVS/TSO-E and uses IBMtype adresses: NAME > at NODE)? How, if the physical link between the two networks actually > exists, should he write the adresses to be understood by TCP/IP? > > Does anybody know anything about this? IBM has an SMTP mail gateway that allows IBM employees to send and receive mail to and from the Internet. SMTP addresses are of the form: %.IINUS1.IBM.COM (no MX support) or @.IINUS1.IBM.COM (with MX support) Note that this is a restricted mail gateway running IBM's TCP/IP Version 2 for VM Secure Mail Gateway code, and IBM employees must first be authorized before they can use the gateway. If you have specific questions about the gateway, write: postmaster@iinus1.ibm.com Daniel ======================================================================== Daniel M. Barton TCP/IP Development IBM Research Triangle Park, NC Internet: dmbarton@ralvmm.iinus1.ibm.com dmbarton%ralvmm@iinus1.ibm.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- ["25-Feb-91.11:32:25.EST".*.Steven_V_Rosekrans.Roch817@Xerox.com] <1991022516322500> From: Steven_V_Rosekrans.Roch817@XEROX.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: LPR as RFC 1179 (was: Is there a protocol for remote printing) Message-ID: <"25-Feb-91.11:32:25.EST".*.Steven_V_Rosekrans.Roch817@Xerox.com> Date: 25 Feb 91 16:32:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 5 Does anyone within Xerox know of a repository of RCPs. I'd like to get a copy of 1179 -- info regarding LPR. Thanks, --STEVE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102251655.AA23563@gaak.LCS.MIT.EDU] <1991022516552500> From: MAP@LCS.MIT.EDU (Michael A. Patton) Newsgroups: comp.protocols.tcp-ip Subject: interest group mail from From: field handling Message-ID: <9102251655.AA23563@gaak.LCS.MIT.EDU> Date: 25 Feb 91 16:55:25 GMT References: <9102201702.AA20162@desktalk.desktalk.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 23 Date: Wed, 20 Feb 91 09:02:42 PST From: rlg@desktalk.com (Richard L. Gralnik) Hi. Whenever someone posts to an interest group (e.g. tcp-ip), the mail the rest of us receive as part of the distribution of that posting shows tcp-ip-RELAY@NIC.DDN.MIL in the From: field of the header. I think your local mailer is at fault. As you can see above, your message arrived here with a proper "From:" field. The SMTP envelope did contain tcp-ip-RELAY@nic.ddn.mil, but that should only be used for bounces (and I appreciate their doing that so I don't see the bounces when I post :-). I suspect some local mail delivery system at your end or your mail user agent is misinterpreting the RFC822 header and/or the RFC821 envelope. __ /| /| /| \ 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---- [9102251755.AA19933@ucbvax.Berkeley.EDU] <1991022517551200> From: HANK@VM.BIU.AC.IL (Hank Nussbacher) Newsgroups: comp.protocols.tcp-ip Subject: MANs Message-ID: <9102251755.AA19933@ucbvax.Berkeley.EDU> Date: 25 Feb 91 17:55:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 X-Unparsable-Date: Mon, 25 Feb 91 16:26:04 IST I am looking for technical information comparing the various MAN technology that has emerged over the past year: SONET, DQDB, SMDS, IEEE 802.6, ANSI X3T9.3, Frame Relay, etc. I need to possibily give a presentation next week and would appreciate any postscript graphs or pictures or any other material that compares the various technologies and where they stand today. If anyone has a preliminary RFC or some document discussing all this, I would love to get a copy of it. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb25.185436.11447@watserv1.waterloo.edu] <1991022518543600> From: broehl@watserv1.waterloo.edu (Bernie Roehl) Newsgroups: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: Re: What Is Difference Between Internet And X.400 Style Names? Message-ID: <1991Feb25.185436.11447@watserv1.waterloo.edu> Date: 25 Feb 91 18:54:36 GMT References: <39557@cup.portal.com> Organization: University of Waterloo Lines: 33 In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Can someone please explain the difference between X.400 and Internet-style >names of the form: USER@SITE.DOMAIN? I had thought that X.400 names >were of the form /THIS=,/THAT=,/ANDWHATEVER=. They are. The standard syntax "user@site.domain" is used throughout the Internet (and beyond!). The "/this=,that=" is unique to X.400, which is part of the OSI spec. >First, someone told me that the USER@SITE.DOMAIN was an X.400 standard. They were mistaken. I much prefer the user@site.domain, since it's shorter and easier to remember than "/admd=domain,/prmd=site,/name=user". >Second, I noticed that PSI offers an X.500 service as part of their >TCP/IP public data network PSInet. Their >advertising literature seems to imply that the X.500 database holds >addresses of the USER@SITE.DOMAIN type. It's my understanding that X.500 databases can hold addresses in just about any format, including physical street addresses. >are the USER@SITE.DOMAIN style names X.400 or UNIX standards Neither -- they're standard throughout the entire Internet, which includes many Unix systems, VMS systems, VM systems, DOS systems, Macintoshes, etc etc. -- Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: {allegra,decvax,utzoo,clyde}!watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102251927.AA27889@gateway.mitre.org] <1991022519271700> From: hal@GATEWAY.MITRE.ORG (Hal Feinstein) Newsgroups: comp.protocols.tcp-ip Subject: UDP 901 info needed Message-ID: <9102251927.AA27889@gateway.mitre.org> Date: 25 Feb 91 19:27:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 7 In our IP trace we see UDP protocol port 901 in some datagrams. However, I can't find anything that tells me what protocol or system this might be associated with. Has anyone come across UDP 901 before and can supply some info on it?? Thanks in advance -Hal. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb25.214152.27244@prism.poly.edu] <1991022521415200> From: drubin@prism.poly.edu (Dave Rubin) Newsgroups: comp.sys.att,comp.protocols.tcp-ip Subject: WIN-TCP Problem on 3B2/500 Message-ID: <1991Feb25.214152.27244@prism.poly.edu> Date: 25 Feb 91 21:41:52 GMT Reply-To: drubin@prism.UUCP (Dave Rubin) Organization: Polytechnic University, New York Lines: 23 We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is running System V Release 3.2.1. We are experiencing several annoying problems, most which have been around since the earliest versions of WIN-TCP: unstable network connections that are closed for no reason, daemon's (mostly sendmail) going into bad states, not accepting connections or producing file-related errors, streams functions failing on various programs, system crashes due to Kernel MMU fault, NFS/OpenLook totally broken. Lately we cannot even get sendmail to work at all (although it does work on another almost identical 3B2/500). Needless to say, the situation is unacceptable. I have heard that version 3.2 of WIN-TCP has been released. Does anyone know if this latest version fixes any of the problems stated above? Or do I need to look into an alternative to these 3B2 systems that can't seem to behave themselves on the network? Any help would be appreciated... -- Dave Rubin Polytechnic University Brooklyn, New York ----MESSAGE-END---- ----MESSAGE-BEGIN---- [910225182114328-DSB*Wesley.R.Palmer@dsb.cpg.cdc.com] <1991022600215100> From: Wesley.R.Palmer@DSB.CPG.CDC.COM Newsgroups: comp.protocols.tcp-ip Subject: Whoops Message-ID: <910225182114328-DSB*Wesley.R.Palmer@dsb.cpg.cdc.com> Date: 26 Feb 91 00:21:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Sorry about that last message. I pasted in the wrong address. It was meant for tcp-ip-request. Wes Palmer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102260055.AA03710@nswc-wo.navy.mil] <1991022600555600> From: dlove@NSWC-WO.NAVY.MIL (Donnie Love) Newsgroups: comp.protocols.tcp-ip Subject: PSN Questions Message-ID: <9102260055.AA03710@nswc-wo.navy.mil> Date: 26 Feb 91 00:55:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 16 Hi, I have some detailed PSN questions and apologize if this is the wrong group. 1) Is there a limitation to the number of virtual circuits that a PSN will allow a particular host for X.25 Standard connections? I need 64. 2) What are the chances (slim, probably, definitely) that I can always get up to 64 virtual circuits when my host requests them? 3) Will a PSN close a virtual circuit which has been idle for a period of time? If so, what is the timer value in the PSN? Please reply directly to me because I am not on the list, and I'll repost. -Donnie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102260100.AA03112@dalek.isi.edu] <1991022601002800> From: finn@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: ICMP Source Quench questions Message-ID: <9102260100.AA03112@dalek.isi.edu> Date: 26 Feb 91 01:00:28 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 49 Marten Terpstra, ICMP Source Quench messages may be issued by a gateway when that gateway becomes heavily loaded (congested). The congested gateway picks a message and sends a Source Quench back to that message's source. The original message is then discarded by the gateway. The idea is that the source will notice this and cut down on its rate of transmission. That in turn soon decreases the affected gateway's congestion. The throughput of a gateway is linear as it approaches overload but can fall to zero quickly. Consider throughput as the vertical axis and offered load the horizontal axis and ignore scale. As load rises from zero, the graph slope is positive to a knee, then flattish as the gateway's processing limit is closely approached, then another knee and a rapid descent asymptotically toward zero. Source Quench is a way of telling you that the second knee has been reached. The hope is that if enough sources cut their rates of transmission, the gateway's operating point moves quickly back to the left of the catastrophe. 1) How is the message picked? Well, it was envisioned that whenever a gateway had a queue overflow, the message that caused the overflow would be chosen for Source Quench. It turns out that many gateways generate them only for SOME of the messages that cause a queue overflow and not all. That is because no mechanism to force sources to slow down in response to receiving a Source Quench was adopted as a standard. However, that may change. 2) Newer implementations of TCP (incorporating Van Jacobson's code) treat the receipt of a Source Quench message as evidence of a message lost due to congestion and do slow down for a time as a result. If you run Berkeley UNIX there is a high probability that you are running this TCP. Research is underway that may place code into source IP modules that looks for Source Quench messages. 3) Will ICMP Source Quench messages cause a network is down condition. No, not by themselves. If a gateway's routing tables indicate that a network is unreachable, only then should it send a Network Unreachable version of the ICMP Destination Unreachable message. This is my understanding. I hope that this has helped you. --- ggf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [287@iscden.jbsys.com] <1991022603503000> From: jbev@iscden.jbsys.com ( J B Systems) Newsgroups: comp.protocols.tcp-ip Subject: Looking for mil spec archive Keywords: TCP IP specs Message-ID: <287@iscden.jbsys.com> Date: 26 Feb 91 03:50:30 GMT Organization: J B Systems on HiPeak, Morrison, Co. Lines: 6 I have received a spec which references MS 1777 (IP) and MS 1778 (TCP). I have the rfc's to tcp and ip, but where can I find an archive for the mil standards? Any help would be welcome. Jim Bevier jbev@jbsys.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1916@public.BTR.COM] <1991022606581900> From: thad@public.BTR.COM (Thaddeus P. Floryan) Newsgroups: comp.sys.att,comp.protocols.tcp-ip Subject: Re: WIN-TCP Problem on 3B2/500 Message-ID: <1916@public.BTR.COM> Date: 26 Feb 91 06:58:19 GMT References: <1991Feb25.214152.27244@prism.poly.edu> Followup-To: comp.sys.att Organization: BTR Public Access UNIX, MtnView CA, Contact: cs@btr.com 415-966-1429 Lines: 38 In article <1991Feb25.214152.27244@prism.poly.edu> drubin@prism.UUCP (Dave Rubin) writes: >We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is >running System V Release 3.2.1. > >We are experiencing several annoying problems, most which have been around >since the earliest versions of WIN-TCP: unstable network connections that >are closed for no reason, daemon's (mostly sendmail) going into bad states, >not accepting connections or producing file-related errors, streams >functions failing on various programs, system crashes due to Kernel MMU >fault, NFS/OpenLook totally broken. Lately we cannot even get sendmail >to work at all (although it does work on another almost identical 3B2/500). >Needless to say, the situation is unacceptable. >[...] Sigh. Looks like not much has changed since their version 1.4 for the 3B1. After some dorking-around with device driver loading, I have managed to find a configuration that "works" ... at least my sytstems have been up since November 1990 and I do a lot of 'net trafficking. HOWEVER: I had to trash a bunch of the "stock" WIN/3B stuff and port over parts of the networking software suite from 4.3BSD "Tahoe" (as found at UUNET), and some other 3B1-aficianados have ported over some other stuff. The WIN/3B sendmail and its daemon is total garbage ... would fill up the process table with defunct processes if one so much as sneezed in the same room, so I tossed it out the window and over the fence to accompany other bad software ... now I'm worrying the fence may collapse. :-) A colleague is bringing up a new sendmail (ported from the BSD world) for the 3B1 and this stuff "should" also work on the 3B2 (but I have NO way of checking). The 3B1 archive site is osu-cis (aka cheops.cis.ohio-state.edu) where you can find some of this stuff as well as in comp.sources.3b1 soon. If you have all the include files and socket library stuff, you may wish to try some of the 3B1 ports. No help possible with NFS, though, since that feature "level" never made it into the 3B1 product. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102261203.AA00606@fiamass.ie] <1991022612032300> From: sean@noname.UUCP (Sean Mc Grath) Newsgroups: comp.protocols.tcp-ip Subject: rcp problems with PC/TCP Message-ID: <9102261203.AA00606@fiamass.ie> Date: 26 Feb 91 12:03:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 We have a network consisting of a bunch of PCs and a Sun machine. The SUN is a SPARC 1+ running SunOS 4.1. The PCs use 3COM ethernet cards and PC/TCP from FTP. We use the rcp command provided by PC/TCP from FTP. Nine times out of ten the rcp works fine. By runing ps on the SPARC we see things like :- karl 2231 0.0 0.0 44 0 ? IW 10:23 0:00 rcp -f result.s karl 2230 0.0 0.0 64 0 ? IW 10:23 0:00 csh -c rcp -f result.s So it would seem that the rcp caused a csh shell to run the rcp. The only funny thing here is that the rcp command takes a -f option. It is not documented under SunOS and seems to cause any rcp to sit around forever. Anyway the copy works fine. however from time to time we get a hang on the PC end doing an rcp. When this happens ps on the SPARC yields things like :- root 2231 0.0 0.0 44 0 ? IW 10:23 0:00 rcp -f result.s karl 2230 0.0 0.0 64 0 ? IW 10:23 0:00 csh -c rcp -f result.s I.e. it looks as if the spawned rcp command is running as root! We end up rebooting the PC and killing off the csh and rcp processes. I've used trace(1) to watch the system calls that inetd is making to handle our rcp's but the results are the same irrespective of whether or not the PC hangs. Has anyone any idea what is going on? Thanks in advance. Sean Mc Grath (sean@fiamass.ie) 12 Clarinda Park North Dun Laoghaire Co. Dublin Ireland. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.150141.6430@ugle.unit.no] <1991022615014100> From: hta@isolde.Berkeley.EDU (Harald Tveit Alvestrand) Newsgroups: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: Re: What Is Difference Between Internet And X.400 Style Names? Message-ID: <1991Feb26.150141.6430@ugle.unit.no> Date: 26 Feb 91 15:01:41 GMT References: <39557@cup.portal.com> Sender: news@ugle.unit.no Reply-To: harald.alvestrand@elab-runit.sintef.no Organization: ELAB-RUNIT, SINTEF, Norway Lines: 22 In article <39557@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes: I had thought that X.400 names |> were of the form /THIS=,/THAT=,/ANDWHATEVER=. You were right. BUT............ 1) There exists an RFC called RFC-987 (see also RFC-1148) that specifies how to map X.400 addresses to RFC format addresses and the other way round, using a big, ugly table called "the RFC-987 mapping table". See, for example, the two formats of my address below; they are the SAME mailbox. 2) The format /THIS=... is ONE of the possible ways to write an X.400 address (you might think that this is nitpicking until you encounter another one :-) 3) X.500 can store anything. We use it today to store (among other things) X.400 mailbox names and RFC-822 mailbox names. Confused? You are not alone! Harald Tveit Alvestrand Harald.Alvestrand@elab-runit.sintef.no C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald +47 7 59 70 94 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.172603.22618@cbnewsd.att.com] <1991022617260300> From: cage@cbnewsd.att.com (charles.gerlach) Newsgroups: comp.protocols.tcp-ip Subject: Re: WIN-TCP Problem on 3B2/500 Message-ID: <1991Feb26.172603.22618@cbnewsd.att.com> Date: 26 Feb 91 17:26:03 GMT References: <1991Feb25.214152.27244@prism.poly.edu> <1916@public.BTR.COM> Organization: AT&T Bell Laboratories Lines: 26 Posted: Tue Feb 26 11:26:03 1991 Folks: Here we go again. Trashing products based upon rumors, innuendos, and mis-information. I empathize with your 3B1 dilemma, but to compare that to the current AT&T WIN/3B product is wrong. The 3B2 product was produced by TWG approximately 4 years ago as a totally separate product from the 3B2 and 386 lines. Since then there have been 3 major releases of the other lines (R2.1, R3.0.1/R3.0, and R3.2). I just checked with AT&T's support organization and Release 1.4 is the current 3B1 WIN product. Its my understanding this product is not under active development, so R1.4 is all there every will be on the 3B1. Now to get back to the original question. Around Christmas, Release 3.2 of WIN/3B and WIN/386 became generally available. This release consolidates the available R3.0.1/R3.0 patches and other changes to improve the functionality of the products. Release 1.2 of NFS is also available. To upgrade from a previous release, please contact your AT&T support organization or your salesperson. If they have any problems, tell them to contact the product manager, Tim Trautman, for information on the upgrade procedure. Chuck Gerlach cag@iwlcs.att.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [15511@uudell.dell.com] <1991022617375200> From: mjhammel@Kepler.dell.com (Michael J. Hammel) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for source for CUTP Keywords: Clarkson CUTP tcpip ncsa Message-ID: <15511@uudell.dell.com> Date: 26 Feb 91 17:37:52 GMT References: <172@rand.mel.cocam.oz.au> Sender: news@uudell.dell.com Reply-To: mjhammel@Kepler.dell.com (Michael J. Hammel) Organization: Dell Computer Corp. Lines: 15 In article <172@rand.mel.cocam.oz.au>, sgs@rand.mel.cocam.oz.au (Stuart Szabo) writes: > Does anyone know where I can file request the Clarkson University's > version of NCSA's telnet and ftp? The current version of CUTCP (Clarkson's version of NCSA Telnet) is available for FTP from omnigate.clarkson.edu:pub/cutcp/2.2-C/tc.cutcp.zoo Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Recycle. Just do it." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.181450.21346@walt.disney.com] <1991022618145000> From: scott@walt.disney.com (Scott Watson) Newsgroups: comp.dcom.lans,comp.protocols.tcpip Subject: Laser (optical) bridges for Ethernet Keywords: 802.3 Ethernet Laser Bridges Message-ID: <1991Feb26.181450.21346@walt.disney.com> Date: 26 Feb 91 18:14:50 GMT Sender: scott@walt.disney.com (Scott Watson) Organization: Walt Disney Imagineering Lines: 12 Does anybody out there have any information optical (LASER) 802.3 bridges for use out of doors?? We have some buildings that we would like to connect, but dread running cable... any experiences with doing this??? Vendors?? Thanks in advance -- Scott Watson / Walt Disney Imagineering scott@walt.disney.com #ifdef SANE #include #endif ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.153030.42@kahuna.asd-yf.wpafb.af.mil] <1991022620303000> From: nieland_t@kahuna.asd-yf.wpafb.af.mil Newsgroups: comp.protocols.tcp-ip Subject: How to set up PTR records Message-ID: <1991Feb26.153030.42@kahuna.asd-yf.wpafb.af.mil> Date: 26 Feb 91 20:30:30 GMT Organization: USAF ASD/YF, WPAFB, Dayton, OH Lines: 11 I am looking for a good explaination how to set up the PTR records for a subnet. I have the records defined for my subnet and they seem to be working on my system, but they are not being found on any other system in inquire. Some of the people I have been asking around here don't have a good idea on how to set up the PTR system, so I can use any suggestions. Ted Nieland nieland_t@kahuna.asd-yf.wpafb.af.mil Control Data Corporation nieland@dayfac.cdc.com (513) 427-6355 ted@nieland.dayton.oh.us ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102262055.AA00694@buit13.bu.edu] <1991022620553300> From: kwe@BU-IT.BU.EDU (Kent England) Newsgroups: comp.protocols.tcp-ip Subject: Compressed Video Transport Requirements Summary Message-ID: <9102262055.AA00694@buit13.bu.edu> Date: 26 Feb 91 20:55:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 250 I didn't get an answer to my question, but I did get some info on the new ISO standards for compression of still frames and motion pictures (correlated frame sequences, actually). Herewith is what I got, including news on a satellite broadcast system that is going to use compression to get more channels to the end-user. You might want to check out comp.ivideodisc, comp.multimedia, comp.graphics, rec.video.satellite for more info. --Kent _________________________ From c3!c3.PLA.CA.US!rww@fernwood.mpk.ca.us Wed Feb 13 05:43:16 1991 Date: Wed, 13 Feb 91 02:26:55 PST From: rww@c3.PLA.CA.US (Richard W. Webb) To: kwe@bu.edu, barmar@think.com Subject: Video Compression Newsgroups: comp.protocols.tcp-ip Organization: C-Cube Microsystems, San Jose, CA I have a keen interest in the use of video compression in a networked environment. I have collected a number of articles describing what is available. I have edited it, so be forewarned that this is a somewhat biased viewpoint. JPEG is a Still-image compression technique. Video is generated by rapidly displaying consecutive independent frames. MPEG is a Moving Picture approach that utilizes some of the similarities that exist between consecutive frames. It also includes sound compression and a number of other "system" features. Both of these approaches have problems, but, in some sense, they represent a "optimal" tradeoff between complexity and quality. They are also highly parameterized and allow a broad adjustment in capabilities. One final note on bandwidth requirements. Both standards make allowances for fixed-rate transmission and reception. This fixed rate can be updated periodically (at the encoder end) based, say, on an extimate of network congestion. The update rate can be sent, at most, once per frame (60 or 50 frames per second), but once per 6 or 10 frames is more typical. ======================================================================= From: cnh5730@calvin.tamu.edu (Chuck Herrick) Date: 8 Feb 91 16:57:29 GMT Organization: Geodynamics Research Institute, Texas A&M University Lines: 36 JPEG stands for Joint Photographers Engineering Group or some such, and this is a "standardizing body" which has formalized a 2-d (thus useful for images) compression/decompression scheme which uses a modified cosine transform to "do its thing." Right now, the JPEG compression sceme is "cutting edge" in the image processing game. Please note that the JPEG compression is what the folks in the trade call "lossy"... this means that you may lose at least some information in the compression process (you might be pretty impressed at the fact that in many cases, you can't see the difference between an original image and its compressed-decompressed sibling). JPEG is neither strictly hardware nor strictly software. A company called C-Cube is in the process of trying to implement the JPEG modified cosine transform compression/decompression algorithm in a chip (i.e. in hardware). When, and if, they succeed, the C-Cube chip will allow real-time compression, and will be great for real-time video grabbing. However, the chip is still in process, and until someone gets a bug-free JPEG chip to the market, one will need to implement the JPEG algorithm in software. ======================================================================= >From: jim@newmedia.UUCP (Jim Beveridge) Newsgroups: comp.ivideodisc,comp.multimedia Subject: Re: DVI questions Date: 15 Jan 91 15:09:30 GMT Organization: New Media Graphics, Billerica, MA The first chip to do JPEG is from C-Cube, and they are currently only shipping the still frame version of the chip. The real time version is still not available. Even in compressed form, the bandwidth required for a full JPEG screen far exceeds the abilities of an IBM bus to transfer. (I don't believe it to be a problem for the Apple NuBus) JPEG still requires LOTS of data moving around. To keep track of it, you pretty much require the full resources of the system to move it off the hard disk and pump it into the chip fast enough. Of course, there are ways around this problem with a private bus and private hard drives, but that is $$$. The MPEG standard is still under discussion and won't be ready for at least a year. Don't expect commercially available MPEG boards for a couple of years. DVI is shipping now, but is VERY expensive, particularly for the production level video that requires that you send a tape to Intel. The "home-brew" comperssion that the DVI chips now do is very grainy and not suitable for production. The good news is that the production level does not require almost the entire power of the CPU to keep the picture running. Jim ======================================================================= From: jandreas@pro-graphics.cts.com (Jason Andreas) Newsgroups: comp.graphics Subject: Re: JPEG in VLSI Date: 26 Jan 91 07:56:21 GMT C-Cube MicroSystems 399-A West Trimble Road San Jose, CA 95131 voice. (408) 944-6300 fax. (408) 944-6314j Ask for Jill Milton or Clint Chao. ====================================================================== From: ltran@pluton.matrox.com (Linh TRAN) Newsgroups: comp.graphics Subject: Re: Animation Standards JPEG Date: 30 Jan 91 21:49:37 GMT Organization: Matrox Ltd. I think MPEG is working on standard for motion picture (animation and sound included). The MPEG uses fundamentally the same algorithm regarding compression scheme (it use Discrete Cosine Transform, follow by Quantization of coefficients and Huffman encoding, for intra frame compression). JPEG mandate is to arrive at photographic resolution compression. ====================================================================== Yakov Rekhter of IBM was kind enough to forward this on to me. -kwe ____________________________________________ From YAKOV%YKTVMZ@IBM.COM Thu Feb 21 08:23:57 1991 Date: Thu, 21 Feb 91 08:19:27 EST From: YAKOV@IBM.COM To: bu-it.bu.edu!kwe@uunet.UU.NET Subject: compressed video transport requirements From: andre@rail.mentor (Andre' Hut) Newsgroups: rec.video.satellite,misc.consumers,misc.consumers.house Subject: SkyPix cooks up home satellite dish for $700 Message-ID: Date: 6 Feb 91 17:43:13 GMT Sender: Unknown@caeco.UUCP Organization: /net/rail/home/andre/.organization Lines: 170 [Reprinted without permission from Electronic Engineering TIMES, Jan. 21, 1991, by Richard Doherty] Skypix brings home 80 channels of digitized TV - ---------------------------------------------- Two-foot dish, set-top digital decoder will be priced at $699 -24-inch parabolic reflector -Cassegrain signal mirror -Ten channels of digitally compressed programming -Ku-band GaAs downconverter (12Ghz) -Infrared Remote -Phone connection for credit ordering -Stereo, 480-line NTSC video Las Vegas, Nev. -- The cable TV and backyard satellite dish industries are girding for a new challenge: the first window-mount home satellite system available in the U.S. SkyPix (Kent, Wash.) offered a sneak preview of its compact dish system at last week's Consumer Electronics Show here and will be on hand at this week's Satellite Business Communications Association show, also to be held here. The startup expects to begin selling systems through retail channels this summer for about $700. SkyPix hopes to tap digitial compression technology licensed from Compression Labs Inc. and advanced Ku-band digital RF modulation to deliver home programming at a price that will challenge existing cable TV and larger C-band satellite systems. Initially, SkyPix will offer up to 80 channels of video programming, but the system's decoder, a set-top box based on three VLSI chips, will be able to receive up to 250 channels when more powerful satellites are launched later this decade. ... The SkyPix system achieves a data-compression rate of 54 to 1 by using Sun Microsystems Inc. computers operating at 150 Gflops along with digital- compression technology licensed from Compression Labs Inc. With compression, each channel requires just 2.2 Mbits/second for video and audio, down from a source data rate of 120 Mbits/s. Error-correction overhead brings the total channel requirement to 3 Mbits/s. The 10 Ku-band channels that are decoded from an RF tuner section that includes three custom LSI chips. These chips that the 160 Mhz fo 80 channel data and extract specific TV images, stereo sound and data. SkyPix said it will purchase Ku-band GaAs down-converter assemblies from a number of sources. These devices change the 12-Ghz incoming satellite signal into a UHF-band signal that is easier to convey on low-cost coaxial cable. Once the antenna is aimed at the Hughes SBS-6 satellite, it can be mounted under the eaves of a house, on its roof or side or on the ground. At 12-Ghz Ku-band frequencies, satellite antennas usually are subject to one nagging problem: signal absorption during rainfalls. In the satellite industry, signal fades tied to local downpours are referred to as rainouts. But because of advanced digitial modulation and error-correction technology, rainouts are not expected to be a problem, according to SkyPix. The SkyPix system sports a signal reserve of 5db. In severe cases in which total signal interruptions occur -- such as when an aircraft flies over the antenna -- the system will lock into a digitial freeze-frame until the signal is restored. In demonstrations viewed by EE Times at the Winter Consumer Electronics Show last week, most of the video channels shown displayed better than TV-broadcast quality. Eight channels were shown operating at one time, fed by a 36-inch satellite dish. Image color depth was excellent, and video resolution was above NTSC standards. However, during some fast-moving action scenes, there were moments when the digital compression could not keep up with screen refresh demand. At these times, much of the picture turned grainier, as the digital compression tried to keep up with deltas from one frame to the next. Overall, the images were free from RF signal ghosting and coaxial reflection that plague some cable TV systems. -- Richard Doherty - -- - ------------------------------------------------------------------- Andre' Hut {mntgfx,utah-cs}!caeco!andre Mentor Graphics, Suite 300, 5295 South 300 West, Murray, Utah 84107 - ------------------------------------------------------------------- ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.224923.14252@athena.mit.edu] <1991022622492300> From: bamakati@athena.mit.edu (Ayisi B. Makatiani) Newsgroups: comp.protocols.tcp-ip Subject: problems with snmpd.conf on sun Keywords: snmpd.conf,snmpd Message-ID: <1991Feb26.224923.14252@athena.mit.edu> Date: 26 Feb 91 22:49:23 GMT Sender: news@athena.mit.edu (News system) Reply-To: bamakati@athena.mit.edu (Ayisi B. Makatiani) Organization: Massachusetts Institute of Technology Lines: 10 I compiled MIT's snmpd on a SparcStation 370 after messing around with the sources and tried to query it from a Decstation in Ultrix. To do this, I needed snmpd.conf which I copied from Ultrix 4.0 but my queries are not replied to by the Sparc. Does anyone have an idea what I might need to change? Is there a way to accomplish the same results from SUN OS and MIT snmp as compared to MIT snmp and RISC Ultrix? Thanks in advance. -ayisi ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb26.233447.9017@usenet.ins.cwru.edu] <1991022623344700> From: cjs@po.CWRU.Edu (Christopher J. Seline) Newsgroups: alt.censorship,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: CWRU student prevented from teaching how to send ethernet packets Message-ID: <1991Feb26.233447.9017@usenet.ins.cwru.edu> Date: 26 Feb 91 23:34:47 GMT Sender: news@usenet.ins.cwru.edu Reply-To: cjs@po.CWRU.Edu (Christopher J. Seline) Organization: Case Western Reserve University, Cleveland, OH (USA) Lines: 34 Nntp-Posting-Host: cwns6.ins.cwru.edu Well...I tried to post the source code to a program I'd written to a local USENET board here at CWRU...the program demonstrated how to put packets onto and take packets off of our campus wide ethernet. The program was summarily deleted from the board and I was..well...looks like they threatened me.....anyway....the message follows....please feel free to write to the the fellow who deleted the program "jag@po.cwru.edu", and his boss "rkn@po.cwru.edu". [start included material] Article #1210 (1213 is last): >Newsgroups: cwru.ins.general From: jag@po.CWRU.Edu (Jeff Gumpf) Subject: Interfering with Network Operation Reply-To: jag@po.CWRU.Edu (Jeff Gumpf) Date: Tue Feb 26 16:12:28 1991 We have removed a posting by "cjs" of a program that allows one to send raw Ethernet packets. We suggest that users NOT attempt to use this or any similar program to send raw packets on the network. We remind users that any disruption of the network through the use of such programs, intentional or not, is considered a violation of the University's ethics policy. Anyone found violating that policy will be brought up on charges to the appropriate University office. Such activity will result in disciplinary action up to and including dismissal from the institution. Jeff [end included material] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb27.014104.30007@m.cs.uiuc.edu] <1991022701410400> From: knauer@cs.uiuc.edu (Rob Knauerhase) Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell,alt.censorship Subject: Re: CWRU student prevented from teaching how to send ethernet packets Message-ID: <1991Feb27.014104.30007@m.cs.uiuc.edu> Date: 27 Feb 91 01:41:04 GMT References: <1991Feb26.233447.9017@usenet.ins.cwru.edu> Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager)) Followup-To: alt.censorship Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL Lines: 40 In <1991Feb26.233447.9017@usenet.ins.cwru.edu> cjs@po.CWRU.Edu (Christopher J. Seline) writes: >Well...I tried to post the source code to a program I'd written >to a local USENET board here at CWRU...the program demonstrated how to put >packets onto and take packets off of our campus wide ethernet. First, this is a completely non-technical issue so I'm directing followups to alt.censorship alone. The character above has apparenly graduated from firestarting in cwru.ins.general and has discovered the Usenet at large. Pity. Chris, there is nothing wrong with the free flow of information. However, I think you and I (as well as the cwru.ins.general readership) know that you didn't post that innocently. Your post was (my opinion) calculated not to educate, but to infuriate the Information Network Services people at Case. >The program was summarily deleted from the board and I was..well...looks >like they threatened me.....anyway....the message follows....please feel >free to write to the the fellow who deleted the program "jag@po.cwru.edu", >and his boss "rkn@po.cwru.edu". To the readers of comp.protocols.* and others: A little knowledge is a dangerous thing, and in that respect this fellow is dangerous. His pranks have included instigating personal attacks and playing with reply-to fields and so forth to harass the staff and directorship of Information Network Services. I urge you to ignore his request to further annoy these people. Perhaps alt.censorship is an appropriate place to get into the philosophy of Computing Ethics policies. Chris, if you must invent dirty laundry to hang out, please take it there or keep it in cwru.ins.general... [I hate disclaimers, but here goes:] I have no current affiliation with Case Western Reserve University except as a recent alumnus who keeps current. Lucky for the human race, few people are spoiled enough to have a fiber ethernet port in their dorm rooms and not appreciate it; unfortunately, Mr. Seline doesn't realize that there are responsibilities therewith. Rob Knauerhase, University of Illinois at Urbana-Champaign Department of Computer Science, Gigabit Study Group knauer@cs.uiuc.edu, rck@ces.cwru.edu, knauer@scivax.lerc.nasa.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102271032.AA23671@ucbvax.Berkeley.EDU] <1991022708322200> From: PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: Re: Sendmail/SMTP/TCP mystery? Message-ID: <9102271032.AA23671@ucbvax.Berkeley.EDU> Date: 27 Feb 91 08:32:22 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 On Mon, 25 Feb 91 15:33:52 GMT William Jaynes said: >(Deferred: Connection timed out during result wait with uv1.im.med.umich.edu) >These messages never get delivered. All attempts fail until they time out and >are bounced. >The mailhub is a SunSLC. The host in question is a Vax running some >Wollengong TCP-IP/SMTP etc. software. Up until last week there was not a A problem we've had seems just faintly related, but might help. A Ultrix host was repeatedly trying to send to a Sun what appears to be the end part of a mail item, until the 3-days limit expired. [ub4b.cs.kuleuven.ac.be to georges.montefiore.ulg.ac.be] 19 lines from a dest queue file w/o control starting (probably spilled here): returns the network address and name of all the subscribers. If you do not wish your name to be available to others in this fashion, just issue a "SET MACMAIL -- etc..., end of quote -- On each and every attempt, the Sun's sendmail was producing a core dump. I am in charge of none of those hosts, just routing in between. The problem may have be started by a longer than usual outage of routers in test. Yet. 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---- [martino.667651557@krypton] <1991022710455700> From: martino@logitek.co.uk (Martin O'Nions) Newsgroups: comp.os.os2.misc,comp.os.os2.programmer,comp.protocols.tcp-ip Subject: Re: Looking for OS/2 TCP/IP products with RFC 1001/1002 Message-ID: Date: 27 Feb 91 10:45:57 GMT References: <4432@se-sd.SanDiego.NCR.COM> Organization: Logitek Plc. Lines: 30 nolet@se-sd.SanDiego.NCR.COM (Jason Nolet) writes: >Hello OS/2 Users or Programmers! >We are looking for a TCP/IP product on OS/2 which offers a NetBIOS I/F via >RFC 1001/1002. Can you offer any recommendations? I understand that >3Com offers a TCP/IP product for OS/2, but I don't know any details. I >would be most interested in the "more popular" TCP/IP-for-OS/2 products >on the market. The 3Com product does do the job, and provides RFC NetBIOS connectivity for DOS and OS/2. The latest version (1.2 I think....) has support for 1.21 OS/2, and is supposed to have NetBIOS Name Service Agent capabilities. As soon as I get round to obtaining/testing a copy internally, I'll post some more, as this product is of interest for the LM/X <-> LM interconnectivity market. If anybody out there has got more info., please post! Martin -- DISCLAIMER: All My Own Work (Unless stated otherwise) -------------------------------------------------------------------------- Martin O'Nions Logitek Group Support martino@logitek.co.uk -------------------------------------------------------------------------- Auntie did you feel no pain / Falling from that willow tree? Could you do it, please again / 'Cos my friend here didn't see. (Harry Graham - Ruthless Rhymes for Heartless Homes) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6515@acdhq.north.de] <1991022712070300> From: kaba@acdhq.north.de (Kai Bartels) Newsgroups: comp.protocols.tcp-ip Subject: do FINs count as 1 like SYNs ? Keywords: programimng Message-ID: <6515@acdhq.north.de> Date: 27 Feb 91 12:07:03 GMT Distribution: comp Organization: ACD Advanced Computer Design GmbH Lines: 20 Hi! Sending a SYN advances the sequence number by one since it must be ACKed. A FIN is ACKed, too, so does it advanced the sequence number? I browsed through RFC761 but found nothing which tells me. :-( "Is there anybody out there" (who knows about it) ? greetings, Kai -------------------- Kai Bartels | kaba@acdhq.UUCP | The sound of bombs Hudemuehler 37 | kaba@acdhq.north.de | Has given way to childrens cries D-2800 HB 41 | G14B@DHBRRZ41.BITNET | (0421)34636-13 |g14b@sie.rz.uni-bremen.de|------------------------------ bang: {uunet|pyramid|rutgers}!cbmvax!cbmehq!cbmger!acdhq!kaba -- -------------------- ACD Advanced Computer Design GmbH |acdhq.uucp |Networks Dammweg 15 | Tel.: (+49) (0) 421 34636-0| | and D2800 Bremen 1 | Fax : (+49) (0) 421 3499518|...!cbmvax!cbmger!acdhq| more! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102271500.AA29081@ucbvax.Berkeley.EDU] <1991022713531400> From: malis@BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: PSN Questions Message-ID: <9102271500.AA29081@ucbvax.Berkeley.EDU> Date: 27 Feb 91 13:53:14 GMT References: <9102260055.AA03710@nswc-wo.navy.mil> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 36 Donnie, > 1) Is there a limitation to the number of virtual circuits that > a PSN will allow a particular host for X.25 Standard > connections? I need 64. Depending on the model PSN, 400 or 1200 (or possibly fewer, depending on your host's particular port configuration). > 2) What are the chances (slim, probably, definitely) that I > can always get up to 64 virtual circuits when my host > requests them? The C/300 PSN can support 1200 simultaneous VCs for all of its hosts, and the C/30 PSN can support 400. Individual hosts can also be limited by configuration to a fewer number of VCs, although that is not, to my knowledge, common practice on the MILNET. On a C/300 PSN, for all practical purposes, your host should have no problem getting 64 VCs whenever it needs them. On a C/30 PSN, it becomes more dependent upon what the other hosts on the PSN are also doing at the same time. > 3) Will a PSN close a virtual circuit which has been idle for a > period of time? If so, what is the timer value in the PSN? Yes. The MILNET uses a timer value of 3 minutes. If you are not sure what model PSN you are using, or have any problems using the MILNET, I suggest calling the CONUS MILNET Monitoring Center at (800) 451-7413, or (703) 692-5726 or 692-2268. They can also be reached by email at DCA-MMC@DCA-EMS.DCA.MIL . Regards, Andy Malis BBN Communications ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb27.144731.23147@usenet.ins.cwru.edu] <1991022714473100> From: cjs@po.CWRU.Edu (Christopher J. Seline) Newsgroups: comp.protocols.tcp-ip Subject: Re: CWRU student prevented from teaching how to send ethernet packets Message-ID: <1991Feb27.144731.23147@usenet.ins.cwru.edu> Date: 27 Feb 91 14:47:31 GMT References: <1991Feb27.014104.30007@m.cs.uiuc.edu> <1991Feb26.233447.9017@usenet.ins.cwru.edu> Sender: news@usenet.ins.cwru.edu Reply-To: cjs@po.CWRU.Edu (Christopher J. Seline) Organization: Case Western Reserve University, Cleveland, OH (USA) Lines: 37 Nntp-Posting-Host: cwns6.ins.cwru.edu I was originally going to sit out for a few days and take the deserved heat for bringing this up in an international forum; unfortunently, Rob has libeled me and I'll take a moment to respond. In a previous article, knauer@cs.uiuc.edu (Rob Knauerhase) says: >Chris, there is nothin wrong with the free flow of information. However, I >think you and I (as well as the cwru.ins.general readership) know that you >didn't post that innocently. Your post was (my opinion) calculated not to >educate, but to infuriate the Information Network Services people at Case. Nope. Please don't tell me what I was thinking. I wrote a program that puts packets on ethernet and takes responce packets off; the idea that my (or any) program could be modified to send n+1 packets (swamping our 100M FDDI fiber backbone) scared them; my program didn't do that -- but it (And any other program) could be modified to do so. > A little knowledge is a dangerous thing, and in that respect this fellow >is dangerous. His pranks have included instigating personal attacks and >playing with reply-to fields and so forth to harass the staff and directorship >of Information Network Services. I urge you to ignore his request to further >annoy these people. Nope. I've repeatedly posted (in a local board for discussion) my oppinion (based on 15 years in the field) that our local computer administration is inappropriately restricting knowledge and interfering in people's research; I've also stated that the computer administration is out of touch and that they innapropriately ignore the advice and comments of faculty/staff/and grad students (as well as UnderGrads). I've further compared their management to how I managed things when I was root (at another fine institution). I'D LIKE TO APOLOGIZE TO EVERYONE WHO HAS BEEN BOTHERED BY THE WHOLE THING. I INTENDED TO SIT THIS OUT AND TAKE MY DESERVED LUMPS BUT THIS LIBEL NEEDED A RESPONCE. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [867@nddsun1.sps.mot.com] <1991022716473000> From: wied@birdie.sps.mot.com (Bill Wied) Newsgroups: comp.protocols.tcp-ip Subject: Need: Enhanced FTP Message-ID: <867@nddsun1.sps.mot.com> Date: 27 Feb 91 16:47:30 GMT Sender: root@nddsun1.sps.mot.com Reply-To: wied@birdie.sps.mot.com (Bill Wied) Lines: 13 I hope I'm posting this in the right news group. I'm looking for an enhanced version of FTP which will create virtual connections between hosts that are not directly connected, possibly using routing table information on in between hosts. What I'm thinking of is an enhanced FTP that will first check to see if it can attached directly to the host being sought, if not then it will check it's routing information and FTP to a machine that can connect, possibly through more links, to the machine wanted. The control connection probably needs to be some virtual pipe but the data connection can either create a virtual connection or use some kind of store and forward mechanism to route it's data to the desired host. Is there any kind of code already out there??? I would really rather not reinvent the wheel. I would appreciate any help. If I can not find code already existing I will post my solution somewhere. Please mail me at wied@birdie.sps.mot.com Thanks in advance! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [morrison.667678440@herodotus.cs.uiuc.edu] <1991022718140000> From: morrison@herodotus.cs.uiuc.edu (Vance Morrison) Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans Subject: PCbridge 3C507 support beta testers needed Message-ID: Date: 27 Feb 91 18:14:00 GMT Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 18 Hello, The latest beta version of PCbridge now supports 3COMs Etherlink-16 (3C507) card. This card is a fast 16bit bus ethernet card designed for high performance machines. With it a 12Mhz AT will filter ethernet packets at 20,000 PPS and forward at 11,000 PPS. I have tested the software myself quite a bit, but before I make it 'official' I am hopping to get some other people to test it out too. Thus I need people who ether have 3c507 cards, or what a high performance bridge and are thus willing to buy the 3c507s. If you fit this category, you can pick up the code and documentation from accuvax.nwu.edu (129.105.49.1) in pub/pcroute/exp. The files you want are pcbridge1.2b.r10.src.tar.Z and pcbridge1.2b.r10.tar.Z. Vance ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8698@gollum.twg.com] <1991022719155300> From: david@twg.com (David S. Herron) Newsgroups: comp.protocols.tcp-ip,news.admin,comp.mail.misc Subject: Re: What Is Difference Between Internet And X.400 Style Names? Message-ID: <8698@gollum.twg.com> Date: 27 Feb 91 19:15:53 GMT References: <39557@cup.portal.com> Followup-To: comp.protocols.tcp-ip Organization: The Wollongong Group, Palo Alto, CA Lines: 65 In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Can someone please explain the difference between X.400 and Internet-style >names of the form: USER@SITE.DOMAIN? I had thought that X.400 names >were of the form /THIS=,/THAT=,/ANDWHATEVER=. Recently, two things >made me question this. First, someone told me that the USER@SITE.DOMAIN >was an X.400 standard. Second, I noticed that PSI offers an X.500 >service as part of their TCP/IP public data network PSInet. Their >advertising literature seems to imply that the X.500 database holds >addresses of the USER@SITE.DOMAIN type. I understand that "bang" style >names are unique to UNIX (a derivative of UUCP), but are the USER@SITE.DOMAIN >style names X.400 or UNIX standards, and what is the relationship to >the longer addressing form /THIS=,/ETC=? > >Thanks, >Will Estes (apple!cup.portal.com!Will) X.{4,5}00 names for people & mailboxes have (at least) the following attributes: Country /C=../ Administrative Domain /ADMD=.../ Primary Domain /PRMD=.../ Organization /O=.../ Organizational Unit /OU=.../ Surname /S=.../ Given Name /G=.../ Common Name /CN=.../ These are commonly strung together much like what you listed above. But there isn't a standard for how to represent them on paper. There also isn't (for X.400 anyway) a given order to these things, though there is a "natural" order/hierarchy for all but the "OU" attributes. RFC-987 specifies a translation between that form & RFC-822 domain addresses which looks like local-part@OU$bleep.OU$bloop.O$blarp.PRMD$grunch.ADMD$plink.C$frobozz The equivalent slashy form is /C=frobozz/ADMD=plink/PRMD=grunch/O=blarp/OU=bloop/OU=bleep/CN=local-part/ So there is something of a mapping. I am not familiar with the service that PSI is offering, asking them directly might be useful. "bang" names are derived from UUCP, but UUCP is no longer unique to Unix. Nor has it been for a couple of years now.. I have UUCP on my Amiga at home & it works fine (gets >1000 characters per second through a local trailblazer connection! 7.xx MHz 68000 at that ;-) Suggested reading: RFCs 987, 1138, 1148 and 1154. ISO X.4xx & X.5xx standards (available for $$$ from Omnicom in Falls Church, VA). Marshal Roses "The Open Book" (but only if you can stand long digressions into the political maneuvers which networking development has become ... (*sigh*)) David -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- MS-DOS ... The ultimate computer virus. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MOCK.91Feb27120033@watt.support.Corp.Sun.COM] <1991022720003300> From: mock@watt.support.Corp.Sun.COM (Joseph Mocker) Newsgroups: comp.protocols.tcp-ip Subject: ? : TCP Data Integrity Message-ID: Date: 27 Feb 91 20:00:33 GMT Sender: news@jethro.Corp.Sun.COM Distribution: comp Organization: Sun Microsystems Inc. Lines: 15 o.k. you TCP Guru's, Heres one for ya! I've been reading up on the TCP/IP protocol suite and I got a question about TCP. I can't seem to find out how TCP insures data integrity? in the TCP Segment header, there is a checksum field, but that seems to be only for the Header information. So by that, we know that the data got to the right place, but there is nothing that checksums the data sent. Is this up to the user program? How is data integrity kept in a TCP transaction? thanks...joe -- ------------------------------------------------------------------------------ Joe Mocker//USAC//PC-NFS Support :: mock@Corp.Sun.COM :: Sun Microsystems Inc. :: there's still lofty dreams :: meager desires :: still sillyness :: ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1421@fang.dsto.oz] <1991022720030700> From: sxc@se2.dsto.oz (Stephen Crawley) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified Mail Systems... Message-ID: <1421@fang.dsto.oz> Date: 27 Feb 91 20:03:07 GMT References: Sender: news@fang.dsto.oz Lines: 79 PH461A04@VAX1.UMKC.EDU (Guerra de Bureau) writes: >Regarding a protocol for SMTP certified mail, can anyone suggest >why the following procedure would not work?? > 1) Local mail system encrypts mail with time-varying key > 2) Local system forwards mail to remote system > 3) Remote system delivers (encrypted) mail to designated user > 4) Designated user requests key from remote system > 5) Remote system requests key from local system > 6) Local system indicates to message originator that message > has been received and key requested. > 7) Local forwards key to remote > 8) If remote system does note recieve key withing (x) units, > repeats request for (y) tries before informing recipient key > unavailable > 9) Remote delievers key to remote user/unencrypts original message >The only failure that I see is if a) the remote system requests the >key from the local system; b) the local system acknowledges the request, >and c) the anknowlegment(key) never gets back to the remote, and finally >d) the remote is not able to re-request the key within the designated >time frame. Given the increasing network reliability and the decreasing >network transfer time and a sufficient number of retries/length of >time before discard this system would seem fairly secure. >Any problems?? If we assume that the network is insecure, I can think of three security problems with your proposal. First, a third party (call it "spy") can read mail sent from "local" to "remote". Here is how: When "local" send the encrypted mail message to "remote", "spy" grabs a copy of the message. When "remote" requests the key, "spy" grabs the reply message from "local" and uses it to decrypt the message at his leasure. Second, "spy" can fool "local" into thinking that a message has been delivered when this is not the case. This is how: When "local" tries to send the encrypted mail message to "remote", "spy" intercepts it and sends a request to "local" saying "I'm remote; what's the key". "local" responds with the key, and tells the sender that the mail has been delivered. In fact, the message has black-holed. Third, "spy" could prevent "remote" from reading mail messages, by grabbing the messages containing the decryption key. For ultimate maliciousness, it could forward the messages with garbled keys! The root causes of these problems are: 1) The decryption key message is sent in clear. 2) Key request and replies cannot be authenticated as coming from the right place. In addition to the security issues above, there are a number of more mundane problems. 1) The use of timeouts and timestamps means that the protocol is likely to fail when certified mail and/or key messages are relayed through a slow or flakey mail gateway. 2) The "local" system has to keep a record of the keys for each certified message sent. It is not obvious how long this information needs to be kept. 3) The mail message is sent only once. If it gets lost, the sender loses. He/she can't distinguish that case from the recipient not having read the message. 4) The notification to the sender of a key request does not tell him that the recipient has been able to read the mail. If the decryption key fails to arrive, this will be impossible. -- Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb27.220337.29559@cbnewsj.att.com] <1991022722033700> From: duckie@cbnewsj.att.com (john.c.mc millan) Newsgroups: comp.sys.att,comp.protocols.tcp-ip Subject: Re: WIN-TCP Problem on 3B2/500 Summary: Upgrade is worthwhile Message-ID: <1991Feb27.220337.29559@cbnewsj.att.com> Date: 27 Feb 91 22:03:37 GMT References: <1991Feb25.214152.27244@prism.poly.edu> Distribution: na Organization: AT&T Bell Laboratories Lines: 56 In article <1991Feb25.214152.27244@prism.poly.edu> drubin@prism.UUCP (Dave Rubin) writes: >We are running Wollongong's WIN-TCP Version 3.0.1 on a 3B2/500 which is >running System V Release 3.2.1. : >I have heard that version 3.2 of WIN-TCP has been released. Does anyone know >if this latest version fixes any of the problems stated above? Or do I >need to look into an alternative to these 3B2 systems that can't seem to >behave themselves on the network? Over the past 3 months our cluster of 3 3B2/700's has upgraded to WIN/3B r3.2 and SVR3.2.3. The improvements have been enormous... a several-fold reduction in hung processes and crashes. These machines are cross-mounting [RFS] file systems and pound the TCP interfaces pretty heavily at times. There still are crashes, but we're also running an extensive assembly of packages, some of which are of local origin, so.... 8) I would STRONGLY recommend upgrading to BOTH SVR3.2.3 and WIN/3Br3.2. The caveats... - Until this a.m., we were running Beta versions of WIN/3Br3.2. I would EXPECT the now-available version -- by coincidence loaded onto one of our systems this morning -- to be at least as reliable. (As pevidence: that system hasn't crashed since! 8) - TCP under WIN/3Br3.2 seems to be argumentative with earlier releases: rumor has it that as a result of fixing a long-term bug regarding window-sizing, negotiation-arguments occasionally erupt between 3.2 systems and earlier ones. I've seen 99% of system CPU disappear for 30 minutes running. It's possible the now-available version has employed some strategy to counter this, but I'd confirm that, or convert all your 3B2's AND 386's at one time! We did convert, and we're quite enthusiastic about the result. - SVR3.2.3 drops support of the "proc" driver -- 'tho' there's a rumor it might return. (Do you use/ require 'renice' or 'truss'?) - SVR3.2.3 defaults to 2KB logical block File Systems: you don't HAVE to convert your existing FS, but the KERNEL BUFFERS will be 2KB regardless of your FS, so that's 50% wasted RAM in the buffers if you don't convert some of your FS to 2KB logical blocks. With pre-apologies for any errors in the above... John McMillan -- >> jcm@pegasus.att.com << Muttering for self, only ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb27.220942.18774@eagle.lerc.nasa.gov] <1991022722094200> From: xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) Newsgroups: comp.protocols.tcp-ip Subject: "Forking" with MVS TCP/IP Message-ID: <1991Feb27.220942.18774@eagle.lerc.nasa.gov> Date: 27 Feb 91 22:09:42 GMT Sender: news@eagle.lerc.nasa.gov Reply-To: xxbja@csduts1.lerc.nasa.gov (Betty Jo Armstead) Organization: NASA/Lewis Research Center, Cleveland Lines: 25 >I have an a TCP server on MVS that must provide concurrent processing of >multiple clients. On UNIX, the approach would be to have the parent >accept a new connection, fork a child to provide the service, and have >the parent continue to listen for additional connections. How does one >achieve the equivalent of "fork" in MVS under MVS/TCP? >MVS/TCP comes with standard servers like FTP and TELNET. How do they >"fork" and is the approach general? (I do not yet? have source to >these so I haven't been able to look myself). >To up the ante, I would prefer this server to be RPC based. I have had >good success developing and porting (non-forking) RPC clients and >servers between UNIX and MVS and would like to reuse some of that code. >Thanks in advance. --Jack Fitch@dockmaster.ncsc.mil I am also interested in how one writes concurrent servers on MVS. I hope you have better luck than I did getting answers. Isn't anyone from IBM listening? -- Betty Jo Armstead SVERDRUP Technology Inc. 21000 Brookpark Rd.Ms 142-2 Nasa Lewis Research Center Cleveland Ohio 44135 From: xxbja@csduts1.lerc.nasa.gov ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102272231.AA04209@frodo.jdssc.dca.mil] <1991022722314800> From: blknowle@frodo.JDSSC.DCA.MIL (Brad L. Knowles) Newsgroups: comp.protocols.tcp-ip Subject: Re: CWRU student prevented from teaching how to send ethernet packets... Message-ID: <9102272231.AA04209@frodo.jdssc.dca.mil> Date: 27 Feb 91 22:31:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 55 Look Guys, This is getting a little tiresome -- if you want to make general (non-inflamatory) comments on why a particular decision was made, then do so. If you want to tell us about a program that you wrote that we might find useful, then do so. BUT PLEASE KEEP YOUR FLAME WARS OFF THE MAILING LIST(S)! And also please refrain from using all caps to make a point -- I did it above to point out how inapprorpiate it is, but please do not follow my (or Chris's) example. These mailing lists have been set up for one purpose -- so that people who have questions about a particular subject (in this case TCP-IP protocols) can do so and expect that very knowledgeable people might be on the mailing lists and replay to those questions. It is also here to let people who have information on a particular subject can tell others about it, even if there has not been an explicit Rquest For Information on the subject -- if it has something to do primarily with TCP-IP protocols and their support under any particular Operating System, then tell us about it or ask us the question. If what you have to say has very little to do with TCP-IP, then make your statement or ask your question elsewhere. Rob & Chris, please do not misinterpret this post -- I'm not flaming you (yet :-| ), I would just like to make sure that we keep the chaff down to a minimum on this mailing list, and if someone sees your comments without some sort of response of the sort I have presented here, then they might get the wrong idea. Chris, you had every right to tell us about the availablility of your program, and the fact that you had tried to make it publicly available, but politics kept you from doing so. Neither you nor Rob have the right to say whether the Univeristy was correct in their decision to keep it off the publicly available file-space, as that is a matter of opinion. Also, neither of you have the right to take public offense at statements of fact -- they are a matter of fact, and nothing can change that. So long as we keep our statements factual, and police ourselves strongly on matters of opinion, this mailing list will remain useful. The moment everyone (myself included) starts making lots of statements of opinion, no matter whether or not they say that what they have to say is opinion or fact (unless specifically asked for their opinions, and then they should make sure that what they have to say is kept very short and sweet), then this mailing list becomes a vehicle for junk e-mail -- something I'm sure we can all do without. Now, I'll get down off my soapbox! Please do *not* respond! We have enough statements of opinion in this post as it is, and I'll just /dev/null private e-mail on this subject anyway! _____________________________________________________________________________ | Brad Knowles | email: blknowle@frodo.jdssc.dca.mil | | Sun System Administrator | or: blknowle@wis-cms.dca.mil | | DCA/JDSSC/JNSL | W Phone: (703) 693-5849 ____________________| | The Pentagon, Room BE685 | Fax: (703) 693-7329 |Of course, the usual| | Washington, D.C. 20301-7010 | Autovon: 223-5849 |disclaimers apply. | |______________________________|_________________________|____________________| ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb27.224829.5226@shell.shell.com] <1991022722482900> From: qureshi@redwood.shell.com (Fawad Qureshi) Newsgroups: comp.protocols.tcp-ip Subject: ftp's PC/TCP; Is it NDIS compliant?? Keywords: NDIS, PC/TCP, DLC Message-ID: <1991Feb27.224829.5226@shell.shell.com> Date: 27 Feb 91 22:48:29 GMT Sender: usenet@shell.shell.com (USENET News System) Organization: Shell Oil Lines: 14 Originator: qureshi@redwood I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need to know exactly what sits between the PC/TCP kernel and the token ring board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info... Fawad Qureshi Shell Oil Company Internet: qureshi@shell.com && qureshi@cs.rpi.edu Bitnet: userfwqu@rpitsmts.BITNET -- Fawad Qureshi Shell Oil Company (713)795-3772 internet: qureshi@shell.com && qureshif@cs.rpi.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [morrison.667698041@dante.cs.uiuc.edu] <1991022723404100> From: morrison@herodotus.cs.uiuc.edu (Vance Morrison) Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans Subject: PCroute bridge-router testers needed Message-ID: Date: 27 Feb 91 23:40:41 GMT Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 24 Hello, I have gotten a version of PCroute to work as a IP bridge-router and have done some initial testing on it. Now I am in need of beta-testers. Due to problems I don't want to get into, I can only distribute the binary executables at this time (no source), The source is only slightly different from the generic PCroute distribution, but there is some subtlety in its compilation. I have compiled three versions of this code, one for the WD8013EBT card, one for the 3COM 3c507 card and one for the WD8003E card. These files as well as a simple documentation file that should be enough to get you going is available from accuvax.nwu.edu (129.105.49.1) in pub/pcroute/exp/broute. So if you are interested in bridge-routing capability, pick up the software and give it a try. If you do plan on testing it, or are just interested in the bridge-routing capability in general please drop me a message so I know. Thanks Vance ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102272230.AA00109@asylum.sf.ca.us] <1991022806302900> From: romkey@ASYLUM.SF.CA.US (John Romkey) Newsgroups: comp.protocols.tcp-ip Subject: ? : TCP Data Integrity Message-ID: <9102272230.AA00109@asylum.sf.ca.us> Date: 28 Feb 91 06:30:29 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: romkey@asylum.sf.ca.us Organization: The Internet Lines: 5 The TCP checksum includes the TCP header, the psuedoheader (which isn't transmitted) and the TCP data. The IP checksum only includes the IP header. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb28.063456.4039@Think.COM] <1991022806345600> From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: ? : TCP Data Integrity Message-ID: <1991Feb28.063456.4039@Think.COM> Date: 28 Feb 91 06:34:56 GMT References: Sender: news@Think.COM Distribution: comp Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 19 In article mock@watt.support.Corp.Sun.COM (Joseph Mocker) writes: >I've been reading up on the TCP/IP protocol suite and I got a question about >TCP. I can't seem to find out how TCP insures data integrity? in the >TCP Segment header, there is a checksum field, but that seems to be only >for the Header information. So by that, we know that the data got to the >right place, but there is nothing that checksums the data sent. Is this up >to the user program? How is data integrity kept in a TCP transaction? You apparently misread. TCP checksums the entire segment. UDP's optional checksum is also of the entire datagram. IP, however, has a header-only checksum, but IP doesn't claim to ensure data integrity. It was designed so that it could be used by applications that care more about speed than accuracy (e.g. digitized voice). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9103010927.AA06667@ucbvax.Berkeley.EDU] <1991022806420000> From: TAYBENGH@NUSDISCS.BITNET Newsgroups: comp.protocols.tcp-ip Subject: How multiple OOB are hold/mark in socket with only one so_oobmark? Message-ID: <9103010927.AA06667@ucbvax.Berkeley.EDU> Date: 28 Feb 91 06:42:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 Hi netlanders, After reading thru the implementation of socket and TCP/IP from the book The Design and Implementation of the 4.3BSD OS (published by Addison-Wesley), I am puzzled of implementing OOB in the socket. Inside the book (pg 335) the authors describe that multiple OOB messages can be hold in a protocol if the user specify the SO_OOBINLINE option to force the OOB data to be placed in the normal receive queue. However, according to the data structure of socket, so_oobmark is used to mark the offset of the LAST OOB message from the beginning of the receive queue. My question is: How can a so_oobmark to mark different OOB messages? Or does it means that although many OOB messages can be hold in the receive queue, only ONE of them can be received using so_oobmark? If so, what is the purpose of holding multiple messages if we can not differentiate in-band and the rest OOB data? Thanks in advance. - Beng Hang Dept of Information Systems and Computer Science National University of Singapore ----MESSAGE-END---- ----MESSAGE-BEGIN---- [701@digigw.digital.co.jp] <1991022808210100> From: gday@digigw.digital.co.jp (Gordon Day) Newsgroups: comp.protocols.tcp-ip Subject: best cost/performance solutions for site interconnection Keywords: slip, Van Jacobson's TCP/CSLIP Message-ID: <701@digigw.digital.co.jp> Date: 28 Feb 91 08:21:01 GMT Organization: Digital Electronics Corp., Osaka, Japan Lines: 16 Posted: Thu Feb 28 02:21:01 1991 Is SLIP the best way to cheaply connect two small (~20 machines each) Unix-based lan sites (~30km apart) together? I'm interested in solutions which address the requirements of low cost for a internet with low performance requirements (typical applications would be SMTP, ~3 megabytes ftp/week, and occasional Telnet sessions). With this in mind, the best thing I have heard about was CSLIP. Is it available to all? If so, where can it be obtained from? Are there better ways? Cheers, Gordon Day. -- Gordon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281354.AA15153@europa.clearpoint.com] <1991022813542700> From: kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Re: ? : TCP Data Integrity Message-ID: <9102281354.AA15153@europa.clearpoint.com> Date: 28 Feb 91 13:54:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 71 > From tcp-ip-RELAY@NIC.DDN.MIL Thu Feb 28 00:23:15 1991 > From: sun-barr!newstop!jethro!mock@apple.com (Joseph Mocker) > Organization: Sun Microsystems Inc. > Subject: ? : TCP Data Integrity > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > o.k. you TCP Guru's, Heres one for ya! > > I've been reading up on the TCP/IP protocol suite and I got a question about > TCP. I can't seem to find out how TCP insures data integrity? in the > TCP Segment header, there is a checksum field, but that seems to be only > for the Header information. So by that, we know that the data got to the > right place, but there is nothing that checksums the data sent. Is this up > to the user program? How is data integrity kept in a TCP transaction? > > thanks...joe > -- > ------------------------------------------------------------------------------ > Joe Mocker//USAC//PC-NFS Support :: mock@Corp.Sun.COM :: Sun Microsystems Inc. > > :: there's still lofty dreams :: meager desires :: still sillyness :: Joe, From the TCP RFC (RFC793) Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be ^^^^^^^^ aka the data checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a 96 bit pseudo header conceptually [Page 16] ^L September 1981 Transmission Control Protocol Functional Specification prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across the TCP/Network interface in the arguments or results of calls by the TCP on the IP. +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), and it does not count the 12 octets of the pseudo header. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281357.AA07530@sol.bucknell.edu] <1991022813575800> From: droms@SOL.BUCKNELL.EDU (Ralph E. Droms) Newsgroups: comp.protocols.tcp-ip Subject: Re: What Is Difference Between Internet And X.400 Style Names? Message-ID: <9102281357.AA07530@sol.bucknell.edu> Date: 28 Feb 91 13:57:58 GMT References: <8698@gollum.twg.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: droms@bucknell.edu.Date:27.Feb.91.19:15:53.GMT.From:mips!twg.com!david@apple.com Organization: The Internet Lines: 25 () David S. Herron (mips!twg.com!david@apple.com) writes; X.{4,5}00 names for people & mailboxes have (at least) the following attributes: Country /C=../ Administrative Domain /ADMD=.../ Primary Domain /PRMD=.../ Organization /O=.../ Organizational Unit /OU=.../ Surname /S=.../ Given Name /G=.../ Common Name /CN=.../ Are these attributes required of every X.[45]00 people and mailbox names, or are they specific to the naming convention chosen by the NYSERNet White Pages Project (and possibly others)? - Ralph Droms Computer Science Department droms@bucknell.edu 323 Dana Engineering Bucknell University (717) 524-1145 Lewisburg, PA 17837 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb28.152833.12503@b11.ingr.com] <1991022815283300> From: allen@b11.ingr.com (John Allen) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNA tunneling? Message-ID: <1991Feb28.152833.12503@b11.ingr.com> Date: 28 Feb 91 15:28:33 GMT References: Organization: Intergraph Corp. Huntsville, AL Lines: 18 in article , bob@MorningStar.Com (Bob Sutterfield) says: > > Is anyone working on a standard for IP tunneling over SNA networks? > That is, given an existing SNA network, and a desire to use it for IP > transport, is there an equivalent to any of RFCs 1201, 1188, 1171, > 1149, 1088, 1042, and 877? > > (OK, I just mentioned 1149 to see if you were really watching :-) Harris - Adacom has TCP/IP over LU6.2. Requires no software on the IBM host. I believe this is a UNIX-based box, it can act as a gateway to connect remote TCP/IP LANs through an existing IBM Mainframe. -- * O . John E. Allen * * /\__ ____@__ . ingr!b23b!allen!jallen@uunet.uu.net * * /\ -|0 ... (205) 730-8627 (days) * * / \ ===...... . * ----MESSAGE-END---- ----MESSAGE-BEGIN---- [91059.110657PMW1@psuvm.psu.edu] <1991022816065700> From: PMW1@psuvm.psu.edu (Peter M. Weiss) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNA tunneling? Message-ID: <91059.110657PMW1@psuvm.psu.edu> Date: 28 Feb 91 16:06:57 GMT References: <1991Feb28.152833.12503@b11.ingr.com> Organization: Penn State University Lines: 25 In article <1991Feb28.152833.12503@b11.ingr.com>, allen@b11.ingr.com (John Allen) says: >in article , bob@MorningStar.Com >(Bob Sutterfield) says: >> >> Is anyone working on a standard for IP tunneling over SNA networks? >> That is, given an existing SNA network, and a desire to use it for IP >> transport, is there an equivalent to any of RFCs 1201, 1188, 1171, >> 1149, 1088, 1042, and 877? >> >> (OK, I just mentioned 1149 to see if you were really watching :-) >Harris - Adacom has TCP/IP over LU6.2. As far as I am aware, IBM's TCP/IP For MVS can do this too (except it uses LU_0 ) and it is called SNALINK. ref: "TCP/IP For MVS Installation and Connections" form GG24-3412-00 /Pete -- Peter M. Weiss | pmw1 @ PSUADMIN | psuvm.psu.edu|psuvm 31 Shields Bldg - PennState Univ.| ^ affiliated with psuvm.psu.edu|psuvm University Park, PA USA 16802 | Secrecy is the guardian of bureaucracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [275@gradient.gradient.com] <1991022816121000> From: robin@gradient.gradient.com (Dr R.P. Alston) Newsgroups: comp.unix.xenix.sco,comp.unix.sysv386,comp.protocols.tcp-ip Subject: SCO UNIX, getting the real enet address (48bits) Keywords: SCO-ODT lachman TCP/IP MAC address Message-ID: <275@gradient.gradient.com> Date: 28 Feb 91 16:12:10 GMT Followup-To: poster Organization: Gradient Technologies Inc., Hudson MA Lines: 39 Although this question relates currently to the SCO UNIX boxes, we are going to have to answer this same question on more platforms and UNIX's in the future. Any general suggestions are welcome, this approach has been currently chosen because the ubiquitous IBM PC architecture does not have any mechanism to uniquely identify a box (any [34]86 clone walks, talks and smells like any other clone), unlike other machines such as SUN's that have unique ID's in ROM. We have an application that would like to obtain a unique node identity that is difficult to forge. We would like to be able to obtain the 48 bit ethernet address for a given board in SCO [34]86 UNIX (3.2) machines which have the lachman tcp-ip installed. Is there some mechanism in existence that allows a request to convert on a given machine an internet address to the ethernet address of the board that supports that INET address? Ideally this would be able to move forward in the future to other interfaces, and whatever makes them unique. We have done this on other machines (SVR4 386) but have had to develop a driver that goes and mucks with the ARP tables to find the entry that corresponds to a given INET address, since the arp program, nor the ioctls associated with arp do not typically provide a way to get the local ethernet address (after all it knows who it is doesn't it?). I thought that inquiring here before I go off the deep end again would be worthwhile. I was wondering if anyone knows or understands this copy protection scheme (cpd) that SCO has implemented to know if it provides this mechanism or not. Thankyou for any help, save the NET please e-mail responses. robin -- Dr Robin P. Alston, Principal Member, Technical Staff, Gradient Technologies, robin@gradient.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102282032.AA15550@ucbvax.Berkeley.EDU] <1991022816252300> From: JEFF@MITVMA.MIT.EDU (Jeff Harrington) Newsgroups: comp.protocols.tcp-ip Subject: Underscores Message-ID: <9102282032.AA15550@ucbvax.Berkeley.EDU> Date: 28 Feb 91 16:25:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 9 Hi, I've been getting complaints about my SMTP rejecting mail from sites with a underscore in its host name. If I read RFC 821 correctly, names may consist of letters, digits, and hyphens. Has this been liberalized recently? The site in question is: its_gate.cc.uow.edu.au Thanks, Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281650.AA01305@ftp.com] <1991022816505000> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: Looking for mil spec archive Message-ID: <9102281650.AA01305@ftp.com> Date: 28 Feb 91 16:50:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 19 I have received a spec which references MS 1777 (IP) and MS 1778 (TCP). I have the rfc's to tcp and ip, but where can I find an archive for the mil standards? I don't think the Mil Stds are available in machine-readable form. Those two happen to be included in the DDN Protocol Handbook, which you can buy from the NIC at SRI in Menlo Park, CA or the DTIC in Alexandria, VA. In any case, you don't want to implement from the Mil Stds for TCP and IP. They don't specify exactly the same protocol as the RFCs, and furthermore, they are internally inconsistent in at least a couple of important places (see RFCs 964 and 963). Use the HRRFCs (1122 and 1123) to supplement the basic RFCs (791, 792, 793, etc) and you'll be on the right track. Note that the "IP Security" that the DoD may want to buy is *not* what is described in either Mil Std 1777 or RFC 791. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281650.AA01313@ftp.com] <1991022816505400> From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: lsrr, ssrr, & rr options that don't work Message-ID: <9102281650.AA01313@ftp.com> Date: 28 Feb 91 16:50:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 19 1) Should the packet be tossed? If the next hop in a Strict Source Route can't be reached directly, drop it. Ditto if you can't route towards the next hop in a Loose Source Route. 2) Should the packet be answered with an ICMP unreachable message? ICMP Destination Unreachable, Code 5 (Source Route Failed), unless the failed packet was an ICMP Error Message itself. And, if so, how should A handle the Record portion of the option list? A never forwarded it so it never really was routed by it. Don't record yourself (I'm guessing), because the information is already available in the source IP address of the ICMP error. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb28.170013.13683@phri.nyu.edu] <1991022817001300> From: roy@phri.nyu.edu (Roy Smith) Newsgroups: alt.censorship,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell Subject: Re: CWRU student prevented from teaching how to send ethernet packets Message-ID: <1991Feb28.170013.13683@phri.nyu.edu> Date: 28 Feb 91 17:00:13 GMT References: <1991Feb26.233447.9017@usenet.ins.cwru.edu> Sender: news@phri.nyu.edu (News System) Followup-To: alt.censorship Organization: Public Health Research Institute, New York City Lines: 112 [Note: of all the groups the original posting was send to, alt.censorship is the only really relevant one and I've sent directed all followups there. It's clearly not a protocol issue.] cjs@po.CWRU.Edu (Christopher J. Seline) writes: > Well...I tried to post the source code to a program I'd written to a > local USENET board here at CWRU...the program demonstrated how to put > packets onto and take packets off of our campus wide ethernet. The > program was summarily deleted from the board [...] I hesitate to get involved in what is obviously an internal policy decision, but I would tend to agree that the administrators who removed your posting were perfectly withing their rights to do so. There is a serious constitutional issue at stake here, that of free speech. However, I think Christopher has slightly misunderstood the issue. My reasoning goes something along these lines: First, the campus wide ethernet is a shared resource. Proper operation of it depends to a large degree on the cooperation of everybody who uses it. It is fairly trivial for anybody with the proper knowledge and a PC (or a Sun workstation running NIT that they have root permission on, or lots of other things) directly connected to the ethernet to totally disrupt the entire network. This is clearly A Bad Thing. If the university decides to expell somebody who deliberately puts hand-crafted packets on the network and messes things up, that sounds fine to me. It is also besides the point. The university administration is also exercising head-in-the-sand security practices if they think removing the article with the "evil" source code will keep such ethernet tapping/spoofing from happening, but that, too, is rather besides the point. Second, even though you do have the right of free speech, that right does not extend to using somebody else's communication media to spread your message, at their expense. The university paid for the computer on which you posted your program, and clearly they have a right to decide what is a valid use of it. They don't want you to tell other people how to send random packets onto the ethernet, and (regardless of whether or not they are wise in wishing this knowledge kept secret) they certainly have the right to prevent you from using university resources to spread your message. It doesn't matter that your tuition dollars may be going to help pay for the machines; you still don't own them. However, let's say you took a slightly different tack. What if you printed up your source code and went to a local copy shop and xeroxed, at your own expense, 1000 copies and handed them out to students? Let's play it safe and say you aren't even doing the handing out on university property; instead you stand just outside of the campus front gate (not obstructing traffic, etc) on public property. It would probably be more useful to make up 1000 floppy disks with your code on it and hand them out, but that doesn't really change anything. In that case, if the university attempted to stop you, I think you would have an extremely strong case that you are simply exercising your constitutional right to free speech and there isn't anything they can do about it. You could go a step further and find operators of private BBS systems who would be willing to have your code uploaded to their machines and distribute it that way. Or, you could buy your own machine and set up your own BBS. Or you can stand on a street corner with a megaphone and read your code to the masses (I'd really like to see somebody standing on a street corner with a megaphone shouting "Yes, people, I tell you, all you have to do is open a socket with address family AF_NIT as root and bind it to /dev/le0 and do a few ioctl's ..."), or hire a skywriter to draw it in the sky over the computer center. As long as it doesn't involve using university resources, they can't do anything to you to keep you from spreading your message, at your own expense. A somewhat different case exists with public service announcements on TV. In that case, you need a license from the FCC to broadcast, and the number of TV channels that can be allocated in a given area is limited; even if you were willing and able to spend the considerable sum of money needed to set up your own TV transmitter, it wouldn't do you any good. Since that is the case, as a condition of granting a license to a station, the FCC requires that the station allow a certain amout of public service use. You could try to make a case, I suppose, that the campus-wide ethernet is a monopoly similar to a TV channel allocation, and thus the university is required to allow you to post your code as a "public service" but I think the case would be extremely weak indeed and you wouldn't get very far with it, especially considering how easy it is for you to find other distribution methods that are essentially just as good and would cost you a relatively modest sum of money. You could set up a BBS in your dorm room (or, better yet, your off-campus apartment) to distribute the code and I suspect that anybody who could make use of it would have the equipment and know-how to download it. Total outlay to you for a cheap PC and a modem could easily be under $1000; a lot of money for a college student, I guess, but lots of undergraduates CS majors do seem to have their own PCs (many schools even require it, CS major or not). Please note that I am *not* advocating that you send random packets on the ethernet, or that you distribute your code to other people so they can do so. I think doing either would be an extremely irresponsible thing to do. However, there is an important constitutional issue here; namely that you do have the right to distribute information which other people find distasteful, as long as you do it at your own expense. The fine line which many people seem to misunderstand, however, is that you *don't* have the right to force other people to distribute it for you. Free speech doesn't mean that the New York Times has to accept my full-page ad esposing my personal opinion that Saddam Hussain is a nice guy if they don't want to, it just means that I can, if I choose, buy my own printing press and paper and ink and go into the newspaper business myself, if that's the only way I can find to get my ad into print. In my college days, the big censorship deal was whether the ChemE students who wanted to do free paraquat testing (as a public service) should be allowed to advertise their services in the college newspaper. Paraquat, for those who havn't heard of it, was something (a herbicide?) that was once sprayed on marijuana fields by the drug control folks; smoking paraquat tainted pot was very bad for your health. I don't think the idea ever got off the ground, so the issue was a moot point. Among other things, they probably were planning on using the school chem labs to do the testing, which, of course, the school was within their rights to disallow. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281705.AA02081@ftp.com] <1991022817053300> From: fks@FTP.COM (Frances Selkirk) Newsgroups: comp.protocols.tcp-ip Subject: Re: ftp's PC/TCP; Is it NDIS compliant?? Message-ID: <9102281705.AA02081@ftp.com> Date: 28 Feb 91 17:05:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need to know exactly what sits between the PC/TCP kernel and the token ring board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info... Our PC/TCP is available for a variety of environments. Usually, people running PC/TCP over Token Ring use an IBM ASI driver (e.g. tokreui, the LAN Support Program) and our PC-219, but you could also get our PC-210 and use it over an NDIS driver or a Class 3 (802.5) packet driver. In addition, we have direct support, with our own drivers, for several Proteon PROnet cards. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [BOB.91Feb28120702@volitans.MorningStar.Com] <1991022817071200> From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: SNA tunneling? Message-ID: Date: 28 Feb 91 17:07:12 GMT References: <1991Feb28.152833.12503@b11.ingr.com> <91059.110657PMW1@psuvm.psu.edu> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 40 In article <1991Feb28.152833.12503@b11.ingr.com>, allen@b11.ingr.com (John Allen) says: in article , bob@MorningStar.Com (Bob Sutterfield) says: Is anyone working on a standard for IP tunneling over SNA networks? Harris - Adacom has TCP/IP over LU6.2... and in private mail: Date: Tue, 19 Feb 91 18:21:28 CST From: David Boyes The IBM TCP/IP for VM package already does this quite nicely. The SNALNK component of the software opens a LU0... From: Paul Sergeant Date: Mon, 25 Feb 91 10:09:33 CST IBM's ... SNALINK ... for MVS and VM. This connects TCP/IP networks using LU0 connections. Each IBM mainframe must have TCP/IP installed for this to work. OpenConnect Systems ... an IP level router ... called OCIR, encapsulates TCP/IP or UDP/IP in an LU 6.2 frame ... OCIR also can emulate IBM's SNALINK, so it can connect via IBM's TCP/IP. Date: Tue, 26 Feb 91 17:56:51 EST From: rlg@ida.org (Randy garrett) I also found a company called Brixton that has a card for the Sun that translates IP into something understandable to a 3745... There are several implementations, using disparate schemes, but no standards. The schemes about which there's any detail use either LU0 or LU6.2 transports, as expected. But unless one explicitly emulates another, there's no guarantee that their encapsulation methods will interoperate, even if they picked the same LU transport. Caveat Emptor! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9102281724.AA02559@ftp.com] <1991022817243300> From: cws@FTP.COM (Cris Shuldiner) Newsgroups: comp.protocols.tcp-ip Subject: Re: ftp's PC/TCP; Is it NDIS compliant?? Message-ID: <9102281724.AA02559@ftp.com> Date: 28 Feb 91 17:24:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cws@ftp.com Organization: The Internet Lines: 24 Date: 27 Feb 91 22:48:29 GMT From: nuchat!shell!redwood!qureshi@uunet.uu.net (Fawad Qureshi) Subject: ftp's PC/TCP; Is it NDIS compliant?? I need to know if ftp's PC/TCP is NDIS compliant? In other words, I need to know exactly what sits between the PC/TCP kernel and the token ring board, DLC?, IBM's Lan Support Program?, NDIS? Thanx for any info... Fawad Qureshi Yes, our PC-210 part number of PC/TCP works with NDIS. If you wish to run on Token Ring the you can use this with Token Ring NDIS drivers. Alternatively, you can use our PC-219 part number to work with the IBM Lan Support Program (or other ASI's). Cris Shuldiner Product Support cws@ftp.com FTP Software, Inc. Ph: (617) 246-2920 Fax: (617) 245-7943 --------------------------------------------------------------------------- "Nobody told me there'd be days like these. Strange Days Indeed." -John Lennon --------------------------------------------------------------------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [tb.667764093@elwood] <1991022818013300> From: tb@Materna.DE (Torsten Beyer) Newsgroups: comp.protocols.tcp-ip Subject: SNMP Products Message-ID: Date: 28 Feb 91 18:01:33 GMT Sender: root@Materna.DE Lines: 14 Hi Everybody, I'm interested in SNMP-products that will be demonstrated at next months CeBIT computer show in Hannover/Germany. Any hints on company exhibiting their SNMP product in Hannover are greatly appreciated... ciao -Torsten -- Torsten Beyer e-mail : tb@Materna.DE Dr. Materna GmbH VOX : +49 231 5599 225 Vosskuhle 37 FAX : +49 231 5599 100 D-4600 Dortmund 1, West Germany ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb28.183714.12039@csusac.csus.edu] <1991022818371400> From: cs175111@csusac.ecs.csus.edu (Steven Little) Newsgroups: comp.protocols.tcp-ip Subject: Need a compact Ethernet driver for AT&T 7300 Message-ID: <1991Feb28.183714.12039@csusac.csus.edu> Date: 28 Feb 91 18:37:14 GMT Sender: cs175111@csusac.csus.edu (Steven Little) Distribution: na Organization: California State University, Sacramento Lines: 11 I am currently working on a project to connect an AT&T 7300 to a host via an Ethernet cable. The problem I'm having is that the ROM space in the 7300 is very small. What I need is a reduced tcp-ip or a tiny tcp-ip to handle this problem. I thank anyone who can help me with my problem in advance. Send response to cs175111@csusac.ecs.csus.edu This is the first time I have posted on this newsnet so sorry if I make some errors. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860@cns.SanDiego.NCR.COM] <1991022818593000> From: nolet@cns.SanDiego.NCR.COM (Jason Nolet) Newsgroups: comp.protocols.tcp-ip Subject: TCP/IP via Token Ring Message-ID: <860@cns.SanDiego.NCR.COM> Date: 28 Feb 91 18:59:30 GMT Reply-To: nolet@cns.SanDiego.NCR.COM (Jason Nolet) Organization: NCR Corp. SE-San Diego Lines: 17 Netters: Has anyone out there implemented the TCP/IP protocols over a Token Ring LAN? If so, is there an RFC is can turn to (1042 maybe)? I would be very interested in the names of any vendors which offer such as product. Thanks for your help! /******************************************************/ /* Jason Nolet */ /* Network Products Div. - San Diego, NCR Corporation */ /* email: Jason.Nolet@SanDiego.NCR.COM */ /* Phone: (619) 578-9000 Fax: (619) 963-5705 */ /******************************************************/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1991Feb28.213453.18756@pcserver2.naitc.com] <1991022821345300> From: kdenning@pcserver2.naitc.com (Karl Denninger) Newsgroups: comp.protocols.tcp-ip Subject: Time server (Internet-style); anyone got freely distributable source? Message-ID: <1991Feb28.213453.18756@pcserver2.naitc.com> Date: 28 Feb 91 21:34:53 GMT Organization: AC Nielsen, Bannockburn IL USA Lines: 20 Hi! I'm looking for the source code to the Internet time server program. The MIPS systems we have here have a thing called "timed", and the Suns have "rdate". Both of these appear to be proprietary to their respective machines. I would like to be able to synchronize all the clocks in our domain using this.... including PCs. Beame and Whiteside has the ability to query one on demand, if I can find the Unix-side code! Thanks in advance for pointers or code! -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [17082@sdcc6.ucsd.edu] <1991022822002900> From: bruno@sdcc10.ucsd.edu (Bruce W. Mohler) Newsgroups: comp.protocols.tcp-ip,comp.sources.wanted,comp.unix.admin Subject: whois server source Keywords: whois server source Message-ID: <17082@sdcc6.ucsd.edu> Date: 28 Feb 91 22:00:29 GMT Sender: news@sdcc6.ucsd.edu Followup-To: comp.sources.wanted Distribution: na Lines: 14 Nntp-Posting-Host: sdcc10.ucsd.edu Does anyone know of any freely available source to a whois server? I'm aware of the ones that are available from UC Davis and U Virginia. I'm aware of the "client" program that is part of the BSD 4.3 distribution. All pointers welcome! Thanks, in advance. Bruce -- Bruce W. Mohler Systems Programmer (aka Staff Analyst) bruno@sdcc10.ucsd.edu voice: 619-586-2218 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [36540023@hpindwa.cup.hp.com] <1991022822535800> From: raj@hpindwa.cup.hp.com (Rick Jones) Newsgroups: comp.protocols.tcp-ip Subject: Does BSD Know Packets? Message-ID: <36540023@hpindwa.cup.hp.com> Date: 28 Feb 91 22:53:58 GMT Organization: Hewlett-Packard, Cupertino CA Lines: 28 A few toss-up questions: Does anyone have data showing the 'hit rate' of pulling as much data as possible into a retransmission? Put another way, how often does a series of packets get lost vs a single packet? I think the effectiveness is rather low, but am not sure. This comes out of some 'deep-thought' I've been trying to do concerning BSD's implementing the congestion control packet windows as byte windows - presumeably because BSD does not have a concept of a 'packet rtxq' in favor of a 'bytes rtxq' (Does that change in 4.4?) In another life ;-) I worked-on a system where there was a 'packet rtxq', which would seem to more purely implement a packet congestion window scheme (primarily because it knows how many 'packets' are out there and doesn't estimate it using MSS's). The trade-off (which I think was unconscious) was that there was no 'pulling-up' of data into retransissions. If a 10 byte packet was lost, then a 10 byte packet would be retransmitted. It also seems to have more frequently achieved exponential growth in packet window, whereas BSD seems to effectively get linear (one MSS per ACK packet - or does that change too?) Hence my question as to the effectiveness of pulling-up data into rtxs. There are other questions, but I'll float these first. rick jones ----MESSAGE-END----