Hi!

I think ISP block unused IP and ports, or use only necessary for them. Yesterday i tried to connect from other network but it doesn't worked. Today I call to my ISP and he enabled my raspberry IP and port, now Hydrosys working exellent. ISP advidce "If you have default password please change it" :)

So good luck

Hi all

Just wanted to update and thank beauebay for help in solving my issue with remote access, looking back I should have really worked it out myself but as I'm relatively new to anything network I just couldn't see the wood for the trees! So thank you. Merry Xmas all, I look forward to following this tread in the new year!

It looks like this can be tested, if I well understood the steps would be the following:

- get the mobile IP address (e.g. using myip) mobile should not be connected with same wifi network as raspberry.

- from local network, access the raspberry and send a ping to the mobile address (in case the port is also used, no idea)

- try to connect to the raspberry from the mobile

if it works, they are using a simple IP list.

Next step, using mail to send the IP address of the mobile to the hydrosys4?

We could get lucky too, in that the ISP applied a poorly implemented version of Stateful packet inspection. There is a chance they're just logging outbound IP addresses and adding them to the list, as opposed to inspecting the packets for successful 3-way handshakes... If that is the case, a simple ping to your mobile device address should get it added to the list for 2 way communication. If they're combining port info with IP, then we'll need to beacon from the raspberry pi with a source port of 5172, to your mobile device with a destination port of 80/443. If they did a good job, we will need a full 3 way handshake, but that's not usually the case in security..

Thinking out loud here, this is going to be very difficult to track all the various IPs as your mobile device traverses various cell towers, your IP address will change. Same thing if/when you connect to public Wifi, the IP will change. Without the specific IP you will be connecting from, we cannot establish and maintain a session. it's not really feasible to track down every single IP your mobile device could possibly use and leverage those...

What is feasible, is the man in the middle/relay/proxy approach. There is a centralized location where the raspberry pi maintains connection. This location will have a static IP that will never change. In my scenario, I imagine using an AWS server since they're 'in the cloud' and they're relatively cheap, if not freee... So lets stand a host up in AWS. Get that IP address, and have the raspberry pi establish connection with that IP address (AWS land). On the other end, point your mobile android device to forward all hydrosys related activity (port 5172) to the AWS land IP.

This is what's known as a jumpbox. The AWS server should be configured to relay that activity back and forth. Note that, without any security controls the AWS session will be a backdoor into your local network - specifically the raspberry pi. I would setup soem type of firewall, likely based on MAC address to limit the devices that can connect through. Sorry guys, just thinking out loud. It's a little more involved than what I've documented here, but this gets the basic approach communicated.

I'll see if I can play with it today, though I suspect I won't have time.

Very useful info, I'm available to modify the source code if we can elaborate a reasonably simple solution.

The filtering based on stateful packet inspection, where they only allow inbound communications that were first requested as outbound it really a killer of the free access to internet. I'm surprised this practice is allowed to the ISP.

The very design principle of the of the hydrosys4 is not to have a centralized server and let people to directly manage the data without a men in the middle unlike almost all of the other home system.

But this design inherently requires to start a communication from outside. Open for ideas on this point (about the app, not really understood how it could work).

I'd add also another problem that might very easily be included in the ISP filtering. The hydrosys4 uses the http protocol. Implementing the https should not be so difficult, but currently my understanding of the Https private certification is very limited.

If Hydrosys4 could regularily update an external webpage with a button or link back to the hydrosys4 connection, that could work well.

I'm guessing the creation of a mobile app that maintains the connection is too difficult to create. I've seen older web apps the simply use urls to provide the mobile functionality. If that url could maintain the connection and then pass along the info, that would work as well.

Anything really to allow remote contact and monitoring.

We need to send the signal FROM the hydrosys4 to establish the connection.

For this, you will need an address of whom to establish the connection with (your mobile device) IP, or domain name, and then we'll need to modify the sourcecode so that if a session does not exist, create the session (ie. reach out to your mobile device from hydrosys.) Something to that effect. modifying the source is the most straightforward approach, though there might be other options. I haven't even looked at the source as of yet - maybe i'll get some time now that I have the interest.

While most of this is beyond my abilities, I think the approach is the right approach.

It seems that my cameras (reolink) operate on the same principle by first opening the connection from the inside, and then communicating. My undertanding is the team viewer takes the same approach, since you must first start the app, which establishes the connection, and then open the connection using another tool in the software.

What I think is still missing is the ability to send a signal to the hydrosys4 software to open the connection. I'm not sure how that could be established since all the ports to get to it are blocked.

Another possible solution, maybe more involved, and depending on how BELL is filtering, it may not work, but is to take advantage of their stateless connection filtering.

In order for your web request to succeed, there must have already been communication to your external IP establishing a session. You can't just come in from the outside, that looks like a bot enumerating for vulnerablities. Basically, you'll have to make the raspberry pi reach out to your mobile device FIRST, and then from there you two will have established a session and can communicate.

The way I think about this, but I have different extensive experience, is to setup a cronjob to run netcat that establishes a connection with my external device (whatever IP that is). In the end, what I'm speaking of here will require modification to the source code.

Well, so according to bell, they do not appear to block/filter SSH.. so we'll basically want to do what they've setup in this blurb: https://superuser.com/questions/1383373/tunnelling-server-traffic-throuh-ssh-when-port-forwarding-on-network-is-unavaila

That article specifically is utilizing the linux tool socat - but I think that's more because it's converting UDP to TCP traffic. Either way, you WILL need to use some tool to create the tunnel if your router is incapable. Maybe this is an option we can create in the source - an option for traffic tunneling. Maybe an enhancement request @hydrosys4 ? In theory, you should be able to forward on your router. Set it up so that inbound port 22 goes to 192.168.1.172:5172.

You got it. Bell at work!

This certainly is a shady practice and even after literally months of trying to get someone at Bell to admit what they were doing, they never really speak to it.

I have tried all other options in terms of other ISP's. There simply are none that can reach my location at the current moment. Starlink is likely my only hope once they turn on my area. Help me Obi-wan... you are my only hope.

Thank you for providing the links. From what you've seen is there a port or other connection that might allow me to communicate with the Hydrosys rather than through an android box and team viewer?

I very much value your thoughts since you seem to understand the situation better than anyone else has so far...

There it is... They filter port 80 to block customers from running web servers locally... to protect their bandwidth. That's a shady practice right there... That's what this is really about - bandwidth security.

So you'll definitely need to use a different port..

"In addition to protecting bandwidth by preventing customers from running high-traffic web servers, we can stop many destructive worms that spread through security holes in web server software."

Little bit of research does show they filter specific ports. https://www3.bellmts.ca/mts/support/internet/security/blocked+or+restricted+ports

There is also this reddit post: https://www.reddit.com/r/bell/comments/f1179x/exhaustive_list_of_inbound_blocked_ports/

In order for a TCP/IP connection to succeed, there must first be what's known as the three-way handshake which establishes communications both ways. You can't just 'broadcast' data in a stateful session such as TCP/IP. A specified port on any given network is a listening service. If there is a port open on a host, it's listening, and responding, on that port. What's most likely happening with your teamviewer, and even your security cameras, is these connections are being transmitted over ports that are not being blocked.

Its not feasible for your ISP to block all inbound ports - your internet simply would not work in that way...

it's possible they're doing stateful packet inspection, where they only allow inbound communications that were first requested as outbound. In other words, you cannot establish a new session from external - it has to be started from within the local network and then the state of that session is allowed to 'persist'. I'm just not buying the idea that your ISP blocked all inbound ports. At that point they're no longer an ISP, but a firewall, and if they truly did block all port, your internet wouldn't work. Little bit of research says teamviewer uses port 5938, but more importantly says it can be used to make UDP connections. This is stateless networking, in that it sends a packet and forgets it. There doesn't need to be a 2 way handshake, confirmation of packets recieved, etc. If a packet is missed, it simply moves on to the next. That would explain why your teamviewer is 'clunky'.

Teamviewer is using port 5938.

TeamViewer prefers to make outbound TCP and UDP connections over port 5938 – this is the primary port it uses, and TeamViewer performs best using this port. Your security cameras are likely doing the same thing. I don't know what port they operate on, but it has to be over a port your ISP is not blocking...

If you can, you might look into a different ISP.

First order: you have to identify a port that is allowed inbound.

You can do this with a tool like nmap.

Once you identify the allowed inbound ports, you can either 1) hijack that service by hosting your hydrosys service on that port, or 2) relay that inbound port traffic to your hydrosys connection 192.168.1.172:5172

Thanks everyone for the thoughts and suggestions.

These are all good ideas but my network provider (Bell) has blocked all incoming port access (including port 80).

Where I have found some success is by using the team viewer app. I have set up team viewer on a local android box (matricom g-box) and I am able to tunnel into this box remotely. I'm not sure how team viewer manages this but I am able to gain remote access to that box through the team viewer app. Once I have remote access, I am able to access the hyrdosys4 raspberry pi device using the normal procedure. This has worked, but it is so clunky and slow that I have moved away from remote access. It is simply too difficult.

I have managed to set up some remote security cameras and light controls. Both of these apps allow remote access somehow. I am not sure how they are functioning but I can turn on and off devices through their apps as well as view camera feeds through each app. My guess is that they are somehow broadacasting a signal outbound, rather than accepting a signal inbound.

Does anyone know if it might be possible to configure a raspberry pi to communicate in a similar fashion? For example, broadcasting a signal somehow to a remote device, and then connecting to that remote device to send singles inbound?

It would be great to get this working to allow remote access since everything else about the software is excellent, with only this small portion preventing me from using it more robustly...

All suggestions are welcome!

I'm not familiar with teh cloud keys specifically, so I can't speak to those. So, you've got a local unifi network, that when you're connected to, you can access hydrosys4.

But when you're not on the unifi network - for example you're on public wifi at starbucks, you cannot access hydrosys - is this understanding correct?

Have you tried accessing your public IP:port socket?

So instead of 192.168.1.172:5172, try whatever your public IP (whatismyip.com) is plus port 5172. For example, 68.71.122.110:5172. Basically, what's happening here, thinking out loud, when you try to access 192.168, that's a local network connection - it does not go over the internet. It instead search the local network for that service/port - which it's not local unless youre' on the ubiqiti network.

I'm thinking you'll need to hit your public IP and that port in order for it to make it to your house where your router will associate that port/service with the local address 192.168.1.172. You can either do this with a static DNS entry, with whatever name you want - or you can add a static route for the IPs, etc.

Bottom line, you have to get back to your home network and the only way to do that over the internet is with a VPN/Tunnel, or your publicIP.

I've set up Hydrosys4 to irrigate my lawn at a holiday home, eventually I plan to add moisture sensors and go fully automatic but at this stage I've just scheduled the 3 areas using the planner and all works fantastic, so thank you.

Only issue I'm having so far is remote log-in, I run a Unifi network at both properties that run Unifi controller via Cloud key's and I have no issue logging in and updating etc. However I'm only able to access Hydrosys4 when I'm connected directly to that network. I've set up port forwarding in Unifi, tried changing the IP address, switched off port filtering by my ISP and still no access. Any advise welcome as with summer coming I will likely need to add the odd manual watering.

Regards

Technically, the more I think about it, there isn't any difference. All you're doing with IP:Port combination is creating a socket for network sessions. Port 80 is used for web interface data, typically HTTP connections - which you're already using web interface (HTTP) anyway, it will work just the same. it's all TCP/IP packets.. As far as the router, just configure it for port forwarding to port 80 for that address.

Interesting conversation here.

I always wander if using the port 80 could have some side effect or limitations.

How the router should be configured in such case?