You are here

What protocols allowed on AREDN / Mesh? HTTPS, SSH, etc?

17 posts / 0 new
Last post
k0tan's picture
What protocols allowed on AREDN / Mesh? HTTPS, SSH, etc?

While planning a local mesh, I planned having files shared from an RPi3, and some applications, such as a web server, chat server, and a relay module.

How does the Ham community interpret FCC regulations regarding secure protocols over Mesh?  I'm used to using self-signed certs, and standard user/group security on Linux and other systems.

Thanks, Charlie KØTAN

I'm about to call it a night
I'm about to call it a night so this will be short, I can go more in depth later.

My personal interpretation is that they are generally not permissible, especially when an alternative exists that isn't encrypted (http vs https, telnet Vs ssh, ftp vs ftps, etc) then the adding of encryption would (to me) exist solely to "obscure the meaning"  of the  transmissions.

Self signed certs dont directly expose the private key needed for decryption, and even if you have the intial private key many protocols renegotiate the encryption key shortly after the initial connection is established meaning no one knows the real decryption key for the cycle unless you specifically log the negotiated key and publish it.

If it's argued that it's an unspecified digitial code and the protocol is fully published (e.g. Http with TLS private key blah) as the reason to allow it then we hit the question "why bother doing it that way and adding extra bureaucracy when an HTTP session would do it anyways"

Personaly I avoid any encrypted traffic over the mesh. I've yet to find anything that couldn't conceivably be done without encryption. Internet has worked for decades with encryptionnonly used to secure the most critical of transmissions, its only recently (5-10 years) "encrypt everything" has become common on the global internet.
In general, encryption is not
In general, encryption is not allowed. But to clear something up: Wi-Fi encryption on an access point connected to the mesh is perfectly fine. The traffic is decrypted at the AP, and never goes over the air.

As for application-level encryption, still mostly no. The FCC has informally said it's ok to use SSH to manage a server over the mesh, but I wouldn't bet my license on it. So you have a few options for node/server control: One is to use Telnet. The nodes already have telnet servers built in. Another is to set up SSH with a 'none' cipher. The nodes do not natively support this, and the AREDN team decided it wasn't worth it. Or you could play the odds and hope you don't get a letter from the FCC.

The main reason I opt for the second option is because SSH has capabilities that Telnet doesn't, such as tunneling, passwordless auth, agent forwarding, X11 forwarding, et cetera. 

As for HTTPS, there is not yet a significant good reason nor workaround. HTTP/2 is starting to come into being, and so far every implementation requires encryption. Its advantages for the mesh are mainly related to speed and bandwidth, which would be especially helpful for cameras, but the encryption negates it. Do you have any specific needs for an encrypted protocol?
Source of FCC info

The FCC has informally said it's ok to use SSH to manage a server over the mesh, but I wouldn't bet my license on it.

This is very interesting. Can you cite the source of this information please?

w6bi's picture
Also heard here.
I was given the same information (guidance, I guess) by Marty Woll N6VI, the ARRL Southwestern Division Vice Director.
Would love a cite as well as
Would love a cite as well as the only permmitted use I'm aware of is a "telecommand station" (has a very specific definition regarding space stations being involved ) communicating to a "station in space".
W6RUF's picture
Is there another option?
what about just choosing to operate the nodes on a non-amateur allocated frequency and use all the encryption you need?
RE: Is there another option?
I would be interested to know what protocol "needs" encryption ? I can't think of anything that I could put on my mesh that "has" to have it, web servers,ftp,voip etc all work fine without.
k1ky's picture
We use PART 15 when needed
We choose to use the PART 15 frequencies, especially in the 5Ghz band whenever possible to avoid these issues.  No worries about content, etc.  Unfortunately, this is not an option in the 3.4Ghz band and the 2.4Ghz band is pretty crowded for long-range work in PART 15.
W6RUF's picture
Thank you K1KY
This was one of the first questions I had when I got involved with AREDN.  The answer seemed obvious. It's one of those questions you learn not to ask...because once you do, you've lost defense from the "known or should have known" prosecution. 
Actually not even the "should

Actually not even the "should have known" part.

If a "reasonable individual would know reasonable should be expected to know" the defense wouldn't hold up.

In addition I recall an FCC case (though I don't have citation in front of me to verify it) where FCC went even further than that declaring basically "as a licensees Title 47 Part 97 license holder you are expected to comply with all of Title 47 and subject
to higher penalties for non compliance" (such as a part 15 device running out of spec )

Regarding using Part 15 channels (especially in 5.8 GHz)
Be advised that frequency is not the only issue at play here to make a node need to comply with Part 97 regs.

  • Nodes routinely broadcast an identification Packet with callsign. This could be argued it makes the connection a part 97 transmitter (however there is some room to argue it's just carried data like a cellphone call) so should be kept in mind.
  • AREDN nodes (even NanoStation M5's) very easily can transmit above permitted maximum Part 15 power outputs. A NSM5 for example would need to be set to a maximum of 19dbm comply with FCC power regulations while the hardware supports 27dbm. Your loosing 8dbm of power  from a NSM5 to be in Part 15.
  • None of the required frequency controls (DFS) for part 15 are included in AREDN builds (just because a channel is in US bandplan doesn't mean you run it as we are not doing the Part 15 radar checks.)
  • If you talk to a single remote device that is found its running Part 97 it could move the entire RF network of those nodes that can be traced to a contiguous RF path into Part 97 (and vice versa) since the two services are not permitted to speak to each other and there is not really a concept of a device operating under both licenses at once.
  • Local ham's running Part 97 can request you shut down your Part 15 operations that hinder Part 97 operations.
  • And way more regulations.
K7OPA's picture
Was going to ask a related
Was going to ask a related question when I found this thread.  Having read above, if someone wanted to run nodes with AREDN SW but strictly using Part 15 channels, the SW would not be adequate to meet all regulations??
We are trying to link an outlying clinic to the main hospital for emcomm purposes but are finding out that their normal comms are weak and they would like to 'piggy back' on the mesh.  I was thinking about running everything on Part 15 channels with the chance to reconfigure (change channel and ID on each node) in case of an emergency situation.  Sounds like that is a no no.
Basically you would need to
Basically you would need to be an expert on Part 15 and understand what features need to exist and not exist. This isn't something the AREDN team specializes in.

In many cases what would normally be in a Part 15 devices the AREDN firmware leaves out (forcing you to stay in band, attempting to enforce power limits, avoiding frequency jumping/radar detection, etc)

There are a lot of regulations in Part 15 that I don't understand and can't speak to fully  (like a regulation on multiple transmitters st the same site carrying the same data, does that mean exact same packets or does it mean same information like routing data going out two diffrent nodes, because that impacts how much power you can transmit per node)

Since the software is developed primarily for Amateur Radio that's where the feature set is geared to. If your an expert on Part 15 it could likely be configured on some channels to hit those requirements but it equally and very easily can be configured to not meet Part 15 requirements.

Couple examples of configurations we allow that are not Part 15 compliant:
Any channel below 149 we don't support DFS which is required for Part 15 but not for Part 97.
Any Channel above 166 is guaranteed out of Part 15 WIFI
Any Power level excursion (as noted a NanoStation M5 at full power pumps out around 8 times (2^3) the legal Part 15 Power levels )

Ultimatley the AREDN team isn't in my mind equipped to guarantee a Part 15 compliance, it's just so far outside our realm
of normal tasks. I know a decenent bit of Part 15 from years of reading, but as noted before there are parts that I have to say I'm not sure" on.  There was talk ages ago about a Part 15 only mode but it got stricken largely for those reasons that we are not experts on Part 15 and that those of us involved at the time really wanted to focus on what we knew and who we were targeting (Amateur Radio Operators.)

AE6XE's picture
I'd echo Conrad's feedback.  
I'd echo Conrad's feedback.   If it were me, I would be comfortable operating in part 15 using AREDN firmware under the following bases and constraints:

1) Stand on part 15 compliance in the wifi linux driver for related settings AREDN has not changed:
2) AREDN change #1:  Do not use DFS channels below 149 (AREDN firmware will not automatically hop to another channel if weather radar pulses are detected).
3) AREDN change #2: Do not use channels above 165 to stay within part 15.407 (uni-3).  (Don't try part 15.247 with another 25Mhz of space above 165--your equipment isn't likely certified under these different rules to begin with.) 
4) Do your homework on the xmit power setting compliant with part 15 power limits.  (This isn't an AREDN change, rather any WISP operator still needs to do this given various antenna gain options to choose from.)
5) Encryption is turned off in AREDN for the 802.11 adhoc connection, this feature is not avialable.  However, under part 15 rules, you may transport https and other encrypted protocols (and/or deploy a vpn over this link for the serviced entity).  
6) Hope there isn't too much channel contention, and link is still usable. 

I don't believe we've made any other relevant changes to the linux driver to account for.  Conrad is that correct, did I miss any?


Probably the big one now that

Probably the big one now that I think in it is that to my knowledge it is impermissible for a Part 15 device to be capable of going out of Band, by loading the AREDN firmware and confirming it into mesh mode it does permit out of band it's possible it negates any Part 15 operating ability of the hardware (even if not utilized. )  So may need to remove that configured code as well.

Part 15 is a VERY big set of regulations, I make no guarantee to any of it and I don't track what changes we do that may be Part 15 noncompliant as I'm focusing on  Amatur Radio regulations when coding.

AE6XE's picture
The current AREDN supported

The current AREDN supported equipment is prior to newer fcc rules going into effect enforcing this channel lockdown, e.g. Mikrotik, devices certified under the same part 15 rules with the same out-of-part-15-channel ability meet FCC rules to operate legitimately.  This may be a future issue for equipment manufactured under these newer fcc rules.  But even then, I'm not convinced this is an issue for 3rd party FOSS's software enabling channels outside of part 15 would prevent part 15 usage.  

The part 15 rules certify the 'equipment' and allow 3rd party FOSS to be loaded and maintain the equipment's certification to operate.  The 3rd party FOSS is never 'certified' per se.   The same equipment on 3rd party FOSS may or may not not pass certification--OpenWRT/LEDE's case--certification compliance is unknown.    But it is apparently still permissible to operate.  Of course if operations for whatever reason are outside part 15, one can be busted.   I'm leaning on this reference: 


K7OPA's picture
Thanks for all the comments and info - seems like there might be a scenario where this would work - I will investigate further.  I also remember reading about the out of 15 channel issue and the apparent flexibility.  Thanks again to all


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer