home *** CD-ROM | disk | FTP | other *** search
- From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sun Feb 3 18:01:39 1991 remote from tosspot
- Received: by tosspot (1.63/waf)
- via UUCP; Sun, 03 Feb 91 19:32:04 EST
- for lee
- Received: from somewhere by elf.wang.com id aa15380; Sun, 3 Feb 91 18:01:38 GMT
- Received: from ucsd.edu by uunet.UU.NET (5.61/1.14) with SMTP
- id AA05451; Sun, 3 Feb 91 12:31:23 -0500
- Received: by ucsd.edu; id AA04587
- sendmail 5.64/UCSD-2.1-sun
- Sun, 3 Feb 91 04:30:18 -0800 for hpbbrd!db0sao!dg4scv
- Received: by ucsd.edu; id AA04568
- sendmail 5.64/UCSD-2.1-sun
- Sun, 3 Feb 91 04:30:09 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
- Message-Id: <9102031230.AA04568@ucsd.edu>
- Date: Sun, 3 Feb 91 04:30:06 PST
- From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
- Reply-To: Packet-Radio@ucsd.edu
- Subject: Packet-Radio Digest V91 #33
- To: packet-radio@ucsd.edu
-
-
- Packet-Radio Digest Sun, 3 Feb 91 Volume 91 : Issue 33
-
- Today's Topics:
- HELP with compiling Xenix SysV NET.
- PACKET->Internet Gateway
- recommended NOS version?
- Shareware on Packet
-
- Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
- Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
- Problems you can't solve otherwise to brian@ucsd.edu.
-
- Archives of past issues of the Packet-Radio Digest are available
- (by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".
-
- 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: 3 Feb 91 01:44:31 GMT
- From: munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@uunet.uu.net (Carl Makin)
- Subject: HELP with compiling Xenix SysV NET.
- To: packet-radio@ucsd.edu
-
- Hi,
- I got a copy of the System V version of Net from TOMCAT for the house
- Xenix system here and am having a REAL problem compiling it. The code seems
- to compile OK but before I actually get to compiling it the MAKE program
- falls over screaming "out of memory". :-(
-
- Now I'm reasonably new to Xenix/Unix and C but as far as I can see the
- only solutions would be either to compile it manually (urk) or split the
- makefile.
-
- Has anyone else had this sort of problem?
-
- The machine I'm trying to compile it on is a 12Mhz 80286 running SCO Xenix
- 2.2.3 in 2.5Mb of RAM and 105Mb of Hard disk.
-
- (Hopefully in a couple of weeks we can borrow 8Mb of RAM for a couple of days
- but I'm not sure that will help. :-( )
-
- Carl.
-
- ------------------------------
-
- Date: 2 Feb 91 20:43:50 GMT
- From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun!jbloom@tut.cis.ohio-state.edu (Jon Bloom)
- Subject: PACKET->Internet Gateway
- To: packet-radio@ucsd.edu
-
- In article <253@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes:
- >
- > I have heard numerous times that because the remote station would be
- > controlling the transmitter and he is (possibly) a non-ham that this
- > would be illegal. Now lets look at this from a practical technical
- > aspect.
- >
- > If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M
- > and initiate a contact on 10M. This is not considered illegal although
- > the TECH is initiating the contact. I have heard that this is OK under
- > the rules covering 3rd Party traffic cause the TECH isn't the control
- > operator of the 10M station. Well, I'm sorry, but that doesn't wash
- > either. Cause then all the 10M contacts with G-land AND DL-land etc.
- > are illegal cause we don;t have 3rd party agreements with them. The
- > fact of the matter is that the TECH on 2M never has control of the
- > signal generated on 10M and that is why the FCC allows it. I think
-
- The reason this doesn't fall under the normal third-party rules is that
- the FCC has made explicit exceptions in the case of repeaters. While
- third-party traffic normally requires a control operator to be
- present at the control point (see 97.109), automatic control of a
- repeater is explicitly allowed [see 97.205(d)]. In the case of the
- cross-band repeater with an output on 10m, the Technician cannot be
- the control operator. Fortunately, since a repeater is allowed to
- be under automatic control, no control operator is needed. But if
- the originating signal is not coming from an amateur station, as would
- be the case with Internet-originated data, the station is not, by
- definition, a repeater [see 97.3(a)(34)]. So the analogy between cross-
- band repeaters and an Internet gateway is false.
-
- > the time has come to look at possible INTERNET<->AMPR gateways the same
- > way. If it takes letters to the FCC to convince them then so be it.
- > If I put up such a gateway, I am controling the emissions of the transmitter
- > not the guy in Odessa, TX who sent a message to one of the hams on the
- > local LAN.
-
- But you are *not* controlling the content of the messages being transmitted
- by your station. No ham is controlling that, and therein lies the problem.
-
- > As long as all other rules are abided by, I can't see where there is any
- > kind of legal problem. I don't see a lot of difference between this and
- > NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is
- > placed into the amateur system at one point by a ham. Basicly the same
- > should apply to gateways. I would be considered the ham putting the traffic
- > into the amateur system.
- > The potential gain would be great. Hams would be able to exchange ideas
- > and colaborate with hams and non-hams alike in their technological projects.
-
- I completely agree with your last statement. But there *is* a legal
- difference between the gateway and the NTS example. See below.
-
- [...Internet legalities deleted]
-
- > So, would someone out there care to show me the error of my ways?? :-)
- > I'm not interested in "Well, it you just can't do it, so there."
- > I want concrete evidence that shows that the arguments that apply to one
- > type of technology (cross-band repeaters) can't be applied to a new
- > technology.
-
- At the risk of (once again) being accused of being a technology-bashing,
- Luddite, ARRL old fart, let me try to (once again) explain how it is that
- the existing rules unfortunately prohibit unattended Internet->AMPR
- gateways.
-
- 97.109(e) allows packet stations operating above 50 MHz to pass third-
- party traffic under automatic control, but "The retransmitted messages
- must originate at a station that is being locally or remotely controlled."
- Even worse, messages originated by non-hams (where the notion of a control
- operator can't possibly be stretched to cover the originator) surely come
- under the requirements of 97.115(b) which states in part:
-
- (b) The third party may participate in stating the message where:
- (1) The control operator is present at the control point and is
- continuously *monitoring* and supervising the third party's
- participation. [Emphasis mine.]
-
- This means that, under the current rules, you have to monitor (read)
- the data being sent by the Internet participant. A bit difficult in
- an IP gateway!
-
- Once again... cross-band repeaters are repeaters and fall under the
- repeater rules. An Internet gateway is *not* a repeater and does
- *not* fall under these rules. The reason the repeater rules were
- created in the first place was to provide relief from the third-
- party rules when only relay of *amateur* signals was involved. Trying
- to interpret these rules in some way that would allow automatic relay
- of nonamateur signals violates both the spirit and letter of the repeater
- rules. Sorry.
-
- --
- Jon Bloom, KE3Z | American Radio Relay League
- Internet: jbloom@uhasun.hartford.edu |
- Snail: 225 Main St., Newington, CT 06111 | "I have no opinions."
-
- ------------------------------
-
- Date: 2 Feb 91 21:17:02 GMT
- From: modcomp!dan@uunet.uu.net (Dan Grostick)
- Subject: recommended NOS version?
- To: packet-radio@ucsd.edu
-
- Can anyone recommend their favorite NOS version and where to get
- it from. I have access to uunet but not directly to internet -
- except via a ftp-request mechanism that requires internet address
- and file names.
-
- Thanks
-
- -Dan
-
- N4IXP
-
- ------------------------------
-
- Date: 2 Feb 91 17:10:00 GMT
- From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!ke4zv!gary@tut.cis.ohio-state.edu (Gary Coffman)
- Subject: Shareware on Packet
- To: packet-radio@ucsd.edu
-
- In article <1991Jan31.044034.21294@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
- >A question was posed to me by an amateur who is interested in getting
- >into packet. It seems he has a large collection of shareware on his
- >land-line BBS and he was wondering if he could legally set up his
- >BBS on packet and allow shareware downloads.
- >
- >I know about the avoiding business in amateur radio, but does
- >shareware count?
-
- Shareware authors ask for and expect money for their product just like
- any other business. They're just freeloading their marketing dept off
- on to the public access systems. While shareware is probably the most
- often pirated software, it's still a commercial product. Therefore it
- would certainly be illegal to distribute it over amateur radio. Think
- of shareware as digital pizzas. :-)
-
- On the other hand, true freeware and public domain software are perfectly
- ok to send over amateur radio.
-
- Gary KE4ZV
-
- ------------------------------
-
- End of Packet-Radio Digest
- ******************************
-