|
|
ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for October 1985 (126 messages, 44348 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Oct-85 14:31:00 EDT From: stanonik@NPRDC.ARPA (Ron Stanonik) To: fa.tcp-ip Subject: 4.2BSD tftp doesn't retransmit acks
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,
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Oct-85 15:31:39 EDT From: Myer@DEWEY.UDEL.EDU To: fa.tcp-ip Subject: Papers on tcp/ip
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.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Tue, 1-Oct-85 20:31:00 EDT From: CERF@USC-ISI.ARPA To: fa.tcp-ip Subject: Re: Papers on tcp/ip
Jon Postel probably has the best bibliography - also check with the NIC. Vint
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1985 19:12:46 PDT From: POSTEL@USC-ISIB.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: TCP Testing
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 ***
-------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Wed, 2-Oct-85 22:12:46 EDT From: POSTEL@USC-ISIB.ARPA To: fa.tcp-ip Subject: TCP Testing
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 ***
-------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Oct-85 01:47:21 EDT From: @CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20 (Asheem) To: fa.tcp-ip Subject: Intel 310 Networking
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
-------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Thu 3 Oct 85 01:47:21-EDT From: Asheem <@CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20> To: tcp-ip@sri-nic.ARPA Subject: Intel 310 Networking
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
-------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Oct-85 13:32:54 EDT From: wjc@LL-VLSI.ARPA (Bill Chiarchiaro) To: fa.tcp-ip Subject: System V -- Help!
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.
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Oct-85 16:27:38 EDT From: Bhobe@DEWEY.UDEL.EDU To: fa.tcp-ip Subject: lan internetworking
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
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 3-Oct-85 16:47:59 EDT From: WUTS@USC-ECLC.ARPA (Maurice J. Wuts) To: fa.tcp-ip Subject: Time servers
I know there are Unix time pollers / servers out there. Is there anyone with a Tops20 version? Maurice Wuts -------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Sat, 5-Oct-85 22:45:40 EDT From: medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems G) To: fa.tcp-ip Subject: IBM TCP/IP product
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
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 1985 08:36 PST From: Gary Krall <GARY@ACC.ARPA> To: TCP-IP@SRI-NIC Cc: MEDIN%ORION@AMES,FALSETTI%ORION@AMES Subject: IBM Ethernet attach
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 ------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 85 09:07:00 PDT From: HATFIELD, WILLIAM T <hatfield@ge-crd> To: tcp-ip <tcp-ip@sri-nic>
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. ------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Oct-85 12:36:00 EDT From: GARY@ACC.ARPA (Gary Krall) To: fa.tcp-ip Subject: IBM Ethernet attach
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 ------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Oct-85 13:05:02 EDT From: minshall@UCBOPAL.CC (Greg Minshall) To: fa.tcp-ip Subject: Wisconsin code
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
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Oct-85 13:06:37 EDT From: medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN Advanced Systems G) To: fa.tcp-ip Subject: Re: IBM Ethernet attach
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
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Mon, 7-Oct-85 14:54:31 EDT From: poggio@SRI-TSC.ARPA (Andy Poggio) To: fa.tcp-ip Subject: ACM Sigcomm Announcement
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
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1985 15:26:24 PDT From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: LYNCH@USC-ISIB.ARPA Subject: Excelan
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 -------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Oct-85 12:53:23 EDT From: milazzo@RICE.EDU (Paul Milazzo) To: fa.tcp-ip Subject: IBM block mode tty emulation
"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
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Tue, 8-Oct-85 18:26:24 EDT From: LYNCH@USC-ISIB.ARPA (Dan Lynch) To: fa.tcp-ip Subject: Excelan
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 -------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Wed, 9-Oct-85 09:11:45 EDT From: delp@HUEY.UDEL.EDU (Gary Delp) To: fa.tcp-ip Subject: Re: Excelan
dan, Can you let me know what your responses are? thanks, gary
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 09 Oct 85 09:11:45 EDT (Wed) From: Gary Delp <delp@huey.udel.EDU> To: Dan Lynch <LYNCH@usc-isib.ARPA> Cc: tcp-ip@sri-nic.ARPA Subject: Re: Excelan
dan, Can you let me know what your responses are? thanks, gary
-----------[000022][next][prev][last][first]---------------------------------------------------- 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
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Oct-85 17:42:26 EDT From: HAL@SRI-NIC.ARPA (Hal Huntley) To: fa.tcp-ip Subject: TCP for IBM AT?
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 -------
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Fri, 11-Oct-85 21:52:08 EDT From: mills@DCN6.ARPA To: fa.tcp-ip Subject: NTP and timetelling issues
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 -------
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 11-Oct-85 21:50:16-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Cc: mills@dcn6.arpa Subject: NTP and timetelling issues
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 -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1985 10:11:33 PDT From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: Hal Huntley <HAL@SRI-NIC.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA Subject: Re: TCP for IBM AT?
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 -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1985 14:34:48 PDT From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: LYNCH@USC-ISIB.ARPA Subject: Excelan
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 -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Sat, 12-Oct-85 13:11:33 EDT From: LYNCH@USC-ISIB.ARPA (Dan Lynch) To: fa.tcp-ip Subject: Re: TCP for IBM AT?
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 -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1985 17:43:51 PDT From: Dan Lynch <LYNCH@USC-ISIB.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: LYNCH@USC-ISIB.ARPA Subject: Excelan gateway addendum
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 -------
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sat, 12-Oct-85 17:34:48 EDT From: LYNCH@USC-ISIB.ARPA (Dan Lynch) To: fa.tcp-ip Subject: Excelan
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 -------
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Sat, 12-Oct-85 20:43:51 EDT From: LYNCH@USC-ISIB.ARPA (Dan Lynch) To: fa.tcp-ip Subject: Excelan gateway addendum
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 -------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Sun, 13-Oct-85 12:45:04 EDT From: lwa@apollo.UUCP To: fa.tcp-ip Subject: Re: 4.2BSD tftp doesn't retransmit acks
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
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Mon, 14-Oct-85 21:05:36 EDT From: romkey@MIT-BORAX.ARPA (John Romkey) To: fa.tcp-ip Subject: new 4.2 tftp daemon
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
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 85 13:26:00 PDT From: <prodmkt@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: IBM TCP/IP survey
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?
------
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Tue, 15-Oct-85 16:26:00 EDT From: prodmkt@ACC.ARPA To: fa.tcp-ip Subject: IBM TCP/IP survey
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?
------
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Tue, 15-Oct-85 19:51:31 EDT From: schoff@RPICS.CSNET (Martin Lee Schoffstall) To: fa.tcp-ip 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
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 Oct 85 19:51:31 EDT From: Martin Lee Schoffstall <schoff%rpics.csnet@CSNET-RELAY.ARPA> 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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Wed, 16-Oct-85 07:21:00 EDT From: norm@NCSC.ARPA (Ernest Norman) To: fa.tcp-ip Subject: Help with host addressing
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.
-------
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 85 07:21 EDT From: Ernest Norman <norm@ncsc> To: TCP-IP-REQUEST@SRI-NIC Cc: norm@ncsc Subject: Help with host addressing
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.
-------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 16-Oct-85 11:27:00 EDT From: Mills@CISL-SERVICE-MULTICS.ARPA To: fa.tcp-ip Subject: French ARPANET connections?
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
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 16-Oct-85 17:54:30 EDT From: MILLS@USC-ISID.ARPA To: fa.tcp-ip Subject: Re: French ARPANET connections?
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) -------
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 16-Oct-85 19:29:25 EDT From: raj@UCI-ICSA.ARPA (Richard Johnson) To: fa.tcp-ip Subject: Ethernet problems
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)
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 1985 07:37:23 CDT From: DDN-REQT@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: DDN-REQT@GUNTER-ADAM.ARPA Subject: excelan boards
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 -------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Thu, 17-Oct-85 08:37:23 EDT From: DDN-REQT@GUNTER-ADAM.ARPA To: fa.tcp-ip Subject: excelan boards
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 -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 85 12:24:00 PDT From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: Request for TCP/IP test program
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"<Art@ACC.ARPA> ------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Thu, 17-Oct-85 10:47:48 EDT From: lbyers%xls-plexus01.amc@AMC-HQ.ARPA (Lynn) To: fa.tcp-ip Subject: Deletion
Please delete <lbyers at amc-hq> from the tcp-ip mailing list. Thanks....Lynn
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 85 10:47:48-EDT (Thu) From: Lynn <lbyers%xls-plexus01.amc@AMC-HQ.ARPA> To: tcp-ip%sri-nic.arpa@AMC-HQ.ARPA Subject: Deletion
Please delete <lbyers at amc-hq> from the tcp-ip mailing list. Thanks....Lynn
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thu, 17-Oct-85 11:58:18 EDT From: marwaha@LOUIE.UDEL.EDU To: fa.tcp-ip Subject: info on commercially available LANs
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
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Thu, 17-Oct-85 15:24:00 EDT From: art@ACC.ARPA To: fa.tcp-ip Subject: Request for TCP/IP test program
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"<Art@ACC.ARPA> ------
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 85 09:46:00 PDT From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Subject: RE: Ethernet problem
>
> 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"<Art@ACC.ARPA>
------
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Fri, 18-Oct-85 09:42:38 EDT From: MILLS@USC-ISID.ARPA To: fa.tcp-ip Subject: Re: Request for TCP/IP test program
In response to the message sent 17 Oct 85 12:24:00 PDT from <art@acc.arpa> 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 -------
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 1985 1341-PDT (Friday) From: jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) To: DDN-REQT@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: excelan boards
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
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Fri, 18-Oct-85 12:46:00 EDT From: art@ACC.ARPA To: fa.tcp-ip Subject: RE: Ethernet problem
>
> 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"<Art@ACC.ARPA>
------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Fri, 18-Oct-85 12:56:52 EDT From: clements@BBNCCQ.ARPA (Bob Clements) To: fa.tcp-ip Subject: Re: Request for TCP/IP test program
[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
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Fri, 18 Oct 85 12:56:52 EDT From: Bob Clements <clements@bbnccq.ARPA> To: <art@acc.arpa> Cc: tcp-ip@sri-nic.arpa, clements@bbnccq.arpa Subject: Re: Request for TCP/IP test program
[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
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Fri, 18-Oct-85 13:54:00 EDT From: stanonik@NPRDC.ARPA (Ron Stanonik) To: fa.tcp-ip Subject: Re: 4.2BSD tftp doesn't retransmit acks
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
-----------[000057][next][prev][last][first]----------------------------------------------------
Date: Fri, 18-Oct-85 14:37:00 EDT
From: jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro")
To: fa.tcp-ip
Subject: Re: info on commercially available LANsBRIDGE 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
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 1985 17:43:12 PDT From: POSTEL@USC-ISIB.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: art@ACC.ARPA Subject: re: TCP test programs
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.
-------
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Fri 18 Oct 85 15:19:00-EDT From: Vince.Fuller@C.CS.CMU.EDU To: clements@BBNCCQ.ARPA Cc: art@ACC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Request for TCP/IP test program
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 -------
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 85 18:38:26 EDT From: DonWinter.pasa@Xerox.ARPA To: Richard Johnson <raj@UCI.EDU> Cc: tcp-ip@sri-nic.arpa Subject: Re: Ethernet problems
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
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Fri, 18-Oct-85 20:43:12 EDT From: POSTEL@USC-ISIB.ARPA To: fa.tcp-ip Subject: re: TCP test programs
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.
-------
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Sat, 19-Oct-85 12:40:37 EDT From: radzy@calma.UUCP To: fa.tcp-ip Subject: Re: Ethernet problems
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
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Sat, 19-Oct-85 20:01:25 EDT From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) To: fa.tcp-ip Subject: Re: Ethernet problems
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? -------
-----------[000064][next][prev][last][first]----------------------------------------------------
Date: Sat, 19-Oct-85 20:12:00 EDT
From: jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro")
To: fa.tcp-ip
Subject: Re: info on commercially available LANsSorry 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
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Sun, 20-Oct-85 08:42:55 EDT From: dpk@mcvax.UUCP To: mod.protocols.tcp-ip Subject: Re: TCP test programs
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-
-----------[000066][next][prev][last][first]----------------------------------------------------
Date: Mon, 21-Oct-85 14:20:17 EDT
From: cak@PURDUE.EDU ("Christopher A. Kent")
To: mod.protocols.tcp-ip
Subject: Re: TCP test programsNope, I didn't do any little services, just finger. We use a program called inetd (not like SUN's inetd) from Marshall Rose. chris ----------
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 21 Oct 1985 1706-EST From: Dale Moore <MOORE@PS1.CS.CMU.EDU> To: TCP-IP@NIC
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? ------
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Mon, 21-Oct-85 18:06:00 EDT From: MOORE@PS1.CS.CMU.EDU (Dale Moore) To: mod.protocols.tcp-ip Subject: (none)
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? ------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 21 Oct 85 21:37:00 PDT From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Cc: unix-wizards@brl Subject: Thanks for responses
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"<Art@ACC.ARPA> ------
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 22-Oct-85 00:37:00 EDT From: art@ACC.ARPA To: mod.protocols.tcp-ip Subject: Thanks for responses
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"<Art@ACC.ARPA> ------
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 22-Oct-85 10:47:00 EDT From: Mills@CISL-SERVICE-MULTICS.ARPA To: mod.protocols.tcp-ip Subject: French ARPANET connections
Thanks to everyone who responded to my earlier request. The number of replies and the quality of the information was very impressive. John Mills
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Wed, 23-Oct-85 00:03:59 EDT From: ron@BRL.ARPA (Ron Natalie) To: mod.protocols.tcp-ip 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
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Oct 85 0:03:59 EDT From: Ron Natalie <ron@BRL.ARPA> 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
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 1985 1839-PDT (Wednesday) From: Tim Mann <mann@su-pescadero.arpa> To: Jonathan Dreyer <jdreyer@BBNCCV.ARPA> Cc: tcp-ip@sri-nic Subject: Re: IP, ICMP, TCP, and UDP checksumming.
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
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Wed, 23-Oct-85 19:14:00 EDT From: jdreyer@BBNCCV.ARPA (Jonathan Dreyer) To: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming.
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.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 23 Oct 85 19:14:00 EDT (Wed) From: Jonathan Dreyer <jdreyer@BBNCCV.ARPA> To: Ron Natalie <ron@brl.ARPA> Cc: tcp-ip@sri-nic.ARPA Subject: Re: IP, ICMP, TCP, and UDP checksumming.
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.
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Wed, 23-Oct-85 21:39:00 EDT From: mann@SU-PESCADERO.ARPA (Tim Mann) To: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming.
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
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Wed, 23-Oct-85 22:33:00 EDT From: don.provan@A.CS.CMU.EDU To: mod.protocols.tcp-ip Subject: Re: IP, ICMP, TCP, and UDP checksumming.
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...
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Thu, 24-Oct-85 03:02:34 EDT From: mike@BRL.ARPA (Mike Muuss) To: mod.protocols.tcp-ip 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
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 Oct 85 3:02:34 EDT From: Mike Muuss <mike@BRL.ARPA> 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
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Thu, 24-Oct-85 03:20:47 EDT From: mike@BRL.ARPA (Mike Muuss) To: mod.protocols.tcp-ip 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
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 Oct 85 3:20:47 EDT From: Mike Muuss <mike@BRL.ARPA> 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
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 25 Oct 85 12:41:00 PDT From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic> Cc: unix-wizards@brl Subject: LH/DH-11 and IMP padding
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"<Art@ACC.ARPA> ------
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Fri, 25-Oct-85 15:41:00 EDT From: art@ACC.ARPA To: mod.protocols.tcp-ip Subject: LH/DH-11 and IMP padding
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"<Art@ACC.ARPA> ------
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 25 Oct 1985 20:32:09 PDT From: POSTEL@USC-ISIB.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: re: serial-line ip/tcp ?
For background see RFCs 914, 916, 935. --jon. -------
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: Fri, 25-Oct-85 17:41:16 EDT From: jas@PROTEON.ARPA To: mod.protocols.tcp-ip Subject: 802.2 SAP's
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.) -------
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Fri, 25-Oct-85 21:28:40 EDT From: wales@LOCUS.UCLA.EDU (Rich Wales) To: mod.protocols.tcp-ip Subject: Serial-line TCP/IP?
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
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: Fri, 25-Oct-85 23:32:09 EDT From: POSTEL@USC-ISIB.ARPA To: mod.pr