SpaceX shutdown part of Dishys API because of me (and others)
Well...that happened...I really think they shutdown part of Dishys gRPC API because of me (and other people) using it, let me explain why i think this and what happened:
Dishy (user terminal for Starlink) has a gRPC based API that offers different methods to query data from it. This API is also used by the web interface as well as the app to interact with the dish by a normal Starlink User. SpaceX doesn't offer any documentation about it, but in the past months, many people had a look at their Starlink hardware and were able to find out all functions that are available. Some are used by the app as well, others are things that are not used by any Consumer software from Starlink. One of these "secret" methods is the so called "dishGetContext" endpoint, this is the API they shutdown with the last firmware updates...possible because of me and others using it.
What did i use the Api for?
I created a website called Starlinkstatus.space that collects Starlink statistics from people that run a script every few minutes on a Raspberry Pi or linux PC. It pings different servers, makes a speedtest and sends that data to my server, the data then gets shared and analysed on the website to get a bigger picture about Starlinks performance around the world. Pings and speedtest are good, but wouldn't it be nice to have data on there that comes directly from Dishy? Well, that's when i started playing with the API and after a bit of a hassle with gRPC (never heard about that before to be honest) i updated my script, backend and website to work with telemetry from Dishy as a nice addition to the other data. The API methods i used where "getStatus", that is also used by the Starlink app, as well as the before mentioned dishGetContext endpoint.
The strange Context Method
At first the data that is returned looks very similar to the getStatus result, but it already is a bit unusual that it reports partly the exact same data getStatus does, this doesn't make sense in such an API. Things like DeviceInfo, DeviceState and some obstruction infos are exactly the same, on the other hand there are some really interesting fields in there that are nice to have and analyse.
Fields like the CellID, that shows in which cell Dishy is located, are cool to maybe analyse but much more interesting to me where secondsToSlotEnd, initalSatelliteId and initialGatewayId. After watching a bit of live data, i was able to confirm that SpaceX uses a 15s slot interval, so every 15s Dishy gets another communication slot assigned. So in theory the path/route (satellite, ground station, POP) your Internet connection takes could change every 15 Seconds! Fascinating, isn't it?
And now comes the strange part of the API...everything does what the name says...as i know it from APIs...but then i realised that the initial satellite/gatewayId do in fact change...even every 15s sometimes...what the? After a quick check of some satellite orbits, i was able to confirm that the Values are in fact live! After i knew that, i removed the data from my Starlinkstatus website, just in case it would be a problem for SpaceX (they get sued for anything competitors can think of).
Why that could be a Problem
Many people, especially competitors of Starlink, could try and use that data to do things against SpaceX, what would be bad for all Starlink users. I can think of many things that could get them in trouble, even when they are not doing anything out of FCC guidelines. For example, i was able to observe that satellites that are not in their final orbit were already used by consumer Dishys i had access to. They are allowed to do this, but if someone has a problem with that, they could sue SpaceX and potentially make them shutdown some satellites until it is sorted out. You could also triangulate ground stations with data from enough Dishys etc. what can all be used against them, so i can understand why they don't want anyone knowing when Dishy is connected to which ground station and satellite.
When they shutdown dishGetContext
The mentioned API endpoint looks to me like something they use internally for testing or similar things, and they just missed closing it down. Of course, Dishy will phone home to the SpaceX HQ and send back information to improve the user's experience and fix bugs. Part of that data could be a log of the gRPC API requests. That's why i think they shutdown the context API because of me and others using it in the past weeks / days all around the world. For months only a handful of people used that API on their local dashboards or other things, now where many were using it they seem to have noticed that it is not only used by a few interns at SpaceX but people all over the world :)
About a week after users of Starlinkstatus and some other people were using the context API more and more, a new firmware update appeared (first seen: 25.06.2021) that closed down the API. Starlink updates are not sent to every Dishy at the same time, so i was able to see that every day a couple of Dishys stopped reporting the context data to Starlinkstatus until all stations where updated after a few days to "4990ce8d-5028-4e51-a015-e9ab1b1ebe1a.uterm.release" or newer.
(title Image: Netvault.net.au)
{{ 'Comments (%count%)' | trans {count:count} }}
{{ 'Comments are closed.' | trans }}