Meshtastic is described as an off-grid text message project. The text messages travel entirely over a network consisting of LoRa devices connected in a mesh. What does “off-grid” mean in this context? It means the text messages use a network that has nothing to do with wifi or the Internet or cell phone service. Instead the messages are transported over a mesh network made up of multiple LoRa devices. The device that sends and displays the texts is a smartphone, connected by bluetooth to a LoRa device. The LoRa device is in turn part of a mesh network with other LoRa devices. Again, wifi, the Internet, or the cellular network are not involved. Bluetooth is used only to connect between the smartphone and the LoRa device. Thus the entire end-to-end text message is completed off the grid. Meshtastic is a firmware version that is installed on a LoRa device. One example of a LoRa device is a TTGO T-Beam, shown below. Meshtastic firmware has been installed.
What does LoRa and Meshtastic have to do with a remote station?
The answer to that question is, it can be used for station telemetry. That means temperature, voltage, and current can be texted back to the client automatically. The text messages can be generated by an Arduino microcontroller or a Raspberry Pi Pico microcomputer and fed into the Lora device. On the other hand the client can send texts that turn on relays or turn off relays. Equipment can be rebooted. Equipment can be turned on and off.
It is a plan to implement a Meshtastic system at the W0QL remote station once a Lora signal path is reliable.
Upon further study, it appears that the above scenario would work fine if the two endpoints were less than 2 miles a part. With distances of 35 miles it is not a solution. Meshtastic requires the mesh nodes, that is, the relays in the middle, to be under the control of the same operator as the end points. Given the t-beam units have a range of 2 miles, several nodes will be necessary as relays. The purchase cost, maintenance, and installation of multiple nodes may be a limiting factor to using Meshtastic. Moving on to similar technologies, would LoraWAN work?
Research on LoraWAN shows it needs a gateway to the Internet. Any gateway at the remote station site would be down if the Internet is down and therefore not usable at the very time it is needed most. Finding another gateway that is reachable out in the country is a challenge. Gateways require authorization and that’s where this technology is limited. So as of now there doesn’t seem to be a solution for telemetry monitoring over a 35-mile link that is within reason. Project is on hold.
Mike Walker at Flexradio introduced us to KMTronic. He uses this device in his remote station to simplify turning equipment on and off remotely over the web. The KMTronic has a built in web page providing a simple user interface. All that is needed is a web browser and the KMTronic’s i.p. address. Priced at less than $100, it is a great solution for remote station users.
At the W0QL remote station a KMTronic has been installed to provide two backdoor access functions. One is LAN isolation between the AT&T Mobile Hotspot and the main LAN. Four relay contacts are used to electrically bridge the two LAN’s, or to isolate them. The other four contacts are used to reset the BMS’s on the four battery banks. If a BMS has tripped, the KMTronic can be accessed over the Internet and the corresponding relay can be activated that will reset the BMS remotely. This saves a site visit.
How To Use
Internally the i.p. address of the KMTronic is 192.168.1.204. It can be reached remotely by any device on ZeroTier with a network id ending in ee4.
Abstract: It has always been a goal to have “backdoor” remote access for troubleshooting. There are times when the primary Internet connection is down and normal access is not possible. It is those times when backdoor remote access saves the day. It could prevent a site visit, a trip to the site.These are the specific essential building blocks:
AT&T Mobile Hotspot
Raspberry Pi running ZeroTier, ipforward and iptables
Same subnet but separate ranges of i.p. addresses
Let’s get started: First, an explanatory overview. The hotspot provides Internet access over a different path by using the cellular data network. This specific hotspot costs $35 a month for unlimited data. T-Mobile’s $50 service would probably also work. Up and down bandwidth is 30 Mbps, even in the rural location. Luckily there is an AT&T cell tower not too far from the remote site. Not so lucky is the fact that the hotspot provides only a private i.p. address and not a public address so it cannot be reached from the outside world. Called “carrier grade NAT” or CGNAT, it is a heavy duty impenetrable firewall. Not to fear, however.
A great solution to the CGNAT problem is a product call ZeroTier which becomes the second detail of this project. ZeroTier is an application that runs on a computer behind a firewall and reaches out over the Internet to a software defined LAN. A software defined LAN is similar to the user side of a home router. Instead of the hardware connections like a home router uses, a software defined LAN does it all with algorithms and the Internet. Other computers running the same application and same credentials can reach the same software defined LAN and communicate as if they were all in the same office. For backdoor access one instance of the application is running on a computer at the remote site (a Raspberry Pi) and another instance is running on a computer (Windows 11 pc ) at the home location. Competing products exist and might also work, like Tailsscale, reverse TCP tunnelling, SoftEther, WireGuard and possibly others that do NAT traversal. ZeroTier has been the most comfortable and successful of the ones tried at this remote station.
How To Use
Any device anywhere worldwide on the same ZeroTier network can reach the LAN at the remote site. As this is written the network id ends in ee4. To reach the i3 NUC: Power is on the ‘Station’ circuit on the 4005i using port 82. The NUC i.p. on the LAN is 192.168.1.100. It can be reached using Remote Desktop Protocol. The Pi is at 192.168.1.204 and it can be reached with Putty. The KMTronic is at 192.168.1.204 and it can be reached with a browser. If the main LAN is down the only device that can be reached is the Pi. Other well known ports:
Follow the instructions on the ZeroTier web page to make an account and to create a network. Their free plan has all the features needed.
This brings us to the third detail, the Raspberry Pi computer.
A Raspberry Pi is fully capable of running the ZeroTier application and then some.
Shown above is a Raspberry Pi model 3 which is the model being used in this project. Follow the instructions on the ZeroTier web page to join the network created above. With a hotspot and a Pi running ZeroTier the hardware and some of the software to get into the site is complete but no connection has been made to the main LAN yet.
Each detail has involved challenges but probably the biggest challenge of all has been how to connect to and how to communicate with the existing LAN at the remote site. At this point there are two LAN’s, one providing a data link between the hotspot and the Pi and the other LAN providing communication for all the existing equipment. Connecting any two LAN’s requires a router, but not just any router. An ordinary home router will not do. Turns out the solution is simple and elegant thanks to the Linux operating system running on the Raspberry Pi. It can run a few built-in processes and perform the necessary router functions. A nice writeup of how to configure this routing function is published by the ZeroTier developers: “Route between ZeroTier and Physical Networks“
sudo iptables -t nat -A POSTROUTING -o $PHY_IFACE -j MASQUERADE sudo iptables -A FORWARD -i $PHY_IFACE -o $ZT_IFACE -m state –state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i $ZT_IFACE -o $PHY_IFACE -j ACCEPT
Another essential process is ipforwarding:
sudo sysctl -w net.ipv4.ip_forward=1
Edit /etc/sysctl.conf to uncomment net.ipv4.ip_forward. This enables forwarding at boot.
Next, take steps to avoid two devices having the same addresses on the combined LAN: On the hotspot, set the dhcp i.p. address range to the highest 50 addresses in the subnet, and make the subnet identical to the main LAN subnet. Turnoff DHCP on the hotspot. On the main LAN, set the router dhcp range to exclude the top 50 addresses and leave DHCP on.
A few items remain to polish the backdoor project. The whole idea is to be able to access the remote network at all times. There is no way to know what the source of the failure might be. It could be power down inside the remote station. In that case the backdoor needs to have it’s own power. For that reason, the hotspot and Pi have their own battery and solar panel separate from the rest. Considering the main LAN goes through a big ethernet switch and that switch could be down, the hotspot and Pi have their own switch. That small switch is also powered by the separate battery. Rebooting devices remotely is invaluable. Some devices, like computers, can be rebooted with software commands or they might need a hardware reset. Other devices, like BMS’s and EMC’s require a hardware reset. Relays wired to provide the hardware reset, controlled over the Internet through the backdoor can save a trip to the site. At this site relays are wired to short out the BMS’s (which is how they are reset if they have tripped). Another bank of relays is installed to reset the EMC’s if they lock up ( like they have been prone to do ). Almost all equipment has a method of being rebooted or reset remotely.
A successful backdoor access project provides a lot of comfort knowing the every day remote operation has tools for a better chance of recovery when something goes wrong.
Thoughts for future improvements – One improvement could be to move all the non-radio equipment to the secondary Internet connection, leaving the entire bandwidth of the main connection to the radio. That would be easy because the hardware connections are already in place. It would just be a matter of changing the i.p. settings on each piece of equipment to static with the gateway address of the secondary connection. A second idea is to combine the two Internet connections into what is called “dual-WAN” service. A product exists to do this easily (according to the sales literature). It is called Speedify and is worth checking out someday.
One additional thought. Use bridging instead of routing to see if bridging would pass the broadcast packets. What this means is the packets that advertise a service are being blocked (by the hotspot??) when using routing. It is possible bridging would fix this. The hotspot would not see the packet headers and thus not know any particular packet was a broadcast packet.
One more additional thought. Use iptables “mangle” to create a mangle table which will be a MSS filter. Set the filter size to, in turn, create an MTU size that will pass through the PPPoE Internet connection at the radio end.
Here is an example of a line of code to create the mangle table:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
Flexradio says the Maestro manufacturing has been held up for several months due to a shortage of parts caused by Covid-19. This unit was snatched up from the QRZ.com online swapmeet and it’s a beauty.
Shown above in it’s travelling mode. All it needs is a wifi connection. It has an internal battery that will run quite a few hours. Portable operation gets a lot simpler with this device. A mic or a paddle is all it needs to get on the air. Back at the shack it looks equally at home with a paddle and a microphone.
The Maestro is an option that is not essential because all operations can be done with a pc or a laptop alone but this is for those of us who still like knobs. The knobs on the Maestro have an expensive-radio feel. It’s a pleasure to operate with this option.
Update: Flexradio says this issue was fixed with SmartSDR release 3.3.29 in April, 2022 but when a test was done it looks like this problem is still there. Same with 3.3.32.
Remember this number: 1478. Another way to put this is “The maximum segment size should be set appropriately for the network path between the two endpoints, so that no segment has to be fragmented”. ( to be explained later)
Mark this day, February 29, 2020, which is leap day. A new FlexRadio 6600 transceiver was ordered today and that’s a big leap. The advertising seems to emphasize both FT8 and remote operation. What could be better?
Actually this is a picture of the 6600M meaning it has the Maestro front panel builtin. A 6600 and a Maestro were ordered separately so it can be used remotely. It’s a big step breaking out of the Icom juggernaut. The plan is to see which radio performs better and sell the other. Beating an IC-7610 will be a big challenge.
The 6600 arrives! The Maestro is on back order. The 6600 is even more beautiful in person. A perfect project for the Covid lockdown using a pc and SmartSDR while waiting for the backordered Maestro. Now to see it perform. First tests are to feed a signal to WSJT-X and count FT8 decodes. The antenna here at home is hookup wire with a tuner which is not equivalent to the 43′ vertical at the remote base but it’s good for testing. Evaluating a few passes shows fewer decodes and poorer SNR just as expected. It’s not a real test until both radios are on the same antenna but it does demonstrate how easy it is to get up and running on FT8. The challenge begins.
Testing at home before the journey to the remote site.
Installed at the remote site and operating, squeezed between a battery and the 7610.
The installation went 99 per cent smoothly with only one issue remaining. That one remaining issue turned into a 5 week nightmare to troubleshoot. Issue: The 6600 cannot be reached over Comcast Xfinity internet service. It cannot be accessed over the Internet if the Internet provider at the client end is Comcast Xfinity. Access works when the client is using a AT&T mobile hotspot. It also works when the client is using an iphone hotspot on AT&T. Flex support says Xfinity has implemented a new security feature called Advanced Security and that might be the issue. An attempt is being made now to work on this issue, so far with little luck and much frustration.
All indications point to Xfinity being the problem so a new modem was ordered which is XFi capable. The existing modem is too old to have that new Xfinity security feature. Modem is scheduled to arrive this week.
Followups: Arriss model TG1682G modem purchased from eBay arrives. The new ebay modem worked great for Internet access but it did not provide the feature needed which is XFi. Working with Comcast technicians over the phone it was finally disclosed that the XFi feature is only available on Comcast supplied modems. A Comcast modem was ordered, arrived, and activated. XFi works now and Advanced Security was turned on and off. No joy. Same results. The 6600 cannot be reached. A Flex community forum post said someone had the identical problem. He said the old modem, an Arriss 862G, worked but his new one didn’t. An Arriss 862G was immediately ordered from ebay and it’s arrival is being anxiously awaited, as of April 24. Meanwhile, Flex still has an open ticket but it is on hold til all the gyrations are exhausted on this end. The AT&T Hotspot still works and is being utilized as a temporary alternative.
Followup May 10, 2020. The Arriss 862G produced identical results. No joy.
A vpn (virtual private network) was set up as a test on Comcast Xfinity and it works (ExpressVPN). Go figure. That is a second work around along with the AT&T mobile hotspot but not a solution. Dan Quigley, the manager of support at Flexradio became involved. He looked at traceroutes and theorizes where there is a problem in the network. He is comparing good traceroutes to bad traceroutes. Zayo is the provider at the destination and all connections work once they get to Zayo (except clients with Comcast). They also work if they go through the last couple of Comcast routers, the highest of which has the host name or dns of “910fifteenth”. That is the address of the “Internet Hotel” in downtown Denver, which is a peer location to handoff Internet service to multiple providers in the region. The router directly above that is “1601milehigh”. That is the address of the small Comcast building in the parking lot of Mile High Stadium. Dan thinks that might be where some packet filtering is going on. Contacting Comcast Advanced Repair was fruitless and frustrating. Very much no joy and no progress.
Meanwhile a network probe was installed at the Strasburg end to see if any packets are by chance actually reaching the Flex. They ARE. So the packets are not getting blocked or filtered by Comcast apparently. The Wireshark sniffer shows what is happening. When a setup packet comes into Strasburg the Flex responds. An oversized TCP packet is being generated by the Flex but only with Comcast at the client end. The size of the packet is 1514 bytes and the MTU (maximum transmission unit) in the remote router is 1492. An error shows up on wireshark coming from the remote router which says the packet should be fragmented. Why is the Flex not fragmenting packets and why is it only when we are using Comcast? The VPN also uses Comcast and it causes no problem. Why? This information has been forwarded to Dan Quigley at Flex and his ideas are being anxiously awaited. No response from Flex in three days. (Or ever)
Followup: Success! We figured the problem out on our own after “putting in the work” as they say. It is solved by a simple parameter change on our own equipment. A connection from a client using Comcast with no VPN works perfectly now. Audio is not choppy. Full panafall display works just as it should. CW is smooth. All is good. The simple and free change? Reducing MTU on the client router from 1500 to 1478. That’s it. Ready for the long and tedious explanation? Here goes.
Changing the MTU causes the pc to send a SYN packet with a MSS (maximum segment size) specification of 1438. By the rules of the Internet (RFC 1323) the Flex is therefore obligated to send no packet with a payload bigger than 1438 bytes. The Flex adds on the header overhead of 54 bytes, which can’t be reduced, for a total of 1492. Bingo. The MTU of the remote router is 1492. That number is prescribed because the Internet service uses the protocol of PPPoE which is limited to 1492. Here is the key to the original failure which requires a more detailed explanation. Overwhelmed yet?
The Flex was generating packets that were 1514 in length and the remote router was correctly dropping them and sending back an error message. Unfortunately Flex has ICMP turned off which means it was never getting those error messages. The Flex would retry the oversized packet several times and give up. A connection request always timed out and failed. Why did other Internet carriers work? The answer lies in the MTU of those networks. Just by luck the MTU’s somewhere deep in their networks were always 1478 or smaller. The client PC always performs a Path MTU Discovery as part of beginning a connection for the purpose of discovering the smallest MTU deep in the network. This detail was researched from a Cisco white paper. Windows does a Path MTU Discovery to find out what the smallest MTU is in the network. Windows uses this information to avoid causing fragmented packets. The PC inserts that number in a SYN packet telling the far end host how big the host’s MSS, or payload, can be. At that point the host, the Flex, would generate packets no bigger than 1492 and therefore would not overflow the remote router. Connection successful.
How was this solution figured out? It has apparently not been written about in the Flex community forum based on multiple searches producing nothing. Comcast was no help in network troubleshooting. Flex’s only response has been to direct us in the wrong direction, the network. Certainly Flex has added to the problem by having ICMP turned off which caused it to not even receive the error messages. If it had received the errors it possibly could have adjusted the packet size on the fly and fixed the problem without intervention. But that’s just speculation. No doubt Flex has a good reason to have ICMP turned off. Here is one good explanation which also includes an easy way to turn it back on if one had shell access. https://www.thegeekstuff.com/2010/07/how-to-disable-ping-replies-in-linux/
The big puzzle was why the Flex was sending packets that were too large. How did the Flex determine the size of those packets? A little digging provided the answer: MSS or maximum segment size. MSS is the payload size. By the rules the host can vary the size of a packet by changing the size of the payload as long as it’s not bigger than the MSS. The host cannot exceed the MSS. A header with a fixed size is wrapped around that payload. Next logical question is how is MSS set? A little more digging provided the answer: A client PC runs Path MTU Discovery and sends a SYN packet to the remote host which includes the MSS calculated from that Discovery. Consider this. The Comcast network could be so good that all their routers have the maximum MTU. Therefore the PC could be sending a SYN packet with a MSS that is ok for Comcast but too big for the network at the remote site (remember it uses PPPoE protocol which has an MTU of 1492). At that point it was easy to use Wireshark to show what the actual MSS was in the SYN packets. Indeed it was too large. Next question is how could the MSS be reduced? The answer lies in the fact that Path MTU Discovery looks at all the MTU’s in all the routers along the path including the router at each end. It then uses the smallest MTU found to calculate MSS. Aha. Maybe if the router at the client end had the smallest MTU the Path Discovery would calculate a small MSS. Changing the MTU on the router at the client end was tried. The MTU was manually set to a number that caused the MSS to be small enough not to cause an error when the Flex generated it’s reply. That MTU number is 1478. MSS is calculated by the machine to be 1438. The fixed header is 54 bytes which is wrapped around the payload of 1438 bytes for a total of 1492. Joy. That 1478 is the MTU of the client router and it is happy. Problem solved.
Sidebar: Why did some networks work and not others? The Internet service at the remote site is provided by a wireless ISP which uses a protocol of PPPoE. PPPoE and ADSL both add 8 bytes of overhead to the packet headers which reduces the MTU by 8 bytes. The customer only gets to use 1492 instead of what is standard for most Internet which is 1500. That is most likely why the connection to the Flex also failed when we tested it on Century Link. Century Link uses ADSL which also limits the MTU to 1492. As for why it works on VPN the answer probably is in the MTU of one of the routers used along the way by the VPN. Same possibility with the AT&T Mobile Hotspot. Some hop has a small MTU, which results in a smaller MSS, which results in the Flex sending smaller packets, which results in a good connection.
Trying to help others from suffering this is the post made to the Flex Community Forum:
Can’t connect to Flex using Smartlink over Comcast but works ok with other providers?
The post included a very short synopsis and solution in the hopes of helping some one out there.
January, 2022: New router and upgraded Internet service make MTU problem raise it’s ugly head again. This time the problem is caused by not being able to change the MTU on the router. First new router, ASUS AZ86U, only allows the MTU to be changed if the Internet connection type is PPPoE. That router was exchanged for Netgear Nighthawk RAX120. Changing the MTU is supported but it doesn’t work. Changing the MTU parameter and applying makes no difference to what the router actually transmits. Netgear Case number 45573570. TPLink AX6600 works fine.
At least two workarounds are possible. The first one is to add a second router in series with the PC or Maestro and set the MTU on the new router.
The second workaround uses the command line to do network shell routines. One routine can change the MTU on the PC. Open cmd with administrator permissions and enter these commands.
Changed out the old Linksys E2500 router today for an upgraded Linksys EA6350. Two problems are addressed. First the E2500 has the lowest lan-to-wan throughput of any Linksys router, per tomshardware.com. The EA6350 is much better. Second, out of all the Linksys routers the E2500 is one of only a few that are susceptible to the new vpnfilter malware, per https://www.symantec.com/blogs/threat-intelligence/vpnfilter-iot-malware. The E2500 has blocked some web sites even when using the I.P. address which is a good hint that it has the malware.
Some days you eat the bear and some days the bear eats you. Success is going from failure to failure with enthusiasm. I know. You’ve heard ’em all. This was one of those days. Time to redesign. When the pole was up to about 45 degrees one of the fiberglass sections snapped. As it came crashing down around me two more sections snapped when they hit the ground. Three sections are broken and replacements are not available on ebay. The picture below is NOT how it’s supposed to look.
The ladder was being used as a gyn pole raising fixture and it did it’s job very well. Fiberglass camo poles just aren’t strong enough to lift their own weight when they’re longer than 8 sections.
Aluminum sections are the only type I could currently find on the market forcing a switch. Ladder line won’t work inside aluminum and that dictates we switch to coax. We’ll need a balun at the top. More weight to raise. Otherwise the design will stay the same. Aluminum poles are on order. Hopefully aluminum sections will be strong enough. Work is on hold til they arrive. Meanwhile…
Thursday, April 14, 2016 Update – I’m having second thoughts about switching to aluminum and coax. I’d be much happier if I could figure out how to get the original design working. Today I found a company on the Internet that says they have fiberglass army poles. I think fiberglass will work if I lift the pole one section at a time from the bottom like a telescoping pole. I’ll make the mounting post taller so the top clamp holds the pole at about 5 feet above ground. Then I can slip in the next section and raise the pole. Repeat until the proper height is reached. I will loosen the guys enough each time to allow raising the pole one section but not enough to allow the pole to fall over. I tried this method for the remaining unbroken poles in the picture below and it seems to work. It only needs 3 more sections inserted at the bottom.
Oops. I called to make sure the company that advertised fiberglass poles really had them. They do but the shipping is $48.00. I passed. (After about passing out.) Still hoping for fiberglass, I will try to repair what I can and reuse the broken sections. Lonely and waiting for attention the half done support pole awaits.
The article below might be one reason why I had second thoughts about going to coax. This is stolen from KV5R’s web site which I highly encourage one to visit: http://kv5r.com/ham-radio/ladder-line/
To efficiently feed a non-resonant multi-band antenna.
First, let’s dispel the greatest myth in antenna theory: Antennas must be “resonant” to be efficient. Baloney! It just ain’t so!
Please recognize that an antenna need not be resonant in order to be an effective radiator. There is in fact nothing magic about having a resonant antenna, provided of course that you can devise some efficient means to feed the antenna. Many amateurs use non-resonant (even random-length) antennas fed with open-wire transmission lines and antenna tuners. They radiate signals just as well as those using coaxial cable and resonant antennas, and as a bonus they usually can use these antenna systems on multiple frequency bands.
ARRL Antenna Book, Ch. 2
As long as the length of the antenna is at least a half-wavelength at its lowest intended frequency, its efficiency is well over 90%, just like a resonant dipole. The problem is getting power to it—coax is very lossy (due to dielectric heating) unless terminated into its characteristic impedance, and this effect is what leads most hams to erroneously believe that non-resonant antennas are inefficient. But the problem isn’t non-resonance, it’s high SWR on coax.
On the other hand, ladder-line does not suffer from high losses at high SWR, so may be effectively used to feed an antenna that may, at various frequencies, present the feed-line with any SWR from 1:1 to ~10:1. So, with ladder-line, you can completely forget about resonance and SWR, until you get to the radio, where you use a tuner to make the match to 50 j0 ohms.
To compare mismatched feed-line losses we have to start with the antenna’s feed-point impedance, and the line’s impedance, then calculate the SWR, and finally, the loss of each feed-line-type at a given frequency and length.
For a worst-case example, feeding a voltage node (like running 40 meters on an 80 meter dipole), let’s say the feed-point impedance is 3500 ohms. With 100 feet of RG-8 coax at 7 MHz, that’s a whopping 65:1 SWR, with a total loss of 78%. With 600-ohm open-wire line, the SWR is only 5.8, and the loss is 3%! Then, if we switch to 80 meters, the impedance is 50 ohms, the SWR is ~12:1, and the loss is 7%. In this case, 450-ohm line would be even better, because the SWR only varies from about 9:1 at 50 ohms to 7.7:1 at 3500 ohms. The total losses for 100 feet of 450-ohm windowed ladder-line, at 9:1 SWR, ranges from 5% at 3.5 MHz, to 14% at 28 MHz, and again, that’s at the worst-case mismatch points.
So we see that ladder-line is not only better for non-resonant antennas because of its much lower loss at high SWR, but also because its characteristic impedance places it nearer the center of the antenna’s impedance range, from lowest (odd half-waves) to highest (even half-waves).
Before we get too far ahead discussing antennas we need to address the very important subject of configuring software for port forwarding.
Port forwarding is necessary for getting through the firewall on the router at the remote site. Otherwise when the I.P. address of the remote base is entered the packets would get blocked by the firewall. Remote Rig is the device that needs to be reached behind the firewall. Other devices might have been added like we did (the Remote Power Monitor ). Entries need to be made for each device using unique port numbers.
Find the page where port forwarding is configured on your router. On our Linksys it was under the “Applications and Gaming” button and then under “Single Port Forwarding”. First enter the “Application Name” which is what the device will be called by. Our Remote Rig is being called Rem Rig. In the next column is the port number chosen arbitrarily. You can chose any port number you want that is available. ( ISP’s block certain ports ). We chose 81 because it’s the next port after web pages ( port 80 ) and it’s not being used by other services.
In the next column the port number used by the Remote Rig is entered. This is normally Port 80 because it is the Remote Rig’s web page. Port 80 displays the internal web page and this is what we want to access. Here is what our port forwarding page looks like.
We also need to reach the ports used for sip and the voice packets on the Remote Rig. Those ports are 13000 through 13009. Those can be put in one at a time on the Single Port Forwarding Page or all at once with one entry on the Port Range Forwarding page as shown below.
For the Remote Power Monitor we chose the next available port number which is 82. We will forward port 82 to the Monitor’s port 80. It does not require any other ports because all the information is displayed on the Monitor’s web page.
To reach the Monitor from any place on the Internet we type in the I.P. given to us by our ISP followed by a colon and the port number. Let’s say, for example, we had been given 18.104.22.168. We would use our web browser and type in 22.214.171.124:82. Up pops the Remote Power Monitor main page.
At some point we need to find out what the I.P. is that our ISP has given us. This can be done by going into the router’s status screen and looking at the Internet or WAN address. If the first number begins with a 10, 172, or 192 more work needs to be done. Those are private I.P. addresses behind a firewall and you need a public address. You must obtain a public i.p. from you Internet Service Provider and there will likely be a fee involved. The fee we pay is $10 a month.
Although we haven’t tested it there might be a way to save the fee and get around the firewall by using proxy sites.
Earlier we found the I.P. address of the Remote Rig. That information is located in a “dhcp table”. The router will have a button somewhere to display the table. On our Linksys the button is located right on the front page and it’s called “dhcp reservations”. Remote Rig was not named so we had to obtain the (12 character) MAC address from the physical label on the Remote Rig and then search for that mac address in the dhcp table. For us the i.p. address is 192.168.3.134 (It later changed to 192.168.3.147). Beginning with a 192 is ok here because we are on the LAN side behind the firewall and that’s where private addresses are used.
And now we’ve discussed port forwarding and hopefully shown how easy it is.
Here’s what Morningstar says about port forwarding on their web site:
There are many different router models, so we cannot provide specific direction in this document for configuring port forwarding. However, the website:
When one dials into the Remote Power Monitor this is the greeting screen. It shows voltage and current draw from each device. It also provides the ability to turn on or off any device over the Internet. Very dangerous because the Internet equipment can be turned off remotely leaving us disconnected with no way to turn it back on. If that happens it would require a site visit to restore.