home *** CD-ROM | disk | FTP | other *** search
/ World of Ham Radio 1994 January / AMSOFT_1994.iso / packet / docs / pd198711.doc < prev    next >
Encoding:
Text File  |  1993-12-31  |  227.2 KB  |  5,200 lines
  1. 1-Nov-87 02:09:00-EST,2578;000000000000
  2. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 1 Nov 87 02:09-EST
  3. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22690@EDDIE.MIT.EDU>; Sat, 31 Oct 87 22:18:37 EST
  4. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22671@EDDIE.MIT.EDU>; Sat, 31 Oct 87 22:18:17 EST
  5. Received: from Taurus.Tau.Ac.IL by wiscvm.wisc.edu ; Sat, 31 Oct 87 13:34:27 CDT
  6. Received: by Taurus.Tau.Ac.IL (5.51/ta.1.4)
  7.     id AA01885; Sat, 31 Oct 87 14:02:20 +0200
  8. Comments: You can reach this host both as TAURUS.TAU.AC.IL
  9.        and TAURUS.BITNET The first form is preferred.
  10. Return-Path: <ofer@Taurus.Tau.Ac.IL>
  11. Date: Sat, 31 Oct 87 14:02:20 +0200
  12. From: Ofer Lapid 4X6OJ <ofer@Taurus.Tau.Ac.IL>
  13. Message-Id: <8710311202.AA01885@Taurus.Tau.Ac.IL>
  14. To: info-hams@simtel20.arpa, packet-radio@eddie.mit.edu
  15. Subject: Packet Request from 4XNET
  16.  
  17. From: Ofer Lapid 4X6OJ <ofer@taurus.BITNET> || <ofer@taurus.TAU.AC.IL>
  18. To: TCP/IP operators and wizards.
  19. Subject: TCP/IP over packet radio in Israel's 4XNET
  20.  
  21.   Hello netpeople,
  22. I call you with an urgent request.
  23.   We in Israel are quite new to the subject of Packet Radio, nevertheless
  24. we have been improving our network rapidly since the summer of 86 when we
  25. built the first PacCom TNC-200 kits.
  26.   Today we have more than 70 users all around the country and the number
  27. is increasing everyday.
  28.   We are successfully operating some 6 WA7MBL PBBS software version 320
  29. and running some servers around it to aid the distribution of binary
  30. files accross the country, we even have some ham from Egypt who uses our
  31. PBBS's frequently.
  32.   We have been following the advances of the group lead by KA9Q implementing
  33. the TCP/IP on packet and decided to adopt it to our networking as well.
  34. Until last spring SIMTEL20 was responsive to bitnet mail requests of files
  35. and we got the recent versions from there, now that the SIMTEL20 is *NOT*
  36. responding to mail requests we *CANNOT* be updated and cannot advance with
  37. the rest of the packet community.
  38.  
  39.   I am calling for every ham in big USA who can help us solving this
  40. matter and establish a strong, long lasting link through which software
  41. updates would flow to us from the large continent.
  42.  
  43.   We have tried sending self addressed diskettes over the mail but it
  44. came out very *SLOW* *UNRELIABLE* and *SQUASHED* ( the media not the software).
  45.  
  46.   WE CANNOT FTP TO ANY ARPA HOST ONLY PLAIN E-MAIL...
  47.  
  48. I will thank and appreciate any mail reply to this call
  49.                              Ofer Lapid 4X6OJ .
  50.  
  51. r mylogo
  52.  2-Nov-87 19:16:57-EST,2816;000000000000
  53. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 2 Nov 87 19:16-EST
  54. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21053@EDDIE.MIT.EDU>; Mon, 2 Nov 87 14:21:39 EST
  55. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21046@EDDIE.MIT.EDU>; Mon, 2 Nov 87 14:21:28 EST
  56. Message-Id: <8711021921.AA21046@EDDIE.MIT.EDU>
  57. To: packet-radio@EDDIE.MIT.EDU
  58. Cc: clements@LF-SERVER-2.BBN.COM
  59. Subject: Re:  PBBSes and TCP/IP
  60. Date: Mon, 02 Nov 87 14:23:38 -0500
  61. From: clements@LF-SERVER-2.BBN.COM
  62.  
  63.  
  64. < In article <8710282317.AA03565@june.cs.washington.edu>,
  65. <  Gary Delong <linus!raybed2!cvbnet!gdelong@EDDIE.MIT.EDU> writes:
  66. < In article <4286@well.UUCP>, tenney@well.UUCP (Glenn S. Tenney) writes:
  67. < > 
  68. < > Now the questions:
  69. < > 1. W0RLI software *sucks* compared to FIDO/OPUS.  Is there any
  70. < >    decent PBBS software out there?  Where?
  71. < > 2. Is there any existing software to run with the TCP/IP code
  72. < >    that would let people use it as a BBS (ie. conferencing)?
  73. < >    Ideally, any readnews software (I mean, netnews is better than
  74. < >    W0RLI by a looong shot!)?
  75. < > 
  76. < > Were these stupid questions or what?
  77. < > tnx
  78. < > Glenn Tenney
  79. < > AA6ER
  80. < 
  81. < No, Glenn, they aren't stupid questions, just phrased in such a way that anyone
  82. < who spent thousands of hours of his own time developing code that is given away
  83. < would have to be pissed.
  84. < ...
  85. < Remember, W0RLI is a person, not a product.
  86. < 
  87. < 73s
  88. <    _____ 
  89. <   /  \    /   All spelling errors        |       Gary A. Delong, N1BIP
  90.  
  91. I gave Hank, W0RLI, copies of the above two messages at dinner Friday night.
  92. He was not pissed.  After all, he has been in the PBBS business for a LONG
  93. time now, and has received a LOT of feedback of all kinds.
  94.  
  95. He did comment that from Glenn's location it would be impossible to
  96. get any decent throughput, whether AX.25 or TCP.  Serious hidden
  97. terminal problems, congested channels and digipeater disasters.
  98. He also mentioned that Glenn seemed to be unwilling to type H<return> for
  99. help, no matter how many times the system suggested he do so.  I will
  100. certainly agree that the system's command interface leaves a lot to be
  101. desired, though, and I've pushed hard on Hank to improve it over
  102. the years, with only partial success...
  103.  
  104. Hank did mention that he HAS become ticked off at two people, though,
  105. one JA op and one 2-lander named Brian something, who have
  106. taken Hank's code, modified it slightly and claimed it as their own,
  107. with copyright statements, even.
  108. This may be the straw that finally causes Hank to stop work on the
  109. system.  [But he has been claiming he was through developing the BBS
  110. for years...]
  111.  
  112. He gave me a copy of version 4.1, hot off the presses.  I'll get it
  113. posted to SIMTEL shortly.
  114.  
  115. 73,  Bob, K1BC     clements@bbn.com
  116.  3-Nov-87 04:28:11-EST,1057;000000000000
  117. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 04:28-EST
  118. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04351@EDDIE.MIT.EDU>; Tue, 3 Nov 87 00:43:26 EST
  119. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04331@EDDIE.MIT.EDU>; Tue, 3 Nov 87 00:41:41 EST
  120. Date: Mon, 2 Nov 1987  22:41 MST
  121. Message-Id: <KPETERSEN.12347568901.BABYL@SIMTEL20.ARPA>
  122. Sender: KPETERSEN@SIMTEL20.ARPA
  123. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  124. To: packet-radio@EDDIE.MIT.EDU
  125. Subject: W0RLI C PBBS V 4.1 now available from SIMTEL20 (correction)
  126.  
  127. The directory name in the previous announcement was incorrect.
  128. It showed device PS:.  It should have read PD:  That was my fault.
  129. the corrected list is below.
  130.  
  131. --Keith W8SDZ
  132.  
  133. Filename                        Type     Bytes   CRC
  134.  
  135. Directory PD:<MSDOS.PACKET>
  136. IO41.ARC                        BINARY    9793  3224H
  137. IOSRC41.ARC                     BINARY   36076  110CH
  138. MB41.ARC                        BINARY  140294  56D8H
  139. MB41READ.ME                     ASCII     2344  7552H
  140. MBSRC41.ARC                     BINARY   91852  FAA2H
  141.  
  142. Again, MBBIOS.ARC is unchanged.
  143.  
  144. MBBIOS.ARC                      BINARY   32256  E594H
  145.  3-Nov-87 05:56:42-EST,3583;000000000000
  146. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 05:56-EST
  147. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04148@EDDIE.MIT.EDU>; Tue, 3 Nov 87 00:30:49 EST
  148. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04124@EDDIE.MIT.EDU>; Tue, 3 Nov 87 00:30:03 EST
  149. Resent-Message-Id: <8711030530.AA04124@EDDIE.MIT.EDU>
  150. Date: Monday, 2 November 1987  21:31-MST
  151. Message-Id: <KPETERSEN.12347563981.BABYL@SIMTEL20.ARPA>
  152. Sender: clements@BBN.COM
  153. From: clements@BBN.COM
  154. To: w8sdz@SIMTEL20.ARPA
  155. Subject:   W0RLI C PBBS V 4.1 now available from SIMTEL20
  156. Resent-From: KPETERSEN@SIMTEL20.ARPA
  157. Resent-To: packet-radio@EDDIE.MIT.EDU
  158. Resent-Date: Mon 2 Nov 1987 22:14-MST
  159.  
  160. I have just uploaded version 4.1 of the W0RLI C PBBS to SIMTEL20.
  161.  
  162. Filename                        Type     Bytes   CRC
  163.  
  164. Directory PS:<MSDOS.PACKET>
  165. IO41.ARC                        BINARY    9793  3224H
  166. IOSRC41.ARC                     BINARY   36076  110CH
  167. MB41.ARC                        BINARY  140294  56D8H
  168. MB41READ.ME                     ASCII     2344  7552H
  169. MBSRC41.ARC                     BINARY   91852  FAA2H
  170.  
  171. Again, MBBIOS.ARC is unchanged.
  172.  
  173. MBBIOS.ARC                      BINARY   32256  E594H
  174.  
  175. Sorry to ship you a new one right after you announced V4.0, but Hank
  176. handed me a disk on Friday and it's my duty to spread the wealth...
  177.  
  178. 73, Bob, K1BC
  179.  
  180. [Extract from the README file in MB41.ARC]
  181.  
  182.        The W0RLI / VE3GYQ C BBS
  183.  
  184.   Release notes for C BBS Version  4.1 - 10/15/87
  185.  
  186.   See the file CHANGES.MB for details on new features included
  187.   and bugs fixed in this release.
  188.  
  189.  
  190.                *** Warning ***
  191.  
  192.   If you are now running a version prior to 4.0 you must convert
  193.   your existing message and user files to version 4 format.
  194.  
  195.   First, backup all files in the directory used by the MailBox.
  196.   In case something goes wrong, you will be able to restore
  197.   everything to where it was without loss of messages.
  198.  
  199.   The conversion from earlier versions to version 4 is done by MBCONV.
  200.   Set the default directory to the directory containing the
  201.   MAIL.DAT and USER.DAT files. Then run MBCONV.
  202.  
  203.   If you are running a version prior to 3.0 you must first make
  204.   certain that the message text has been moved to individual files.
  205.   Do this by executing the GF command.
  206.  
  207.              *** Note ***
  208.  
  209.   COMXBIOS has been replaced by PIPE. The old COMXBIOS device
  210.   driver will not work with versions of the MailBox beyond 4.0
  211.  
  212.   Check that any sub-directory you use in config.mb exists,
  213.   the existance of most directory / device paths is NOT checked.
  214.  
  215.   ... Hank
  216.  
  217. [Extract from the CHANGES.MB file]
  218.  
  219.       Changes from V4.0 to V4.1    Starting 10/1/87
  220.  
  221. Removed the "max # users in user file" from config.mb
  222. Separate times for "old" for NTS, user, bulletins.
  223. Would not rev fwd if target system had script in fwd.mb
  224. Removed /EX as end-of-msg, it was a bad idea.
  225. COMXBIOS replaced by PIPE. Generalizes the function to 4 ports.
  226. "monitor" "watch user" "see TNC commands" per port.
  227. Added DOS escape: ! command and ! list in fwd.mb.
  228. Got tired of seeing all the commands to the tnc, now not echo to screen.
  229. Zip code was not justified correctly in user record.
  230. Repaired "defered remote sysop command.
  231.  
  232.       Changes from V3.5 to V4.0    Starting 9/19/87
  233.  
  234. Fixed bug: download to a tnc did not return to terminal mode properly.
  235. Removed 256 character limit on greeting message.
  236. Added message state "H" (held), hold list, LH command.
  237. Much better handling of disconnect of "unhappy" tnc (from ve3gyq).
  238. Various bugs that showed up in 3.5 are fixed.
  239. Yet another change to DD timeslice handling.
  240. Message and User files version 8
  241. ----------------------------------------
  242.  3-Nov-87 21:29:26-EST,2148;000000000000
  243. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 21:29-EST
  244. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22192@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:31:53 EST
  245. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22169@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:30:58 EST
  246. Received: by june.cs.washington.edu (5.52.1/6.10)
  247.     id AA05145; Tue, 3 Nov 87 15:32:05 PST
  248. Return-Path: <uunet!mcvax!nikhefk!henkp@eddie.mit.edu>
  249. Message-Id: <8711032332.AA05145@june.cs.washington.edu>
  250. Date: 31 Oct 87 20:00:03 GMT
  251. From: uunet!mcvax!nikhefk!henkp@EDDIE.MIT.edu (Henk Peek)
  252. To: PACKET-RADIO@EDDIE.MIT.EDU
  253. Subject: (Belgium) Packet Radio Seminar
  254.  
  255.  
  256.         (Belgium) PACKET RADIO SEMINAR
  257.         ------------------------------
  258.  
  259. The Packet Work Group organize on 7 november a packet radio
  260. semainar at the Antwerp University Clininc Auditorium (AZU).
  261.  
  262.  9h45  10h00  Welcom address
  263.  
  264. 10h00  11h00  Networking via TCP/IP
  265.           G.J. van der Grinten, PA0GRI
  266.  
  267. 11h30  12h30  Rhein-Main Network controller
  268.           Klaus Dieter Friedrich, DH1FAB
  269.           Rhein-Main Packet Radio Group
  270.  
  271. 14h00  15h00  Packet radio experiment on bord of phase IIIc
  272.           Dipl-Ing Hans Peter Kuhlen, DK1YQ
  273.           Rudak group
  274.  
  275. 15h30  16h30  Packet message forwarding in the UK. packet network protocols
  276.           Jeff Ward, G0/K8KA
  277.           Uosat Spacecraft Engineering Unit
  278.           Universitery of Surrey
  279.  
  280. 17h00  18h00  Debate and conclusion
  281.  
  282. Free admittance to the surronding demonstration and meeting area.
  283. We have to charge 250 BEF covering the admittance to the auditorium
  284. (lectures), the complete seminar documentation and coffee breaks at
  285. regulair intervals. Luncheon can be provided at 250 BEF. Payment
  286. is required in advance for lectures and/or lunch:
  287. acct. 441-9610359-38 PWZ vzw, Teanisstraat 30, 9920 Lovendegem, Belgium
  288.  
  289. Information: Willy Wittseale, ON1AWU, Ter Borchtlaan 32, B2520 Edegem, Belgium.
  290.  
  291. ===============================================================================
  292.  
  293.     Henk Peek PA0HZP
  294.  
  295. Mail:   NIKHEF-K, postbox 4395, 1000 AJ Amsterdam, Holland
  296. UUCP:   uunet!mcvax!nikhefk!henkp.UUCP
  297. BITNET: U00234@HASARA5
  298.  
  299.  
  300.  3-Nov-87 22:18:06-EST,1807;000000000000
  301. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 22:18-EST
  302. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22121@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:28:20 EST
  303. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22117@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:28:00 EST
  304. Received: by june.cs.washington.edu (5.52.1/6.10)
  305.     id AA04977; Tue, 3 Nov 87 15:29:24 PST
  306. From: sun!imagen!atari!portal!cup.portal.com!Patrick_J_Fagan@EDDIE.MIT.edu
  307. Return-Path: <sun!imagen!atari!portal!cup.portal.com!Patrick_J_Fagan@eddie.mit.edu>
  308. Message-Id: <8711032329.AA04977@june.cs.washington.edu>
  309. Date: 31 Oct 87 21:40:21 GMT
  310. Newsgroups: rec.ham-radio.packet
  311. Subject: Re: Information exchange
  312. References: <7283@eddie.MIT.EDU>
  313. Xportal-User-Id: 1.1001.2475
  314. Apparently-To: packet-dist@EDDIE.MIT.EDU
  315.  
  316. GateWay was made available in ELECTRONIC FORM by Jon Bloom, KE3Z
  317. who is the former editor of this newsletter.  Since he is no longer
  318. charged with that responsibility, the files have not been made read-
  319. ily available to him.  This is why the ARRL Letter and GateWay have
  320. been hard to find on Packet/LL BBS's around the country.  There have
  321. been a few industrious souls that have taken on the monumental task
  322. of manually keying in the text from the printed edition.  Most have
  323. given up after a few issues when learning of the amount of time re-
  324. quired.
  325.  
  326. These periodicals are very reasonably priced.  So much so, the ARRL
  327. doesn't even cover the cost of production with revenue from paid
  328. subscriptions.  This may be another reason why it hasn't shown up
  329. in electronic form on PORTAL and elsewhere as of late.  Giving it
  330. away on BBS's hinders the incentive to subscribe.  Bob, I hope this
  331. will help answer your question.
  332.  
  333. 73, Pat - WA5DVV @ WA5DVV
  334. sun!cup.portal.com!WA5DVV
  335.  
  336.  3-Nov-87 22:48:00-EST,2878;000000000000
  337. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 22:47-EST
  338. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22042@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:23:05 EST
  339. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22037@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:22:52 EST
  340. Received: by june.cs.washington.edu (5.52.1/6.10)
  341.     id AA04629; Tue, 3 Nov 87 15:24:17 PST
  342. Return-Path: <husc6!bbn!rochester!udel!princeton!idacrd!mac@eddie.mit.edu>
  343. Message-Id: <8711032324.AA04629@june.cs.washington.edu>
  344. Date: 3 Nov 87 18:29:58 GMT
  345. From: husc6!bbn!rochester!udel!princeton!idacrd!mac@EDDIE.MIT.edu (Bob McGwier)
  346. To: PACKET-RADIO@EDDIE.MIT.EDU
  347. Subject: Re:  PBBSes and TCP/IP
  348. References: <7306@eddie.MIT.EDU>
  349.  
  350. > I gave Hank, W0RLI, copies of the above two messages at dinner Friday night.
  351. > He was not pissed.  After all, he has been in the PBBS business for a LONG
  352. > time now, and has received a LOT of feedback of all kinds.
  353. > 
  354. > 
  355. > Hank did mention that he HAS become ticked off at two people, though,
  356. > one JA op and one 2-lander named Brian something, who have
  357. > taken Hank's code, modified it slightly and claimed it as their own,
  358. > with copyright statements, even.
  359.  
  360. I would think that Bob would agree that I have known Hank for a long
  361. time and I do know Brian and I admire Hank as much as anybody who has
  362. ever met him but this is simply going too far.  "Modified slightly" is
  363. simply not at all accurate.  I would say that the similarities are
  364. outnumbered by the differences now.  ON EVERY occassion I have EVER
  365. heard Brian talk about the code he says, "PRMBS is based on the CBBS by
  366. W0RLI and with many additions made by me".  He in fact has EVERY right
  367. to copyright ANY code that is his own work so long as credit is given
  368. where credit is due.  Brian does not get enough credit as far as I am
  369. concerned for ideas contributed to the "other one" either.
  370. Brian and Hank are "warring" over those damn headers again and this
  371. should not be allowed to spill over into other things.  Frankly, Brian's
  372. additions to that code have made it the most full featured BBS for
  373. packet radio of any I know.  
  374.  
  375. BBS's are and should be only a stop gap to a more general object that is
  376. capable of running tasks at the behest of the user and sending files,
  377. mail, etc at request.  We need a better network for this and better
  378. networking software.  I believe that we have the bedrock for this in
  379. KA9Q's TCP/IP. Brian is making a valuable contribution to the existing
  380. networking arrangements and it behooves us not to have statements like
  381. this made.
  382.  
  383. I am sure Bob feels loyalty to our old friend from New England but care
  384. should be taken when making flat statements like this one.
  385.  
  386. NN2Z, Dave has also made contributions to Brian KA2BQE's efforts.  I for
  387. one wish all this childish bickering would cease.
  388.  
  389. Bob McGwier N4HY
  390.  
  391.  
  392.  
  393.  3-Nov-87 23:46:29-EST,2213;000000000000
  394. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 3 Nov 87 23:46-EST
  395. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22229@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:34:35 EST
  396. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22224@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:34:21 EST
  397. Received: by june.cs.washington.edu (5.52.1/6.10)
  398.     id AA05273; Tue, 3 Nov 87 15:35:46 PST
  399. Return-Path: <cornell!batcomputer!mitch@eddie.mit.edu>
  400. Message-Id: <8711032335.AA05273@june.cs.washington.edu>
  401. Date: 29 Oct 87 12:46:38 GMT
  402. From: cornell!batcomputer!mitch@EDDIE.MIT.edu (Mitch Collinsworth)
  403. To: PACKET-RADIO@EDDIE.MIT.EDU
  404. Subject: Hurtin' TNC
  405. Keywords: GLB TNC-2A, TNC2 clone, doesn't transmit
  406.  
  407. Hi all.  After being quite inactive on packet during the summer months,
  408. I returned to the rig a few weeks ago and found that I could not coerce
  409. my GLB TNC-2A to transmit with any of the normal commands.  The only
  410. command that would cause it to transmit is the one for adjusting the
  411. tones that puts it key-down and lets you alternate between the tones
  412. until you shut it off (I forget the name of the command).  Other than
  413. that it seems to be functioning "normally."  When you C W2XYZ, it
  414. does nothing for approximately the right period of time and then gives
  415. the normal messages you would see if it had actually transmitted the
  416. connect packets, but got no response.  It receives fine and if someone
  417. tries to connect to me, the CON light comes on and I get the connected
  418. message, but it never acknowledges the connect.
  419.  
  420. I first thought it might be seeing something on the receive line that
  421. would look like another transmitter and keep it from interrupting, but
  422. I put a MFJ TNC in its place and it works fine.
  423.  
  424. It was working just fine until I ignored it for the summer while
  425. persuing outdoor activities.  Anyone have any ideas what might cause a
  426. problem like this.  I thought it was simply a bad connection somewhere
  427. until I found that it actually would transmit with the above-mentioned
  428. test command.  Could this be simply a parameter that needs to be changed?
  429. Don't assume I haven't overlooked the obvious, as that could very well
  430. have happened.
  431.  
  432. -Mitch Collinsworth, K2VD
  433.  
  434.  
  435.  4-Nov-87 00:39:03-EST,1899;000000000000
  436. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Nov 87 00:39-EST
  437. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22891@EDDIE.MIT.EDU>; Tue, 3 Nov 87 19:20:25 EST
  438. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22872@EDDIE.MIT.EDU>; Tue, 3 Nov 87 19:20:03 EST
  439. Message-Id: <8711040020.AA22872@EDDIE.MIT.EDU>
  440. To: packet-radio@EDDIE.MIT.EDU
  441. Cc: clements@LF-SERVER-2.BBN.COM
  442. Subject: Oh, noooo!!! Get the fire extinguisher!!!
  443. Date: Tue, 03 Nov 87 19:18:57 -0500
  444. From: clements@LF-SERVER-2.BBN.COM
  445.  
  446. In message <325@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes:
  447.  
  448. < I am sure Bob feels loyalty to our old friend from New England but care
  449. < should be taken when making flat statements like this one.
  450. < ...
  451. <                                                                    I for
  452. < one wish all this childish bickering would cease.
  453.  
  454. < Bob McGwier N4HY
  455.  
  456. Good grief!   I seem to have hit a sore point!    My apologies.
  457.  
  458. First, I said clearly that I was repeating a comment from Hank,
  459. not making a flat statement of my own.  I cannot swear that he used
  460. the word "slightly", so I may have misrepresented him to that extent,
  461. but that was the impression I got.
  462.  
  463. Second, this is the first I had heard of ANY complaints along
  464. these lines, so I think that the "all this childish bickering"
  465. comment is out of place, certainly for this newsgroup.  There
  466. hasn't been any "all" except for one message.
  467.  
  468. It is certainly true that I know nothing about Brian's system. I
  469. don't think there are any copies of it running in New England.
  470. I, for one, have stopped running a PBBS at all.  It ain't worth
  471. it.
  472.  
  473. In any case, forget I ever mentioned it.  I had no intention of
  474. starting (or continuing) a war.  Apparently I stepped on a land
  475. mine that I didn't know was there.
  476.  
  477. 73, (running to hide in a hole somewhere)
  478. Bob, K1BC,  clements@bbn.com
  479.  4-Nov-87 01:23:37-EST,2878;000000000000
  480. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 4 Nov 87 01:23-EST
  481. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22042@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:23:05 EST
  482. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22037@EDDIE.MIT.EDU>; Tue, 3 Nov 87 18:22:52 EST
  483. Received: by june.cs.washington.edu (5.52.1/6.10)
  484.     id AA04629; Tue, 3 Nov 87 15:24:17 PST
  485. Return-Path: <husc6!bbn!rochester!udel!princeton!idacrd!mac@eddie.mit.edu>
  486. Message-Id: <8711032324.AA04629@june.cs.washington.edu>
  487. Date: 3 Nov 87 18:29:58 GMT
  488. From: husc6!bbn!rochester!udel!princeton!idacrd!mac@EDDIE.MIT.edu (Bob McGwier)
  489. To: PACKET-RADIO@EDDIE.MIT.EDU
  490. Subject: Re:  PBBSes and TCP/IP
  491. References: <7306@eddie.MIT.EDU>
  492.  
  493. > I gave Hank, W0RLI, copies of the above two messages at dinner Friday night.
  494. > He was not pissed.  After all, he has been in the PBBS business for a LONG
  495. > time now, and has received a LOT of feedback of all kinds.
  496. > 
  497. > 
  498. > Hank did mention that he HAS become ticked off at two people, though,
  499. > one JA op and one 2-lander named Brian something, who have
  500. > taken Hank's code, modified it slightly and claimed it as their own,
  501. > with copyright statements, even.
  502.  
  503. I would think that Bob would agree that I have known Hank for a long
  504. time and I do know Brian and I admire Hank as much as anybody who has
  505. ever met him but this is simply going too far.  "Modified slightly" is
  506. simply not at all accurate.  I would say that the similarities are
  507. outnumbered by the differences now.  ON EVERY occassion I have EVER
  508. heard Brian talk about the code he says, "PRMBS is based on the CBBS by
  509. W0RLI and with many additions made by me".  He in fact has EVERY right
  510. to copyright ANY code that is his own work so long as credit is given
  511. where credit is due.  Brian does not get enough credit as far as I am
  512. concerned for ideas contributed to the "other one" either.
  513. Brian and Hank are "warring" over those damn headers again and this
  514. should not be allowed to spill over into other things.  Frankly, Brian's
  515. additions to that code have made it the most full featured BBS for
  516. packet radio of any I know.  
  517.  
  518. BBS's are and should be only a stop gap to a more general object that is
  519. capable of running tasks at the behest of the user and sending files,
  520. mail, etc at request.  We need a better network for this and better
  521. networking software.  I believe that we have the bedrock for this in
  522. KA9Q's TCP/IP. Brian is making a valuable contribution to the existing
  523. networking arrangements and it behooves us not to have statements like
  524. this made.
  525.  
  526. I am sure Bob feels loyalty to our old friend from New England but care
  527. should be taken when making flat statements like this one.
  528.  
  529. NN2Z, Dave has also made contributions to Brian KA2BQE's efforts.  I for
  530. one wish all this childish bickering would cease.
  531.  
  532. Bob McGwier N4HY
  533.  
  534.  
  535.  
  536.  6-Nov-87 15:18:23-EST,1061;000000000000
  537. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 6 Nov 87 15:18-EST
  538. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14469@EDDIE.MIT.EDU>; Fri, 6 Nov 87 09:52:17 EST
  539. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14433@EDDIE.MIT.EDU>; Fri, 6 Nov 87 09:50:53 EST
  540. Date: Fri 6 Nov 87 09:43:50-EST
  541. From: Jeff Markel <HAZELTINE@A.ISI.EDU>
  542. Subject: Removal from distribution
  543. To: packet-radio@EDDIE.MIT.EDU
  544. Cc: hazeltine@A.ISI.EDU
  545. Message-Id: <12348454018.31.HAZELTINE@A.ISI.EDU>
  546.  
  547. Gentlemen:
  548.  
  549.     Please remove me immediately from the Packet Radio (amateur) 
  550.  
  551.     distribution. Your discussion are becoming too voluminous
  552.  
  553.     for me to keep up with.
  554.  
  555.  
  556.  
  557.     I will attempt to reinstate myself in the future. Right now I am 
  558.  
  559.     picking up Program Manager responsiblity from J.L. Markel
  560.  
  561.     and it is time consuming enough to keep up with the Program's
  562.  
  563.     Arpanet mail. Thanks for your help.
  564.  
  565.     
  566.  
  567.                        Donna Linke-Klein
  568.  
  569. -------
  570.  7-Nov-87 14:56:59-EST,1468;000000000000
  571. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 7 Nov 87 14:56-EST
  572. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18888@EDDIE.MIT.EDU>; Sat, 7 Nov 87 13:14:27 EST
  573. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18880@EDDIE.MIT.EDU>; Sat, 7 Nov 87 13:14:16 EST
  574. Received: from ROOK.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175685; Sat 7-Nov-87 13:14:50 EST
  575. Date: Sat, 7 Nov 87 13:14 EST
  576. From: Henry Minsky <hqm@VALLECITO.SCRC.Symbolics.COM>
  577. Subject: Repeater advice anyone?                
  578. To: packet-radio@eddie.mit.edu
  579. Message-Id: <871107131436.4.HQM@ROOK.SCRC.Symbolics.COM>
  580.  
  581.  
  582. It happens that there is a 440 Mhz repeater ready and waiting to be
  583. installed here at MIT, which Prof. Steve Ward once got from Motorola
  584. for the express purpose of being a digital communications repeater.
  585. Some people from the MIT w1mx radio club have experience with an
  586. identical piece of equiptment, and are willing to help set up a packet
  587. only repeater. I know almost nothing about repeaters.
  588.  
  589. I saw some postings awhile back about someone who had set up a repeater
  590. for packet, and was very pleased with it. I seem to have lost those
  591. messages! I'd like to ask if anyone has any advice on setting up a
  592. machine, which could be used for low and high speed packet repeating.
  593. I'm interested in nitty gritty details, like what kind of controller to
  594. use, or antenna placement or ... 
  595.  
  596. thanks,
  597. Henry N1EZP
  598.  
  599.  8-Nov-87 12:48:28-EST,1204;000000000000
  600. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 8 Nov 87 12:48-EST
  601. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05832@EDDIE.MIT.EDU>; Sun, 8 Nov 87 11:11:09 EST
  602. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05826@EDDIE.MIT.EDU>; Sun, 8 Nov 87 11:10:56 EST
  603. Received: by june.cs.washington.edu (5.52.1/6.10)
  604.     id AA20196; Sun, 8 Nov 87 08:11:33 PST
  605. Return-Path: <oliveb!pyramid!voder!randy@eddie.mit.edu>
  606. Message-Id: <8711081611.AA20196@june.cs.washington.edu>
  607. Date: 7 Nov 87 06:38:33 GMT
  608. From: oliveb!pyramid!voder!randy@EDDIE.MIT.edu (Randy Flatness)
  609. To: PACKET-RADIO@EDDIE.MIT.EDU
  610. Subject: pk232 software (also ts440).
  611. Keywords: pk232, ts440, software
  612.  
  613. Recently I arquired an AEA pk232 all mode terminal unit for use
  614. with my ts440. First of all I think it is an outstanding piece
  615. of gear! Second, I would like to get even more out of it by using
  616. a control program for interfacing to both the radio and pk232. 
  617.  
  618. Does anyone have any such program, or is there anything in public
  619. domain close to this. (I have seen one ad for a commercial product - 
  620. and am interested in any user response also). 
  621.  
  622.  
  623. Thanks in advance                               Randy Flatness
  624.   
  625.  
  626.  
  627. 10-Nov-87 18:26:17-EST,1288;000000000000
  628. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 18:26-EST
  629. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00598@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:17:34 EST
  630. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00587@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:17:14 EST
  631. Received: by june.cs.washington.edu (5.52.1/6.10)
  632.     id AA12553; Tue, 10 Nov 87 12:18:19 PST
  633. Return-Path: <ucdavis!uop!mrapple@ucbvax.berkeley.edu>
  634. Message-Id: <8711102018.AA12553@june.cs.washington.edu>
  635. Date: 6 Nov 87 05:45:27 GMT
  636. From: ucdavis!uop!mrapple@ucbvax.berkeley.edu (Nick Sayer)
  637. To: PACKET-RADIO@EDDIE.MIT.EDU
  638. Subject: Packet freqs
  639.  
  640. I know that on 2 meters the frequencies of choice are
  641. 5.01-5.09 every .02 Mhz (and to some extent 4.91-4.99),
  642. but can someone tell me what the 220 Mhz freqs. are?
  643. How about for 10 meters?
  644.  
  645. The band plans mention 'digital and experimental FM,'
  646. but in pretty vague terms.
  647.  
  648. ----- 
  649. Nick Sayer | Packet Radio: N6QQQ @ WA6RDH | CMS: SYSOP@STOKTON%STOCKTON
  650. uucp: ...!sdcsvax!ucbvax!ucdavis!uop!mrapple | Fido: 161/31
  651. Disclaimer:   You didn't REALLY believe that, did you?
  652. Kirk: Analysis, Mr. Spock?       Spock: It appears to be of external origin.
  653. Kirk: Mr. Sulu, go to pass two.  Sulu:  Aye aye, sir, going to pass two.
  654.  
  655.  
  656. 10-Nov-87 18:37:42-EST,1130;000000000000
  657. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 18:37-EST
  658. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00545@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:16:06 EST
  659. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00533@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:15:41 EST
  660. Received: by june.cs.washington.edu (5.52.1/6.10)
  661.     id AA12523; Tue, 10 Nov 87 12:16:46 PST
  662. Return-Path: <bellcore!faline!karn@eddie.mit.edu>
  663. Message-Id: <8711102016.AA12523@june.cs.washington.edu>
  664. Date: 6 Nov 87 16:25:51 GMT
  665. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  666. To: PACKET-RADIO@EDDIE.MIT.EDU
  667. Subject: Re: Packet freqs
  668. Summary: 220 mhz packet freqs
  669. Keywords: Frequencies
  670. References: <698@uop.UUCP>
  671.  
  672. The band plan recommendation is to put conventional (i.e., AFSK/FM) packet
  673. on the frequencies 221.01, .03, ... with 20 khz spacing.  High speed
  674. (100 Khz) channels are 220.55, .65, .75, .85 and .95.
  675.  
  676. These recommendations are only that; you must still clear them with your
  677. local frequency coordination committee. And, of course, all this assumes
  678. we keep that portion of the band.
  679.  
  680. Phil
  681.  
  682.  
  683. 10-Nov-87 18:39:33-EST,3885;000000000000
  684. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 18:39-EST
  685. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00436@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:12:06 EST
  686. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00427@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:11:49 EST
  687. Received: by june.cs.washington.edu (5.52.1/6.10)
  688.     id AA12336; Tue, 10 Nov 87 12:11:40 PST
  689. Return-Path: <ihnp4!homxb!hotps!ka2qhd!kc2wz@eddie.mit.edu>
  690. Message-Id: <8711102011.AA12336@june.cs.washington.edu>
  691. Date: 5 Nov 87 20:42:01 GMT
  692. From: ihnp4!homxb!hotps!ka2qhd!kc2wz@EDDIE.MIT.edu (Bob)
  693. To: PACKET-RADIO@EDDIE.MIT.EDU
  694. Subject: Level 3 protocols - some info?
  695. Keywords: TCPIP,COSI,NETROM
  696.  
  697. Ok people first I want to make it clear I am searching for information.  I am
  698. NOT trying to fuel the so-called protocol war.  So please keep my terminal
  699. >from bursting into FLAMES.  I'm opened to reasoned arguments not "name 
  700. calling".  That said, on to my questions.
  701.  
  702. Though I have been active on packet since 1984, I have for a number of reasons
  703. not completely followed the growing of the various Level 3 protocols.  I find
  704. the information confusing and in some cases conflicting.  I'm certain there
  705. are others in hamdom who are similarly confused.  If I can get together enough
  706. real information, maybe I'll write an article for one ham magazines.
  707.  
  708. Please straighten out any misconceptions or errors I have about the following:
  709.  
  710.    1.  TCP/IP - which KA9Q, et al are proposing is the best way to go for
  711.        Level 3.  Why?  What are its advantages over the other protocols?  What
  712.        are is disadvantages? (Come now we know nothing is perfect.)
  713.  
  714.    2.  COSI - I'm not certain who developed the idea.  Again, why should this
  715.        be adopted as a Level 3 standard?  What are its advantages?  What are
  716.        its disadvantages?
  717.  
  718.    3.  NET/ROM - Is this the same as COSI?  It SEEMS to be the way things are
  719.        going in the New Jersey/New York area on 2 meters.  Am I wrong?  Why 
  720.        should it be adopted?  What are its advantages?  Its disadvantages?
  721.  
  722.    4.  OTHER PROTOCOLS?  Are there others be proposed?  These are the only
  723.        ones I have heard mentioned. As above what are the advantages and
  724.        disadvantages?
  725.  
  726.    5.  Much of the work seems to centered are the IBM-PC and clones.
  727.        Obviously, these are very popular micros.  But there are a variety of
  728.        other makes which don't seem to be supported.  My machine (Tandy Color
  729.        Computer 3) is one example.  Other 6809/68000 machines also SEEM to be
  730.        left in the cold.  Is this true or just my impression?
  731.  
  732.    6.  My final(?) question (for now), how to go about setting up the TNC
  733.        and computer to use Level 3?  Is it necessary that everyone has Level 3
  734.        running in their TNC or is this a waste?  I have a TAPR TNC-1 running
  735.        WA8DED's software.  Will I have to burn a new EPROM with the new code?
  736.        How will my computer be interfaced with the TNC?
  737.  
  738. I think that is enough for now.  You can be certain I will have more to come.
  739. As I said please no FLAMES.  I realize that there are emotions running high in
  740. support of various protocols.  I am completely open agruments from all sides.
  741. What I am not open to is calling protocol X a piece of trash.  Maybe it is.
  742. But convince me with good arguments not FLAMES.
  743.  
  744. I guess all these questions are what results when one fails to keep up with
  745. the fast changing packett scene.  So I am playing catch up before I fall too
  746. far behind.
  747.  
  748. Thanks in advance for the information.  73...
  749.  
  750. -- 
  751.    Bob Billson, KC2WZ                    Packet: KC2WZ at NN2Z
  752. SnailMail: 837 Summit Avenue             UUCP: ucbvax!ihnp4!hotps!ka2qhd!kc2wz
  753.        Westfield, NJ 07090           Phone: 201-232-2805
  754. For those with maps: Lat. 40.640972 N, Long. 74.337833 W, Elev. 15.24 M
  755.  
  756.  
  757. 10-Nov-87 19:01:47-EST,1326;000000000000
  758. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 19:01-EST
  759. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00775@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:22:30 EST
  760. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00767@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:22:06 EST
  761. Received: by june.cs.washington.edu (5.52.1/6.10)
  762.     id AA12725; Tue, 10 Nov 87 12:22:44 PST
  763. From: ihnp4!drutx!mtgzz!mtuxo!mtune!whuts!homxb!hotps!ka2qhd!kc2wz@EDDIE.MIT.edu
  764. Return-Path: <ihnp4!drutx!mtgzz!mtuxo!mtune!whuts!homxb!hotps!ka2qhd!kc2wz@eddie.mit.edu>
  765. Message-Id: <8711102022.AA12725@june.cs.washington.edu>
  766. Date: 3 Nov 87 20:06:59 GMT
  767. To: PACKET-RADIO@EDDIE.MIT.EDU
  768. Subject: Any OS-9 Users on packet?
  769. Keywords: OS9
  770.  
  771. Is there anyone in this group who has (or is interested in) experimented(ing)
  772. with OS-9 Levels 1 and/or 2, BASIC09, or C running on a Tandy Color Computer
  773. or any other OS-9 based system on packet radio?
  774.  
  775. If so, I would like to hear from you.  I am interested in seeing how
  776. OS-9 can be adapted to packet. Since it is a multi-user, multi-tasking
  777. operating system, it should have many varied and INEXPENSIVE uses on packet.
  778. Anyone game?
  779.  
  780.        73...Bob Billson, KC2WZ
  781.  
  782.  nn2z-4      U Snail: 837 Summit Ave.
  783.                      Westfield, NJ 07090
  784.  
  785.  
  786. 10-Nov-87 20:04:28-EST,2834;000000000000
  787. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 20:04-EST
  788. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00836@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:25:20 EST
  789. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00823@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:24:43 EST
  790. Received: by june.cs.washington.edu (5.52.1/6.10)
  791.     id AA12864; Tue, 10 Nov 87 12:25:40 PST
  792. Return-Path: <cornell!batcomputer!mitch@eddie.mit.edu>
  793. Message-Id: <8711102025.AA12864@june.cs.washington.edu>
  794. Date: 5 Nov 87 12:59:34 GMT
  795. From: cornell!batcomputer!mitch@EDDIE.MIT.edu (Mitch Collinsworth)
  796. To: PACKET-RADIO@EDDIE.MIT.EDU
  797. Subject: Stolen from club newsletter.  Enjoy.
  798.  
  799.             MORE FROM THE OLD TIMER
  800.  
  801. Contrary to what was reported about me last month, I was not sleeping...
  802. I was only resting my eyes!
  803.  
  804. As you know well, packet is all the rage these days.  There's a lot of
  805. "hacking" activity on two meters.  So I thought I would try it.  Being
  806. rather thrifty (some call it cheap), I searched high and low for the
  807. least expensive TNC (terminal node controller) available.  Finally I
  808. found one for $39.95 from some outfit in the midwestern desert named
  809. "Trapper".  No sales tax and prepaid shipping.  Boy, I thought "what
  810. a great deal!"
  811.  
  812. Alas, when the TNC arrived, I found that the unit contained a send-only
  813. modem, and the resident firmware was installed on a write-only EEPROM
  814. CHIP.  So, I am saving up again for a TNC that really works -- one with
  815. 4 ports and one starboard.
  816.  
  817. All was not lost, because the instruction manual sent with the TNC was
  818. very informative, although slightly obscure.  If any of you could help
  819. me understand their list of default commands and parameter settings,
  820. some of which are shown below, please write the editor.
  821.  
  822. FRACK AFTER FRICK'N
  823. XENON GASSED
  824. MAXOUT 12
  825. TAXDELAY FEDERAL/STATE/COUNTY/CITY
  826. CONOK CONOK WHO'S THERE
  827. STREAMSWITCH ON GET MOP
  828. ALAMODE ON
  829. HAIRSHIRT OFF
  830. BACON EVERY 10
  831. EGGS EVERY 5
  832. MYRESPONSE NEGATIVE
  833. KILL EVERY CONTROL-G
  834. MALL CLOSED
  835. SHOP EARLY
  836. BED CHECK
  837. XMITOK AFTER XMITIK
  838. SENDPAC COOKIES
  839. BUG OFF
  840. SUPLISP THERTAINLY
  841. SWEDEDETECT ON
  842. DANE DETECT OFF
  843. RAGTIME AFTER 1
  844. PERM $20
  845. MANICUR $5
  846. UNPROTON NEUTRON
  847. MYDILEMM ON
  848. CSTAMP OUCH
  849. TEATIME OFF
  850. CANPAC CHOO CHOO
  851. ABAWD DIRTY
  852. HBAWD DIRTY
  853. AXDELAY EXECUTION OFF
  854. BTEXT BZZZZ
  855. BUDLIST ANHEUSER/BUSCH
  856. MONOTOR SUNK
  857. ENUF ALREADY
  858.  
  859. If anyone can, please help!  I know I should have stayed with twenty
  860. meter CW!!
  861.  
  862.  
  863.     From November 1987 RaRa Rag
  864.         (RaRa = Rochester Amateur Radio Association)
  865.  
  866.     Credit in RaRa Rag was given to RAGS Review
  867.         (RAGS = Radio Amateurs of Greater Syracuse)
  868.  
  869. ------------------------------------------------------------------------
  870.  
  871. -Mitch
  872.  mitch@tcgould.tn.cornell.edu
  873.  
  874. "If your antenna didn't fall down last winter, it wasn't big enough."
  875.  
  876.  
  877. 10-Nov-87 21:08:45-EST,1718;000000000000
  878. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 21:08-EST
  879. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00768@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:22:11 EST
  880. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00744@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:21:16 EST
  881. Received: by june.cs.washington.edu (5.52.1/6.10)
  882.     id AA12668; Tue, 10 Nov 87 12:21:30 PST
  883. From: ihnp4!drutx!mtgzz!mtuxo!mtune!whuts!homxb!hotps!ka2qhd!kc2wz@EDDIE.MIT.edu
  884. Return-Path: <ihnp4!drutx!mtgzz!mtuxo!mtune!whuts!homxb!hotps!ka2qhd!kc2wz@eddie.mit.edu>
  885. Message-Id: <8711102021.AA12668@june.cs.washington.edu>
  886. Date: 3 Nov 87 20:31:45 GMT
  887. To: PACKET-RADIO@EDDIE.MIT.EDU
  888. Subject: TCP/IP available for 6809/68000?
  889. Keywords: OS9,TCPIP
  890.  
  891. Can anyone tell me where I might obtain KA9Q's TCP/IP files which will run
  892. on the 6809/680000 microprocessors?  I run OS-9 Level 2 on a Tandy Color
  893. Computer 3.  I would like to be able to use TCP/IP on my TNC1 (which is runn-
  894. ing WA8DED's software.)
  895.  
  896. Unfortunately, all the files are apparenty only available for MS-DOS machines.
  897. I do have a utility which can unARC the files but I still have a few problems.
  898.  
  899.      1.  No way to transfer MS-DOS files to an OS-9 disk.  Can anyone help
  900.      here?
  901.  
  902.      2.  Once I get them unARCed what do I do?  I do have a C compiler
  903.      (Microware's) so I can recompile the code.  However, not being very
  904.      familiar with MS-DOS, I don't know how to handle the machine
  905.      specific code.  Can anyone help here?
  906.  
  907. Thanks very much all for the assistance.
  908.  
  909.        73...Bob Billson, KC2WZ
  910.  
  911.  nn2z-4      U Snail: 837 Summit Ave.
  912.                      Westfield, NJ 07090
  913.  
  914.  
  915. 10-Nov-87 21:12:18-EST,1992;000000000000
  916. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 21:12-EST
  917. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07376@EDDIE.MIT.EDU>; Tue, 10 Nov 87 19:30:57 EST
  918. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07353@EDDIE.MIT.EDU>; Tue, 10 Nov 87 19:29:19 EST
  919. Received: by june.cs.washington.edu (5.52.1/6.10)
  920.     id AA22371; Tue, 10 Nov 87 16:30:07 PST
  921. Return-Path: <somewhere!David_G._Michelson%UBC.MAILNET@um.cc.umich.edu>
  922. Message-Id: <8711110030.AA22371@june.cs.washington.edu>
  923. Date: Tue, 10 Nov 87 11:32:08 PST
  924. From: David_G._Michelson%UBC.MAILNET@um.cc.umich.edu
  925. To: packet-radio@EDDIE.MIT.EDU
  926. Subject: Repeater advice anyone?
  927.  
  928. Re: 440 MHz Repeater for Packet Radio
  929.  
  930. One of the most interesting things about packet radio (in my opinion)
  931. is the different ways one can approach the problem of repeating.
  932.  
  933. The simplex digipeater is the simplest but, as subscribers to this
  934. mailing list are aware, it has severe disadvantages due to contention
  935. between the orginal packet, all its copies, and the many acknowledge-
  936. ments that fly back and forth up and down the link.
  937.  
  938. NET/ROM is a significant improvement to the simple digipeater concept
  939. which, as I understand, uses standard TNC-2 hardware but enhanced
  940. firmware.
  941.  
  942. Cross-band and cross-channel packet radio repeaters offer significant
  943. advantages because they eliminate the possibility of collision between
  944. originator-repeater traffic and repeater-addressee traffic.
  945.  
  946. And then there are the many people who use conventional duplex repeaters
  947. for packet traffic (i.e., no regeneration).
  948.  
  949. Are these the issues you were concerned with or are you after the
  950. technical details of a specific implementation?
  951.  
  952.  
  953.                    David G. Michelson, VE7TSX
  954.                  University of British Columbia
  955.                        Amateur Radio Club
  956.  
  957.                 BitNet Address: USERMDG@UBCMTSG
  958.  
  959.  
  960. 10-Nov-87 21:27:36-EST,1091;000000000000
  961. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 10 Nov 87 21:27-EST
  962. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00353@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:09:30 EST
  963. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00349@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:09:17 EST
  964. Received: by june.cs.washington.edu (5.52.1/6.10)
  965.     id AA12262; Tue, 10 Nov 87 12:10:16 PST
  966. Return-Path: <ihnp4!cbosgd!gwspc!cbcsta!n8emr!gws@eddie.mit.edu>
  967. Message-Id: <8711102010.AA12262@june.cs.washington.edu>
  968. Date: 8 Nov 87 04:02:04 GMT
  969. From: ihnp4!cbosgd!gwspc!cbcsta!n8emr!gws@EDDIE.MIT.edu (Gary W. Sanders )
  970. To: PACKET-RADIO@EDDIE.MIT.EDU
  971. Subject: ham domain
  972.  
  973. Has anyone ever looking into getting a domain registered for the
  974. amateur radio packet network? I know that arpa has a set up
  975. address setup, but what about on other networks. Can an single
  976. person register a domain or does an orgainazation (ARRL) have
  977. to do this??
  978.  
  979. -- 
  980. Gary W. Sanders         {ihnp4|cbosgd}!n8emr!gws
  981. (cis) 72277,1325        (packet) N8EMR @ W8CQK
  982. HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps
  983.  
  984.  
  985. 11-Nov-87 00:27:42-EST,40098;000000000000
  986. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Nov 87 00:27-EST
  987. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00500@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:14:54 EST
  988. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00473@EDDIE.MIT.EDU>; Tue, 10 Nov 87 15:13:15 EST
  989. Received: by june.cs.washington.edu (5.52.1/6.10)
  990.     id AA12415; Tue, 10 Nov 87 12:14:14 PST
  991. From: sun!imagen!atari!portal!cup.portal.com!Patrick_J_Fagan@DECWRL.DEC.COM
  992. Return-Path: <sun!imagen!atari!portal!cup.portal.com!Patrick_J_Fagan@decwrl.dec.com>
  993. Message-Id: <8711102014.AA12415@june.cs.washington.edu>
  994. Date: 6 Nov 87 03:22:58 GMT
  995. To: PACKET-RADIO@EDDIE.MIT.EDU
  996. Subject: MFJ-40 A/B/C Upgrade Kit - Software Release 1.1.5 for TNC 2
  997. Xportal-User-Id: 1.1001.2475
  998.  
  999. [Via WA5DVV]
  1000.  
  1001.    *====================================================================*
  1002.    | This information was taken from MFJ documentation.  Permission to  |
  1003.    | electronically reproduce and distribute this data has been granted |
  1004.    | to the Mississippi Amateur Radio Digital Association {MARDA}.      |
  1005.    *====================================================================*
  1006.  
  1007.  
  1008.              MFJ-40A/40B/40C
  1009.       UPDATE KIT FOR TNC 2 VERSION 2, RELEASE 1.1.5
  1010.  
  1011. This kit contains one 27C256 EPROM with Release 1.1.5 software
  1012. and one instruction sheet. MFJ-40A contains software
  1013. release 1.1.5-16K for 16K RAM operation.   MFJ-40B contains
  1014. software release 1.1.5-32K EPROM and a 32K RAM.  MFJ-40C contains
  1015. software release 1.1.5-32K EPROM without 32K RAM.         
  1016.  
  1017.       INSTALLATION OF MFJ-40A FOR 16K RAM OPERATION
  1018. 1.  Remove all power from the TNC 2.  
  1019. 2.  Remove the cover by removing the mounting screws on the side 
  1020.     of the cabinets.  
  1021. 3.  Remove JMP 5 jumper.  This disconnects the Lithium battery.
  1022. 4.  Carefully remove the EPROM (U23, 27256) from the TNC 
  1023.     2 board.  Make note of the orientation of the IC. 
  1024. 5.  Install the new EPROM containing 1.1.5-16K software on 
  1025.     the TNC 2 board at U23.  Make sure that no IC pins are 
  1026.     bent under the IC.  Make sure that the notch is pointed in
  1027.     the same direction as the old EPROM.  
  1028. 6.  Install JMP5 jumper.  
  1029. 7.  Replace the cover of the cabinet.    
  1030. 8.  Apply power to the TNC 2.  
  1031.  
  1032.     INSTALLATION OF MFJ-40B/40C FOR 32K RAM OPERATION
  1033.  
  1034. 1.  Remove all power from the TNC 2. 
  1035. 2.  Remove the cover by removing the mounting screws on the 
  1036.     side of the cabinets. 
  1037. 3.  Remove JMP5 jumper.  This disconnects the Lithium 
  1038.     battery. 
  1039. 4.  Remove 8K RAMs at U24 and U25. 
  1040. 5.  FOR MFJ-1270:  Remove circuit board from chassic.  Cut the 
  1041.     trace that is connected between the center pad and the pad 
  1042.     closest to R29 of JMP 12.  Connect a jumper wire between the 
  1043.     center pad and the pad closest to C28 of JMP 12.  Re-install the 
  1044.     circuit board.
  1045.     FOR MFJ-1270B AND MFJ-1274:  A removable jumper for JMP12 is 
  1046.     provided.  Remove the jumper from pin 2 and 3 of JMP12 and 
  1047.     install it on pin 1 and 2 of JMP12.
  1048. 6.  Install 32K RAM chip at U25 (U24 is left unused).  Some 
  1049.     32K RAMs which may be used are NEC 43256C-15L, Hitachi 
  1050.     HM64456L-15 or HM62256L-15 and Toshiba 55257PL-15.  
  1051.     NOTE: If you purchased the MFJ-40C update, you must supply 
  1052.     your own 32K RAM.  This EPROM will not operate with 16K RAM.
  1053. 7.  Carefully remove the EPROM (U23, 27256) from the TNC 2 
  1054.     board.  Make note of the orientation of the IC.  
  1055. 8.  Install the new EPROM with 1.1.5-32K software on the TNC 
  1056.     2 board at U23.  Make sure that no IC pins are bent 
  1057.     under the IC.  Make sure that the notch on the IC is 
  1058.     pointed in the same direction as the old EPROM.  
  1059. 9.  Install JMP5 jumper. 
  1060. 10. Replace the cover of the cabinet.
  1061. 11. Apply power to the TNC2.  
  1062.  
  1063.  
  1064. The 1.1.5-16K and 1.1.5-32K software releases contain all 
  1065. FIXES, CHANGES AND ADDITIONS of the 1.1.4 and 1.1.3 releases.
  1066.  
  1067.  
  1068.       SOFTWARE RELEASE NOTES FOR RELEASE 1.1.3
  1069.  
  1070.                FIXES
  1071.  
  1072.      o- When  AX25L2V2  is ON,  the TNC now  answers  L2  UI 
  1073.      frames  with P and C set with either:  RR if  connected 
  1074.      (regardless  of rcvr flow control state),  or DM if not 
  1075.      connected.
  1076.  
  1077.      o- Path for SABM received while in link-setup state  is 
  1078.      not  checked.   This corrects earlier operation where a 
  1079.      self-connect via an odd number of different digipeaters 
  1080.      fails.
  1081.  
  1082.      o- T2  <RESPTIME>  utilization corrected  for  the  2nd 
  1083.      through nth link
  1084.  
  1085.      o- FULLDUP operation restored
  1086.  
  1087.      o- Channel capture during busy times improved
  1088.  
  1089.      o- NOMODE bug, where the 'connect mode' setting was not 
  1090.      used  on received SABMS has been corrected.   This  bug 
  1091.      may  have  caused  the TNC to enter a  state  where  it 
  1092.      seemed  like  the  TNC died,  when it actually  was  in 
  1093.      TRANSparent mode.
  1094.  
  1095.               CHANGES 
  1096.  
  1097.      o- BEACONS not sent if BTEXT is null
  1098.  
  1099.      o- RESPTIME default now at 5; i.e. 500ms
  1100.  
  1101.  
  1102.              ADDITIONS
  1103.  
  1104.      o- RXBLOCK command
  1105.  
  1106.      o- TNC "Health" feature group installed
  1107.  
  1108. Fourteen counters have been added to TNC 2.  All of them are 
  1109. 16 bits wide, and are ALWAYS initialized to 0000 on power up 
  1110. or "RESTART".
  1111.  
  1112.      o- ASYRXOVR:   Increases  when  the software  does  not 
  1113.             service  the  asynchronous  receiver  in 
  1114.             time.   Indicates data from the user  to 
  1115.             the  TNC is being dropped.   This  error 
  1116.             counter  should  never  become  non-zero 
  1117.             under supported data rates.
  1118.  
  1119.      o- DIGISENT:   Each frame digipeated by this TNC causes 
  1120.             the counter to increase.
  1121.  
  1122.      o- HOVRERR:    Increases  when  HDLC  receiver  is  not 
  1123.             serviced  rapidly  enough  and  data  is 
  1124.             lost.   This counter should never incre-
  1125.             ment at any supported data rate.
  1126.  
  1127.      o- HUNDRERR:   Increases  when the HDLC transmitter  is 
  1128.             not  serviced rapidly enough and  frames 
  1129.             are aborted.   This counter should never 
  1130.             be non-zero at any supported data rate.
  1131.  
  1132.      o- RCVDFRMR:   Increases  when Frame reject frames  are 
  1133.             received from a connected station.
  1134.  
  1135.      o- RCVDIFRA:   Increases  for  each reception of  an  I 
  1136.             frame from a connectee.
  1137.  
  1138.      o- RCVDREJ:    Increases  for each reception of an REJ-
  1139.             ect frame from a connectee.
  1140.  
  1141.      o- RCVDSABM:   Each  received  SABM frame addressed  to 
  1142.             the  TNC causes this counter to be  inc-
  1143.             reased by one.
  1144.  
  1145.      o- RXCOUNT:    Increases  when  any frame  is  received 
  1146.             with good CRC (or any CRC if HGARBAGE is 
  1147.             turned on).
  1148.  
  1149.      o- RXERRORS:   Increments each time a received frame is 
  1150.             thrown  out due to it being  too  short, 
  1151.             suffering  overrun(s),   or it having  a 
  1152.             bad  CRC.   Latter occurs only when  CRC 
  1153.             checking  is enabled (i.e.  HGARBAGE  is 
  1154.             OFF).  This counter will often increment 
  1155.             in the presence of noise.
  1156.  
  1157.      o- SENTFRMR:   Increments  each  time  a  Frame  reject 
  1158.             frame is transmitted.
  1159.  
  1160.      o- SENTIFRA:   Increases by one each time an I frame is 
  1161.             sent.
  1162.  
  1163.      o- SENTREJ:    Whenever  a REJect frame is transmitted, 
  1164.             this counter is incremented.
  1165.  
  1166.      o- TXCOUNT:    Incremented whenever a frame is correct-
  1167.             ly transmitted.
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173. The following information should be inserted into the DISPLAY command.
  1174.  
  1175. DISPLAY HEALTH
  1176.  
  1177. The counters just described,  and the setting of HEALLED are 
  1178. displayed in response to the health inquiry.
  1179.  
  1180.  
  1181.             New Commands
  1182.  
  1183. AX25L2V2 ON|OFF                                 Default: OFF
  1184.  
  1185.  
  1186. Parameters:
  1187.  
  1188.      ON        The  TNC  will use AX.25 Level 2 Version  2.0 
  1189.            protocol.
  1190.  
  1191.      OFF       The  TNC  will use AX.25 Level 2 Version  1.0 
  1192.            protocol.
  1193.  
  1194. Some  implementations of the earlier version of AX.25 proto-
  1195. col (e.g., TAPR's TNC 1) won't properly digipeat version 2.0 
  1196. AX.25 packets.  This command exists to provide compatibility 
  1197. with these other TNCs until their software has been updated.
  1198.  
  1199. During  the  protocol  transition  period,  you  should  set 
  1200. AX25L2V2 OFF.
  1201.  
  1202. After your local area TNCs are updated to the newer protocol 
  1203. version, you should set AX25L2V2 ON.
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227. RXBLOCK ON|OFF                                  Default: OFF
  1228.  
  1229.  
  1230. Parameters:
  1231.  
  1232.      ON        The  TNC  will send data to the  terminal  in 
  1233.            RXBLOCK format.
  1234.  
  1235.      OFF       The  TNC  will send data to the  terminal  in 
  1236.            standard format.
  1237.  
  1238.  
  1239. RXBLOCK is designed for automated operations, such as packet 
  1240. bulletin  board  stations.   It  is intended  to  help  such 
  1241. systems   discriminate  between  data  received   from   the 
  1242. connected station and TNC-generated messages.
  1243.  
  1244. Correct  operation  of  RXBLOCK is dependant  on  the  AWLEN 
  1245. parameter getting set to 8 (bits) since the character FF hex 
  1246. marks the beginning of a recieved data unit header.
  1247.  
  1248. When  RXBLOCK is on,  data from other stations will be  sent 
  1249. >from the TNC in the following format:
  1250.  
  1251.    ------------------------------------------------------
  1252.   |  $FF   |  L0  |  L1  |  PID  |       DATA            |
  1253.    ------------------------------------------------------
  1254.  
  1255.   ( prefix )(  length   ) ( pid ) (      data            )
  1256.  
  1257. The fields above are defined as follows:
  1258.  
  1259. prefix    $FF  ::=  A character with all 8 bits set
  1260. length    L0   ::=  The  high  order  length  of  the  data, 
  1261.             length,  and  pid fields logically  ORed 
  1262.             with the value $F0
  1263.       L1   ::=  The  low  order  length  of  the   data, 
  1264.             length, and pid fields
  1265. pid       PID  ::=  The  Protocol  IDentifier byte  received 
  1266.             for the following data field
  1267. data      DATA ::=  [Optional], variable length data
  1268.  
  1269.  
  1270. For  best  operation it is suggested  that  parameters  like 
  1271. AUTOLF,  MFILTER etc.  be set OFF in order to prevent uncer-
  1272. tanties in the size of the data field.
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282. HEALLED  ON|OFF                                 Default: OFF
  1283.  
  1284.  
  1285. Parameters:
  1286.  
  1287.      ON        The  TNC  will "dither" the CON and STA LEDs.
  1288.  
  1289.      OFF       The  TNC will control the CON and STA LEDs in 
  1290.            normal fashion.
  1291.  
  1292.  
  1293. This  command  allows the user to redefine the functions  of 
  1294. the two CPU controllable LEDs (i.e.  the STAtus and  CONnect 
  1295. LEDs).
  1296.  
  1297. When  HEALLED  is set ON,  the two LEDs flash in  a  seeming 
  1298. random fashion.   At a glance, the user may make a judgement 
  1299. on  whether  the software has crashed,  since the LEDs  will 
  1300. probably not flash if the software fails catastrophically.
  1301.  
  1302. With HEALLED set OFF, the LEDs function as before.
  1303.  
  1304.  
  1305. LCSTREAM  ON|OFF                                 Default: ON
  1306.  
  1307.  
  1308. Parameters:
  1309.  
  1310.      ON        The TNC will translate the chareacter immedi-
  1311.            ately following the STREAMSWITCH character to 
  1312.            upper case before processing it.
  1313.  
  1314.      OFF       The TNC will process the character immediate-
  1315.            ly following the STREAMSWITCH character as it 
  1316.            is entered.
  1317.  
  1318.  
  1319. When operating multi-connect,  the user must enter a  stream 
  1320. identifier  (default  A  through J) after  the  STREAMSWITCH 
  1321. character (default |) to select a new logical stream to send 
  1322. data.   Normally,  the  stream identifier must be  in  upper 
  1323. case, or an error message will result.
  1324.  
  1325. When LCSTREAM is ON, the character immediately following the 
  1326. streamswitch  character  is converted to upper  case  before 
  1327. being acted upon.   Thus,  the case (upper or lower) becomes 
  1328. insignificant.   Use of LCSTREAM is useful if you are typing 
  1329. in lower case and don't want to be bothered with remembering 
  1330. to switch to upper case when changing streams.
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337. NOMODE ON|OFF                                   Default: OFF
  1338.  
  1339.  
  1340. Parameters:
  1341.  
  1342.      ON        The  TNC  will only  switch  modes  (command, 
  1343.            converse  or transparent) upon explicit  com-
  1344.            mand.
  1345.  
  1346.      OFF       The  TNC will switch modes in accordance with 
  1347.            the setting of NEWMODE.
  1348.  
  1349.  
  1350. When  NOMODE  is  ON,  the TNC  will  never  change  between 
  1351. CONVERSE or TRANSPARENT mode to COMMAND mode (or vice-versa) 
  1352. on  its own.   Only user commands (CONV,  TRANS,  or ^C) may 
  1353. change the typein mode.
  1354.  
  1355. If NOMODE is OFF,  then automatic mode switching is  handled 
  1356. according to the setting of the NEWMODE command.
  1357.  
  1358.  
  1359.         SOFTWARE RELEASE NOTES FOR RELEASE 1.1.4
  1360.  
  1361.  
  1362.                FIXES
  1363.     
  1364. o - Transmitted  I-frames  under Level 2 Version 2  did  not 
  1365.     have     their P bits set at the appropriate times.   In 
  1366.     fact,  they     never had their P bits set. This has now 
  1367.     been  fixed.   The  last I-frame of a  multiple  I-frame 
  1368.     transmission has its P bit set. 
  1369.  
  1370. o - A mistake in the protocol state table was fixed. 
  1371.  
  1372. o - bbRAM  scanning  now checks all ten possible  connection  
  1373.     control structures (instead of just the first one). 
  1374.  
  1375.  
  1376.               CHANGES
  1377.        
  1378. o - AX25L2V2 defaults to the ON position.
  1379.  
  1380. o - Major change made to AX25L2V2 handling.   If retry limit 
  1381.     is exceeded, or the TNC receives a "disconnected" respo-
  1382.     nse to a poll, the connection is ended
  1383.  
  1384.     The old method (and the one proscribed) is fraught  with 
  1385.     problems  for  automated stations that can  not  recover 
  1386.     without an indication of loss of the connecion. 
  1387.  
  1388. The PERMCON control will replace the functionality of this 
  1389. aspect of AX25L2V2 which was removed.
  1390.  
  1391.  
  1392.             ENHANCEMENTS
  1393.  
  1394. o - 32K  of RAM is now expected.   Virtually all of the  new 
  1395.     space is used to enlarge existing queues within the TNC, 
  1396.     yielding  greater  performance especially at  faster  RF 
  1397.     data rates, and making the on-board message buffer capa-
  1398.     bility a bit more useful.  
  1399.  
  1400. o - The  MCOM  command decodes all control  fields  (invalid 
  1401.     ones are marked with ????). 
  1402.  
  1403. For  I  and S frames,  sequence number informnation is  also 
  1404. presented. 
  1405.  
  1406. Frames compatible with the AX.25 Level 2.0 standard are also 
  1407. decoded  as to the state of the Command/Response  (C/R)  and 
  1408. Poll/Final (P/F) bits.  
  1409.     Ex:  WA7GXD>KV7B <I C SO RO>:
  1410.      Hi Dan, 
  1411.  
  1412.      WA7GXD>KV7B <I C P S1 RO>:
  1413.      have you been on EIES lately?
  1414.      
  1415.      KV7B>WA7GXD <RR R F R2>
  1416.      KV7B>WA7GXD <I C P S1 R2>:
  1417.      I  was  just  thinking about that.   I  heard  that          
  1418.      @(username) made some real unbelievable comment  on          
  1419.      it!
  1420.  
  1421.      WA7GXD>KV7B <RR R F R2>
  1422.      WB2SPE>KV7B <C>
  1423.      KV7B>WB2SPE <DM>
  1424.      KV7B>WA7GXD <I C P S2 R2>:
  1425.      Good conditions now...
  1426.  
  1427.      WA7GXD>KV7B <RR R F R3>
  1428.      WA7GXD>KV7B <I C P S2 R3>:
  1429.      Yes @(username) did.  It was quite remarkable. 
  1430.  
  1431. And so on.  See Chapter 9 Table 9-1 in your TNC 2 manual for 
  1432. a breakdown of the control field codes.  For complete infor-
  1433. mation  on  the AX.25 Level 2 Version 2.0  Protocol,  please 
  1434. refer  to  the ARRL AX.25 Protocal  Specification  document, 
  1435. available from ARRL for $10.00.
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.                NEW COMMANDS
  1448.  
  1449. CBELL ON:OFF                                   Default: OFF
  1450.  
  1451. Parameters:
  1452.  
  1453.      ON           Connect bell enabled
  1454.  
  1455.     OFF           Connect bell disabled
  1456.  
  1457. This command is used to control whether an ASCII $O7  (BELL) 
  1458. character is sent as part of the connected message. 
  1459.  
  1460. When  set  ON,  the bell character immediately procedes  the 
  1461. asterisk portion of the connected message, e.g.:
  1462.  
  1463.      <BELL>*** Connected to: <callsign>
  1464.  
  1465.  
  1466.  
  1467. CM5GDISC ON:OFF                                Default: OFF
  1468.  
  1469. Parameters:
  1470.  
  1471.      ON          Automatic disconnect enabled
  1472.      
  1473.      OFF         Automatic disconnect disabled
  1474.  
  1475. This  command  controls whether the TNC 2 will  iniitiate  a 
  1476. disconnect sequence after it is connected to. 
  1477.  
  1478. If  CMSG is OFF,  or CTEXT has no connected  text,  the  TNC 
  1479. initiates  a disconnect immediately upon receiving  informa-
  1480. tion or acknowledgement frames from the other station.  
  1481.  
  1482. If CMSG is ON end CTEXT contains some text information,  the 
  1483. TNC  initiates a disconnect after the packet containing con-
  1484. nect text (CTEXT) is acknowledged. 
  1485.  
  1486. This  command may be useful to bulletin board  operators  or 
  1487. others  with  a need to send a short  message,  confirm  its 
  1488. receipt, and disconnect.  
  1489.  
  1490. NOTE:     Use  this  command with care - If you find  you're 
  1491.       able to receive connects, yet never get data, it's 
  1492.       possible  CMSGDisc has been left  on.   It's  also 
  1493.       possible   is  that  RS-232  DCD  is  holding  the 
  1494.       terminal  off -- see the TNC 2 System  Manual  for 
  1495.       details on hardware flow control. 
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502. LFIGNORE ON:OFF                                Default: OFF
  1503.  
  1504. Parameters: 
  1505.  
  1506.      ON          TNC will ignore <LF> characters. 
  1507.  
  1508.      OFF         TNC will respond to <LF> characters. 
  1509.  
  1510. This  command controls whether TNC 2 responds to ASCII  Lind 
  1511. Feed  (<LF>  $OA) characters or ignores them in command  and 
  1512. conerse modes. 
  1513.  
  1514. When  turned  on,  line feeds are totally ignored except  in 
  1515. transparent mode.  
  1516.  
  1517. New HEALTH Counters
  1518.  
  1519. BBfailed n :   Counts number of times bbRAM checksum was  in 
  1520.            error. 
  1521.  
  1522. TXQovflw n :   Counts how many times frames were discarded 
  1523.            because the outgoing frame queue was  too 
  1524.            small.
  1525.  
  1526.         SOFTWARE RELEASE NOTES FOR RELEASE 1.1.5  
  1527.  
  1528. This  document  describes the differents between the  latest 
  1529. release  1.1.5  and  the previous (1.1.4)  release  of  TAPR 
  1530. software for the TNC 2.  
  1531.  
  1532. The new object image occupies almost 0X45FF bytes of EPROM. 
  1533.  
  1534.             NEW COMMAND  
  1535.  
  1536. BBSMSGS ON:OFF                                 Default: OFF
  1537.  
  1538. This command controls how the TNC displays certain  messages 
  1539. in  command and CONVERSE modes.   The messages affected  are 
  1540. described below:  
  1541.  
  1542.        MESSAGE          EFFECT WHEN BBSMSGS ON
  1543.  
  1544. ***CONNECTED to xxxx   -A newline is added just before"***"
  1545.  
  1546. ***DISCONNECTED        -           "             "
  1547.  
  1548. ***retry limit exceeded-           "             "
  1549.  
  1550. ***xxxx Busy           -           "             "
  1551.  
  1552. ***FRMR sent           -           "             "
  1553.  
  1554. ***FRMR rcvd           -           "             "
  1555.  
  1556. ***Connect request:xxxx-This message is omitted. 
  1557.  
  1558. The BBSMSGS command is primarily useful for host  operation.  
  1559. Primarily  with  WORLI and like bulletin board systems  that 
  1560. require  link status messages to begin in the  first  output 
  1561. column.
  1562.  
  1563. The  connect request message is omitted during BBSMSGS mode.  
  1564. This  should  be most useful for  preventing  corruption  of 
  1565. messages when forwarding with small frames.  
  1566.  
  1567.  
  1568. TXTMO : Counter                                 Default: 0                                            
  1569.  
  1570. TXTMO  is  a  new addition to the  TNC  health-group.   This 
  1571. register may accumulate counts as the TNC succesfully  reco-
  1572. vers  from HDLC transmitter timeouts.   This is not a useful 
  1573. command for the majority of the users.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.                FIXES
  1579.  
  1580. o  -  Release 1.1.4 suffered from a spurious condition where 
  1581.       the  HDLC  transmitter  would  time  out.   When  this 
  1582.       happened.  TXQOVFLW  would typically show  a  non-zero 
  1583.       count.  Release 1.1.5 incorporates an HDLC transmitter
  1584.       timeout  feature  to  capture  and  recover  from  the 
  1585.       timeout error.
  1586.  
  1587. o  -  DWAIT operation has been fixed.
  1588.  
  1589.  
  1590. ****************************************************************************
  1591. | Above fix corrects the DIGI HANG problem when used in DIGI mode.  When   | 
  1592. | used as an unattended DIGI - BUG in 1.1.4 caused TNC not to respond.     |
  1593. | The only way to recover was to reset TNC.  This has been fixed in 1.1.5. |
  1594. ****************************************************************************
  1595.  
  1596. [EOF]
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.              MFJ-40A/40B/40C
  1612.       UPDATE KIT FOR TNC 2 VERSION 2, RELEASE 1.1.5              
  1613.  
  1614. This kit contains one 27C256 EPROM with Release 1.1.5 software
  1615. and one instruction sheets. MFJ-40A contains software 
  1616. release 1.1.5-16K for 16K RAM operation.   MFJ-40B contains
  1617. software release 1.1.5-32K EPROM and a 32K RAM.  MFJ-40C contains 
  1618. software release 1.1.5-32K EPROM without 32K RAM.         
  1619.  
  1620.       INSTALLATION OF MFJ-40A FOR 16K RAM OPERATION
  1621. 1.  Remove all power from the TNC 2.  
  1622. 2.  Remove the cover by removing the mounting screws on the side 
  1623.     of the cabinets.  
  1624. 3.  Remove JMP 5 jumper.  This disconnects the Lithium battery.
  1625. 4.  Carefully remove the EPROM (U23, 27256) from the TNC 
  1626.     2 board.  Make note of the orientation of the IC. 
  1627. 5.  Install the new EPROM containing 1.1.5-16K software on 
  1628.     the TNC 2 board at U23.  Make sure that no IC pins are 
  1629.     bent under the IC.  Make sure that the notch is pointed in
  1630.     the same direction as the old EPROM.  
  1631. 6.  Install JMP5 jumper.  
  1632. 7.  Replace the cover of the cabinet.    
  1633. 8.  Apply power to the TNC 2.  
  1634.  
  1635.     INSTALLATION OF MFJ-40B/40C FOR 32K RAM OPERATION
  1636.  
  1637. 1.  Remove all power from the TNC 2. 
  1638. 2.  Remove the cover by removing the mounting screws on the 
  1639.     side of the cabinets. 
  1640. 3.  Remove JMP5 jumper.  This disconnects the Lithium 
  1641.     battery. 
  1642. 4.  Remove 8K RAMs at U24 and U25. 
  1643. 5.  FOR MFJ-1270:  Remove circuit board from chassic.  Cut the 
  1644.     trace that is connected between the center pad and the pad 
  1645.     closest to R29 of JMP 12.  Connect a jumper wire between the 
  1646.     center pad and the pad closest to C28 of JMP 12.  Re-install the 
  1647.     circuit board.
  1648.     FOR MFJ-1270B AND MFJ-1274:  A removable jumper for JMP12 is 
  1649.     provided.  Remove the jumper from pin 2 and 3 of JMP12 and 
  1650.     install it on pin 1 and 2 of JMP12.
  1651. 6.  Install 32K RAM chip at U25 (U24 is left unused).  Some 
  1652.     32K RAMs which may be used are NEC 43256C-15L, Hitachi 
  1653.     HM64456L-15 or HM62256L-15 and Toshiba 55257PL-15.  
  1654.     NOTE: If you purchased the MFJ-40C update, you must supply 
  1655.     your own 32K RAM.  This EPROM will not operate with 16K RAM.
  1656. 7.  Carefully remove the EPROM (U23, 27256) from the TNC 2 
  1657.     board.  Make note of the orientation of the IC.  
  1658. 8.  Install the new EPROM with 1.1.5-32K software on the TNC 
  1659.     2 board at U23.  Make sure that no IC pins are bent 
  1660.     under the IC.  Make sure that the notch on the IC is 
  1661.     pointed in the same direction as the old EPROM.  
  1662. 9.  Install JMP5 jumper. 
  1663. 10. Replace the cover of the cabinet.
  1664. 11. Apply power to the TNC2.  
  1665.  
  1666.  
  1667. The 1.1.5-16K and 1.1.5-32K software releases contain all 
  1668. FIXES, CHANGES AND ADDITIONS of the 1.1.4 and 1.1.3 releases.
  1669.  
  1670.  
  1671.       SOFTWARE RELEASE NOTES FOR RELEASE 1.1.3
  1672.  
  1673.                FIXES
  1674.  
  1675.      o- When  AX25L2V2  is ON,  the TNC now  answers  L2  UI 
  1676.      frames  with P and C set with either:  RR if  connected 
  1677.      (regardless  of rcvr flow control state),  or DM if not 
  1678.      connected.
  1679.  
  1680.      o- Path for SABM received while in link-setup state  is 
  1681.      not  checked.   This corrects earlier operation where a 
  1682.      self-connect via an odd number of different digipeaters 
  1683.      fails.
  1684.  
  1685.      o- T2  <RESPTIME>  utilization corrected  for  the  2nd 
  1686.      through nth link
  1687.  
  1688.      o- FULLDUP operation restored
  1689.  
  1690.      o- Channel capture during busy times improved
  1691.  
  1692.      o- NOMODE bug, where the 'connect mode' setting was not 
  1693.      used  on received SABMS has been corrected.   This  bug 
  1694.      may  have  caused  the TNC to enter a  state  where  it 
  1695.      seemed  like  the  TNC died,  when it actually  was  in 
  1696.      TRANSparent mode.
  1697.  
  1698.               CHANGES 
  1699.  
  1700.      o- BEACONS not sent if BTEXT is null
  1701.  
  1702.      o- RESPTIME default now at 5; i.e. 500ms
  1703.  
  1704.  
  1705.              ADDITIONS
  1706.  
  1707.      o- RXBLOCK command
  1708.  
  1709.      o- TNC "Health" feature group installed
  1710.  
  1711. Fourteen counters have been added to TNC 2.  All of them are 
  1712. 16 bits wide, and are ALWAYS initialized to 0000 on power up 
  1713. or "RESTART".
  1714.  
  1715.      o- ASYRXOVR:   Increases  when  the software  does  not 
  1716.             service  the  asynchronous  receiver  in 
  1717.             time.   Indicates data from the user  to 
  1718.             the  TNC is being dropped.   This  error 
  1719.             counter  should  never  become  non-zero 
  1720.             under supported data rates.
  1721.  
  1722.      o- DIGISENT:   Each frame digipeated by this TNC causes 
  1723.             the counter to increase.
  1724.  
  1725.      o- HOVRERR:    Increases  when  HDLC  receiver  is  not 
  1726.             serviced  rapidly  enough  and  data  is 
  1727.             lost.   This counter should never incre-
  1728.             ment at any supported data rate.
  1729.  
  1730.      o- HUNDRERR:   Increases  when the HDLC transmitter  is 
  1731.             not  serviced rapidly enough and  frames 
  1732.             are aborted.   This counter should never 
  1733.             be non-zero at any supported data rate.
  1734.  
  1735.      o- RCVDFRMR:   Increases  when Frame reject frames  are 
  1736.             received from a connected station.
  1737.  
  1738.      o- RCVDIFRA:   Increases  for  each reception of  an  I 
  1739.             frame from a connectee.
  1740.  
  1741.      o- RCVDREJ:    Increases  for each reception of an REJ-
  1742.             ect frame from a connectee.
  1743.  
  1744.      o- RCVDSABM:   Each  received  SABM frame addressed  to 
  1745.             the  TNC causes this counter to be  inc-
  1746.             reased by one.
  1747.  
  1748.      o- RXCOUNT:    Increases  when  any frame  is  received 
  1749.             with good CRC (or any CRC if HGARBAGE is 
  1750.             turned on).
  1751.  
  1752.      o- RXERRORS:   Increments each time a received frame is 
  1753.             thrown  out due to it being  too  short, 
  1754.             suffering  overrun(s),   or it having  a 
  1755.             bad  CRC.   Latter occurs only when  CRC 
  1756.             checking  is enabled (i.e.  HGARBAGE  is 
  1757.             OFF).  This counter will often increment 
  1758.             in the presence of noise.
  1759.  
  1760.      o- SENTFRMR:   Increments  each  time  a  Frame  reject 
  1761.             frame is transmitted.
  1762.  
  1763.      o- SENTIFRA:   Increases by one each time an I frame is 
  1764.             sent.
  1765.  
  1766.      o- SENTREJ:    Whenever  a REJect frame is transmitted, 
  1767.             this counter is incremented.
  1768.  
  1769.      o- TXCOUNT:    Incremented whenever a frame is correct-
  1770.             ly transmitted.
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776. The following information should be inserted into the DISPLAY command.
  1777.  
  1778. DISPLAY HEALTH
  1779.  
  1780. The counters just described,  and the setting of HEALLED are 
  1781. displayed in response to the health inquiry.
  1782.  
  1783.  
  1784.             New Commands
  1785.  
  1786. AX25L2V2 ON|OFF                                 Default: OFF
  1787.  
  1788.  
  1789. Parameters:
  1790.  
  1791.      ON        The  TNC  will use AX.25 Level 2 Version  2.0 
  1792.            protocol.
  1793.  
  1794.      OFF       The  TNC  will use AX.25 Level 2 Version  1.0 
  1795.            protocol.
  1796.  
  1797. Some  implementations of the earlier version of AX.25 proto-
  1798. col (e.g., TAPR's TNC 1) won't properly digipeat version 2.0 
  1799. AX.25 packets.  This command exists to provide compatibility 
  1800. with these other TNCs until their software has been updated.
  1801.  
  1802. During  the  protocol  transition  period,  you  should  set 
  1803. AX25L2V2 OFF.
  1804.  
  1805. After your local area TNCs are updated to the newer protocol 
  1806. version, you should set AX25L2V2 ON.
  1807.  
  1808.  
  1809.  
  1810.  
  1811.  
  1812.  
  1813.  
  1814.  
  1815.  
  1816.  
  1817.  
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.  
  1830. RXBLOCK ON|OFF                                  Default: OFF
  1831.  
  1832.  
  1833. Parameters:
  1834.  
  1835.      ON        The  TNC  will send data to the  terminal  in 
  1836.            RXBLOCK format.
  1837.  
  1838.      OFF       The  TNC  will send data to the  terminal  in 
  1839.            standard format.
  1840.  
  1841.  
  1842. RXBLOCK is designed for automated operations, such as packet 
  1843. bulletin  board  stations.   It  is intended  to  help  such 
  1844. systems   discriminate  between  data  received   from   the 
  1845. connected station and TNC-generated messages.
  1846.  
  1847. Correct  operation  of  RXBLOCK is dependant  on  the  AWLEN 
  1848. parameter getting set to 8 (bits) since the character FF hex 
  1849. marks the beginning of a recieved data unit header.
  1850.  
  1851. When  RXBLOCK is on,  data from other stations will be  sent 
  1852. >from the TNC in the following format:
  1853.  
  1854.    ------------------------------------------------------
  1855.   |  $FF   |  L0  |  L1  |  PID  |       DATA            |
  1856.    ------------------------------------------------------
  1857.  
  1858.   ( prefix )(  length   ) ( pid ) (      data            )
  1859.  
  1860. The fields above are defined as follows:
  1861.  
  1862. prefix    $FF  ::=  A character with all 8 bits set
  1863. length    L0   ::=  The  high  order  length  of  the  data, 
  1864.             length,  and  pid fields logically  ORed 
  1865.             with the value $F0
  1866.       L1   ::=  The  low  order  length  of  the   data, 
  1867.             length, and pid fields
  1868. pid       PID  ::=  The  Protocol  IDentifier byte  received 
  1869.             for the following data field
  1870. data      DATA ::=  [Optional], variable length data
  1871.  
  1872.  
  1873. For  best  operation it is suggested  that  parameters  like 
  1874. AUTOLF,  MFILTER etc.  be set OFF in order to prevent uncer-
  1875. tanties in the size of the data field.
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885. HEALLED  ON|OFF                                 Default: OFF
  1886.  
  1887.  
  1888. Parameters:
  1889.  
  1890.      ON        The  TNC  will "dither" the CON and STA LEDs.
  1891.  
  1892.      OFF       The  TNC will control the CON and STA LEDs in 
  1893.            normal fashion.
  1894.  
  1895.  
  1896. This  command  allows the user to redefine the functions  of 
  1897. the two CPU controllable LEDs (i.e.  the STAtus and  CONnect 
  1898. LEDs).
  1899.  
  1900. When  HEALLED  is set ON,  the two LEDs flash in  a  seeming 
  1901. random fashion.   At a glance, the user may make a judgement 
  1902. on  whether  the software has crashed,  since the LEDs  will 
  1903. probably not flash if the software fails catastrophically.
  1904.  
  1905. With HEALLED set OFF, the LEDs function as before.
  1906.  
  1907.  
  1908. LCSTREAM  ON|OFF                                 Default: ON
  1909.  
  1910.  
  1911. Parameters:
  1912.  
  1913.      ON        The TNC will translate the chareacter immedi-
  1914.            ately following the STREAMSWITCH character to 
  1915.            upper case before processing it.
  1916.  
  1917.      OFF       The TNC will process the character immediate-
  1918.            ly following the STREAMSWITCH character as it 
  1919.            is entered.
  1920.  
  1921.  
  1922. When operating multi-connect,  the user must enter a  stream 
  1923. identifier  (default  A  through J) after  the  STREAMSWITCH 
  1924. character (default |) to select a new logical stream to send 
  1925. data.   Normally,  the  stream identifier must be  in  upper 
  1926. case, or an error message will result.
  1927.  
  1928. When LCSTREAM is ON, the character immediately following the 
  1929. streamswitch  character  is converted to upper  case  before 
  1930. being acted upon.   Thus,  the case (upper or lower) becomes 
  1931. insignificant.   Use of LCSTREAM is useful if you are typing 
  1932. in lower case and don't want to be bothered with remembering 
  1933. to switch to upper case when changing streams.
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940. NOMODE ON|OFF                                   Default: OFF
  1941.  
  1942.  
  1943. Parameters:
  1944.  
  1945.      ON        The  TNC  will only  switch  modes  (command, 
  1946.            converse  or transparent) upon explicit  com-
  1947.            mand.
  1948.  
  1949.      OFF       The  TNC will switch modes in accordance with 
  1950.            the setting of NEWMODE.
  1951.  
  1952.  
  1953. When  NOMODE  is  ON,  the TNC  will  never  change  between 
  1954. CONVERSE or TRANSPARENT mode to COMMAND mode (or vice-versa) 
  1955. on  its own.   Only user commands (CONV,  TRANS,  or ^C) may 
  1956. change the typein mode.
  1957.  
  1958. If NOMODE is OFF,  then automatic mode switching is  handled 
  1959. according to the setting of the NEWMODE command.
  1960.  
  1961.  
  1962.         SOFTWARE RELEASE NOTES FOR RELEASE 1.1.4
  1963.  
  1964.  
  1965.                FIXES
  1966.     
  1967. o - Transmitted  I-frames  under Level 2 Version 2  did  not 
  1968.     have     their P bits set at the appropriate times.   In 
  1969.     fact,  they     never had their P bits set. This has now 
  1970.     been  fixed.   The  last I-frame of a  multiple  I-frame 
  1971.     transmission has its P bit set. 
  1972.  
  1973. o - A mistake in the protocol state table was fixed. 
  1974.  
  1975. o - bbRAM  scanning  now checks all ten possible  connection  
  1976.     control structures (instead of just the first one). 
  1977.  
  1978.  
  1979.               CHANGES
  1980.        
  1981. o - AX25L2V2 defaults to the ON position.
  1982.  
  1983. o - Major change made to AX25L2V2 handling.   If retry limit 
  1984.     is exceeded, or the TNC receives a "disconnected" respo-
  1985.     nse to a poll, the connection is ended
  1986.  
  1987.     The old method (and the one proscribed) is fraught  with 
  1988.     problems  for  automated stations that can  not  recover 
  1989.     without an indication of loss of the connecion. 
  1990.  
  1991. The PERMCON control will replace the functionality of this 
  1992. aspect of AX25L2V2 which was removed.
  1993.  
  1994.  
  1995.             ENHANCEMENTS
  1996.  
  1997. o - 32K  of RAM is now expected.   Virtually all of the  new 
  1998.     space is used to enlarge existing queues within the TNC, 
  1999.     yielding  greater  performance especially at  faster  RF 
  2000.     data rates, and making the on-board message buffer capa-
  2001.     bility a bit more useful.  
  2002.  
  2003. o - The  MCOM  command decodes all control  fields  (invalid 
  2004.     ones are marked with ????). 
  2005.  
  2006. For  I  and S frames,  sequence number informnation is  also 
  2007. presented. 
  2008.  
  2009. Frames compatible with the AX.25 Level 2.0 standard are also 
  2010. decoded  as to the state of the Command/Response  (C/R)  and 
  2011. Poll/Final (P/F) bits.  
  2012.     Ex:  WA7GXD>KV7B <I C SO RO>:
  2013.      Hi Dan, 
  2014.  
  2015.      WA7GXD>KV7B <I C P S1 RO>:
  2016.      have you been on EIES lately?
  2017.      
  2018.      KV7B>WA7GXD <RR R F R2>
  2019.      KV7B>WA7GXD <I C P S1 R2>:
  2020.      I  was  just  thinking about that.   I  heard  that          
  2021.      @(username) made some real unbelievable comment  on          
  2022.      it!
  2023.  
  2024.      WA7GXD>KV7B <RR R F R2>
  2025.      WB2SPE>KV7B <C>
  2026.      KV7B>WB2SPE <DM>
  2027.      KV7B>WA7GXD <I C P S2 R2>:
  2028.      Good conditions now...
  2029.  
  2030.      WA7GXD>KV7B <RR R F R3>
  2031.      WA7GXD>KV7B <I C P S2 R3>:
  2032.      Yes @(username) did.  It was quite remarkable. 
  2033.  
  2034. And so on.  See Chapter 9 Table 9-1 in your TNC 2 manual for 
  2035. a breakdown of the control field codes.  For complete infor-
  2036. mation  on  the AX.25 Level 2 Version 2.0  Protocol,  please 
  2037. refer  to  the ARRL AX.25 Protocal  Specification  document, 
  2038. available from ARRL for $10.00.
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.                NEW COMMANDS
  2051.  
  2052. CBELL ON:OFF                                   Default: OFF
  2053.  
  2054. Parameters:
  2055.  
  2056.      ON           Connect bell enabled
  2057.  
  2058.     OFF           Connect bell disabled
  2059.  
  2060. This command is used to control whether an ASCII $O7  (BELL) 
  2061. character is sent as part of the connected message. 
  2062.  
  2063. When  set  ON,  the bell character immediately procedes  the 
  2064. asterisk portion of the connected message, e.g.:
  2065.  
  2066.      <BELL>*** Connected to: <callsign>
  2067.  
  2068.  
  2069.  
  2070. CM5GDISC ON:OFF                                Default: OFF
  2071.  
  2072. Parameters:
  2073.  
  2074.      ON          Automatic disconnect enabled
  2075.      
  2076.      OFF         Automatic disconnect disabled
  2077.  
  2078. This  command  controls whether the TNC 2 will  iniitiate  a 
  2079. disconnect sequence after it is connected to. 
  2080.  
  2081. If  CMSG is OFF,  or CTEXT has no connected  text,  the  TNC 
  2082. initiates  a disconnect immediately upon receiving  informa-
  2083. tion or acknowledgement frames from the other station.  
  2084.  
  2085. If CMSG is ON end CTEXT contains some text information,  the 
  2086. TNC  initiates a disconnect after the packet containing con-
  2087. nect text (CTEXT) is acknowledged. 
  2088.  
  2089. This  command may be useful to bulletin board  operators  or 
  2090. others  with  a need to send a short  message,  confirm  its 
  2091. receipt, and disconnect.  
  2092.  
  2093. NOTE:     Use  this  command with care - If you find  you're 
  2094.       able to receive connects, yet never get data, it's 
  2095.       possible  CMSGDisc has been left  on.   It's  also 
  2096.       possible   is  that  RS-232  DCD  is  holding  the 
  2097.       terminal  off -- see the TNC 2 System  Manual  for 
  2098.       details on hardware flow control. 
  2099.  
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105. LFIGNORE ON:OFF                                Default: OFF
  2106.  
  2107. Parameters: 
  2108.  
  2109.      ON          TNC will ignore <LF> characters. 
  2110.  
  2111.      OFF         TNC will respond to <LF> characters. 
  2112.  
  2113. This  command controls whether TNC 2 responds to ASCII  Lind 
  2114. Feed  (<LF>  $OA) characters or ignores them in command  and 
  2115. conerse modes. 
  2116.  
  2117. When  turned  on,  line feeds are totally ignored except  in 
  2118. transparent mode.  
  2119.  
  2120. New HEALTH Counters
  2121.  
  2122. BBfailed n :   Counts number of times bbRAM checksum was  in 
  2123.            error. 
  2124.  
  2125. TXQovflw n :   Counts how many times frames were discarded 
  2126.            because the outgoing frame queue was  too 
  2127.            small.
  2128.  
  2129.         SOFTWARE RELEASE NOTES FOR RELEASE 1.1.5  
  2130.  
  2131. This  document  describes the differents between the  latest 
  2132. release  1.1.5  and  the previous (1.1.4)  release  of  TAPR 
  2133. software for the TNC 2.  
  2134.  
  2135. The new object image occupies almost 0X45FF bytes of EPROM. 
  2136.  
  2137.             NEW COMMAND  
  2138.  
  2139. BBSMSGS ON:OFF                                 Default: OFF
  2140.  
  2141. This command controls how the TNC displays certain  messages 
  2142. in  command and CONVERSE modes.   The messages affected  are 
  2143. described below:  
  2144.  
  2145.        MESSAGE          EFFECT WHEN BBSMSGS ON
  2146.  
  2147. ***CONNECTED to xxxx   -A newline is added just before"***"
  2148.  
  2149. ***DISCONNECTED        -           "             "
  2150.  
  2151. ***retry limit exceeded-           "             "
  2152.  
  2153. ***xxxx Busy           -           "             "
  2154.  
  2155. ***FRMR sent           -           "             "
  2156.  
  2157. ***FRMR rcvd           -           "             "
  2158.  
  2159. ***Connect request:xxxx-This message is omitted. 
  2160.  
  2161. The BBSMSGS command is primarily useful for host  operation.  
  2162. Primarily  with  WORLI and like bulletin board systems  that 
  2163. require  link status messages to begin in the  first  output 
  2164. column.
  2165.  
  2166. The  connect request message is omitted during BBSMSGS mode.  
  2167. This  should  be most useful for  preventing  corruption  of 
  2168. messages when forwarding with small frames.  
  2169.  
  2170.  
  2171. TXTMO : Counter                                 Default: 0                                            
  2172.  
  2173. TXTMO  is  a  new addition to the  TNC  health-group.   This 
  2174. register may accumulate counts as the TNC succesfully  reco-
  2175. vers  from HDLC transmitter timeouts.   This is not a useful 
  2176. command for the majority of the users.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.                FIXES
  2182.  
  2183. o  -  Release 1.1.4 suffered from a spurious condition where 
  2184.       the  HDLC  transmitter  would  time  out.   When  this 
  2185.       happened.  TXQOVFLW  would typically show  a  non-zero 
  2186.       count.  Release 1.1.5 incorporates an HDLC transmitter
  2187.       timeout  feature  to  capture  and  recover  from  the 
  2188.       timeout error.
  2189.  
  2190. o  -  DWAIT operation has been fixed.
  2191.  
  2192.  
  2193. *==========================================================================*
  2194. | Above fix corrects the DIGI HANG problem experienced in DIGI mode.  When | 
  2195. | used as an unattended DIGI - A BUG in 1.1.4 caused TNC not to respond.   |
  2196. | The only way to recover was to reset TNC.  This has been fixed in 1.1.5. |
  2197. | Version 1.1.5 will work in any 100% compatible TNC 2 unit.               |
  2198. *==========================================================================*
  2199.  
  2200. [EOF]
  2201.  
  2202.  
  2203. 11-Nov-87 01:18:32-EST,1080;000000000000
  2204. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Nov 87 01:18-EST
  2205. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09486@EDDIE.MIT.EDU>; Tue, 10 Nov 87 21:12:10 EST
  2206. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA09472@EDDIE.MIT.EDU>; Tue, 10 Nov 87 21:11:42 EST
  2207. Date: Tue, 10 Nov 1987  19:10 MST
  2208. Message-Id: <KPETERSEN.12349627581.BABYL@SIMTEL20.ARPA>
  2209. Sender: KPETERSEN@SIMTEL20.ARPA
  2210. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2211. To: Info-Cpm@SIMTEL20.ARPA
  2212. Cc: Info-Micro@BRL.ARPA, Info-HZ100@RADC-TOPS20.ARPA, Info-IBMPC@C.ISI.EDU,
  2213.     packet-radio@EDDIE.MIT.EDU, Info-Hams@SIMTEL20.ARPA
  2214. Subject: SIMTEL20 device name change
  2215.  
  2216. We have doubled the disk storage on SIMTEL20.  In the process some
  2217. changes had to be made.  All directories, except those listed below,
  2218. which were previously addressed as device PD: must now be addressed as
  2219. PD1: These include <CPM*>, <MISC*> and <MSDOS*>.
  2220.  
  2221. The following directories must be addressed as device PD2: <ADA*>,
  2222. <CM*>, <VHDL*>, <UNIX*>, <MACINTOSH*>, and <PCNET>.
  2223.  
  2224. --Keith Petersen
  2225. 11-Nov-87 17:04:12-EST,977;000000000000
  2226. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Nov 87 17:04-EST
  2227. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA29646@EDDIE.MIT.EDU>; Wed, 11 Nov 87 13:13:19 EST
  2228. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA29617@EDDIE.MIT.EDU>; Wed, 11 Nov 87 13:12:25 EST
  2229. Received: by june.cs.washington.edu (5.52.1/6.10)
  2230.     id AA10896; Wed, 11 Nov 87 10:13:24 PST
  2231. Return-Path: <sdcsvax!brian@ucbvax.berkeley.edu>
  2232. Message-Id: <8711111813.AA10896@june.cs.washington.edu>
  2233. Date: 11 Nov 87 04:17:42 GMT
  2234. From: sdcsvax!brian@ucbvax.berkeley.edu (Brian Kantor)
  2235. To: PACKET-RADIO@EDDIE.MIT.EDU
  2236. Subject: Re: ham domain
  2237. References: <326@n8emr.UUCP>
  2238. Reply-To: brian@sdcsvax.ucsd.edu (Brian Kantor)
  2239.  
  2240. Domain registration for the amateur world is in progress.  The people at
  2241. the NIC and I have been having productive discussions, and we hope to 
  2242. have something to announce soon - perhaps before the new year.
  2243.  
  2244.     Brian Kantor    WB6CYT  UC San Diego
  2245.  
  2246.  
  2247. 11-Nov-87 20:10:34-EST,1343;000000000000
  2248. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Nov 87 20:10-EST
  2249. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06584@EDDIE.MIT.EDU>; Wed, 11 Nov 87 18:31:23 EST
  2250. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06576@EDDIE.MIT.EDU>; Wed, 11 Nov 87 18:31:11 EST
  2251. Received: by june.cs.washington.edu (5.52.1/6.10)
  2252.     id AA20918; Wed, 11 Nov 87 15:32:06 PST
  2253. Return-Path: <hplabs!pyramid!voder!randy@eddie.mit.edu>
  2254. Message-Id: <8711112332.AA20918@june.cs.washington.edu>
  2255. Date: 11 Nov 87 02:15:25 GMT
  2256. From: hplabs!pyramid!voder!randy@eddie.mit.edu (Randy Flatness)
  2257. To: PACKET-RADIO@EDDIE.MIT.EDU
  2258. Subject: Software control programs for pk232 and ts440.
  2259. Keywords: pk232, ts440, software
  2260.  
  2261.  
  2262. I have been experimenting with the AEA pk232 for a couple
  2263. of months now, and find it to be quite impressive box!
  2264. But now I would like to expand it's operation.
  2265.  
  2266. What I am looking for is a control program which can control
  2267. the pk232 (and the ts440 radio) on an a pc or mac with more
  2268. features than a standard terminal emulator.
  2269.  
  2270. So, if anyone has developed such a program or knows about one
  2271. in public domain please let me know the details.
  2272.  
  2273. I have seen one advertised in the mags and would also be interested
  2274. in any user reports also.
  2275.  
  2276. 73, and thanks in advance.                  Randy Flatness
  2277.  
  2278.  
  2279. 11-Nov-87 20:55:19-EST,1343;000000000000
  2280. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 11 Nov 87 20:55-EST
  2281. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06584@EDDIE.MIT.EDU>; Wed, 11 Nov 87 18:31:23 EST
  2282. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06576@EDDIE.MIT.EDU>; Wed, 11 Nov 87 18:31:11 EST
  2283. Received: by june.cs.washington.edu (5.52.1/6.10)
  2284.     id AA20918; Wed, 11 Nov 87 15:32:06 PST
  2285. Return-Path: <hplabs!pyramid!voder!randy@eddie.mit.edu>
  2286. Message-Id: <8711112332.AA20918@june.cs.washington.edu>
  2287. Date: 11 Nov 87 02:15:25 GMT
  2288. From: hplabs!pyramid!voder!randy@eddie.mit.edu (Randy Flatness)
  2289. To: PACKET-RADIO@EDDIE.MIT.EDU
  2290. Subject: Software control programs for pk232 and ts440.
  2291. Keywords: pk232, ts440, software
  2292.  
  2293.  
  2294. I have been experimenting with the AEA pk232 for a couple
  2295. of months now, and find it to be quite impressive box!
  2296. But now I would like to expand it's operation.
  2297.  
  2298. What I am looking for is a control program which can control
  2299. the pk232 (and the ts440 radio) on an a pc or mac with more
  2300. features than a standard terminal emulator.
  2301.  
  2302. So, if anyone has developed such a program or knows about one
  2303. in public domain please let me know the details.
  2304.  
  2305. I have seen one advertised in the mags and would also be interested
  2306. in any user reports also.
  2307.  
  2308. 73, and thanks in advance.                  Randy Flatness
  2309.  
  2310.  
  2311. 12-Nov-87 02:51:01-EST,5683;000000000000
  2312. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Nov 87 02:51-EST
  2313. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13073@EDDIE.MIT.EDU>; Wed, 11 Nov 87 23:33:52 EST
  2314. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA13065@EDDIE.MIT.EDU>; Wed, 11 Nov 87 23:33:33 EST
  2315. Received: by june.cs.washington.edu (5.52.1/6.10)
  2316.     id AA27437; Wed, 11 Nov 87 20:34:43 PST
  2317. Return-Path: <delni.dec.com!goldstein@decwrl.dec.com>
  2318. Message-Id: <8711120434.AA27437@june.cs.washington.edu>
  2319. Date: 12 Nov 87 00:24:00 GMT
  2320. From: delni.dec.com!goldstein@decwrl.dec.com (Fred R. Goldstein dtn226-7388)
  2321. To: PACKET-RADIO@EDDIE.MIT.EDU
  2322. Subject: re: Level 3 protocols, some comments
  2323.  
  2324. In reply to KC2WZ's questions, here's my mildly opinionated answer.  
  2325. I'll try to avoid flamage.
  2326.  
  2327. >   1.  TCP/IP - which KA9Q, et al are proposing is the best way to go for
  2328. >       Level 3.  Why?  What are its advantages over the other protocols?  What
  2329. >       are is disadvantages? (Come now we know nothing is perfect.)
  2330.  
  2331.     "TCP/IP" (DDN Protocol Suite) has a few advantages.  It is a known,
  2332. working technology.  It is widely used outside hamdom, so there are 
  2333. existing implementations to check against and use if affordable.  It's 
  2334. free with Berkeley Unix.  It has the most popular applications 
  2335. (terminal, mail and file transfer) already defined.  Performance is OK.
  2336.  
  2337.     It is connectionless, which is better or worse than 
  2338. connection-oriented based on your religion (CONS or CLNS).  TCP (Layer 
  2339. 4) makes nice connections out of disjoint Layer 3 datagrams.  This means 
  2340. that every packet must be routed, but there's no need for the router 
  2341. ("gateway") to have knowledge of connections; that's only in the end 
  2342. nodes.  This could make for simpler gateways.  UDP supports 
  2343. connectionless applications too.
  2344.  
  2345.     There's no real smart routing in the KA9Q version of IP, just 
  2346. some clever table-lookup, but some of us are looking at writing an 
  2347. automatic routing program for it.  Addressing is a problem:  It's 32 bits, 
  2348. so you can't map in a call sign or anything.  Directories are thus needed.
  2349.  
  2350. >   2.  COSI - I'm not certain who developed the idea.  Again, why should this
  2351. >       be adopted as a Level 3 standard?  What are its advantages?  What are
  2352. >       its disadvantages?
  2353.  
  2354.     This comes from a few guys in New Jersey (RATTS?).  It's 
  2355. connection-oriented, recycling some X.25 Level 3 protocols.  Again a 
  2356. religious matter; it doesn't need a smart transport layer since the 
  2357. network keeps track of packets, but routers must keep track of virtual 
  2358. circuits along the way.  I don't think it's on the air yet.
  2359.  
  2360. >   3.  NET/ROM - Is this the same as COSI?  It SEEMS to be the way things are
  2361. >       going in the New Jersey/New York area on 2 meters.  Am I wrong?  Why 
  2362. >       should it be adopted?  What are its advantages?  Its disadvantages?
  2363.  
  2364.     This is a home-grown protocol which runs in TNC2s.  It's rather 
  2365. limited in size and scope due to its ROM distribution, but that makes it 
  2366. easy to build little networks in a hurry.  It uses datagrams internally 
  2367. but provides a connection-oriented interface to AX.25.  Good side: It's 
  2368. expedient. Bad side: It's inflexible (burned in ROM) and thus won't 
  2369. "grow up" to easily support a big nationwide network, unless it's 
  2370. reimplemented, at which point it's not so expedient.
  2371.  
  2372.     NET/ROM does beat the pants off of digipeating.
  2373.  
  2374. >   4.  OTHER PROTOCOLS?  Are there others be proposed?  These are the only
  2375. >       ones I have heard mentioned. As above what are the advantages and
  2376. >       disadvantages?
  2377.  
  2378.     I've proposed "AmOSInet", which is an OSI-derived datagram network.
  2379. Procedurally it's a lot like TCP/IP but the addressing is different,
  2380. using a two-level scheme (regions and sections).  The region is the 
  2381. Maidenhead and the station uses its call (or anything else) as its 
  2382. address within that section, so you don't need a directory.  This is 
  2383. just an architectural strawman now, not a product, and I expect it will 
  2384. evolve slowly out of TCP/IP.
  2385.  
  2386.     Down in Florida they have their own X.25L3-based connection 
  2387. oriented network.  Like COSI, it uses telephone area codes as the first 
  2388. part of the address.  Texas also has a local "Texnet" protocol, I think.
  2389.  
  2390. >   5.  Much of the work seems to centered are the IBM-PC and clones.
  2391. >       Obviously, these are very popular micros.  But there are a variety of
  2392. >       other makes which don't seem to be supported.  My machine (Tandy Color
  2393. >       Computer 3) is one example.  Other 6809/68000 machines also SEEM to be
  2394. >       left in the cold.  Is this true or just my impression?
  2395.  
  2396.     Phil's TCP/IP is being ported to several machines (the Mac is 
  2397. out, and I think Amiga too) and its source is as portable as they can 
  2398. make it.  Expect more 68k machines to be supported soon (where's the 
  2399. Atari ST version btw?)
  2400.  
  2401. >   6.  My final(?) question (for now), how to go about setting up the TNC
  2402. >       and computer to use Level 3?  Is it necessary that everyone has Level 3
  2403. >       running in their TNC or is this a waste?  I have a TAPR TNC-1 running
  2404. >       WA8DED's software.  Will I have to burn a new EPROM with the new code?
  2405. >       How will my computer be interfaced with the TNC?
  2406.  
  2407.     L3 doesn't run in the TNC, typically; it runs in the end node 
  2408. and maybe the gateway.  To use TCP/IP, it's best to run the TNC in KISS 
  2409. mode and let the PC handle the AX.25 procedures.  But you typically can
  2410. use "transparent" AX.25 on the TNC too.  NET/ROM, btw, eats a whole TNC 
  2411. which no longer supports terminals, just routing.  Stick it on a 
  2412. mountaiantop somewhere.
  2413.        fred k1io (FN42jk) goldstein@delni.dec.com
  2414.  
  2415.  
  2416. 12-Nov-87 21:38:02-EST,3039;000000000000
  2417. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Nov 87 21:38-EST
  2418. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05614@EDDIE.MIT.EDU>; Thu, 12 Nov 87 18:59:40 EST
  2419. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA05587@EDDIE.MIT.EDU>; Thu, 12 Nov 87 18:58:58 EST
  2420. Received: by june.cs.washington.edu (5.52.1/6.10)
  2421.     id AA27669; Thu, 12 Nov 87 16:00:03 PST
  2422. Return-Path: <rutgers!bellcore!faline!karn@eddie.mit.edu>
  2423. Message-Id: <8711130000.AA27669@june.cs.washington.edu>
  2424. Date: 12 Nov 87 20:27:47 GMT
  2425. From: rutgers!bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  2426. To: PACKET-RADIO@EDDIE.MIT.EDU
  2427. Subject: Re: Level 3 protocols, some comments
  2428. Summary: datagrams vs virtual circuits - regulatory considerations
  2429. References: <8711112140.AA05493@decwrl.dec.com>
  2430.  
  2431. >       It [TCP/IP] is connectionless, which is better or worse than 
  2432. > connection-oriented based on your religion...
  2433.  
  2434. There are many strong and objective technical arguments for
  2435. connectionless network protocols, especially over broadcast media like
  2436. radio. I therefore disagree with your use of the word "religion".
  2437. However, I'll not repeat them here since I've already given them many
  2438. times. But a recent development on the regulatory front gives added
  2439. impetus to use datagrams.
  2440.  
  2441. Australia's amateur packet radio regulations allow the use of any
  2442. protocol as long as *every packet* identifies the originator, the
  2443. station actually transmitting the packet (if different from the
  2444. originator), and the destination.  This is tantamount to REQUIRING a
  2445. datagram protocol at both the link and network layers. Furthermore, this
  2446. means that "protocol translation gateways" or any other mechanisms that
  2447. violate the end-to-end significance of the network layer addresses are
  2448. prohibited.
  2449.  
  2450. Australian hams were recently ordered to shut down their NET/ROM network
  2451. for this reason. Even though NET/ROM uses a perfectly acceptable
  2452. datagram network protocol internally, it is not spoken by the end users.
  2453. Rather, "uplink" and "downlink" sites act as protocol translation
  2454. gateways between "vanilla" AX.25 and the internal NET/ROM protocols.
  2455.  
  2456. It is not known whether the "identification" must be actual callsigns or
  2457. whether it can be a unique bit pattern that can be translated back into
  2458. a callsign if desired.  If the latter is true, IP addresses are
  2459. sufficient since their assignments are public and can be uniquely mapped
  2460. back into callsigns. In the former case, it would be fairly
  2461. straightforward to define an IP header option containing callsigns.
  2462.  
  2463. While Australia may be a relatively small (in population) country, it is
  2464. my understanding that many European countries are using their rules as a
  2465. model as they draft their own packet radio regulations.  There is
  2466. considerable irony here, since we've heard a lot from the COSI camp
  2467. about the need for "international acceptance" of amateur packet radio
  2468. protocols.  Yet the protocols they are pushing do not satisfy the
  2469. Australian identification requirements.
  2470.  
  2471. Phil
  2472.  
  2473.  
  2474. 12-Nov-87 22:09:50-EST,1394;000000000000
  2475. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Nov 87 22:09-EST
  2476. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06904@EDDIE.MIT.EDU>; Thu, 12 Nov 87 20:02:15 EST
  2477. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06897@EDDIE.MIT.EDU>; Thu, 12 Nov 87 20:02:02 EST
  2478. Received: from adam.dg.com by RELAY.CS.NET id aa29006; 12 Nov 87 19:34 EST
  2479. Received: by adam.DG.COM with sendmail; Thu, 12 Nov 87 19:34:00 est
  2480. Reply-To: Podsiadlo_Jim%WDS.CEO.DG.COM@adam.dg.com
  2481. Mmdf-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
  2482. Received: from WDS by adam.DG.COM with CEO; Thu, 12 Nov 87 16:18:54 EST
  2483. Date: Thu, 12 Nov 87 15:03:42 EST
  2484. From: Podsiadlo_Jim%wds.ceo.dg.com@RELAY.CS.NET
  2485. Message-Id: <29.002685@adam.DG.COM>
  2486. To: packet-radio%eddie.mit.edu@RELAY.CS.NET
  2487. Subject: AMPRNET and TCP/IP
  2488.  
  2489. I have been using TCP/IP in the Worcester area for some time now.
  2490. Although I have been very successful with the few stations out here, 
  2491. I would like to help get something more significant going. Is there 
  2492. any interest in really getting the "net" established. Maybe some more 
  2493. full time nodes, other than W1MX. Or maybe some higher data rates on 
  2494. 440. How about trying to link the Boston area into the pocket of 
  2495. activity that exists in the DC area, or even RI. Is anyone else 
  2496. trying to advance the state of AMPRNET in the area???????
  2497. 12-Nov-87 22:44:46-EST,1394;000000000000
  2498. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 12 Nov 87 22:44-EST
  2499. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06904@EDDIE.MIT.EDU>; Thu, 12 Nov 87 20:02:15 EST
  2500. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06897@EDDIE.MIT.EDU>; Thu, 12 Nov 87 20:02:02 EST
  2501. Received: from adam.dg.com by RELAY.CS.NET id aa29006; 12 Nov 87 19:34 EST
  2502. Received: by adam.DG.COM with sendmail; Thu, 12 Nov 87 19:34:00 est
  2503. Reply-To: Podsiadlo_Jim%WDS.CEO.DG.COM@adam.dg.com
  2504. Mmdf-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
  2505. Received: from WDS by adam.DG.COM with CEO; Thu, 12 Nov 87 16:18:54 EST
  2506. Date: Thu, 12 Nov 87 15:03:42 EST
  2507. From: Podsiadlo_Jim%wds.ceo.dg.com@RELAY.CS.NET
  2508. Message-Id: <29.002685@adam.DG.COM>
  2509. To: packet-radio%eddie.mit.edu@RELAY.CS.NET
  2510. Subject: AMPRNET and TCP/IP
  2511.  
  2512. I have been using TCP/IP in the Worcester area for some time now.
  2513. Although I have been very successful with the few stations out here, 
  2514. I would like to help get something more significant going. Is there 
  2515. any interest in really getting the "net" established. Maybe some more 
  2516. full time nodes, other than W1MX. Or maybe some higher data rates on 
  2517. 440. How about trying to link the Boston area into the pocket of 
  2518. activity that exists in the DC area, or even RI. Is anyone else 
  2519. trying to advance the state of AMPRNET in the area???????
  2520. 13-Nov-87 16:44:24-EST,1197;000000000000
  2521. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Nov 87 16:44-EST
  2522. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA24327@EDDIE.MIT.EDU>; Fri, 13 Nov 87 12:24:14 EST
  2523. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA24320@EDDIE.MIT.EDU>; Fri, 13 Nov 87 12:23:54 EST
  2524. Message-Id: <8711131723.AA24320@EDDIE.MIT.EDU>
  2525. Received: from DHHDESY3.BITNET by wiscvm.wisc.edu ; Fri, 13 Nov 87 11:23:53 CDT
  2526. Date:     13 NOV 87  16:20:11 MEZ
  2527. From: F33PAP%DHHDESY3.BITNET@wiscvm.wisc.edu
  2528. To: PACKET-RADIO@EDDIE.MIT.EDU
  2529. Subject:  Re: Repeater advice anyone?
  2530.  
  2531. Hello!
  2532. We are preparing for a duplex digipeater on 70cm. Just now it is only
  2533. AF in, AF out, without regeneration. The next step is a regenerator
  2534. with a K9NG state machine PROM. Yes, it should work! Clock a K9NG PROM
  2535. state machine with 16 times the data rate and use output bit 4 (I think)
  2536. as the regenerated data output.
  2537. We also want to have a TNC-2 with NET/ROM in parallel. The TNC-2 will
  2538. not transmit while the receiver is on... Just switch the data with the
  2539. key line of the TNC from the PROM to the TNC.
  2540. If you need more details, send me a note.
  2541. vy 73, Karl-Heinz, DK8HI, F33PAP@DHHDESY3.BITNET
  2542.  
  2543. 13-Nov-87 22:01:02-EST,1115;000000000000
  2544. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 13 Nov 87 22:01-EST
  2545. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04751@EDDIE.MIT.EDU>; Fri, 13 Nov 87 20:07:05 EST
  2546. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA04695@EDDIE.MIT.EDU>; Fri, 13 Nov 87 20:04:02 EST
  2547. Received: by LANL.GOV (5.54/1.14)
  2548.     id AA01037; Thu, 12 Nov 87 11:31:51 MST
  2549. Received: by MILNET-GW.GOV (5.54/5.17)
  2550.     id AA06520; Thu, 12 Nov 87 08:23:12 MST
  2551. Received: by a (5.51/5.17)
  2552.     id AA24458; Thu, 12 Nov 87 08:22:35 MST
  2553. Date: Thu, 12 Nov 87 08:22:35 MST
  2554. From: djw%a@LANL.GOV (Dave Wade)
  2555. Message-Id: <8711121522.AA24458@a>
  2556. To: PACKET-RADIO@eddie.mit.edu, ihnp4!homxb!hotps!ka2qhd!kc2wz@eddie.mit.edu
  2557. Subject: Re:  Level 3 protocols - some info?
  2558.  
  2559. Might I suggest that a good source of information on the questions you are
  2560. asking is:
  2561. "The Elements of Networking Style"
  2562. by M.A. Padlipsky
  2563. Published by Prentice-Hall., of Englewood Cliffs, N.J. 07632
  2564. ISBN 0-13-268129-3
  2565.  
  2566. You'll enjoy it more than you enjoy the usual fare here...  And,
  2567. you'll undoubtedly learn what you asked.  
  2568.  
  2569. Dave
  2570. WB5PFS
  2571. 14-Nov-87 08:36:54-EST,1441;000000000000
  2572. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Nov 87 08:36-EST
  2573. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14988@EDDIE.MIT.EDU>; Sat, 14 Nov 87 07:18:33 EST
  2574. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA14977@EDDIE.MIT.EDU>; Sat, 14 Nov 87 07:18:16 EST
  2575. Resent-Message-Id: <8711141218.AA14977@EDDIE.MIT.EDU>
  2576. Date: Friday, 13 November 1987  17:58-MST
  2577. Message-Id: <KPETERSEN.12350524696.BABYL@SIMTEL20.ARPA>
  2578. Sender: ZMTKeidel%UCIVMSA.BITNET@WISCVM.WISC.EDU
  2579. From: ZMTKeidel%UCIVMSA.BITNET@WISCVM.WISC.EDU
  2580. To: INFO-HAMS-REQUEST@SIMTEL20.ARPA
  2581. Subject:   AEA PK-232 control (terminal) program
  2582. Resent-From: KPETERSEN@SIMTEL20.ARPA
  2583. Resent-To: packet-radio@eddie.mit.edu
  2584. Resent-Date: Sat 14 Nov 1987 05:18-MST
  2585.  
  2586. I am interested in developing a control program which will interface
  2587. an Apple MacIntosh with the AEA PK-232.  However, I have heard that
  2588. there are not many HAMS with MacIntosh computers!  I have one, my
  2589. roomate has three, and even the engineers at AEA have Mac's.
  2590.  
  2591. Before I invest the time in writing a full-function program, which may
  2592. also include a control section for the most popular computer
  2593. controlled rigs such as the TS-440s, I would like to know if there is
  2594. interest and whether or not Hams do own MacIntosh computers!
  2595.  
  2596. Please respond directly to my bitnet address MKEIDE@UCI.BITNET or if
  2597. your software will allow it, MKEIDEL@UCI.BITNET.
  2598.  
  2599. KA6JAF--  73'S...
  2600. 14-Nov-87 11:45:24-EST,1451;000000000000
  2601. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Nov 87 11:45-EST
  2602. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA17862@EDDIE.MIT.EDU>; Sat, 14 Nov 87 10:34:08 EST
  2603. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA17855@EDDIE.MIT.EDU>; Sat, 14 Nov 87 10:33:57 EST
  2604. Resent-Message-Id: <8711141533.AA17855@EDDIE.MIT.EDU>
  2605. Date: Friday, 13 November 1987  09:31-MST
  2606. Message-Id: <KPETERSEN.12350560383.BABYL@SIMTEL20.ARPA>
  2607. Sender: <RME8650%TAMSIGMA.BITNET@WISCVM.WISC.EDU> (Robert Eden - N5GWY)
  2608. From: <RME8650%TAMSIGMA.BITNET@WISCVM.WISC.EDU> (Robert Eden - N5GWY)
  2609. To: info-hams@SIMTEL20.ARPA
  2610. Subject:   packet radio - VAX gateway
  2611. Resent-From: KPETERSEN@SIMTEL20.ARPA
  2612. Resent-To: packet-radio@eddie.mit.edu
  2613. Resent-Date: Sat 14 Nov 1987 08:34-MST
  2614.  
  2615.     I'm in the finishing stages of a gateway between the W0RLI mailbox network
  2616. and VAX mail.
  2617.  
  2618.     I've written a detached process that talks to a TNC over a standard VAX
  2619. serial port (LAT is ok) and uses that port to receive and transmit messages
  2620. to W0RLI mailboxes.  Mail is sent to VAX uses through the MAIL utility.
  2621.  
  2622.     Anyone who is interested in running this system should contact me and
  2623. I'll send the source and documentation.
  2624.  
  2625.        Robert Eden - N5GWY
  2626.  
  2627. RME8650@TAMSIGMA.BITNET  <<< first choice
  2628. RME8650@TAMVENUS.BITNET  <<< second choice
  2629.  
  2630. reden@sys1.uucp          <<< after Dec. 15th.
  2631. rgd059@mipl3.jpl.nasa.gov<<< if all else fails.
  2632. 14-Nov-87 13:58:28-EST,1451;000000000000
  2633. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 14 Nov 87 13:58-EST
  2634. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA17862@EDDIE.MIT.EDU>; Sat, 14 Nov 87 10:34:08 EST
  2635. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA17855@EDDIE.MIT.EDU>; Sat, 14 Nov 87 10:33:57 EST
  2636. Resent-Message-Id: <8711141533.AA17855@EDDIE.MIT.EDU>
  2637. Date: Friday, 13 November 1987  09:31-MST
  2638. Message-Id: <KPETERSEN.12350560383.BABYL@SIMTEL20.ARPA>
  2639. Sender: <RME8650%TAMSIGMA.BITNET@WISCVM.WISC.EDU> (Robert Eden - N5GWY)
  2640. From: <RME8650%TAMSIGMA.BITNET@WISCVM.WISC.EDU> (Robert Eden - N5GWY)
  2641. To: info-hams@SIMTEL20.ARPA
  2642. Subject:   packet radio - VAX gateway
  2643. Resent-From: KPETERSEN@SIMTEL20.ARPA
  2644. Resent-To: packet-radio@eddie.mit.edu
  2645. Resent-Date: Sat 14 Nov 1987 08:34-MST
  2646.  
  2647.     I'm in the finishing stages of a gateway between the W0RLI mailbox network
  2648. and VAX mail.
  2649.  
  2650.     I've written a detached process that talks to a TNC over a standard VAX
  2651. serial port (LAT is ok) and uses that port to receive and transmit messages
  2652. to W0RLI mailboxes.  Mail is sent to VAX uses through the MAIL utility.
  2653.  
  2654.     Anyone who is interested in running this system should contact me and
  2655. I'll send the source and documentation.
  2656.  
  2657.        Robert Eden - N5GWY
  2658.  
  2659. RME8650@TAMSIGMA.BITNET  <<< first choice
  2660. RME8650@TAMVENUS.BITNET  <<< second choice
  2661.  
  2662. reden@sys1.uucp          <<< after Dec. 15th.
  2663. rgd059@mipl3.jpl.nasa.gov<<< if all else fails.
  2664. 16-Nov-87 14:33:47-EST,2169;000000000000
  2665. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Nov 87 14:33-EST
  2666. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA28995@EDDIE.MIT.EDU>; Mon, 16 Nov 87 11:30:06 EST
  2667. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA28979@EDDIE.MIT.EDU>; Mon, 16 Nov 87 11:29:49 EST
  2668. Received: from ROOK.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 178180; Mon 16-Nov-87 11:04:19 EST
  2669. Date: Mon, 16 Nov 87 11:03 EST
  2670. From: Henry Minsky <hqm@VALLECITO.SCRC.Symbolics.COM>
  2671. Subject: Repeater advice anyone?
  2672. To: David_G._Michelson%UBC.MAILNET@um.cc.umich.edu, packet-radio@EDDIE.MIT.EDU
  2673. In-Reply-To: <8711110030.AA22371@june.cs.washington.edu>
  2674. Message-Id: <871116110347.5.HQM@ROOK.SCRC.Symbolics.COM>
  2675.  
  2676.     Date: Tue, 10 Nov 87 11:32:08 PST
  2677.     From: David_G._Michelson%UBC.MAILNET@um.cc.umich.edu
  2678.     To: packet-radio@EDDIE.MIT.EDU
  2679.     Subject: Repeater advice anyone?
  2680.  
  2681.     Re: 440 MHz Repeater for Packet Radio
  2682.  
  2683.     One of the most interesting things about packet radio (in my opinion)
  2684.     is the different ways one can approach the problem of repeating.
  2685.  
  2686.     The simplex digipeater is the simplest but, as subscribers to this
  2687.     mailing list are aware, it has severe disadvantages due to contention
  2688.     between the orginal packet, all its copies, and the many acknowledge-
  2689.     ments that fly back and forth up and down the link.
  2690.  
  2691.     NET/ROM is a significant improvement to the simple digipeater concept
  2692.     which, as I understand, uses standard TNC-2 hardware but enhanced
  2693.     firmware.
  2694.  
  2695.     Cross-band and cross-channel packet radio repeaters offer significant
  2696.     advantages because they eliminate the possibility of collision between
  2697.     originator-repeater traffic and repeater-addressee traffic.
  2698.  
  2699.     And then there are the many people who use conventional duplex repeaters
  2700.     for packet traffic (i.e., no regeneration).
  2701.  
  2702.     Are these the issues you were concerned with or are you after the
  2703.     technical details of a specific implementation?
  2704.  
  2705. I have been hearing a lot about "regeneration" in a digital full duplex
  2706. repeater. What is that and how does it work? 
  2707.  
  2708.  
  2709. 16-Nov-87 17:26:52-EST,2191;000000000000
  2710. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Nov 87 17:26-EST
  2711. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02758@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:38:31 EST
  2712. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02752@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:38:15 EST
  2713. Received: by june.cs.washington.edu (5.52.1/6.10)
  2714.     id AA26954; Mon, 16 Nov 87 11:39:40 PST
  2715. Return-Path: <bellcore!faline!karn@eddie.mit.edu>
  2716. Message-Id: <8711161939.AA26954@june.cs.washington.edu>
  2717. Date: 16 Nov 87 04:33:01 GMT
  2718. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  2719. To: PACKET-RADIO@EDDIE.MIT.EDU
  2720. Subject: Re: Packet freqs
  2721. Summary: weak-signal people have 500 khz
  2722. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP>
  2723.  
  2724. > Where did those recommendations come from??
  2725.  
  2726. The ARRL Digital Committee, of which I am a member.
  2727.  
  2728. > Has anyone floated them past the 220 weak-signal types??
  2729.  
  2730. The weak-signal types on 220 have 500 Khz of spectrum reserved to them,
  2731. 220.0 - 220.5. Given the very low levels of weak signal activity on that
  2732. band, I should think this would be more than plenty. Note that unlike
  2733. 2 meters, modes other than CW are allowed in this segment. Wideband
  2734. packet could in theory operate here.
  2735.  
  2736. The segment just above 220.5 that was recommended for wideband packet
  2737. is already listed as "experimental and control links". The major problem
  2738. in getting approval for these frequencies in most areas seems to be
  2739. that the local coordination committees seldom have complete records for
  2740. repeater control links, which by their nature are not widely advertised.
  2741.  
  2742. Which gives me an idea: many repeaters have separate, dedicated control
  2743. links mainly to satisfy FCC requirements. They can and do have secondary
  2744. command decoders on their regular inputs, and most routine commanding is
  2745. done this way. The backup control requirement for the voice repeater
  2746. could instead be provided as a secondary function of a co-located packet
  2747. switch. In exchange for providing secure and more sophisticated control
  2748. functions, the packet guys could get an existing antenna and frequency
  2749. assignment at a good site, and everybody wins.
  2750.  
  2751. Phil
  2752.  
  2753.  
  2754. 16-Nov-87 18:52:24-EST,1819;000000000000
  2755. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Nov 87 18:52-EST
  2756. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02740@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:37:44 EST
  2757. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02729@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:37:20 EST
  2758. Received: by june.cs.washington.edu (5.52.1/6.10)
  2759.     id AA26900; Mon, 16 Nov 87 11:38:41 PST
  2760. Return-Path: <uunet!nuchat!splut!jay@eddie.mit.edu>
  2761. Message-Id: <8711161938.AA26900@june.cs.washington.edu>
  2762. Date: 15 Nov 87 14:20:20 GMT
  2763. From: uunet!nuchat!splut!jay@EDDIE.MIT.edu (Jay Maynard)
  2764. To: PACKET-RADIO@EDDIE.MIT.EDU
  2765. Subject: Re: Packet freqs
  2766. Summary: Uh, Phil...
  2767. References: <698@uop.UUCP> <1532@faline.bellcore.com>
  2768.  
  2769. In article <1532@faline.bellcore.com>, karn@faline.bellcore.com (Phil R. Karn) writes:
  2770. > The band plan recommendation is to put conventional (i.e., AFSK/FM) packet
  2771. > on the frequencies 221.01, .03, ... with 20 khz spacing.  High speed
  2772. > (100 Khz) channels are 220.55, .65, .75, .85 and .95.
  2773.  
  2774. Where did those recommendations come from??
  2775. Has anyone floated them past the 220 weak-signal types??
  2776.  
  2777. > These recommendations are only that; you must still clear them with your
  2778. > local frequency coordination committee. And, of course, all this assumes
  2779. > we keep that portion of the band.
  2780.  
  2781. A hope we all share...
  2782. Beware, though: some coordination committees only espouse jurisdiction in
  2783. the repeater bands, and have little-to-no contact with the folks who this
  2784. would really affect.
  2785.  
  2786. -- 
  2787. Jay Maynard, K5ZC (@WB5BBW)...>splut!< | uucp: uunet!nuchat!splut!jay
  2788. Never ascribe to malice that which can | or:  academ!uhnix1!--^
  2789. adequately be explained by stupidity.  | GEnie: JAYMAYNARD  CI$: 71036,1603
  2790. The opinions herein are shared by none of my cats, much less anyone else.
  2791.  
  2792.  
  2793. 16-Nov-87 18:52:41-EST,2191;000000000000
  2794. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 16 Nov 87 18:52-EST
  2795. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02758@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:38:31 EST
  2796. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02752@EDDIE.MIT.EDU>; Mon, 16 Nov 87 14:38:15 EST
  2797. Received: by june.cs.washington.edu (5.52.1/6.10)
  2798.     id AA26954; Mon, 16 Nov 87 11:39:40 PST
  2799. Return-Path: <bellcore!faline!karn@eddie.mit.edu>
  2800. Message-Id: <8711161939.AA26954@june.cs.washington.edu>
  2801. Date: 16 Nov 87 04:33:01 GMT
  2802. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  2803. To: PACKET-RADIO@EDDIE.MIT.EDU
  2804. Subject: Re: Packet freqs
  2805. Summary: weak-signal people have 500 khz
  2806. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP>
  2807.  
  2808. > Where did those recommendations come from??
  2809.  
  2810. The ARRL Digital Committee, of which I am a member.
  2811.  
  2812. > Has anyone floated them past the 220 weak-signal types??
  2813.  
  2814. The weak-signal types on 220 have 500 Khz of spectrum reserved to them,
  2815. 220.0 - 220.5. Given the very low levels of weak signal activity on that
  2816. band, I should think this would be more than plenty. Note that unlike
  2817. 2 meters, modes other than CW are allowed in this segment. Wideband
  2818. packet could in theory operate here.
  2819.  
  2820. The segment just above 220.5 that was recommended for wideband packet
  2821. is already listed as "experimental and control links". The major problem
  2822. in getting approval for these frequencies in most areas seems to be
  2823. that the local coordination committees seldom have complete records for
  2824. repeater control links, which by their nature are not widely advertised.
  2825.  
  2826. Which gives me an idea: many repeaters have separate, dedicated control
  2827. links mainly to satisfy FCC requirements. They can and do have secondary
  2828. command decoders on their regular inputs, and most routine commanding is
  2829. done this way. The backup control requirement for the voice repeater
  2830. could instead be provided as a secondary function of a co-located packet
  2831. switch. In exchange for providing secure and more sophisticated control
  2832. functions, the packet guys could get an existing antenna and frequency
  2833. assignment at a good site, and everybody wins.
  2834.  
  2835. Phil
  2836.  
  2837.  
  2838. 17-Nov-87 19:47:31-EST,2526;000000000000
  2839. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Nov 87 19:47-EST
  2840. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00627@EDDIE.MIT.EDU>; Tue, 17 Nov 87 17:50:40 EST
  2841. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00584@EDDIE.MIT.EDU>; Tue, 17 Nov 87 17:47:38 EST
  2842. Received: by cod.nosc.mil (5.58/1.27)
  2843.     id AA02165; Tue, 17 Nov 87 12:25:59 PST
  2844. Date: Tue, 17 Nov 87 12:25:59 PST
  2845. From: coleman@cod.nosc.mil (Jeffrey L. Coleman)
  2846. Message-Id: <8711172025.AA02165@cod.nosc.mil>
  2847. To: packet-radio@eddie.mit.edu
  2848. Subject: DIGICOM>64
  2849.  
  2850.  
  2851. I obtained DIGICOM>64 from an American ham who distributes it for $1.00
  2852. if you send him a disk and stamped mailer.  Sorry, I don't have his
  2853. address with me but I got it from QST, October 1987.  He includes
  2854. 2 schematics for modems and hints on selecting and building one of them.
  2855.  
  2856. The software seems to be very well written and documentation is included
  2857. on the disk.  I built the modem using the XR2206 and XR2211 for about
  2858. $20 in parts.  The chip set cost $7.50, the rest was mostly the box,
  2859. board, connectors, trimpots, etc.
  2860.  
  2861. I have 2 questions about the system, one trivial and one critical:
  2862.  
  2863. Trivial:  Why is it necessary to set HBAUD to 1156 instead of 1200?
  2864.     Are European Commodores different than U.S. Commodores?  The
  2865.     explanation given in the documentation that this corrects the
  2866.     clock for the American 60Hz vs. the European 50Hz doesn't make
  2867.     sense to me.
  2868.     
  2869. Critical:  Why can't I connect to anything?  I have never operated
  2870.     packet before so maybe there is something simple I'm overlooking.
  2871.     I can copy packets off the air (and have a pretty good idea what
  2872.     most of the codes and symbols mean) but when I command "c wa6mu"
  2873.     my computer always gives up after 6 retries.  I can hear my
  2874.     packets being transmitted by listening to another radio so I
  2875.     know the connection to the transmitter is good but I never
  2876.     copy any response from the addressee station.
  2877.  
  2878.     I used a frequency counter to adjust my output frequencies to
  2879.     1200 and 2200 Hz.  I have tried various settings on the output
  2880.     level to prevent overmodulation but it seems to make no difference.
  2881.     I have tried to connect to several digipeaters and BBS's including
  2882.     some that I saw others using.
  2883.  
  2884. Any ideas or suggestions?  I'm running out of things to try.
  2885.  
  2886. Thanks,
  2887. Jeff Coleman, KI6NL
  2888. coleman@cod.nosc.mil
  2889.  
  2890. Disclaimer:  The above views are those of a normally sane, rational person
  2891. who has been staring at a homebrew project too long.
  2892.  
  2893. -------
  2894.  
  2895. 17-Nov-87 22:46:36-EST,2801;000000000000
  2896. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 17 Nov 87 22:46-EST
  2897. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01716@EDDIE.MIT.EDU>; Tue, 17 Nov 87 18:52:10 EST
  2898. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01704@EDDIE.MIT.EDU>; Tue, 17 Nov 87 18:51:59 EST
  2899. Received: from ROOK.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 178890; Tue 17-Nov-87 18:52:41 EST
  2900. Date: Tue, 17 Nov 87 18:52 EST
  2901. From: Henry Minsky <hqm@VALLECITO.SCRC.Symbolics.COM>
  2902. Subject: DIGICOM>64
  2903. To: coleman@cod.nosc.mil, packet-radio@eddie.mit.edu
  2904. In-Reply-To: <8711172025.AA02165@cod.nosc.mil>
  2905. Message-Id: <871117185228.7.HQM@ROOK.SCRC.Symbolics.COM>
  2906.  
  2907.     From: coleman@cod.nosc.mil (Jeffrey L. Coleman)
  2908.     Message-Id: <8711172025.AA02165@cod.nosc.mil>
  2909.     To: packet-radio@eddie.mit.edu
  2910.     Subject: DIGICOM>64
  2911.     ... 
  2912.     ... 
  2913.     I have 2 questions about the system, one trivial and one critical:
  2914.  
  2915.     Trivial:  Why is it necessary to set HBAUD to 1156 instead of 1200?
  2916.         Are European Commodores different than U.S. Commodores?  The
  2917.         explanation given in the documentation that this corrects the
  2918.         clock for the American 60Hz vs. the European 50Hz doesn't make
  2919.         sense to me.
  2920.     
  2921.     Critical:  Why can't I connect to anything?  I have never operated
  2922.         packet before so maybe there is something simple I'm overlooking.
  2923.         I can copy packets off the air (and have a pretty good idea what
  2924.         most of the codes and symbols mean) but when I command "c wa6mu"
  2925.         my computer always gives up after 6 retries.  I can hear my
  2926.         packets being transmitted by listening to another radio so I
  2927.         know the connection to the transmitter is good but I never
  2928.         copy any response from the addressee station.
  2929.  
  2930.         I used a frequency counter to adjust my output frequencies to
  2931.         1200 and 2200 Hz.  I have tried various settings on the output
  2932.         level to prevent overmodulation but it seems to make no difference.
  2933.         I have tried to connect to several digipeaters and BBS's including
  2934.         some that I saw others using.
  2935.  
  2936.     Any ideas or suggestions?  I'm running out of things to try.
  2937.  
  2938. I suggest that you try setting any parameters which control the
  2939. "TXDELAY" and/or "TXTAIL" (or the equivalent in your system).
  2940.  
  2941.  These are parameters which control how long a delay the computer adds
  2942. after it keys the transmitter, but before sending the packet data, and
  2943. likewise, how long it holds the transmitter keyed after the last packet
  2944. bits have been sent. 
  2945.  
  2946. I was unable to sucessfully transmit packets using my Yaesu handheld,
  2947. until I set something like a 50 millisecond txdelay, and about 20
  2948. millisecond tail.
  2949.  
  2950. Some of these transcievers can take even longer to key up, I've heard.
  2951.  
  2952.  
  2953. 18-Nov-87 16:35:05-EST,1616;000000000000
  2954. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Nov 87 16:35-EST
  2955. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18332@EDDIE.MIT.EDU>; Wed, 18 Nov 87 12:26:14 EST
  2956. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18173@EDDIE.MIT.EDU>; Wed, 18 Nov 87 12:18:05 EST
  2957. Received: by cod.nosc.mil (5.58/1.27)
  2958.     id AA25856; Wed, 18 Nov 87 08:50:33 PST
  2959. Date: Wed, 18 Nov 87 08:50:33 PST
  2960. From: coleman@cod.nosc.mil (Jeffrey L. Coleman)
  2961. Message-Id: <8711181650.AA25856@cod.nosc.mil>
  2962. To: packet-radio@eddie.mit.edu
  2963. Subject: DIGICOM>64 (continued)
  2964.  
  2965.  
  2966. I made an error in yesterday's posting.  The article on DIGICOM64 was in
  2967. November issue of QST (not October), on page 59.  To quote the article,
  2968. "The software, documentation and modem schematic may be obtained by sending
  2969. a blank disk, a self-addressed disk mailer with enough postage for at least
  2970. 3 ounces and $1 for the cost of the printed documentation to Barry Kutner,
  2971. W2UP, 286 Leedom Way, Newtown, PA 18940."
  2972.  
  2973. Now the good news:  SUCCESS!
  2974. Last night I finally found a station which I could connect to.  Then I also
  2975. connected to myself using him as a digipeater.  The number of retries
  2976. seemed high and I lost the connection a couple of times when sending long 
  2977. packets so I'll still be playing with the system trying to improve it (re-tune
  2978. the transmitter, shorten the cables) but now it has gotten more interesting.
  2979.  
  2980. If others are interested, I'll report later on my impressions of it and
  2981. problems I've had.
  2982.  
  2983. 73,
  2984. Jeff Coleman, KI6NL
  2985. coleman@cod.nosc.mil
  2986.  
  2987. Disclaimer:  I hereby disclaim.
  2988. ------
  2989. -------
  2990.  
  2991. 18-Nov-87 19:15:46-EST,3581;000000000000
  2992. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Nov 87 19:15-EST
  2993. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25585@EDDIE.MIT.EDU>; Wed, 18 Nov 87 16:54:35 EST
  2994. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25567@EDDIE.MIT.EDU>; Wed, 18 Nov 87 16:54:15 EST
  2995. Message-Id: <8711182154.AA25567@EDDIE.MIT.EDU>
  2996. Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 18 Nov 87 16:53:30 EST
  2997. Received: from TRIUMFCL.BITNET (ROSK) by MITVMA.MIT.EDU (Mailer X1.25) with
  2998.  BSMTP id 8079; Wed, 18 Nov 87 16:19:33 EST
  2999. Date:     Wed, 18 Nov 87 13:12 PST
  3000. From: <ROSK%TRIUMFCL.BITNET@MITVMA.MIT.EDU>
  3001. Subject:  Re: DIGICOM>64 Problems.
  3002. To: PACKET-RADIO@EDDIE.MIT.EDU
  3003. X-Original-To:  pack, ROSK
  3004.  
  3005. In answer to a couple of questions from Jeffrey L. Coleman
  3006. <coleman@cod.nosc.mil> about the DIGICOM>64 software:
  3007.  
  3008. >       Why is it necessary to set HBAUD to 1156 instead of 1200?
  3009. >    Are European Commodores different than U.S. Commodores?  The
  3010. >    explanation given in the documentation that this corrects the
  3011. >    clock for the American 60Hz vs. the European 50Hz doesn't make
  3012. >    sense to me.
  3013.  
  3014. The baud rate timing is derived from the CPU clock via one of the
  3015. programmable counters. The problem is that the European CPU clock is
  3016. at a slightly different frequency than the USA clock. This is because
  3017. the Video output is also derived from the CPU clock. The European
  3018. version produces a PAL picture (625 line - 50 frame/sec) and the USA
  3019. version an NTSC picture (525 line - 60 frame/sec.) The timings for the
  3020. two standards are quite different, but most of the difference is taken
  3021. care of by using a different version of the VIC chip. (Thats what generates
  3022. the video.) BUT, it cant quite do it all - the primary crystal frequency
  3023. has to be slightly different ~17MHz for PAL, ~14MHz for NTSC. After some
  3024. dividing in the (different) VICs, this results in CPU clock rates of
  3025. 0.98 MHz for PAL and 1.02MHz for NTSC. So the NTSC CPU clock runs a bit
  3026. faster, and to get 1200 baud, you have to tell the program to run 1156bd
  3027. instead. The program could be "fixed" by adding a USA/EU switch, but I
  3028. for one can put up with this quirk.
  3029.  
  3030. >    Why can't I connect to anything?  I have never operated
  3031. >    packet before so maybe there is something simple I'm overlooking.
  3032. >    I can copy packets off the air (and have a pretty good idea what
  3033. >    most of the codes and symbols mean) but when I command "c wa6mu"
  3034. >    my computer always gives up after 6 retries.  I can hear my
  3035. >    packets being transmitted by listening to another radio so I
  3036. >    know the connection to the transmitter is good but I never
  3037. >    copy any response from the addressee station.
  3038.  
  3039. Get another packet station to MONITOR your packets. Talk to them on
  3040. the phone, or 2m, have them tell you what they see. Try setting TXDELAY
  3041. larger - try 20 for starters. This gives the TX longer to "get on the air"
  3042. before the real data is transmitted. This was my problem when getting
  3043. started.
  3044. You can test your software and modem without the radio - connect the
  3045. modem output to the modem input. Set the following:
  3046. MYCALL KI6NL  < thats your call sign.
  3047. CONOK ON      < that allows someone to connect to you
  3048. FULL ON       < that allows full duplex operation
  3049. Now try   CONNECT KI6NL
  3050. You should connect to yourself! Note - it doesn't always work perfectly.
  3051. The C64 is working hard to generate output and copy the input at the same
  3052. time, all on timer interrupts, when running Full Duplex. You may not get
  3053. perfect packet transmission every time.
  3054.  
  3055. 73 VE7AII.
  3056.  
  3057. 18-Nov-87 19:40:37-EST,4837;000000000000
  3058. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 18 Nov 87 19:40-EST
  3059. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22527@EDDIE.MIT.EDU>; Wed, 18 Nov 87 15:03:36 EST
  3060. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA22499@EDDIE.MIT.EDU>; Wed, 18 Nov 87 15:02:56 EST
  3061. Received: by june.cs.washington.edu (5.52.1/6.10)
  3062.     id AA09409; Wed, 18 Nov 87 12:04:07 PST
  3063. From: ihnp4!homxb!mtuxo!mtune!petsd!pedsgo!pedsga!tsdiag!tom@eddie.mit.edu
  3064. Return-Path: <ihnp4!homxb!mtuxo!mtune!petsd!pedsgo!pedsga!tsdiag!tom@eddie.mit.edu>
  3065. Message-Id: <8711182004.AA09409@june.cs.washington.edu>
  3066. Date: 13 Nov 87 15:40:35 GMT
  3067. To: PACKET-RADIO@EDDIE.MIT.EDU
  3068. Subject: Re: Level 3 protocols - some info?
  3069. Keywords: TCPIP,COSI,NETROM
  3070. References: <242@ka2qhd.UUCP>
  3071.  
  3072. Bob, You are right it's time these questions were asked by someone who
  3073. has no stake in the protocol wars!!!
  3074.  
  3075. Your questions in order...
  3076.  
  3077. 1) Is TCP/IP best?
  3078.     There are people who do believe that this is the only networking
  3079.     protocol that can solve everyone's needs.  It does have advantages
  3080.     some environments, I personally do not agree.  The basic disadvantage
  3081.     is that it is an all or nothing and you must have the whole protocol
  3082.     running in your computer to access the network.
  3083.  
  3084. 2) COSI Switch - What is it?
  3085.     I am the programmer writing the switch,  it is based on CCITT X.25,
  3086.     (aka ISO 8208) which is the International standard used to connect
  3087.     data networks throughout the world. [note that tcp/ip is also used
  3088.     globally, but isn't accepted by all PTT's, in fact many tcp/ip
  3089.     connections are running on top of X.25]
  3090.  
  3091.     Why X.25?  I believe that to run a network on packet radio it is very
  3092.     important to provide error recovery at all levels. [for ip it's end to
  3093.     end, very much like good 'ole digipeating is now] Which means that if
  3094.     any data gets lost you get notified and can re-send the information.
  3095.  
  3096.     An X.25 network can not be an ad hoc network, it must be expanded in
  3097.     a coordinated fashion. [remember kaos on 145.01?]
  3098.  
  3099.     Politics, many PTT's won't accept a new protocol, the COSI suite is
  3100.     going to be following the same standards that they are seeing in the
  3101.     commerical world, how can they say no!
  3102.  
  3103.     The ISO protocols are the next generation of networking which the
  3104.     commerical world is going to.  TCP/IP was developed on the ARPAnet
  3105.     [a US DoD funded project] and while many companies use this protocol
  3106.     many of the "small" companies are working towards these protocols.
  3107.     [companies such as IBM, DEC, Xerox to name the "small ones"]
  3108.  
  3109.     COSI Switch will provide a Level 2 User interface so users don't have
  3110.     to run on a PC/Clone, they just need a terminal!  This is not the best
  3111.     way to use the network, but it is provided to allow *any* user to take
  3112.     advantage of the network, without having to buy a new computer!
  3113.  
  3114.     Disadvantages - it's coming out in Jan '88 and inspite of my extensive
  3115.     testing I know it will contain a bug of two.  Remember I started the
  3116.     project in June '87.
  3117.  
  3118. 3) NET/ROM
  3119.     NET/ROM is a $65 rom with a non-standard datagrame [TCP/IP-ish]
  3120.     protocol.  I don't know much about it execpt user comments about
  3121.     problems or other things they don't like. [no verified information]
  3122.  
  3123.  
  3124. 4) Other Protocols - There isn't much else around in the way of commonly
  3125.     accepted netwotking protocols.
  3126.  
  3127. 5) IBM/Clones
  3128.     Yes many of us have clones and use them for development, the TCP/IP
  3129.     runs there (from KA9Q), as well as a few other machines, I hear that
  3130.     new evironments are being worked on.
  3131.     The COSI suite will be ported to many machines also, the switch will
  3132.     be running on a TNC 2/Clone first and then the DR-200 and PS-186 as well
  3133.     as the PC.  We will also have a Level 3 User PAD (aka TNC code) for
  3134.     various TNC's (I'll do it for the TNC 1 if there is a C compiler for it)
  3135.     Give me a 68000 machine for 2-3 Weekends and it'll be up there too!
  3136.     Any other machines, if there is a C compiler it should be easy.
  3137.  
  3138. 6) What does a User need?
  3139.     For TCP/IP you should have one of the machines that the KA9Q code has
  3140.     been ported to.
  3141.  
  3142.     For COSI you need WHAT YOU ARE USING RIGHT NOW! (a terminal)
  3143.     In the long run it would be good for the TNC to run level 3 (it's
  3144.     called a PAD) or to have it in the host[user] computer.
  3145.  
  3146. I have tried to be as fair as possible and have presented the information as
  3147. I know it. [Phil - I hope I was FAIR-ly accurate on your stuff]
  3148.  
  3149. Bob, please question anything you want, this topic needs clearing up to OUR
  3150. [packet radio's] users in the worst way!!
  3151.  
  3152. 73
  3153. tom
  3154. -- 
  3155. Thomas A. Moulton, W2VY          Life is too short to be mad about things.
  3156. Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
  3157. Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
  3158. Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy
  3159.  
  3160.  
  3161. 19-Nov-87 15:45:55-EST,6188;000000000000
  3162. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Nov 87 15:45-EST
  3163. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21876@EDDIE.MIT.EDU>; Thu, 19 Nov 87 13:35:18 EST
  3164. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21514@EDDIE.MIT.EDU>; Thu, 19 Nov 87 13:24:58 EST
  3165. Received: by june.cs.washington.edu (5.52.1/6.11)
  3166.     id AA13072; Thu, 19 Nov 87 10:06:09 PST
  3167. Return-Path: <bellcore!faline!karn@EDDIE.MIT.EDU>
  3168. Message-Id: <8711191806.AA13072@june.cs.washington.edu>
  3169. Date: 18 Nov 87 21:34:52 GMT
  3170. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  3171. To: PACKET-RADIO@EDDIE.MIT.EDU
  3172. Subject: Re: Level 3 protocols - some info?
  3173. Summary: response to W2VY
  3174. Keywords: TCPIP,COSI,NETROM
  3175. References: <242@ka2qhd.UUCP> <129@tsdiag.UUCP>
  3176.  
  3177. > 1) Is TCP/IP best?
  3178. >       There are people who do believe that this is the only networking
  3179. >       protocol that can solve everyone's needs.  It does have advantages
  3180. >       some environments, I personally do not agree.  The basic disadvantage
  3181. >       is that it is an all or nothing and you must have the whole protocol
  3182. >       running in your computer to access the network.
  3183.  
  3184. TCP/IP can't solve everyone's needs, but of all things existing (or
  3185. promised) it comes closest. TCP and IP are just two members (albeit the
  3186. most important ones) of large and highly modular family of protocols
  3187. more properly called the ARPA Internet Protocol Suite. Some (e.g., TCP
  3188. and IP) are more important than others. The only "essential" protocol is
  3189. IP. Because everyone on the Internet has to implement it, it was kept as
  3190. simple as possible. Many of the applications are optional. The ARPA suite
  3191. is by no means "all or nothing".
  3192.  
  3193. >       ... [note that tcp/ip is also used
  3194. >       globally, but isn't accepted by all PTT's, in fact many tcp/ip
  3195. >       connections are running on top of X.25]
  3196. >[...]
  3197. >       Politics, many PTT's won't accept a new protocol, the COSI suite is
  3198. >       going to be following the same standards that they are seeing in the
  3199. >       commerical world, how can they say no!
  3200. > 
  3201.  
  3202. This reflects a fundamental misunderstanding (or misrepresentation) of
  3203. the role of TCP/IP in computer networking. TCP and IP are transport
  3204. (layer 4) and internetwork (layer 3B) protocols. They run ON TOP of
  3205. existing subnetworks, including, as Tom points out, X.25 networks.  As
  3206. such, TCP/IP packets are carried AS USER DATA by these subnetworks. The
  3207. decision to use TCP/IP is made by the subscribers to the PTT data
  3208. networks. Whether the PTTs "accept" TCP/IP is completely irrelevant.
  3209. They have no more say in the matter than they do over what language you and
  3210. your friends speak in your voice telephone calls.
  3211.  
  3212. >       Why X.25?  I believe that to run a network on packet radio it is very
  3213. >       important to provide error recovery at all levels. [for ip it's end to
  3214. >       end, very much like good 'ole digipeating is now] Which means that if
  3215. >       any data gets lost you get notified and can re-send the information.
  3216.  
  3217. It is almost universally believed within the computer networking
  3218. industry that full end-to-end error control is both necessary AND
  3219. sufficient for reliable transfer of data between computers. TCP is one
  3220. way of doing this. Once you have such a mechanism in place, the question
  3221. of whether additional error recovery mechanisms are also needed at the
  3222. lower levels becomes a question of performance, not reliability. More
  3223. often than not, such mechanisms merely result in needless complexity and
  3224. overhead, as they can never eliminate the need for the end-to-end
  3225. mechanism.
  3226.  
  3227. Amateur packet radio as it now stands is one of the few areas where
  3228. these low-level mechanisms may help. Nevertheless, it would be far
  3229. better to prevent collisions in the first place through the the use of
  3230. full duplex and controlled frequency reuse within the backbone network.
  3231. Once this is done, low level mechanisms again become superfluous.
  3232.  
  3233. Nevertheless, to quiet the critics who imply that TCP/IP somehow
  3234. *precludes* lower level recovery mechanisms, I have added full-blown
  3235. AX.25 Level 2 to the KA9Q Internet Package.  IP datagrams may now be
  3236. optionally acknowledged on a hop-by-hop basis.  However, this technique
  3237. suffers from exactly the same collision-aggravation problem I described
  3238. in my recent note "The Trouble with NET/ROM". I therefore strongly
  3239. recommend that you use this technique only as a last resort, after you
  3240. have exhausted all other techniques to improve the raw packet loss rate.
  3241.  
  3242. >       COSI Switch will provide a Level 2 User interface so users don't have
  3243. >       to run on a PC/Clone, they just need a terminal!  This is not the best
  3244. >       way to use the network, but it is provided to allow *any* user to take
  3245. >       advantage of the network, without having to buy a new computer!
  3246. > [...]
  3247. >       For COSI you need WHAT YOU ARE USING RIGHT NOW! (a terminal)
  3248. >       In the long run it would be good for the TNC to run level 3 (it's
  3249. >       called a PAD) or to have it in the host[user] computer.
  3250.  
  3251. This is also misleading. The reason the KA9Q Internet Protocol Package
  3252. requires a computer to run on is that many of its high-level services
  3253. are only meaningful on computers with file systems. How do you provide
  3254. services like "file transfer" or "mail transfer" when all you have is a
  3255. dumb terminal?  Yes, a stripped-down version of TCP/IP and Telnet
  3256. *could* be put on a TNC-2 for use with a dumb terminal.  This would gain
  3257. the ability to "internetwork" between an amateur packet radio channel
  3258. and computers on Ethernets, X.25 nets, etc, also running TCP/IP, and
  3259. this may make such a project worthwhile. However, you would gain no
  3260. additional FUNCTIONALITY over what you can already do with a dumb
  3261. terminal and "vanilla" AX.25. All you get is "remote terminal access",
  3262. not true computer networking.
  3263.  
  3264. Comparing the ARPA Suite and X.25 is comparing apples and oranges. Or,
  3265. to use Michael Padlipsky's favorite analogy, it's like comparing a
  3266. complete, working automobile with a bare chassis and tires. Arguing that
  3267. X.25 is somehow "better" than the ARPA suite because you don't need a
  3268. real computer to run it is like arguing that a bare chassis is better
  3269. than a complete car because you can save money on body paint.
  3270.  
  3271. Phil
  3272.  
  3273.  
  3274. 19-Nov-87 16:01:31-EST,11202;000000000000
  3275. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Nov 87 16:01-EST
  3276. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21950@EDDIE.MIT.EDU>; Thu, 19 Nov 87 13:38:16 EST
  3277. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA21545@EDDIE.MIT.EDU>; Thu, 19 Nov 87 13:26:07 EST
  3278. Received: by june.cs.washington.edu (5.52.1/6.11)
  3279.     id AA13166; Thu, 19 Nov 87 10:09:55 PST
  3280. From: ucbvax!jade!aurora!labrea!umunhum!paulf@EDDIE.MIT.edu
  3281. Return-Path: <ucbvax!jade!aurora!labrea!umunhum!paulf@EDDIE.MIT.EDU>
  3282. Message-Id: <8711191809.AA13166@june.cs.washington.edu>
  3283. Date: 19 Nov 87 01:45:34 GMT
  3284. To: PACKET-RADIO@EDDIE.MIT.EDU
  3285. Subject: Re: Level 3 protocols - some info?
  3286. Keywords: TCPIP,COSI,NETROM
  3287. References: <242@ka2qhd.UUCP> <129@tsdiag.UUCP>
  3288. Reply-To: paulf@umunhum.stanford.edu (Paul Flaherty)
  3289.  
  3290. In article <129@tsdiag.UUCP> tom@tsdiag.UUCP (Tom Moulton) writes:
  3291. >Bob, You are right it's time these questions were asked by someone who
  3292. >has no stake in the protocol wars!!!
  3293.  
  3294. Perhaps it would be better if they were ANSWERED by someone who has no
  3295. stake in the protocol wars.  Personally, I havn't written any code for
  3296. either system, although I have used both sets of protocols at various times.
  3297.  
  3298. >1) Is TCP/IP best?
  3299. >       There are people who do believe that this is the only networking
  3300. >       protocol that can solve everyone's needs.  It does have advantages
  3301. >       some environments, I personally do not agree.  The basic disadvantage
  3302. >       is that it is an all or nothing and you must have the whole protocol
  3303. >       running in your computer to access the network.
  3304.  
  3305.     People generally don't care who propagates a standard nearly as 
  3306. much as the care whether or not it solves a problem.  This is why de facto
  3307. standards get started; and, in a sense, the DDN protocols have become
  3308. the de facto international protocol.
  3309.  
  3310.     I disagree with your contention that the DDN protocols are all or 
  3311. nothing.  In fact, the only required protocol is IP; the user then implents 
  3312. only those layers which are useful to the solution of the problem.  Take,
  3313. for example, the gateway box that I'm using as a terminal server (at this
  3314. very moment); it only implements IP, UDP, and BOOTP (tcp and telnet are
  3315. added features that aren't really necessary).  I'd much rather implement
  3316. a switch based on IP and UDP (relatively simple protocols) than x.75 and
  3317. tp4 (much more complex protocols).
  3318.  
  3319.     Also, look at the Imagen TCP implementation of tcp/ip, which is
  3320. ROMable.  If we want people to use tnc's, all we need to do is 
  3321. implement a version of TELNET in ROM for the 6809, which is both doable
  3322. and desirable...
  3323.  
  3324. >2) COSI Switch - What is it?
  3325. >       I am the programmer writing the switch,  it is based on CCITT X.25,
  3326. >       (aka ISO 8208) which is the International standard used to connect
  3327. >       data networks throughout the world. [note that tcp/ip is also used
  3328. >       globally, but isn't accepted by all PTT's, in fact many tcp/ip
  3329. >       connections are running on top of X.25]
  3330.  
  3331.     Well, now we know your biases, anyway.
  3332.  
  3333.     You are confusing medium access protocols with internetworking and
  3334. transport protocols.  In the first place, in order to accomplish roughly
  3335. the same goals as TCP/IP, one need x.75 AND TP4, in addition to x.25.
  3336. Of course, one could just as easily implement TCP/IP on top of x.25, and
  3337. this has been done in practice.  Moreover, the number of TCP/IP installations
  3338. in Europe is growing exponentially, so if the PTTs want to make money, 
  3339. they'll allow it.  Finally, it's worth noting that IP gives one a much 
  3340. higher degree of internetworking flexibility than x.75, which is designed
  3341. for x.25; IP runs just as easily with Ethernet, x.25, AppleTalk, or any of
  3342. a myriad of data link protocols.  Try doing THAT with x.75.
  3343.  
  3344. >       Why X.25?  I believe that to run a network on packet radio it is very
  3345. >       important to provide error recovery at all levels. [for ip it's end to
  3346. >       end, very much like good 'ole digipeating is now] Which means that if
  3347. >       any data gets lost you get notified and can re-send the information.
  3348.  
  3349.     Your beliefs do not corroborate with the results of research done
  3350. in this area.  In particular, Karn's excellent paper on X.25 in the 
  3351. multiaccess environment shows a number of pitfalls.  In particular, the 
  3352. NAK packets alone can send the network into the thrashing region.  Boesch's
  3353. thesis work here at Stanford indicates that the only real way to do multihop
  3354. packet radio is to violate the OSI model, and establish communications
  3355. between nonadjacent layers.  Needless to say, IP does this much more 
  3356. gracefully than x.75.
  3357.  
  3358.     The real problem here is that, in a lossy multihop subnet, multi
  3359. layer protocols don't perform terribly well; the solution is to implement
  3360. out - of - band acknowledgements, which IP is more than capable of handling.
  3361.  
  3362. >       An X.25 network can not be an ad hoc network, it must be expanded in
  3363. >       a coordinated fashion. [remember kaos on 145.01?]
  3364.  
  3365.     Big disadvantage.  As I stated in an earlier article, the amprnet
  3366. is closer in organization to DDN than any PTT.  And the DDN protocols were
  3367. meant to connect nets run by different administrations, which will definitely
  3368. be the case for amprnet (we don't want them funny folks from Back East telling
  3369. us how to run OUR network...).  And, as I stated before, do YOU want the job
  3370. of coordinating all of this?
  3371.  
  3372. >       Politics, many PTT's won't accept a new protocol, the COSI suite is
  3373. >       going to be following the same standards that they are seeing in the
  3374. >       commerical world, how can they say no!
  3375.  
  3376.     They can say no if nobody is using the product.  So far, the growth
  3377. rate of TCP/IP has outstripped TP4.  PTTs may be political, but they also 
  3378. like to make money (well, ok, MOST of them, anyway).  Also, TCP/IP is hardly
  3379. a new protocol; if anything, as a PTT, I'd rather have TCP/IP running, since
  3380. its failure modes are fairly well known and documented.
  3381.  
  3382. >
  3383. >       The ISO protocols are the next generation of networking which the
  3384. >       commerical world is going to.  TCP/IP was developed on the ARPAnet
  3385. >       [a US DoD funded project] and while many companies use this protocol
  3386. >       many of the "small" companies are working towards these protocols.
  3387. >       [companies such as IBM, DEC, Xerox to name the "small ones"]
  3388.  
  3389.     The "next generation" argument smacks of innuendo.  TCP is in fact 
  3390. a "next generation" protocol, having replace NTP; assuming that TP4 actually
  3391. improves on TCP (evidence which is lacking at this point), we could implement
  3392. changes in TCP to accomplish the same thing, and still use the existing IP 
  3393. layer and everything below it.
  3394.  
  3395.     TCP/IP was developed on the ARPA _InterNet_, which includes the
  3396. ARPANET as a member.  Not all research on the DDN protocols has been done
  3397. with DOD funding; in particular, NFS and BOOTP were developed at Stanford
  3398. to support our internal networking facilities.
  3399.  
  3400.     IBM, DEC and Xerox all support implementations of TCP/IP, as well
  3401. as their own internal protocols (SNA, DECNET, and XNS).  If anything, by
  3402. promulgating their own internal architectures, they have shown a lack of 
  3403. faith in the OSI committees to produce anything practical.
  3404.  
  3405. >
  3406. >       COSI Switch will provide a Level 2 User interface so users don't have
  3407. >       to run on a PC/Clone, they just need a terminal!  This is not the best
  3408. >       way to use the network, but it is provided to allow *any* user to take
  3409. >       advantage of the network, without having to buy a new computer!
  3410.  
  3411.     Again, this is not unique.  It is just as easy to write TNC code to
  3412. do a simple TELNET implementation.  Conversely, you get what you pay for.
  3413.  
  3414. >
  3415. >       Disadvantages - it's coming out in Jan '88 and inspite of my extensive
  3416. >       testing I know it will contain a bug of two.  Remember I started the
  3417. >       project in June '87.
  3418.  
  3419.     Of course, this is the disadvantage of all COSI software.  Not only
  3420. is it untried, and full of bugs, but we really don't know its failure
  3421. modes.  And, even assuming a marginal benefit from converting to the OSI
  3422. protocols (and that's really stretching things), lack of known failure modes
  3423. introduces unknown and unquantifiable risks into the network, which easily
  3424. outweighs any gain.
  3425.  
  3426. >3) NET/ROM
  3427. >       NET/ROM is a $65 rom with a non-standard datagrame [TCP/IP-ish]
  3428. >       protocol.  I don't know much about it execpt user comments about
  3429. >       problems or other things they don't like. [no verified information]
  3430.  
  3431.     Odd, I thought NET/ROM implemented virtual circuits.  Or at least it
  3432. did the last time I used it. (Or, should I say, almost did...)
  3433.  
  3434. >4) Other Protocols - There isn't much else around in the way of commonly
  3435. >       accepted netwotking protocols.
  3436.  
  3437.     Unless, of course, one counts TCP/IP, which is the de facto 
  3438. international standard.
  3439.  
  3440. >5) IBM/Clones
  3441. >       Yes many of us have clones and use them for development, the TCP/IP
  3442. >       runs there (from KA9Q), as well as a few other machines, I hear that
  3443. >       new evironments are being worked on.
  3444.  
  3445.     TCP/IP is available for almost all pc's and mainframes; besides
  3446. the KA9Q implementation, there are the MIT and SUMEX implementations for
  3447. the IBM PC domain.  There are several implementations for the Mac, including
  3448. the SUMEX code, which is available on a basis similar to PCIP (CMU also has
  3449. a MAC TCP/IP suite).  The KA9Q code has been ported, or is in the process
  3450. of being ported, to UNIX System V (Bdale Garbee et al), the Commmodore
  3451. Amiga, laptop clones, and many others.
  3452.  
  3453. >6) What does a User need?
  3454. >       For TCP/IP you should have one of the machines that the KA9Q code has
  3455. >       been ported to.
  3456.  
  3457.     Which covers most of the market, except for the games machines...
  3458.  
  3459. >       For COSI you need WHAT YOU ARE USING RIGHT NOW! (a terminal)
  3460. >       In the long run it would be good for the TNC to run level 3 (it's
  3461. >       called a PAD) or to have it in the host[user] computer.
  3462.  
  3463.     Like I said, this is not unique.  "Given a few weeks of free time",
  3464. I could have telnet up and running on a TNC.  Unfortunately, my free time
  3465. comes in minutes, not weeks...
  3466.  
  3467. >I have tried to be as fair as possible and have presented the information as
  3468. >I know it. [Phil - I hope I was FAIR-ly accurate on your stuff]
  3469.  
  3470.     Well, I don't think that you were unfair, but I think that it is clear
  3471. that you were inaccurate, but that's probably not your fault anyway.
  3472.  
  3473.     To reiterate my arguments from my last posting, the DDN protocols 
  3474. have several clear and evident advantages over the OSI suite.  Some of these
  3475. are related to the fact that TCP/IP has been around awhile (good routing,
  3476. lots of user layer protocols, and availability), but most are intrinsic
  3477. (strong internetworking, layering flexibility, subnetting and distributed
  3478. management, tremendous reliability and throughput).
  3479.  
  3480.     Given all of this, why make such a major effort to convert to
  3481. a protocol suite which offers no additional user funtionality?
  3482.  
  3483.     Still not convinced?  Well, just remember, when Phase IV flies,
  3484. the only cost free long distance network in the country will be running
  3485. TCP/IP...
  3486.  
  3487.  
  3488.  
  3489.  
  3490.  
  3491.  
  3492.  
  3493. -=Paul Flaherty, N9FZX           | "One Internet to rule them all,
  3494. Computer Systems Laboratory      |          One Internet to find them,
  3495. Stanford University              |  One Internet to bring them all
  3496. Domain: paulf@shasta.Stanford.EDU|          and in the ether bind them." -ToIH
  3497.  
  3498.  
  3499. 19-Nov-87 16:18:53-EST,1162;000000000000
  3500. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 19 Nov 87 16:18-EST
  3501. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA24560@EDDIE.MIT.EDU>; Thu, 19 Nov 87 15:05:46 EST
  3502. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA24547@EDDIE.MIT.EDU>; Thu, 19 Nov 87 15:05:25 EST
  3503. Received: from huey.udel.edu by Louie.UDEL.EDU id ab01625; 19 Nov 87 13:48 EST
  3504. Date:     Thu, 19 Nov 87 13:44:49 EST
  3505. From: Mills@UDEL.EDU
  3506. To: "Phil R. Karn" <bellcore!faline!karn@eddie.mit.edu>
  3507. Cc: PACKET-RADIO@eddie.mit.edu
  3508. Subject:  Re:  Repeater advice anyone?
  3509. Message-Id:  <8711191344.aa02654@Huey.UDEL.EDU>
  3510.  
  3511. Phil,
  3512.  
  3513. DARPA packet radios use a technique called pacing, in which the onward
  3514. transmission of a packet from the digipeater to the next hop is heard
  3515. by the original transmitter as the ACK for its transmission. Since the
  3516. digipeater will delay until the channel is quiet, this forms an automatic
  3517. sensing mechanism for hidden transmitters and without the channel overhead
  3518. of additional ACKs. The sender, of course, should delay once his relayed
  3519. transmission is heard to avoid collision on the next hop, just as you
  3520. describe.
  3521.  
  3522. Dave
  3523. 22-Nov-87 22:25:09-EST,2495;000000000000
  3524. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:25-EST
  3525. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18425@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:08:06 EST
  3526. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18419@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:07:46 EST
  3527. Received: by june.cs.washington.edu (5.52.1/6.11)
  3528.     id AA02759; Sun, 22 Nov 87 18:08:37 PST
  3529. Return-Path: <princeton!idacrd!mac@eddie.mit.edu>
  3530. Message-Id: <8711230208.AA02759@june.cs.washington.edu>
  3531. Date: 20 Nov 87 15:25:30 GMT
  3532. From: princeton!idacrd!mac@eddie.mit.edu (Bob McGwier)
  3533. To: PACKET-RADIO@EDDIE.MIT.EDU
  3534. Subject: protowars
  3535.  
  3536. I would like to provide a quote for the nets perusal.  I am quoting
  3537. AA4RE, Roy Engehausen's, column from PSR, "In the Mailbox".
  3538.  
  3539. Food for Thought - One Man's Opinion
  3540.  
  3541. Competition has been with packet radio a long time.  I think it all started
  3542. with the VADCG versus AX25 controversy.  We now have all sorts of things
  3543. bouncing around in the packet world. Zip code versus area code; NETROM versus
  3544. COSI versus TCP/IP versus TEXNET; W0RLI CBBS versus WA7MBL versus KA2BQE
  3545. mailboxes; etc. etc.
  3546.  
  3547. (Editorial comment: Roy either doesn't understand internetworking or is
  3548. writing for the "unwashed masses" as IP will run on top of ALL these
  3549. offerings with varying degrees of difficulty depending on whether the
  3550. internal structure is datagrammes or not)
  3551.  
  3552. Competition is good.  Unfortunately, the real world does not have the nice
  3553. black and white decisions we would like.  Each competiting system has
  3554. advantages and disadvantages that have to be carefully examined, and, in
  3555. most cases tried.  Opinions have to be heard and the facts weighed.
  3556.  
  3557. The result is usually a good (if not right) decision.  Most packeteers can
  3558. agree today that AX25 was the better way to go initially so the system does
  3559. work (sic). 
  3560.  
  3561. The trick to competition is timing.  At some point, a majority of packeteers
  3562. will be going in the same direction.  The proponents of the other alternatives
  3563. have a choice: they can either abandon their approach and help improve packet
  3564. for all of us or they can keep sapping the strength of amateur radio by
  3565. spending resources and energy on a "dead end".
  3566.  
  3567. If you find your self North while everyone else is going South, it may be
  3568. time to say "Ah, What the Heck" and join the crowd.
  3569.  
  3570. 73, Roy AA4RE
  3571.  
  3572.  
  3573.  
  3574. I thought this might be appropriate at this juncture in the protocol
  3575. wars to give it a wider audience.
  3576.  
  3577. Bob N4HY
  3578.  
  3579.  
  3580. 22-Nov-87 22:31:06-EST,9713;000000000000
  3581. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:31-EST
  3582. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18488@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:13:31 EST
  3583. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18483@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:13:05 EST
  3584. Received: by june.cs.washington.edu (5.52.1/6.11)
  3585.     id AA03078; Sun, 22 Nov 87 18:13:56 PST
  3586. Return-Path: <delni.dec.com!goldstein@decwrl.dec.com>
  3587. Message-Id: <8711230213.AA03078@june.cs.washington.edu>
  3588. Date: 20 Nov 87 18:50:00 GMT
  3589. From: delni.dec.com!goldstein@DECWRL.DEC.COM (Fred R. Goldstein dtn226-7388)
  3590. To: PACKET-RADIO@EDDIE.MIT.EDU
  3591. Subject: Let's calm down the CONS/CLNS flames just a bit?
  3592.  
  3593. The recent go-round by Tom Moulton W2VY and Paul Flaherty N9FZX was fun 
  3594. to read but seems a bit too flamish... let me just correct some
  3595. misunderstandings based upon my (agnostic) rather finite knowledge.
  3596.  
  3597. VY> 1) Is TCP/IP best?
  3598. VY> The basic disadvantage
  3599. VY> is that it is an all or nothing and you must have the whole protocol
  3600. VY> running in your computer to access the network.
  3601.  
  3602. FZX>    I disagree with your contention that the DDN protocols are all or 
  3603. FZX> nothing.  In fact, the only required protocol is IP; the user then 
  3604. FZX> implents only those layers which are useful to the solution of the 
  3605. FZX> problem.   
  3606.  
  3607.     Paul is closer to the mark than Tom, but the implementations,
  3608. not protocols, are what make it so.  Both stacks (COSI and TCP/IP) 
  3609. require L3 to be implemented in the ISs (routers/gateways); the KA9Q
  3610. implementation of IP puts the PAD function (TELNET) in the host only,
  3611. while Tom's COSI will provide an AX.25L2 to COSI gateway PAD.  The
  3612. TCP and other  higher-layers don't have to go in routers anyway.
  3613.  
  3614. VY> 2) COSI Switch - What is it?
  3615. VY>     I am the programmer writing the switch,  it is based on CCITT X.25,
  3616. VY>     (aka ISO 8208) which is the International standard used to connect
  3617. VY>     data networks throughout the world. [note that tcp/ip is also used
  3618. VY>     globally, but isn't accepted by all PTT's, in fact many tcp/ip
  3619. VY>     connections are running on top of X.25]
  3620.  
  3621. VY>     Politics, many PTT's won't accept a new protocol, the COSI suite is
  3622. VY>     going to be following the same standards that they are seeing in the
  3623. VY>     commerical world, how can they say no!
  3624. VY>  
  3625. VY>     The ISO protocols are the next generation of networking which the
  3626. VY>     commerical world is going to.  TCP/IP was developed on the ARPAnet
  3627. VY>     [a US DoD funded project] and while many companies use this protocol
  3628. VY>     many of the "small" companies are working towards these protocols.
  3629. VY>     [companies such as IBM, DEC, Xerox to name the "small ones"]
  3630.  
  3631.     This isn't exactly fair about OSI.  The PTT's adopted X.25
  3632. in 1976 based on their "connection" model of telephony applied to data.
  3633. They know how to bill for connections!  OSI has adopted both connection-
  3634. oriented (ISO 8208) and connectionless (8473) network layers.  The 
  3635. former is really X.25-1984; the latter is new to OSI. 
  3636.  
  3637.     And while many companies are adopting OSI, it doesn't mean we're
  3638. throwing out our other protocols.  OSI is open systems 
  3639. _interconnection_, meaning a common means to link multi-vendor nets 
  3640. together.  DECnet isn't going away even after it adopts OSI (8473) as 
  3641. the basis of its network layer.  This doesn't discredit OSI per se;
  3642. it just means that we don't speak "Church Latin" (or Esperanto, if you 
  3643. prefer that analogy) to members of our own community, even if it's the 
  3644. common language we share with other communities.
  3645.  
  3646. FZX>    People generally don't care who propagates a standard nearly as 
  3647. FZX> much as the care whether or not it solves a problem.  This is why de facto
  3648. FZX> standards get started; and, in a sense, the DDN protocols have become
  3649. FZX> the de facto international protocol.
  3650.  
  3651. True enough at the moment; DDN Suite provides the most popular network 
  3652. functions on a public domain multi-vendor basis.  It does provide an 
  3653. open systems interconnection (lower case) function!  ISO OSI is a more 
  3654. ambitious project of which X.25-1984 is a small piece.
  3655.  
  3656. FZX>    You are confusing medium access protocols with internetworking and
  3657. FZX> transport protocols.  In the first place, in order to accomplish roughly
  3658. FZX> the same goals as TCP/IP, one need x.75 AND TP4, in addition to x.25.
  3659. FZX> Of course, one could just as easily implement TCP/IP on top of x.25, and
  3660. FZX> this has been done in practice.  Moreover, the number of TCP/IP 
  3661. FZX> installations
  3662. FZX> in Europe is growing exponentially, so if the PTTs want to make money, 
  3663. FZX> they'll allow it.  Finally, it's worth noting that IP gives one a much 
  3664. FZX> higher degree of internetworking flexibility than x.75, which is designed
  3665. FZX> for x.25; IP runs just as easily with Ethernet, x.25, AppleTalk, or any of
  3666. FZX> a myriad of data link protocols.  Try doing THAT with x.75.
  3667.  
  3668.     Let's not get TP4 confused with TP0-3.  X.75 is the IS-IS 
  3669. protocol that goes with X.25.  ISO IP (8473) does pretty much what DDN 
  3670. IP does.  When you run either datagramme network layer, you need a good 
  3671. transport to fix it up; TP4 and TCP are quite similar in function though 
  3672. the headers parse quite differently.  If you like TCP you shouldn't 
  3673. dislike TP4, though you might not like TP0 (the "do nothing" Transport)!
  3674.  
  3675.     The hard-core CONS fans in the PTT world prefer lower-class TPs, 
  3676. which require a "perfect" virtual circuit in order to operate.  TP4 is 
  3677. the favorite of datagramme fans _and_ those who don't trust in the perfect 
  3678. reliability of packet switch implementations.
  3679.  
  3680. VY>     Politics, many PTT's won't accept a new protocol, the COSI suite is
  3681. VY>     going to be following the same standards that they are seeing in the
  3682. VY>     commerical world, how can they say no!
  3683.  
  3684. FZX>    They can say no if nobody is using the product.  So far, the growth
  3685. FZX> rate of TCP/IP has outstripped TP4.  PTTs may be political, but they also 
  3686. FZX> like to make money (well, ok, MOST of them, anyway).  Also, TCP/IP is hardly
  3687. FZX> a new protocol; if anything, as a PTT, I'd rather have TCP/IP running, since
  3688. FZX> its failure modes are fairly well known and documented.
  3689.  
  3690. VY>     The ISO protocols are the next generation of networking which the
  3691. VY>     commerical world is going to.  TCP/IP was developed on the ARPAnet
  3692. VY>     [a US DoD funded project] and while many companies use this protocol
  3693. VY>     many of the "small" companies are working towards these protocols.
  3694. VY>     [companies such as IBM, DEC, Xerox to name the "small ones"]
  3695.  
  3696. FZX>    The "next generation" argument smacks of innuendo.  TCP is in fact 
  3697. FZX>a "next generation" protocol, having replace NTP; assuming that TP4 actually
  3698. FZX>improves on TCP (evidence which is lacking at this point), we could implement
  3699. FZX> changes in TCP to accomplish the same thing, and still use the existing IP 
  3700. FZX> layer and everything below it.
  3701.  
  3702.     Better, you could use 8473 (ISO IP) and maybe run TCP et al 
  3703. above it, since IP's addressing is ill-suited to AMPRnet.  Again TP4 is
  3704. not the issue since _it_ runs on top of most anything; TP classes 0 to 3 don't.
  3705.  
  3706. FZX>    TCP/IP was developed on the ARPA _InterNet_, which includes the
  3707. FZX> ARPANET as a member.  Not all research on the DDN protocols has been done
  3708. FZX> with DOD funding; in particular, NFS and BOOTP were developed at Stanford
  3709. FZX> to support our internal networking facilities.
  3710.  
  3711. FZX>    IBM, DEC and Xerox all support implementations of TCP/IP, as well
  3712. FZX> as their own internal protocols (SNA, DECNET, and XNS).  If anything, by
  3713. FZX> promulgating their own internal architectures, they have shown a lack of 
  3714. FZX> faith in the OSI committees to produce anything practical.
  3715.  
  3716.     Horse hockey.  OSI is eminently practical for inter-vendor 
  3717. communication.  SNA wouldn't be too efficient on VAXen nor would DECnet 
  3718. on 370s.  (Though gateways exist in both directions.)  OSI will allow 
  3719. both to communicate on neutral terms.  Maybe TCP/IP would too, but that's 
  3720. not for me to say.
  3721.  
  3722. FZX> And, even assuming a marginal benefit from converting to the OSI
  3723. FZX> protocols (and that's really stretching things), lack of known failure modes
  3724. FZX> introduces unknown and unquantifiable risks into the network, which easily
  3725. FZX> outweighs any gain.
  3726.  
  3727.     Again confusing implementations with protocol.  There are bugs 
  3728. in Phil's TCP/IP code too, and he continues to work on them.  Tom's code
  3729. is new and of course buggy too -- what code isn't?  Star wars?  (HI)
  3730. Implementations aren't the key to protocol beauty contests like this 
  3731. one.
  3732.  
  3733. FZX>    Odd, I thought NET/ROM implemented virtual circuits.  Or at least it
  3734. FZX> did the last time I used it. (Or, should I say, almost did...)
  3735.  
  3736.     NET/ROM uses datagrammes within its private subnet and VCs to 
  3737. the outside world.  So there.  (Telenet did this once, before moving its 
  3738. innards to X.75 since that matched up better with its X.25 outards.)  
  3739. Best or worst of both worlds if you're so inclined, but expedient.
  3740.  
  3741. FZX>    To reiterate my arguments from my last posting, the DDN protocols 
  3742. FZX> have several clear and evident advantages over the OSI suite.  Some of these
  3743. FZX> are related to the fact that TCP/IP has been around awhile (good routing,
  3744. FZX> lots of user layer protocols, and availability), but most are intrinsic
  3745. FZX> (strong internetworking, layering flexibility, subnetting and distributed
  3746. FZX> management, tremendous reliability and throughput).
  3747.  
  3748.     The OSI suite is newer but not intrinsically that different,
  3749. since it includes connectionless as well as X.25-style VC networking.
  3750. Remember that in standardsland, it's easier to write more standards to 
  3751. include everybody than to pick a single solution.
  3752.     fred k1io
  3753.  
  3754.  
  3755. 22-Nov-87 22:42:15-EST,2398;000000000000
  3756. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:42-EST
  3757. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18814@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:38:28 EST
  3758. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18810@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:38:15 EST
  3759. Received: by june.cs.washington.edu (5.52.1/6.11)
  3760.     id AA03741; Sun, 22 Nov 87 18:39:12 PST
  3761. Return-Path: <pyramid!voder!apple!winter@eddie.mit.edu>
  3762. Message-Id: <8711230239.AA03741@june.cs.washington.edu>
  3763. Date: 21 Nov 87 00:00:01 GMT
  3764. From: pyramid!voder!apple!winter@eddie.mit.edu (Patty Winter)
  3765. To: PACKET-RADIO@EDDIE.MIT.EDU
  3766. Subject: Re: Packet freqs
  3767. Summary: Would packet control of a repeater really be secure?
  3768. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <1548@faline.bellcore.com>
  3769.  
  3770. In article <1548@faline.bellcore.com> karn@faline.bellcore.com (Phil R. Karn) 
  3771. writes:
  3772. > [discussion of amateur spectrum above 220.5 MHz]
  3773. >Which gives me an idea: many repeaters have separate, dedicated control
  3774. >links mainly to satisfy FCC requirements. They can and do have secondary
  3775. >command decoders on their regular inputs, and most routine commanding is
  3776. >done this way. The backup control requirement for the voice repeater
  3777. >could instead be provided as a secondary function of a co-located packet
  3778. >switch. In exchange for providing secure and more sophisticated control
  3779. >functions, the packet guys could get an existing antenna and frequency
  3780. >assignment at a good site, and everybody wins.
  3781.  
  3782. Hmmm, intriguing idea. But I don't see how such control would be
  3783. more secure. Control codes flying by on a packet channel would 
  3784. require less (read: none) effort to view than would the DTMF tones
  3785. normally used. I don't know how many packeteers leave MON ON         
  3786. nowadays with all the activity going on, but it wouldn't be
  3787. difficult to set your TNC to grab only those messages going from 
  3788. the repeater's control operators. 
  3789.  
  3790. And even if the control codes were encrypted and then translated 
  3791. at the repeater controller (would that be legal?), I don't expect 
  3792. it would take a diehard hacker long to crack them. Right, Phil? :-)
  3793.  
  3794.  
  3795. Patty
  3796.  
  3797. -- 
  3798.           Patty Winter N6BIS                   (408) 973-2814
  3799.      M/S 2C, Apple Computer, Inc., 20525 Mariani Ave., Cupertino, CA 95014 
  3800.               {decwrl,nsc,sun,dual}!apple!winter
  3801.  
  3802.  
  3803. 22-Nov-87 22:54:58-EST,1908;000000000000
  3804. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:54-EST
  3805. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18953@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:50:36 EST
  3806. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18948@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:50:18 EST
  3807. Received: by june.cs.washington.edu (5.52.1/6.11)
  3808.     id AA04094; Sun, 22 Nov 87 18:51:12 PST
  3809. Return-Path: <ulysses!faline!karn@eddie.mit.edu>
  3810. Message-Id: <8711230251.AA04094@june.cs.washington.edu>
  3811. Date: 22 Nov 87 01:49:01 GMT
  3812. From: ulysses!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  3813. To: PACKET-RADIO@EDDIE.MIT.EDU
  3814. Subject: Re: Packet freqs
  3815. Summary: packet security is quite possible
  3816. Keywords: repeater control, security
  3817. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <6791@apple.UUCP>
  3818.  
  3819. > Hmmm, intriguing idea. But I don't see how such control would be
  3820. > more secure. 
  3821.  
  3822. No problem. See my paper "Another Look at Authentication" in the 6th
  3823. ARRL Computer Networking conference proceedings.
  3824.  
  3825. Basically, the idea is to use DES encryption on the packet. The original
  3826. packet is sent in the clear, but the DES is used to compute a "cipher
  3827. checksum" that is sent along with the packet. By running the same
  3828. algorithm and comparing the results, the receiver can detect bogus or
  3829. corrupted packets.  This technique is in widespread use in the banking
  3830. industry; the detection of forged EFT orders is much more important than
  3831. keeping legitimate orders secret.
  3832.  
  3833. For those of you familiar with DES, the exact technique is to encrypt
  3834. the packet with DES in the Cipher Block Chaining mode, and then transmit
  3835. the original plaintext packet along with the last cipherword.
  3836.  
  3837. This does not violate the FCC restriction on codes and ciphers because no
  3838. information is being hidden; the "ciphertext" (such as it is) is sent along
  3839. with the plaintext that produced it.
  3840.  
  3841. Phil
  3842.  
  3843.  
  3844. 22-Nov-87 22:55:10-EST,2400;000000000000
  3845. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:55-EST
  3846. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18930@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:48:00 EST
  3847. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18925@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:47:47 EST
  3848. Received: by june.cs.washington.edu (5.52.1/6.11)
  3849.     id AA04011; Sun, 22 Nov 87 18:48:40 PST
  3850. From: ihnp4!homxb!whuts!mtune!petsd!pedsgo!pedsga!tsdiag!tom@EDDIE.MIT.edu
  3851. Return-Path: <ihnp4!homxb!whuts!mtune!petsd!pedsgo!pedsga!tsdiag!tom@eddie.mit.edu>
  3852. Message-Id: <8711230248.AA04011@june.cs.washington.edu>
  3853. Date: 21 Nov 87 17:27:12 GMT
  3854. To: PACKET-RADIO@EDDIE.MIT.EDU
  3855. Subject: Re: Level 3 protocols - some info?
  3856. Summary: Sorry Bob some people don't read directions.
  3857. References: <242@ka2qhd.UUCP> <129@tsdiag.UUCP> <1556@faline.bellcore.com> <103@umunhum.STANFORD.EDU>
  3858.  
  3859. Bob, KC2WZ,
  3860.     I hope you noted how your request did not get any reaction until there
  3861. was someone to jump all over.  I personally am trying to have fun with packet
  3862. after all it's a hobby, and I really don't have time for this crap.
  3863.  
  3864. I am tired of this bickering back and forth about the exact words i use in my
  3865. messages, it seems some people don't understand that by attacking my words and
  3866. ideas they are not going to get anywhere, I'm going to do what I believe is
  3867. best for the network.
  3868.  
  3869. I feel that the NETWORK I am working on building will be best to serve our needs.
  3870.  
  3871. I am also sorry that this group did not see fit to honor your request to avoid
  3872. inflammatory remarks, in my comment I may not have succeded 100% but I tried
  3873. and do think I was fair in my remarks.
  3874.  
  3875. We all have two things in common, 1) We are building Alternatives for our USERS
  3876. and 2) We are following the path we feel is best.
  3877.  
  3878. 73 and remember IT'S ONLY A HOBBY
  3879. Tom, W2VY
  3880.  
  3881. Thomas A. Moulton, W2VY          Life is too short to be mad about things.
  3882. Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
  3883. Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
  3884. Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy
  3885. -- 
  3886. Thomas A. Moulton, W2VY          Life is too short to be mad about things.
  3887. Home: (201) 779-W2VY             Packet: w2vy@kd6th  Voice: 145.190 (r)
  3888. Work: (201) 492-4880 x3226       FAX:  (201) 493-9167
  3889. Concurrent Computer Corp.        uucp: ...!ihnp4!hotps!ka2qhd!w2vy
  3890.  
  3891.  
  3892. 22-Nov-87 22:55:57-EST,6809;000000000000
  3893. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 22:55-EST
  3894. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18836@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:41:23 EST
  3895. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18830@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:41:05 EST
  3896. Received: by june.cs.washington.edu (5.52.1/6.11)
  3897.     id AA03782; Sun, 22 Nov 87 18:41:56 PST
  3898. Return-Path: <umunhum!paulf@umunhum.stanford.edu>
  3899. Message-Id: <8711230241.AA03782@june.cs.washington.edu>
  3900. Date: 21 Nov 87 04:29:57 GMT
  3901. From: umunhum!paulf@umunhum.stanford.edu (paulf)
  3902. To: PACKET-RADIO@EDDIE.MIT.EDU
  3903. Subject: %&^#*$BOOM&^%&$
  3904. Reply-To: paulf@umunhum.STANFORD.edu (Paul Flaherty)
  3905. Distribution: world
  3906.  
  3907.  
  3908. >True enough at the moment; DDN Suite provides the most popular network 
  3909. >functions on a public domain multi-vendor basis.  It does provide an 
  3910. >open systems interconnection (lower case) function!  ISO OSI is a more 
  3911. >ambitious project of which X.25-1984 is a small piece.
  3912.  
  3913.     The key operative here is "public domain".  Most of the TCP/IP
  3914. implementations running today were hacked out on the govenment dole, and
  3915. are henceforth free.  Some individuals have even been known to use all of 
  3916. their "recreation time" to do this.
  3917.  
  3918.     This, of course, is entirely unacceptable to certain vendors, who
  3919. woudl stand to make tons of money selling networking software, if the 
  3920. public domain stuff wasn't there.  So, don't be suprised to see them
  3921. hawking their wares here.
  3922.  
  3923.     I strongly disagree with your "more ambitious" labelling of 
  3924. the OSI protocols.  The degree of difference in offerred services is
  3925. slight, yet large enough to make the two protocol sets incompatible.
  3926.  
  3927.     Frankly, all of this reminds me of the US T1 vs. CCITT T1 battles;
  3928. the US poured tons of money to develop the concept, and the CCITT made
  3929. subtle changes, so that the US couldn't sell its technology overseas.
  3930.  
  3931. >       Let's not get TP4 confused with TP0-3.  X.75 is the IS-IS 
  3932. >protocol that goes with X.25.  ISO IP (8473) does pretty much what DDN 
  3933. >IP does.  When you run either datagramme network layer, you need a good 
  3934. >transport to fix it up; TP4 and TCP are quite similar in function though 
  3935. >the headers parse quite differently.  If you like TCP you shouldn't 
  3936. >dislike TP4, though you might not like TP0 (the "do nothing" Transport)!
  3937.  
  3938.     Okay, so if they're so similar, why waste money and effort?
  3939. I know, I know, because it's an INTERNATIONAL STANDARD.  Ptooey.  I like
  3940. TCP because it has fewer internal states than TP4, therefore it will run
  3941. faster almost universally.  And, speaking of fast, what about UDP?
  3942. Incidentally, I'm assuming x.75, since that is the hack that belongs with
  3943. x.25. I'd rather see otherwise...
  3944.  
  3945. >       Better, you could use 8473 (ISO IP) and maybe run TCP et al 
  3946. >above it, since IP's addressing is ill-suited to AMPRnet.  Again TP4 is
  3947. >not the issue since _it_ runs on top of most anything; TP classes 0 to 3 don't.
  3948.  
  3949.     Okay, I'll bite.  Why is IP addressing unsuitable to the ampr?
  3950. Most of the problems which have been brought up (like location routing) could
  3951. be solved via communicating gateways.  The problems that have been mentioned
  3952. are not unknown to research, and have been discussed before in many different
  3953. contexts.
  3954.  
  3955. >FZX>   IBM, DEC and Xerox all support implementations of TCP/IP, as well
  3956. >FZX> as their own internal protocols (SNA, DECNET, and XNS).  If anything, by
  3957. >FZX> promulgating their own internal architectures, they have shown a lack of 
  3958. >FZX> faith in the OSI committees to produce anything practical.
  3959. >       Horse hockey.  OSI is eminently practical for inter-vendor 
  3960. >communication.  SNA wouldn't be too efficient on VAXen nor would DECnet 
  3961. >on 370s.  (Though gateways exist in both directions.)  OSI will allow 
  3962. >both to communicate on neutral terms.  Maybe TCP/IP would too, but that's 
  3963. >not for me to say.
  3964.  
  3965.     Of course TCP/IP isn't practical for inter - vendor communication, 
  3966. because they can't make any money off of it.
  3967.  
  3968.     TCP/IP is the most practical way (at the moment, and otherwise) to
  3969. do inter - vendor machine linking.  And with NFS (which doesn't exist for
  3970. OSI), that linking becomes even more practical and useful.
  3971.  
  3972. >       Again confusing implementations with protocol.  There are bugs 
  3973. >in Phil's TCP/IP code too, and he continues to work on them.  Tom's code
  3974. >is new and of course buggy too -- what code isn't?  Star wars?  (HI)
  3975. >Implementations aren't the key to protocol beauty contests like this 
  3976. >one.
  3977.  
  3978.     Wrong.  Certain features of protocols can make them immune to 
  3979. software faults; conversely, some features make protocols error prone.
  3980. In particular, DDN subnetting isolates faults, and bogus packets (thank
  3981. you, oh Martian Filters).  TP4 has a greater number of internal states,
  3982. which increases the complexity of the code (or state machine) required 
  3983. to implement it, ergo more bugs.
  3984.  
  3985.     This is NOT a beauty contest.  We are trying to make a serious 
  3986. comparison of two protocol families, before we lock ourselves into one.
  3987. That way, we can hopefully avoid expensive mistakes like AX.25.
  3988.  
  3989. >FZX>   Odd, I thought NET/ROM implemented virtual circuits.  Or at least it
  3990. >FZX> did the last time I used it. (Or, should I say, almost did...)
  3991. >       NET/ROM uses datagrammes within its private subnet and VCs to 
  3992. >the outside world.  So there.  (Telenet did this once, before moving its 
  3993. >innards to X.75 since that matched up better with its X.25 outards.)  
  3994. >Best or worst of both worlds if you're so inclined, but expedient.
  3995.  
  3996.     Like I said, NET/ROM implements virtual circuits (out of datagrams).
  3997. Of course, designing a network on TOP of this is uneconomical, since you
  3998. can't take advantage of the economy of UDP packets.  (Yeah, I know about
  3999. x.25 datagrams...nice afterthought.)
  4000.  
  4001. >       The OSI suite is newer but not intrinsically that different,
  4002. >since it includes connectionless as well as X.25-style VC networking.
  4003. >Remember that in standardsland, it's easier to write more standards to 
  4004. >include everybody than to pick a single solution.
  4005. >        fred k1io
  4006.  
  4007.     "Newer". "International". "Advanced". Bull.
  4008.  
  4009.     The de facto international open systems interconnect is TCP/IP.
  4010. The burden of proof clearly lies with those in COSI - land.  Show me
  4011. a significant advantage.  Show me evidence of growth.  Show me freeware.
  4012. Show me a working implentation.  Show me Network Virtual Disk.  Show me 
  4013. what's wrong with the DDN protocols, and the weight of research.
  4014. And, most of all, show me that CCITT isn't screwing the pooch.
  4015.  
  4016.  
  4017.  
  4018.  
  4019.  
  4020. -=Paul Flaherty, N9FZX           | "One Internet to rule them all,
  4021. Computer Systems Laboratory      |          One Internet to find them,
  4022. Stanford University              |  One Internet to bring them all
  4023. Domain: paulf@shasta.Stanford.EDU|          and in the ether bind them." -ToIH
  4024.  
  4025.  
  4026. 22-Nov-87 23:10:31-EST,1886;000000000000
  4027. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 22 Nov 87 23:10-EST
  4028. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18844@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:43:31 EST
  4029. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA18840@EDDIE.MIT.EDU>; Sun, 22 Nov 87 21:43:02 EST
  4030. Received: by june.cs.washington.edu (5.52.1/6.11)
  4031.     id AA03840; Sun, 22 Nov 87 18:43:54 PST
  4032. Return-Path: <Shasta!kaufman@shasta.stanford.edu>
  4033. Message-Id: <8711230243.AA03840@june.cs.washington.edu>
  4034. Date: 21 Nov 87 17:00:06 GMT
  4035. From: Shasta!kaufman@shasta.stanford.edu (Marc Kaufman)
  4036. To: PACKET-RADIO@EDDIE.MIT.EDU
  4037. Subject: Re: Packet freqs
  4038. Keywords: repeater control, security
  4039. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <1548@faline.bellcore.com> <6791@apple.UUCP>
  4040.  
  4041. In article <6791@apple.UUCP> winter@apple.UUCP (Patty Winter) writes:
  4042.  
  4043. >Hmmm, intriguing idea. But I don't see how such control would be
  4044. >more secure. Control codes flying by on a packet channel would 
  4045. >require less (read: none) effort to view than would the DTMF tones
  4046. >normally used. I don't know how many packeteers leave MON ON         
  4047. >nowadays with all the activity going on, but it wouldn't be
  4048. >difficult to set your TNC to grab only those messages going from 
  4049. >the repeater's control operators. 
  4050.  
  4051. Well, my station has an Apple II with a tone decoder chip, that I can
  4052. use to listen to DTMF tones... no problem.  Besides, most people can
  4053. remember tones well enough, for a few minutes, to match them with a telephone.
  4054.  
  4055. I submit that one is not more secure intrinsicly than another, and that
  4056. if the packet message included control characters, or those with bit 8 set,
  4057. it would be just as secure as DTMF.  For real security, you could implement
  4058. a challenge/response algorithm with time varying keys.
  4059.  
  4060. Marc Kaufman, WB6ECE (kaufman@Shasta.stanford.edu)
  4061.  
  4062.  
  4063. 23-Nov-87 15:05:32-EST,540;000000000000
  4064. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Nov 87 15:05-EST
  4065. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02779@EDDIE.MIT.EDU>; Mon, 23 Nov 87 13:47:42 EST
  4066. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02771@EDDIE.MIT.EDU>; Mon, 23 Nov 87 13:47:27 EST
  4067. Date: Mon 23 Nov 87 10:47:35-PST
  4068. From: Allen Takahashi <TAKAHASHI@KL.SRI.COM>
  4069. Subject: Removal
  4070. To: packet-radio@EDDIE.MIT.EDU
  4071. Message-Id: <12352954839.28.TAKAHASHI@KL.SRI.COM>
  4072.  
  4073. Please remove me from the packet-radio list.
  4074. -------
  4075. 23-Nov-87 17:28:55-EST,540;000000000000
  4076. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 23 Nov 87 17:28-EST
  4077. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02779@EDDIE.MIT.EDU>; Mon, 23 Nov 87 13:47:42 EST
  4078. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA02771@EDDIE.MIT.EDU>; Mon, 23 Nov 87 13:47:27 EST
  4079. Date: Mon 23 Nov 87 10:47:35-PST
  4080. From: Allen Takahashi <TAKAHASHI@KL.SRI.COM>
  4081. Subject: Removal
  4082. To: packet-radio@EDDIE.MIT.EDU
  4083. Message-Id: <12352954839.28.TAKAHASHI@KL.SRI.COM>
  4084.  
  4085. Please remove me from the packet-radio list.
  4086. -------
  4087. 24-Nov-87 04:06:26-EST,774;000000000000
  4088. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Nov 87 04:06-EST
  4089. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA20691@EDDIE.MIT.EDU>; Tue, 24 Nov 87 02:58:28 EST
  4090. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA20682@EDDIE.MIT.EDU>; Tue, 24 Nov 87 02:58:14 EST
  4091. Message-Id: <8711240758.AA20682@EDDIE.MIT.EDU>
  4092. Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Tue, 24 Nov 87 02:58 EST
  4093. Date: Tue, 24 Nov 87 02:59 EDT
  4094. From: Ray Wong <UCONRAY%Vms.Cis.Pittsburgh.Edu@VB.CC.CMU.EDU>
  4095. Subject: RE: Delete me for the list
  4096. To: packet-radio@EDDIE.MIT.EDU
  4097. X-Vms-To: IN%"packet-radio@eddie.mit.EDU"
  4098.  
  4099.  
  4100.  
  4101. Yes, please delete the user 000544@pittvms  from the list since this
  4102. person no long is at the university.
  4103.  
  4104. Thank you,
  4105.  
  4106. Ray
  4107. 24-Nov-87 07:49:36-EST,716;000000000000
  4108. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 24 Nov 87 07:49-EST
  4109. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA23888@EDDIE.MIT.EDU>; Tue, 24 Nov 87 06:52:15 EST
  4110. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA23870@EDDIE.MIT.EDU>; Tue, 24 Nov 87 06:51:38 EST
  4111. Received: by trout.nosc.mil (5.58/1.27)
  4112.     id AA10279; Tue, 24 Nov 87 03:53:10 PST
  4113. Date: Tue, 24 Nov 87 03:53:10 PST
  4114. From: maziarz@trout.nosc.mil (Donald R. Maziarz)
  4115. Message-Id: <8711241153.AA10279@trout.nosc.mil>
  4116. To: packet-radio@eddie.mit.edu
  4117. Cc: johnb@trout.nosc.mil, beeler@trout.nosc.mil
  4118. Subject: remove me
  4119.  
  4120. -------
  4121. Please remove me from the packet-radio mail list.  Its been interesting.
  4122. -------
  4123.  
  4124. 25-Nov-87 14:32:08-EST,5430;000000000000
  4125. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 14:32-EST
  4126. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA28061@EDDIE.MIT.EDU>; Wed, 25 Nov 87 12:54:40 EST
  4127. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA26466@EDDIE.MIT.EDU>; Wed, 25 Nov 87 12:12:34 EST
  4128. Message-Id: <8711251712.AA26466@EDDIE.MIT.EDU>
  4129. To: packet-radio@EDDIE.MIT.EDU
  4130. Cc: clements@LF-SERVER-2.BBN.COM
  4131. Subject: PBBSes and Philosophy
  4132. Date: Wed, 25 Nov 87 12:12:53 -0500
  4133. From: clements@LF-SERVER-2.BBN.COM
  4134.  
  4135. >Date: 19 Nov 87 13:34:22 GMT
  4136. >From n2dsy-4!hotps!hou2d!n2dsy  Wed Nov 18 12:17:29 1987 remote from hotps
  4137. >
  4138. >Bob,
  4139. >   Please forward this to W0RLI.
  4140. > 
  4141. > J. Gordon Beattie, Jr., N2DSY
  4142.  
  4143. Hank can be reached as W0RLI @ W0RLI, or at his postal address
  4144. which is published with his widely distributed source code. :-)
  4145.  
  4146.  
  4147. >REGARDING these comments>>>>>
  4148. >> 
  4149. >> Hank did mention that he HAS become ticked off at two people, though,
  4150. >> one JA op and one 2-lander named Brian something, who have
  4151. >> taken Hank's code, modified it slightly and claimed it as their own,
  4152. >> 
  4153. >> ...
  4154.  
  4155. The above "..." deletes the main point of Hank's comment, about
  4156. COPYRIGHTING the modified code.
  4157.  
  4158. >> 
  4159. >> 73,  Bob, K1BC     clements@bbn.com
  4160. >>
  4161.  
  4162. >[From Brian, KA2BQE]
  4163. > Hank and/or Bob,
  4164. > 
  4165. > The code in question started with a pre-release of
  4166. > W0RLI's earliest posted version (on CompuServe) and at this
  4167. > point contains less than 10% of the original code.
  4168.  
  4169. [ Long list of changes and additions deleted here. ]
  4170.  
  4171. Well, Hank's code has certainly improved and changed a lot since
  4172. then, too, including some of the items listed here.  Things he didn't
  4173. do were mostly in the area that your list includes, improving the
  4174. user and sysop interfaces.  I agree, those drastically need
  4175. improvement in Hank's version.
  4176.  
  4177. > In addition, during the
  4178. > first three months, I sent at least 25 bug fixes to the RLI
  4179. > team, most of which were NEVER acknowledged...
  4180.  
  4181. I don't know what to say about this.  My fixes and additions
  4182. were acknowledged, and usually included in the next version.
  4183.  
  4184. > Last but not least, I would very much appreciate your thorough
  4185. > examination of the code I will send you.  This should prove my
  4186. > contentions.
  4187.  
  4188. Thank you for the offer, but, as stated in my previous message, I
  4189. have retired from the PBBS business. I was the second 820 PBBS on
  4190. the air (after W0RLI) back in the dark ages, and I retired my
  4191. 8088 systems this summer.
  4192.  
  4193. > I would ask you, after such examination, to
  4194. > consider sending a retraction/apology onto the NETWORKS as
  4195. > your initial statement which was widely circulated did much to
  4196. > impugn my reputation and the 14 months of intensive work that
  4197. > I have done.  
  4198. > 
  4199. >                     Sincerely,
  4200. >                                Brian Riley, KA2BQE @ KA2BQE
  4201. >                                             609-268-9497
  4202.  
  4203. I have already posted a partial retraction on the word
  4204. "slightly".  I posted it to the same list as the first message.
  4205. If you didn't see it, I'm sorry.  I said I had been repeating my
  4206. impression of what Hank said, and that he may not have used the
  4207. word "slightly".  I said I did not personally know the extent of
  4208. the changes.
  4209.  
  4210. But here's the point:
  4211.  
  4212. The world benefits by the free exchange of ideas.  In the packet
  4213. environment, that includes software.
  4214.  
  4215. Hank's PBBS code, both Xerox 820 based and MS-DOS based, has been
  4216. freely distributed, in both source and binary, since day one.
  4217. It has benefited from the work of many others who have provided
  4218. their efforts just as freely for the common good.
  4219.  
  4220. KA9Q's TCP/IP code has been spreading the same way.  See the book
  4221. "Hackers" by Steve Levy (in which I am mentioned briefly) for a
  4222. clear statement of this philosophy.
  4223.  
  4224. Consider as a counterexample the hoarding of source code for the
  4225. TNC-1 which held us all back for years.  The TNC-2 code is also
  4226. being kept secret.  If sources had been available, we wouldn't
  4227. have all that kludgey code dealing with "*** CONNECT REQUEST ***
  4228. messages and XON/XOFF handling.  We could have fixed the TNCs.
  4229.  
  4230. WA7MBL implemented reverse-forwarding a long time ago. I don't
  4231. know whether he was first, but he was the first that Hank or I
  4232. saw.  And he keeps his code secret and didn't respond to requests
  4233. for his algorithm so Hank could put it in his code compatibly.
  4234. So W0RLI PBBSes didn't get reverse forwarding until recently.
  4235.  
  4236. This message from Brian is the first I have seen offering a copy
  4237. of his sources.  Maybe he has made the offer before, but I
  4238. haven't seen it.  They never made it to any site in the New
  4239. England area THAT I KNOW OF during the development stages.
  4240.  
  4241. Contrast that with the W0RLI and KA9Q systems which are always
  4242. released with sources.  They are posted on Compuserve, on
  4243. SIMTEL-20 on the ARPANET, and on many dial-up BBSes.  And this
  4244. benefits us all.  That difference in philosophy is what Hank was
  4245. objecting to, especially when the undistributed code had been
  4246. based on his freely distributed code.  And I agree with him.
  4247.  
  4248. I do not intend to get into a "My PBBS is better than yours" war.
  4249. Or any other kind of war.  I'm sorry the message I posted before
  4250. got people bent out of shape.  I'm sorry Brian missed the point
  4251. of the message (and deleted it from his followup).
  4252.  
  4253. Let's all try to cooperate a little more, people.
  4254.  
  4255. 73, Bob, K1BC    clements@bbn.com   "Good in the callbook"
  4256. 25-Nov-87 16:17:22-EST,1960;000000000000
  4257. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 16:17-EST
  4258. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01178@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:09:02 EST
  4259. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01169@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:08:47 EST
  4260. Received: by june.cs.washington.edu (5.52.1/6.11)
  4261.     id AA16691; Wed, 25 Nov 87 12:10:19 PST
  4262. Return-Path: <uunet!mnetor!jim@eddie.mit.edu>
  4263. Message-Id: <8711252010.AA16691@june.cs.washington.edu>
  4264. Date: 23 Nov 87 18:35:11 GMT
  4265. From: uunet!mnetor!jim@EDDIE.MIT.edu (Jim Stewart)
  4266. To: PACKET-RADIO@EDDIE.MIT.EDU
  4267. Subject: Re: Packet freqs
  4268. Keywords: repeater control, security
  4269. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <6791@apple.UUCP> <1565@faline.bellcore.com>
  4270.  
  4271. In article <1565@faline.bellcore.com> karn@faline.bellcore.com (Phil R. Karn) writes:
  4272.  
  4273. >Basically, the idea is to use DES encryption on the packet.
  4274. >...This technique is in widespread use in the banking industry;...
  4275.  
  4276. >For those of you familiar with DES, the exact technique is to encrypt
  4277. >the packet with DES in the Cipher Block Chaining mode, and then transmit
  4278. >the original plaintext packet along with the last cipherword.
  4279.  
  4280. Why go to all the trouble of chaining?  As I recall the IBM 3624 cash
  4281. dispenser, while the pin is sent only encrypted, does the verification
  4282. you speak of, with a single random byte sent both inside the encrypted
  4283. field and outside in the clear.  Even though only a single byte is
  4284. used for verification, since DES works in groups of eight bytes, it
  4285. is difficult to tell what the resultant cipher will be without the key.
  4286.  
  4287. In other words, you don't need to chain, just encrypt the first 8 bytes,
  4288. and make sure at least one of those bytes is different in every packet.
  4289.  
  4290. -- 
  4291. Jim Stewart, VE3SRJ
  4292. UUCP:  {decvax|allegra|ihnp4|linus|utcsri}!utzoo!mnetor!jim
  4293. ARPA:  mnetor!jim@seismo.css.gov
  4294. BELL:  (416)475-8980 x303
  4295.  
  4296.  
  4297. 25-Nov-87 16:39:05-EST,6276;000000000000
  4298. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 16:39-EST
  4299. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01235@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:11:47 EST
  4300. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01213@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:10:54 EST
  4301. Received: by june.cs.washington.edu (5.52.1/6.11)
  4302.     id AA16790; Wed, 25 Nov 87 12:12:26 PST
  4303. From: umunhum!!paulf@umunhum.stanford.edu
  4304. Return-Path: <umunhum!!paulf@umunhum.stanford.edu>
  4305. Message-Id: <8711252012.AA16790@june.cs.washington.edu>
  4306. Date: 23 Nov 87 19:35:02 GMT
  4307. To: PACKET-RADIO@EDDIE.MIT.EDU
  4308. Subject: Oh, no, not AGAIN...
  4309. Reply-To: paulf@umunhum.stanford.edu (Paul Flaherty)
  4310.  
  4311. >       Real Live OSI is "public domain" too -- ISO doesn't really like
  4312. >to bless things that cost significant money to license (since ISO 
  4313. >represents many parties, most of whom by definition would be licensees). 
  4314. >Implementations are a different story -- somebody could sell commercial
  4315. >TCP/IP code  (Hmmm, don't Wollangong, NRC, etc.?) or OSI code.
  4316.  
  4317.     I never implied that the Standard itself wouldn't be public domain.
  4318. I'm more concerned with the Implementations, which won't be.  To repeat a 
  4319. point, most TCP/IP sites right now are running public domain software.  Oh
  4320. sure, there are a few people, like Wollongong, who are selling code, but
  4321. what they're really selling is support.  And, TWG WIN-TCP isn't used
  4322. nearly as much as the Tek or CMU ports for VMS, which are available for the
  4323. cost of the tape.
  4324.  
  4325.     The difference here is that the OSI protocols are commercial entities,
  4326. while the DDN protocols are the property of the govenment, and by extension,
  4327. all of us (well, at least in the US).  Commercial entities exist to make 
  4328. money (certainly nothing wrong with that), while governmental entities serve
  4329. their constituency (hopefully).  The long of the short of it is that I don't
  4330. see the same forces in OSI which propelled large numbers of Public Domain
  4331. DDN implementations.
  4332.  
  4333. >       As one who lives in that space, I'll disagree:  AT&T DS-1 was
  4334. >a first stab; CEPT-1 (CCITT style) is a hell of a lot better.  Like 
  4335. >PAL and SECAM vs. NTSC for color TV:  The US innovates, Europe debugs 
  4336. >and comes up with a better standard(s), and other countries manufacture!
  4337.  
  4338.     As one who lived in that space (I used to work for Bell Labs, Toll
  4339. Switching), I'll press the point:  the result of the split was hideously
  4340. expensive to the US, not only in lost overseas sales, but in the expense
  4341. required to maintain the 4ESS International Interfaces (not to mention 
  4342. development, and Bell Labs ain't cheap).  CEPT-1 may be "better" in that
  4343. more calls are carried per trunk, but "what price betterment"?
  4344.  
  4345. >       IP addressing is unsuitable because it 1) requires call to IP 
  4346. >address mapping which is difficult in practice as nets get big (I guess 
  4347. >I don't have faith in on-air nameservers); 2) doesn't allow callsigns in
  4348. >the datagram level headers; and 3) doesn't provide geographic
  4349. >information unless you rule out portable/mobile operation.  And probably
  4350. >other reasons. IP procedures are not the problem, but to be in favor of
  4351. >IP-style connectionless networks, one doesn't have to clone the wireline
  4352. >Internet hook, line and sinker. 
  4353.  
  4354.     Anything can be unsuitable if you don't implent it right.  To 
  4355. address your concerns one by one:
  4356.  
  4357.     1) Empirical experience with the 4.3bsd caching software has shown
  4358.     that most Internet sites do indeed exhibit locality; that is, they
  4359.     tend to access the same few sites over and over again.  A cache size
  4360.     of about 16 is fine for most sites.  With a limited table size, the
  4361.     performance limitation lies with a particular processor's ability,
  4362.     or lack thereof, to handle comparisons within a table.  This is why
  4363.     we've been after the RISC people to keep fast compares, or provide
  4364.     on - chip ARP caches.  Ergo, if this is a problem at all, it is 
  4365.     a processor architecture one.  This is also an artifact of running
  4366.     TCP/IP on top of AX.25, which is dog meat anyway.
  4367.  
  4368.     2) Again, this is an artifact of AX.25.
  4369.  
  4370.     3) You don't WANT your addresses to be geographically significant.
  4371. If they are, then I'll need at least ten personally, as opposed to one with
  4372. CGP.
  4373.  
  4374. >       Priced any Wollangong software lately?  BTW, DECnet and SNA 
  4375. >protocols (most of 'em) are "free", but implementations aren't.
  4376.  
  4377.     That's because DECnet and SNA were promulgated by commercial concerns,
  4378. like OSI.  Again, most implentations of TCP/IP are freeware, or close to it.
  4379.  
  4380. >       Come on.  It may be easier to implement a simpler protocol
  4381. >(how about Kermit for everything? :-) ) but we're not at the stage yet 
  4382. >where we can dismiss DDN-IP/TCP _or_ OSI-IP/TP4 as inherently buggy.
  4383.  
  4384.     Time to go shaving with Occam's Razor.  Clearly kermit does not
  4385. provide the desired user functionality of either DDN or OSI.  But of the
  4386. two, there is little doubt as to which one is simpler internally.  Just going
  4387. by paper alone, the OSI TP4 and IP specs make up twice as many pages as
  4388. TCP and IP. (RFC's 905 and 926 vs 791, 793.)
  4389.  
  4390. >       OSI and COSI aren't the same thing!  Connectionless OSI is alive 
  4391. >and well.  There's lots more work to be done, and TCP/IP is a great 
  4392. >thing for today, but we can't rest on our laurels and halt any progress 
  4393. >that isn't directly upward-compatible with it.
  4394. >       fred k1io
  4395.  
  4396.     Somehow I've never seen it that way.  It makes far more sense to me
  4397. to build on DDN TCP/IP, than to scuttle it and go to the OSI protocols.
  4398. Again, this is because I have yet to see something significant that OSI can do
  4399. that DDN cannot.  Moreover, I see the move as being extremely costly to the
  4400. end user.
  4401.  
  4402.     Upward compatibility is not necessarily a good thing.  It becomes 
  4403. significant only when the foundation architecture has demonstrated enormous
  4404. utility, which TCP/IP has, unquestioningly so.  It becomes a bad thing when
  4405. it gets in the way of clear and significant architectural improvement.  And
  4406. that has yet to be demonstrated with OSI.
  4407.  
  4408.  
  4409.  
  4410.  
  4411.  
  4412.  
  4413.  
  4414. -=Paul Flaherty, N9FZX           | "One Internet to rule them all,
  4415. Computer Systems Laboratory      |          One Internet to find them,
  4416. Stanford University              |  One Internet to bring them all
  4417. Domain: paulf@shasta.Stanford.EDU|          and in the ether bind them." -ToIH
  4418.  
  4419.  
  4420. 25-Nov-87 16:44:07-EST,1622;000000000000
  4421. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 16:44-EST
  4422. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01292@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:14:07 EST
  4423. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01287@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:13:49 EST
  4424. Received: by june.cs.washington.edu (5.52.1/6.11)
  4425.     id AA16966; Wed, 25 Nov 87 12:15:21 PST
  4426. Return-Path: <pyramid!voder!apple!winter@eddie.mit.edu>
  4427. Message-Id: <8711252015.AA16966@june.cs.washington.edu>
  4428. Date: 23 Nov 87 07:15:37 GMT
  4429. From: pyramid!voder!apple!winter@EDDIE.MIT.edu (Patty Winter)
  4430. To: PACKET-RADIO@EDDIE.MIT.EDU
  4431. Subject: Re: AEA PK-232 control (terminal) program
  4432. References: <7410@eddie.MIT.EDU>
  4433.  
  4434. In article <7410@eddie.MIT.EDU> ZMTKeidel%UCIVMSA.BITNET@WISCVM.WISC.EDU writes:
  4435. >I am interested in developing a control program which will interface
  4436. >an Apple MacIntosh with the AEA PK-232.  
  4437.  
  4438. You might want to see whether Jack Brindle has added an AEA package
  4439. to his TAPR and Kantronics versions of MacPacket. He's WA4FIB and is
  4440. at 3155 Resin Street, Marietta, GA 30066. Might save you some work.
  4441.  
  4442. >However, I have heard that
  4443. >there are not many HAMS with MacIntosh computers!  I have one, my
  4444. >roomate has three, and even the engineers at AEA have Mac's.
  4445.  
  4446. Well, I have two. :-) :-)  Unfortunately for your survey, I'm not 
  4447. using either of them for packet....
  4448.  
  4449.  
  4450. Patty
  4451.  
  4452. -- 
  4453.           Patty Winter N6BIS                   (408) 973-2814
  4454.      M/S 2C, Apple Computer, Inc., 20525 Mariani Ave., Cupertino, CA 95014 
  4455.               {decwrl,nsc,sun,dual}!apple!winter
  4456.  
  4457.  
  4458. 25-Nov-87 18:24:07-EST,1649;000000000000
  4459. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 18:24-EST
  4460. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01479@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:22:59 EST
  4461. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA01474@EDDIE.MIT.EDU>; Wed, 25 Nov 87 15:22:45 EST
  4462. Received: by june.cs.washington.edu (5.52.1/6.11)
  4463.     id AA17930; Wed, 25 Nov 87 12:24:20 PST
  4464. Return-Path: <bellcore!faline!karn@eddie.mit.edu>
  4465. Message-Id: <8711252024.AA17930@june.cs.washington.edu>
  4466. Date: 25 Nov 87 01:16:25 GMT
  4467. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  4468. To: PACKET-RADIO@EDDIE.MIT.EDU
  4469. Subject: Re: Packet freqs
  4470. Summary: authentication
  4471. Keywords: repeater control, security
  4472. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <4346@mnetor.UUCP>
  4473.  
  4474. > Why go to all the trouble of chaining?
  4475.  
  4476. Well, it protects against any part of your packet being modified. Of
  4477. course, repeater control packets aren't likely to be very big in the
  4478. first place. If they're 8 bytes or less, then "chaining" has no meaning.
  4479. You just transmit them along with their encrypted equivalents.  Remember
  4480. to include a sequence number or time-of-day clock to prevent playback
  4481. attacks.
  4482.  
  4483. I'm surprised no one has pointed out the one vulnerability of my scheme
  4484. for providing repeater control functions off a packet switch: the
  4485. control frequency becomes known. You may not be able to enter an
  4486. unauthorized command, but you could probably jam out an authorized
  4487. control operator. Of course, in this day of R-7000s it probably woudn't
  4488. take THAT long to track down a control channel if it is used at all.
  4489.  
  4490. Phil
  4491.  
  4492.  
  4493. 25-Nov-87 21:10:39-EST,861;000000000000
  4494. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 21:10-EST
  4495. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06583@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:46:34 EST
  4496. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06573@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:46:18 EST
  4497. Received: from huey.udel.edu by Louie.UDEL.EDU id aa07498; 25 Nov 87 19:10 EST
  4498. Date:     Wed, 25 Nov 87 19:08:53 EST
  4499. From: Mills@UDEL.EDU
  4500. To: "Phil R. Karn" <bellcore!faline!karn@eddie.mit.edu>
  4501. Cc: PACKET-RADIO@eddie.mit.edu
  4502. Subject:  Re:  Packet freqs
  4503. Message-Id:  <8711251908.aa08427@Huey.UDEL.EDU>
  4504.  
  4505. Phil,
  4506.  
  4507. The easy way to do it is to encrypt the checksums. Yaas, yaas, you can
  4508. byte-swamp the entire message, sort the words and still come out with
  4509. the same checksums, but that is independent of the encryption. Life
  4510. is much too short.
  4511.  
  4512. Dave
  4513. 25-Nov-87 21:31:33-EST,2506;000000000000
  4514. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 21:31-EST
  4515. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06743@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:55:05 EST
  4516. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06739@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:54:43 EST
  4517. Received: by june.cs.washington.edu (5.52.1/6.11)
  4518.     id AA25005; Wed, 25 Nov 87 15:12:03 PST
  4519. Return-Path: <athena.mit.edu!wesommer@athena.mit.edu>
  4520. Message-Id: <8711252312.AA25005@june.cs.washington.edu>
  4521. From: athena.mit.edu!wesommer@athena.mit.edu (William Sommerfeld)
  4522. To: PACKET-RADIO@EDDIE.MIT.EDU
  4523. Subject: Re: Packet freqs
  4524. Keywords: repeater control, security
  4525. Date: 24 Nov 87 10:53:53 GMT
  4526. References: <698@uop.UUCP> <1532@faline.bellcore.com> <250@splut.UUCP> <6791@apple.UUCP> <1565@faline.bellcore.com> <4346@mnetor.UUCP>
  4527. Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
  4528.  
  4529. In article <4346@mnetor.UUCP> jim@mnetor.UUCP (Jim Stewart) writes:
  4530. >Why go to all the trouble of chaining?  As I recall the IBM 3624 cash
  4531. >dispenser, while the pin is sent only encrypted, does the verification
  4532. >you speak of, with a single random byte sent both inside the encrypted
  4533. >field and outside in the clear.  Even though only a single byte is
  4534. >used for verification, since DES works in groups of eight bytes, it
  4535. >is difficult to tell what the resultant cipher will be without the key.
  4536. >
  4537. >In other words, you don't need to chain, just encrypt the first 8 bytes,
  4538. >and make sure at least one of those bytes is different in every packet.
  4539.  
  4540. If the "command" you send extends outside the first cypher block, then
  4541. someone wanting to spoof the repeater could listen in and grab the
  4542. first and last cypher blocks of the transmission, and later replay
  4543. those blocks, bracketing a modified command.
  4544.  
  4545. Of course, even if you do CBC encrypt the whole message, and send the
  4546. final checksum, you still stand the risk of someone just replaying
  4547. your transmission verbatim at a later time (not being particularly
  4548. familiar with the workings of repeaters, I assume that typical
  4549. repeater control commands are simple things such as "shut down the
  4550. repeater" or "disable the autopatch"); this kind of defeats the
  4551. purpose of encrypting. 
  4552.  
  4553. To _really_ guard against tampering, you have to include some sort of
  4554. timestamp/sequence number in the plaintext message, which the repeater
  4555. would know how to verify for each authorized control operator.
  4556.  
  4557.                 Bill Sommerfeld, N1FHN
  4558.                 wesommer@athena.mit.edu
  4559.  
  4560.  
  4561. 25-Nov-87 21:39:10-EST,1954;000000000000
  4562. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 21:39-EST
  4563. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06756@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:55:31 EST
  4564. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06745@EDDIE.MIT.EDU>; Wed, 25 Nov 87 19:55:15 EST
  4565. Received: by june.cs.washington.edu (5.52.1/6.11)
  4566.     id AA25901; Wed, 25 Nov 87 15:23:28 PST
  4567. Return-Path: <bellcore!faline!karn@EDDIE.MIT.EDU>
  4568. Message-Id: <8711252323.AA25901@june.cs.washington.edu>
  4569. Date: 25 Nov 87 03:43:15 GMT
  4570. From: bellcore!faline!karn@eddie.mit.edu (Phil R. Karn)
  4571. To: PACKET-RADIO@EDDIE.MIT.EDU
  4572. Subject: Re: IP and roundtables/nets?
  4573. Summary: multicasting is much easier if the subnet supports it
  4574. Keywords: multicasting, UDP
  4575. References: <4732@spool.wisc.edu>
  4576.  
  4577. > problems involved, but I was wondering if anyone had done any work
  4578. > on multiconnection or multicast protocols that would support such things.
  4579.  
  4580. This is one of my favorite back-burner topics. Right now we are almost
  4581. completely squandering one of the few advantages that radio has for
  4582. sending data (other than it being "fun", of course!). That is, the
  4583. ability for a single transmission to be heard by multiple receivers.
  4584. Existing "conference bridges" that send N copies of the data out on N
  4585. separate virtual circuits to N different receivers (all on the same
  4586. channel) are utterly silly.
  4587.  
  4588. Multicasting is FAR easier when the "subnet" (e.g., radio channel and
  4589. associated hardware) supports it directly. Lossy channels make reliable
  4590. multicasting almost impossible, so things should be configured such that
  4591. each packet will get through with a very high degree of probability
  4592. WITHOUT acknowledgements from each receiver. This means coordinated
  4593. frequency assignments, full-duplex operation (most likely cross-band)
  4594. and other things that I talked about in my ARRL conference paper "A High
  4595. Performance Collision Free Packet Radio Network".
  4596.  
  4597. Phil
  4598.  
  4599.  
  4600. 25-Nov-87 21:45:58-EST,1679;000000000000
  4601. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 21:45-EST
  4602. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07231@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:24:45 EST
  4603. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07224@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:24:24 EST
  4604. Received: by june.cs.washington.edu (5.52.1/6.11)
  4605.     id AA25151; Wed, 25 Nov 87 15:13:15 PST
  4606. Return-Path: <husc6!uwvax!caseus!dan@EDDIE.MIT.EDU>
  4607. Message-Id: <8711252313.AA25151@june.cs.washington.edu>
  4608. Date: 24 Nov 87 14:38:56 GMT
  4609. From: husc6!uwvax!caseus!dan@eddie.mit.edu (Daniel M. Frank)
  4610. To: PACKET-RADIO@EDDIE.MIT.EDU
  4611. Subject: IP and roundtables/nets?
  4612. Keywords: multicasting, UDP
  4613. Reply-To: dan@caseus.wisc.edu (Daniel M. Frank)
  4614.  
  4615.    I vaguely remember this question being brought up a while back, so 
  4616. I apologize for the repetition ...
  4617.  
  4618.    The NTS people in Wisconsin are starting to talk about setting up
  4619. an organized packet network in the state, mostly for traffic handling.
  4620. One of the questions that came up was about support for roundtable
  4621. traffic nets.  I'm aware of some of the technical and performance
  4622. problems involved, but I was wondering if anyone had done any work
  4623. on multiconnection or multicast protocols that would support such things.
  4624. I know there are some RFCs on multicasting.  Is any of this work
  4625. applicable?
  4626.  
  4627.    Also, I'd appreciate getting any "case histories" of TCP/IP use for 
  4628. intrastate traffic handling, for obvious reasons.
  4629.  
  4630.    Thanks!
  4631.  
  4632.       Dan Frank  (w9nk)
  4633.     ARPA: dan@db.wisc.edu   UUCP: ... uwvax!dan
  4634.       Attention Democratic Party Line Eater:
  4635.     {prosperity,freedom,work,responsibility,honesty,self-reliance}
  4636.  
  4637.  
  4638. 25-Nov-87 21:56:04-EST,1999;000000000000
  4639. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 21:56-EST
  4640. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07248@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:25:29 EST
  4641. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07234@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:25:00 EST
  4642. Received: by june.cs.washington.edu (5.52.1/6.11)
  4643.     id AA25784; Wed, 25 Nov 87 15:20:18 PST
  4644. Return-Path: <pyramid!prls!philabs!trotter!bill@EDDIE.MIT.EDU>
  4645. Message-Id: <8711252320.AA25784@june.cs.washington.edu>
  4646. Date: 23 Nov 87 17:08:10 GMT
  4647. From: pyramid!prls!philabs!trotter!bill@eddie.mit.edu (Bill Gunshannon)
  4648. To: PACKET-RADIO@EDDIE.MIT.EDU
  4649. Subject: Re: Let's calm down the CONS/CLNS flames just a bit?
  4650. Summary: N2WX Level 3 Switch
  4651. References: <8711201629.AA23107@decwrl.dec.com>
  4652.  
  4653.  
  4654. I have a new question.  Why is it with all the arguments about COSI,
  4655. TCP-IP, NETROM, etc. I never hear anyone mention the N2WX Level 3 Switch
  4656. software.  I just put up a PAC-COMM DR200 and am impressed by what I have
  4657. seen so far.  
  4658.  
  4659. I would be interested in hearing from anyone else who has experience with
  4660. this software.  I would like to learn more about the statistics and also
  4661. if there are any major or minor networks set up using it.  I am trying to
  4662. get something going on 6 meters here on the east coast.  Maybe this would
  4663. be a good way to start.  If others are interested we can try and set up an
  4664. engineered network rather than just letting it grow out of control on it's
  4665. own (145.01).
  4666.  
  4667. Any information or comments would be appreciated.
  4668.  
  4669. And by the way how does one get in touch with N2WX??? Is he on the net 
  4670. anywhere??
  4671.  
  4672. 73's
  4673.  
  4674.  
  4675. bill gunshannon
  4676.  
  4677.  
  4678. UUCP: {philabs}\                        US SNAIL: Martin Marietta Data Systems 
  4679.       {phri   } >!trotter.usma.edu!bill           USMA, Bldg 600, Room 26 
  4680.       {sunybcs}/                                  West Point, NY  10996      
  4681. RADIO:         KB3YV                    PHONE: WORK    (914)446-7747
  4682. AX.25:         KB3YV @ K3RLI            PHONE: HOME    (914)565-5256
  4683.  
  4684.  
  4685. 25-Nov-87 22:13:00-EST,5134;000000000000
  4686. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 22:12-EST
  4687. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06863@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:03:12 EST
  4688. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA06859@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:02:59 EST
  4689. Received: by june.cs.washington.edu (5.52.1/6.11)
  4690.     id AA16560; Wed, 25 Nov 87 12:06:45 PST
  4691. Return-Path: <delni.dec.com!goldstein@DECWRL.DEC.COM>
  4692. Message-Id: <8711252006.AA16560@june.cs.washington.edu>
  4693. Date: 23 Nov 87 18:02:00 GMT
  4694. From: delni.dec.com!goldstein@DECWRL.DEC.COM (Fred R. Goldstein dtn226-7388)
  4695. To: PACKET-RADIO@EDDIE.MIT.EDU
  4696. Subject: trying to throw water on protocol flames
  4697.  
  4698. Paul Flaherty replies to me, 
  4699.  
  4700. IO>True enough at the moment; DDN Suite provides the most popular network 
  4701. IO>functions on a public domain multi-vendor basis.  It does provide an 
  4702. IO>open systems interconnection (lower case) function!  ISO OSI is a more 
  4703. IO>ambitious project of which X.25-1984 is a small piece.
  4704.  
  4705. FZX>    The key operative here is "public domain".  Most of the TCP/IP
  4706. FZX>implementations running today were hacked out on the govenment dole, and
  4707. FZX>are henceforth free.  Some individuals have even been known to use all of 
  4708. FZX>their "recreation time" to do this.
  4709.  
  4710. FZX>    This, of course, is entirely unacceptable to certain vendors, who
  4711. FZX>woudl stand to make tons of money selling networking software, if the 
  4712. FZX>public domain stuff wasn't there.  So, don't be suprised to see them
  4713. FZX>hawking their wares here.
  4714.  
  4715.     Real Live OSI is "public domain" too -- ISO doesn't really like
  4716. to bless things that cost significant money to license (since ISO 
  4717. represents many parties, most of whom by definition would be licensees). 
  4718. Implementations are a different story -- somebody could sell commercial
  4719. TCP/IP code  (Hmmm, don't Wollangong, NRC, etc.?) or OSI code.
  4720.  
  4721. FZX>    Frankly, all of this reminds me of the US T1 vs. CCITT T1 battles;
  4722. FZX> the US poured tons of money to develop the concept, and the CCITT made
  4723. FZX> subtle changes, so that the US couldn't sell its technology overseas.
  4724.  
  4725.     As one who lives in that space, I'll disagree:  AT&T DS-1 was
  4726. a first stab; CEPT-1 (CCITT style) is a hell of a lot better.  Like 
  4727. PAL and SECAM vs. NTSC for color TV:  The US innovates, Europe debugs 
  4728. and comes up with a better standard(s), and other countries manufacture!
  4729.  
  4730. IO> If you like TCP you shouldn't 
  4731. IO>dislike TP4, though you might not like TP0 (the "do nothing" Transport)!
  4732.  
  4733. FZX> And, speaking of fast, what about UDP?
  4734.  
  4735.     ISO is beginning to look at connectionless applications stacks.
  4736. They're behind.
  4737.  
  4738. FZX>    Okay, I'll bite.  Why is IP addressing unsuitable to the ampr?
  4739.  
  4740.     IP addressing is unsuitable because it 1) requires call to IP 
  4741. address mapping which is difficult in practice as nets get big (I guess 
  4742. I don't have faith in on-air nameservers); 2) doesn't allow callsigns in
  4743. the datagram level headers; and 3) doesn't provide geographic
  4744. information unless you rule out portable/mobile operation.  And probably
  4745. other reasons. IP procedures are not the problem, but to be in favor of
  4746. IP-style connectionless networks, one doesn't have to clone the wireline
  4747. Internet hook, line and sinker. 
  4748.  
  4749. FZX>    Of course TCP/IP isn't practical for inter - vendor communication, 
  4750. FZX>because they can't make any money off of it.
  4751.  
  4752.     Priced any Wollangong software lately?  BTW, DECnet and SNA 
  4753. protocols (most of 'em) are "free", but implementations aren't.
  4754.  
  4755. IO>Implementations aren't the key to protocol beauty contests like this 
  4756. IO>one.
  4757.  
  4758. FZX>    Wrong.  Certain features of protocols can make them immune to 
  4759. FZX>software faults; conversely, some features make protocols error prone.
  4760.  
  4761.     Come on.  It may be easier to implement a simpler protocol
  4762. (how about Kermit for everything? :-) ) but we're not at the stage yet 
  4763. where we can dismiss DDN-IP/TCP _or_ OSI-IP/TP4 as inherently buggy.
  4764.  
  4765. FZX>    This is NOT a beauty contest.  We are trying to make a serious 
  4766. FZX>comparison of two protocol families, before we lock ourselves into one.
  4767. FZX>That way, we can hopefully avoid expensive mistakes like AX.25.
  4768.  
  4769.     I agree on the goal!  But OSI is not one protocol stack like
  4770. DDN; it is a family whose members are not all in agreement (i.e., the
  4771. X.25-TP0 clan vs. 8473-TP4).  BTW, the term "protocol beauty contest"
  4772. comes from Eric K3NA in his agendas for ANSI T1D1.2 a couple years 
  4773. back; I confess to having stolen his term.
  4774.  
  4775. FZX>    The de facto international open systems interconnect is TCP/IP.
  4776.  
  4777.     True.  Today.  If it accomodates your "style of computing";
  4778. it won't fit in all the mainframers who are playing OSI.  It does
  4779. handle AMPR nicely, except for the addressing and concomitant routing 
  4780. problems.
  4781.  
  4782. FZX>The burden of proof clearly lies with those in COSI - land.  
  4783.  
  4784.     OSI and COSI aren't the same thing!  Connectionless OSI is alive 
  4785. and well.  There's lots more work to be done, and TCP/IP is a great 
  4786. thing for today, but we can't rest on our laurels and halt any progress 
  4787. that isn't directly upward-compatible with it.
  4788.        fred k1io
  4789.  
  4790.  
  4791. 25-Nov-87 23:40:13-EST,2093;000000000000
  4792. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 25 Nov 87 23:40-EST
  4793. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07197@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:23:05 EST
  4794. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07193@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:22:44 EST
  4795. Received: by june.cs.washington.edu (5.52.1/6.11)
  4796.     id AA26180; Wed, 25 Nov 87 15:29:37 PST
  4797. Return-Path: <bellcore!faline!karn@EDDIE.MIT.EDU>
  4798. Message-Id: <8711252329.AA26180@june.cs.washington.edu>
  4799. Date: 25 Nov 87 03:09:48 GMT
  4800. From: bellcore!faline!karn@eddie.mit.edu (Phil R. Karn)
  4801. To: PACKET-RADIO@EDDIE.MIT.EDU
  4802. Subject: Re: Repeater advice anyone?
  4803. Summary: problems with implicit acks
  4804. References: <7446@eddie.MIT.EDU>
  4805.  
  4806. > DARPA packet radios use a technique called pacing, in which the onward
  4807. > transmission of a packet from the digipeater to the next hop is heard
  4808. > by the original transmitter as the ACK for its transmission. Since the
  4809. > digipeater will delay until the channel is quiet, this forms an automatic
  4810. > sensing mechanism for hidden transmitters and without the channel overhead
  4811. > of additional ACKs. The sender, of course, should delay once his relayed
  4812. > transmission is heard to avoid collision on the next hop, just as you
  4813. > describe.
  4814.  
  4815. "Implicit acks" (using the retransmission of your packet by a digipeater
  4816. as an acknowledgement that your packet was received by the digipeater)
  4817. is an appealing idea. It does have its pitfalls, though.  The protocol
  4818. must be designed to allow the digipeater to filter out duplicates
  4819. generated when the sending station doesn't hear the retransmission of a
  4820. packet even though the digipeater relayed it successfully to the next
  4821. station down the chain.  Otherwise it's possible to get a geometric
  4822. explosion of duplicate packets.
  4823.  
  4824. Hidden transmitters are still a problem, since there may be "hidden"
  4825. traffic on frequency that doesn't involve the digipeater. And there can,
  4826. of course, be collisions by user stations out of direct range with each
  4827. other that try to access the digipeater simultaneously.
  4828.  
  4829. Phil
  4830.  
  4831.  
  4832. 26-Nov-87 00:00:05-EST,4851;000000000000
  4833. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Nov 87 00:00-EST
  4834. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07221@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:24:08 EST
  4835. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA07204@EDDIE.MIT.EDU>; Wed, 25 Nov 87 20:23:27 EST
  4836. Received: by june.cs.washington.edu (5.52.1/6.11)
  4837.     id AA26038; Wed, 25 Nov 87 15:27:37 PST
  4838. Return-Path: <bellcore!faline!karn@EDDIE.MIT.EDU>
  4839. Message-Id: <8711252327.AA26038@june.cs.washington.edu>
  4840. From: bellcore!faline!karn@EDDIE.MIT.edu (Phil R. Karn)
  4841. To: PACKET-RADIO@EDDIE.MIT.EDU
  4842. Newsgroups: rec.ham-radio.packet
  4843. Subject: Re: trying to throw water on protocol flames
  4844. Summary: ip addressing
  4845. Date: 25 Nov 87 03:00:17 GMT
  4846. References: <8711231507.AA07190@decwrl.dec.com>
  4847.  
  4848. >       IP addressing is unsuitable because it 1) requires call to IP 
  4849. > address mapping which is difficult in practice as nets get big (I guess 
  4850. > I don't have faith in on-air nameservers); 2) doesn't allow callsigns in
  4851. > the datagram level headers; and 3) doesn't provide geographic
  4852. > information unless you rule out portable/mobile operation.  And probably
  4853. > other reasons. IP procedures are not the problem, but to be in favor of
  4854. > IP-style connectionless networks, one doesn't have to clone the wireline
  4855. > Internet hook, line and sinker. 
  4856.  
  4857. We've been over this one many times, in many different forms. You will
  4858. need one of the following in ANY amateur network:
  4859.  
  4860. 1. callsign to address mapping 
  4861.  
  4862.     -or-
  4863.  
  4864. 2. "flat" routing tables large enough to hold an entry for each and
  4865. every station in the network.
  4866.  
  4867. The fundamental problem is that callsigns do not contain any information
  4868. about geographic location. Even if they did, they would not necessarily
  4869. tell you anything useful about routing. Hence you will always need
  4870. *some* routing tables, flat or hierarchical. Given (for the moment) that
  4871. purely "flat" routing tables are impractically large, we will have to
  4872. incur the administrative burden of assigning addresses to stations with
  4873. the topology of the network in mind, and of mapping callsigns to these
  4874. addresses.
  4875.  
  4876. We have no lack of proposals for addressing schemes. Grid squares,
  4877. telephone area codes, airport identifiers, postal zip codes and even
  4878. congressional districts have been proposed. Each has ardent proponents
  4879. who argue that theirs is *the* easiest to use. True enough, almost
  4880. everyone knows their own telephone number, mailing address and home
  4881. airport. Most hams know, or can easily find out, what grid square they
  4882. live in. Some even know the name of their Representative (though not
  4883. necessarily his district number). One problem with all these schemes,
  4884. however, is that they are based on geography, politics and historical
  4885. accidents, not network topology.  Another, more serious one: you may know
  4886. your own address well enough, but how will you find that of your
  4887. destination party if all you know is his callsign?
  4888.  
  4889. Worse, consider a station operating portable or mobile.  (Amateur packet
  4890. voice is not that far away). Must he change his address and notify
  4891. everyone who might try to reach him when operating away from home, even
  4892. temporarily? (I thought we were trying to avoid the "frequently updated
  4893. distributed database", i.e., "nameserver", problem).
  4894.  
  4895. Clearly, you want address assignments to be relatively stable, whether
  4896. or not you happen to believe in nameservers. (SOME mechanism will have
  4897. to be found to publish address assignments, and even if this is done
  4898. through the network itself you want to minimize the frequency of
  4899. changes). Any attempt to "hardwire" geographic location fields into addresses
  4900. is therefore a Bad Idea, not only because it makes life hard for those
  4901. trying to communicate with stations in motion, but because it makes
  4902. addresses so much larger without commeasurate benefit.
  4903.  
  4904. Surely our network should be able to allow at least a small number of
  4905. stations to move around without immediately forcing them to change
  4906. addresses. What's needed is a hybrid between hierarchical and flat
  4907. addressing that combines the efficiency of the former for the majority
  4908. of stations that remain fixed with the flexibility of the latter for
  4909. those relatively few stations in motion. I believe I have laid the
  4910. foundation for this in the way I've implemented IP address routing in my
  4911. TCP/IP package; we simply don't need the kind of address expansion Fred
  4912. proposes.
  4913.  
  4914. One final, radical, thought: flat addressing isn't all that unthinkable
  4915. anymore. Consider that there are only about 300,000 hams in the US (in
  4916. very round numbers). Dynamic RAM is now cheap enough that I could store
  4917. an IP routing table entry for each and every US ham in perhaps $125
  4918. worth of chips, even without any clever storage compression tricks.  And
  4919. that price is of course only going to go down.
  4920.  
  4921. Phil
  4922.  
  4923.  
  4924. 26-Nov-87 02:00:00-EST,1342;000000000000
  4925. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Nov 87 01:59-EST
  4926. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA11189@EDDIE.MIT.EDU>; Thu, 26 Nov 87 00:47:30 EST
  4927. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA11177@EDDIE.MIT.EDU>; Thu, 26 Nov 87 00:47:13 EST
  4928. Received: from huey.udel.edu by Louie.UDEL.EDU id aa12294; 26 Nov 87 0:45 EST
  4929. Date:     Thu, 26 Nov 87 0:42:09 EST
  4930. From: Mills@UDEL.EDU
  4931. To: "Phil R. Karn" <bellcore!faline!karn@eddie.mit.edu>
  4932. Cc: PACKET-RADIO@eddie.mit.edu
  4933. Subject:  Re:  Repeater advice anyone?
  4934. Message-Id:  <8711260042.aa00464@Huey.UDEL.EDU>
  4935.  
  4936. Phil,
  4937.  
  4938. All that is quite true, but pacing sure improves performance of the system.
  4939. Next bauble to play is tier-based routing, a variant of distributed
  4940. Bellman-Ford (min-hop) algorithms in which a relayed packet can go
  4941. "forward," "sideways" (by one hop), but not "backwards."
  4942.  
  4943. Gently, gently the DARPA secrets are exposed to the teeming throng. See
  4944. Proc. IEEE November 1978 and subsequent articles scattered widely and
  4945. thinly so you may never find them. Unfortunately, the SURAN (Survivable
  4946. Radio Network) program has not published on the traditional RFC (Request
  4947. for Comments) frequencies, so the technology has fallen below the noise
  4948. level of most receivers. Maybe something can be done about that.
  4949.  
  4950. Dave
  4951. 26-Nov-87 03:42:16-EST,1115;000000000000
  4952. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Nov 87 03:42-EST
  4953. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA11075@EDDIE.MIT.EDU>; Thu, 26 Nov 87 00:37:01 EST
  4954. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA11061@EDDIE.MIT.EDU>; Thu, 26 Nov 87 00:36:42 EST
  4955. Received: from huey.udel.edu by Louie.UDEL.EDU id aa11754; 26 Nov 87 0:34 EST
  4956. Date:     Thu, 26 Nov 87 0:32:20 EST
  4957. From: Mills@UDEL.EDU
  4958. To: "Phil R. Karn" <bellcore!faline!karn@eddie.mit.edu>
  4959. Cc: PACKET-RADIO@eddie.mit.edu
  4960. Subject:  Re:  IP and roundtables/nets?
  4961. Message-Id:  <8711260032.aa00434@Huey.UDEL.EDU>
  4962.  
  4963. Phil,
  4964.  
  4965. I recommend the NCC Proceedings 1979 (Washington, DC) in which the DARPA
  4966. SATNET system "coming out party" was honked to the world precisely on
  4967. the merits you suggest and subsequently forgotten. Even INTELSAT forgot,
  4968. in spite of my hooting and hollering at the time. The broadcast nature
  4969. of the satellite/packet-radio channel is an exquisitely precious feature
  4970. too valuable to ignore. Virtual-circuit fanatics should really learn to
  4971. understand and exploit this feature.
  4972.  
  4973. Dave
  4974. 26-Nov-87 12:19:17-EST,528;000000000000
  4975. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Nov 87 12:19-EST
  4976. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA19194@EDDIE.MIT.EDU>; Thu, 26 Nov 87 11:38:06 EST
  4977. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA19186@EDDIE.MIT.EDU>; Thu, 26 Nov 87 11:37:56 EST
  4978. Date:  Thu, 26 Nov 87 11:36 EST
  4979. From: McAuliffe@RADC-MULTICS.ARPA
  4980. Subject:  Removal
  4981. To: packet-radio@EDDIE.MIT.EDU
  4982. Message-Id:  <871126163602.385105@RADC-MULTICS.ARPA>
  4983.  
  4984. Please remove me from the packet-radio list also.
  4985. 26-Nov-87 22:59:34-EST,5278;000000000000
  4986. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 26 Nov 87 22:59-EST
  4987. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA25289@EDDIE.MIT.EDU>; Thu, 26 Nov 87 22:03:12 EST
  4988. Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <AA25282@EDDIE.MIT.EDU>; Thu, 26 Nov 87 22:02:58 EST
  4989. Resent-Message-Id: <8711270302.AA25282@EDDIE.MIT.EDU>
  4990. Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 26 Nov 87 22:09:11 EST
  4991. Date: Wednesday, 25 November 1987  13:53-MST
  4992. Message-Id: <KPETERSEN.12353831510.BABYL@SIMTEL20.ARPA>
  4993. Sender: deneb.ucdavis.edu!ccruss@UCDAVIS.UCDAVIS.EDU (Russ Hobby)
  4994. From: deneb.ucdavis.edu!ccruss@UCDAVIS.UCDAVIS.EDU (Russ Hobby)
  4995. To: tcp-ip@SRI-NIC.ARPA
  4996. Subject:   SLIP software available
  4997. Resent-From: KPETERSEN@SIMTEL20.ARPA
  4998. Resent-To: packet-radio%eddie.mit.edu@mc.lcs.mit.edu
  4999. Resent-Date: Thu 26 Nov 1987 20:03-MST
  5000.  
  5001. Yes,  we have a SLIP server implementation  now ready. The reason I have 
  5002. not  posted it sooner is  because we have been  working with the Sun NFS 
  5003. people  on the method of establishing a  dialin slip connection and have 
  5004. been   refitting   some   of   their   suggestions   into  our  version.  
  5005.  
  5006. The software allows PCs to make dialup SLIP connections to the campus IP 
  5007. network. We are also have worked out a method of abbreviated serial line 
  5008. IP  (ASLIP) packeting that makes dialup  IP networks more efficient. The 
  5009. ASLIP software is new to this version and Sun has not seen it yet. 
  5010.  
  5011. Here  is how  the system  works. The  user logs  on to  the host that is 
  5012. acting  as the gateway, a  4.3 bsd system. He  then types in the command 
  5013. "slip"  and he becomes  a host on  the network. He  can then use all the 
  5014. programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make 
  5015. connecting  to the network  a little easier,  we have written  a program 
  5016. that  will do the complete  login automatically. The program  has a user 
  5017. configurable  script file that  specifies a sequence  of strings to send 
  5018. out  the serial line and  responses to wait for  coming back. It has its 
  5019. own  simple language with branching depending on if the correct response 
  5020. came  back. The net result is that after the script has been set up, the 
  5021. user types in one command on the PC to connect to the network. 
  5022.  
  5023. Unlike  some PC/IPs, our system  assumes that each PC  (or actually each 
  5024. user)  has its own, permanent IP address.  Security is provided by logon 
  5025. security  on the gateway  host. The IP  address of the  PC is associated 
  5026. with  the usercode on the gateway host.  The network connection for that 
  5027. PC's  IP address  can only  be started  from a  user logged  in with the 
  5028. correct  usercode. The system also makes sure that the IP address is not 
  5029. already connected before making a new connection. 
  5030.  
  5031. The  way we have  set up IP  address for the  PCs is to  have a separate 
  5032. subnet  that contains all the PCs. This  way the gateway host needs only 
  5033. to  advertise that  it is  a route  to that  subnet and  all the PCs are 
  5034. covered.  In  essence  the  gateway  host  is  the  network for all SLIP 
  5035. connections on that subnet. 
  5036.  
  5037. The  abbreviated  packets  work  on  the  assumption that the connecting 
  5038. computer  is an endnode and will not be  doing any routing. In this case 
  5039. many  of the  fields in  the IP  packet are  unnecessary. ASLIP uses the 
  5040. minimum header size based on this assumption. With ASLIP the header size 
  5041. is  either 8 or  4 bytes, much  smaller than the  standard 40 bytes. The 
  5042. host  that is acting as the ASLIP  gateway rebuilds the outgoing packets 
  5043. to  legal IP packets before sending them out the network and abbreviates 
  5044. the  incoming packets from the network. The same server software handles 
  5045. both  SLIP and ASLIP. It only goes into  ASLIP mode once it has received 
  5046. an ASLIP packet from the PC, thus if only SLIP packets are sent, it will 
  5047. stay  in  regular  SLIP  mode.  I  will  post  more details on the ASLIP 
  5048. protocol later. 
  5049.  
  5050. Also  there have  been some  terminal server  vendors interested in this 
  5051. project.  It should not be  much work to turn  a terminal server into an 
  5052. ASLIP  or SLIP server and that would make it cheaper than using a VAX as 
  5053. the  gateway. Plus there would  not be as much  maintenance and downtime 
  5054. with a simple server box. 
  5055.  
  5056. The  software is available via anonymous FTP  from ucdavis.edu and is in 
  5057. the  directory  dist/slip/.  This  includes  all  software  to  run  the 
  5058. SLIP/ASLIP  server on  a 4.3  bsd system,  and the  modifications to CMU 
  5059. PC/IP software to implement ASLIP and the auto-login program, plus fix a 
  5060. couple bugs.  See the README file in this directory for a discription of
  5061. what the various tar files give you.
  5062.  
  5063. The  next thing we  want to add  to the system  is BOOTP so  that the PC 
  5064. software  does not have to be configured  for IP address, but rather get 
  5065. it from the server. 
  5066.  
  5067.                 Russell Hobby               
  5068.              Data Communications Manager 
  5069.      U. C. Davis                 
  5070.      Computing Services       BITNET:    RDHOBBY@UCDAVIS 
  5071.      Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
  5072.      (916) 752-0236           INTERNET:  rdhobby@ucdavis.edu
  5073.  
  5074. 27-Nov-87 04:28:50-EST,660;000000000000
  5075. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 27 Nov 87 04:28-EST
  5076. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA28207@EDDIE.MIT.EDU>; Fri, 27 Nov 87 03:29:04 EST
  5077. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA28200@EDDIE.MIT.EDU>; Fri, 27 Nov 87 03:28:50 EST
  5078. Posted-Date: 27 Nov 87  9:08 +0100
  5079. Received: by tor.nta.no (5.54/3.21)
  5080.     id AA08916; Fri, 27 Nov 87 09:08:28 +0100
  5081. Date: 27 Nov 87  9:08 +0100
  5082. From: Tore J Berg <tore%tor.re.nta.uninett@TOR.nta.no>
  5083. To: <packet-radio@EDDIE.MIT.EDU>
  5084. Message-Id: <270*tore@tor.re.nta.uninett>
  5085. Subject: Removal
  5086.  
  5087. Please remove me from the packet-radio list.
  5088.  
  5089. Tore/NDRE
  5090. 28-Nov-87 12:06:23-EST,1067;000000000000
  5091. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 28 Nov 87 12:06-EST
  5092. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA19275@EDDIE.MIT.EDU>; Sat, 28 Nov 87 11:17:03 EST
  5093. Received: from mc.lcs.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id <AA19252@EDDIE.MIT.EDU>; Sat, 28 Nov 87 11:16:34 EST
  5094. Resent-Message-Id: <8711281616.AA19252@EDDIE.MIT.EDU>
  5095. Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 28 Nov 87 11:19:01 EST
  5096. Date: Wednesday, 25 November 1987  14:39-MST
  5097. Message-Id: <KPETERSEN.12354237431.BABYL@SIMTEL20.ARPA>
  5098. Sender: ZAKAR@A.ISI.EDU
  5099. From: ZAKAR@A.ISI.EDU
  5100. To: info-hams@SIMTEL20.ARPA
  5101. Subject:   AX.25
  5102. Resent-From: KPETERSEN@SIMTEL20.ARPA
  5103. Resent-To: packet-radio%eddie.mit.edu@mc.lcs.mit.edu
  5104. Resent-Date: Sat 28 Nov 1987 09:13-MST
  5105.  
  5106. Folks,
  5107.      i'm just getting started in packet radio.  I understand that I can
  5108. get a copy of the AX.25 spec from ARRL, but does anyone know if there
  5109. is an electronic copy available over Arpanet?
  5110.  
  5111. Thanks,
  5112. Joe Zakar
  5113. Zakar at A.ISI.EDU
  5114. . 
  5115.  
  5116. 30-Nov-87 17:10:52-EST,2927;000000000000
  5117. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Nov 87 17:10-EST
  5118. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00658@EDDIE.MIT.EDU>; Mon, 30 Nov 87 15:52:37 EST
  5119. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA00652@EDDIE.MIT.EDU>; Mon, 30 Nov 87 15:52:19 EST
  5120. Received: by june.cs.washington.edu (5.52.1/6.11)
  5121.     id AA26067; Sun, 29 Nov 87 09:27:27 PST
  5122. Return-Path: <uunet!nuchat!sugar!splut!jay@EDDIE.MIT.EDU>
  5123. Message-Id: <8711291727.AA26067@june.cs.washington.edu>
  5124. Date: 28 Nov 87 21:55:19 GMT
  5125. From: uunet!nuchat!sugar!splut!jay@EDDIE.MIT.edu (Jay Maynard)
  5126. To: PACKET-RADIO@EDDIE.MIT.EDU
  5127. Subject: Re: trying to throw water on protocol flames
  5128. References: <8711231507.AA07190@decwrl.dec.com> <1574@faline.bellcore.com>
  5129.  
  5130. Phil answered most of my questions about IP address assignment versus
  5131. callsigns, except for one: how can we keep the FCC happy? (NOTE: I'm _NOT_
  5132. flaming, but asking for info.) How can they (or we, in our time-honored role
  5133. as self-policing spectrum users) know that 44.93.6.129 is K5ZC? (No, that's
  5134. _not_ my address; I haven't gotten an answer yet from E-mail to WB6JPR about
  5135. getting a Texas block assignment.)
  5136.  
  5137. In article <1574@faline.bellcore.com>, karn@faline.bellcore.com (Phil R. Karn) writes:
  5138. > Surely our network should be able to allow at least a small number of
  5139. > stations to move around without immediately forcing them to change
  5140. > addresses. What's needed is a hybrid between hierarchical and flat
  5141. > addressing that combines the efficiency of the former for the majority
  5142. > of stations that remain fixed with the flexibility of the latter for
  5143. > those relatively few stations in motion. I believe I have laid the
  5144. > foundation for this in the way I've implemented IP address routing in my
  5145. > TCP/IP package; we simply don't need the kind of address expansion Fred
  5146. > proposes.
  5147.  
  5148. Huh? Please expand on this; you allow a very nice hierarchical address
  5149. structure, but what happens when I take my Houston-area address with me when
  5150. I move to Dallas? or San Diego? The high order bits don't apply any more.
  5151.  
  5152. > One final, radical, thought: flat addressing isn't all that unthinkable
  5153. > anymore. Consider that there are only about 300,000 hams in the US (in
  5154. > very round numbers). Dynamic RAM is now cheap enough that I could store
  5155. > an IP routing table entry for each and every US ham in perhaps $125
  5156. > worth of chips, even without any clever storage compression tricks.  And
  5157. > that price is of course only going to go down.
  5158.  
  5159. Transferring that data file would be a real pain, though; talk about network
  5160. loading!
  5161.  
  5162. -- 
  5163. Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
  5164. uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay
  5165. Never ascribe to malice that which can adequately be explained by stupidity.
  5166. The opinions herein are shared by none of my cats, much less anyone else.
  5167.  
  5168.  
  5169. 30-Nov-87 21:52:31-EST,1567;000000000000
  5170. Received: from EDDIE.MIT.EDU by DEEP-THOUGHT.MIT.EDU via Chaosnet; 30 Nov 87 21:52-EST
  5171. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA08248@EDDIE.MIT.EDU>; Mon, 30 Nov 87 20:44:08 EST
  5172. Received: by EDDIE.MIT.EDU with sendmail-5.45/4.7 id <AA08210@EDDIE.MIT.EDU>; Mon, 30 Nov 87 20:42:19 EST
  5173. Message-Id: <8712010142.AA08210@EDDIE.MIT.EDU>
  5174. Received: from DHVRRZN1.BITNET by wiscvm.wisc.edu ; Mon, 30 Nov 87 17:31:13 CDT
  5175. Date: Mon, 30 Nov 87 19:32:21 MEZ
  5176. To: packet-radio@eddie.mit.EDU
  5177. From: MAMI%DHVRRZN1.BITNET@wiscvm.wisc.edu
  5178. Subject: searching TNC2C-Terminal prg for ATARI & MAC
  5179.  
  5180. hello ob's,
  5181.  
  5182. I am new with packet radio and I am looking for a special terminal
  5183. program to work with TNC2C with WA8DED firmware in host mode for
  5184. two kinds of computers, the MAC and the Atari ST. If any body has
  5185. an idea, where I can get that adopted programespecially for the MAC,
  5186. please let me know. I have full access to all BITNET servers and I
  5187. wonder if there is any availibilty for BITNETTER's getting prog's
  5188. and sources of such specified code??? I subscribe the packet-radio
  5189. bulletin since 3 month, but I don't remember anything in that connection.
  5190.  
  5191. Second kind of problems is the solution of TCP/IP for both of these
  5192. computers. Atari is well known to much hams here in Hannover but MAC
  5193. is not. Therefore system support for MAC with public domain software
  5194. with packet-radio application is closed to ZERO.
  5195.  
  5196. It would be wonderful to get some information on that 2 problems...
  5197. Thank you very much, 73, cul
  5198.  
  5199. Michael Hartje, DK5HH, (MAMI@DHVRRZN1)
  5200.