Using a wifi AND 3G connection from a router on a boat.

Any possibilities in getting the boat to set up a ssh tunnel to home? VPN?

+1 for reverse SSH tunnel
Until the end of the season I was running one behind the marina wifi, with the Pi using SSH to send data home.
I used weaved.com to contact the pi from outside - but weaved has since been changed, but there are lots of similar IoT services being developed.
 
Any possibilities in getting the boat to set up a ssh tunnel to home? VPN?
When I've got it working that's my plan. Mainly so the "boat LAN" becomes part of the "home LAN" and I can check stuff back at home. SSH is easy but linking the two LANs via VPN would be pretty useful, although harder.

Possibly not needed really.....! :-)
 
+1 for reverse SSH tunnel
Until the end of the season I was running one behind the marina wifi, with the Pi using SSH to send data home.
I used weaved.com to contact the pi from outside - but weaved has since been changed, but there are lots of similar IoT services being developed.
I'd never even heard of reverse SSH tunnel! For accessing my home LAN behind the NAT'ed router I'd just forwarded a high free port to port 22 of the internal server.

What's the advantage of reverse SSH over doing this? The only one I can think of is if your router is locked down (and for "real" corporate LANs).
 
I'd never even heard of reverse SSH tunnel! For accessing my home LAN behind the NAT'ed router I'd just forwarded a high free port to port 22 of the internal server.

What's the advantage of reverse SSH over doing this? The only one I can think of is if your router is locked down (and for "real" corporate LANs).

That still assumes that your router has at least one public IP address - possibly dynamically assigned. Normal 3G connections implement the NAT in the network infrastructure at Vodafone/O2/T-Mobile and you do not have control over port forwarding.

Techniques like the reverse SSH tunnel rely on some device in the boat making an outgoing connection to a remote server that does have a public IP address and keeping that connection open - then software at the other end can route traffic to the boat.
 
That still assumes that your router has at least one public IP address - possibly dynamically assigned. Normal 3G connections implement the NAT in the network infrastructure at Vodafone/O2/T-Mobile and you do not have control over port forwarding.

Techniques like the reverse SSH tunnel rely on some device in the boat making an outgoing connection to a remote server that does have a public IP address and keeping that connection open - then software at the other end can route traffic to the boat.

Nice! I missed that. I've learnt a few new things here.

My 3G router does have a DynDNS client and you can port forward on it. Although I've never used either. It's designed to be used with a static IP and a non-consumer SIM card.
 
Nice! I missed that. I've learnt a few new things here.

My 3G router does have a DynDNS client and you can port forward on it. Although I've never used either. It's designed to be used with a static IP and a non-consumer SIM card.

... and you have to be very careful about putting a "non-consumer SIM" with a static IP address into it! As I said above, I did consider doing that - having found a data SIM at an apparently reasonable price that would give me a static IP address. The trouble is that the network provider did not implement any firewalling at their end - they simply transmitted raw internet traffic to the 3g router. As soon as you have a public IP address, you will start getting hit by bots all over the world, probing your network to see if they can find vulnerabilities. I administer our company network in my spare time and keep an eye on the firewall logs - we are hit several times per minute by attackers scanning and probing the network - quite often we get hit by storms of scans as the bots try to break in by brute force. Our firewalls are secure and on the end of a professional grade broadband link, so this is a minor annoyance - we lose a bit of bandwidth, but we keep the attackers out.

But... 3G SIMs charge for all traffic transmitted to the router - irrespective of whether or not the firewall lets it through. And the price per megabyte is usually much higher than it is for an ADSL broadband link. I did a back-of-a-fag-packet calculation of the probable bill if my 3G router got hit as hard as our company internet link is every day and the price was scary! I discussed it with the supplier of the SIM and they confirmed that it was an issue and there was no good solution. This problem does not exist with a consumer SIM since you have no public IP address that can be attacked. The malicious traffic does not get beyond the Vodafone/O2/T-Mobile data centre and cannot inflate your bill.
 
That still assumes that your router has at least one public IP address - possibly dynamically assigned. Normal 3G connections implement the NAT in the network infrastructure at Vodafone/O2/T-Mobile and you do not have control over port forwarding.

Techniques like the reverse SSH tunnel rely on some device in the boat making an outgoing connection to a remote server that does have a public IP address and keeping that connection open - then software at the other end can route traffic to the boat.

Yes, though it doesn't have to be kept open; my Pi on the boat fires up a cron job periodically to shift the small amounts of data, connection is to a dynamic DNS rather than IP, so as long as the remote device has a wifi connection the PIs can keep in touch despite IP and physical location changing at both ends.

The OP was connecting on his own LAN so the above is OTT for that scenario.
 
Yes, though it doesn't have to be kept open; my Pi on the boat fires up a cron job periodically to shift the small amounts of data, connection is to a dynamic DNS rather than IP, so as long as the remote device has a wifi connection the PIs can keep in touch despite IP and physical location changing at both ends.

The OP was connecting on his own LAN so the above is OTT for that scenario.

The discussion has diverged a bit from the OP - partly because the OP was a bit ambiguous. The most recent posts were addressing the question of how the 3G connected boat could accept incoming connections, not make the periodic outgoing connection that you describe. My boat does pretty much the same as yours, but there are times when I would like to be able to connect in from home and ask it what the temperature is or to turn on the heating. I know that you can achieve that via things like SMS messages, but there is a (somewhat simplistic) attraction to being able to run a web server on the boat and interrogate it at will!
 
The discussion has diverged a bit from the OP - partly because the OP was a bit ambiguous. The most recent posts were addressing the question of how the 3G connected boat could accept incoming connections, not make the periodic outgoing connection that you describe. My boat does pretty much the same as yours, but there are times when I would like to be able to connect in from home and ask it what the temperature is or to turn on the heating. I know that you can achieve that via things like SMS messages, but there is a (somewhat simplistic) attraction to being able to run a web server on the boat and interrogate it at will!

That's what the reverse tunnel lets you do, but setting that up manually is probably a bit old school (but free) .. however, the IoT (internet of Things) arena is changing rapidly, with new services coming out every week that let you easily connect to remote devices that are behind firewalls, and routers where you don't have permission to port forward .. perfect for your remote web server. Examples are REMOT3.IT and dataplicity
 
That's what the reverse tunnel lets you do, but setting that up manually is probably a bit old school (but free) .. however, the IoT (internet of Things) arena is changing rapidly, with new services coming out every week that let you easily connect to remote devices that are behind firewalls, and routers where you don't have permission to port forward .. perfect for your remote web server. Examples are REMOT3.IT and dataplicity

Mmmm, Dataplicity is interesting - I had toyed with the idea of using web sockets to implement a reverse tunnel type structure ever since they were invented, but the pressures of paid work got in the way!
 
That's what the reverse tunnel lets you do, but setting that up manually is probably a bit old school (but free) .. however, the IoT (internet of Things) arena is changing rapidly, with new services coming out every week that let you easily connect to remote devices that are behind firewalls, and routers where you don't have permission to port forward .. perfect for your remote web server. Examples are REMOT3.IT and dataplicity

Yep, no need for any of that. I've just had MQTT and node-red working over the internet, really easy. Node-red is already install on raspian. Then just send a keywork to a MQTT topic and tell node-red to do whatever you want it to. Easy :cool:

cuhjwu6.png
 
Yep, no need for any of that. I've just had MQTT and node-red working over the internet, really easy. Node-red is already install on raspian. Then just send a keywork to a MQTT topic and tell node-red to do whatever you want it to. Easy :cool:

...

But, in the absence of some kind of reverse tunnel, isn't that once again dependent on the systems in the boat polling out to a message queue? I know that works perfectly well in most cases, but it is not the "always-on" connection into the boat that triggered this thread...
 
But, in the absence of some kind of reverse tunnel, isn't that once again dependent on the systems in the boat polling out to a message queue? I know that works perfectly well in most cases, but it is not the "always-on" connection into the boat that triggered this thread...
Not sure what polling out to a message queue means. MQTT is pretty much instant if yo are on the web, if you want check then get node-red to send a ACK message back.

Edit - simple to get node-red send back a confirmation message.

And isn't mqtt ideal for this sort of thing?
What is MQTT?MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.
 
Last edited:
Not sure what polling out to a message queue means. MQTT is pretty much instant if yo are on the web, if you want check then get node-red to send a ACK message back.

Edit - simple to get node-red send back a confirmation message.

OK, back to basics... The problem with all these IoT remote solutions is the network connection. You can't make an incoming connection to a device if it does not have a public IP address and public IP addresses are like gold dust these days - we've been on the internet for years and have a decent sized block of static IP addresses allocated to us which I guard jealously, but today it is becoming difficult to get any. Most 3G SIMs are on plans which put you behind NATting servers that are out of your control, so there is no way that you can configure the hardware which is under your control to accept and process an incoming connection.

One way to get round that is to set up some kind of reverse tunnel between the remote, 3G connected device and a server that does have a public IP address. Once you've done that, software at both ends can take care of routing and give you the appearance of an incoming connection.

The alternative is to make use of some kind of message queuing system on a publically accessible server and set up the remote IoT device to repeatedly ask the message queue if there is anything for it to do. The trouble with this approach is that, if you want to get anything like the real-time response that goes with a full internet connection, you have to poll the message queue very frequently and this can soak up a low-cost SIM plan quite quickly.
 
The alternative is to make use of some kind of message queuing system on a publically accessible server and set up the remote IoT device to repeatedly ask the message queue if there is anything for it to do. The trouble with this approach is that, if you want to get anything like the real-time response that goes with a full internet connection, you have to poll the message queue very frequently and this can soak up a low-cost SIM plan quite quickly.
As far as i can make out MQTT doesn't poll. Looking at network traffic on the Pi, node-red looked to be sending a 2 byte message occasionaly, maybe MQTT. Hardly going to use up the most frugal data plan. If you don't want to send MQTT messages then set up a node-red MQTT keyword to trigger an update. It just seems not worth the bother to go another route when there software already install to do this using MQTT which was designed exactly for this, low data and low power requirements.
 
As far as i can make out MQTT doesn't poll. Looking at network traffic on the Pi, node-red looked to be sending a 2 byte message occasionaly, maybe MQTT. Hardly going to use up the most frugal data plan. If you don't want to send MQTT messages then set up a node-red MQTT keyword to trigger an update. It just seems not worth the bother to go another route when there software already install to do this using MQTT which was designed exactly for this, low data and low power requirements.

I don't now enough about MQTT or node-red to be sure of disagreeing with you, but it is very difficult to see how a remote IoT device sitting on a 3G router connection can interface with the rest of the world without polling. I am going to have to understand this better for the next system we are designing, so perhaps in a few weeks I'll be in a position to continue this conversation!
 
I don't now enough about MQTT or node-red to be sure of disagreeing with you, but it is very difficult to see how a remote IoT device sitting on a 3G router connection can interface with the rest of the world without polling. I am going to have to understand this better for the next system we are designing, so perhaps in a few weeks I'll be in a position to continue this conversation!
Even if it does poll, after watching the network traffic for a little while UDP port 53 which google says is DNS uses far more than MQTT/Node red so using up too much data doesn't look like an issue, it's next to nothing.
 
It might have diverged somewhat, but I've learnt quite a bit. So keep going ..... ;-)

What are hoping to monitor with the Pi? Anything NMEA or measuring temperature is easy. Voltage little more involved but shouldn't be too complex. Talking to it from anywhere with a web browser should be quite easy to set up as well.
 
What are hoping to monitor with the Pi? Anything NMEA or measuring temperature is easy. Voltage little more involved but shouldn't be too complex. Talking to it from anywhere with a web browser should be quite easy to set up as well.

The main motivation behind this was the midnight phone call from a neighbour to say the bilge alarm was going off on my boat (I was on a non-boating holiday in Lanzarote drinking my Sangria at the time!). So I want to count the times the bilge alarm (and also bilge pumps) have activated.

Once that's done I guess I'll add things as and when. Temperature, both engine room and boat in general (for over winter) would be a good start.
 
Top