Date: Thu, 7 Apr 94 04:30:09 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #101 To: Ham-Digital Ham-Digital Digest Thu, 7 Apr 94 Volume 94 : Issue 101 Today's Topics: Baycom TCP/IP Software FCC Packet Message Forwarding MFJ 1270C TNC and Host Mode spread-spectrum links hooking libraries in CA.. Televideo 925 terminal setup X1-J and DRSI DPK-2 TNC's Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 6 Apr 94 20:19:27 GMT From: news-mail-gateway@ucsd.edu Subject: Baycom TCP/IP Software To: ham-digital@ucsd.edu >Is there a driver available for TCP/IP on the Baycom software and modem? There is a file AX25DRV.ZIP available which contains a driver and instructions. It should be on ucsd.edu somewhere in /hamradio/packet/tcpip and is also available on the TAPR fileserver. Send a message to file-request@tapr.org with the lines: get /pub/packet/ax25drv.zip and it will be send uuencoded. ------------------------------ Date: 7 Apr 1994 05:11:17 GMT From: ihnp4.ucsd.edu!swrinde!gatech!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch!chuckv@network.ucsd.edu Subject: FCC Packet Message Forwarding To: ham-digital@ucsd.edu Well it's final.... Here is the latest rule from the FCC..... Report No. DC-2582 ACTION IN DOCKET CASE April 4, 1994 COMMISSION AMENDS RULES CONCERNING MESSAGE FORWARDING SYSTEMS IN THE AMATEUR SERVICE (PR DOCKET NO. 93-85) The FCC has relaxed the amateur service rules to enable contemporary message forwarding systems to operate at hundreds of characters per second while retaining safeguards to prevent misuse. A message forwarding system is a group of amateur stations participating in a voluntary, cooperative, interactive arrangement where communications from the control operator of an originating station are transmitted to one or more destination stations via forwarding stations, which may or may not be automatically controlled. Currently, the control operator of each station is held individually accountable for each message retransmitted, resulting in unnecessary content review and delays. The American Relay League, Inc. (League) stated that the obligation of the control operator of the first forwarding station should be the establishment of the identity of the station originating the message. Only when this is not done should these control operators be held accountable for improper message content. Also, there are currently no central supervisory authority in an ad hoc amateur service digital network, making these unsupervised systems easy targets for misuse by uncooperative operators and non-licensees. Moreover, the Commission said that it could be difficult to establish after the fact that a particular VHF station originated a fleeting high speed digital transmission. For these reasons, the Commission said there must be on-going oversight of the system and the control operators of the first forwarding stations are in the best position to provide such oversight. Therefore, the Commission will hold accountable only the licensees of the station originating a message and the license of the first station forwarding a message in a high speed message forwarding system. The licensee of the first forwarding station must either authenticate the identify of the station from which it accepts communications on behalf of the system, or accept accountability for the content of the message. (over) -2- The Commission also clarified that the station that receives a communication directly from the originating station and introduces it into the message forwarding system is the first forwarding station. The League and the Colorado Council of Amateur Radio Clubs suggested that the Commission substitute the word "simultaneously" for "instantaneously" in the redefinition of a repeater. The Commission concurred and adopted this modification. The Commission believes that these rule changes will enable contemporary high speed message forwarding systems to operate as their designers intended, while retaining the minimum safeguards necessary to prevent misuse. Action by the Commission March 30, 1994, by Report and Order (FCC 94-76). Chairman Hundt, Commissioners Quello and Barrett. -FCC- News Media contact: Patricia A. Chew at (202) 632-5050. Private Radio Bureau contact: William T. Cross at (202) 632- 4964. -- |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | Chuck Vyverberg | Internet: chuckv@comtch.iea.com | | | Packet : WB7NNF@WB7NNF.#EWA.USA.NOAM | | | | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------ Date: 6 Apr 94 20:26:42 GMT From: news-mail-gateway@ucsd.edu Subject: MFJ 1270C TNC and Host Mode To: ham-digital@ucsd.edu >I've been looking through my TNC documentation, and the only reference I find >to host mode mentions that documentation is available on diskette, but no >command is given for putting the TNC into host mode. > >Can anyone help? There is a disk containing discriptions of the host mode and a primative program to use it available from TAPR. Also a file with documentation up to TAPR version 1.1.8a firmware, which has the pertinent commands (with much other valuable TNC information). Send a message to file-request@tapr.org with the following lines in the body of the message: get /pub/packet/tnc2host.zip get /pub/packet/tnc2doc.zip quit The files will be sent to you uuencoded. ------------------ Bob Nielsen, W6SWE Internet: w6swe@tapr.org Tucson, AZ AMPRnet: w6swe@w6swe.ampr.org [44.124.12.16] AX.25: w6swe@wb7tls.az.usa.na ------------------------------ Date: Wed, 6 Apr 1994 15:08:26 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.ans.net!paperboy.amoco.com!apctrc!msc.edu!mr.net!idss.nwa.com!csinc!chrise@network.ucsd.edu Subject: spread-spectrum links hooking libraries in CA.. To: ham-digital@ucsd.edu I remember reading about a project some of the guys on here did a while back to hook libraries in some part of California to the Internet using part 15 spread-spectrum equipment. Are those guys still around ? If so, I have a couple questions for you and would like to discuss that project... Could you email me ? Thanks. Chris -- Chris Elmquist, N0JCF voice: (612)631-7614 chrise@comtrol.com fax: (612)631-8117 ------------------------------ Date: Thu, 7 Apr 1994 02:48:33 GMT From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!acsu.buffalo.edu!jwelch@network.ucsd.edu Subject: Televideo 925 terminal setup To: ham-digital@ucsd.edu Anyone have the manual for a Televideo 925 terminal? I have purchased one second hand, and would appreciate any information about the two banks of DIP switches at the back of the terminal. One is labelled baud (but no explanation of what switches select which speed). The other is labelled function. I believe that there is also a third bank of switches inside the unit. Any help would be appreciated. Thanks, John Welch KA2VGV ------------------------------ Date: 7 Apr 94 06:09:08 GMT From: VNET.IBM.COM@uunet.uu.net Subject: X1-J and DRSI DPK-2 TNC's To: ham-digital@ucsd.edu I'm planning to install a X1-J rom in to a DRSI DPK-2. Is there anything I should look out for before doing the bank switching mod??? Oh and also is there a sourceon info on wiring a TNc w/ a 9600 bd modem to a Motorola Maxtor UHF radio. Thanks Stephen sharp IBM, Micro Electronics Div. Burlington, VT Internet ID: ssharp@vnet.ibm.com ------------------------------ Date: 6 Apr 1994 22:10:39 GMT From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@uunet.uu.net To: ham-digital@ucsd.edu References <1994Mar29.100554.3059@hemlock.cray.com>, <2nphhd$djt@hpbab.mentorg.com>, <2nqhsn$f9s@network.ucsd.edu>om Reply-To : Hank_Oredson@mentorg.com Subject : Re: [REPOST] The # in PBBS addresses.... In article <2nqhsn$f9s@network.ucsd.edu>, brian@nothing.ucsd.edu (Brian Kantor) writes: |> In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: |> >You are perhaps talking about the internet, which chose to ignore |> >the existing use of NA in one of it's connected networks? |> |> Oh jeez, Hank, stop making things up. The AMPR.ORG domain has never used |> the ham bbs hierarchical routing/addressing scheme to name hosts. We were not discussing host names. We were discussing email addresses. Please do not confuse a host name with an email address, this is one of the worst mistakes an email system designer might make. But since you brought up the topic, why would AMPR.ORG *not* choose some sort of rational subdomain naming convention for host names? Perhaps the fact that they didn't, and that they consistently confuse email addresses with host names is why it is impossible to move email from one tcp/ip system within .ampr.org to another without making use of those "other" (BBS network) email addresses? But now back to our scheduled discussion of email addresses. |> With some exceptions, the namespace of the AMPR.ORG domain consists |> solely of callsigns within the domain. Names are not routes, routes |> are not names, and mixing them up is one of the worst possible mistakes |> a network architect could make. Well gee Brian! Glad you least understand the basics! A name is not a route. A route is not a location. An address is none of the above. Etc. etc. So *WHY* do you persist in confusing them? Repeat after me "A host name is not an email address." |> That means that whilst you might see |> W0RLI.AMPR.ORG |> or |> BBS.W0RLI.AMPR.ORG |> you won't see |> W0RLI.#NNJ.NJ.USA.NOAM.AMPR.ORG |> or the like And why would I not see such things? Why would we not use subdomains in our email addresses? Why would we not put routing hints into our email addresses? Why would we not identify our email address by it's internet domain name. Why wait! Look at my signature! It has ".mentorg.com", which clearly is an internet domain name! But wait ... there is something missing - the subdomains. Why are they missing? Because a router with address "mentorg.com" will take care of translating the (missing) portion of my email address once email addressed to the "mentorg.com" domain arrives there. Where is "there"? Well, that depends on where your email to me started ... "there" might be NJ or OR or Bracknell or Singapore. At any one of these locations email destined for .mentorg.com is re-routed by adding the rest of the address. So the rest of the world does not need to know about .hanko.mentorg.com, nor about .hanko.moses.mentorg.com, nor about hanko.moses40.moses.mentorg.com We use ABBREVIATIONS and ALIASES for the actual addresses. What does this have to do with the ham radio digital network? In the ham radio digital network, we do not yet use aliases nor abbreviations. We specify the whole email address. (Note for Brian: this is NOT "source routing" since we do not specify a route, but specify an address). Look again in my signature. I show a ham radio digital network email address. There is *no* "host name" in that address. There are in fact two hosts that may handle email addressed to my address: RLIMB:W0RLI-2 and WLINN2:W0RLI-4. These are the host addresses within the AX.25 network. In the CLOVER network, that first host is named W0RLI. This is not confusing to anyone, because the W0RLI name is only known in the CLOVER network, and the RLIMB and WLINN2 names are only known in their respective AX.25 networks. If I had a tcp/ip system on air, it would have an ip address. Most folks have no trouble distinguishing between the email address and the host name. It is not a complicated thing. In fact it is very simple: email destined for email addresses of the form ".OR.USA.NOAM" may be sent to any of the hosts listed in the previous paragraph, and it will be properly delivered. Oh yes - email addresses of the form ".WA.USA.NOAM" may also be sent to these hosts as well. If you want email to reach me personally you may send it addressed per my signature, and to any of those same hosts. Brian, now that you have again told us "Don't do it that way" would you please oh please tell us "The right way to do it." ... Hank -- Hank Oredson @ Mentor Graphics Internet : hank_oredson@mentorg.com Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM ------------------------------ Date: 6 Apr 94 23:17:20 GMT From: dog.ee.lbl.gov!ihnp4.ucsd.edu!news.cerf.net!ccnet.com!ccnet.com!not-for-mail@ucbvax.berkeley.edu To: ham-digital@ucsd.edu References <2nph5e$djt@hpbab.mentorg.com>, , <2nuqbe$omj@hpbab.mentorg.com> Subject : Re: NTS traffic on packet Hank Oredson (hanko@wv.mentorg.com) wrote: : What would prevent duplicates or lost messages? : How would you accomplish this? Remember we don't have a "fixed : configuration" network. We don't have reliable paths. We do have multiple I don't understand. There are fixed routes in and out of any full service bbs. The HF routes may seasonally change and require manual assistence. What is going to happen if the BBS protocol is allowed to be the rule on the DASH digital amateur super highway. It is my understanding that the proposal for the 219 MHz 56kb DASH will require point to point auxiliary operation. Will the bbs protocol work in this new arena? : ways to get from point A to point B. We don't have a protocol that : addresses all the problems, and would *love* to have one. : Any suggestions would be most welcome. : I hope we will hear from the networking gurus on these topics. : So far, we have heard from a couple of the networking gurus. : Their message has been "You are doing it wrong." : I presume they will follow up with "And here is how to do it right." : ("just use tcp/ip" is not a reasonable answer. We don't use it.) Maybe the answer is to make the 219 MHz DASH a tcp/ip network and put the bbs mail traffic into for safe transport across the network. I would like to see some more discussion on the future implementation of this new network. Has anyone done any traffic analysis of bbs messages? Are the bulk of the messages two or three hops? With the increase in network speed will the message flow naturally increase? Will my bbs mail reading program be able to keep up with the vast number of bulletins that will be arriving? I realize that I will be reading at 1200 for quite some time ... maybe 9600 if the bbs operators will provide this service. Sorry Hank, I am not a network guru, just your average packet user. Bob : -- : Hank Oredson @ Mentor Graphics : Internet : hank_oredson@mentorg.com : Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM -- Bob Wilkins work bwilkins@cave.org Berkeley, California home rwilkins@ccnet.com 94701-0710 play n6fri@n6eeg.#nocal.ca.usa.noam ------------------------------ Date: 6 Apr 1994 17:09:02 GMT From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@uunet.uu.net To: ham-digital@ucsd.edu References , <2nph5e$djt@hpbab.mentorg.com>, g.c Reply-To : Hank_Oredson@mentorg.com Subject : Re: NTS traffic on packet In article , dts@world.std.com (Daniel T Senie) writes: |> In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: |> >In article , dts@world.std.com (Daniel T Senie) writes: |> >|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) writes: |> >|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote: |> > |> >|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to |> >|> my STM at the other end of the section got there 4 times. We have had |> >|> a rash of multiple NTS deliveries. |> > |> >This is a very serious problem. |> > |> >There are many possible causes, but they all come down to poor operating |> >practices by the sysops. If the sysops had things set up reasonably, |> >and made certain their systems were operating properly, then there would |> >be no (zero, zilch, none) duplicated bulletins. |> > |> >Personal messages and NTS traffic are handled differently. |> >Duplicates are allowed to occur, rather than lose an occasional message. |> >However, these duplicates should be rare: 1 in 1000 perhaps. |> |> This raises some alarm bells with me. Networks need to either send or not |> send messages. Protocols are designed to be able to be sure of such things. |> Could you imagine if something like an international money transfer were |> occasionally duplicated on the commercial networks? It sounds like the |> protocols involved (in nthis case, the handling methods) may need some |> review. We are not talking "banking networks" here, we are talking about a network rather similar to the internet. Duplicates occur. Such is life. Any suggestions you have would be most welcome ... |> Why is the software designed to allow even an occasional duplicate? Why |> is there otherwise the possibility of a lost message? What would prevent duplicates or lost messages? How would you accomplish this? Remember we don't have a "fixed configuration" network. We don't have reliable paths. We do have multiple ways to get from point A to point B. We don't have a protocol that addresses all the problems, and would *love* to have one. Any suggestions would be most welcome. I hope we will hear from the networking gurus on these topics. So far, we have heard from a couple of the networking gurus. Their message has been "You are doing it wrong." I presume they will follow up with "And here is how to do it right." ("just use tcp/ip" is not a reasonable answer. We don't use it.) ... ... Hank -- Hank Oredson @ Mentor Graphics Internet : hank_oredson@mentorg.com Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM ------------------------------ End of Ham-Digital Digest V94 #101 ****************************** ******************************