Closed jefferypalmer closed 1 year ago
Do you have an always on 'server' behind each terminal? Or possible to have a small device like a raspberry pi on that side? You can just run the tools on a tiny $30 device and push it to the remote server. That's one option.
Alternatively - something that's on my own todolist - talk to starlink.com like the starlink app does and query the data from their servers. They have real time telemetry from each terminal (basics for residential, a lot more for business, not sure which ones you have). But as you know, the app can do a remote connect through starlink's side to get data. I don't think there's a public project for that yet but certainly something worth looking at.
Also, wifi is a pain for a device to collect data from if you need reliability really. I'd ensure each location has the $25 ethernet adapter and just plug it in there. Then it'd pretty much always work. Get something ultra cheap low power with an ethernet jack. Too bad the ethernet adapter doesn't provide PoE out. Then you'd not even need any extra power. Anyway.
As @wcoekaer mentioned, SpaceX does have a remote API that can query data from the dish from the WAN side; however, the Starlink browser app does not use it and the mobile apps access it via HTTPS, so it's not possible to reverse-engineer the protocol by just sniffing the network traffic. It may be possible to examine the app communication with enough hackery on the mobile device side, but I suspect SpaceX would not be happy about someone publishing the results of that.
If this is a commercial application, maybe you could inquire with SpaceX on getting access to their remote APIs. If they are just tunneling the the existing gRPC protocols (which I suspect they are), then it ought to be possible to wire up the tools in this project to them.
Absent that, I don't see any other way than having something running on the LAN side. At a minimum you would need something that can tunnel a TCP connection. Even if your Starlink devices had publicly routeable IP addresses (static or otherwise), that would not be sufficient: that IP address would be the one assigned to the WAN side of the router, not the dish itself.
Run an android emulator for development, matching one of the device profiles Starlink is known to work with. Install the Starlink app. You can then intercept SSL traffic locally and reverse engineer to your heart's content. Obviously, there's a few more steps but it's possible and fairly trivial with the right tools.
So anyway... while I have no doubt it would be possible to emulate what the mobile app is doing for the remote API, this would involve interacting with SpaceX servers, not just the dishes (which are owned by the users in most cases), so I'd be reluctant to publish tools for doing that part unless SpaceX gives explicit permission to interact with those authentication services. I may look into it at some point and add the necessary gRPC-level support for to the tools, anyway, but that wouldn't be sufficient by itself.
@darren1713: I'm not sure what you're looking for at this point. If you want more information on what options are available to pipe the data out from the LAN side, you'll need to provide more information on the network configuration at your field sites: Are you using the Starlink router or bypassing it? Any other servers or routers on the premises (whether they be acting as the LAN/WAN gateway or not)? If you did have to add hardware for this, what are you willing to add?
Or if you have no further questions, please close out this issue.
@sparky8512 thanks for the input and expertise! The input provided does clearly give us the option of a) hardware device behind the dish and b) chat with starlink, so we'll go explore both and see where that leads.
Thanks again! (closing issue)
Fantastic project!
Question for the expert, we have a fleet of terminals in the field and would like to ship / retrieve terminal data to a central location. Ideally something like an AWS server pulling / polling data from remote terminals.
The first (and possibly unsurmountable challenge) is that starlink doesn't utilize a public ip / non-nat option. This may be a complete deal breaker...
Do you know of any mechanism to retrieve terminal data via the "land side"?
One thought is a small/simple wifi based something that pairs with every terminal and simply pipes this data back towards us. Adding more hardware to every install is a pain, but would be a guaranteed option/solution.