Regarding a few things mentioned
setup/encryption
- 802.11 encryption would not be necessary if you use a band not shared with Part 15 Users - 802.11 encryption technically does not obscure the fact that you are transmitting standard 802.11 Wireless Ethernet traffic - also, this debate can extend into HTTPS traffic over Amateur RF, except in an Emergency (transferring Health information for a hospital, for example, REQUIRES encryption in the US [HIPPA]) - even if HTTPS traffic is sent, packet inspection of the frames would reveal it is a HTTPS packet, its source and its destination - making the callsign the SSID is not the only method of complying with station identification rules; but it is the easiest - There are other methods of encrypting a WiFi signal other than a pre-shared key (many stations commented that they key must be posted or announced), user account authentication is another method
regulation
- regarding sending a music/video file or stream via 802.11 - the communication would be data, in the analog world, I would assume this would be similar to sending the sheet music via snail mail - regarding N6MEF's concern regarding 3rd party email communications, email is not an "automatically forwarded" technology; an amateur does not automatically receive that message through any technology governed by Part 97 (there are two exceptions I can imagine - if the amateur maintains his own email server at the receiving [client] end of the radio link or provides email as a service to non-amateurs) - I'm somewhat lost as to the concerns regarding inbound traffic, the problem only arises if the intent is to run infrastructure (i.e. services) over RF for non-amateur use, otherwise, the requests would initiate from an amateur station and would not be 3rd party - servers and devices on AMPR can be firewalled to only accept traffic from 44.0.0.0/8, in fact my DNS server (44.60.44.3) is configured to only resolve non AMPR IPs and domains for 44/8 traffic - if a non-amateur is reaching a 44/8, they MUST be using commodity Internet, if the services are on the gateway or on a device connected by wire or Part 15 device, that is not governed by Part 97 (Part 97 only governs Amateur RF) - I cannot find 97.109(e) - I'm not certain how 97.115 relates, except for 97.115(c) "(c) No station may transmit third party communications while being automatically controlled except a station transmitting a RTTY or data emission." Since it is a data emission, 3rd party communications can be transmitted - I'm not certain how 97.219 applies, given that email is not a message forwarding system for the 3rd party (email receipt must be initiated by the amateur, that communication is between the Amateur and their email server, not between the Amateur and the 3rd party)
This is a good thread, and I'm still reading through, I hope I have not missed anything thus far.
73,
Lynwood KB3VWG
Hi Lynwood:
I'll be more explicit.
Assume that I log into BBS A using amateur radio to get my messages. Assume BBS A is connected to BBS B using an amateur-radio frequency. And assume BBS B has an internet connection and is configured to serve as a packet-to-email gateway. If some 3rd party sends me an email, the gateway on BBS B needs to automatically forward the message to BBS A so I will see it when I log into BBS A. That forwarding is not allowed to be over amateur frequencies.
Therefore, anything communicating with 3rd parties needs its own Internet connection. In other words, every BBS that wants to receive email from non-hams needs its own Internet connection. This is basically what WL2K does at the RMS.
So, I use an ISP where available. Or I put up my own microwave links. But if I put up my own links, I don't want to use stuff restricted to amateur-only, because it only restricts what I can do with the network. Specifically, it doesn't solve the problem of giving me a path over which to forward the 3rd party traffic. So I use the commercial/consumer OTS stuff.
As I said, the FCC rules actually push me to NOT use amateur-type gear for any application that would be genuinely useful in the GHz+ range. And by genuinely useful, I mean I don't want to build something that will only allow me to talk to a few other hams (as in, literally, less than a half dozen) here in the south bay who might put up something in the GHz+ range. That's not useful. If I'm going to spend that time, effort, and money, it needs to be on something that is MORE useful that what's already out there commercially.
Gatewaying email to packet is such an application because I can send and receive from literally anywhere in our county -- including places where non-hams can't, such as anywhere that commercial cell service or commercial WISP services are not available. That has fantastic implications for public service events like bike races, etc., and for emergency comms. Our city and county emergency managers love it that we can set up anywhere and still handle their official ICS forms. But if that communications involves 3rd parties, then only the last leg (between me and the BBS) can be over amateur radio because that's not automatic. I initiate that when I log into the BBS. And that last leg is typically VHF/UHF with omni antennas and usually not clear line of site. That's not a place where GHz+ stuff can be used. The BBS-to-BBS connections are between fixed locations and could benefit from the higher bandwidths in the higher bands. But for the reasons already mentioned, it's best if those links do NOT use amateur gear. That's what sucks.
So, back to: why don't more people use amateur-only equipment on the higher bands for higher-bandwidth stuff? My answer is because I haven't come up with a genuinely useful application due to the restrictions of Part 97.
M
-----Original Message----- - regarding N6MEF's concern regarding 3rd party email communications, email is not an "automatically forwarded" technology; an amateur does not automatically receive that message through any technology governed by Part 97 (there are two exceptions I can imagine - if the amateur maintains his own email server at the receiving [client] end of the radio link or provides email as a service to non-amateurs) - I'm somewhat lost as to the concerns regarding inbound traffic, the problem only arises if the intent is to run infrastructure (i.e. services) over RF for non-amateur use, otherwise, the requests would initiate from an amateur station and would not be 3rd party - servers and devices on AMPR can be firewalled to only accept traffic from 44.0.0.0/8, in fact my DNS server (44.60.44.3) is configured to only resolve non AMPR IPs and domains for 44/8 traffic - if a non-amateur is reaching a 44/8, they MUST be using commodity Internet, if the services are on the gateway or on a device connected by wire or Part 15 device, that is not governed by Part 97 (Part 97 only governs Amateur RF) - I cannot find 97.109(e) - I'm not certain how 97.115 relates, except for 97.115(c) "(c) No station may transmit third party communications while being automatically controlled except a station transmitting a RTTY or data emission." Since it is a data emission, 3rd party communications can be transmitted - I'm not certain how 97.219 applies, given that email is not a message forwarding system for the 3rd party (email receipt must be initiated by the amateur, that communication is between the Amateur and their email server, not between the Amateur and the 3rd party)
This is a good thread, and I'm still reading through, I hope I have not missed anything thus far.
73,
Lynwood KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Michael,
Perhaps I'm missing your point regarding email, automatic control and Part 97 regarding data emissions; in addition, I wasn't clear that you were referencing BBS software instead of standard email or webmail. 97.115(c) permits automatic 3rd party communications via data or RTTY. The only instance where your idea would not be allowed is if the 3rd party picked up email from a server whose Internet path could only be reached via an Amateur RF link (e.g. a POP3 or IMAP server [email-for-pickup] located in an Amateur SATERN communications mobile). In this case, you're providing email service to non-amateurs over RF, which is not allowed anyway. SMTP, or transmission of email is automatic, and therefore allowed, if it is a non-amateur sending the email, care must be made that the first leg is not via Part 97 RF (e.g. a local LAN at an EOC connected to AMPR).
Your example of BBS B receiving the message on standard Internet, then sending that message automatically to BBS A via Amateur RF is allowed per 97.115(c). In order for a 3rd party communication to enter AMPR, in all occasions, must be at some gateway between the commodity Internet and AMPR, as the non-amateur should not have direct access to AMPR anyway.
I also noted that you refer to Consumer/Off-the-shelf equipment as non-amateur; that is not entirely the case, it somewhat implies that if one end of the communication is Part 97, it can link to Part 15 equipment; such would not be the case, unless it's first converted the data path to non-RF for the final leg (e.g. wired Ethernet).
- Lynwood KB3VWG
The videoconference appears to be a HTTPS website; but it's password-protected.
Also, I'm interested in how one connects to the PPTP service and what IP address would be received.
There have been some stations interested in VoIP as well (I would have to reference the archive); perhaps they'll contribute to the discussion. I'm very interested in inter-station calling and willing to setup a VoIP/e-fax server as well if there's interest.
-Lynwood KB3VWG
The videoconference appears to be a HTTPS website; but it's password-protected.
My apologies. I should have been more clear on that one. You can connect with any h323 or sip client. That https is only for administration.
Also, I'm interested in how one connects to the PPTP service and what IP address would be received.
In my setup, I have a block of addresses that I can assign to a session. I can set up a login if you are interested in testing.
There have been some stations interested in VoIP as well (I would have to reference the archive); perhaps they'll contribute to the discussion. I'm very interested in inter-station calling and willing to setup a VoIP/e-fax server as well if there's interest.
I am working on a VoIP solution now but my router is old and doesn't have great sip endpoint support.
-Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Lynwood,
Good discussion. Thanks for challenging this. I really hope I'm wrong. I'd hate to unnecessarily limit what we can do.
But I think you've made a few misinterpretations. To wit:
Perhaps I'm missing your point regarding email, automatic control and Part 97 regarding data emissions; in addition, I wasn't clear that you were referencing BBS software instead of standard email or webmail.
97.115(c) permits automatic 3rd party communications via data or RTTY.
Right, but believe it or not, 1200 baud AFSK packet is not "data". See the definitions section, 97.3(b)(2), where "data" is defined as ". emissions having designators with A, C, D, F, G, H, J or R as the first symbol; 1 as the second symbol; D as the third symbol; and emission J2D. Only a digital code of the type specifically authorized in this part may be transmitted."
Unless I'm mistaken, 1200 baud AFSK is emission designator F2D. ("F" for FM, "2" for AFSK, "D" for Data, telemetry, telecommand). That's not listed in the definition for "data." And, the definition for data is specifically exclusive . i.e. "only these things and nothing else".
So, back to 97.109(c): "No station may be automatically controlled while transmitting third party communications, except a station transmitting a RTTY or data emission." And, as clarified above, 1200 baud AFSK packet is not a "data" emission as defined in part 97.
Continuing with 97.109(c): "All messages that are retransmitted must originate at a station that is being locally or remotely controlled." If I log into my BBS, I'm locally controlling that communication. This is how WL2K works. But if BBS B is the email gateway and is retransmitting to BBS A automatically, then BBS B is certainly not being locally or remotely controlled at the time.
There's also this:
97.115(b): The third party may participate in stating the message where:
97.115(b)(1): The control operator is present at the control point is continuously monitoring and supervising the third party's participation; and ."
Certainly, there is no control operator present to monitor and supervise the 3rd party as they create the email that causes the automatic transmission over amateur frequencies.
Another killer is:
97.219(d) "For stations participating in a message forwarding system, the control operator of the first forwarding station must: ."
97.219(d)(1) "Authenticate the identity of the station from which it accepts communications on behalf of the system; or ."
97.291(d)(2) "Accept accountability for any violation of the rules in this part contained in messages it retransmits to the system."
The way I read that is that whoever is the trustee for the gateway must make sure that incoming messages which will be forwarded between BBSs over amateur frequencies are not violating any of the other rules, like which countries and which individuals we can exchange 3rd party communications with, message content, etc. And that's virtually impossible to do in any practical way. But if the gateway is the same machine that I log into, then as I log in, that communication is under my control and I'm responsible. Again, that's how WL2K works.
The only instance where your idea would not be allowed
I believe you're incorrect, see above. But continuing .
is if the 3rd party picked up email from a server whose Internet path could only be reached via an Amateur RF link (e.g. a POP3 or IMAP server [email-for-pickup] located in an Amateur SATERN communications mobile). In this case, you're providing email service to non-amateurs over RF, which is not allowed anyway.
Yes, that would be an obvious violation - a non-ham directly using a ham frequency.
SMTP, or transmission of email is automatic, and therefore allowed, if it is a non-amateur sending the email, care must be made that the first leg is not via Part 97 RF (e.g. a local LAN at an EOC connected to AMPR).
I think I've shown above that it is NOT allowed, even if the first leg is not part 97 RF. But if I'm mistaken, please show me where.
Your example of BBS B receiving the message on standard Internet, then sending that message automatically to BBS A via Amateur RF is allowed per 97.115(c).
Um, 97.115(c) relates to stations sending an ID. I think you mean 97.109(c) which I've already covered above.
In order for a 3rd party communication to enter AMPR, in all occasions, must be at some gateway between the commodity Internet and AMPR, as the non-amateur should not have direct access to AMPR anyway.
Yes, of course. But I think I've show above that automatic forwarding (at least using AFSK) is specifically NOT allowed.
I also noted that you refer to Consumer/Off-the-shelf equipment as non-amateur; that is not entirely the case, it somewhat implies that if one end of the communication is Part 97, it can link to Part 15 equipment; such would not be the case, unless it's first converted the data path to non-RF for the final leg (e.g. wired Ethernet).
No such implication was intended. I'm aware that many off-the-shelf products are modified to work on amateur frequencies. But, once modified, they are no longer "off-the-shelf" and would, of course, be governed by part 97.
Final note: I would love it if someone can show me where I'm wrong. Really!
Michael
N6MEF
Jeez, the mail list eliminated the indents.
Here's another version with manually added ">" and "[N6MEF]"
From: Michael E. Fox - N6MEF [mailto:n6mef@mefox.org] Sent: Tuesday, July 09, 2013 4:59 PM To: 'AMPRNet working group' Subject: RE: [44net] hardware vs. software
Lynwood,
[N6MEF] Good discussion. Thanks for challenging this. I really hope I'm wrong. I'd hate to unnecessarily limit what we can do.
But I think you've made a few misinterpretations. To wit:
Perhaps I'm missing your point regarding email, automatic control and Part
97 regarding data emissions; in addition, I wasn't >clear that you were referencing BBS software instead of standard email or webmail.
97.115(c) permits automatic 3rd party communications via data or RTTY.
[N6MEF] Right, but believe it or not, 1200 baud AFSK packet is not "data". See the definitions section, 97.3(b)(2), where "data" is defined as ". emissions having designators with A, C, D, F, G, H, J or R as the first symbol; 1 as the second symbol; D as the third symbol; and emission J2D. Only a digital code of the type specifically authorized in this part may be transmitted."
[N6MEF] Unless I'm mistaken, 1200 baud AFSK is emission designator F2D. ("F" for FM, "2" for AFSK, "D" for Data, telemetry, telecommand). That's not listed in the definition for "data." And, the definition for data is specifically exclusive . i.e. "only these things and nothing else".
[N6MEF] So, back to 97.109(c): "No station may be automatically controlled while transmitting third party communications, except a station transmitting a RTTY or data emission." And, as clarified above, 1200 baud AFSK packet is not a "data" emission as defined in part 97.
[N6MEF] Continuing with 97.109(c): "All messages that are retransmitted must originate at a station that is being locally or remotely controlled." If I log into my BBS, I'm locally controlling that communication. This is how WL2K works. But if BBS B is the email gateway and is retransmitting to BBS A automatically, then BBS B is certainly not being locally or remotely controlled at the time.
[N6MEF] There's also this:
97.115(b): The third party may participate in stating the message where:
97.115(b)(1): The control operator is present at the control point is continuously monitoring and supervising the third party's participation; and ."
[N6MEF] Certainly, there is no control operator present to monitor and supervise the 3rd party as they create the email that causes the automatic transmission over amateur frequencies.
[N6MEF] Another killer is:
97.219(d) "For stations participating in a message forwarding system, the control operator of the first forwarding station must: ."
97.219(d)(1) "Authenticate the identity of the station from which it accepts communications on behalf of the system; or ."
97.291(d)(2) "Accept accountability for any violation of the rules in this part contained in messages it retransmits to the system."
[N6MEF] The way I read that is that whoever is the trustee for the gateway must make sure that incoming messages which will be forwarded between BBSs over amateur frequencies are not violating any of the other rules, like which countries and which individuals we can exchange 3rd party communications with, message content, etc. And that's virtually impossible to do in any practical way. But if the gateway is the same machine that I log into, then as I log in, that communication is under my control and I'm responsible. Again, that's how WL2K works.
The only instance where your idea would not be allowed
[N6MEF] I believe you're incorrect, see above. But continuing .
is if the 3rd party picked up email from a server whose Internet path could
only be reached via an Amateur RF link (e.g. a POP3 >or IMAP server [email-for-pickup] located in an Amateur SATERN communications mobile). In this case, you're providing email >service to non-amateurs over RF, which is not allowed anyway.
[N6MEF] Yes, that would be an obvious violation - a non-ham directly using a ham frequency.
SMTP, or transmission of email is automatic, and therefore allowed, if it
is a non-amateur sending the email, care must be made >that the first leg is not via Part 97 RF (e.g. a local LAN at an EOC connected to AMPR).
[N6MEF] I think I've shown above that it is NOT allowed, even if the first leg is not part 97 RF. But if I'm mistaken, please show me where.
Your example of BBS B receiving the message on standard Internet, then
sending that message automatically to BBS A via >Amateur RF is allowed per 97.115(c).
[N6MEF] Um, 97.115(c) relates to stations sending an ID. I think you mean 97.109(c) which I've already covered above.
In order for a 3rd party communication to enter AMPR, in all occasions,
must be at some gateway between the commodity >Internet and AMPR, as the non-amateur should not have direct access to AMPR anyway.
[N6MEF] Yes, of course. But I think I've show above that automatic forwarding (at least using AFSK) is specifically NOT allowed.
I also noted that you refer to Consumer/Off-the-shelf equipment as
non-amateur; that is not entirely the case, it somewhat >implies that if one end of the communication is Part 97, it can link to Part 15 equipment; such would not be the case, unless it's >first converted the data path to non-RF for the final leg (e.g. wired Ethernet).
[N6MEF] No such implication was intended. I'm aware that many off-the-shelf products are modified to work on amateur frequencies. But, once modified, they are no longer "off-the-shelf" and would, of course, be governed by part 97.
[N6MEF] Final note: I would love it if someone can show me where I'm wrong. Really!
Michael
N6MEF
-
Jesse Hindmarsh -
lleachii＠aol.com -
Michael E. Fox - N6MEF