Identify how to communicate with the openag_brain behind a firewall

[rwdavis513]

We could tunnel our (bi-directional) communication to a service we set up on a static domain name. pi <-> service.openagfarm.com. Look at existing options.

[sp4ghet]

https://wiki.openag.media.mit.edu/contributors/rikuo/ngrok

I've been looking into ngrok after @novemberalpha 's post on the matter.

[novemberalpha]

Ya ngrok is running on both of my machines. I need to figure out why the DB won't connect to the UI. I suspect that there's a port hardcoded and ngrok obfuscates ports. Otherwise, firewalls are no problem. I haven't tested on proxy-ed environments tho.

Here's the gist

[sp4ghet]

the UI hardcodes 5984 but it would be an easy fix to route something over nginx. ngrok has something like compose files that you can use to open multiple ports as well. I'm thinking if we use the paid plan we can link the ports to subdomains and other fancy stuff.

[novemberalpha]

I dug into the code for openag_ui and the only spot I found the port hardcoded was in the openag-config.json and since root_url is set to null that's not used. window.location.origin returns full root url WITH port so that's what the app appears to use. The grunt couch deploy seems to need localhost:5984 but I think that's just so it can upload and it's not liking when I tell it to go out to ngrok and back.

I removed it from the openag_config.json and the app works great remotely. It doesn't, however, work on the local network. I wonder why the connection isn't consuming the port from the window.location.origin? More digging required.

Thanks!

[sp4ghet]

https://github.com/fatedier/frp#what-can-i-do-with-frp

This looks much more promising and is open source..

[rwdavis513]

Here's a solution using reverse-ssh-tunnels. https://github.com/rwdavis513/openag_brain/blob/auto_pfc_registration/scripts/register_pfc.py

The proposed flow for registering a PFC automatically with the cloud is:

1. User Registers to the cloud and receives a new PFC_name and PFC_password
2. User Connects to PFC broadcasted wifi
3. On the PFC webpage, user enters local wifi information and PFC_name and PFC_password
4. PFC: Connects to Cloud backend providing the PFC_name and PFC_password a. Backend associates PFC with user account b. Return ssh tunnel info

This would allow for people to connect to the pfc using the cloud software entirely without requiring ssh into the pfc or the pfc's ui.

[sp4ghet]

I don't really feel comfortable with treating PFCs as "slaves" to the cloud, which is going to be owned by a private entity. (I assume it's Fenome running openag_cloud for now) and would rather look into something which treats PFCs as hosts/peers. This way we can more easily just host a version of openag_ui that works on the PFC and access from anywhere, or use the API over a cloud service. The more we can keep on the device the more flexible it gets.

I'd be more comfortable with something that does NAT traversal like in console gaming or other p2p applications.