|
|
ARCHIVE: TCP-IP Distribution List - Archives (1986)
DOCUMENT: TCP-IP Distribution List for May 1986 (196 messages, 92855 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1986/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 May 1986 08:39-PDT From: Mike StJohns <StJohns@SRI-NIC.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: X.400 over TCP-IP?
Is there anyone out there running X.400 mail above TCP/IP? Please resond direct to me, I'll summarize for the list. Mike
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 May 86 10:25:55 pdt From: Andy Poggio <poggio@sri-tsc.ARPA> To: Mike StJohns <StJohns@SRI-NIC.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: X.400 over TCP-IP?
Mike, I know that BBN is working on one and we at ISTC have toyed with the idea. I am very interested in any other responses you receive. Please let me know... --Andy
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Thu, 01 May 86 16:58:10 -0800 From: Marshall Rose <mrose@nrtc-gremlin> To: Andy Poggio <poggio@sri-tsc.ARPA> Cc: Mike StJohns <StJohns@sri-nic.ARPA>, tcp-ip@sri-nic.ARPA Subject: Re: X.400 over TCP-IP?
The big problem though is what goes between TCP-IP and X.400.
Where's the session and presentation stuff? This is what partially
motivated rfc983 - the iso/ccitt folks are spending the majority of
their time arguing about addressing, etc. (in general, things that
got solved fairly well 5 years ago!), and much less work is being
done on the application stuff. Since all our previous experience
tells us that doing the higher-level stuff is at least as hard as
the lower-level stuff, if you're doing iso/ccitt applications, the
rfc983 approach is a big win.
(that bit of soap-boxing aside,) I know that the EAN system,
originally from University of British Columbia, and now from Sydney
Development Corporation has a TCP/IP interface. John Demco
(demco@ubc.csnet) is one of the principle gurus at UBC. Looking at
the NIC's HOST.TXT, I note that BBN-DIAMOND advertises TCP/X400 in
addition to TCP/MPM. I've been meaning to ask the Diamond wizards
about that, but haven't gotten around to it. If ISTC also has
something, I'd like to hear more.
/mtr
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 May 86 12:38:20 EDT From: Ross Patterson <PATTERSON@BLUE.RUTGERS.EDU> To: 1017518%MCMASTER.BITNET@WISCVM.WISC.EDU Cc: PATTERSON@BLUE.RUTGERS.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: DEC-IBM connection
Joanne, If you are running MVS on the IBM system, you may want to consider using UCLA's Arpanet Control Program (ACP) software to drive an ACC IF/370E Ethernet adapter. The IF/370E seems to work well, and the UCLA code required no changes to support it (in fact, UCLA is considering buying an IF/370E also.) We have had occasional problems with the hardware, but ACC has been quite responsive. I would be glad to discuss this in more depth, if you're interested. Ross Patterson Rutgers University Center for Computer and Information Services PATTERSON@BLUE.RUTGERS.EDU -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 May 86 11:30:19 pdt From: John Demco <demco%ubc.csnet@CSNET-RELAY.ARPA> To: tcp-ip@sri-nic.ARPA Cc: mrose@nrtc-gremlin.ARPA, CLynn@diamond.bbn.com, Harry Forsdick <forsdick@diamond.bbn.com> Subject: X.400 Mail Transport
I know this isn't TCP related, but I should clarify a bit... The EAN X.400 message system was developed here at the University of British Columbia, and development is continuing. Sydney Development has the commercial rights to EAN. To get back closer to the topic of TCP... EAN implements class 0 of the ISO transport protocol. Above is the X.225 session layer. Below are interfaces to TCP, X.25, DECNET, and TTXP (a protocol based on MMDF for use on asynchronous lines and ITI connections). I am interested in the approach proposed by RFC983 too, although I haven't read the document closely yet. John Demco UBC
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Fri, 2 May 86 09:17:33 EDT From: Harry Forsdick <forsdick@DIAMOND.BBN.COM> To: mrose@nrtc-gremlin.ARPA Cc: CLynn@DIAMOND.BBN.COM, tcp-ip@sri-nic Subject: Diamond X.400 Mail Transport
Hi. I was forwarded your message in tcp-ip about X.400. Yes, we have developed an X.400 based mail transport agent for use by the Diamond Multimedia Communications System. You should contact Charlie Lynn (CLynn@BBN) for details. I'm already aware of the Sydney Development Corp's X.400 on top of IP/TCP. I'm not familiar with "ISTC". Who are they and what are they offering in the way of X.400 mail systems? Regards, Harry P.S., Please reply directly since I am not on the tcp-ip list.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 May 86 08:45:17 pdt From: Jonathan Biggar <sdcrdcf!RDCF.SDC.UUCP!jonab@LOCUS.UCLA.EDU> To: ucla-cs!tcp-ip@sri-nic.arpa
Newsgroups: net.unix-wizards,net.lan,mod.protocols.tcp-ip Subject: Problem with IP fragmentation under Sun 3.0 UNIX Expires: References: Sender: Reply-To: jonab@sdcrdcf.UUCP (Jonathan Biggar) Followup-To: Distribution: Organization: System Development Corporation R&D, Santa Monica Keywords: We have a problem with IP fragmentation-reassembly causing bad tcp checksums at the receiving end under Sun 3.0 UNIX. Any pointers to bug fixes related to this for SUN 3.0, SUN 2.0, or 4.2bsd would be appreciated. Jonathan Biggar sdcrdcf!jonab
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 05-May-86 03:37:34-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: Spurious TCP retransmissions from NIC
Folks, I have noticed an alarmingly high incidence of TCP retransmissions from NIC on FTP transfers over medium-delay, low-loss paths. On a typical transfer from its ARPANET address via an ARPANET gateway and 4800-bps line for instance, an average of 2.5 packet transissions occured for every packet stored. During this transfer no packets were recorded as lost in either the gateway or destination host - all spurious packets were duplicates. In transfers to an Ethernet host connected via the same path an average of 2.0 packet transmissions occured for every packet stored. I supsect something is wrong in the retransmission-timeout algorithm of the NIC TCP client, since other TOPS-20 hosts do not exhibit anything like this behavior; however, other TOPS-20s seem on the hairy edge of eagerness, since ISI hosts,'f for instance, seem to generate rather more duplicates that, say, Unix hosts over the same paths. Fuzzball hosts (ahem) generate next to none over most paths. It implementors read RFC-889. It would be useful to learn if others can confirm or refute these observations, since NIC is fast becoming a major fountain of data. Dave -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: Mon, 5 May 86 10:08:25 edt From: rhott@NSWC-OAS.ARPA To: tcp-ip@sri-nic.ARPA Subject: Looking for MacIP
Has anyone heard of a Macintosh TCP/IP software product called MacIP?
I believe it originated at Carnegie Mellon University. Any pointers
to users, distributors would be appreciated.
Send responses to: rhott@nswc-g.arpa
Thanks,
bob hott Naval Surface Weapons Center, Dahlgren, VA 22448
Code K33 (Systems Integration and Networking)
Milnet mail : rhott@nswc-g.arpa
(703) 663 - 7745
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 May 86 11:16:17 edt From: steve@aplvax (Steven Kahn) To: tcp-ip@sri-nic Subject: 1822/X.25 interoperability question
First, a naive question about 1822/X.25 interoperability. Is it a reality? We understand that all future PSN hook-ups require X.25. Does this mean that we could establish TCP connections via such an interface to another host that is connected to its PSN via 1822? Now for a totally unrelated question regarding IBM TCP/IP. Do any of the software products for IBM (such as the UCLA code) contain the application level functionality (such as SMTP, Telnet and FTP) that I am used to in the UNIX world? For example, is SMTP integrated into IBM's "mailer"? (You can tell I'm not from the IBM world...) Steve Kahn Johns Hopkins Applied Physics Lab Laurel, MD steve@aplvax.arpa
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Tue 6 May 86 12:49:10-EDT From: Dennis G. Perry <PERRY@IPTO.ARPA> To: steve@APLVAX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, perry@IPTO.ARPA Subject: Re: 1822/X.25 interoperability question
Steve, my understanding is that with psn release 5, X.25 and 1822 should be able to talk to each other. Release 5 is almost ready, but required that all C30s be upgraded to C30Es. I believe that this release will occur soon. dennis -------
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue, 6 May 86 13:21:35 EDT From: Robert Myhill <myhill@ccs.bbn.com> To: Dennis G. Perry <PERRY@ipto.arpa> Cc: steve@aplvax.arpa, tcp-ip@sri-nic.arpa, laube@bbncc2.arpa, seisner@bbnccs.arpa, myhill@bbnccs.arpa, malis@bbnccs.arpa Subject: Re: 1822/X.25 interoperability question
Here are some facts on X.25/1822 interoperability: o In order for an X.25 host and an 1822 host to communicate, the PSN connected to the X.25 host must be running PSN Release 6.0 (note that the PSN at the 1822 end of the connection, or any PSN in between, need not be running PSN Release 6.0). o In order for a PSN to be running Release 6.0, it must be running on a C/30E. o PSN Release 6.0 has been officially released. o The hosts at both ends of an X.25 to 1822 connection must be running TCP/IP on top. I've heard that there are at least a couple of MILNET PSNs running Release 6.0, though I don't know this for a fact. I hope this helps. --Robert
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 7 May 1986 04:09-PDT From: STJOHNS@SRI-NIC.ARPA To: myhill@BBNCCS.ARPA Cc: PERRY@IPTO.ARPA, steve@APLVAX.ARPA tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA Subject: Re: 1822/X.25 interoperability question
PSN 6.0 is in LIMITED release on the MILNET and is being fielded to meet specific operational needs. As of the last time I looked, there are no nodes on the ARPANET which have PSN 6.0 installed. We have been waiting for the upgrade to C30Es on the ARPANET to be completed (which may have happened even as I type). Mike
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 7 May 1986 09:06:00 EDT From: Glen Foster <GFoster@USC-ISI.ARPA> To: STJOHNS@SRI-NIC.ARPA Cc: myhill@BBNCCS.ARPA, PERRY@IPTO.ARPA, steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA, laube@BBNCC2.ARPA, seisner@BBNCCS.ARPA, malis@BBNCCS.ARPA Subject: Re: 1822/X.25 interoperability question
I think that the c/30 -> c/30e upgrade has been completed. The PSN ver. 5.0 software is currently being installed in all Arpanet IMPS (oops, PSNS). PSN 28 was just upgraded yesterday. and I don't think it was one of the first. Our Milnet PSN, on the other hand, was upgraded last September. Glen -------
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Wed, 7 May 86 17:04:42 EDT From: swb@devvax.tn.cornell.edu (Scott Brim) To: tcp-ip@sri-nic.arpa Subject: Cisco
I have an introductory blurb from Cisco, a company marketing an IP gateway developed at Stanford. Does anyone have a phone number for the company? Any detailed information on how the product behaves, what its advantages and shortcomings are, what interfaces it supports, etc.? Thanks very much, Scott
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 8 May 1986 12:32:54 PDT From: BRADEN@USC-ISIB.ARPA To: steve@APLVAX.ARPA, tcp-ip@SRI-NIC.ARPA Cc: BRADEN@USC-ISIB.ARPA Subject: Re: 1822/X.25 interoperability question
In response to the message sent Tue, 6 May 86 11:16:17 edt from steve@aplvax Steve, The "UCLA code" for TCP/IP supports Telnet, FTP, and SMTP under OS/MVS. It interfaces not to the IBM "mailer" (because, incredible as it may seem from our perspective, there is no such critter), but to a mailer written at UCLA for both Bitnet and the Internet. There is a fullscreen 3278 interface to this mailer that is comparable in quality and ease with the mailtool on my Sun workstation, for example. Bob Braden -------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 May 86 11:48:45 EDT From: Louis A. Mamakos <louie@trantor.UMD.EDU> To: tcp-ip@sri-nic.arpa Subject: ULTRIX 1.2 brokeness
They did it again. After all of the flaming about the proper thing for a user telnet program to send for an end-of-line sequence, the ULTRIX 1.2 release is STILL broken. It seems that too many vendors assume that the correct thing is what UNIX does. These protocols are not defined by their actions, but by the specifications in the RFCs. The Wollongong people have this same problem, and are even more unresponsive to the user's needs then most vendors are. It's only a 3 line fix to make TELNET work. Oh well. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 8 May 1986 16:14-PDT From: William "Chops" Westfield <BillW@SU-SCORE.ARPA> To: swb@DEVVAX.TN.CORNELL.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Cisco
cisco Systems, Inc PO Box 475 Menlo Park, CA, 94026 (415) 326-1941 5106016967 (telex) They sell the IP gateway, a terminal server (talks TCP), and the MEIS, a massbus ethernet interface (eg for 20's). The gateway supports "Sun" 3Mb ethernet interfaces, 3com 10Mb interfaces, Interlan/micom 10Mb interfaces, ACC 1822 interfaces, and 56Kbps serial links, and others (up to 4 at once). The box is multibus based, so other interface support is feasible. Full support of IP, TCP, ICMP, EGP, ARP, Subnets, etc, and "IGP" (Internal Gateway Protocol (supports multipath routing, etc)). Stanford has about 25 of the "non-production" version linking together their 60 odd cable segments, along with about 60 of the "terminal servers". It all works quite well. Disclaimer: I dont for for cisco, but my boss does. I DO work for Stanford. BillW
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 08 May 86 14:36:54 EST (Thu) From: "Christopher A. Kent" <cak@Purdue.EDU> To: "Louis A. Mamakos" <louie@trantor.UMD.EDU> Cc: tcp-ip@sri-nic.arpa Subject: Re: ULTRIX 1.2 brokeness
Well, the story I get from the folks that actually put Ultrix together is that it takes 10 - 12 months to get changes out the door. So Ultrix 1.2 was probably frozen long before our flaming. Sigh, chris ----------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Thu, 08 May 86 19:03:27 -0500 From: Stan Ames <sra@mitre-bedford.ARPA> To: tcp-ip@sri-nic.ARPA, info-ibmpc@usc-isib.ARPA Cc: sra@mitre-bedford.ARPA Subject: Net Bios on top of TCP/IP
Recently several vendors (including Excelan, UB, and CMC) have anounced products that support the IBM/Microsoft Net Bios on top of the TCP/IP/UDP internet protocols for IEEE 802.3 LAN products. Unfortuantly each has interfaced Net Bios to the internet protocols in a somewhat different mannor. MITRE under the direction of the ULANA program office is attempting to bring the vendors together to agree on an interface specification. In order to be successful each of the vendors must participate and users must make their desires for vendor interoperability known to the vendors. Anyone that is involved in an inpending implementation of Net Bios on the internet protocols is encouraged to participate. Stan Ames sra@mitre-bedford.arpa
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Thu, 8 May 1986 20:13 EDT From: Jon Solomon <JSOL@BUCS20.BU.EDU> To: tcp-ip@sri-nic.arpa Subject: 4.2/4.3 subnetting
I have received numerous replies to my subnetting queries and here is a summary of the results. 1) Subnets aren't anywhere near fully implemented in the field. With the growing number of networks out there and the finite amount of network space it makes sense to utilize all the resources as well as one can. 2) 4.2 has no subnetting support. 4.3 apparently does have full subnetting support. 3) If you have ARP based networks then you can use a hack to implement subnets. This is known as "the ARP hack". I now have a copy of this hack for 4.3, but are in need of it for 4.2. Does anyone have a copy of it they'd be willing to give me? Oh, incidentally the 4.3 ARP hack implementation can be gotten from sally.utexas.edu using the anonymous FTP convention, if memory serves.
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 May 86 0:15:56 EDT From: Ron Natalie <ron@BRL.ARPA> To: Jon Solomon <JSOL@bucs20.bu.edu> Cc: tcp-ip@sri-nic.arpa Subject: Re: 4.2/4.3 subnetting
By the way, if you plan to talk to 4.2 machines using the ARP hack (i.e. you are going to treat the 4.2 machines as being ignorant about subnets), you must fix the code that references the "oldmap" variable as this will prevent ARP from working on the entire 16 bit address. -Ron
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Fri 9 May 86 00:30:31-EDT From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU> To: BillW@SU-SCORE.ARPA, swb@devvax.tn.cornell.edu Cc: tcp-ip@SRI-NIC.ARPA, JNC@XX.LCS.MIT.EDU Subject: Re: Cisco
Are there working examples of the EGP and ARPANet interface, or is that merely an announced product? Noel -------
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 May 86 08:21:07 edt From: martin%sabre@mouton.bellcore.com (Martin J Levy) To: tcp-ip@sri-nic.arpa Subject: Re: ULTRIX 1.2 brokeness
can i also bring up the subject of UDP broadcast's (this is with ULTRIX-32m). i'm coming to the conclusion that there is a mix of 4.2 and 4.3 style code in there for allowing a user to do a broadcast. in 4.2 one only needs to be root to send a broadcast, but with ULTRIX 1.1 it seems you need so do the setsockopt() also, but the correct defines are not in socket.h. can anyone help?, is 1.2 fixed? martin
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 09 May 86 01:54 +0200 From: Peter_Lothberg_STUPI%QZCOM.MAILNET@MIT-MULTICS.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Specs for TCP/IP on Ethernet for t20
Maybe sending to a black hole.... I'm trying to find the specs, that describes what goes on the ethernet cable, from a TCP/IP taking T20 6.1 arpa monitor. (.trying to hook a t10 7.02 with homebuild ethernet hardware into such network.)
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 May 1986 10:05 EDT From: Jon Solomon <JSOL@BUCS20.BU.EDU> To: Ron Natalie <ron@BRL.ARPA> Cc: tcp-ip@sri-nic.arpa Subject: 4.2/4.3 subnetting
Date: Friday, 9 May 1986 00:15-EDT
From: Ron Natalie <ron at BRL.ARPA>
To: Jon Solomon <JSOL>
cc: tcp-ip at sri-nic.arpa
Re: 4.2/4.3 subnetting
By the way, if you plan to talk to 4.2 machines using the ARP
hack (i.e. you are going to treat the 4.2 machines as being
ignorant about subnets), you must fix the code that references
the "oldmap" variable as this will prevent ARP from working on
the entire 16 bit address.
-Ron
Explain more.....Do you have such a fix?
--jsol
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Fri, 9 May 86 22:08:12 edt From: jbvb@BORAX.LCS.MIT.EDU (James B. VanBokkelen) To: tcp-ip@sri-nic.arpa Subject: Ultrix 1.2
One of our customers has reported that TFTP clients which can talk to Ultrix 1.1 just fine can't communicate with Ultrix 1.2. Anyone else experienced this? jbvb@AI.AI.MIT.EDU James B. VanBokkelen
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 10-May-86 04:47:32-UT From: mills@dcn6.arpa To: tcp-ip@sri-nic.arpa Subject: TCP retransmissions from NIC
Folks, Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their comments on my message about excessive TCP retransmissions. Measurements made tonight (about 0400Z) show some improvement. Via the NIC MILNET address, ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA, about one packet in 23 was dropped and one packet in seven was an old duplicate. Via the NIC ARPANET address and the same path, about one packet in 212 was dropped and one packet in 14 was an old duplicate. These figures represent a significant improvement over the figures I reported last week, but still leave room for improvement. I have not measured the performance via higher-speed paths, but suspect it is much better than before. I would like to thank the folk both at NIC and BBN for their quick response and prompt action on my message. Dave -------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Sat, 10-May-86 16:47:33 EDT From: mills@DCN6.ARPA To: mod.protocols.tcp-ip Subject: TCP retransmissions from NIC
Folks, Thanks to Alan Hill of BBN and Bob Knight and Mark Lottor at NIC for their comments on my message about excessive TCP retransmissions. Measurements made tonight (about 0400Z) show some improvement. Via the NIC MILNET address, ARPANET/MILNET gateway complex, DCN-GATEWAY and 4800-bps line to DCN6.ARPA, about one packet in 23 was dropped and one packet in seven was an old duplicate. Via the NIC ARPANET address and the same path, about one packet in 212 was dropped and one packet in 14 was an old duplicate. These figures represent a significant improvement over the figures I reported last week, but still leave room for improvement. I have not measured the performance via higher-speed paths, but suspect it is much better than before. I would like to thank the folk both at NIC and BBN for their quick response and prompt action on my message. Dave -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Sun, 11-May-86 01:24:27 EDT From: faunt@spar.UUCP (Doug Faunt) To: mod.protocols.tcp-ip Subject: info on cisco
Phone number is 415-326-1941. IP gateway is 1-4 way, currently supports IP/TCP and V.35. Coming soon is T1 and DECNET-IP. Price is $7950 for 2-way IP. Add or subtract $1K for less/more ethernets. Each 2-line v.35 (for muxing high-speed (usually 56Kb) phone lines onto ethernet) interface is $2K. Advantages: has run onder 24 different implementations of IP/TCP and has all boot loaders, servers, and net mgmt. stuff in ROM in the box, so you don't need any other box to do diagnostics or traffic management. Also, the command lang. interface is very good, and nearly everything is user-settable in the config. files. Two levels of password protection on idividual lines to net segments. Fast: 1200 pps burst. For more information, contact cisco or BOSACK@SU-SCORE.ARPA I don't work for cisco, but my boss does.
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-May-86 09:36:00 EDT From: Margulies@SCRC-YUKON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Port Collisions
Folks, This mail is a follow-up to a discussion I had with Jon some weeks ago. We here at Symbolics are concerned with the process of assigning TCP/UDP port numbers. It is not always appropriate for us (and other vendors) to apply for ports in the Czar-controlled first 256 ports. Either because of time constraints or issues of proprietary information, we cannot always write and distribute an RFC for each of our protocols. We have had complaints from customers that we are not the only vendor using the `any private file proctocol' port. We need a way to define new protocols without feat of collision with other people. We see two possibilities: 1) A registry of ports for private protocols. Symbolics would be willing to administer a simple registry for a group of ports outside the first 256. We (or someone else, it matters not) would keep a list, and anyone from an identifiable organization could ask for ports. The registrar's only function would be to hand out each such port only once. It would be helpful, of course, if the official RFC's for TCP/UDP would designate the group of ports involved as reserved for use through this registry. 2) A new protocol that would vastly increase the effective namespace by multiplexing ports. For example, a port that the user side connects to and sends an arbitrary (or at least a reasonably long) character string specifying the service desired. Some obvious use of prefixes or suffices would suffice to avoid collisions. --benson
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 13 May 1986 18:38-PDT From: STJOHNS@SRI-NIC.ARPA To: Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA, postel%usc-isib.arpa@MC.LCS.MIT.EDU Subject: Re: Port Collisions
I am not sure I see the problem here. A "private file protocol" is just that - PRIVATE. It is run between machines that make the assumption that they are all running the same private protocol. Or is there the possibility that one machine is running multiple PRIVATE file protocols? Either a protocol is a network wide standard - implying that is is documented, and that it is designed for at least a minimum of interoperability - or it is private, with little or no public documentation, and with no designed interoperability. In this context, I am talking about global interoperability, not just interoperability between UNIX systems for example. I can see some advantage though in providing some sort of sentinal as part of the PRIVATE protocols to say "I am running FOO as my private protocol, go away if you don't talk FOO". But wouldn't this more properly be part of the protocol? Each protocol should do some confirmation for robustness purposes, right? Mike
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-May-86 17:25:46 EDT From: tef@virginia.CSNET.UUCP To: mod.protocols.tcp-ip Subject: TCP-IP Mailing List
Please add me to the tcp-ip mailing list. Thanks, Todd Fuller tef@uvacs.UUCP *************************************************************************** Todd E. Fuller University of Virginia Dept. of Computer Science Path: ...cbosgd!uvacs!tef ...whuxlm!uvacs!tef ...mcnc!ncsu!uvacs!tef
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 May 86 17:25:46 edt From: Todd Eugene Fuller <tef%virginia.csnet@CSNET-RELAY.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: Subject: TCP-IP Mailing List
Please add me to the tcp-ip mailing list. Thanks, Todd Fuller tef@uvacs.UUCP *************************************************************************** Todd E. Fuller University of Virginia Dept. of Computer Science Path: ...cbosgd!uvacs!tef ...whuxlm!uvacs!tef ...mcnc!ncsu!uvacs!tef
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Tue, 13 May 86 21:22:49 -0400 From: Craig Partridge <craig@loki.bbn.com> To: margulies@scrc-yukon.arpa Cc: tcp-ip@sri-nic.arpa Subject: re: Port Collisions
> We here at Symbolics are concerned with the process of assigning TCP/UDP > port numbers. It is not always appropriate for us (and other vendors) > to apply for ports in the Czar-controlled first 256 ports. Either > because of time constraints or issues of proprietary information, we > cannot always write and distribute an RFC for each of our protocols. Why not make the port numbers used user/site configurable? Berkeley actually did this quite nicely with a services list, which mapped a service name/protocol pair with a port number. Since programs use this database (or are supposed to) to find out what port they are supposed to us, one could run SMTP on TCP port 25 on the Internet but port 243 on some private network if one so chose. The advantage is the vendor need not necessarily worry about what port you pick for your special application -- it can always be changed among cooperating machines. Craig Partridge CSNET Technical Staff
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-May-86 21:38:00 EDT From: STJOHNS@SRI-NIC.ARPA To: mod.protocols.tcp-ip Subject: Re: Port Collisions
I am not sure I see the problem here. A "private file protocol" is just that - PRIVATE. It is run between machines that make the assumption that they are all running the same private protocol. Or is there the possibility that one machine is running multiple PRIVATE file protocols? Either a protocol is a network wide standard - implying that is is documented, and that it is designed for at least a minimum of interoperability - or it is private, with little or no public documentation, and with no designed interoperability. In this context, I am talking about global interoperability, not just interoperability between UNIX systems for example. I can see some advantage though in providing some sort of sentinal as part of the PRIVATE protocols to say "I am running FOO as my private protocol, go away if you don't talk FOO". But wouldn't this more properly be part of the protocol? Each protocol should do some confirmation for robustness purposes, right? Mike
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-May-86 22:13:00 EDT From: CERF@USC-ISI.ARPA.UUCP To: mod.protocols.tcp-ip Subject: C implementations of TCP/IP
Are there any public domain implementations of TCP/IP written in C which are readily accessible? With documentation? Many thanks, Vint Cerf
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 13 May 1986 22:13-EDT From: CERF@USC-ISI.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: C implementations of TCP/IP
Are there any public domain implementations of TCP/IP written in C which are readily accessible? With documentation? Many thanks, Vint Cerf
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Tue, 13-May-86 22:16:39 EDT From: craig@LOKI.BBN.COM (Craig Partridge) To: mod.protocols.tcp-ip Subject: re: Port Collisions
> We here at Symbolics are concerned with the process of assigning TCP/UDP > port numbers. It is not always appropriate for us (and other vendors) > to apply for ports in the Czar-controlled first 256 ports. Either > because of time constraints or issues of proprietary information, we > cannot always write and distribute an RFC for each of our protocols. Why not make the port numbers used user/site configurable? Berkeley actually did this quite nicely with a services list, which mapped a service name/protocol pair with a port number. Since programs use this database (or are supposed to) to find out what port they are supposed to us, one could run SMTP on TCP port 25 on the Internet but port 243 on some private network if one so chose. The advantage is the vendor need not necessarily worry about what port you pick for your special application -- it can always be changed among cooperating machines. Craig Partridge CSNET Technical Staff
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 05:37:25 EDT From: Murray.pa@XEROX.COM.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
One word of caution.... Xerox managed to get off on the wrong foot in the Ethernet packet type assignment business. If you administer a group of ports, I suggest that the ground rules include publishing a who-to-contact as well as a simple (one line?) description of its function. Otherwise people will flame at you when you won't answer questions. The proprietary aspect might complicate that attitude. I don't think that objection really holds water. It's too easy to look at the bits on an ethernet. I like your second suggestion, but somebody is bound to ignore it because it takes an extra packet to get started.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 07:45:00 EDT From: Margulies@SCRC-YUKON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: 13 May 1986 18:38-PDT
From: STJOHNS@SRI-NIC.ARPA
I am not sure I see the problem here. A "private file protocol"
is just that - PRIVATE. It is run between machines that make the
assumption that they are all running the same private protocol.
Wrong meaning of private. Try the definition `A protocol not published
as an RFC, for any reason whatsoever.'
Or is there the possibility that one machine is running multiple
PRIVATE file protocols?
Exactly. Symbolics has a 'private' file protocol. One of our customers
wanted to teach their lisp machine to talk someone elses 'private' file
protocol. Unfortunately, they were on the same port. This situation is
typical, and likely to happen again and again.
Either a protocol is a network wide standard - implying that is
is documented, and that it is designed for at least a minimum of
interoperability - or it is private, with little or no public
documentation, and with no designed interoperability. In this
context, I am talking about global interoperability, not just
interoperability between UNIX systems for example.
The problem is with the phrase `network-wide standard'. The number
czar only designates protocols as `network-wide standards' as part of
the activity of the internet research community (I'm paraphrasing Jon
Postel, and I hope that I'm getting it right). That is not to say that
vendors cannot offer protcols for inclusion in the global set. However,
it is often not practical for us to do so. We can't always afford the
time to document the protocol for the community, which is a pretty-near
necessart for inclusion in the global protocol set.
Anyway, I don't think that your simple division of the world into Public
and Private is good enough. I think that things are more complex.
First, there is an extensive gray area between officially blessed
protocols (global interoperability) and protocols that are private hacks
amongst a small number of cooperative machines (no interoperability).
As a commercial vendor, we are concerned with orderly partial
inter-operability. If Berkley has established a 'private' Unix TCP
protocol, it is very likely that sooner or later someone with a lisp
machine (or something else non-Unix) will want to talk that protocol to
a Unix. That dosen't necessarily qualify the protocol as a network-wide
standard, but gives a good reason for us to avoid port collisions.
Second, even if I were implementing a protocol that would only be used
at one site amongst three machines, I would like some assurance that I
won't find out next week that some vendor is using the port that I chose
for some protocol that I am interested in using.
I can see some advantage though in providing some sort of
sentinal as part of the PRIVATE protocols to say "I am running
FOO as my private protocol, go away if you don't talk FOO". But
wouldn't this more properly be part of the protocol? Each
protocol should do some confirmation for robustness purposes,
right?
Indeed, its not hard to say `sorry, you can't talk to him, because he's
doing something else over that port.' Cold comfort if your goal is to
talk to him.
Mike
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 07:49:00 EDT From: Margulies@SCRC-YUKON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed, 14 May 86 02:37:25 PDT
From: Murray.pa@Xerox.COM
One word of caution.... Xerox managed to get off on the wrong foot in
the Ethernet packet type assignment business.
If you administer a group of ports, I suggest that the ground rules
include publishing a who-to-contact as well as a simple (one line?)
description of its function. Otherwise people will flame at you when you
won't answer questions.
Fine with me.
The proprietary aspect might complicate that attitude. I don't think
that objection really holds water. It's too easy to look at the bits on
an ethernet.
I expect that proprietary protocols will be fairly rare. Mostly, I
expect that people just won't have the time or inclination to document.
I really cannot see why someone would insist on a listing of `Foobar
Company proprietary protocol 1'.
I like your second suggestion, but somebody is bound to ignore it
because it takes an extra packet to get started.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 11:07:00 EDT From: DCP@SCRC-QUABBIN.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed, 14 May 86 02:37:25 PDT
From: Murray.pa@Xerox.COM
I like your second suggestion, but somebody is bound to ignore it
because it takes an extra packet to get started.
For reference, I suggest people read the documentation for the CHAOSNET
protocol, MIT A.I. Memo 628. Basically, CHAOSNET wins in the connection
initiation methodology and the IP-class of protocols lose. Small fields
(read: numbers) that require a number czar make ease of extension very
difficult. In chaos it is easy to say "I want to invent a protocol
called RESET-TIME-SERVER" because the name of the protocol can also be
the contact name used in the RFC (SYN, for TCP folks).
I have a feeling TP4 loses in this respect as well.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 14 May 1986 15:05:06 PDT From: POSTEL@USC-ISIB.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: port collisions
Hi. The number czar is primarily interested in having the protocols assigned ports from the reserved space (numbers 0 through 255) be documented and public. It does not really matter much if the protocol is developed for academic internet research or practical commercial use. It does matter that there be some good reason for the protocol and that there be some evidience that some work was actually done on the protocol. The number czar dislikes assigning numbers on speculation (that is, tends to turn down requests of the form "I might write some protocols, give me a bunch of port numbers"). There are already a few assignments for essentially private protocols (some that would not be made today), but in most of these recent cases the developer was able to send the czar some description of the protocol. One of the great things about the Internet is that is an "open system", and what that means is that the protocols are public. Over and over the czar has seen people develop some little hack protocol for their own private use that turns out to be a neat thing and other people want to use it too but it is not documented. If there really is a need for a set of port numbers to be assigned to individuals or companies for private use, the number czar is perfectly happy to do the work of keeping track of who owns which numbers and giving the next available number to the next requestor. If this is a thing we want to do what part of the port number space should be allocated to this? How many numbers should be set aside for this type of assignment? What is the impact on existing programs and systems? Is anyone using the numbers that will suddenly be off limits by this this reservation of part of the port number space? Or if the other suggestion is followed (to have a port assigned for a multiplexing service based on a character string argument), the number czar is happy to keep the list of unique (initial) strings and who is the contact person. --jon. -------
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 13:01:46 EDT From: PATTERSON@BLUE.RUTGERS.EDU.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Yes, but then you have collision problems with protocol names. Most people would use acronyms, not word-by-word forms. You still need a Socket Czar, only now sockets have a (reasonably) human-understandable format (i.e TELNET instead of 23.) Ross Patterson Center for Computer and Information Services Rutgers University -------
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 13:47:27 EDT From: braden@ISI-BRADEN.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
It sounds like another version of the SNA/DECNET free-enterprise protocol wars. Do you think we should encourage the proliferation of private protocols, many of them doing the same things? It is clearly in the national interest (that's us, friends) to promote maximal interconnection of heterogeneous systems. That is what standards are for. Until recently, in England there were several different standards for electric plugs, because each of the 19th century power barons designed their own. So you bought an appliance with a cord but no plug on the end, and added the plug necessary for your outlet. Rather like a configuration file, isn't it? As a customer, do you think I should buy a software system from a vendor that did not have the resources to properly document its internal function? I wonder what kind of maintenance and support I will get with that product.
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 14 May 1986 14:56:02 CDT From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]
Anybody know where one of these monsters is?
Darrel
---------------
Return-Path: <domiller@lognet2.ARPA>
Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT
Return-Path: <domiller@lognet2.ARPA>
Received: by lognet2.ARPA
id AA11563; Tue, 13 May 86 11:15:36 edt
Message-Id: <8605131515.AA11563@lognet2.ARPA>
Date: Tue May 13 11:15:33 1986
From: domiller@lognet2.ARPA (Donald G. Miller)
Subject: HP 3000
To: afddn.beach@gunter-adam
Status: N
Is there anyone on the DDN with full suite or working a full
suite on an HP 3000???? If so can you give me a POC?? tks don m
-------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 14:36:00 EDT From: DCP@SCRC-QUABBIN.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: 14 May 86 13:01:46 EDT
From: Ross Patterson <PATTERSON@BLUE.RUTGERS.EDU>
Yes, but then you have collision problems with protocol names. Most people
would use acronyms, not word-by-word forms. You still need a Socket Czar,
only now sockets have a (reasonably) human-understandable format (i.e TELNET
instead of 23.)
Go read Benson's message again. He said that private protocols would be
rather long contact names, possibly including the vendor/entity that
implemented it as part of the name. People who use short names or
acronyms are anti-social. Standard contact-names that correspond to
RFCs could still be administered by a Czar, e.g., TELNET, SUPDUP, ECHO,
but private protocols would have names like SYMBOLICS-NFILE.
Benson and I have already colided, AND WE'RE ON THE SAME FLOOR OF THE
SAME BUILDING OF THE SAME COMPANY. Since numbers don't mean anything,
we both happened to pick 666 for our private port number.
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 14 May 1986 at 1437-EDT From: hsw at TYCHO.ARPA (Howard Weiss) To: cerf at isi Cc: tcp-ip at nic Subject: re: C implementations of TCP/IP
Vint, I have a version of TCP/IP that was written by BBN under DCA sponsorship. This version was written in C and runs on V6 UNIX. There is some documentation and it currently runs on the internet at both our site and at DCEC. Also, this is the version that Honeywell converted to run on the SCOMP. Howard Weiss National Computer Security Center (301) 859-4491 -------
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 14:45:00 EDT From: Margulies@SCRC-YUKON.ARPA (Benson I. Margulies) To: mod.protocols.tcp-ip Subject: re: Port Collisions
Date: Tue, 13 May 86 21:22:49 -0400
From: Craig Partridge <craig@loki.bbn.COM>
> We here at Symbolics are concerned with the process of assigning TCP/UDP
> port numbers. It is not always appropriate for us (and other vendors)
> to apply for ports in the Czar-controlled first 256 ports. Either
> because of time constraints or issues of proprietary information, we
> cannot always write and distribute an RFC for each of our protocols.
Why not make the port numbers used user/site configurable? Berkeley
actually did this quite nicely with a services list, which mapped
a service name/protocol pair with a port number. Since programs
use this database (or are supposed to) to find out what port they
are supposed to us, one could run SMTP on TCP port 25 on the Internet
but port 243 on some private network if one so chose.
We believe in 'plug-in-and-play' software. Expecting not-very-savy
users to figure out the port usage of all the various programs they are
using is a big expectation.
What if two sites disagree on the port for a protocol? They will never
be able to inter-operate!
We have logical services and protocols that are mapped to ports. The
only way to make that do what you want is to use a different protocol
name for each port assignment in use anyplace, so that the database of
hosts can indicate which hosts are going to talk over which ports. This
is an unreasonable burden.
The advantage is the vendor need not necessarily worry about what
port you pick for your special application -- it can always be
changed among cooperating machines.
Its the vendor's job to worry so the user dosen't have to.
Craig Partridge
CSNET Technical Staff
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 14:52:00 EDT From: Margulies@SCRC-YUKON.ARPA (Benson I. Margulies) To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed, 14 May 86 10:47:27 PDT
From: braden@isi-braden.arpa (Bob Braden)
It sounds like another version of the SNA/DECNET free-enterprise protocol
wars.
Do you think we should encourage the proliferation of private protocols,
many of them doing the same things? It is clearly in the national
interest (that's us, friends) to promote maximal interconnection of
heterogeneous systems. That is what standards are for.
Not all protocols are suitable for standardization. Sometimes, there
isn't enough knowledge in the industry to settle on a standard. We
can't be expected to wait around.
Some protocols perform very specific functions that are pointless to
standardize. Heavily networked products are very likely to involve
network protocols that are not useful outside a particular application.
Yet these have to have ports, and those ports can't conflict with other,
interoperating protocols.
Until recently, in England there were several different standards for
electric plugs, because each of the 19th century power barons designed
their own. So you bought an appliance with a cord but no plug on the
end, and added the plug necessary for your outlet. Rather like a
configuration file, isn't it?
This is why I'm opposed to the configuration file solution.
As a customer, do you think I should buy a software system from a vendor
that did not have the resources to properly document its internal function?
I wonder what kind of maintenance and support I will get with that product.
The statement `did not have the resources' is not a realistic view. As a
customer, I'd rather my vendor spent their (my) money on supporting me,
not informing the internet community about the network protocols in
their product.
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 15:30:04 EDT From: MRC%PANDA@SUMEX-AIM.ARPA (Mark Crispin) To: mod.protocols.tcp-ip Subject: private/proprietary protocols
Personally, I think that proprietary protocols have no place in the Internet research/military community. They are absolutely not in the best interest of US national defense. Quite enough problems exist because the UUCP protocol is AT&T proprietary. As a software vendor, I sympathize with the need for trade secret and other forms of software protection. However, a deliberate attempt to lock out interoperability with other vendors' products is bad for the customer and ultimately bad for the vendor. Private protocols should be discouraged as much as possible. If a protocol is useful enough to consume part of the Internet namespace, it is useful enough to be documented for the rest of the Internet community. My feeling is that if there MUST be a private protocol assignment it should be "one port per organization", and that organization should make some arrangement to identify which of their private protocols they way (e.g. the first octet from the user agent identifies "MIT protocol #n", or "Symbolics protocol #n", etc.) I have occasionally been frustrated with the delays and paperwork involved in getting numbers assigned by Postel, but at the same time I feel these procedures are necessary. If anything, Jon has erred on the side of giving out a number in questionable circumstances. I vote to keep the current procedure; if it ain't broke don't fix it. -- Mark -- -------
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 15:56:02 EDT From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: mod.protocols.tcp-ip Subject: [domiller@lognet2.ARPA (Donald G. Miller): HP 3000]
Anybody know where one of these monsters is?
Darrel
---------------
Return-Path: <domiller@lognet2.ARPA>
Received: FROM LOGNET2.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 13 May 86 10:15:45 CDT
Return-Path: <domiller@lognet2.ARPA>
Received: by lognet2.ARPA
id AA11563; Tue, 13 May 86 11:15:36 edt
Message-Id: <8605131515.AA11563@lognet2.ARPA>
Date: Tue May 13 11:15:33 1986
From: domiller@lognet2.ARPA (Donald G. Miller)
Subject: HP 3000
To: afddn.beach@gunter-adam
Status: N
Is there anyone on the DDN with full suite or working a full
suite on an HP 3000???? If so can you give me a POC?? tks don m
-------
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 18:05:06 EDT From: POSTEL@USC-ISIB.ARPA To: mod.protocols.tcp-ip Subject: re: port collisions
Hi. The number czar is primarily interested in having the protocols assigned ports from the reserved space (numbers 0 through 255) be documented and public. It does not really matter much if the protocol is developed for academic internet research or practical commercial use. It does matter that there be some good reason for the protocol and that there be some evidience that some work was actually done on the protocol. The number czar dislikes assigning numbers on speculation (that is, tends to turn down requests of the form "I might write some protocols, give me a bunch of port numbers"). There are already a few assignments for essentially private protocols (some that would not be made today), but in most of these recent cases the developer was able to send the czar some description of the protocol. One of the great things about the Internet is that is an "open system", and what that means is that the protocols are public. Over and over the czar has seen people develop some little hack protocol for their own private use that turns out to be a neat thing and other people want to use it too but it is not documented. If there really is a need for a set of port numbers to be assigned to individuals or companies for private use, the number czar is perfectly happy to do the work of keeping track of who owns which numbers and giving the next available number to the next requestor. If this is a thing we want to do what part of the port number space should be allocated to this? How many numbers should be set aside for this type of assignment? What is the impact on existing programs and systems? Is anyone using the numbers that will suddenly be off limits by this this reservation of part of the port number space? Or if the other suggestion is followed (to have a port assigned for a multiplexing service based on a character string argument), the number czar is happy to keep the list of unique (initial) strings and who is the contact person. --jon. -------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 18:23:00 EDT From: SRA@XX.LCS.MIT.EDU (Rob Austein) To: mod.protocols.tcp-ip Subject: Port Collisions
The collision problem with protocol names is not as severe as the with (small) protocol numbers. People implementing private applications tend to use ports in the low 500s (or working down from 1024), so there is a fair chance that there will eventually be conflicts. Whereas I doubt that Symbolics would have much trouble testing a new service named "SYMBOLICS-PRIVATE-PROTOCOL-XYZ-PRIME". When a protocol becomes well enough known and widely enough used that it needs a short snappy name, -then- you go talk to the Socket Czar. --Rob
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 19:43:02 EDT From: karels@MONET.BERKELEY.EDU (Mike Karels) To: mod.protocols.tcp-ip Subject: Re: C implementations of TCP/IP
The Berkeley 4.2/4.3BSD TCP/IP code is written in C. It's not quite public domain (it is copyright by the university), but the only restriction on its use is that the University of California be credited. Mike
-----------[000056][next][prev][last][first]----------------------------------------------------
Date: Wed, 14-May-86 19:54:03 EDT
From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
To: mod.protocols.tcp-ip
Subject: Re: Port CollisionsRight. What happens if you pick a name for your private protocol that happens to be exactly the same as the name someone else picked for their private protocol? You are merely using strings instead of numbers; the same problems can happen. The set of possible identifiers is still pretty small, if people use descriptive english words for services. Now, if you preface all your private services with some personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then maybe you have a valid point. Noel -------
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 21:15:44 EDT From: hsw@TYCHO.ARPA (Howard Weiss) To: mod.protocols.tcp-ip Subject: re: C implementations of TCP/IP
Vint, I have a version of TCP/IP that was written by BBN under DCA sponsorship. This version was written in C and runs on V6 UNIX. There is some documentation and it currently runs on the internet at both our site and at DCEC. Also, this is the version that Honeywell converted to run on the SCOMP. Howard Weiss National Computer Security Center (301) 859-4491 -------
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 22:09:00 EDT From: DCP@SCRC-QUABBIN.ARPA (David C. Plummer) To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed, 14 May 86 10:47:27 PDT
From: braden@isi-braden.arpa (Bob Braden)
It sounds like another version of the SNA/DECNET free-enterprise protocol
wars.
Do you think we should encourage the proliferation of private protocols,
many of them doing the same things? It is clearly in the national
interest (that's us, friends) to promote maximal interconnection of
heterogeneous systems. That is what standards are for.
Until recently, in England there were several different standards for
electric plugs, because each of the 19th century power barons designed
their own. So you bought an appliance with a cord but no plug on the
end, and added the plug necessary for your outlet. Rather like a
configuration file, isn't it?
As a customer, do you think I should buy a software system from a vendor
that did not have the resources to properly document its internal function?
I wonder what kind of maintenance and support I will get with that product.
Example. Symbolics calls its current "private file protocol" NFILE. It
is currently documented in the Release 6.1 Release Notes. We know it to
be far superior to TCP/FTP and pervious file protocols on Lisp Machines.
NFILE is a true file ACCESS protocol as oposed to FTP which is a
transfer protocol. Back then we weren't ready to tout it to the rest of
the world. I'm still not sure we are. The reasons are many. We aren't
sure it is really sufficient. We do know that there are some very
complex operations in it because of the need to handle aborting out of
operations correctly. The generic-file-system model it assumes may not
fit in well with all known system. We also fear that many people will
not understand the need for some of the complexity and will either want
it thrown out because they can't figure out how to implement it, or
won't implement the parts without telling people. (Need I remind people
that Unix TCP/FTP still sends the wrong code for the DELETE operation, I
believe it is.) Companies may be willing to document their protocols to
let others experiment with them. They may not be prepared to solidify
on it or to change it to the whims of the masses. If NFILE replaced
TCP/FTP as the Internet standard, and if we discovered some other
feature that is rather crucial to our system, we would be in the same
ballpark as we are now: a private protocol.
There are sometimes some good reasons not to push private protocols as
standards until all the conditions are right, even though those private
protocols are documented and provide superior functionality.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Wed, 14-May-86 22:28:00 EDT From: JSOL@BUCS20.BU.EDU.UUCP To: mod.protocols.tcp-ip Subject: Documenting locally defined protocols
I want to point out that there's a difference between internally (to a company) documenting protocols and reporting those protocols back to the Internet via a RFC. --jsol
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: Wed, 14 May 1986 22:28 EDT From: Jon Solomon <JSOL@BUCS20.BU.EDU> To: tcp-ip@sri-nic.arpa Subject: Documenting locally defined protocols
I want to point out that there's a difference between internally (to a company) documenting protocols and reporting those protocols back to the Internet via a RFC. --jsol
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 01:29:57 EDT From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) To: mod.protocols.tcp-ip Subject: Re: Port Collisions
If your argument is:
"having a port space of 512 distinct addresses is too small"
then I doubt anyone dis-agrees in principle. On the other hand, if
your argument is:
"Benson and I, working on the floor for the same company,
collided, so the port space is too small"
Then your argument points more to a possible (mis)management problem
in your company than a port scarcity problem!
Let's face it, 512 distinct addresses for ports probably is too
small for the totality of applications that can/could use TCP. I
don't think it's too small any given group of co-operating sites
using TCP, though I could be convinced otherwise.
Personally, I like the Berkeley method since you can just define
some numbers to meet your needs. I'm not so keen on using strings
or datastructures as port identifiers, though I'm sure, when ISO
gets around to defining the port space for TS-users, they'll be sure
to add an option for regular expressions, mandelbrots, etc. (-:
/mtr
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 03:19:37 EDT From: dpk@mcvax.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
I like the idea of the "multiplexing port". Consider this one vote for it. -Doug-
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 07:49:00 EDT From: Margulies@SCRC-YUKON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed 14 May 86 19:54:03-EDT
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Right. What happens if you pick a name for your private
protocol that happens to be exactly the same as the name someone else
picked for their private protocol? You are merely using strings
instead of numbers; the same problems can happen. The set of possible
identifiers is still pretty small, if people use descriptive english
words for services.
Now, if you preface all your private services with some
personal string, e.g. 'SYMBOLICS-', as in 'SYMBOLICS-NEW-FILE' then
maybe you have a valid point.
That is exactly my plan.
Noel
-------
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 08:03:00 EDT From: Margulies@SCRC-YUKON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
From: Doug Kingston <mcvax!dpk@seismo.CSS.GOV>
I like the idea of the "multiplexing port". Consider this one
vote for it.
-Doug-
well, so do I. However, for it to be a workable solution, there has to
be some commitment that it won't be a member of the large `ignored RFC'
collection. I think that we need a registry to tide us over in the
interim.
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Thu, 15 May 1986 12:22 EST From: Gary D. Twiraga <GARY%HARVARDA.BITNET@WISCVM.WISC.EDU> To: <TCP-IP@SRI-NIC.ARPA>
please take my name off your mailing list....
thank
gary at harvarda.bitnet
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 15 May 86 14:28 PDT From: Jeff Makey <Makey@LOGICON.ARPA>, Tom Perrine <tom@LOGICON.ARPA> To: tcp-ip@sri-nic Cc: Tom Perrine <tom@logicon.arpa>, Jeff Makey <Makey@logicon.arpa> Subject: Redirect wars and Buterfly gateways
This month's issue (May) of "Mini-Micro Systems" has a blurb in the "Breakpoints" section (page 20) about a system called "Monarch", from BBN Laboratories which will have 8,192 parallel processors of an undisclosed type. In the paragraph they mention that, for those who can't wait for Monarch, BBN is shipping something called the "Butterfly" system consisting of 256 Motorola MC68020 processors working in parallel. Is this any relation to the much-alluded-to "Butterfly gateway" which is supposed to save us from the ravages of brain-dead gateways? Speaking of brain-dead gateways, we have had some more instances of the ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened 11 times in 29 seconds while trying to establish a connection. A reponse came in 23 seconds, but after we had timed out. Obviously this is sub-optimal... Tom Perrine & Jeff Makey
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 11:58:00 EDT From: DCP@SCRC-QUABBIN.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
Date: Wed, 14 May 86 17:46:32 -0700
From: Marshall Rose <mrose@nrtc-gremlin>
If your argument is:
"having a port space of 512 distinct addresses is too small"
then I doubt anyone dis-agrees in principle. On the other hand, if
your argument is:
"Benson and I, working on the floor for the same company,
collided, so the port space is too small"
Then your argument points more to a possible (mis)management problem
in your company than a port scarcity problem!
We were both doing independent, exploratory research of completley
unrelated problem domains. Maybe we should have a number czar that is
on call 24 hours a day in case somebody has a hack attack at 9:30pm (or
3am) and needs a protocol number in 5 minutes. Because my application
was stream oriented it works over TCP and CHAOS. I didn't have any
problem with Chaos because my protocol was called MANDELBROT and
Benson's was completely different.
Let's face it, 512 distinct addresses for ports probably is too
small for the totality of applications that can/could use TCP. I
don't think it's too small any given group of co-operating sites
using TCP, though I could be convinced otherwise.
Here is a list of protocols that we use at Symbolics. Some are trivial.
Some work over TCP and have RFCs. All are (or were at one time or
another) useful, but not critical. Sorry to bother everybody with this
list, but it shows that one company has several protocols that are not
all RFCs. I don't think any of the ones below are considered
proprietary. That's 32+ protocols we have use for. If 16 companies or
groups or implementations each have 32 different protocols, we would (a)
have a tower of Babel, and (b) run out of the 512 port numbers. The
tower of Babel might be needed. For example, what machines other than
Suns can use the Sun net-paging protocol?
"MANDELBROT" My network mandelbrot protocol and is Lisp only
(it actually sends Lisp forms)
"SEND" Interactive messages (ancient)
"CONVERSE" Interactive messages, done much better
"SMTP" (It's a byte stream protocol)
"EXPAND-MAILING-LIST" (ditto)
"ECHO" I think these have TCP equivalents
"BABEL"
"TIME"
"NAME"
"MAIL" Chaos version
"UPTIME" Similar to TIME
"QFILE" (old) LispM file protocol
"NFILE" new one
"FINGER" Similar to NAME, but simpler in ways
"DOMAIN" The internet domain resolver stuff
"NAMESPACE" Our own namespace stuff, written before the RFC
"NAMESPACE-TIMESTAMP" for domains came out, and in some of our
"WHO-AM-I" opinions, superior
"TELNET" Specified in an RFC
"SUPDUP" Specified in an RFC
"TELSUP" A mixture of the two
"TTYLINK" "raw" linking; no protocol. useful for connecting to Unix
"3600-LOGIN" Better than all the above for talking to 3600s
"PRINTER-QUEUE" Various printer queue operations
"LGP-STATUS"
"LGP"
"LGP-QUEUE"
"DOVER"
"DOVER-STATUS"
"CONFIGURATION" Various other useful protocols
"RESET-TIME-SERVER" For machines whose clocks are off
"TCP" To connect to TCP streams through a protocol gateway
"NOTIFY" Information dispersal
"STATUS" Network status
"DUMP-ROUTING-TABLE" Topology debugging
"RTAPE" Remote Tape facility
Personally, I like the Berkeley method since you can just define
some numbers to meet your needs. I'm not so keen on using strings
or datastructures as port identifiers, though I'm sure, when ISO
gets around to defining the port space for TS-users, they'll be sure
to add an option for regular expressions, mandelbrots, etc. (-:
/mtr
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 12:04:14 EDT From: root@BU-CS.BU.EDU.UUCP To: mod.protocols.tcp-ip Subject: re: port collisions
I think there is a problem here. Due to obvious security reasons many of these protocols will need a low socket number and there are only 255 of those guaranteed to be available (UNIX extends that to 1023 but I don't think everyone can honor that.) Some small portion of that is already in use and if commercial trends continue I suspect many, many vendors will need a *secure* port for their products. The only solution I can think of is a super-server protocol which would listen on a single secure port and map strings to available non-secure ports indirectly (I believe the TOPS-20 IPC works something like this.) I've thought about it a few hours and it's not easy, especially when you start to take different TCP implementations into account (how exactly do I reserve and "hand-off" a port number between two unrelated processes? that's an O/S issue but I fear not generally easy.) Doesn't SUN's RPC (which I believe is in the public domain) address this issue (no pun intended)? If you say "do you seriously expect me to implement RPC and XDR just to get a port number?", I sympathize, I was only trying to find analogues for enlightenment. -Barry Shein, Boston University
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 13:22:00 EDT From: GARY@HARVARDA.BITNET.UUCP To: mod.protocols.tcp-ip Subject: (none)
please take my name off your mailing list....
thank
gary at harvarda.bitnet
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Thu 15 May 86 17:31:54-PDT From: MULHERN@SRI-KL.ARPA To: braden@ISI-BRADEN.ARPA Cc: Margulies@SCRC-YUKON.ARPA, Murray.pa@XEROX.COM, postel@USC-ISI.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Port Collisions
I did work for Jon Brommeland at NAVELEX Vallejo which was sponsored by PDW-120. He did not let us contact 120 directly, and the Vallejo involvement did not turn out well, but I (and several others here) learned much about 120's systems -- NWSS, FHLT,HLT,OBS, OBU, IID, STT/TDCS and ISE. Our task was to design a local network for the 120 testbed at Patuxent River. We also reviewed the initial specifications for OBU (non-black world). This work was completed in 82/83. -------
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 16:16:44 EDT From: dab@BORAX.LCS.MIT.EDU.UUCP To: mod.protocols.tcp-ip Subject: port collisions
Date: Thu, 15 May 86 12:04:14 EDT From: Ra <root@BU-CS.BU.EDU> I think there is a problem here. Due to obvious security reasons many of these protocols will need a low socket number and there are only 255 of those guaranteed to be available (UNIX extends that to 1023 but I don't think everyone can honor that.) Some small portion of that is already in use and if commercial trends continue I suspect many, many vendors will need a *secure* port for their products. -Barry Shein, Boston University As far as I've found, this belief that some ports are secure while others aren't is only implemented by Berkekley Unix. Since other IP implementations do not necessarily honor this belief, there is no security in using *secure* ports unless your network consists exclusively of machines running Berkelely Unix. David Bridgham
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 17:28:00 EDT From: tom@LOGICON.ARPA.UUCP To: mod.protocols.tcp-ip Subject: Redirect wars and Buterfly gateways
This month's issue (May) of "Mini-Micro Systems" has a blurb in the "Breakpoints" section (page 20) about a system called "Monarch", from BBN Laboratories which will have 8,192 parallel processors of an undisclosed type. In the paragraph they mention that, for those who can't wait for Monarch, BBN is shipping something called the "Butterfly" system consisting of 256 Motorola MC68020 processors working in parallel. Is this any relation to the much-alluded-to "Butterfly gateway" which is supposed to save us from the ravages of brain-dead gateways? Speaking of brain-dead gateways, we have had some more instances of the ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened 11 times in 29 seconds while trying to establish a connection. A reponse came in 23 seconds, but after we had timed out. Obviously this is sub-optimal... Tom Perrine & Jeff Makey
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 19:29:35 EDT From: mrose@nrtc-gremlin.UUCP To: mod.protocols.tcp-ip Subject: Re: Port Collisions
The obviously problem with a "multiplexing port" is that you can no
longer tell by looking at the TCB what protocol is being spoken.
This renders programs like netstat on BSD UNIX, et. al., pretty
much worthless. If we're going to expand the port space somehow, I
vote we do it explicitly in the TCP headers, so it's part of the
information in the TCB, rather than expand the port space covertly
by exchanging the information in the TCP data.
/mtr
ps: of course, this is the exact opposite of what we did in rfc973
(iso transport on top of the tcp), primarily because I thought 1)
keeping track of the numbers, if there ever were numbers, should be
separate from the tcp port space, since the protocols probably
weren't going to look anything like our good old ARM-style protocols
; and, 2), there's a good chance that we'd need more than 512 port
numbers in the next three-five years. To postpone that problem, 4K
port numbers were reserved; presumably, though I didn't think about
it, 2K of those are for "private" use.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Thu, 15-May-86 19:58:31 EDT From: geof@imagen.UUCP.UUCP To: mod.protocols.tcp-ip Subject: Re: C implementations of TCP/IP
Two from MIT that I know of:
- The MIT PC/IP software for the IBM-PC.
- The V6 Unix TCP/IP software written by Liza Martin at MIT.
The alto implementation (BCPL) is also available; pieces of each of
the unix packages are direct translations to C of the alto code.
Both the MIT packages should be available from someone at the systems
group at MIT. The only appropriate person I know of who is still
(sort of) in the systems group is Jerry Saltzer.
In the meantime, here is an implementation of TCP that I wrote and
am willing to put in the public domain. I call it "tinytcp" after
"tinybasic" and "tiny-c" -- it's a very simple TCP that accomodates
a busywaiting style of coding. We use it here at Imagen to allow
us to boot our image processors using arpa-ftp. There are one or
two nasty hacks in the code. The worst hack is that big-endian
byte ordering is assumed. Please send flames about such hacks to
/dev/null. But report any bugs to me.
- Geof
---------------CUT HERE------------------------------------------------
#!/bin/sh
: "This is a shell archive, meaning: "
: "1. Remove everything above the #! /bin/sh line. "
: "2. Save the resulting test in a file. "
: "3. Execute the file with /bin/sh (not csh) to create the files:"
: " README"
: " arp.c"
: " sed.c"
: " sed.h"
: " tinyftp.c"
: " tinytcp.c"
: " tinytcp.h"
: "This archive created: Thu May 15 16:43:07 PDT 1986 "
echo file: README
sed 's/^X//' >README << 'END-of-README'
X
X TinyTcp Public Domain Release
X
XThe files in this release contain a simple implementation of
XTCP & FTP, suitable for burning into ROM. It is, in effect,
Xa big hack put together in two or three days. It works for
Xus, though, and you might like it, too. Warning: the code
Xwas intended for a 68000, and doesn't have any byte swapping
Xsupport in it. Shouldn't be too hard to add, though.
X
X - Geof Cooper
X Imagen Corporation
X [imagen!geof@decwrl.dec.com]
X April 16, 1986
X
XThe package requires some system support:
X
X clock_ValueRough() - should be a procedure that returns the current
X value of a millisecond clock. The procedure is called frequently,
X so that interrupts are not needed to service the clock. Our
X implementation polls the real time timer and assumes that it is
X called frequently enough so that it doesn't miss clock ticks (Since
X the timer is only used for network timeouts, it doesn't really matter
X if it does miss clock ticks, of course). Systems without a clock
X could probably get by with a procedure that increments a static
X variable and returns it, by adjusting the timeout constants in the
X program.
X
X Network driver - some network interface driver is needed. A driver for a
X 3Com multibus (ethernet) board is included; this board isn't made anymore
X (at least not by 3Com), so you'll probably need to write a driver for the
X board in your system.
X
X
XGuide to source files:
X
X sed.c - Simple Ethernet Driver - Driver for 3Com multibus card. If you
X have another type of Ethernet board, you can use this driver as
X a template.
X
X sed.h - header file for the above.
X
X arp.c - Implementation of Address Resolution Protocol. Note that there
X is no arp "mapping" per se. The higher level code (tcp, in this case)
X is required to keep track of internet and ethernet addresses.
X
X tinytcp.c - Implementation of TCP.
X
X tinytcp.h - Header file for above, and for everything else.
X
X tinyftp.c - Implementation of FTP, only allows files to be retrieved, not sent.
END-of-README
echo file: arp.c
sed 's/^X//' >arp.c << 'END-of-arp.c'
X/*
X * SAR: Simple Address Resolution Protocol Implementation
X * Written by Geoffrey Cooper, September 27, 1983
X *
X * This package implements a very simple version of the Plummer Address
X * Resolution Protocol (RFC 826). It allows clients to resolve Internet
X * addresses into Ethernet addresses, and knows how to respond to an
X * address resolution request (when the transmit buffer is free).
X *
X * Routines:
X *
X * sar_CheckPacket( pb ) => 1, if ARP packet and processed, 0 otherwise
X * sar_MapIn2Eth( ina, ethap ) => 1 if did it, 0 if couldn't.
X *
X * Copyright (C) 1983, 1986 IMAGEN Corporation
X * "This code may be duplicated in whole or in part provided that [1] there
X * is no commercial gain involved in the duplication, and [2] that this
X * copyright notice is preserved on all copies. Any other duplication
X * requires written notice of the author."
X *
X */
X#include "tinytcp.h"
X
Xsar_CheckPacket(ap)
X register arp_Header *ap;
X{
X register arp_Header *op;
X
X if ( ap->hwType != arp_TypeEther || /* have ethernet hardware, */
X ap->protType != 0x800 || /* and internet software, */
X ap->opcode != ARP_REQUEST || /* and be a resolution req. */
X ap->dstIPAddr != sin_lclINAddr /* for my addr. */
X ) return ( 0 ); /* .... or we ignore it. */
X
X /* format response. */
X op = (arp_Header *)sed_FormatPacket(ap->srcEthAddr, 0x806);
X op->hwType = arp_TypeEther;
X op->protType = 0x800;
X op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress);
X op->opcode = ARP_REPLY;
X op->srcIPAddr = sin_lclINAddr;
X MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress));
X ap->dstIPAddr = op->srcIPAddr;
X MoveW(ap->srcEthAddr, op->dstEthAddr, sizeof(eth_HwAddress));
X
X sed_Send(sizeof(arp_Header));
X
X return ( 1 );
X}
X
X/*
X * Do an address resolution bit.
X */
Xsar_MapIn2Eth(ina, ethap)
X longword ina;
X eth_HwAddress *ethap;
X{
X register arp_Header *op;
X extern in_HwAddress sin_lclINAddr;
X register i;
X longword endTime;
X longword rxMitTime;
X
X sed_Receive( 0 );
X endTime = clock_ValueRough() + 2000;
X while ( endTime > clock_ValueRough() ) {
X op = (arp_Header *)sed_FormatPacket(&sed_ethBcastAddr[0], 0x806);
X op->hwType = arp_TypeEther;
X op->protType = 0x800;
X op->hwProtAddrLen = (sizeof(eth_HwAddress) << 8) + sizeof(in_HwAddress);
X op->opcode = ARP_REQUEST;
X op->srcIPAddr = sin_lclINAddr;
X MoveW(sed_lclEthAddr, op->srcEthAddr, sizeof(eth_HwAddress));
X op->dstIPAddr = ina;
X
X /* ...and send the packet */
X sed_Send( sizeof(arp_Header) );
X
X rxMitTime = clock_ValueRough() + 250;
X while ( rxMitTime > clock_ValueRough() ) {
X op = (arp_Header *)sed_IsPacket();
X if ( op ) {
X if ( sed_CheckPacket(op, 0x806) == 1 &&
X op->protType == 0x800 &&
X op->srcIPAddr == ina &&
X op->opcode == ARP_REPLY ) {
X MoveW(op->srcEthAddr, ethap, sizeof(eth_HwAddress));
X return ( 1 );
X }
X sed_Receive(op);
X }
X }
X }
X return ( 0 );
X}
END-of-arp.c
echo file: sed.c
sed 's/^X//' >sed.c << 'END-of-sed.c'
X/*
X * Ethernet Driver.
X * A Very Simple set of ethernet driver primitives. The ethernet (3com Mbus)
X * interface is controlled by busy-waiting, the application is handed the
X * location of on-board packet buffers, and allowed to fill in the
X * transmit buffer directly. The interface is entirely blocking.
X *
X * Written March, 1986 by Geoffrey Cooper
X *
X * Copyright (C) 1986, IMAGEN Corporation
X * "This code may be duplicated in whole or in part provided that [1] there
X * is no commercial gain involved in the duplication, and [2] that this
X * copyright notice is preserved on all copies. Any other duplication
X * requires written notice of the author."
X *
X * Primitives:
X * sed_Init() -- Initialize the package
X * sed_FormatPacket( destEAddr ) => location of transmit buffer
X * sed_Send( pkLength ) -- send the packet that is in the transmit buffer
X * sed_Receive( recBufLocation ) -- enable receiving packets.
X * sed_IsPacket() => location of packet in receive buffer
X * sed_CheckPacket( recBufLocation, expectedType )
X *
X * Global Variables:
X * sed_lclEthAddr -- Ethernet address of this host.
X * sed_ethBcastAddr -- Ethernet broadcast address.
X */
X
X#include "tinytcp.h"
X#include "sed.h"
X
X#define en10pages ((en10size) >> pageshift)
X
Xoctet *sed_va; /* virtual address of ethernet card */
Xeth_HwAddress sed_lclEthAddr; /* local ethernet address */
Xeth_HwAddress sed_ethBcastAddr; /* Ethernet broadcast address */
XBOOL sed_respondARPreq; /* controls responses to ARP req's */
Xchar bufAinUse, bufBinUse; /* tell whether bufs are in use */
X
X/*
X * Initialize the Ethernet Interface, and this package. Enable input on
X * both buffers.
X */
Xsed_Init()
X{
X int recState;
X register i, j;
X
X recState = 7; /* == mine + broad - errors */
X
X /* Map the Ethernet Interface in, and initialize sed_va */
X sed_va = (octet *)SED3CVA; /* our virtual addr */
X
X /* Map memory for 3Com board (must be 8k boundary) */
X /* INSERT CODE HERE */
X map_ethernet_board();
X
X /* Reset the Ethernet controller */
X MECSR(sed_va) = RESET;
X for (i=0; i<10; i++); /* delay a bit... */
X
X /* just copy on-board ROM to on-board RAM, to use std. address */
X Move(MEAROM(sed_va), sed_lclEthAddr, 6);
X Move(sed_lclEthAddr, MEARAM(sed_va), 6);
X
X MECSR(sed_va) |= AMSW; /* and tell board we did it */
X
X /*
X * and initialize the exported variable which gives the Eth broadcast
X * address, for everyone else to use.
X */
X for (i=0; i<3; i++) sed_ethBcastAddr[i] = 0xFFFF;
X
X /* accept packets addressed for us and broadcast packets */
X
X MECSR(sed_va) = (MECSR(sed_va)&~PA) | recState;
X
X /* declare both buffers in use... */
X bufAinUse = bufBinUse = TRUE;
X
X}
X
X/*
X * Format an ethernet header in the transmit buffer, and say where it is.
X * Note that because of the way the 3Com interface works, we need to know
X * how long the packet is before we know where to put it. The solution is
X * that we format the packet at the BEGINNING of the transmit buffer, and
X * later copy it (carefully) to where it belongs. Another hack would be
X * to be inefficient about the size of the packet to be sent (always send
X * a larger ethernet packet than you need to, but copying should be ok for
X * now.
X */
Xoctet *
Xsed_FormatPacket( destEAddr, ethType )
X register octet *destEAddr;
X{
X register octet *xMitBuf;
X
X xMitBuf = &((octet *)MEXBUF(sed_va))[-0x800];
X Move( destEAddr, xMitBuf, 6 );
X Move( sed_lclEthAddr, xMitBuf + 6, 6 );
X *((short *)(xMitBuf+12)) = ethType;
X return ( xMitBuf+14 );
X}
X
X/*
X * Send a packet out over the ethernet. The packet is sitting at the
X * beginning of the transmit buffer. The routine returns when the
X * packet has been successfully sent.
X */
Xsed_Send( pkLengthInOctets )
X register int pkLengthInOctets;
X{
X register octet *fromO, *toO;
X register pkLength;
X register csr;
X
X pkLengthInOctets += 14; /* account for Ethernet header */
X pkLengthInOctets = (pkLengthInOctets + 1) & (~1);
X
X if (pkLengthInOctets < E10P_MIN)
X pkLengthInOctets = E10P_MIN; /* and min. ethernet len */
X
X /* and copy the packet where it belongs */
X pkLength = pkLengthInOctets;
X fromO = &((octet *)MEXBUF(sed_va))[-0x800] + pkLength;
X toO = ((octet *)MEXBUF(sed_va));
X
X while ( pkLength-- ) *--toO = *--fromO;
X
X /* send the packet */
X
X MEXHDR(sed_va) = 2048 - pkLengthInOctets;
X MECSR(sed_va) |= TBSW;
X
X /* and wait until it has really been sent. */
X
X for (pkLength=0; pkLength < 15; pkLength++) {
X while ( (! ((csr = MECSR(sed_va)) & JAM)) && (csr & TBSW) )
X ;
X if (csr & JAM ) {
X /* Ethernet Collision detected... */
X#ifdef DEBUG
X printf("sed: JAM: MECSR=%x\n", csr);
X#endif
X MEBACK(sed_va) = clock_ValueRough();
X MECSR(sed_va) |= JAM;
X } else break;
X }
X if ( pkLength == 15 ) SysBug("Go and Buy a New Ethernet Interface.");
X
X /* else we sent the packet ok. */
X}
X
X/*
X * Enable the Ethernet interface to receive packets from the network. If
X * the argument is zero, enable both buffers. If the argument is nonzero,
X * take it as the address of the buffer to be enabled.
X */
Xsed_Receive( recBufLocation )
X octet *recBufLocation;
X{
X word enables = 0;
X
X if (recBufLocation == 0) {
X bufAinUse = FALSE;
X bufBinUse = FALSE;
X enables = (ABSW | BBSW);
X }
X recBufLocation -= 16;
X if (recBufLocation == ((octet *)MEAHDR(sed_va))) {
X bufAinUse = FALSE;
X enables = ABSW;
X }
X if (recBufLocation == ((octet *)MEBHDR(sed_va))) {
X bufBinUse = FALSE;
X enables = BBSW;
X }
X
X MECSR (sed_va) |= enables;
X}
X
X/*
X * Test for the arrival of a packet on the Ethernet interface. The packet may
X * arrive in either buffer A or buffer B; the location of the packet is
X * returned. If no packet is returned withing 'timeout' milliseconds,
X * then the routine returns zero.
X *
X * Note: ignores ethernet errors. may occasionally return something
X * which was received in error.
X */
X
Xoctet *
Xsed_IsPacket()
X{
X register oldStatus;
X register octet *pb;
X
X pb = 0;
X if ( ! bufAinUse && (MECSR(sed_va)&ABSW) == 0 )
X pb = (octet *)MEAHDR(sed_va);
X if ( ! pb && ! bufBinUse && (MECSR(sed_va)&BBSW) == 0 )
X pb = (octet *)MEBHDR(sed_va);
X
X if ( pb ) {
X if ( ((octet *)pb) == ((octet *)MEAHDR(sed_va)) ) bufAinUse = 1;
X else bufBinUse = 1;
X pb += 16; /* get past the ethernet header */
X }
X
X return ( pb );
X}
X
X/*
X * Check to make sure that the packet that you received was the one that
X * you expected to get.
X */
Xsed_CheckPacket( recBufLocation, expectedType )
X word *recBufLocation;
X word expectedType;
X{
X register recHeader = recBufLocation[-8];
X if ( (recHeader&R_ERROR) != 0 ||
X (recHeader&R_OFFSET) < E10P_MIN ) {
X return ( -1 );
X }
X if ( recBufLocation[-1] != expectedType ) {
X return ( 0 );
X }
X return (1);
X}
END-of-sed.c
echo file: sed.h
sed 's/^X//' >sed.h << 'END-of-sed.h'
X/*
X * Header file for very simple ethernet driver, based on 3Com Multibus
X * board.
X *
X * Copyright (C) 1986, IMAGEN Corporation
X * "This code may be duplicated in whole or in part provided that [1] there
X * is no commercial gain involved in the duplication, and [2] that this
X * copyright notice is preserved on all copies. Any other duplication
X * requires written notice of the author."
X */
X
X#define en10size (8*1024) /* size of interface memory */
X#define en10pages ((en10size) >> pageshift)
X#define E10P_MIN 60 /* Minimum Ethernet packet size */
X
X/*
X * The position of the 3Com interface in virtual memory. If we're
X * Running the bootloader function, then it must be in the last 8k
X * of virtual addresses.
X */
X#ifdef BOOTLOADER
X#define SED3CVA vm_3ComAdr /* hack, only need pb68.h if bootloader */
X#endif
X#ifndef SED3CVA
X#define SED3CVA 0x1c000
X#endif
X
X/* 10Mb Ethernet interface addresses */
X
X#define MECSR(eth_va) *(word*)(((octet *) eth_va) + 0x0)
X#define MEBACK(eth_va) *(word*)(((octet *) eth_va) + 0x2)
X#define MEAROM(eth_va) (word*)(((octet *) eth_va) + 0x400)
X#define MEARAM(eth_va) (word*)(((octet *) eth_va) + 0x600)
X#define MEXHDR(eth_va) *(word*)(((octet *) eth_va) + 0x800)
X#define MEXBUF(eth_va) (word*)(((octet *) eth_va) + 0x1000)
X#define MEAHDR(eth_va) (word*)(((octet *) eth_va) + 0x1000)
X#define MEBHDR(eth_va) (word*)(((octet *) eth_va) + 0x1800)
X
X/* control/status register fields */
X
X#define BBSW 0x8000 /* Buffer B belongs to Network */
X#define ABSW 0x4000 /* Buffer A belongs to Network */
X#define TBSW 0x2000 /* Transmit buffer belongs to Network */
X#define JAM 0x1000 /* Set when transmit collision */
X#define AMSW 0x0800 /*
X#define RBBA 0x0400 /* Oldest received packet is in B */
X/*#define UNUSED 0x0200 */
X#define RESET 0x0100 /* Reset the controller */
X#define BINT 0x0080 /* Interrupt when BBSW=>0 (packet in B) */
X#define AINT 0x0040 /* Interrupt when ABSW=>0 (packet in A) */
X#define TINT 0x0020 /* Interrupt when TBSW=>0 (transmit done) */
X#define JINT 0x0010 /* Enable interrupts when JAM=>1 */
X#define PA 0x000F /* Which packets should be received? */
X#define INTENABLS 0x00F0
X
X/*
X * Receiver Header Fields:
X * The receiver header is the first (short) word of the receive buffer. It
X * includes such information as how big the packet is, whether it was a
X * broadcast, whether there was an error in receiving it, etc.
X */
X
X#define R_FCS 0x8000 /* fcs error */
X#define R_BCAST 0x4000 /* packet was NOT a broadcast */
X#define R_RANGE 0x2000 /* range error (size of pkt?) */
X#define R_MATCH 0x1000 /* packet is multicast (i.e., address
X received is not that of the interface) */
X#define R_FRAME 0x0800 /* framing error */
X#define R_ERROR 0x8800 /* was there any error */
X#define R_OFFSET 0x07FF /* packet length + 1 word */
X
Xextern octet *sed_FormatPacket(), *sed_WaitPacket();
X
X#ifdef BOOTLOADER
X#define ConsPrintf printf
X#endif
END-of-sed.h
echo file: tinyftp.c
sed 's/^X//' >tinyftp.c << 'END-of-tinyftp.c'
X/*
X * tinyftp.c - user ftp built on tinytcp.c
X *
X * Written March 31, 1986 by Geoffrey Cooper
X *
X * Copyright (C) 1986, IMAGEN Corporation
X * "This code may be duplicated in whole or in part provided that [1] there
X * is no commercial gain involved in the duplication, and [2] that this
X * copyright notice is preserved on all copies. Any other duplication
X * requires written notice of the author."
X */
X#include "tinytcp.h"
X
Xtcp_Socket ftp_ctl, ftp_data, ftp_data2;
Xbyte ftp_cmdbuf[120];
Xint ftp_cmdbufi;
X
Xbyte ftp_outbuf[80];
Xint ftp_outbufix, ftp_outbuflen;
X
Xshort ftp_rcvState;
X#define ftp_StateGETCMD 0 /* get a command from the user */
X#define ftp_StateIDLE 1 /* idle connection */
X#define ftp_StateINCOMMAND 2 /* command sent, awaiting response */
X#define ftp_StateRCVRESP 3 /* received response, need more data */
X
Xchar *ftp_script[7];
Xint ftp_scriptline;
Xchar ftp_retrfile[80];
XBOOL ftp_echoMode;
X
Xftp_ctlHandler(s, dp, len)
X tcp_Socket *s;
X byte *dp;
X int len;
X{
X byte c, *bp, data[80];
X int i;
X
X if ( dp == 0 ) {
X tcp_Abort(&ftp_data);
X return;
X }
X
X do {
X i = len;
X if ( i > sizeof data ) i = sizeof data;
X MoveW(dp, data, i);
X len -= i;
X bp = data;
X while ( i-- > 0 ) {
X c = *bp++;
X if ( c != '\r' ) {
X if ( c == '\n' ) {
X ftp_cmdbuf[ftp_cmdbufi] = 0;
X ftp_commandLine();
X ftp_cmdbufi = 0;
X } else if ( ftp_cmdbufi < (sizeof ftp_cmdbuf)-1 ) {
X ftp_cmdbuf[ftp_cmdbufi++] = c;
X }
X }
X }
X } while ( len > 0 );
X}
X
Xftp_commandLine()
X{
X printf("> %s\n", ftp_cmdbuf);
X switch(ftp_rcvState) {
X case ftp_StateIDLE:
X if ( ftp_cmdbuf[3] == '-' )
X ftp_rcvState = ftp_StateRCVRESP;
X break;
X
X case ftp_StateINCOMMAND:
X if ( ftp_cmdbuf[3] == '-' )
X ftp_rcvState = ftp_StateRCVRESP;
X case ftp_StateRCVRESP:
X if ( ftp_cmdbuf[3] == ' ' )
X ftp_rcvState = ftp_StateIDLE;
X break;
X }
X}
X
Xftp_Abort()
X{
X tcp_Abort(&ftp_ctl);
X tcp_Abort(&ftp_data);
X}
X
X
Xftp_application()
X{
X char *s;
X char *dp;
X int i;
X
X i = -1;
X if ( isina() ) {
X i = busyina() & 0177;
X#ifdef DEBUG
X if ( i == ('D' & 037) ) SysBug("Pause to DDT");
X#endif
X if ( i == ('C' & 037) ) {
X printf("Closing...\n");
X tcp_Close(&ftp_ctl);
X }
X }
X
X switch (ftp_rcvState) {
X case ftp_StateGETCMD:
X getcmd:if ( i != -1 ) {
X ftp_outbuf[ftp_outbuflen] = 0;
X switch (i) {
X case 'H' & 037:
X case 0177:
X if ( ftp_outbuflen > 0 ) {
X ftp_outbuflen--;
X printf("\010 \010");
X }
X break;
X
X case 'R' & 037:
X if ( ftp_echoMode )
X printf("\nFtpCmd> %s", ftp_outbuf);
X break;
X
X case 033:
X ftp_echoMode = ! ftp_echoMode;
X break;
X
X case '\r':
X case '\n':
X busyouta('\n');
X dp = &ftp_outbuf[ftp_outbuflen];
X goto docmd;
X
X default:
X if ( i >= ' ' && ftp_outbuflen < sizeof ftp_outbuf ) {
X ftp_outbuf[ftp_outbuflen++] = i;
X if ( ftp_echoMode ) busyouta(i);
X }
X }
X }
X break;
X
X case ftp_StateIDLE:
X if ( ftp_scriptline < 0 ) {
X ftp_rcvState = ftp_StateGETCMD;
X ftp_echoMode = true;
X ftp_outbuflen = 0;
X printf("FtpCmd> ");
X goto getcmd;
X }
X s = ftp_script[ftp_scriptline];
X if ( s == NIL )
X break;
X ftp_scriptline++;
X printf("%s\n", s);
X dp = ftp_outbuf;
X while ( *dp++ = *s++ ) ;
X dp--;
X docmd: *dp++ = '\r';
X *dp++ = '\n';
X ftp_outbuflen = dp - ftp_outbuf;
X ftp_outbufix = 0;
X ftp_rcvState = ftp_StateINCOMMAND;
X /* fall through */
X case ftp_StateINCOMMAND:
X i = ftp_outbuflen - ftp_outbufix;
X if ( i > 0 ) {
X i = tcp_Write(&ftp_ctl, &ftp_outbuf[ftp_outbufix], i);
X ftp_outbufix += i;
X tcp_Flush(&ftp_ctl);
X }
X /* fall through */
X case ftp_StateRCVRESP:
X break;
X }
X
X}
X
Xftp(host, fn, dataHandler)
X in_HwAddress host;
X char *fn;
X procref dataHandler;
X{
X word port;
X char filecmd[80];
X
X port = (sed_lclEthAddr[2] + clock_ValueRough()) | 0x8000;
X
X if ( fn ) {
X /* set up the script for this session */
X ftp_script[0] = "user foo";
X ftp_script[1] = "pass foo";
X ftp_script[2] = "type i";
X sprintf(filecmd, "retr %s", fn);
X ftp_script[3] = filecmd;
X ftp_script[4] = "quit";
X ftp_script[5] = 0;
X ftp_scriptline = 0;
X } else {
X ftp_scriptline = -1; /* interactive mode */
X ftp_echoMode = true;
X }
X
X /* set up state variables */
X ftp_rcvState = ftp_StateRCVRESP;
X ftp_cmdbufi = 0;
X tcp_Listen(&ftp_data, port, dataHandler, 0);
X tcp_Open(&ftp_ctl, port, host, 21, ftp_ctlHandler);
X tcp(ftp_application);
X}
END-of-tinyftp.c
echo file: tinytcp.c
sed 's/^X//' >tinytcp.c << 'END-of-tinytcp.c'
X/*
X * tinytcp.c - Tiny Implementation of the Transmission Control Protocol
X *
X * Written March 28, 1986 by Geoffrey Cooper, IMAGEN Corporation.
X *
X * This code is a small implementation of the TCP and IP protocols, suitable
X * for burning into ROM. The implementation is bare-bones and represents
X * two days' coding efforts. A timer and an ethernet board are assumed. The
X * implementation is based on busy-waiting, but the tcp_handler procedure
X * could easily be integrated into an interrupt driven scheme.
X *
X * IP routing is accomplished on active opens by broadcasting the tcp SYN
X * packet when ARP mapping fails. If anyone answers, the ethernet address
X * used is saved for future use. This also allows IP routing on incoming
X * connections.
X *
X * The TCP does not implement urgent pointers (easy to add), and discards
X * segments that are received out of order. It ignores the received window
X * and always offers a fixed window size on input (i.e., it is not flow
X * controlled).
X *
X * Special care is taken to access the ethernet buffers only in word
X * mode. This is to support boards that only allow word accesses.
X *
X * Copyright (C) 1986, IMAGEN Corporation
X * "This code may be duplicated in whole or in part provided that [1] there
X * is no commercial gain involved in the duplication, and [2] that this
X * copyright notice is preserved on all copies. Any other duplication
X * requires written notice of the author."
X */
X
X#include "tinytcp.h"
X
X/*
X * Local IP address
X */
Xin_HwAddress sin_lclINAddr;
X
X/*
X * IP identification numbers
X */
Xint tcp_id;
X
Xtcp_Socket *tcp_allsocs;
X
X/* Timer definitions */
X#define tcp_RETRANSMITTIME 1000 /* interval at which retransmitter is called */
X#define tcp_LONGTIMEOUT 31000 /* timeout for opens */
X#define tcp_TIMEOUT 10000 /* timeout during a connection */
X
X#ifdef DEBUG
X/*
X * Primitive logging facility
X */
X#define tcp_LOGPACKETS 1 /* log packet headers */
Xword tcp_logState;
X#endif
X
X/*
X * Initialize the tcp implementation
X */
Xtcp_Init()
X{
X extern eth_HwAddress sed_lclEthAddr;
X
X /* initialize ethernet interface */
X sed_Init();
X
X tcp_allsocs = NIL;
X#ifdef DEBUG
X tcp_logState = 0;
X#endif
X tcp_id = 0;
X
X /* hack - assume the network number */
X sin_lclINAddr = 0x7d000000 + (*((longword *)&sed_lclEthAddr[1]) & 0xFFFFFF);
X}
X
X/*
X * Actively open a TCP connection to a particular destination.
X */
Xtcp_Open(s, lport, ina, port, datahandler)
X tcp_Socket *s;
X in_HwAddress ina;
X word lport, port;
X procref datahandler;
X{
X extern eth_HwAddress sed_ethBcastAddr;
X
X s->state = tcp_StateSYNSENT;
X s->timeout = tcp_LONGTIMEOUT;
X if ( lport == 0 ) lport = clock_ValueRough();
X s->myport = lport;
X if ( ! sar_MapIn2Eth(ina, &s->hisethaddr[0]) ) {
X printf("tcp_Open of 0x%x: defaulting ethernet address to broadcast\n", ina);
X Move(&sed_ethBcastAddr[0], &s->hisethaddr[0], sizeof(eth_HwAddress));
X }
X s->hisaddr = ina;
X s->hisport = port;
X s->seqnum = 0;
X s->dataSize = 0;
X s->flags = tcp_FlagSYN;
X s->unhappy = true;
X s->dataHandler = datahandler;
X s->next = tcp_allsocs;
X tcp_allsocs = s;
X tcp_Send(s);
X}
X
X/*
X * Passive open: listen for a connection on a particular port
X */
Xtcp_Listen(s, port, datahandler, timeout)
X tcp_Socket *s;
X word port;
X procref datahandler;
X{
X s->state = tcp_StateLISTEN;
X if ( timeout == 0 ) s->timeout = 0x7ffffff; /* forever... */
X else s->timeout = timeout;
X s->myport = port;
X s->hisport = 0;
X s->seqnum = 0;
X s->dataSize = 0;
X s->flags = 0;
X s->unhappy = 0;
X s->dataHandler = datahandler;
X s->next = tcp_allsocs;
X tcp_allsocs = s;
X}
X
X/*
X * Send a FIN on a particular port -- only works if it is open
X */
Xtcp_Close(s)
X tcp_Socket *s;
X{
X if ( s->state == tcp_StateESTAB || s->state == tcp_StateSYNREC ) {
X s->flags = tcp_FlagACK | tcp_FlagFIN;
X s->state = tcp_StateFINWT1;
X s->unhappy = true;
X }
X}
X
X/*
X * Abort a tcp connection
X */
Xtcp_Abort(s)
X tcp_Socket *s;
X{
X if ( s->state != tcp_StateLISTEN && s->state != tcp_StateCLOSED ) {
X s->flags = tcp_FlagRST | tcp_FlagACK;
X tcp_Send(s);
X }
X s->unhappy = 0;
X s->dataSize = 0;
X s->state = tcp_StateCLOSED;
X s->dataHandler(s, 0, -1);
X tcp_Unthread(s);
X}
X
X/*
X * Retransmitter - called periodically to perform tcp retransmissions
X */
Xtcp_Retransmitter()
X{
X tcp_Socket *s;
X BOOL x;
X
X for ( s = tcp_allsocs; s; s = s->next ) {
X x = false;
X if ( s->dataSize > 0 || s->unhappy ) {
X tcp_Send(s);
X x = true;
X }
X if ( x || s->state != tcp_StateESTAB )
X s->timeout -= tcp_RETRANSMITTIME;
X if ( s->timeout <= 0 ) {
X if ( s->state == tcp_StateTIMEWT ) {
X printf("Closed. \n");
X s->state = tcp_StateCLOSED;
X s->dataHandler(s, 0, 0);
X tcp_Unthread(s);
X } else {
X printf("Timeout, aborting\n");
X tcp_Abort(s);
X }
X }
X }
X}
X
X/*
X * Unthread a socket from the socket list, if it's there
X */
Xtcp_Unthread(ds)
X tcp_Socket *ds;
X{
X tcp_Socket *s, **sp;
X
X sp = &tcp_allsocs;
X for (;;) {
X s = *sp;
X if ( s == ds ) {
X *sp = s->next;
X break;
X }
X if ( s == NIL ) break;
X sp = &s->next;
X }
X}
X
X/*
X * busy-wait loop for tcp. Also calls an "application proc"
X */
Xtcp(application)
X procref application;
X{
X in_Header *ip;
X longword timeout, start;
X int x;
X
X sed_Receive(0);
X
X timeout = 0;
X while ( tcp_allsocs ) {
X start = clock_ValueRough();
X ip = sed_IsPacket();
X if ( ip == NIL ) {
X if ( clock_ValueRough() > timeout ) {
X tcp_Retransmitter();
X timeout = clock_ValueRough() + tcp_RETRANSMITTIME;
X }
X
X application();
X
X continue;
X }
X
X if ( sed_CheckPacket(ip, 0x806) == 1 ) {
X /* do arp */
X sar_CheckPacket(ip);
X
X } else if ( sed_CheckPacket(ip, 0x800) == 1 ) {
X /* do IP */
X if ( ip->destination == sin_lclINAddr &&
X in_GetProtocol(ip) == 6 &&
X checksum(ip, in_GetHdrlenBytes(ip)) == 0xFFFF ) {
X tcp_Handler(ip);
X }
X }
X /* recycle buffer */
X sed_Receive(ip);
X
X x = clock_ValueRough() - start;
X timeout -= x;
X }
X
X return ( 1 );
X}
X
X/*
X * Write data to a connection.
X * Returns number of bytes written, == 0 when connection is not in
X * established state.
X */
Xtcp_Write(s, dp, len)
X tcp_Socket *s;
X byte *dp;
X int len;
X{
X int x;
X
X if ( s->state != tcp_StateESTAB ) len = 0;
X if ( len > (x = tcp_MaxData - s->dataSize) ) len = x;
X if ( len > 0 ) {
X Move(dp, &s->data[s->dataSize], len);
X s->dataSize += len;
X tcp_Flush(s);
X }
X
X return ( len );
X}
X
X/*
X * Send pending data
X */
Xtcp_Flush(s)
X tcp_Socket *s;
X{
X if ( s->dataSize > 0 ) {
X s->flags |= tcp_FlagPUSH;
X tcp_Send(s);
X }
X}
X
X/*
X * Handler for incoming packets.
X */
Xtcp_Handler(ip)
X in_Header *ip;
X{
X tcp_Header *tp;
X tcp_PseudoHeader ph;
X int len;
X byte *dp;
X int x, diff;
X tcp_Socket *s;
X word flags;
X
X len = in_GetHdrlenBytes(ip);
X tp = (tcp_Header *)((byte *)ip + len);
X len = ip->length - len;
X
X /* demux to active sockets */
X for ( s = tcp_allsocs; s; s = s->next )
X if ( s->hisport != 0 &&
X tp->dstPort == s->myport &&
X tp->srcPort == s->hisport &&
X ip->source == s->hisaddr ) break;
X if ( s == NIL ) {
X /* demux to passive sockets */
X for ( s = tcp_allsocs; s; s = s->next )
X if ( s->hisport == 0 && tp->dstPort == s->myport ) break;
X }
X if ( s == NIL ) {
X#ifdef DEBUG
X if ( tcp_logState & tcp_LOGPACKETS ) tcp_DumpHeader(ip, tp, "Discarding");
X#endif
X return;
X }
X
X#ifdef DEBUG
X if ( tcp_logState & tcp_LOGPACKETS )
X tcp_DumpHeader(ip, tp, "Received");
X#endif
X
X /* save his ethernet address */
X MoveW(&((((eth_Header *)ip) - 1)->source[0]), &s->hisethaddr[0], sizeof(eth_HwAddress));
X
X ph.src = ip->source;
X ph.dst = ip->destination;
X ph.mbz = 0;
X ph.protocol = 6;
X ph.length = len;
X ph.checksum = checksum(tp, len);
X if ( checksum(&ph, sizeof ph) != 0xffff )
X printf("bad tcp checksum, received anyway\n");
X
X flags = tp->flags;
X if ( flags & tcp_FlagRST ) {
X printf("connection reset\n");
X s->state = tcp_StateCLOSED;
X s->dataHandler(s, 0, -1);
X tcp_Unthread(s);
X return;
X }
X
X switch ( s->state ) {
X
X case tcp_StateLISTEN:
X if ( flags & tcp_FlagSYN ) {
X s->acknum = tp->seqnum + 1;
X s->hisport = tp->srcPort;
X s->hisaddr = ip->source;
X s->flags = tcp_FlagSYN | tcp_FlagACK;
X tcp_Send(s);
X s->state = tcp_StateSYNREC;
X s->unhappy = true;
X s->timeout = tcp_TIMEOUT;
X printf("Syn from 0x%x#%d (seq 0x%x)\n", s->hisaddr, s->hisport, tp->seqnum);
X }
X break;
X
X case tcp_StateSYNSENT:
X if ( flags & tcp_FlagSYN ) {
X s->acknum++;
X s->flags = tcp_FlagA