home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 1 / HamRadio.cdr / misc / pkthints / pd91031.txt < prev    next >
Internet Message Format  |  1991-02-01  |  14KB

  1. From wang!elf.wang.com!ucsd.edu!packet-radio-relay Fri Feb  1 15:29:32 1991 remote from tosspot
  2. Received: by tosspot (1.63/waf)
  3.     via UUCP; Sat, 02 Feb 91 12:00:59 EST
  4.     for lee
  5. Received: from somewhere by elf.wang.com id aa08178; Fri, 1 Feb 91 15:29:30 GMT
  6. Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP 
  7.     id AA28207; Fri, 1 Feb 91 08:58:40 -0500
  8. Received: by ucsd.edu; id AA05080
  9.     sendmail 5.64/UCSD-2.1-sun
  10.     Fri, 1 Feb 91 04:30:21 -0800 for hpbbrd!db0sao!dg4scv
  11. Received: by ucsd.edu; id AA05066
  12.     sendmail 5.64/UCSD-2.1-sun
  13.     Fri, 1 Feb 91 04:30:15 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
  14. Message-Id: <9102011230.AA05066@ucsd.edu>
  15. Date: Fri,  1 Feb 91 04:30:11 PST
  16. From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
  17. Reply-To: Packet-Radio@ucsd.edu
  18. Subject: Packet-Radio Digest V91 #31
  19. To: packet-radio@ucsd.edu
  20.  
  21.  
  22. Packet-Radio Digest         Fri,  1 Feb 91       Volume 91 : Issue  31
  23.  
  24. Today's Topics:
  25.                   Amprnet services listing (2 msgs)
  26.                    FREE Kantronics KPC-II Firmware.
  27.                           Help! What is it?
  28.                    ka9q NOS on an AT&T 3b1 unix-pc
  29.                         Omni vs beam antennas.
  30.                        PACKET->Internet Gateway
  31.                          Shareware on Packet
  32.  
  33. Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
  34. Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
  35. Problems you can't solve otherwise to brian@ucsd.edu.
  36.  
  37. Archives of past issues of the Packet-Radio Digest are available 
  38. (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
  39.  
  40. We trust that readers are intelligent enough to realize that all text
  41. herein consists of personal comments and does not represent the official
  42. policies or positions of any party.  Your mileage may vary.  So there.
  43. ----------------------------------------------------------------------
  44.  
  45. Date: Thu, 31 Jan 91 09:45:41 -0500
  46. From: rossjr%gtec3.dnet@gte.com (Charlie Ross, Jr.)
  47. Subject: Amprnet services listing
  48. To: "maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@uunet.uu.net"@gte.com
  49.  
  50.   > In the last issue of QEX magazine, the "Gateway" had a listing
  51.   > of finger and mail services for TCP/IP.  A question popped into my
  52.   > head as why such a list was given in a national magazine.
  53.   > 
  54.   > Since we do not have a nationwide TCP/IP network in the USA, is
  55.   > connectivity to these services a problem or is it
  56.   > possible for ANY TCP/IP'er to use these services.
  57.  
  58. I was the person who compiled the list.  It was originally published in two
  59. regional newsletters, "The Wireless Bitstream" (newsletter of the Boston
  60. Computer Society A/R SIG) and "The New England TCPer" (newsletter of the
  61. New England TCP Association.  I didn't hear about it appearing in QEX/Gateway
  62. until people received their copies and started mentioning it.
  63.  
  64. I'm currently unclear as to why it was published in a national newsletter.
  65. A copy is "in the mail" to me and I want to see it before pursuing it further
  66. with Stan Horzepa (Gateway's editor).
  67.  
  68. Yes, indeed--connectivity would be a "problem" unless you're linked into 
  69. the New England subnet.  I do feel that similar listings would be useful
  70. for each regional net, particularly for the sake of newcomers in each area.
  71. To that extent, perhaps it was published as an example--I don't know, I'll have
  72. to see what wrap-around Stan wrote for it.
  73.  
  74. --Charlie Ross, NC1N
  75. rossjr@gtec3.gte.com
  76. nc1n@nc1n.ampr.org
  77. NC1N @ WA1PHY.MA
  78.  
  79. ------------------------------
  80.  
  81. Date: 31 Jan 91 16:04:47 GMT
  82. From: att!cbnewsj!kb2glo@ucbvax.Berkeley.EDU  (thomas.kenny)
  83. Subject: Amprnet services listing
  84. To: packet-radio@ucsd.edu
  85.  
  86. In article <9101311445.AA06449@bunny.gte.com> rossjr%gtec3.dnet@GTE.COM (Charlie Ross, Jr.) writes:
  87. >  > In the last issue of QEX magazine, the "Gateway" had a listing
  88. >  > of finger and mail services for TCP/IP.  A question popped into my
  89. >  > head as why such a list was given in a national magazine.
  90. >I was the person who compiled the list.  It was originally published in two
  91. >regional newsletters, "The Wireless Bitstream" (newsletter of the Boston
  92. >Computer Society A/R SIG) and "The New England TCPer" (newsletter of the
  93. >New England TCP Association.  I didn't hear about it appearing in QEX/Gateway
  94. >until people received their copies and started mentioning it.
  95. >
  96. >I'm currently unclear as to why it was published in a national newsletter.
  97. >A copy is "in the mail" to me and I want to see it before pursuing it further
  98. >with Stan Horzepa (Gateway's editor).
  99.  
  100. ------------------------------
  101.  
  102. Date: 30 Jan 91 15:59:17 GMT
  103. From: swrinde!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!felix!alonso%felix.UUCP@ucsd.edu  (Oscar S. Alonso)
  104. Subject: FREE Kantronics KPC-II Firmware.
  105. To: packet-radio@ucsd.edu
  106.  
  107. Free firmware to the first person to send me email with there mailing
  108. address can obtain Kantronics KPC II packet communcator firmware revision 2.82.
  109.  
  110. I just upgraded to version 3.00.
  111.  
  112. Oscar S. Alonso
  113. uunet!ccicpg!felix!alonso
  114.  
  115. ------------------------------
  116.  
  117. Date: 31 Jan 91 11:18:40 GMT
  118. From: public!techie@decwrl.dec.com  (Bob Vaughan techie@btr.com)
  119. Subject: Help! What is it?
  120. To: packet-radio@ucsd.edu
  121.  
  122. In article <andreap.665077581@s.ms.uky.edu> andreap@ms.uky.edu (Peach) writes:
  123. >I have discovered a packet radio signal, locally, on 412.875 MHz.
  124. >While it is not in the ham band, it sounds very similar to 1200
  125. >baud packet.
  126.  
  127. This is probably US Army or USAF packet. 412 Mhz is a federal government
  128. frequency. My Hollins book lists the assignment as US Army, and USAF.
  129.  
  130.  
  131.  
  132. -- 
  133. Welcome My Son, Welcome To The Machine
  134. Bob Vaughan     - techie@well.sf.ca.us {apple,pacbell,hplabs,ucbvax}!well!techie
  135. 1-415-856-8025  - techie@btr.com       {fernwood,decwrl,mips,sgi}!btr!techie
  136. I am me, I am only me, and no one else is me. What could be simpler?
  137.  
  138. ------------------------------
  139.  
  140. Date: 31 Jan 91 03:17:18 GMT
  141. From: sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!msuinfo!sharkey!fmsrl7!hpftc!slimer!mco@ucsd.edu  (Mark C. Otto)
  142. Subject: ka9q NOS on an AT&T 3b1 unix-pc
  143. To: packet-radio@ucsd.edu
  144.  
  145. In article <3812@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes:
  146. >In article <1991Jan25.040010.11231@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes:
  147. >>would anyone who has ka9q NOS (or hyprids thereof) running under unix (sysV)
  148. >and me (if available for the 3b1, of course), pretty please!
  149. >Lucio de Re.
  150.  
  151. Me too, please!
  152.  
  153.  
  154. Mark Otto
  155.  
  156.  
  157.  
  158. -- 
  159. Mark C. Otto   EMail: mco@slimer, {teemc | hpftc}!slimer!mco
  160. Voice: 1-313-441-4264    USnail: 5133 Heather #208, Dearborn, MI. 48126
  161. Quote: "Yeah. Right. Kermit my a*s." - Mark C. Otto, '90
  162.  
  163. ------------------------------
  164.  
  165. Date: 30 Jan 91 11:12:52 GMT
  166. From: mintaka!ogicse!emory!wa4mei!ke4zv!gary@bloom-beacon.mit.edu  (Gary Coffman)
  167. Subject: Omni vs beam antennas.
  168. To: packet-radio@ucsd.edu
  169.  
  170. In article <28.Jan.91.17:05:26.GMT.#9023@UK.AC.NWL.IA> PJML@ibma.nerc-wallingford.ac.uk ("Pete Lucas, NCS-TLC, Holbrook House, Swindon") writes:
  171. >Hi. I recently had a 'discussion' with another packeteer as to whether
  172. >it was better to use omni-directional antennas or beams for accessing
  173. >BBS's and the like. He argued that using beams results in less mutual
  174. >interference; i argued that the CSMA model ceases to work if there are
  175. >nodes that cannot hear each other yet can interfere with each others
  176. >working.
  177. >This discussion got quite 'inflamed';  What say you good people? Theres
  178. >an evening of free drinks (for me!) in the balance here.
  179. >
  180. >           Pete Lucas PJML@UK.AC.NWL.IA  G6WBJ@GB7SDN.GBR.EU
  181.  
  182. The correct answer is that it depends on the RF topology of your particular
  183. network. If we assume that the bbs or node is forced to use omni antennas,
  184. a necessity in most cases, then the use of a beam by a user station may
  185. reduce total thruput on the channel. The reason being that your signals
  186. arriving at the bbs will be interfered with by other packeteers' signals
  187. because the beam prevents either you or the other packeteer from hearing
  188. each other and performing the normal channel hold off function. If,
  189. however, all user stations are using beams, and the beams are good enough
  190. that the capture effect is significantly enhanced at the bbs so that the
  191. desired station's signal overrides all other users on the channel while
  192. at the same time being so weak at the other users' sites as to not bother
  193. their transmissions, then the beams create a form of spatial reuse similar
  194. to cellular and thruput is enhanced. However, with the generally random
  195. physical distribution of stations in the network that wish to communicate 
  196. with each other at any given time, the probability of this case occurring 
  197. is relatively small. Therefore, use of beams generally worsens channel
  198. collisions even though there are special cases where the beams can
  199. help.
  200.  
  201. Gary KE4ZV
  202.  
  203. ------------------------------
  204.  
  205. Date: 31 Jan 91 18:51:09 GMT
  206. From: swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!platypus!bill@ucsd.edu  (Bill Gunshannon)
  207. Subject: PACKET->Internet Gateway
  208. To: packet-radio@ucsd.edu
  209.  
  210. In article <4610001@hp-vcd.HP.COM>, carlp@hp-vcd.HP.COM (Carl Peterson) writes:
  211. > If you set up a gateway/router you would have to take a great
  212. > deal of care about what addresses could access which services.
  213. > Obviously, you could not allow a non 44. address to initiate
  214. > a connection to a 44 address.  
  215.  
  216. OK. Enough is enough.  It is time to bring this one out in the open
  217. and resolve it once and for all.
  218.  
  219. I have heard numerous times that because the remote station would be 
  220. controlling the transmitter and he is (possibly) a non-ham that this
  221. would be illegal.  Now lets look at this from a practical technical
  222. aspect.  
  223.  
  224. If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
  225. and initiate a contact on 10M.  This is not considered illegal although
  226. the TECH is initiating the contact.  I have heard that this is OK under
  227. the rules covering 3rd Party traffic cause the TECH isn't the control
  228. operator of the 10M station.  Well, I'm sorry, but that doesn't wash 
  229. either.  Cause then all the 10M contacts with G-land AND DL-land etc.
  230. are illegal cause we don;t have 3rd party agreements with them.  The 
  231. fact of the matter is that the TECH on 2M never has control of the
  232. signal generated on 10M and that is why the FCC allows it.  I think 
  233. the time has come to look at possible INTERNET<->AMPR gateways the same
  234. way.  If it takes letters to the FCC to convince them then so be it.
  235. If I put up such a gateway, I am controling the emissions of the transmitter
  236. not the guy in Odessa, TX who sent a message to one of the hams on the
  237. local LAN.
  238.  
  239. As long as all other rules are abided by, I can't see where there is any
  240. kind of legal problem.  I don't see a lot of difference between this and 
  241. NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
  242. placed into the amateur system at one point by a ham.  Basicly the same
  243. should apply to gateways.  I would be considered the ham putting the traffic
  244. into the amateur system.  
  245. The potential gain would be great.  Hams would be able to exchange ideas
  246. and colaborate with hams and non-hams alike in their technological projects.
  247.  
  248. And just to add a little fuel to the fire, all this talk of setting up
  249. wormholes accross the INTERNET is very interesting.  And according to
  250. The Acceptable Use Policy for PrepNET (other NSFNET members will probably
  251. find the same is true for them) these wormholes would (IMHO) be in 
  252. violation.
  253.  
  254. So, would someone out there care to show me the error of my ways??  :-)
  255. I'm not interested in "Well, it you just can't do it, so there."
  256. I want concrete evidence that shows that the arguments that apply to one
  257. type of technology (cross-band repeaters) can't be applied to a new
  258. technology.
  259.  
  260. bill   KB3YV
  261.  
  262.  
  263. -- 
  264.  
  265.      Bill Gunshannon          |        If this statement wasn't here,
  266.      bill@platypus.uofs.edu   |  This space would be left intentionally blank
  267.  
  268. ------------------------------
  269.  
  270. Date: 31 Jan 91 15:12:59 GMT
  271. From: julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!know!tegra!vail@apple.com  (Johnathan Vail)
  272. Subject: Shareware on Packet
  273. To: packet-radio@ucsd.edu
  274.  
  275. In article <1991Jan31.044034.21294@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
  276.  
  277.    A question was posed to me by an amateur who is interested in getting
  278.    into packet.  It seems he has a large collection of shareware on his
  279.    land-line BBS and he was wondering if he could legally set up his
  280.    BBS on packet and allow shareware downloads.  
  281.  
  282. I would argue that it is not legal.  Shareware (begware, crippleware,
  283. etc) is software that depends on being distributed in order to
  284. generate revenue for its creator.  Using amateur radio as a means of
  285. distribution is conducting business on amateur radio.
  286.  
  287.    I know about the avoiding business in amateur radio, but does 
  288.    shareware count?
  289.  
  290. Of course, since most hams don't bother to pay for their shareware
  291. maybe it isn't business after all...
  292.  
  293.  
  294. I personally don't like shareware and use very little.  It is the
  295. primary means of propogating viruses.  I much prefer public domain
  296. sources, freeware and copyleft software.  In addition to being safer
  297. and more useful, distributing source code that people can improve upon
  298. and modify is more apropos to amateur radio.
  299.  
  300.  
  301. 73s and happy hacking, jv
  302.  
  303. "....say you're thinking about a plate of shrimp...
  304. ..and someone says to you `plate,' or `shrimp'......"
  305.  _____
  306. |     | Johnathan Vail | n1dxg@tegra.com
  307. |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet)
  308.  -----  jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail
  309.  
  310. ------------------------------
  311.  
  312. Date: (null)
  313. From: (null)
  314. -- 
  315. Tom Kenny, KB2GLO
  316. uucp:   att!lzatt!tek          internet: tek%lzlup@att.att.com
  317. packet: kb2glo@nn2z.nj.usa.na  ampr: kb2glo@nn2z.ampr.org [44.64.0.10]
  318.  
  319. ------------------------------
  320.  
  321. End of Packet-Radio Digest
  322. ******************************
  323.