----MESSAGE-BEGIN---- [8510011831.AA02522%40nprdc.arpa] <1985100110310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: stanonik@NPRDC.ARPA (Ron Stanonik) Newsgroups: fa.tcp-ip Subject: 4.2BSD tftp doesn't retransmit acks Message-ID: <8510011831.AA02522@nprdc.arpa> Date: Tue, 1-Oct-85 14:31:00 EDT Article-I.D.: nprdc.8510011831.AA02522 Posted: Tue Oct 1 14:31:00 1985 Date-Received: Thu, 3-Oct-85 04:20:42 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 122 Description: A RRQ on receiving a duplicate data packet doesn't retransmit the last ack. Repeat-By: This would happen intermittently between our vax and a pc, but the problem can be reproduced by hacking tftpd.c to not advance its block count and then tftp'ing to yourself. Fix: Move the retransmit code into the inner loop in recvfile(). This actually causes tftp to retransmit on receiving anything but the next expected packet or an error packet. I believe that's in keeping with RFC783, but at any rate it makes tftp "generous in what it accepts". We haven't really observed the corresponding WRQ problem with duplicate acks, but the logic is the same, so we fixed(?) it too. Oh, the diff will probably only make sense if you've already installed the fixes from mogul@gregorio and satz@joyce. Ron Stanonik stanonik@nprdc.arpa RCS file: RCS/tftp.c,v retrieving revision 1.3 diff -c -r1.3 tftp.c *** /tmp/,RCSt1001512 Tue Oct 1 09:43:20 1985 --- tftp.c Tue Oct 1 09:43:00 1985 *************** *** 73,85 } timeout = 0; (void) setjmp(timeoutbuf); - if (trace) - tpacket("sent", stp, size + 4); - n = sendto(f, sbuf, size + 4, 0, (caddr_t)&sin, sizeof (sin)); - if (n != size + 4) { - perror("tftp: sendto"); - goto abort; - } do { alarm(rexmtval); do { --- 73,78 ----- } timeout = 0; (void) setjmp(timeoutbuf); do { if (trace) tpacket("sent", stp, size + 4); *************** *** 81,86 goto abort; } do { alarm(rexmtval); do { fromlen = sizeof (from); --- 74,86 ----- timeout = 0; (void) setjmp(timeoutbuf); do { + if (trace) + tpacket("sent", stp, size + 4); + n = sendto(f, sbuf, size + 4, 0, (caddr_t)&sin, sizeof (sin)); + if (n != size + 4) { + perror("tftp: sendto"); + goto abort; + } alarm(rexmtval); do { fromlen = sizeof (from); *************** *** 144,157 } timeout = 0; (void) setjmp(timeoutbuf); - if (trace) - tpacket("sent", stp, size); - if (sendto(f, sbuf, size, 0, (caddr_t)&sin, - sizeof (sin)) != size) { - alarm(0); - perror("tftp: sendto"); - goto abort; - } do { alarm(rexmtval); do --- 144,149 ----- } timeout = 0; (void) setjmp(timeoutbuf); do { if (trace) tpacket("sent", stp, size); *************** *** 153,158 goto abort; } do { alarm(rexmtval); do n = recvfrom(f, rbuf, sizeof (rbuf), 0, --- 145,158 ----- timeout = 0; (void) setjmp(timeoutbuf); do { + if (trace) + tpacket("sent", stp, size); + if (sendto(f, sbuf, size, 0, (caddr_t)&sin, + sizeof (sin)) != size) { + alarm(0); + perror("tftp: sendto"); + goto abort; + } alarm(rexmtval); do n = recvfrom(f, rbuf, sizeof (rbuf), 0, ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510012043.AA03256%40UCB-VAX.ARPA] <1985100111313900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: Myer@DEWEY.UDEL.EDU Newsgroups: fa.tcp-ip Subject: Papers on tcp/ip Message-ID: <8510012043.AA03256@UCB-VAX.ARPA> Date: Tue, 1-Oct-85 15:31:39 EDT Article-I.D.: UCB-VAX.8510012043.AA03256 Posted: Tue Oct 1 15:31:39 1985 Date-Received: Thu, 3-Oct-85 05:36:18 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 2 I am doing a study of tcp/ip. I would like to have a bibliography on papers that have anything to do with tcp or ip. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BUSC-ISI.ARPA%5D.1-Oct-85.20:31:33.CERF] <1985100116310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: CERF@USC-ISI.ARPA Newsgroups: fa.tcp-ip Subject: Re: Papers on tcp/ip Message-ID: <[USC-ISI.ARPA].1-Oct-85.20:31:33.CERF> Date: Tue, 1-Oct-85 20:31:00 EDT Article-I.D.: <[USC-ISI.ARPA].1-Oct-85.20:31:33.CERF> Posted: Tue Oct 1 20:31:00 1985 Date-Received: Thu, 3-Oct-85 06:42:48 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 3 Jon Postel probably has the best bibliography - also check with the NIC. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100212124600> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 2 Oct 85 19:19:05-PDT Date: 2 Oct 1985 19:12:46 PDT From: POSTEL@USC-ISIB.ARPA Subject: TCP Testing To: tcp-ip@SRI-NIC.ARPA Hi: Back in the olden days when TCP's were first being tested by those "old network boys" of legend, there were a couple of events called "TCP Bakeoff"s. The first bakeoff was held at ISI with all the implementers of different TCP in the same room (well actually a set of offices on a common hall) -- all six of them. The date of this event escapes me just now. The second bakeoff was held over the network in the spring of 1980. I've dug up the rules used in that bakeoff and appended them below. They may or may not be helpful in suggesting some testing for current implementations of TCP. --jon. < INC-PROJECT, BAKEOFF.NLS.2, >, 8-Apr-80 22:12 JBP ;;;; TCP & IP BAKE OFF --- - -- ---- --- This is the procedure for the distributed TCP & IP Bake Off. Each implementer of a TCP & IP is to perform the following tests and to report the results. You are on the honor system. I will try to figure out some way of presenting the results. The testing period is from now through 27 April. All results must be reported via sndmsg to LINDA@ISIE by midnight (Pacific time) on Monday 28 April. Scoring Note that many of the following apply for each distinct TCP contacted (for example, in the Middleweight Division there is a possibility of 20 points for each other TCP in the Bake Off). Note Bene: Checksums must be enforced. No points will be awarded if the checksum test is disabled. Featherweight Division 1 points for talking to yourself (opening a connection) 1 points for saying something to yourself (sending and receiving data) 1 points for gracefully ending the conversation (closing the connection without crashing) 2 point for a repeating the above without reinitializing the TCP 5 points for a complete conversation via the testing gateway Middleweight Division 2 points for talking to someone else (opening a connection) 2 points for saying something to someone else (sending and receiving data) 2 points for gracefully ending the conversation (closing the connection without crashing) 4 points for a repeating the above without reinitializing the TCP 10 points for a complete conversation via the testing gateway Heavyweight Division 10 points for being able to talk to more than one other TCP at the same time (multiple connections open and active simultaneously with different TCPs) 10 points for correctly handling urgent data 10 points for correctly handling rubber baby buffer bumpers in both directions (End of Letter sequence number adjustments) 10 points for correctly handling sequence number wraparound 10 points for correctly being able to process a "Kamikaze" packet (AKA Nastygram, Christmas tree packet, lamp test segment, et al.) That is, correctly handle a segment with the maximum combination of features at once, e.g., a SYN URG EOL FIN segment with options and data. 30 points for KOing your opponent with legal blows (That is, operate a connection until one TCP or the other crashes, the surviving TCP has KOed the other. Legal blows are segments that meet the requirements of the specification.) 20 points for KOing your opponent with dirty blows (Dirty blows are segments that do not meet the requirements of the specification.) 10 points for showing your opponents checksum test is faulty or disabled Host & Gateway IP Division 25 points for doing fragmentation and reassembly 15 points for doing source route option 10 points for doing return route option 10 points for using quench messages 10 points for using routing advice messages 5 points for doing something with the type of service 5 points for doing something with the security option 5 points for doing something with the timestamp option 5 points for showing that a gateway forwards datagrams without decreasing the time to live 5 points for showing that a gateway forwards datagrams with the time to live equal zero 10 points for showing that a gateway or hosts checksum test is faulty or disabled Bonus Points 10 point for the best excuse 20 points for the fewest excuses 30 points for the longest conversation 40 points for the most simultaneous connections 50 points for the most simultaneous connections with distinct TCPs The following tests have been identified for checking the capabilities of a TCP implementation. These may be useful in attempting to KO an opponent. 1. Single connection. Open & close a single connection many times. 2. Multi connections. Open several connections simultaneously. Two connections to the same socket (i.e., a-b and a-c) check proper separation of data. 3. Half Open Connection. Open a connection, crash local TCP and attempt to open same connection again. 4. Piggy-back Loop. Open connections via Telnet. user telnet--->TCP--->TCP--->server telnet ! V server telnet<---TCP<---TCP<---user telnet ! V user telnet--->... 5. Maximum connections. Open connections between a pair of TCP until refused or worse. 6. Refused connection. Open a connection to a non-accepting socket, does it get refused? 7. Zero Window. Try to send data to a TCP that is presenting a zero window. 8. Fire Hose. Make many connections to data source ports (e.g., TTYTST at TENEX), or connections to a data sink and send as fast as you can. 9. Urgent Test. Try to send data to a user program that only receives data when in urgent mode. 10. Kamikazi Segment. Send and Receive NASTYGRAMS. A NASTYGRAM is a segment with SYN, EOL, URG, and FIN on and carrying one octet of data. 11. Sequence Wraparound. Test proper functioning when sequence numbers (a) pass 2**31 (i.e., go from plus to "minus") and (b) pass 2**32 (i.e., go from 2**32-1 to 0). 12. Buffer size. With buffer size not equal to one, send data in letters of various sizes, use urgent occasionally. 13. Send a NASTYGRAM into a half open connection when the sequence number is about to wrap around. *** end *** ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510030231.AA02846%40UCB-VAX.ARPA] <1985100218124600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: POSTEL@USC-ISIB.ARPA Newsgroups: fa.tcp-ip Subject: TCP Testing Message-ID: <8510030231.AA02846@UCB-VAX.ARPA> Date: Wed, 2-Oct-85 22:12:46 EDT Article-I.D.: UCB-VAX.8510030231.AA02846 Posted: Wed Oct 2 22:12:46 1985 Date-Received: Fri, 4-Oct-85 03:09:49 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 193 Hi: Back in the olden days when TCP's were first being tested by those "old network boys" of legend, there were a couple of events called "TCP Bakeoff"s. The first bakeoff was held at ISI with all the implementers of different TCP in the same room (well actually a set of offices on a common hall) -- all six of them. The date of this event escapes me just now. The second bakeoff was held over the network in the spring of 1980. I've dug up the rules used in that bakeoff and appended them below. They may or may not be helpful in suggesting some testing for current implementations of TCP. --jon. < INC-PROJECT, BAKEOFF.NLS.2, >, 8-Apr-80 22:12 JBP ;;;; TCP & IP BAKE OFF --- - -- ---- --- This is the procedure for the distributed TCP & IP Bake Off. Each implementer of a TCP & IP is to perform the following tests and to report the results. You are on the honor system. I will try to figure out some way of presenting the results. The testing period is from now through 27 April. All results must be reported via sndmsg to LINDA@ISIE by midnight (Pacific time) on Monday 28 April. Scoring Note that many of the following apply for each distinct TCP contacted (for example, in the Middleweight Division there is a possibility of 20 points for each other TCP in the Bake Off). Note Bene: Checksums must be enforced. No points will be awarded if the checksum test is disabled. Featherweight Division 1 points for talking to yourself (opening a connection) 1 points for saying something to yourself (sending and receiving data) 1 points for gracefully ending the conversation (closing the connection without crashing) 2 point for a repeating the above without reinitializing the TCP 5 points for a complete conversation via the testing gateway Middleweight Division 2 points for talking to someone else (opening a connection) 2 points for saying something to someone else (sending and receiving data) 2 points for gracefully ending the conversation (closing the connection without crashing) 4 points for a repeating the above without reinitializing the TCP 10 points for a complete conversation via the testing gateway Heavyweight Division 10 points for being able to talk to more than one other TCP at the same time (multiple connections open and active simultaneously with different TCPs) 10 points for correctly handling urgent data 10 points for correctly handling rubber baby buffer bumpers in both directions (End of Letter sequence number adjustments) 10 points for correctly handling sequence number wraparound 10 points for correctly being able to process a "Kamikaze" packet (AKA Nastygram, Christmas tree packet, lamp test segment, et al.) That is, correctly handle a segment with the maximum combination of features at once, e.g., a SYN URG EOL FIN segment with options and data. 30 points for KOing your opponent with legal blows (That is, operate a connection until one TCP or the other crashes, the surviving TCP has KOed the other. Legal blows are segments that meet the requirements of the specification.) 20 points for KOing your opponent with dirty blows (Dirty blows are segments that do not meet the requirements of the specification.) 10 points for showing your opponents checksum test is faulty or disabled Host & Gateway IP Division 25 points for doing fragmentation and reassembly 15 points for doing source route option 10 points for doing return route option 10 points for using quench messages 10 points for using routing advice messages 5 points for doing something with the type of service 5 points for doing something with the security option 5 points for doing something with the timestamp option 5 points for showing that a gateway forwards datagrams without decreasing the time to live 5 points for showing that a gateway forwards datagrams with the time to live equal zero 10 points for showing that a gateway or hosts checksum test is faulty or disabled Bonus Points 10 point for the best excuse 20 points for the fewest excuses 30 points for the longest conversation 40 points for the most simultaneous connections 50 points for the most simultaneous connections with distinct TCPs The following tests have been identified for checking the capabilities of a TCP implementation. These may be useful in attempting to KO an opponent. 1. Single connection. Open & close a single connection many times. 2. Multi connections. Open several connections simultaneously. Two connections to the same socket (i.e., a-b and a-c) check proper separation of data. 3. Half Open Connection. Open a connection, crash local TCP and attempt to open same connection again. 4. Piggy-back Loop. Open connections via Telnet. user telnet--->TCP--->TCP--->server telnet ! V server telnet<---TCP<---TCP<---user telnet ! V user telnet--->... 5. Maximum connections. Open connections between a pair of TCP until refused or worse. 6. Refused connection. Open a connection to a non-accepting socket, does it get refused? 7. Zero Window. Try to send data to a TCP that is presenting a zero window. 8. Fire Hose. Make many connections to data source ports (e.g., TTYTST at TENEX), or connections to a data sink and send as fast as you can. 9. Urgent Test. Try to send data to a user program that only receives data when in urgent mode. 10. Kamikazi Segment. Send and Receive NASTYGRAMS. A NASTYGRAM is a segment with SYN, EOL, URG, and FIN on and carrying one octet of data. 11. Sequence Wraparound. Test proper functioning when sequence numbers (a) pass 2**31 (i.e., go from plus to "minus") and (b) pass 2**32 (i.e., go from 2**32-1 to 0). 12. Buffer size. With buffer size not equal to one, send data in letters of various sizes, use urgent occasionally. 13. Send a NASTYGRAM into a half open connection when the sequence number is about to wrap around. *** end *** ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510030815.AA08214%40UCB-VAX.ARPA] <1985100221472100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: @CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20 (Asheem) Newsgroups: fa.tcp-ip Subject: Intel 310 Networking Message-ID: <8510030815.AA08214@UCB-VAX.ARPA> Date: Thu, 3-Oct-85 01:47:21 EDT Article-I.D.: UCB-VAX.8510030815.AA08214 Posted: Thu Oct 3 01:47:21 1985 Date-Received: Fri, 4-Oct-85 04:46:03 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 36 Hi, I am working on a year long LAN project that utilizes the Intel 310 OEM Microcomputer system. I was wondering if anyone on the net has used the Intel 310 System for LAN applications. I'd appreciate receiving any comments, advice, misc. info. from anyone who has worked with any of the following Intel products : 1. the iSBC 186/51 COMMputer Multibus board (Ethernet) 2. the iSBC 550/550 Kit Multibus board (Ethernet) 3. iNA 960 Network Software 4. iRMX Net 5. OpenNET . 6. the new iSXM 554 Multibus board (MAP - Token Passing Bus) I also have some specific questions relating to the above, but it's probably more appropriate to carry on a detailed discussion individually between interested parties. Thanks in advance for your help. Asheem Chandna EE Senior Case Western Reserve U. ARPANET : chandna%cwr20b@cu20b.arpa OR chandna%cwru-20b%cwruecmp@csnet-relay.arpa BITNET : chandna%cwr20b@cu20b.bitnet CSNET : chandna%cwru-20b%case.csnet ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100221472101> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Oct 85 01:00:05-PDT Received: from case by csnet-relay.csnet id af12312; 3 Oct 85 3:58 EDT Received: from CWRU-20 (cwru-20.ARPA) by cwruecmp.UUCP (4.12/5.25); Thu, 3 Oct 85 01:46:36 edt Date: Thu 3 Oct 85 01:47:21-EDT From: Asheem <@CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20> Subject: Intel 310 Networking To: tcp-ip@sri-nic.ARPA Hi, I am working on a year long LAN project that utilizes the Intel 310 OEM Microcomputer system. I was wondering if anyone on the net has used the Intel 310 System for LAN applications. I'd appreciate receiving any comments, advice, misc. info. from anyone who has worked with any of the following Intel products : 1. the iSBC 186/51 COMMputer Multibus board (Ethernet) 2. the iSBC 550/550 Kit Multibus board (Ethernet) 3. iNA 960 Network Software 4. iRMX Net 5. OpenNET . 6. the new iSXM 554 Multibus board (MAP - Token Passing Bus) I also have some specific questions relating to the above, but it's probably more appropriate to carry on a detailed discussion individually between interested parties. Thanks in advance for your help. Asheem Chandna EE Senior Case Western Reserve U. ARPANET : chandna%cwr20b@cu20b.arpa OR chandna%cwru-20b%cwruecmp@csnet-relay.arpa BITNET : chandna%cwr20b@cu20b.bitnet CSNET : chandna%cwru-20b%case.csnet ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510031732.AA07555%40ll-vlsi.ARPA] <1985100309325400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: wjc@LL-VLSI.ARPA (Bill Chiarchiaro) Newsgroups: fa.tcp-ip Subject: System V -- Help! Message-ID: <8510031732.AA07555@ll-vlsi.ARPA> Date: Thu, 3-Oct-85 13:32:54 EDT Article-I.D.: ll-vlsi.8510031732.AA07555 Posted: Thu Oct 3 13:32:54 1985 Date-Received: Fri, 4-Oct-85 06:19:59 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 7 I have unfortunately been saddled with three machines running UNIX System V. Does anyone know of any successful implementation of TCP/IP support for this system? Please respond to wjc@ll-vlsi as I am not on this mailing list; if the list's administrator is listening, I'd like to be added. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510032051.AA20033%40UCB-VAX.ARPA] <1985100312273800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: Bhobe@DEWEY.UDEL.EDU Newsgroups: fa.tcp-ip Subject: lan internetworking Message-ID: <8510032051.AA20033@UCB-VAX.ARPA> Date: Thu, 3-Oct-85 16:27:38 EDT Article-I.D.: UCB-VAX.8510032051.AA20033 Posted: Thu Oct 3 16:27:38 1985 Date-Received: Fri, 4-Oct-85 06:51:31 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 Hello I have to present a paper on LAN INTERNETWORKING in the class.As of today I have been able to locate only afew good ones like the one by Dr. Dalal on 'Why 48 bits address for Ethernet' and another one on Campusnet. Can somebody let me know a few more at their earliest.Awaiting your reply. shailesh ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12148242293.28.WUTS%40USC-ECLC.ARPA] <1985100312475900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: WUTS@USC-ECLC.ARPA (Maurice J. Wuts) Newsgroups: fa.tcp-ip Subject: Time servers Message-ID: <12148242293.28.WUTS@USC-ECLC.ARPA> Date: Thu, 3-Oct-85 16:47:59 EDT Article-I.D.: USC-ECLC.12148242293.28.WUTS Posted: Thu Oct 3 16:47:59 1985 Date-Received: Sat, 5-Oct-85 02:16:06 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 4 I know there are Unix time pollers / servers out there. Is there anyone with a Tops20 version? Maurice Wuts ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510060245.AA01386%40orion.ARPA] <1985100518454000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems G) Newsgroups: fa.tcp-ip Subject: IBM TCP/IP product Message-ID: <8510060245.AA01386@orion.ARPA> Date: Sat, 5-Oct-85 22:45:40 EDT Article-I.D.: orion.8510060245.AA01386 Posted: Sat Oct 5 22:45:40 1985 Date-Received: Sun, 6-Oct-85 15:02:21 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 13 Folks, my division is considering buying the IBM TCP/IP package which was developed by UWISC for IBM. For various reasons, we'd like an ethernet connection to our 4381 machine, and this looks like a pretty good way, especially with the peripheral programs like tn3270 and the rest which do block mode emulation. If anybody out there has any experience with this product, both positive and negative, I'd appreciate a note with your comments. I know spartacus has a similar product, buts I don't know of any running on the internet, and I'm not sure about block mode support. Thanks, Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100700360000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 7 Oct 85 08:39:41-PDT Date: 7 Oct 1985 08:36 PST From: Gary Krall Subject: IBM Ethernet attach To: TCP-IP@SRI-NIC Cc: MEDIN%ORION@AMES,FALSETTI%ORION@AMES Reply-To: GARY@ACC.ARPA ACC has recently delivered to Rutgers University (re: Messrs. Hendrick and Marantz) a IBM to Ethernet attachment. Functionally it is the same basic hardware as the 370/DDN interface (ie. Block Mux interface to the channel with 68000 micro's running in a multi-processing environment) except that it attaches directly to the LAN. For host processors running MVS it uses the UCLA developed code set (re: Bob Braden) and has yet to be tested for VM (which we believe should work based on the McKay article in Signal). The Rutgers system is a beta site and ACC will keep you aprised as to the developments. Let me know if you require additional information. Regards, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100702070000> Received: from ge-crd.ARPA by SRI-NIC.ARPA with TCP; Mon 7 Oct 85 06:19:51-PDT Date: 7 Oct 85 09:07:00 PDT From: HATFIELD, WILLIAM T To: tcp-ip Reply-To: HATFIELD, WILLIAM T I'd like to get on the mailing list to receive information dealing with work going on in the area of TCP-IP and Clients. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510071613.AA02833%40UCB-VAX.ARPA] <1985100708360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: GARY@ACC.ARPA (Gary Krall) Newsgroups: fa.tcp-ip Subject: IBM Ethernet attach Message-ID: <8510071613.AA02833@UCB-VAX.ARPA> Date: Mon, 7-Oct-85 12:36:00 EDT Article-I.D.: UCB-VAX.8510071613.AA02833 Posted: Mon Oct 7 12:36:00 1985 Date-Received: Tue, 8-Oct-85 04:08:19 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 19 ACC has recently delivered to Rutgers University (re: Messrs. Hendrick and Marantz) a IBM to Ethernet attachment. Functionally it is the same basic hardware as the 370/DDN interface (ie. Block Mux interface to the channel with 68000 micro's running in a multi-processing environment) except that it attaches directly to the LAN. For host processors running MVS it uses the UCLA developed code set (re: Bob Braden) and has yet to be tested for VM (which we believe should work based on the McKay article in Signal). The Rutgers system is a beta site and ACC will keep you aprised as to the developments. Let me know if you require additional information. Regards, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510071705.AA09371%40ucbopal.Berkeley.Edu] <1985100709050200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: minshall@UCBOPAL.CC (Greg Minshall) Newsgroups: fa.tcp-ip Subject: Wisconsin code Message-ID: <8510071705.AA09371@ucbopal.Berkeley.Edu> Date: Mon, 7-Oct-85 13:05:02 EDT Article-I.D.: ucbopal.8510071705.AA09371 Posted: Mon Oct 7 13:05:02 1985 Date-Received: Thu, 10-Oct-85 08:03:43 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 27 Hi. We've been running the Wisconsin code for a couple of years. Installing it (especially for the DACU) is somewhat of a pain, but actually it runs fairly well. It is not clear to me whether you are better off trying to get the code from U of Wisconsin or from IBM. Each piece of code has things that the other does not have. In terms of performance (which you didn't ask about, but still...), a single Vax <-> 370 connection can run from 12 to 20 kBytes/second. This isn't too swift, given that a Vax <-> Vax connection can run about 50-80 kBytes/second. However, in the Vax <-> 370 case, the numbers appear to be additive; thus two Vax <-> 370 connections (two Vaxen, one 370 = 3081) seems to run about twice as fast as one, three connections run three times as fast, etc. The Spartacus people DO support 3270 emulation. They do the protocol conversion in the 370, which allows you to run from, say, an IBM PC or TOPS20, or whatever. This is a plus. The downsides are two: 1) every character is echoed from the 370; and 2) the 370 needs to know "/etc/termcap" information about every terminal that will connect to it. (please note: I've never used the Spartacus boxes or software, so I am commenting based on what I remember from reading and discussing. The Spartacus people do have tn3270, and may be trying to support that interface as well. Hope this helps. Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510071706.AA00348%40orion.ARPA] <1985100709063700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems G) Newsgroups: fa.tcp-ip Subject: Re: IBM Ethernet attach Message-ID: <8510071706.AA00348@orion.ARPA> Date: Mon, 7-Oct-85 13:06:37 EDT Article-I.D.: orion.8510071706.AA00348 Posted: Mon Oct 7 13:06:37 1985 Date-Received: Thu, 10-Oct-85 05:45:26 EDT References: <8510071541.AA01350@ames.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 8 I'd heard about the ACC product, and it looks to be pretty fast, but I'm concerned about the software support, especially re: block mode emulation of remote TTY's. I believe the remote system should be the guy to do the block mode interpretation, not the IBM machine, since the remote machine certainly should know the screen characteristics of the terminal... Milo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510071854.AA00367%40sri-med] <1985100710543100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: poggio@SRI-TSC.ARPA (Andy Poggio) Newsgroups: fa.tcp-ip Subject: ACM Sigcomm Announcement Message-ID: <8510071854.AA00367@sri-med> Date: Mon, 7-Oct-85 14:54:31 EDT Article-I.D.: sri-med.8510071854.AA00367 Posted: Mon Oct 7 14:54:31 1985 Date-Received: Tue, 8-Oct-85 04:18:34 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 79 CALL FOR PAPERS ACM SIGCOMM '86 SYMPOSIUM Communications Architectures and Protocols Stowe, Vermont August 5-7, 1986 The symposium provides an international forum for the presentation and discussion of communication network applications and technologies, as well as recent advances and proposals on communication architectures, protocols, algorithms, and performance models. Authors are invited to submit full papers concerned with both theory and practice. The areas of interest for the symposium include, but are not limited to the following: Computer network architectures and algorithms Local area networks Computer-based multimedia communications Network interconnection Packet radio networks Satellite and wideband networks Computer networking standards Distributed operating systems Protocol specification, verification, and analysis Applications of computer networks (education, office automation, banking, factory of the future) Papers should be about 20 double-spaced pages long and should have an abstract of 100-150 words. All submitted papers will be reviewed and will be judged with respect to their quality and relevance. Authors of selected papers will be expected to sign an ACM copyright release form. The Proceedings will be distributed at the symposium and published as a special issue of SIGCOMM's Computer Communication Review. Since the proceedings of this conference will be widely disseminated, publication is likely to inhibit republications in ACM's refereed publications. However, a few of the submitted papers will be selected for publication in the ACM Transactions on Computer Systems. Submit 5 copies of each paper by February 15, 1986 to the co-program chairman: Dr. Jose J. Garcia Luna, SRI International, 333 Ravenswood Avenue, Menlo Park, CA 94025, USA. IMPORTANT DATES Deadline for paper submission February 15, l986 Notification of acceptance March 31, 1986 Camera-ready manuscripts due May 15, 1986 General Chairman: Walter Kosinsky, Central China University of Science and Technology Co-program Chairmen: Jose J. Garcia Luna and Franklin F. Kuo, SRI International, California Program Committee Members: David Cheriton, Stanford University, Simon Lam, Univ. of Texas at Austin, USA USA Wesley Chu, UCLA, USA Lawrence Landweber, Univ. of Wisconsin, USA Richard desJardins, DARPA/IPTO, USA Najah Naffah, Bull Transac, France Michael Ferguson, Raphael Rom, SRI International, USA INRS Telecommunications, Canada Juan Garduno, Harry Rudin, IBM Research Lab, Instituto Politecnico Nacional, Mexico Switzerland Jean-Louis Grange, INRIA, France Nachum Shacham, SRI International, USA Peter Kirstein, University College Carl Sunshine, System Development London, UK Corporation, USA Hisashi Kobayashi, IBM Japan, Ltd., Fouad Tobagi, Stanford Univerity, USA Japan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100808262400> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 8 Oct 85 15:30:30-PDT Date: 8 Oct 1985 15:26:24 PDT Subject: Excelan From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA I am interested in the suitability of Excelan products (hardware and software) for internet purposes. I recall seeing some bad press on their Ethernet board for the Masscomp machine. Does anyone else have any other data, good or bad? Just reply to me; no use filling the disks of america needlessly. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1985.10.08.11.53.24.020.03340%40Dione.rice] <1985100808532300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: fa.tcp-ip Subject: IBM block mode tty emulation Message-ID: <1985.10.08.11.53.24.020.03340@Dione.rice> Date: Tue, 8-Oct-85 12:53:23 EDT Article-I.D.: Dione.1985.10.08.11.53.24.020.03340 Posted: Tue Oct 8 12:53:23 1985 Date-Received: Sat, 12-Oct-85 12:18:38 EDT References: <8510071706.AA00348@orion.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 26 "I believe the remote system should be the guy to do the block mode interpretation" - Milo Medin Milo: My modifications to 4.2bsd telnet to support 3278 emulation do exactly that. When, during option negotiation, the client is asked for its terminal type, it assumes the server host must be a 370 and replies that it is an IBM-3278-x, where 'x' depends on the screen size determined from termcap. After that it uses the curses library plus a file containing terminal-specific key bindings to perform 3270 emulation. My code has only been tested against the WISCNET implementation, though after a conversation with Lou Rivas I believe it should work with the UCLA code modulo some tweaking of the option negotiations. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX Domain: milazzo@rice.EDU ARPA: milazzo@rice.ARPA BITNET: milazzo@rice-net, milazzo@ricecsvm UUCP: {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510082242.AA08882%40UCB-VAX.ARPA] <1985100814262400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: fa.tcp-ip Subject: Excelan Message-ID: <8510082242.AA08882@UCB-VAX.ARPA> Date: Tue, 8-Oct-85 18:26:24 EDT Article-I.D.: UCB-VAX.8510082242.AA08882 Posted: Tue Oct 8 18:26:24 1985 Date-Received: Fri, 11-Oct-85 08:22:58 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 8 I am interested in the suitability of Excelan products (hardware and software) for internet purposes. I recall seeing some bad press on their Ethernet board for the Masscomp machine. Does anyone else have any other data, good or bad? Just reply to me; no use filling the disks of america needlessly. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510091438.AA24099%40UCB-VAX.ARPA] <1985100905114500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: delp@HUEY.UDEL.EDU (Gary Delp) Newsgroups: fa.tcp-ip Subject: Re: Excelan Message-ID: <8510091438.AA24099@UCB-VAX.ARPA> Date: Wed, 9-Oct-85 09:11:45 EDT Article-I.D.: UCB-VAX.8510091438.AA24099 Posted: Wed Oct 9 09:11:45 1985 Date-Received: Sat, 12-Oct-85 14:06:57 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 4 dan, Can you let me know what your responses are? thanks, gary ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100905114501> Received: from Huey.UDEL.EDU by SRI-NIC.ARPA with TCP; Wed 9 Oct 85 06:20:41-PDT Received: from localhost by .Huey.UDEL.EDU id a007358; 9 Oct 85 9:11 EDT To: Dan Lynch cc: tcp-ip@sri-nic.ARPA Subject: Re: Excelan In-Reply-To: Your message of 8 Oct 1985 15:26:24 PDT. Date: 09 Oct 85 09:11:45 EDT (Wed) From: Gary Delp dan, Can you let me know what your responses are? thanks, gary ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985100908123800> Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Oct 85 09:13:38-PDT Received: by EDN-VAX.ARPA (4.12/4.7) Date: Wed, 9 Oct 85 12:12:38 edt From: swanson@EDN-VAX.ARPA (John Swanson) To: tcp-ip@sri-nic.ARPA Could the author of the TCP bakeoff message please forward me another copy. Our machines disk crashed and when they resored the directories I had lost that message and I would like to have it. Thanks to whomever! J. Swanson ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12150349358.30.HAL%40SRI-NIC.ARPA] <1985101113422600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: HAL@SRI-NIC.ARPA (Hal Huntley) Newsgroups: fa.tcp-ip Subject: TCP for IBM AT? Message-ID: <12150349358.30.HAL@SRI-NIC.ARPA> Date: Fri, 11-Oct-85 17:42:26 EDT Article-I.D.: SRI-NIC.12150349358.30.HAL Posted: Fri Oct 11 17:42:26 1985 Date-Received: Sat, 12-Oct-85 20:04:58 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 6 Anyone know of a TCP-IP implementation for an IBM AT running XENIX 3.0? Someone told me the rumor that Microsoft has it internally, but they are not saying much about it. Hal Huntley ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510120019.AA24304%40UCB-VAX.ARPA] <1985101117520800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: mills@DCN6.ARPA Newsgroups: fa.tcp-ip Subject: NTP and timetelling issues Message-ID: <8510120019.AA24304@UCB-VAX.ARPA> Date: Fri, 11-Oct-85 21:52:08 EDT Article-I.D.: UCB-VAX.8510120019.AA24304 Posted: Fri Oct 11 21:52:08 1985 Date-Received: Sun, 13-Oct-85 04:19:06 EDT Sender: leblanc@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 50 Folks, Experimental servers for the Network Time Protocol (NTP) announced in RFC958 are running now on several fuzzballs, including DCN1, DCN6, FORD1 and UMICH1. These are servers only and do not implement the distributed algorithms suggested in RFC958. The servers are implemented as a user process, so are not as accurate as ICMP Timestamp messages. Our experience indicates accuracies in the order of 50-ms relative to NBS time should be expected as the NTP reply timestamp leaves one of these hosts. Two new hosts each specifically associated with a radio clock have been activated. One of these (128.4.0.15) tracks WWVB and the other (128.4.0.14) tracks WWV. Particular care was taken in their design to preserve the highest accuracy of ICMP Timestamp messages. For all other protocols, including TCP and UDP, these hosts perform only the standard echo function (RFC862). We have made a number of changes to our fuzzballs and timetellers in order to improve timekeeping robustness and move toward a truly distributed clock service. In summary, we have direct access to two radio clocks (WWVB and WWV) and indirect access to a third (GOES), all of which are available to the local-net routing and timekeeping functions. We have arranged automatic fallback to secondary clocks should the primary ones fail. For this prupose a clock which has never synchronized or has either failed to respond to a poll or has indicated loss of signal for over two minutes is considered to have failed. Only one radio clock will be used at any time to synchronize our local network and its dependencies, including timestamps returned from all 128.4 hosts. In order of preference, the WWVB clock will be chosen first. If it is down the next choice will be the WWV clock and the last the GOES clock. If no radio clock is up the host clock will free-run relative to the last radio-clock update and the intrinsic drift of its crystal. The fallback procedure is automatic and should be glitch-free, except possibly for a step offset if a difference of over 128 milliseconds is involved. If for some reason the host clock was never synchronized, such as when first booted and before any radio-clock updates have occured, that host will not respond to UDP time requests and will close TCP time requests immediately without sending data, which is consistent with RFC868. At present there is no provision for marking a host clock unsynchronized once it has been synchronized; however, our experience indicates the stability of the host clocks is such that this would be indicated only after a prolonged outage (a matter of days) of all radio clocks, which is considered unlikely. The intended result of all this effort is that rotten timestamps such as recently escaped our swamp due thunderstorms and hurricanes will not recur to destabilize the files, messages and bombs of our friends. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101121501600> Received: from DCN7.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Oct 85 16:53:58-PDT Date: 11-Oct-85 21:50:16-UT From: mills@dcn6.arpa Subject: NTP and timetelling issues To: tcp-ip@sri-nic.arpa cc: mills@dcn6.arpa Folks, Experimental servers for the Network Time Protocol (NTP) announced in RFC958 are running now on several fuzzballs, including DCN1, DCN6, FORD1 and UMICH1. These are servers only and do not implement the distributed algorithms suggested in RFC958. The servers are implemented as a user process, so are not as accurate as ICMP Timestamp messages. Our experience indicates accuracies in the order of 50-ms relative to NBS time should be expected as the NTP reply timestamp leaves one of these hosts. Two new hosts each specifically associated with a radio clock have been activated. One of these (128.4.0.15) tracks WWVB and the other (128.4.0.14) tracks WWV. Particular care was taken in their design to preserve the highest accuracy of ICMP Timestamp messages. For all other protocols, including TCP and UDP, these hosts perform only the standard echo function (RFC862). We have made a number of changes to our fuzzballs and timetellers in order to improve timekeeping robustness and move toward a truly distributed clock service. In summary, we have direct access to two radio clocks (WWVB and WWV) and indirect access to a third (GOES), all of which are available to the local-net routing and timekeeping functions. We have arranged automatic fallback to secondary clocks should the primary ones fail. For this prupose a clock which has never synchronized or has either failed to respond to a poll or has indicated loss of signal for over two minutes is considered to have failed. Only one radio clock will be used at any time to synchronize our local network and its dependencies, including timestamps returned from all 128.4 hosts. In order of preference, the WWVB clock will be chosen first. If it is down the next choice will be the WWV clock and the last the GOES clock. If no radio clock is up the host clock will free-run relative to the last radio-clock update and the intrinsic drift of its crystal. The fallback procedure is automatic and should be glitch-free, except possibly for a step offset if a difference of over 128 milliseconds is involved. If for some reason the host clock was never synchronized, such as when first booted and before any radio-clock updates have occured, that host will not respond to UDP time requests and will close TCP time requests immediately without sending data, which is consistent with RFC868. At present there is no provision for marking a host clock unsynchronized once it has been synchronized; however, our experience indicates the stability of the host clocks is such that this would be indicated only after a prolonged outage (a matter of days) of all radio clocks, which is considered unlikely. The intended result of all this effort is that rotten timestamps such as recently escaped our swamp due thunderstorms and hurricanes will not recur to destabilize the files, messages and bombs of our friends. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101203113300> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Sat 12 Oct 85 10:17:01-PDT Date: 12 Oct 1985 10:11:33 PDT Subject: Re: TCP for IBM AT? From: Dan Lynch To: Hal Huntley cc: tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA In-Reply-To: <12150349358.30.HAL@SRI-NIC.ARPA> Excelan has TCP/IP for the AT running Xenix. You buy their Ethernet board and software and you are on the air. Costs about $1600 for everything in quantity 1 lots. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101207344800> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Sat 12 Oct 85 14:36:52-PDT Date: 12 Oct 1985 14:34:48 PDT Subject: Excelan From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA I got about 10 responses on Excelan products and did some digging myself and have the following to report. Basically they make excellent hardware and their software has evolved from a shaky start to the current one where it is quite featureful and supports all the latest characteristics of TCP/IP. Their basic approach is to provide a board that plugs into the backplane ((Unibus, Qbus, Multibus, VMEbus and the IBM PC)) of your machine and drives the Ethernet from the board. Teh board also contains the full TCP/IP software. The host level software makes library calls (library software provided on a pe operating system basis) to do the usual things (open, send/receive, close,...) thus freeing up the host to do other things than messing with packet level interrupts and checksums. There are arguments for and against this apporach to doing networking. I wont detail them here. One misfeature of the current implementation is that since Excellan terminates the IP protocol in the offhost processor and that offhost processor has no provision for multiple network interfaces it cannot act as a gateway device in an Internet environment. The operating systems currently supported are Xenix, Unix System V, (for the VAX), VMS (including for the MicroVaxII), RSX-11M,PC-DOS and some other brands of System V that are OEM related. The real sleeper in their product line is a workstation they call the Nutcracker. It is a slick development/debugging/repairing tool that sits on your Ethernet and copies all packets into its buffers and then depending on the various sets of filters you have established it will take statistics of all kinds. It is fast enought to do tthis at full speed. It can also inject packets for any destination at any speed you wish and can even generate invalid packets for debugging purposes. Quite a lot of work has gone into this product and for research and development sites it looks like an invaluabe tool at many levels of design. The price for this complete workstation is not low, about $50k. You might not want to get one for home use, but its existence in a good indication of the level of engineering talent that exists inside the company. The prices on their boards and host software modules are quite reasonable and they give generous discounts for large volumes. They are located in San Jose and can be reached at 408-434-2300. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510121816.AA11602%40UCB-VAX] <1985101209113300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: fa.tcp-ip Subject: Re: TCP for IBM AT? Message-ID: <8510121816.AA11602@UCB-VAX> Date: Sat, 12-Oct-85 13:11:33 EDT Article-I.D.: UCB-VAX.8510121816.AA11602 Posted: Sat Oct 12 13:11:33 1985 Date-Received: Mon, 14-Oct-85 03:47:47 EDT References: <12150349358.30.HAL@SRI-NIC.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 5 Excelan has TCP/IP for the AT running Xenix. You buy their Ethernet board and software and you are on the air. Costs about $1600 for everything in quantity 1 lots. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101210435100> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Sat 12 Oct 85 17:46:40-PDT Date: 12 Oct 1985 17:43:51 PDT Subject: Excelan gateway addendum From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA In my previous note I said that their offhost board had no provision for anothr network interface thus preventing it from becoming an IP gateway. The real situation is that there is no existing product that performs that way but the actual architecture of the board allows for other I/O interfaces to be attached on the "outboard" side so one could (with cooperation from Excelan) build such a product. I guess they haven't seen a very large marketplace for such a product yet? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510122218.AA13910%40UCB-VAX] <1985101213344800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: fa.tcp-ip Subject: Excelan Message-ID: <8510122218.AA13910@UCB-VAX> Date: Sat, 12-Oct-85 17:34:48 EDT Article-I.D.: UCB-VAX.8510122218.AA13910 Posted: Sat Oct 12 17:34:48 1985 Date-Received: Mon, 14-Oct-85 03:48:01 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 46 I got about 10 responses on Excelan products and did some digging myself and have the following to report. Basically they make excellent hardware and their software has evolved from a shaky start to the current one where it is quite featureful and supports all the latest characteristics of TCP/IP. Their basic approach is to provide a board that plugs into the backplane ((Unibus, Qbus, Multibus, VMEbus and the IBM PC)) of your machine and drives the Ethernet from the board. Teh board also contains the full TCP/IP software. The host level software makes library calls (library software provided on a pe operating system basis) to do the usual things (open, send/receive, close,...) thus freeing up the host to do other things than messing with packet level interrupts and checksums. There are arguments for and against this apporach to doing networking. I wont detail them here. One misfeature of the current implementation is that since Excellan terminates the IP protocol in the offhost processor and that offhost processor has no provision for multiple network interfaces it cannot act as a gateway device in an Internet environment. The operating systems currently supported are Xenix, Unix System V, (for the VAX), VMS (including for the MicroVaxII), RSX-11M,PC-DOS and some other brands of System V that are OEM related. The real sleeper in their product line is a workstation they call the Nutcracker. It is a slick development/debugging/repairing tool that sits on your Ethernet and copies all packets into its buffers and then depending on the various sets of filters you have established it will take statistics of all kinds. It is fast enought to do tthis at full speed. It can also inject packets for any destination at any speed you wish and can even generate invalid packets for debugging purposes. Quite a lot of work has gone into this product and for research and development sites it looks like an invaluabe tool at many levels of design. The price for this complete workstation is not low, about $50k. You might not want to get one for home use, but its existence in a good indication of the level of engineering talent that exists inside the company. The prices on their boards and host software modules are quite reasonable and they give generous discounts for large volumes. They are located in San Jose and can be reached at 408-434-2300. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510130054.AA15788%40UCB-VAX] <1985101216435100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: LYNCH@USC-ISIB.ARPA (Dan Lynch) Newsgroups: fa.tcp-ip Subject: Excelan gateway addendum Message-ID: <8510130054.AA15788@UCB-VAX> Date: Sat, 12-Oct-85 20:43:51 EDT Article-I.D.: UCB-VAX.8510130054.AA15788 Posted: Sat Oct 12 20:43:51 1985 Date-Received: Mon, 14-Oct-85 04:09:52 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 13 In my previous note I said that their offhost board had no provision for anothr network interface thus preventing it from becoming an IP gateway. The real situation is that there is no existing product that performs that way but the actual architecture of the board allows for other I/O interfaces to be attached on the "outboard" side so one could (with cooperation from Excelan) build such a product. I guess they haven't seen a very large marketplace for such a product yet? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510140712.AA13481%40uw-beaver.arpa] <1985101308450400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: lwa@apollo.UUCP Newsgroups: fa.tcp-ip Subject: Re: 4.2BSD tftp doesn't retransmit acks Message-ID: <8510140712.AA13481@uw-beaver.arpa> Date: Sun, 13-Oct-85 12:45:04 EDT Article-I.D.: uw-beave.8510140712.AA13481 Posted: Sun Oct 13 12:45:04 1985 Date-Received: Tue, 15-Oct-85 06:01:01 EDT References: <8510011831.AA02522@nprdc.arpa> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 63 THAT IS NOT A BUG!! The ORIGINAL tftp spec required retransmisson of ack's, as well as of data packets, upon receiving any old packet. This algorithm was shown to be faulty by Michael Greenwald at MIT. It has the following problem: Suppose host A is talking to host B. Suppose further that host A's retransmit timeout is too short (a common case, since there is no good way to determine an initial retransmit timeout). Now observe what happens: Host A sends packet 1 Host A's retransmit timer goes off, and host A retransmits packet 1. Host B receives packet 1, sends ack 1. Host A receives ack 1, sends packet 2. Host B receives retransmitted packet 1, retransmits ack 1. Host A receives retransmitted ack 1, retransmits packet 2. Host B receives packet 2, sends ack 2. Host A receives ack 2, sends packet 3. Host B receives retransmitted packet 2, retransmits ack 2. Host A receives retransmitted ack 2, retransmits packet 3. . . . . . . Note that what has now happened is that every tftp packet is being transmitted twice. Furthermore, if Host A's retransmit timer goes off too early again, every packet will be transmitted three times, and so forth. This quickly causes tftp performance to degrade to zero, and connections eventually time out. The current tftp spec avoids this problem by specifying that only data packets are to be retransmitted in response to receipt of an old ack, and then only if the ack is for the previously transmitted data packet. Acks are retransmitted ONLY when the retransmit timer expires. I believe that this is the way the Berkeley tftp currently (and correctly) behaves, and hence that Ron's "bug fix" is in fact unnecessary and incorrect. There are several other problems with the 4.2bsd tftp as distributed, including: 1) No support for netascii mode. 2) Relies on signals breaking through read() calls; this no longer happens in 4.2 (instead the read() call is restarted after a signal). 3) Uses the same buffer for transmit and receive, thereby clobbering the packet to be retransmitted if an old packet arrives. 4) Several other problems in the retransmit code. I believe that the PC/IP people at MIT are shipping a completely new tftp implementation for 4.2bsd as part of their PC/IP package. I suggest contacting John Romkey at MIT (romkey@mit-borax.mit.edu, I think) for further information. -Larry Allen Apollo Computer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510150105.AA03013%40BORAX.MIT.EDU] <1985101417053600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: romkey@MIT-BORAX.ARPA (John Romkey) Newsgroups: fa.tcp-ip Subject: new 4.2 tftp daemon Message-ID: <8510150105.AA03013@BORAX.MIT.EDU> Date: Mon, 14-Oct-85 21:05:36 EDT Article-I.D.: BORAX.8510150105.AA03013 Posted: Mon Oct 14 21:05:36 1985 Date-Received: Wed, 16-Oct-85 04:28:55 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 14 As Larry Allen mentioned in his message about TFTP retransmissions, we do have a completely new tftp for 4.2 and we'll be shipping it with the next PC/IP release (I'll send in a note about that when it's ready). BTW, Larry wrote/ported this TFTP. The TFTP implementation is also available via anonymous ftp from borax.mit.edu:/pub/tftp.tar. This TFTP doesn't have any of the problems that Larry mentioned in his message. There are a couple of potential drawbacks: we've only run the server under Berkeley's inetd; I don't know if it works without it. The TFTP user also doesn't have the FTP-like interface Berkeley did for their TFTP user. - John Romkey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101506260000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 15 Oct 85 13:42:04-PDT Date: 15 Oct 85 13:26:00 PDT From: Subject: IBM TCP/IP survey To: "tcp-ip" Reply-To: From: SAGE::PRODMKT 15-OCT-1985 13:25 To: PRODMKT Subj: IBM survey The following questionaire solicits responses regarding current and planned useage of IBM mainframes and associated equipment at sites with concurrent requirement for TCP/IP protocols. This information will be used for product planning purposes here at A.C.C. Any one wishing a compilation of the responses should request them from me. If there is a large demand for same, I will post the compilation directly to the net. Please respond directly to me here at A.C.C. Thanks in advance, Mike Kane (PRODMKT@acc.arpa) By the way, include all plug compatible equipment as appropriate, also. 1. How many IBM mainframes at your site? 2. How many 4300's? 3. What is the primary operating system? If you run VM, what guest OS's do you run in addition? 4. What is the primary application(s)? (TSO,CICS,IMS,etc) 5. Does your site support or have planned an SNA network? 6. Does your site have a BSC network? 7. Is there a requirement for interfacing non-IBM, ascii hosts to existing IBM net's? 8. If you are already doing #7, what solution did you use? 9. Do you currently have TCP/IP running in an IBM environment? 10. Do you plan on having TCP/IP in an IBM environment? 11. Which in your IBM requirement set is more pressing; ARPA style attachments, or Ethernet attachments? 12. In the case of both attachments mentioned in #11, is there a further requirement of maintaining SNA network integrity/transparency? 13. Any comments? 14. Any suggestions regarding further questions? ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510152228.AA06732%40UCB-VAX] <1985101512260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: prodmkt@ACC.ARPA Newsgroups: fa.tcp-ip Subject: IBM TCP/IP survey Message-ID: <8510152228.AA06732@UCB-VAX> Date: Tue, 15-Oct-85 16:26:00 EDT Article-I.D.: UCB-VAX.8510152228.AA06732 Posted: Tue Oct 15 16:26:00 1985 Date-Received: Thu, 17-Oct-85 00:25:15 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 72 From: SAGE::PRODMKT 15-OCT-1985 13:25 To: PRODMKT Subj: IBM survey The following questionaire solicits responses regarding current and planned useage of IBM mainframes and associated equipment at sites with concurrent requirement for TCP/IP protocols. This information will be used for product planning purposes here at A.C.C. Any one wishing a compilation of the responses should request them from me. If there is a large demand for same, I will post the compilation directly to the net. Please respond directly to me here at A.C.C. Thanks in advance, Mike Kane (PRODMKT@acc.arpa) By the way, include all plug compatible equipment as appropriate, also. 1. How many IBM mainframes at your site? 2. How many 4300's? 3. What is the primary operating system? If you run VM, what guest OS's do you run in addition? 4. What is the primary application(s)? (TSO,CICS,IMS,etc) 5. Does your site support or have planned an SNA network? 6. Does your site have a BSC network? 7. Is there a requirement for interfacing non-IBM, ascii hosts to existing IBM net's? 8. If you are already doing #7, what solution did you use? 9. Do you currently have TCP/IP running in an IBM environment? 10. Do you plan on having TCP/IP in an IBM environment? 11. Which in your IBM requirement set is more pressing; ARPA style attachments, or Ethernet attachments? 12. In the case of both attachments mentioned in #11, is there a further requirement of maintaining SNA network integrity/transparency? 13. Any comments? 14. Any suggestions regarding further questions? ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510160617.AA15722%40UCB-VAX] <1985101515513100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: schoff@RPICS.CSNET (Martin Lee Schoffstall) Newsgroups: fa.tcp-ip Subject: SUN style RPC's Message-ID: <8510160617.AA15722@UCB-VAX> Date: Tue, 15-Oct-85 19:51:31 EDT Article-I.D.: UCB-VAX.8510160617.AA15722 Posted: Tue Oct 15 19:51:31 1985 Date-Received: Thu, 17-Oct-85 02:04:02 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 23 Here at RPI we are working on a PC version of the RPC's, I'm interested in finding out who else has a version and who is going to. I know about the following: gould,pyramid,4.2vax,sun I'd be interested in hearing about an IBM/VM RPC virtual machine that would allow me to use a 3081D or 3090/400 eventually from my installed base of PC's or any other large machine version. Of intellectual interest would be if anyone is doing this for the CRAY2, (I don't expect to cut a PO for one just yet though). marty schoffstall schoff%rpics.csnet@csnet-relay ARPA schoff@rpics CSNET seismo!rpics!schoff UUCP RPI Computer Science Department Troy, NY 12180 (518) 271-2654 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101515513101> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Oct 85 21:32:26-PDT Received: from rpics by csnet-relay.csnet id ab18498; 16 Oct 85 0:29 EDT Received: by rpics.RPI (4.30/4.7) id AA28184; Tue, 15 Oct 85 19:51:31 EDT Date: Tue, 15 Oct 85 19:51:31 EDT From: Martin Lee Schoffstall To: tcp-ip@sri-nic.arpa Subject: SUN style RPC's Here at RPI we are working on a PC version of the RPC's, I'm interested in finding out who else has a version and who is going to. I know about the following: gould,pyramid,4.2vax,sun I'd be interested in hearing about an IBM/VM RPC virtual machine that would allow me to use a 3081D or 3090/400 eventually from my installed base of PC's or any other large machine version. Of intellectual interest would be if anyone is doing this for the CRAY2, (I don't expect to cut a PO for one just yet though). marty schoffstall schoff%rpics.csnet@csnet-relay ARPA schoff@rpics CSNET seismo!rpics!schoff UUCP RPI Computer Science Department Troy, NY 12180 (518) 271-2654 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510161424.AA21780%40UCB-VAX] <1985101603210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: norm@NCSC.ARPA (Ernest Norman) Newsgroups: fa.tcp-ip Subject: Help with host addressing Message-ID: <8510161424.AA21780@UCB-VAX> Date: Wed, 16-Oct-85 07:21:00 EDT Article-I.D.: UCB-VAX.8510161424.AA21780 Posted: Wed Oct 16 07:21:00 1985 Date-Received: Thu, 17-Oct-85 23:37:20 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 17 I need some help We at NCSC 26.4.0.53 have in the past depended upon the NAVY LABRATORY COMPUTER NETWORK (NALCON) Program Office for updates to software. Recently NALCON announced that they would no longer supply programming support It appears now that NCSC is getting further from the rest of the world in software compatibility. Specifically addressing of hosts when using electronic mail has become a problem. Most sites are now using addressing with some form of dot net (for example NCSC.ARPA). We do not (ex NCSC). I need to know how to get updated software to handle this addressing extension. Currently NCSC is using 4.1bsd UNIX on a VAX 11/750. Where do I get the updates for our software? NORM. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101603210001> Mail-From: VIVIAN created at 16-Oct-85 05:47:25 Return-Path: Received: from ncsc by SRI-NIC.ARPA with TCP; Wed 16 Oct 85 05:29:11-PDT Date: 16 Oct 85 07:21 EDT From: Ernest Norman Subject: Help with host addressing To: TCP-IP-REQUEST@SRI-NIC cc: norm@ncsc ReSent-Date: Wed 16 Oct 85 05:46:19-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12151562480.16.VIVIAN@SRI-NIC.ARPA> I need some help We at NCSC 26.4.0.53 have in the past depended upon the NAVY LABRATORY COMPUTER NETWORK (NALCON) Program Office for updates to software. Recently NALCON announced that they would no longer supply programming support It appears now that NCSC is getting further from the rest of the world in software compatibility. Specifically addressing of hosts when using electronic mail has become a problem. Most sites are now using addressing with some form of dot net (for example NCSC.ARPA). We do not (ex NCSC). I need to know how to get updated software to handle this addressing extension. Currently NCSC is using 4.1bsd UNIX on a VAX 11/750. Where do I get the updates for our software? NORM. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851016152720.836018%40CISL-SERVICE-MULTICS.ARPA] <1985101607270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: Mills@CISL-SERVICE-MULTICS.ARPA Newsgroups: fa.tcp-ip Subject: French ARPANET connections? Message-ID: <851016152720.836018@CISL-SERVICE-MULTICS.ARPA> Date: Wed, 16-Oct-85 11:27:00 EDT Article-I.D.: CISL-SER.851016152720.836018 Posted: Wed Oct 16 11:27:00 1985 Date-Received: Fri, 18-Oct-85 00:16:09 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 7 A number of researchers at French universities are planning on setting up a network between themselves. They are also interested in connecting to the ARPANET. Does the net extend to Europe? Who is a good person for them to contact about geting a sponsor and/or general approval to be on the net? John Mills ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510180836.AA04611%40UCB-VAX] <1985101613543000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: MILLS@USC-ISID.ARPA Newsgroups: fa.tcp-ip Subject: Re: French ARPANET connections? Message-ID: <8510180836.AA04611@UCB-VAX> Date: Wed, 16-Oct-85 17:54:30 EDT Article-I.D.: UCB-VAX.8510180836.AA04611 Posted: Wed Oct 16 17:54:30 1985 Date-Received: Sat, 19-Oct-85 04:12:57 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 9 In response to the message sent Wed, 16 Oct 85 11:27 EDT from Mills@CISL-SERVICE-MULTICS.ARPA John, You might bring the issue up with Dennis Jennings at the NSF Office of Advanced Scientific Computing. These gents might be ripe for NSFNET. Dave (no relation) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [376.498353365%40uci.edu] <1985101615292500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: raj@UCI-ICSA.ARPA (Richard Johnson) Newsgroups: fa.tcp-ip Subject: Ethernet problems Message-ID: <376.498353365@uci.edu> Date: Wed, 16-Oct-85 19:29:25 EDT Article-I.D.: uci.376.498353365 Posted: Wed Oct 16 19:29:25 1985 Date-Received: Sat, 19-Oct-85 04:14:25 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 38 I'm not sure if this is the correct Bboard for this. If not, please let me know where it should be sent. We have an ethernet which consists of 5 VAX 750s plugged into a DEC Delni. This is connected onto a length of cable which has 4 other Int. Sol. machines and 2 suns. We just recently ran about 500 ft. of cable (which together with the already existing cable placed us around 300 meters or so) and moved 2 of the Int. Sol. machines to the end of this length. (All systems are running 4.2BSD [Suns run SUN's version]) Basically our configuration looks like this: A B C +-- added length --+ \ | / V V delni ----------Sun--Sun--IS--IS--------------IS--IS / | \ (x) (y) D E IS About a week or so after this change was made we started having problems. About every 2-4 weeks suddenly every machine on the net claims that every other machine is down. You can't connect to any other machines. I have found that if I disconnect the extra length (recently added) the problem seems to go away. It would seem to not be a bad ethernet board in one of the machines because I can connect either one of the 2 IS's ('x' or 'y') onto the net by itself and the net is still upset. However, I can reconnect the extra length (along with the 2 machines at the end of it) after about 15-30 min's and everything is fine for another few weeks. Sometimes the problem seems to just goes away on its own also! (By the way, a "netstat -i" says we are sending and receiving lots of packets but getting about as many input errors as input packets!) Has anyone ever seen anything like this? I'm guessing it means we're too close to the max. length for the ethernet, but I calculate the total length as around 300 meters and the standard say 500 meters. ------------------------------------------------------------------------ Richard Johnson raj@uci.edu (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101702372300> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 02:28:40-PDT Date: 17 Oct 1985 07:37:23 CDT Subject: excelan boards From: DDN-REQT@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA cc: DDN-REQT@GUNTER-ADAM.ARPA Can anybody tell me if you can order the TCP/IP board with X.25 instead of the ethernet interface. I'd also like some info on the capabilities of the product, or rather the flexibility. Can you do source routing and set IP options? How many connections can the TCP support? etc,etc Getting some documentation on the products would be nice! Darrel B. DDN-REQT@GUNTER-ADAM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510180949.AA05257%40UCB-VAX] <1985101704372300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: DDN-REQT@GUNTER-ADAM.ARPA Newsgroups: fa.tcp-ip Subject: excelan boards Message-ID: <8510180949.AA05257@UCB-VAX> Date: Thu, 17-Oct-85 08:37:23 EDT Article-I.D.: UCB-VAX.8510180949.AA05257 Posted: Thu Oct 17 08:37:23 1985 Date-Received: Sat, 19-Oct-85 04:14:40 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 12 Can anybody tell me if you can order the TCP/IP board with X.25 instead of the ethernet interface. I'd also like some info on the capabilities of the product, or rather the flexibility. Can you do source routing and set IP options? How many connections can the TCP support? etc,etc Getting some documentation on the products would be nice! Darrel B. DDN-REQT@GUNTER-ADAM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101705240000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 01:33:29-PDT Date: 17 Oct 85 12:24:00 PDT From: Subject: Request for TCP/IP test program To: "tcp-ip" Reply-To: Before we reinvent another wheel, I'll try the network... On BSD 4.2 we have been using FTP (in binary mode) to obtain TCP/IP performance numbers for traffic through various network configurations. These figures can be (and have been seen to be) impacted by internal FTP overhead and especially disk I/O bandwidth. What I want is one program which opens a TCP connection and sends blocks of data (data source) and another program which accepts a TCP connection and discards the data (data sink). The internet address, block size and block count should be program arguments. Both source and sink programs should calculate and display throughput statistics. These should be as simple as possible to minimize CPU loading. If anyone has anything like this or could be used as a starting point I would appreciate a copy. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510180856.AA04846%40UCB-VAX] <1985101706474800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: lbyers%xls-plexus01.amc@AMC-HQ.ARPA (Lynn) Newsgroups: fa.tcp-ip Subject: Deletion Message-ID: <8510180856.AA04846@UCB-VAX> Date: Thu, 17-Oct-85 10:47:48 EDT Article-I.D.: UCB-VAX.8510180856.AA04846 Posted: Thu Oct 17 10:47:48 1985 Date-Received: Sat, 19-Oct-85 04:13:52 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 3 Please delete from the tcp-ip mailing list. Thanks....Lynn ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101706474801> Received: from AMC-HQ by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 01:27:05-PDT Received: by AMC-HQ via hq1; 17 Oct 85 11:17 EDT Date: 17 Oct 85 10:47:48-EDT (Thu) From: Lynn To: tcp-ip%sri-nic.arpa@AMC-HQ.ARPA Subject: Deletion Via: xls-plexus01; 17 Oct 85 11:05-EDT Please delete from the tcp-ip mailing list. Thanks....Lynn ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510180844.AA04683%40UCB-VAX] <1985101707581800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: marwaha@LOUIE.UDEL.EDU Newsgroups: fa.tcp-ip Subject: info on commercially available LANs Message-ID: <8510180844.AA04683@UCB-VAX> Date: Thu, 17-Oct-85 11:58:18 EDT Article-I.D.: UCB-VAX.8510180844.AA04683 Posted: Thu Oct 17 11:58:18 1985 Date-Received: Sat, 19-Oct-85 04:13:18 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 14 I am looking for information about commercially available LAN products. This is for a survey report on commercially available LAN systems and how they map onto the various network standards proposed by the various committees. If any body has any pointers to manufacturers/developers of LAN products or knows where I can get such information (e.g. a LAN manufacturers directory) I would be happy to know about it. Thanx. Samar Marwaha 214 Smith Hall University of Delaware Newark DE 19716 marwaha@udel-dewey ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510180909.AA05009%40UCB-VAX] <1985101711240000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: art@ACC.ARPA Newsgroups: fa.tcp-ip Subject: Request for TCP/IP test program Message-ID: <8510180909.AA05009@UCB-VAX> Date: Thu, 17-Oct-85 15:24:00 EDT Article-I.D.: UCB-VAX.8510180909.AA05009 Posted: Thu Oct 17 15:24:00 1985 Date-Received: Sat, 19-Oct-85 04:14:10 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 20 Before we reinvent another wheel, I'll try the network... On BSD 4.2 we have been using FTP (in binary mode) to obtain TCP/IP performance numbers for traffic through various network configurations. These figures can be (and have been seen to be) impacted by internal FTP overhead and especially disk I/O bandwidth. What I want is one program which opens a TCP connection and sends blocks of data (data source) and another program which accepts a TCP connection and discards the data (data sink). The internet address, block size and block count should be program arguments. Both source and sink programs should calculate and display throughput statistics. These should be as simple as possible to minimize CPU loading. If anyone has anything like this or could be used as a starting point I would appreciate a copy. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101802460000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 10:09:09-PDT Date: 18 Oct 85 09:46:00 PDT From: Subject: RE: Ethernet problem To: "tcp-ip" Reply-To: > > About a week or so after this change was made we started having > problems. About every 2-4 weeks suddenly every machine on the net > claims that every other machine is down. You can't connect to any > other machines. I have found that if I disconnect the extra length > (recently added) the problem seems to go away. It would seem to not > be a bad ethernet board in one of the machines because I can connect > either one of the 2 IS's ('x' or 'y') onto the net by itself and the > net is still upset. However, I can reconnect the extra length (along > with the 2 machines at the end of it) after about 15-30 min's and > everything is fine for another few weeks. Sometimes the problem > seems to just goes away on its own also! (By the way, a "netstat -i" > says we are sending and receiving lots of packets but getting about > as many input errors as input packets!) > > Has anyone ever seen anything like this? I'm guessing it means we're > too close to the max. length for the ethernet, but I calculate the > total length as around 300 meters and the standard say 500 meters. > If feasable, you might consider having someone test your cable with a Time Domain Reflectometer to make sure you don't have any significant impedance mismatches. You might also try flexing connectors, tranceiver taps and terminators with the system running to look for mechanical problems in the cable. The DELNI is (I believe) V2 Ethernet specs, so verify that the other equiptment is compatible. (V1 and 802.3 have slight differences) "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510181355.AA08278%40UCB-VAX] <1985101805423800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: MILLS@USC-ISID.ARPA Newsgroups: fa.tcp-ip Subject: Re: Request for TCP/IP test program Message-ID: <8510181355.AA08278@UCB-VAX> Date: Fri, 18-Oct-85 09:42:38 EDT Article-I.D.: UCB-VAX.8510181355.AA08278 Posted: Fri Oct 18 09:42:38 1985 Date-Received: Sat, 19-Oct-85 04:17:10 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 12 In response to the message sent 17 Oct 85 12:24:00 PDT from Art, I suggest you contact Ed Cain (cain@edn-unix.arpa), chairman of the Testing Task Force. He may either ping the members or point you to the Protocol Testing Laboratory at DCEC or both. Many old grizzlies, myself included have well-worn TCP testing machinery, but it is not the kind you simply drop into 4.2 and turn the key. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101806410000> Received: from isi-vaxa.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 13:42:29-PDT Received: by isi-vaxa.ARPA (4.12/4.7) id AA05619; Fri, 18 Oct 85 13:41:53 pdt From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) Message-Id: <8510182041.AA05619@isi-vaxa.ARPA> Date: 18 Oct 1985 1341-PDT (Friday) To: DDN-REQT@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: excelan boards In-Reply-To: Your message of 17 Oct 1985 07:37:23 CDT. <8510181210.AA29671@isi-vaxa.ARPA> One note, if you are 4.2BSD, you may be out of luck. Last I heard, the EXOS series would not support smart operation under 4.2BSD, and EXCELAN was not planning to change things. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510181836.AA12925%40UCB-VAX] <1985101808460000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: art@ACC.ARPA Newsgroups: fa.tcp-ip Subject: RE: Ethernet problem Message-ID: <8510181836.AA12925@UCB-VAX> Date: Fri, 18-Oct-85 12:46:00 EDT Article-I.D.: UCB-VAX.8510181836.AA12925 Posted: Fri Oct 18 12:46:00 1985 Date-Received: Mon, 21-Oct-85 03:36:37 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 30 > > About a week or so after this change was made we started having > problems. About every 2-4 weeks suddenly every machine on the net > claims that every other machine is down. You can't connect to any > other machines. I have found that if I disconnect the extra length > (recently added) the problem seems to go away. It would seem to not > be a bad ethernet board in one of the machines because I can connect > either one of the 2 IS's ('x' or 'y') onto the net by itself and the > net is still upset. However, I can reconnect the extra length (along > with the 2 machines at the end of it) after about 15-30 min's and > everything is fine for another few weeks. Sometimes the problem > seems to just goes away on its own also! (By the way, a "netstat -i" > says we are sending and receiving lots of packets but getting about > as many input errors as input packets!) > > Has anyone ever seen anything like this? I'm guessing it means we're > too close to the max. length for the ethernet, but I calculate the > total length as around 300 meters and the standard say 500 meters. > If feasable, you might consider having someone test your cable with a Time Domain Reflectometer to make sure you don't have any significant impedance mismatches. You might also try flexing connectors, tranceiver taps and terminators with the system running to look for mechanical problems in the cable. The DELNI is (I believe) V2 Ethernet specs, so verify that the other equiptment is compatible. (V1 and 802.3 have slight differences) "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510181731.AA11422%40UCB-VAX] <1985101808565200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: clements@BBNCCQ.ARPA (Bob Clements) Newsgroups: fa.tcp-ip Subject: Re: Request for TCP/IP test program Message-ID: <8510181731.AA11422@UCB-VAX> Date: Fri, 18-Oct-85 12:56:52 EDT Article-I.D.: UCB-VAX.8510181731.AA11422 Posted: Fri Oct 18 12:56:52 1985 Date-Received: Sun, 20-Oct-85 04:27:35 EDT Sender: leo@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 19 [Art @ ACC.ARPA asked about date source/sink programs that avoid the overhead of using the disk for the data.] Art, The original TENEX/TOPS20 FTP server, which I wrote many years ago, had a "feature" to do exactly what you are looking for: It recognized the "NUL:" device as a special case. Data sent to NUL: was discarded immediately by the FTP server, without even calling the file system to discard it. Data requested FROM the NUL: device was generated by the FTP server itself, and it sent a fixed amount, one megabyte or one megabit, I think. Sadly, I have been exiled from 36-bit land for a while, so I don't know whether that feature is still in the current server. I hope so. /Rcc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101808565201> Received: from bbnccq by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 10:05:17-PDT Date: Fri, 18 Oct 85 12:56:52 EDT From: Bob Clements Subject: Re: Request for TCP/IP test program In-Reply-To: Your message of 17 Oct 85 12:24:00 PDT To: Cc: tcp-ip@sri-nic.arpa, clements@bbnccq.arpa [Art @ ACC.ARPA asked about date source/sink programs that avoid the overhead of using the disk for the data.] Art, The original TENEX/TOPS20 FTP server, which I wrote many years ago, had a "feature" to do exactly what you are looking for: It recognized the "NUL:" device as a special case. Data sent to NUL: was discarded immediately by the FTP server, without even calling the file system to discard it. Data requested FROM the NUL: device was generated by the FTP server itself, and it sent a fixed amount, one megabyte or one megabit, I think. Sadly, I have been exiled from 36-bit land for a while, so I don't know whether that feature is still in the current server. I hope so. /Rcc ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510181754.AA06300%40pacific.ARPA] <1985101809540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: stanonik@NPRDC.ARPA (Ron Stanonik) Newsgroups: fa.tcp-ip Subject: Re: 4.2BSD tftp doesn't retransmit acks Message-ID: <8510181754.AA06300@pacific.ARPA> Date: Fri, 18-Oct-85 13:54:00 EDT Article-I.D.: pacific.8510181754.AA06300 Posted: Fri Oct 18 13:54:00 1985 Date-Received: Sat, 19-Oct-85 04:19:17 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 23 Thanks. You refer to a "current tftp spec" which says "Acks are retransmitted ONLY when the retransmit timer expires". The most recent tftp spec I'm aware of is rfc783 which says "If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgement)". Is there some later tftp spec? Where? Also, the problem we encountered was that 4.2bsd tftp never retransmitted the ack. It didn't retransmit in response to repeated data packets, and it didn't timeout because the data packets reset the timer. Given that "acks are only retransmitted when the timer expires", I can see the problem appears to be an incorrectly reset timer. Yep, we're bagging 4.2bsd's tftp, mostly. A couple of pc's here are still running a version of tftp assuming 4.2bsd's damaged netascii. Thanks again, Ron stanonik@nprdc.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510181837.AA03793%40isi-vaxa.ARPA] <1985101810370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro") Newsgroups: fa.tcp-ip Subject: Re: info on commercially available LANs Message-ID: <8510181837.AA03793@isi-vaxa.ARPA> Date: Fri, 18-Oct-85 14:37:00 EDT Article-I.D.: isi-vaxa.8510181837.AA03793 Posted: Fri Oct 18 14:37:00 1985 Date-Received: Sun, 20-Oct-85 06:10:49 EDT References: <8510180914.AA28229@isi-vaxa.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 17 BRIDGE COMMUNICATIONS has a rather extensive set of turnkey/programmable systems. You can find them at: 1345 Shorebird Way Mountain View, CA. 94043 (415)-969-4400 You might ask for Judith Estrin. She is VP of Engineering. She can point you to the appropriate people. A project that I worked on had a good experience with the products and the company. A good marketing contact is Nancy Collins, (714)-476-8844. She was our sales rep. I don't know if she would cover your area. If you call, tell Judith or Nancy that Jeff Cavallaro (formally of TRW) sent you! Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101810431200> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 17:55:23-PDT Date: 18 Oct 1985 17:43:12 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: TCP test programs To: tcp-ip@SRI-NIC.ARPA cc: art@ACC.ARPA Art: You might try the Echo Server (port 7) [RFC 862], the Discard Server (port 9) [RFC 862], and the Character Generator Server (port 19) [RFC 864]. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101811190000> Received: from C.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 12:19:56-PDT Received: ID ; Fri 18 Oct 85 15:19:03-EDT Date: Fri 18 Oct 85 15:19:00-EDT From: Vince.Fuller@C.CS.CMU.EDU Subject: Re: Request for TCP/IP test program To: clements@BBNCCQ.ARPA cc: art@ACC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Bob Clements " of Fri 18 Oct 85 14:26:20-EDT As an unofficial maintainer of a TOPS-20 FTP server, I can say that it still contains code for supporting transfers to and from the NUL: device. --Vince ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985101814382600> Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 15:46:10-PDT Received: from Aurora.ms by ArpaGateway.ms ; 18 OCT 85 15:38:23 PDT From: DonWinter.pasa@Xerox.ARPA Date: 18 Oct 85 18:38:26 EDT Subject: Re: Ethernet problems In-reply-to: raj@UCI.EDU's message of 16 Oct 85 16:29:25 PDT (Wed), <376.498353365@uci.edu> To: Richard Johnson cc: tcp-ip@sri-nic.arpa Message-ID: <851018-153823-1709@Xerox> I have had a problem very similar to this involving an ad hoc Ethernet extension here at Xerox in Pasadena. The problem involved a TRANSCEIVER which was (a) located within minimum distance of the extra piece of net, and (b) "shorted" out its connection for the first twenty minutes or so aftr being turned on. The problem was thus transient for 20 minutes every morning. We tracked it down, because the particular user was not an early riser, and because the ad hoc piece of net was designed for a team project working in a bull-pen environment. Luckily, we also had a network "guru" on the team in that room. We used to joke about the net taking its morning break when this one user arrived, but paid no further attention until he didn't turn on his machine for quite some time after arriving, and the problem occured then. No amount of testing from Network Support showed anything, because the transceiver was always warm then. Our team did a test during the 20 minutes, and proved that the problem moved with the transceiver. Replacement of that transceiver made every user in the building eternaly grateful to the unknown team who had fixed the net's morning break. This may not be germane to your problem, but every little bit if information helps whenn obscure problems arise. Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510190113.AA21478%40UCB-VAX] <1985101816431200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: POSTEL@USC-ISIB.ARPA Newsgroups: fa.tcp-ip Subject: re: TCP test programs Message-ID: <8510190113.AA21478@UCB-VAX> Date: Fri, 18-Oct-85 20:43:12 EDT Article-I.D.: UCB-VAX.8510190113.AA21478 Posted: Fri Oct 18 20:43:12 1985 Date-Received: Sun, 20-Oct-85 04:26:47 EDT Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 9 Art: You might try the Echo Server (port 7) [RFC 862], the Discard Server (port 9) [RFC 862], and the Character Generator Server (port 19) [RFC 864]. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510191640.AA12963%40calma.UUCP] <1985101908403700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: radzy@calma.UUCP Newsgroups: fa.tcp-ip Subject: Re: Ethernet problems Message-ID: <8510191640.AA12963@calma.UUCP> Date: Sat, 19-Oct-85 12:40:37 EDT Article-I.D.: calma.8510191640.AA12963 Posted: Sat Oct 19 12:40:37 1985 Date-Received: Sun, 20-Oct-85 06:10:32 EDT References: <376.498353365@uci.edu> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 63 In article <376.498353365@uci.edu> you write: >I'm not sure if this is the correct Bboard for this. If not, >please let me know where it should be sent. I would have sent it to net.lan, but I don't think net.tcp-ip is INappropriate for it. Ignore any flames. > We just recently ran about 500 ft. of >cable (which together with the already existing cable placed us >around 300 meters or so) > >About a week or so after this change was made we started having >problems. About every 2-4 weeks suddenly every machine on the net >claims that every other machine is down. > I have found that if I disconnect the extra length >(recently added) the problem seems to go away. > However, I can reconnect the extra length (along >with the 2 machines at the end of it) after about 15-30 min's and >everything is fine for another few weeks. > >Has anyone ever seen anything like this? I'm guessing it means we're >too close to the max. length for the ethernet, but I calculate the >total length as around 300 meters and the standard say 500 meters. I doubt the problem is with length. The ethernet specification says 2.5 kilometers, not 500 meters (unless you're using experimental ether, in which case it's still 1 kilometer). I had problems something like that a while back. The symptoms were that the network was (always) slow, and there were lots of illegal packets. Often, you couldn't get connected, same as your net now, but it wasn't periodic, like you're seeing. The problem turned out to be a combination of two things, neither of which is quite kosher, but neither of which (alone) would cause the net to behave quite so lousy: 1. I had added a few sections of the thin cable to one end of the net, for IBM PCs to use with their internal transceivers. The thin cable has a differet impedance than the thick cable. 2. Several of out transceivers were not placed at correct locations. The result of this was that the machines connected to those transceivers were much worse about problems. Could something like either of those problems be related to yours? For the first, check if you have a bad connector (or transceiver, if you are using 3-com type). Also, make sure the cable is top quality (I'm not sure of the nomenclature here, but there are a couple of kinds and one kind costs about 1/2 what the other kind costs -- get the expensive one). For the second, make sure your cable has the marks at about 9-foot intervals, and make sure all your transceivers are on one of the marks. Hope this helps. -- Tim (radzy) Radzykewycz calma!radzy@ucbvax.ARPA ucbvax!calma!radzy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12152471809.5.HEDRICK%40RED.RUTGERS.EDU] <1985101916012500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) Newsgroups: fa.tcp-ip Subject: Re: Ethernet problems Message-ID: <12152471809.5.HEDRICK@RED.RUTGERS.EDU> Date: Sat, 19-Oct-85 20:01:25 EDT Article-I.D.: RED.12152471809.5.HEDRICK Posted: Sat Oct 19 20:01:25 1985 Date-Received: Sun, 20-Oct-85 06:43:09 EDT References: <8510191640.AA12963@calma.UUCP> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 13 As I read it, the spec says 500 meters. 2.5 Km is for configurations involving multiple bridges, and also a 1 Km length of fiber optic cable. If it really takes you 15 - 30 min to recover once you remove the extra length, this suggests that the problem involves software tables. This is about the amount of time it takes Unix systems to clear their ARP tables. I would look carefully at the two machines on the end of the extra cable. Is it possible that they are set up with wrong network configuration information, such that somehow duplicate addresses or forwarding loops are resulting? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510200012.AA18759%40isi-vaxa.ARPA] <1985101916120000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro") Newsgroups: fa.tcp-ip Subject: Re: info on commercially available LANs Message-ID: <8510200012.AA18759@isi-vaxa.ARPA> Date: Sat, 19-Oct-85 20:12:00 EDT Article-I.D.: isi-vaxa.8510200012.AA18759 Posted: Sat Oct 19 20:12:00 1985 Date-Received: Sun, 20-Oct-85 06:43:38 EDT References: <8510181837.AA03793@isi-vaxa.ARPA> Sender: daemon@ucbvax.ARPA Reply-To: tcp-ip@ucb-vax.arpa Organization: The ARPA Internet Lines: 5 Sorry that this message went to the whole group. I guess I didn't fool our automated mail composition SW very well. Sorry for the advertisement overtones. It was not meant to be one. Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510201238.AA18373%40mcvax.UUCP] <1985102004425500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: dpk@mcvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP test programs Message-ID: <8510201238.AA18373@mcvax.UUCP> Date: Sun, 20-Oct-85 08:42:55 EDT Article-I.D.: mcvax.8510201238.AA18373 Posted: Sun Oct 20 08:42:55 1985 Date-Received: Sun, 20-Oct-85 17:30:38 EDT Sender: daemon@ucbvax.ARPA Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@ucb-vax.arpa I believe there are two different implementations of the "little services" (source, sink, echo, & others) for UNIX (4.2BSD). I think one of them was done by Chris Kent at Purdue (cak@purdue). -Doug- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510211820.AA22843%40merlin.Purdue.EDU] <1985102110201700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: cak@PURDUE.EDU ("Christopher A. Kent") Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP test programs Message-ID: <8510211820.AA22843@merlin.Purdue.EDU> Date: Mon, 21-Oct-85 14:20:17 EDT Article-I.D.: merlin.8510211820.AA22843 Posted: Mon Oct 21 14:20:17 1985 Date-Received: Tue, 22-Oct-85 01:20:14 EDT References: <8510201238.AA18373@mcvax.UUCP> Sender: usenet@ucbvax.ARPA Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@ucb-vax.arpa Nope, I didn't do any little services, just finger. We use a program called inetd (not like SUN's inetd) from Marshall Rose. chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102112060000> Received: from PS1.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Mon 21 Oct 85 14:25:37-PDT Date: 21 Oct 1985 1706-EST From: Dale Moore To: TCP-IP@NIC Reply-To: MOORE@PS1.CS.CMU.EDU I was looking into commercially available IP/TCP products for VMS. Below is an excerpt of one candidates "IP/TCP Primer". INTERNET address are defined as having 4-tuples (or parts), [a.b.c.d]. The first address, a, stands for the actual network where your host is located. For example, there could be a network coded as "128", supporting some number of ARPANET host systems. The second field, b, is the subnet of your host system. For the purposes of this example, b would be equal to "30". Each network, therefore, is divided into subnets. As each network receives a packet, it checks to see which subnet the data is for and routes it accordingly. Address field c is the local network number of your network. So, each sub-network is divided into another group of computer systems that are configured in a local network arrangement. In the example, c is equal to "5". . . . . . Using the numbers assigned above, if someone on the INTERNET sent data to a system address of [128.2.5.3], The data would be delivered to system 3 on local network 5 on the subnetwork 30 lying on network 128. Once you system has a unique address, testing the IP/TCP implementation can be accomplished with any (or all) of the approximately 500 hosts on the INTERNET. The above is copied verbatim from their primer (The IP/TCP Primer October 1984 V1.14). Given that the above is full of lies and misinformation, I won't tell you the name of the company. But their initials are TWG, and it is the only IP/TCP code sold by DEC for VMS. Would you by networking software from these folks? ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510212150.AA14371%40UCB-VAX] <1985102114060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: MOORE@PS1.CS.CMU.EDU (Dale Moore) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8510212150.AA14371@UCB-VAX> Date: Mon, 21-Oct-85 18:06:00 EDT Article-I.D.: UCB-VAX.8510212150.AA14371 Posted: Mon Oct 21 18:06:00 1985 Date-Received: Tue, 22-Oct-85 01:18:58 EDT Sender: daemon@ucbvax.ARPA Reply-To: MOORE@PS1.CS.CMU.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@ucb-vax.arpa I was looking into commercially available IP/TCP products for VMS. Below is an excerpt of one candidates "IP/TCP Primer". INTERNET address are defined as having 4-tuples (or parts), [a.b.c.d]. The first address, a, stands for the actual network where your host is located. For example, there could be a network coded as "128", supporting some number of ARPANET host systems. The second field, b, is the subnet of your host system. For the purposes of this example, b would be equal to "30". Each network, therefore, is divided into subnets. As each network receives a packet, it checks to see which subnet the data is for and routes it accordingly. Address field c is the local network number of your network. So, each sub-network is divided into another group of computer systems that are configured in a local network arrangement. In the example, c is equal to "5". . . . . . Using the numbers assigned above, if someone on the INTERNET sent data to a system address of [128.2.5.3], The data would be delivered to system 3 on local network 5 on the subnetwork 30 lying on network 128. Once you system has a unique address, testing the IP/TCP implementation can be accomplished with any (or all) of the approximately 500 hosts on the INTERNET. The above is copied verbatim from their primer (The IP/TCP Primer October 1984 V1.14). Given that the above is full of lies and misinformation, I won't tell you the name of the company. But their initials are TWG, and it is the only IP/TCP code sold by DEC for VMS. Would you by networking software from these folks? ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102114370000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 21 Oct 85 21:53:56-PDT Date: 21 Oct 85 21:37:00 PDT From: Subject: Thanks for responses To: "tcp-ip" cc: unix-wizards@brl Reply-To: This is a note of thanks to all who responded to my query for TCP/IP test programs for 4.2 UNIX. The response reconfirms my view that the network is an extremely valuable resource for information sharing. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510220501.AA23193%40UCB-VAX] <1985102120370000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Thanks for responses Message-ID: <8510220501.AA23193@UCB-VAX> Date: Tue, 22-Oct-85 00:37:00 EDT Article-I.D.: UCB-VAX.8510220501.AA23193 Posted: Tue Oct 22 00:37:00 1985 Date-Received: Tue, 22-Oct-85 08:17:59 EDT Sender: daemon@ucbvax.ARPA Reply-To: Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@ucb-vax.arpa This is a note of thanks to all who responded to my query for TCP/IP test programs for 4.2 UNIX. The response reconfirms my view that the network is an extremely valuable resource for information sharing. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851022144712.014127%40CISL-SERVICE-MULTICS.ARPA] <1985102206470000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Mills@CISL-SERVICE-MULTICS.ARPA Newsgroups: mod.protocols.tcp-ip Subject: French ARPANET connections Message-ID: <851022144712.014127@CISL-SERVICE-MULTICS.ARPA> Date: Tue, 22-Oct-85 10:47:00 EDT Article-I.D.: CISL-SER.851022144712.014127 Posted: Tue Oct 22 10:47:00 1985 Date-Received: Wed, 23-Oct-85 13:29:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@ucb-vax.arpa Thanks to everyone who responded to my earlier request. The number of replies and the quality of the information was very impressive. John Mills ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510230413.AA04085%40UCB-VAX] <1985102220035900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: IP, ICMP, TCP, and UDP checksumming. Message-ID: <8510230413.AA04085@UCB-VAX> Date: Wed, 23-Oct-85 00:03:59 EDT Article-I.D.: UCB-VAX.8510230413.AA04085 Posted: Wed Oct 23 00:03:59 1985 Date-Received: Wed, 23-Oct-85 13:27:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@ucb-vax.arpa This has come up before, but I don't know if we came up with an answer. When doing the complement of the ones complement sum, do you fix negative zero to be zero; pick one: never, after the sum and before the complement, after the complement. The obvious solution is to never normalize the value you insert in the header but always check for a comparison of 0 equals -0 when doing verification. Or, do we want to get more rigorous. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102220035901> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Oct 85 21:04:10-PDT Date: Wed, 23 Oct 85 0:03:59 EDT From: Ron Natalie To: tcp-ip@SRI-NIC.ARPA Subject: IP, ICMP, TCP, and UDP checksumming. This has come up before, but I don't know if we came up with an answer. When doing the complement of the ones complement sum, do you fix negative zero to be zero; pick one: never, after the sum and before the complement, after the complement. The obvious solution is to never normalize the value you insert in the header but always check for a comparison of 0 equals -0 when doing verification. Or, do we want to get more rigorous. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102311390000> Received: from su-pescadero.arpa by SRI-NIC.ARPA with TCP; Wed 23 Oct 85 18:40:44-PDT Received: by su-pescadero.arpa with Sendmail; Wed, 23 Oct 85 18:39:46 pdt Date: 23 Oct 1985 1839-PDT (Wednesday) From: Tim Mann To: Jonathan Dreyer Cc: tcp-ip@sri-nic Subject: Re: IP, ICMP, TCP, and UDP checksumming. In-Reply-To: Jonathan Dreyer / 23 Oct 85 19:14:00 EDT (Wed). The problem with your analysis is that it depends on a particular way of doing ones-complement arithmetic on a non-ones-complement machine. (Unsigned addition followed by end-around carry, with no normalization step.) If I have a true ones-complement machine, it would be perfectly legitimate for it to automatically normalize ~0 to +0 after every addition, in which case the property "you can never get 0 in a sum unless both addends are 0" does not hold. Also, treating ~0 and +0 as different makes it much more confusing to analyze the arithmetic, since if they are treated as identical, we have modulo (2^n) - 1 arithmetic, whose properties are well-known, but if they are treated as different, the system is not even a group. Nonetheless, I think your analysis is correct. The upshot is that IF you are checking a checksum on a twos-complement machine and doing end-around carry in software, you will never get ~0 after complementing if the checksum is correct. HOWEVER, you will not be robust, since another implementation may put +0 in the checksum field when it meant ~0, in a packet with zeroes in all other fields, in which case you WILL get ~0. (This is the only case in which you will get ~0.) This problem is a common one since it isn't absolutely clear to people who read the IP spec that "the ones complement of the ones-complement sum..." can never be +0. In fact, if one uses the above checksum-checking code to generate checksums as well, it is easy to make that mistake. This is a problem we actually ran into at Stanford a while back. In short, avoid headaches by normalizing. --Tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510232322.AA23506%40UCB-VAX] <1985102315140000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jdreyer@BBNCCV.ARPA (Jonathan Dreyer) Newsgroups: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming. Message-ID: <8510232322.AA23506@UCB-VAX> Date: Wed, 23-Oct-85 19:14:00 EDT Article-I.D.: UCB-VAX.8510232322.AA23506 Posted: Wed Oct 23 19:14:00 1985 Date-Received: Thu, 24-Oct-85 11:09:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@ucb-vax.arpa The following argument is so simple, it must be wrong. You should never have to "normalize" a ones complement checksum. In the following, by "sum" or "+" I mean the ones complement sum, by "0" I mean positive zero (all bits are zero), and by "full checksum computation" I mean the complement of the (ones complement) sum. Let S be the sum of all the words in a message except the checksum field. The checksum field of the message should thus contain ~S. The full checksum computation on the message with the checksum in place is thus ~(S + ~S). But the sum of anything and its complement is all ones (~0) so ~(S + ~S) = ~(~0) = 0. This argument is based on commutativity and associativity of the ones complement sum. I think this is a valid assumption but don't have the patience to verify it. Another way of looking at it is to note that you can never get 0 in a sum unless both addends are 0. Think of it: you can only get zero (of one flavor or other) when the addends are inverses, and the addends are inverses only when they are complements or both zero. Thus there are three ways to get a sum of some kind of zero: 0 + 0 = 0 ~0 + (+/~ 0) = ~0 (left as exercise) nonzero + ~nonzero = ~0. Thus a full checksum computation (complement of the sum) can never yield ~0, except when all the data is 0. In this special case, the checksum field should be ~0 so again the full checksum computation yields 0. Thus, in no case can the full checksum computation yield ~0. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102315140001> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Wed 23 Oct 85 16:16:09-PDT To: Ron Natalie cc: tcp-ip@sri-nic.ARPA Subject: Re: IP, ICMP, TCP, and UDP checksumming. In-reply-to: Your message of Wed, 23 Oct 85 0:03:59 EDT. Date: 23 Oct 85 19:14:00 EDT (Wed) From: Jonathan Dreyer The following argument is so simple, it must be wrong. You should never have to "normalize" a ones complement checksum. In the following, by "sum" or "+" I mean the ones complement sum, by "0" I mean positive zero (all bits are zero), and by "full checksum computation" I mean the complement of the (ones complement) sum. Let S be the sum of all the words in a message except the checksum field. The checksum field of the message should thus contain ~S. The full checksum computation on the message with the checksum in place is thus ~(S + ~S). But the sum of anything and its complement is all ones (~0) so ~(S + ~S) = ~(~0) = 0. This argument is based on commutativity and associativity of the ones complement sum. I think this is a valid assumption but don't have the patience to verify it. Another way of looking at it is to note that you can never get 0 in a sum unless both addends are 0. Think of it: you can only get zero (of one flavor or other) when the addends are inverses, and the addends are inverses only when they are complements or both zero. Thus there are three ways to get a sum of some kind of zero: 0 + 0 = 0 ~0 + (+/~ 0) = ~0 (left as exercise) nonzero + ~nonzero = ~0. Thus a full checksum computation (complement of the sum) can never yield ~0, except when all the data is 0. In this special case, the checksum field should be ~0 so again the full checksum computation yields 0. Thus, in no case can the full checksum computation yield ~0. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510240212.AA27126%40UCB-VAX] <1985102317390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mann@SU-PESCADERO.ARPA (Tim Mann) Newsgroups: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming. Message-ID: <8510240212.AA27126@UCB-VAX> Date: Wed, 23-Oct-85 21:39:00 EDT Article-I.D.: UCB-VAX.8510240212.AA27126 Posted: Wed Oct 23 21:39:00 1985 Date-Received: Thu, 24-Oct-85 11:34:25 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@ucb-vax.arpa The problem with your analysis is that it depends on a particular way of doing ones-complement arithmetic on a non-ones-complement machine. (Unsigned addition followed by end-around carry, with no normalization step.) If I have a true ones-complement machine, it would be perfectly legitimate for it to automatically normalize ~0 to +0 after every addition, in which case the property "you can never get 0 in a sum unless both addends are 0" does not hold. Also, treating ~0 and +0 as different makes it much more confusing to analyze the arithmetic, since if they are treated as identical, we have modulo (2^n) - 1 arithmetic, whose properties are well-known, but if they are treated as different, the system is not even a group. Nonetheless, I think your analysis is correct. The upshot is that IF you are checking a checksum on a twos-complement machine and doing end-around carry in software, you will never get ~0 after complementing if the checksum is correct. HOWEVER, you will not be robust, since another implementation may put +0 in the checksum field when it meant ~0, in a packet with zeroes in all other fields, in which case you WILL get ~0. (This is the only case in which you will get ~0.) This problem is a common one since it isn't absolutely clear to people who read the IP spec that "the ones complement of the ones-complement sum..." can never be +0. In fact, if one uses the above checksum-checking code to generate checksums as well, it is easy to make that mistake. This is a problem we actually ran into at Stanford a while back. In short, avoid headaches by normalizing. --Tim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [23Oct85.223317.DP0N%40A.CS.CMU.EDU] <1985102318330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: don.provan@A.CS.CMU.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming. Message-ID: <23Oct85.223317.DP0N@A.CS.CMU.EDU> Date: Wed, 23-Oct-85 22:33:00 EDT Article-I.D.: A.23Oct85.223317.DP0N Posted: Wed Oct 23 22:33:00 1985 Date-Received: Thu, 24-Oct-85 11:14:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@ucb-vax.arpa if you checksum the entire message (or header in IP), including the checksum field, you'll always get -0 regardless of what the sending entity put in the checksum field (assuming the packet isn't entirely zero, which isn't legal in IP and TCP and, i think, ICMP and UDP). if everyone used this approach (which, i believe, works just as well if the machine does your ones complement addition, although you'd check for +0 on a machine that normalized), we shouldn't have to worry about which one is "right". of course, when they change the checksum we'll all be up a creek... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510240741.AA03114%40UCB-VAX] <1985102323023400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: BRL's ROOT Domain Server Message-ID: <8510240741.AA03114@UCB-VAX> Date: Thu, 24-Oct-85 03:02:34 EDT Article-I.D.: UCB-VAX.8510240741.AA03114 Posted: Thu Oct 24 03:02:34 1985 Date-Received: Fri, 25-Oct-85 02:23:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@ucb-vax.arpa BRL's ROOT Domain Server once again seems to be well. For those hosts on the east coast, or on MILNET, you may wish to experiment with using this one. BRL-AOS.ARPA 192.5.22.82 is the place (*Not* BRL.ARPA 26.0.0.29). We were experiencing difficulty with the software, and with the root tables. Please let me know if you encounter any problems. I make no claim that things are perfect yet. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102323023401> Received: from BRL-AOS.ARPA by SRI-NIC.ARPA with TCP; Thu 24 Oct 85 00:02:17-PDT Date: Thu, 24 Oct 85 3:02:34 EDT From: Mike Muuss To: TCP-IP@sri-nic.ARPA Subject: BRL's ROOT Domain Server BRL's ROOT Domain Server once again seems to be well. For those hosts on the east coast, or on MILNET, you may wish to experiment with using this one. BRL-AOS.ARPA 192.5.22.82 is the place (*Not* BRL.ARPA 26.0.0.29). We were experiencing difficulty with the software, and with the root tables. Please let me know if you encounter any problems. I make no claim that things are perfect yet. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510240830.AA03873%40UCB-VAX] <1985102323204700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Hyperchannel problem Message-ID: <8510240830.AA03873@UCB-VAX> Date: Thu, 24-Oct-85 03:20:47 EDT Article-I.D.: UCB-VAX.8510240830.AA03873 Posted: Thu Oct 24 03:20:47 1985 Date-Received: Fri, 25-Oct-85 03:12:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@ucb-vax.arpa At BRL we operate a 3-node Hyperchannel network which has it's share of problems. One node attaches to a CDC Cyber, and the other two are A440 ("minicomputer adaptor") nodes, using the PI-13 UNIBUS interface. About once a week or so, one of the three PI-13 boards in the network will get "stuck", and powering the A440 off and on does not help, nor does performing a UNIBUS INIT. Only removing power from the PI-13 and restoring it will clear the condition. This can be a real nuisance. Also, several times a month, each Hyperchannel adaptor will signal a power-off, power-on transition which none of our PDUs claim existed. This is curious, but not particularly harmful. My question is: has anybode else on the list had similar experiences with Hyperchannel equipment, and are there known fixes? The vendor has not been very helpful trying to track this problem down. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102323204701> Received: from BRL-VGR.ARPA by SRI-NIC.ARPA with TCP; Thu 24 Oct 85 00:24:22-PDT Date: Thu, 24 Oct 85 3:20:47 EDT From: Mike Muuss To: TCP-IP@sri-nic.arpa cc: Hardware@BRL.ARPA Subject: Hyperchannel problem At BRL we operate a 3-node Hyperchannel network which has it's share of problems. One node attaches to a CDC Cyber, and the other two are A440 ("minicomputer adaptor") nodes, using the PI-13 UNIBUS interface. About once a week or so, one of the three PI-13 boards in the network will get "stuck", and powering the A440 off and on does not help, nor does performing a UNIBUS INIT. Only removing power from the PI-13 and restoring it will clear the condition. This can be a real nuisance. Also, several times a month, each Hyperchannel adaptor will signal a power-off, power-on transition which none of our PDUs claim existed. This is curious, but not particularly harmful. My question is: has anybode else on the list had similar experiences with Hyperchannel equipment, and are there known fixes? The vendor has not been very helpful trying to track this problem down. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102505410000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Fri 25 Oct 85 13:00:39-PDT Date: 25 Oct 85 12:41:00 PDT From: Subject: LH/DH-11 and IMP padding To: "tcp-ip" cc: unix-wizards@brl Reply-To: I reviewed the 1822 spec regarding IMP message lengths and relearned some interesting information. The IMP was originally designed to deal with three different machine word lengths (source machine, IMP and destination machine). This involves a padding scheme which adds padding as a message goes from src->IMP and also IMP->dst. The IMP ALWAYS appends a 1 to the message and zero pads to the end of an IMP word (16 bits). For machines with an LH/DH-11 (PDP-11 or VAX) this causes the destination host to receive 16 bits more than the original message length (plus any padding the destination host interface might have to add). The maximum message size that an IMP will send to a host is 8160 bits (1020 bytes). The BSD 4.2 driver CORRECTLY limits the messages sent to the IMP to 1018 bytes, but INCORRECTLY uses a 1018 byte buffer to receive into. If the LH/DH-11 is healthy, the driver logic does deal with this situation, but with unneccessary interrupt overhead (to start a bunch of 2 byte reads). If the LH/DH-11 occasionally drops the EOM when DMA is restarted, messages would get concatonated, with the second (or both) messages being ignored. We will attempt to cause this failure in the lab, but recommend that LH/DH-11 drivers read into at least an 1020 byte buffer. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510252014.AA04091%40ucb-vax.berkeley.edu] <1985102511410000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: LH/DH-11 and IMP padding Message-ID: <8510252014.AA04091@ucb-vax.berkeley.edu> Date: Fri, 25-Oct-85 15:41:00 EDT Article-I.D.: ucb-vax.8510252014.AA04091 Posted: Fri Oct 25 15:41:00 1985 Date-Received: Sat, 26-Oct-85 03:18:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@ucbvax.berkeley.edu I reviewed the 1822 spec regarding IMP message lengths and relearned some interesting information. The IMP was originally designed to deal with three different machine word lengths (source machine, IMP and destination machine). This involves a padding scheme which adds padding as a message goes from src->IMP and also IMP->dst. The IMP ALWAYS appends a 1 to the message and zero pads to the end of an IMP word (16 bits). For machines with an LH/DH-11 (PDP-11 or VAX) this causes the destination host to receive 16 bits more than the original message length (plus any padding the destination host interface might have to add). The maximum message size that an IMP will send to a host is 8160 bits (1020 bytes). The BSD 4.2 driver CORRECTLY limits the messages sent to the IMP to 1018 bytes, but INCORRECTLY uses a 1018 byte buffer to receive into. If the LH/DH-11 is healthy, the driver logic does deal with this situation, but with unneccessary interrupt overhead (to start a bunch of 2 byte reads). If the LH/DH-11 occasionally drops the EOM when DMA is restarted, messages would get concatonated, with the second (or both) messages being ignored. We will attempt to cause this failure in the lab, but recommend that LH/DH-11 drivers read into at least an 1020 byte buffer. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102513320900> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 25 Oct 85 20:36:51-PDT Date: 25 Oct 1985 20:32:09 PDT From: POSTEL@USC-ISIB.ARPA Subject: re: serial-line ip/tcp ? To: tcp-ip@SRI-NIC.ARPA For background see RFCs 914, 916, 935. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510252218.AA07509%40ucb-vax.berkeley.edu] <1985102513411600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: jas@PROTEON.ARPA Newsgroups: mod.protocols.tcp-ip Subject: 802.2 SAP's Message-ID: <8510252218.AA07509@ucb-vax.berkeley.edu> Date: Fri, 25-Oct-85 17:41:16 EDT Article-I.D.: ucb-vax.8510252218.AA07509 Posted: Fri Oct 25 17:41:16 1985 Date-Received: Sat, 26-Oct-85 08:24:23 EDT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@ucbvax.berkeley.edu Given as IBM has annouced their 802.5 network, those of us who use IP are starting to think about running IP over it. I've looked at RFC 948 (Two methods for IP over 802.3), and it mentions the issue of using 802.2 SAP's. With 802.5, we don't have any choice but to use SAPs. There is no type field in the header like there was in Ethernet. There is a SAP for IP, as well as ones for ISO and SNA. However we don't have a SAP for ARP, or anything like it. All three of the 802.[345] networks use 48-bit addresses, so all of them will need ARP to map from 32 bits to 48. (Now is not the time to start using translation tables.) Has anybody seen any efforts in this direction from standards bodies? Who beat up the IEEE 802.2 committee to get the IP SAP in the first place? It would be really nice if there were a good RFC as to how IP runs over 802.2/802.5 before a line of code gets written. Let's not have incompatible IP's. (Of course, maybe all this is solved by 802.1, but I doubt it.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [499138120-13197-wales%40DIANA.LOCUS.UCLA.EDU] <1985102517284000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: wales@LOCUS.UCLA.EDU (Rich Wales) Newsgroups: mod.protocols.tcp-ip Subject: Serial-line TCP/IP? Message-ID: <499138120-13197-wales@DIANA.LOCUS.UCLA.EDU> Date: Fri, 25-Oct-85 21:28:40 EDT Article-I.D.: DIANA.499138120-13197-wales Posted: Fri Oct 25 21:28:40 1985 Date-Received: Sat, 26-Oct-85 08:35:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu Has anyone implemented TCP/IP over serial lines in 4.2BSD UNIX? We are connecting a couple of systems via a 9600-baud leased line, and it would be wonderful if we could make them into a two-host local network talking ARPA protocols. I seem to remember hearing about something like this -- but I don't remember who did it. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510260342.AA03630%40UCB-VAX] <1985102519320900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: POSTEL@USC-ISIB.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: serial-line ip/tcp ? Message-ID: <8510260342.AA03630@UCB-VAX> Date: Fri, 25-Oct-85 23:32:09 EDT Article-I.D.: UCB-VAX.8510260342.AA03630 Posted: Fri Oct 25 23:32:09 1985 Date-Received: Sat, 26-Oct-85 08:35:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@ucbvax.berkeley.edu For background see RFCs 914, 916, 935. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510260501.AA05992%40mitre.ARPA] <1985102521015200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cperry@MITRE.ARPA (Chris Perry) Newsgroups: mod.protocols.tcp-ip Subject: Re: Serial-line TCP/IP? Message-ID: <8510260501.AA05992@mitre.ARPA> Date: Sat, 26-Oct-85 01:01:52 EDT Article-I.D.: mitre.8510260501.AA05992 Posted: Sat Oct 26 01:01:52 1985 Date-Received: Sat, 26-Oct-85 08:44:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@ucbvax.berkeley.edu I'm forwarding your note to Bryan Gorman (gorman@isid), since I think he knows of somebody in the Washington, DC area who has implemented a 19.2 Kbps serial IP. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510260520.AA04914%40UCB-VAX] <1985102521062900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Serial-line TCP/IP? Message-ID: <8510260520.AA04914@UCB-VAX> Date: Sat, 26-Oct-85 01:06:29 EDT Article-I.D.: UCB-VAX.8510260520.AA04914 Posted: Sat Oct 26 01:06:29 1985 Date-Received: Sat, 26-Oct-85 08:44:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@ucbvax.berkeley.edu rick@seismo did it, ghg@purdue did a low-overhead version thereof. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102521062901> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Fri 25 Oct 85 22:12:43-PDT Date: Sat, 26 Oct 85 1:06:29 EDT From: Mike Muuss To: Rich Wales cc: TCP-IP@sri-nic.arpa Subject: Re: Serial-line TCP/IP? rick@seismo did it, ghg@purdue did a low-overhead version thereof. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102607180000> Received: from SRI-CSL.ARPA by SRI-NIC.ARPA with TCP; Sat 26 Oct 85 14:19:42-PDT Date: 26 Oct 1985 14:18-PDT Sender: GEOFF@SRI-CSL.ARPA Subject: Re: Serial-line TCP/IP? From: the tty of Geoffrey S. Goodfellow To: wales@LOCUS.UCLA.EDU Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[SRI-CSL.ARPA]26-Oct-85 14:18:41.GEOFF> In-Reply-To: <499138120-13197-wales@DIANA.LOCUS.UCLA.EDU> Marshall Rose of UCI wrote something like this, suggest you contact him. Particulars available from NIC WHOIS. g ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510261751.AA13342%40UCB-VAX] <1985102609433800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: LH/DH-11 and IMP padding Message-ID: <8510261751.AA13342@UCB-VAX> Date: Sat, 26-Oct-85 13:43:38 EDT Article-I.D.: UCB-VAX.8510261751.AA13342 Posted: Sat Oct 26 13:43:38 1985 Date-Received: Sun, 27-Oct-85 00:23:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@ucbvax.berkeley.edu In response to the message sent 25 Oct 85 12:41:00 PDT from Art, Every year some poor dude relearns about IMP padding and sends a message like yours and reminds the rest of us. This year it was you. Don't feel bad, a couple of years ago it was me. Those who forget the lessons of history are bound to repeat them. Or something like that. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102609530000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Sat 26 Oct 85 16:59:45-PDT Date: 26 Oct 85 16:53:00 PDT From: Subject: TCP/IP over serial lines To: "wales" cc: tcp-ip@sri-nic Reply-To: Thomas Ferrin (ucsfcgl!tef) at Univ. of California, San Francisco has written a paper entitled "A Recipe for Establishing Point-to-Point TCP/IP Network Links with 4.2 BSD Unix". In the paper he describes the procedures necessary for establishing a point-to-point network link. Tom points out the necessary hardware, software, and costs of establishing either a 9600 baud or 56 K baud dedicated link. A working network link between UCSF and UCB was used as a model. ACC participated by supplying the Host Interface (the ACP 6100) at the UCSF site. Gary Krall/ACC ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102612472900> Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Sat 26 Oct 85 19:56:10-PDT Date: Sat, 26 Oct 85 19:47:29 PDT From: tencati@JPL-VLSI.ARPA Subject: TCP/IP over serial lines... To: tcp-ip@sri-nic.arpa I too have a similar need. I am looking for a TCP/IP program to connect two vaxes running VMS. One of the VAXes is running V3.7, the other runs V4.2. The software broke when JPL-VLSI went to V4.1. At that time, host JPL-ROBOTICS was forced off the ARPAnet. I will check with the references already listed in responses to the UNIX query, but if anyone knows of a program that will run under both versions of VMS (or at least V4.x), I would appreciate the pointers. Thanks in advance, Ron Tencati JPL-VLSI.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BSRI-CSL.ARPA%5D26-Oct-85.14:18:41.GEOFF] <1985102614180000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow) Newsgroups: mod.protocols.tcp-ip Subject: Re: Serial-line TCP/IP? Message-ID: <[SRI-CSL.ARPA]26-Oct-85.14:18:41.GEOFF> Date: Sat, 26-Oct-85 19:18:00 EST Article-I.D.: <[SRI-CSL.ARPA]26-Oct-85.14:18:41.GEOFF> Posted: Sat Oct 26 19:18:00 1985 Date-Received: Sun, 27-Oct-85 09:41:26 EST References: <499138120-13197-wales@DIANA.LOCUS.UCLA.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@ucbvax.berkeley.edu Marshall Rose of UCI wrote something like this, suggest you contact him. Particulars available from NIC WHOIS. g ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510270009.AA18312%40UCB-VAX] <1985102616530000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gary@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP over serial lines Message-ID: <8510270009.AA18312@UCB-VAX> Date: Sat, 26-Oct-85 21:53:00 EST Article-I.D.: UCB-VAX.8510270009.AA18312 Posted: Sat Oct 26 21:53:00 1985 Date-Received: Sun, 27-Oct-85 09:43:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu Thomas Ferrin (ucsfcgl!tef) at Univ. of California, San Francisco has written a paper entitled "A Recipe for Establishing Point-to-Point TCP/IP Network Links with 4.2 BSD Unix". In the paper he describes the procedures necessary for establishing a point-to-point network link. Tom points out the necessary hardware, software, and costs of establishing either a 9600 baud or 56 K baud dedicated link. A working network link between UCSF and UCB was used as a model. ACC participated by supplying the Host Interface (the ACP 6100) at the UCSF site. Gary Krall/ACC ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510270305.AA20154%40UCB-VAX] <1985102620472900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: tencati@JPL-VLSI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP over serial lines... Message-ID: <8510270305.AA20154@UCB-VAX> Date: Sun, 27-Oct-85 01:47:29 EST Article-I.D.: UCB-VAX.8510270305.AA20154 Posted: Sun Oct 27 01:47:29 1985 Date-Received: Sun, 27-Oct-85 09:43:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu I too have a similar need. I am looking for a TCP/IP program to connect two vaxes running VMS. One of the VAXes is running V3.7, the other runs V4.2. The software broke when JPL-VLSI went to V4.1. At that time, host JPL-ROBOTICS was forced off the ARPAnet. I will check with the references already listed in responses to the UNIX query, but if anyone knows of a program that will run under both versions of VMS (or at least V4.x), I would appreciate the pointers. Thanks in advance, Ron Tencati JPL-VLSI.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [cdp.0.16689.499317770%40cdp.UUCP] <1985102718533100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: scott@cdp.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP and FTP for MS-DOS Message-ID: Date: Sun, 27-Oct-85 23:53:31 EST Article-I.D.: cdp.cdp.0.16689.499317770 Posted: Sun Oct 27 23:53:31 1985 Date-Received: Mon, 28-Oct-85 23:11:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu I'm looking for public domain or commercial software that implements TCP/IP and FTP on MS-DOS. Please reply to me directly, since I'm not on this list. -scott cdp!scott@SU-Glacier.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510280534.AA12180%40emory.eu] <1985102719342900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: km@emory.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP on 3B2? Message-ID: <8510280534.AA12180@emory.eu> Date: Mon, 28-Oct-85 00:34:29 EST Article-I.D.: emory.8510280534.AA12180 Posted: Mon Oct 28 00:34:29 1985 Date-Received: Mon, 28-Oct-85 23:12:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@ucbvax.berkeley.edu Does anyone know anything firm about the availability of TCP/IP for the 3B2? I remember a press release a while back about TWG doing a port, but don't recall seeing a product announcement. I also know that Sun is porting NFS to the 3B2, but again don't know when or if it will be a product (or if it necessarily uses TCP). Ken Mandelberg Emory University Dept of Math and CS Atlanta, Ga 30322 {akgua,sb1,gatech,decvax}!emory!km USENET km@emory CSNET km.emory@csnet-relay ARPANET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510281554.AA16293%40UCB-VAX] <1985102804010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: cain@EDN-UNIX.ARPA (Edward A. Cain) Newsgroups: mod.protocols.tcp-ip Subject: Re: 802.2 SAP's Message-ID: <8510281554.AA16293@UCB-VAX> Date: Mon, 28-Oct-85 09:01:00 EST Article-I.D.: UCB-VAX.8510281554.AA16293 Posted: Mon Oct 28 09:01:00 1985 Date-Received: Tue, 29-Oct-85 01:42:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@ucbvax.berkeley.edu Working with Rob Rosenthal of the National Bureau of Standards, I put together a case for a SAP for IP using the IEEE 802 committee's rules for standard SAP assignments -- basically arguments about universal use and widespread deployment. The IP SAP assignment for IP was an exception to the usual practice of assigning SAPs to "international standards". I tried the same route for ARP a few months ago, even though ARP isn't nearly as universal as IP. I was told: 1. There is a critical shortage of reserved numbers, even limiting them to the ISO and CCITT standards. 2. There are a bunch of numbers available for unofficial assignment, and one of these numbers ought to be picked for things like ARP. A directory of these unoffical number assignment is available to help avoid stepping on already assigned "toes". 3. Don't push your luck. Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102804010001> Received: from EDN-UNIX.ARPA by SRI-NIC.ARPA with TCP; Mon 28 Oct 85 07:33:57-PST Date: 28 Oct 1985 9:01:00 EST From: Edward A. Cain Subject: Re: 802.2 SAP's In-Reply-to: Your message of Fri, 25 Oct 85 17:41:16 EDT To: jas@proteon.arpa Cc: tcp-ip@sri-nic.arpa Working with Rob Rosenthal of the National Bureau of Standards, I put together a case for a SAP for IP using the IEEE 802 committee's rules for standard SAP assignments -- basically arguments about universal use and widespread deployment. The IP SAP assignment for IP was an exception to the usual practice of assigning SAPs to "international standards". I tried the same route for ARP a few months ago, even though ARP isn't nearly as universal as IP. I was told: 1. There is a critical shortage of reserved numbers, even limiting them to the ISO and CCITT standards. 2. There are a bunch of numbers available for unofficial assignment, and one of these numbers ought to be picked for things like ARP. A directory of these unoffical number assignment is available to help avoid stepping on already assigned "toes". 3. Don't push your luck. Ed Cain ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510281403.AA15801%40mitre.ARPA] <1985102804034900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: raklein@MITRE.ARPA (Richard Klein) Newsgroups: mod.protocols.tcp-ip Subject: Re: 802.2 SAP's Message-ID: <8510281403.AA15801@mitre.ARPA> Date: Mon, 28-Oct-85 09:03:49 EST Article-I.D.: mitre.8510281403.AA15801 Posted: Mon Oct 28 09:03:49 1985 Date-Received: Mon, 28-Oct-85 23:28:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@ucbvax.berkeley.edu The Manufacturing Automation Protocol (MAP) is an ISO based internetworking concept. MAP uses TP4 and IP on top of X.25 and 802.2 LLC type 1; 802.4 and 802.3 are currently supported. Plans call for including support for 802.2 LLC type 3 and Proway PLC. The people at NBS (John Heafner, 301-921-3537) and the GM Technical Center (Gary Workman, 313-575-0632) can give you more details on the architecture, protocols, and implementation of the system. A demo of MAP will be presented at the AUTOFACT 85 conference in Detroit, during the first week of November. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102808173700> Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Mon 28 Oct 85 17:20:17-PST Received: by su-shasta.arpa with TCP; Mon, 28 Oct 85 17:21:51 pst Received: by imagen.UUCP; Mon, 28 Oct 85 16:18:41 pst To: shasta!DDN-REQT@GUNTER-ADAM.ARPA Cc: shasta!tcp-ip@sri-nic.ARPA Reply-To: imagen!geof@decwrl Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Subject: Re: TCP/IP and FTP for MS-DOS Date: 28 Oct 85 16:17:37 PST (Mon) From: Geoffrey H. Cooper Since you asked... To: "Scott Weikart; Community Data Processing; 415-322-9069" Subject: Re: TCP/IP and FTP for MS-DOS Date: 28 Oct 85 09:36:06 PST (Mon) There is a package called PC/IP from MIT -- contact (John) romkey@borax for details. It is public domain and provides telnet and TFTP. FTP is not supported, because the TCP implementation supports only one connection at a time. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102808342100> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Mon 28 Oct 85 12:34:07-PST Date: 28 Oct 1985 14:34:21 CST Subject: Re: TCP/IP and FTP for MS-DOS From: DDN-REQT@GUNTER-ADAM.ARPA To: "Scott Weikart; Community Data Processing; 415-322-9069" cc: tcp-ip@SRI-NIC.ARPA, DDN-REQT@GUNTER-ADAM.ARPA In-Reply-To: ------- Return-Path: Received: FROM SRI-NIC.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 28 Oct 85 11:00:01 CST Received: from glacier by SRI-NIC.ARPA with TCP; Sun 27 Oct 85 20:49:09-PST Received: by glacier with Sendmail; Sun, 27 Oct 85 20:53:31 pst Date: Sun, 27 Oct 85 20:53:31 pst From: "Scott Weikart; Community Data Processing; 415-322-9069" To: tcp-ip@sri-nic.ARPA Message-Id: Subject: TCP/IP and FTP for MS-DOS I'm looking for public domain or commercial software that implements TCP/IP and FTP on MS-DOS. Please reply to me directly, since I'm not on this list. -scott cdp!scott@SU-Glacier.arpa ------- If anybody comes up with good information ion this one, please make sure the rest of wus hear about it. 're here at the Air Force DDN PMO and would sure like to be able to pass this kink ofd of info to our users. Link Verstegen (DDN=-REQT@GUNTER-ADAM.ARPA) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510281857.AA08618%40pop.UTEXAS.EDU] <1985102808570400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: smoot@POP.UTEXAS.EDU (Smoot Carl-Mitchell) Newsgroups: mod.protocols.tcp-ip Subject: subnet bug fixes under 4.2 Message-ID: <8510281857.AA08618@pop.UTEXAS.EDU> Date: Mon, 28-Oct-85 13:57:04 EST Article-I.D.: pop.8510281857.AA08618 Posted: Mon Oct 28 13:57:04 1985 Date-Received: Tue, 29-Oct-85 15:15:53 EST Sender: bershad@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 66 Approved: tcp-ip@ucbvax.berkeley.edu I discovered a botch in my subnet implementation which I posted about a month ago. I've updated the sources whcih are available in ~ftp/pub/subnet.tar on sally.utexas.edu (formerly ut-sally.arpa). In addition I added a sanity check to allow hosts with non-zero subnets to coexist with hosts with subnet 0 on the same network. The pertinent code changes are in if_subenable (in if_ether.c) and in if_loop.c. (which is where the botch is). The botch which I overlooked is in loattach (in if_loop.c). Change the following line: sin->sin_addr.s_addr = 0xff000000; to: sin->sin_addr.s_addr = htonl(0xff000000); The error is obvious and dumb. Here is a listing of the latest version of if_subenable with the sanity check added: /* determine if target address is on an interface with arp subnet routing * enabled */ if_subenable(itaddr, sinterface) struct in_addr itaddr; struct ifnet *sinterface; { struct route ro; struct sockaddr_in *sin; struct sockaddr wildcard; extern struct ifnet *if_ifonnetof(); /* target address is on a local network */ if (in_localaddr(itaddr)) { int net; struct ifnet *interface; net = in_netof(itaddr); /* sanity check - don't match if target is on the same * interface the arp request came from */ if (sinterface != NULL && net == sinterface->if_net) return(0); interface = if_ifonnetof(net); if (interface == NULL) { /* this should never happen */ printf("subenable - interface not found for net - %x\n", net); return(0); } return(interface->if_flags & IFF_SUBARP); } /* if target is not local then * look in routing table for the interface to use */ sin = (struct sockaddr_in *)(&ro.ro_dst); sin->sin_family = AF_INET; sin->sin_addr = itaddr; ro.ro_rt = NULL; (void) rtalloc(&ro); if (ro.ro_rt != NULL && ((struct sockaddr_in *)(&ro.ro_rt->rt_dst))->sin_addr.s_addr != 0 && ro.ro_rt->rt_ifp->if_flags & IFF_SUBARP && sinterface != ro.ro_rt->rt_ifp) return(1); return(0); } ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510282050.AA03118%40ucbvax] <1985102810342100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: DDN-REQT@GUNTER-ADAM.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP and FTP for MS-DOS Message-ID: <8510282050.AA03118@ucbvax> Date: Mon, 28-Oct-85 15:34:21 EST Article-I.D.: ucbvax.8510282050.AA03118 Posted: Mon Oct 28 15:34:21 1985 Date-Received: Tue, 29-Oct-85 01:46:19 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@ucbvax.berkeley.edu ------- Return-Path: Received: FROM SRI-NIC.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 28 Oct 85 11:00:01 CST Received: from glacier by SRI-NIC.ARPA with TCP; Sun 27 Oct 85 20:49:09-PST Received: by glacier with Sendmail; Sun, 27 Oct 85 20:53:31 pst Date: Sun, 27 Oct 85 20:53:31 pst From: "Scott Weikart; Community Data Processing; 415-322-9069" To: tcp-ip@sri-nic.ARPA Message-Id: Subject: TCP/IP and FTP for MS-DOS I'm looking for public domain or commercial software that implements TCP/IP and FTP on MS-DOS. Please reply to me directly, since I'm not on this list. -scott cdp!scott@SU-Glacier.arpa ------- If anybody comes up with good information i on this one, please make sure the rest of w us hear about it. 're here at the Air Force DDN PMO and would sure like to be able to pass this kink of d of info to our users. Link Verstegen (DDN= -REQT@GUNTER-ADAM.ARPA) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510282211.AA05405%40ucbvax] <1985102810380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Vshank@WEIZMANN.BITNET (Henry Nussbacher) Newsgroups: mod.protocols.tcp-ip Subject: Pc/Ip Message-ID: <8510282211.AA05405@ucbvax> Date: Mon, 28-Oct-85 15:38:00 EST Article-I.D.: ucbvax.8510282211.AA05405 Posted: Mon Oct 28 15:38:00 1985 Date-Received: Tue, 29-Oct-85 14:20:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@ucbvax.berkeley.edu Could someone please direct me to the Pc-Ip forum? Is there one? How many different versions of Pc/Ip are there? I now of the ones mentioned at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem to remember that certain sites where doing further development in this area (especially in the 3270 emulation area). Any leads? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510290013.AA00334%40cmu-ws-postoffice] <1985102814111500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: 802.2 SAP's Message-ID: <8510290013.AA00334@cmu-ws-postoffice> Date: Mon, 28-Oct-85 19:11:15 EST Article-I.D.: cmu-ws-p.8510290013.AA00334 Posted: Mon Oct 28 19:11:15 1985 Date-Received: Thu, 31-Oct-85 10:05:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@ucbvax.berkeley.edu We have been toying around the 802.2 SAP problem for a while. First of all, we think that RFC 948 should apply for all IP using 802.2 service quite regardless of the underlying network services (802.3, 802.4 or 802.5). Secondly, the SAP address for IP as per assigned by IEEE is not decimal 96 as in RFC 943, Page 21. IEEE has assigned the patent 01100000 for IP. In IEEE's notation, the least significant bit is the *leftmost* bit (section 3.3.1.2 of 802.2). Hence 01100000 is really decimal 6. Thirdly, having just 7 bit (exclusive of the LSB) for SAP is plain short sighted giving only 128 SAP's. This is further reduce by the fact that IEEE has reserved only the range X1DDDDDD (i.e 64 numbers !!). [ It appears that X0DDDDDD is fair game for anyone ]. I asked Jon Postel to see if he can get IEEE to get another number for ARP from IEEE. It looks as though they are quite reluctant to assign one of their scarce numbers for a protocol rather than a class of protocol. So, offically, we are kind of stuck. There are a number of things we can do : (a) Twist IEEE's arm until they cough up a number ..... (b) For DSAP, always use X1100000 for IP as per assigned. But for SSAP field, we will use the un-IEEE reserved convention - X0SSSSSS : Hence X0100000 will means IP type and X0110000 for ARP. (c) In view of the IEEE reserved usage of SAP is for really higher level protocol ID (or equivalent in function to the Ethernet type field), the SSAP field essentially is redundant (unless there is such unusal cases where we will like to have two different protocol sets communicating directly with each other). We can, therefore, bastardise the SSAP field for our own purpose. Hence SSAP X1100000 can be made to mean IP and X1110000 for ARP. My own preference is for (a) then (b). If (a) does not produce any result by the end of the year, I will like to produce an RFC based on(b) to replace 948. John Leong@* leong@@h.cs.cmu.edu P.S. : For those interested in the 802.5 (a..k.a. IBM token ring), there is, in my opinion, a major oversight - I do not see a maximum packet size specified any where!!!! Imagine the case where different interface cards have different buffer sizes ....... [ we then have to use 802.2's XID to exchange buffer size information, and, of course, the format of such exchange is not defined .....] ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510290142.AA10752%40ucbvax] <1985102814173700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: geof@imagen.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP/IP and FTP for MS-DOS Message-ID: <8510290142.AA10752@ucbvax> Date: Mon, 28-Oct-85 19:17:37 EST Article-I.D.: ucbvax.8510290142.AA10752 Posted: Mon Oct 28 19:17:37 1985 Date-Received: Tue, 29-Oct-85 15:14:31 EST Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@ucbvax.berkeley.edu Since you asked... To: "Scott Weikart; Community Data Processing; 415-322-9069" Subject: Re: TCP/IP and FTP for MS-DOS Date: 28 Oct 85 09:36:06 PST (Mon) There is a package called PC/IP from MIT -- contact (John) romkey@borax for details. It is public domain and provides telnet and TFTP. FTP is not supported, because the TCP implementation supports only one connection at a time. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102900170000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 08:20:59-PST Date: 29 Oct 85 08:17:00 PST From: Subject: TCP/IP over serial lines To: "tcp-ip" Reply-To: Correction: ACC has a board capable of supporting T1 data rates which is supported on a VAX system running 4.2. UCSF is in the process of purchasing a board from ACC in their point-to-point link mentioned earlier. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102902080000> Received: from WISCVM.ARPA by SRI-NIC.ARPA with TCP; Mon 28 Oct 85 13:38:13-PST Received: from (VMMAIL)WEIZMANN.BITNET by WISCVM.ARPA on 10/28/85 at 15:39:19 CST Return-path: VSHANK%WEIZMANN.BITNET@WISCVM.ARPA Received: by WEIZMANN (Mailer X1.20) id 6435; Mon, 28 Oct 85 22:44:14 O Date: Mon, 28 Oct 85 22:38 O From: Henry Nussbacher Subject: Pc/Ip To: Could someone please direct me to the Pc-Ip forum? Is there one? How many different versions of Pc/Ip are there? I now of the ones mentioned at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem to remember that certain sites where doing further development in this area (especially in the 3270 emulation area). Any leads? Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510291907.AA03190%40ucbvax] <1985102906170000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gary@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP over serial lines Message-ID: <8510291907.AA03190@ucbvax> Date: Tue, 29-Oct-85 11:17:00 EST Article-I.D.: ucbvax.8510291907.AA03190 Posted: Tue Oct 29 11:17:00 1985 Date-Received: Thu, 31-Oct-85 08:01:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@ucbvax.berkeley.edu Correction: ACC has a board capable of supporting T1 data rates which is supported on a VAX system running 4.2. UCSF is in the process of purchasing a board from ACC in their point-to-point link mentioned earlier. Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510291955.AA04353%40ucbvax.berkeley.edu] <1985102909175400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: delp@HUEY.UDEL.EDU (Gary Delp) Newsgroups: mod.protocols.tcp-ip Subject: Re: Pc/Ip Message-ID: <8510291955.AA04353@ucbvax.berkeley.edu> Date: Tue, 29-Oct-85 14:17:54 EST Article-I.D.: ucbvax.8510291955.AA04353 Posted: Tue Oct 29 14:17:54 1985 Date-Received: Wed, 30-Oct-85 00:48:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Gary Delp Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@ucbvax.berkeley.edu >> Could someone please direct me to the Pc-Ip forum? Is there one? How >> many different versions of Pc/Ip are there? I now of the ones mentioned >> at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem >> to remember that certain sites where doing further development in this >> area (especially in the 3270 emulation area). Any leads? There is a bboard on louie.udel.edu that discusses these issues, the mailing address to be added to the bboard is: pcip-request@louie.udel.edu In addition to the MIT version, there is one from stanford that supports multiple connections, and hence ftp. wisconsin, and maryland as well as udel are working on other versions. Gary Delp 140 Evans Hall Department of Electrical Engineering University of Delaware Newark DE 19716 (302) 451-6653 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985102909175401> Received: from Huey.UDEL.EDU by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 11:20:13-PST Received: from localhost by Huey.UDEL.EDU id a010984; 29 Oct 85 14:18 EST Reply-To: Gary Delp To: Henry Nussbacher cc: tcp-ip@sri-nic.ARPA Subject: Re: Pc/Ip In-Reply-To: Your message of Mon, 28 Oct 85 22:38 O. Date: 29 Oct 85 14:17:54 EST (Tue) From: Gary Delp >> Could someone please direct me to the Pc-Ip forum? Is there one? How >> many different versions of Pc/Ip are there? I now of the ones mentioned >> at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem >> to remember that certain sites where doing further development in this >> area (especially in the 3270 emulation area). Any leads? There is a bboard on louie.udel.edu that discusses these issues, the mailing address to be added to the bboard is: pcip-request@louie.udel.edu In addition to the MIT version, there is one from stanford that supports multiple connections, and hence ftp. wisconsin, and maryland as well as udel are working on other versions. Gary Delp 140 Evans Hall Department of Electrical Engineering University of Delaware Newark DE 19716 (302) 451-6653 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [851029-163751-1872%40Xerox] <1985102914361400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: Kluger.osbunorth@XEROX.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: 802.2 SAP's Message-ID: <851029-163751-1872@Xerox> Date: Tue, 29-Oct-85 19:36:14 EST Article-I.D.: Xerox.851029-163751-1872 Posted: Tue Oct 29 19:36:14 1985 Date-Received: Sat, 2-Nov-85 03:21:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@ucbvax.berkeley.edu Don't Panic! There are contributions before the 802.x committees which will fix the problem of only 64 SAPs. The best contribution fixes the problem by proposing that one of the reserved 64 saps serve as an escape, opening up another field of 40 bits which is then used to demultiplex protocols. (It'll work very well.) The 802.1 contribution is by Tony Lauck and Arthur Harvey of DEC. The best would be for you all to go to the next meeting and support the proposal (if you agree with it). For more information, you can contact the proposal's authors. =====>>>> But have an influence, go to the IEEE 802 Meetings !!!! It is ONLY by attending the meetings that the work can be influenced. (The reason we got into this pickle in the first place is because not enough people with internetting experience have attended the meetings in the past.) The next meeting is November 11-15, '85 in Atlanta, Georgia at the Ritz-Carlton hotel in Buckhead. Registration fee is $100 at the meeting. Regards, Larry Kluger Team Leader for Internet Services Xerox Palo Alto ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12155255551.28.JNC%40MIT-XX.ARPA] <1985103004525800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: JNC@MIT-XX.ARPA ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: 802.2 SAP's Message-ID: <12155255551.28.JNC@MIT-XX.ARPA> Date: Wed, 30-Oct-85 09:52:58 EST Article-I.D.: MIT-XX.12155255551.28.JNC Posted: Wed Oct 30 09:52:58 1985 Date-Received: Thu, 31-Oct-85 08:15:46 EST References: <851029-163751-1872@Xerox> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu Yow! Can you say 'variable length wrappers'? (Those things give packet switches (routers) fits; unless you are prepared to copy data around, you can always think up wierd situations in which preallocated speace on the front of the buffer for construction of local headers isn't big enough.) How on Earth did they manage to use 64 numbers anyway? Does anyone have a list of the assigned numbers they could post? I'm wondering how long the edifice of computer networks will last before it collapses under the weight of its own complexity and braindamage, like some modern day Tower of Babel. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1985103013020000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Wed 30 Oct 85 21:19:49-PST Date: 30 Oct 85 21:02:00 PST From: Subject: DEC IMP interfaces To: "gds" cc: tcp-ip@sri-nic Reply-To: >Does anyone out there know of a board that DEC makes which can be used >to talk to an IMP? It would be called something like an imp11. Also, >are there any Unix drivers written for it? Be aware that DEC CSS made two different IMP interfaces. The first, the IMP11-A, was based on a pair of DR11-B interfaces. The second, the IMP11-B, was based on the KMC-11 microprocessor. The css driver in BSD 4.2 was for the IMP11-A and I doubt it will talk to an IMP11-B given the difference in base hardware. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510302317.AA11339%40sri-spam.arpa] <1985103013171600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gds@SRI-SPAM.ARPA (Greg Skinner) Newsgroups: mod.protocols.tcp-ip Subject: DEC 1822 interface board Message-ID: <8510302317.AA11339@sri-spam.arpa> Date: Wed, 30-Oct-85 18:17:16 EST Article-I.D.: sri-spam.8510302317.AA11339 Posted: Wed Oct 30 18:17:16 1985 Date-Received: Sun, 3-Nov-85 03:53:26 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@ucbvax.berkeley.edu Does anyone out there know of a board that DEC makes which can be used to talk to an IMP? It would be called something like an imp11. Also, are there any Unix drivers written for it? Please respond to me by mail if you know of any such board. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510310150.AA14392%40sri-spam.arpa] <1985103015500700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: gds@SRI-SPAM.ARPA (Greg Skinner) Newsgroups: mod.protocols.tcp-ip Subject: imp11 1822 interface board Message-ID: <8510310150.AA14392@sri-spam.arpa> Date: Wed, 30-Oct-85 20:50:07 EST Article-I.D.: sri-spam.8510310150.AA14392 Posted: Wed Oct 30 20:50:07 1985 Date-Received: Sun, 3-Nov-85 03:54:02 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@ucbvax.berkeley.edu Thanks to all who responded. I found the source for the driver, it's in /sys/vaxif/if_css.c in the 4.2bsd distribution. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8510310534.AA05846%40ucb-vax.berkeley.edu] <1985103019020000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: art@ACC.ARPA Newsgroups: mod.protocols.tcp-ip Subject: DEC IMP interfaces Message-ID: <8510310534.AA05846@ucb-vax.berkeley.edu> Date: Thu, 31-Oct-85 00:02:00 EST Article-I.D.: ucb-vax.8510310534.AA05846 Posted: Thu Oct 31 00:02:00 1985 Date-Received: Thu, 31-Oct-85 10:35:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@ucbvax.berkeley.edu >Does anyone out there know of a board that DEC makes which can be used >to talk to an IMP? It would be called something like an imp11. Also, >are there any Unix drivers written for it? Be aware that DEC CSS made two different IMP interfaces. The first, the IMP11-A, was based on a pair of DR11-B interfaces. The second, the IMP11-B, was based on the KMC-11 microprocessor. The css driver in BSD 4.2 was for the IMP11-A and I doubt it will talk to an IMP11-B given the difference in base hardware. "Art Berggreen" ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12155459261.8.BILLW%40SU-SCORE.ARPA] <1985103023315900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: BILLW@SU-SCORE.ARPA (William "Chops" Westfield) Newsgroups: mod.protocols.tcp-ip Subject: Improving TCP throughput. Message-ID: <12155459261.8.BILLW@SU-SCORE.ARPA> Date: Thu, 31-Oct-85 04:31:59 EST Article-I.D.: SU-SCORE.12155459261.8.BILLW Posted: Thu Oct 31 04:31:59 1985 Date-Received: Sat, 2-Nov-85 03:18:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@ucbvax.berkeley.edu The Tops20 TCP implementation attempts to be "sociable" by not sending bare ACKs. In order to do this, whenever it receives a packet that requires an ACK, it tells itself to wait for 250 milliseconds for some data to appear that is going in the opposite direction so that the ACK can go with it. On something like a telnet connection, this can essentially half the number of packets being sent, and so it is an excellent and widely implemented idea. Unfortunately, Many TCP connections are essentially "one-way". There is never going to be any data to send in the reverse direction to piggyback the ACK on, and the system ends up waiting when it should send and ack immediately. Furthermore, some TCPs (including TOPS20's) calculate their retransmission interval based on how long it takes them to receive the ACK for a packet they have sent. Delaying your ACK waiting for data disturbs this calculation, as pointed out by Alan Larson on the TOPS20 mailing list (27-Jun-85). Now, if the time it takes the other system to fill the window (presumably including data transmission time) is less than the time that your system waits to send the ACK, transmission becomes bursty, and you get serious performance degradation. This is aggravated by fast networks and small windows. Such was the case on Stanford Tops20 systems (which are on ethernets) running programs using the DEC JFN interface to TCP (which advertises a maximum 1456 byte window). Using FTP, for example, getting a file transfer speed of greater than 30K bps was rare. Using a BBN/CMU FTP (which advertises much larger windows), higher throughputs could be achieved (up to over 300Kbps, if irratically, and in extreme cases), which provided additional frustration. PUP FTP regularly beat 150Kbps. To improve upon this situation, I have implemented a concept I call "Interactivity". A connection is maximally interactive if a packet is sent every time a packet is received, and minimally interactive if it never sends any packets. In the first case, you want to wait a bit to try to piggyback acks on the outgoing data, but in the second case this introduces delays, and you want to send acks immediately. "Inverse interactivity" can be approximated by counting the number of packets received between each one sent. If greater than N, it is probably a good idea to send ACKs immediately. [Note: Immediately in this case mean AFTER to have chosen not to avoid sending the ACK to prevent the Silly Window Syndrome]. After performing this operation on the local tops20 systems, FTP data rates (using the JFN interface) as high as 150kbps were seen on the local ethernet. As might be expected from the above discussion, little increase in performance was seen on connections to hosts "further away" or on connections that used very large windows. I am CCing this message to various mailing lists besides TOPS20 since the idea may be useful within other TCP implementations. [The new tops20 sources (ANAUNV, TCPBBN, TCPTCP, STG) are available from Sierra in <6-1-monitor>, although these modules include some additional TCP fixes of a less general nature. They are also on Score, though those sources may be in transitory states. This monitor has been running on Score and Sushi since last friday without any apparent ill effects.] BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1985.10.31.17.43.36.240.05943%40Dione.rice] <1985103113433600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: milazzo@RICE.EDU (Paul Milazzo) Newsgroups: mod.protocols.tcp-ip Subject: proNET driver for Celerity? Message-ID: <1985.10.31.17.43.36.240.05943@Dione.rice> Date: Thu, 31-Oct-85 18:43:36 EST Article-I.D.: Dione.1985.10.31.17.43.36.240.05943 Posted: Thu Oct 31 18:43:36 1985 Date-Received: Sat, 2-Nov-85 07:11:53 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@ucbvax.berkeley.edu We would dearly love to have a proNET driver for a Celerity C1200, of which several have recently appeared. If you have one, or are working on one, please let me know! If not, could anyone estimate the difficulty involved in writing one? Since it is a 4.2bsd machine with a Multibus, perhaps one could use the SUN driver for inspiration? Thanks, Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX Domain: milazzo@rice.EDU ARPA: milazzo@rice.ARPA BITNET: milazzo@ricecsvm UUCP: {cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511010543.AA11097%40ucb-vax.berkeley.edu] <1985103119312700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Improving TCP throughput. Message-ID: <8511010543.AA11097@ucb-vax.berkeley.edu> Date: Fri, 1-Nov-85 00:31:27 EST Article-I.D.: ucb-vax.8511010543.AA11097 Posted: Fri Nov 1 00:31:27 1985 Date-Received: Sat, 2-Nov-85 07:21:39 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@ucbvax.berkeley.edu In response to the message sent Thu 31 Oct 85 01:31:59-PST from BILLW@SU-SCORE.ARPA Bill, It's refreshing to see that somebody is still brave enough to keep hacking at TCP trying to improve performance. We have seem some awful broken things wandering by our gateway, some of which caused massive congestion due imappropriate choices of retransmission timeouts, packetization, etc. Our darling fuzzballs were taught a very similar trick some time back for the same reason - to improve throughput on low-delay nets while sustaining good packetization efficiency on long-delay ones. However, we took a slightly different approach. If the left window edge moves an ACK will be guaranteed after no more than a nominal delay (about the same as yours). If the right window edge moves more than MSS octets since the last ACK, an ACK is forced immediately. Thus, high-volume traffic with max-size packets is not delayed, while interactive traffic with tinygrams is delayed for piggybacking opportunities. Using the Nagle Algorithm together with this technique, a typist can twinkle on a keyboard with a TOPS-20 or fuzzball (but not a 4.2) and result in one segment flipping end-for-end picking up data, remote-echoes and ACKs as it flips. The gateways love it. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8511010743.AA13849%40ucb-vax.berkeley.edu] <1985103122353400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mills@DCN6.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Time lurches on Message-ID: <8511010743.AA13849@ucb-vax.berkeley.edu> Date: Fri, 1-Nov-85 03:35:34 EST Article-I.D.: ucb-vax.8511010743.AA13849 Posted: Fri Nov 1 03:35:34 1985 Date-Received: Sat, 2-Nov-85 07:26:24 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@ucbvax.berkeley.edu Folks, They think our giant panda is pregnant, which might be a good omen. Nevertheless, today an ionospheric glitch blitzed our WWVB radio clock and the host caring for our WWV clock was several times off-net. Our ritzy new clock-backup features built into the local-net protocols switched everything around so our timestamps served to the world had nary a hiccup. However, turns out our third backup (GOES at Ford Research) had the wrong patchcords, so they were tracking us. The result was that we both walked the plank, but never swayed off more than a couple of hundred milliseconds, which is an eon around here. It was the intent that the GOES clock be the Ford primary, while their sfirst backup be us and second backup be a WWV clock at U Michigan. Grin while you might at all this ticking and tocking, but it's great fun and something refreshingly different. But, as the Potomac Electic technocrat said when I asked howcum they couldn't keep their clocks straighter, it's not a tariffed service... Dave ------- ----MESSAGE-END----