You are here

Updated: Best Mobile Node for RV/Motorhome

17 posts / 0 new
Last post
K6BKD's picture
Updated: Best Mobile Node for RV/Motorhome

I recently acquired a 2007 Coachman Freelander Motorhome and wanted to put a AREDN node on it that could connect to anyone in the US. What equipment would be recommended. I've watched the ARDEN in the Park video and was thinking of a similar setup, just mobile. As for mounting the node on the antenna of the RV, this one came with an Omni TV Antenna so there is no mast that I have to raise to get a signal. So no where to mount the AREDN Node, except maybe on the ladder in the back. 

Also on a very important side note, why does this site not go to HTTPS mode when signing in the users? My password Vault warned me that it wasn't in secure mode when filling in my secure credentials.

As for getting to this site from the AREDN mesh network. I didn't know you could get to the Internet from AREDN. Since that is possible, then I would still want the login process encrypted as passwords should never be in the clear text. It could be setup where the authentication process went to tls mode but the content on the site wasn't. Or you could make the front end of the site have a redirector that looks where you are coming from and takes you to the secure version when you are coming from the internet but unsecured if from AREDN, except for the login process. 

Ben (K6BKD)

K5DLQ's picture
1) for the motor home:
1) for the motor home: Ubiquiti AirRouter
2) SSL/TLS: great question.   I agree and will check with the team on this.

K5DLQ - Darryl
Note: The following is a
Note: The following is a personal opinion and in no way represents an official policy of AREDN.

As a security guy I'm very pro TLS and say no site should ever be unencrypted.

As a ham, there is some argument to leaving the site unencrypted (especially since it's got useful info for mesh) incase someone needs to get on over the mesh.

Going encryption only on AREDN would be much how Google is no longer useable by HAM's on the mesh since you can no longer disable encryption.  A real shame considering how useful Google is.
WL7COO's picture
Hello Conrad; Respectfully, as you know, I'm a relative

neophyte re: current Internet security issues.  I've been reading USC Title 47,  Part 97 at  very random intervals along with the occasional FCC Responses to Proposed Rule Makings that reference 'encryption'.    Recent close readings of Part 97 coupled with various FCC responses,  primarily the denials, to Proposed rule makings trying to change Part 97 to allow encryption makes it clear that Amateurs have always been encouraged by the FCC to make use of available published algorithms to ensure reliability, non-repudiation and security for Public Service and Public Safety traffic we convey between Served Agency sites as well as what we originate as tasked to by Served Agencies, over Amateur Freqs.   What Part 97 does forbid, along with the pecuniary and conduct prohibitions,  is for us to 'encode' traffic that we originate in order to obfuscate the message (communication) or it's points of origin & delivery.  I don't think the words 'encryption'  or 'encrypt' are ever used in Part 97.   Every time someone files a Proposed Rule Making that Amateurs be allowed to "encrypt" data on Amateur frequencies, the denial of that proposal includes the language "... because it is not necessary".  It is my belief that the FCC really doesn't care what traffic goes through AREDN on Amateur freqs so long as the source (node), destination (node)  and callsign of the responsible Amateur is readily discernable for every packet, in English,  during every RF hop on Amateur freqs?    Nothing in Part 97 that I can find requires the contents of a digital multimedia packet payload to be readily discernable by anybody.  It is however our responsibility to ensure it does not contain otherwise proscribed communications.  The longstanding belief that Part 97 forbids "encryption" on Amateur Freqs has to be viewed in the context of;  "can the FCC (or anyone else  who cares,  using appropriate equipment and publicly available software) discern where (which AREDN node) any given tcp or udp packet originated,  which AREDN node it is going to on this hop and under whose license authority it is being transmitted?"   What Part 97 tells us not to do is muck about with the payloads of packets we move.  One of the reasons I believe AREDN technology has so much appeal to Emergency Managers is that data streams originating at one location will reliably arrive where they are sent to unchanged.  This is a sincere request for you to explain how, where and why AREDN traffic will be violating Part 97 transporting packets between an Amateur or a Served Agency Employee (including duly authorized Volunteers)  and a public Internet web site (like Google) that is using published security algorithms and RFC defined protocols to protect communications with clients?    I agree that every Amateur has to make their own decisions about this issue.   It helps me to read Part 97 at least yearly -  what I think it means definitely changes with every reading.  Thank you again Conrad for your ongoing contributions to AREDN.   73, ...dan wl7coo 

AE6XE's picture
In addition to the AirRouter
In addition to the AirRouter (inside the RV), I'd put a Nanosation on the roof, ideally on the Digital TV antenna that one can raise and rotate from inside the RV.   Alternatively, this might be a Rocket Omni (the shorter lower gain one).   You'd be able mesh with all the other hams in the RV campground.  

Then, I'd probably put up another NanoStation with AirOS in bridge client AP mode to connect into the campground's wifi  and connect it on the WAN port of the AirRouter.   These antennas would be right next to the HF Antenna, DirectTV, 2m/70cm, and other antennas...  :)

Joe AE6XE 
Joe, show us a picture

we we should all have a picture of your RV roof...

N2MH's picture
Luggage Rack

I have a NanoStation permanently mounted to the forward looking bar of my luggage rack. Normally, the NanoStation has about a 60 degree beamwidth in the horizontal direction and single digits in the vertical direction. However, since mine is mounted horizontally, that single digit vertical is now single digit in the horizontal direction. This results in the node needing very precise aiming at whatever other node it is trying to reach. So, if you can, mount the NanoStation vertically if at all possible.

For a picture of the node, go to my Bug Report:

73, Mark

n0kfb's picture
I believe that encryption over amateur radio is prohibited by 97.113, subsection A 4.

97.113   Prohibited transmissions.

(a) No amateur station shall transmit:

(4) ... messages encoded for the purpose of obscuring their meaning...

We also need to watch the restrictions placed on us by 97.115 concerning third party communications.

I would expect it to be easier to just keep power levels to part 15 limits, and then do whatever you want with regard to encryption and third party traffic.

Dan Meyer / n0kfb
K5DLQ's picture
That is the crux of in my
That is the crux of in my opinion.  "... for the purpose of obscuring their meaning..".

If I am on the mesh and navigate to WebEOC (which forces the use of encryption), my "Part 97" purpose in using a TLS (encrypted) connection is NOT to obscure, but, to use a valuable service that is only available over a TLS connection.

Therefore my intent is to access a service, not to obscure the meaning.

My $0.02 worth
Yes but as this is a 2 way
Yes but as this is a 2 way communication you have to ask WebEOC why they use encryption.

I don't mean to put words in WebEOC mouth, but I can tell you when I use HTTPS on a server my purpose is to "obscure and secure the communications channel from eavesdroppers" 

To my knowledge nothing stops someone from having a gateway server to decrypt WebEOC at the PoP(Point of Prescence) and then push it to the mesh decrypted.
KD2EVR's picture
One could consider making the

One could consider making the argument that the primary "purpose" of https in these cases is to "ensure the integrity/authenticity of the data"

Ferinstance, if I ask another ham on VHF for a pre-arranged "code word" to authenticate that he is who he says he is, would that violate part 97?

Just some thoughts.  I suppose until someone gets a positive response from the FCC its all academic. 

AE6XE's picture
FCC rule making process regarding encryption
This issue was somewhat hashed out in the FCC rule making process. Please see links below. Note, the ARRL comments to the FCC was that encryption is unnecessary for Amateur Radio to achieve our purposes (except justified/allowed for purposes of authentication). HSMM (which includes AREDN) technologoies was specifically commented on by the ARRL. The FCC subsequently agreed and denied the request to allow encryption noting that the majority of comments did not support the rule change. The bigger discussion (we should start another thread if further replies), is if the timing, conditions, and justification exists for someone to request rule making that, e.g. a vpn connection or https for webEOC, is a requirement from a served agency for Amateur radio to provide emergency services. Our world has moved away from analog technologies to digital communications where it is mandatory to encrypt protocols carrying messages against threats -- anyone "WannaCry"? I have been asked by local Sheriff's IT organization the options to do exactly this for linking the mobile command center back to command central--enabling officer's access to Sheriff applications in support of their job. This is in context that their commercial 4G cell data service failed for 2 years in a row at the event. While this may not technically be an emergency, the lack of communications increases risk to safety and security in our community. Joe AE6XE
WL7COO's picture
Thank you Joe. Well said.

The Petition  RM-11699 you reference and the FCC's Order Denying it,  DA 13-1918 do focus clearly on the issue of Amateurs 'encrypting' traffic and thereby possibly eroding (according to the ARRL)  the 'self policing'  capability and nature of Amateur Communications.  At the same time it deftly avoids saying we can or can not handle traffic originating from and delivered to Served Governmental Agencies within  the United States. 

I agree with you that denying or limiting the security of Internet interactive Amateur Communications today is a certain invitation for dysfunction and warrants a much closer focus than it has received so far , by *all*  involved Agencies.

See DA 13-1918  III. Discussion,  6.  and footnote 21 related thereto.
This kind of language is reminiscent of the position I attempted to describe in my previous message in this thread.

Might there be a 'presumptive conclusion' by the FCC that handling Emergency and Public Service Traffic originated  (and as appropriate, encrypted)  by a Served Governmental Agency in the U.S. which is delivered  by Amateurs to the same said agency in the U.S.  is not perceived by the FCC as violating Part 97?

This has been an ongoing discussion all along so establishing a separate thread seems appropriate .  
Eventually somebody in the FCC will more clearly address the issue.
That is, if DHS or FEMA hasn't already broached the subject with them and the FCC's silence has meaning in and of itself.

The extent to which the FCC has relied, almost exclusively,  on ARRL for legislative input regarding Amateur Broadband Multi Media Communications has been an open question for more than a decade.  Involvement by Served Agency's, at all levels of Government,  might be forthcoming, if solicited by the FCC,  and might  make a difference now.

Sort of does make one 'WannaCry'....  not to mention giving pause to wonder if a really good Janit0r  or 'Chemotherapy' might help speed up the process?

​AREDN technology  is vastly superior to all 3 of those non solutions and will have a much larger and longer lasting  impact on Amateur Radio.

...dan wl7coo​

k0tan's picture
FCC rule making process regarding encryption
Joe, et al:
I'd like to see a thread continued on this topic. Since the FCC relies on ARRL input, we need a focused effort to educate our Section and Division leaders on AREDN, the usefulness of secure protocols, and the fact that the source and destination call-signs are available. EmComm is in a new era, and we need to get caught up.  AREDN is the arguably the first hot technological advance Amateur Radio has seen since SDR a decade ago.  Building on the work of giants.

With the articles in June QST and March CQ, plus presentations at all major Hamfests, including the classes at Dayton, this is the year of AREDN.  I'll be making the case to Arizona Section Manager Rick K7RAP in a couple of weeks.  If anyone has an "ammo" document, I'd love to present it. Else I'll take what I've gleaned here.

Charlie KØTAN
ckotan at gmail
K6AH's picture
AREDN Core Team working with league
I am already working with ARRL senior leadership on this issue and expect to report progress over the coming months.  Thanks for the support and ask that you encourage section managers to work within the league structure to offer their support.

Andre, K6AH
setup a proxy

If you have to access sites that force https and you are that kind of person concerned about all that.. an option would be to access those sites using a proxy.   You'd connect over RF to the http side of the proxy, it connects over non RF using https to google or any other https forcing site.

Key words:
Transparent squid proxy.... https to http proxy

N0MRZ's picture
RV Mobile Node

Ben, I will clue you in as to what works for me on the back of our 40' three-axle toyhauler. I installed a receiver hitch on the back, if it is a motorhome, you may already have one.  I bought a receiver flag holder that will take up to a 2-1/2" flag pole.  I mount my antenna on a 4' military pole, raise it and add another, and do that until I have 20' of sections, set it in the mount and tighten the two bolts, rotate if needed. Works perfect every time! I usually run a dual bander on top, and a cell phone repeater yagi under that. Starting in the spring, I will be adding AREDN.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer