How to modify Starlink Mini to run without the built-in WiFi router
(olegkutkov.me)302 points by LorenDB a day ago
302 points by LorenDB a day ago
If they actually figured out which disablement codes can be tricked or circumvented, they wouldn’t share that. I guess it would all depend on how strict Starlink checks and enforces for unauthorised usage. For a US company operating on this scale I wouldn’t be surprised if it’s between very strict to just the basics or on demand.
A commentator here mentioned that Starlink also works in Russia, which it shouldn’t? Maybe some devices delivered to Ukraine can be used in Russia too.
Fascinating that they chose to use modulated board-to-board Ethernet instead of just running RGMII from MAC to MAC.
Ethernet seems far easier to prototype with. There's almost no off the shelf stuff for talking to RGMII whereas Ethernet you can just plug into your laptop for testing. If it's two different teams building things it seems like it would be a lot easier to just agree on Ethernet as the interface and then delay integration testing or release earlier.
RGMII is not some obscure competitor to Ethernet, but rather, Ethernet was designed to be a modular two-part design with "MAC" and "PHY" chips connected via "MII" interface. RGMII is simply the latest version of it.
Many Ethernet-supported SoCs still use various MII style interfaces because it makes more sense to outsource the physical layer to some external chip especially if not everyone is going to use Ethernet.
It's perhaps like the difference between using Thunderbolt vs raw PCIe. You technically shouldn't need Thunderbolt if you're just permanently connecting two things inside a same machine.
Is it smarter to do it proper and make it silicon efficient than just shipping the darn thing ASAP? idk. We'll see.
RGMII requires way more work to run board-to-board (heaps of signals, quite precise length matching, impedance control, etc. on the boards, better board-to-board connectors etc.) and at the end of all that will likely be less robust than just running Ethernet. I'd much rather use SGMII just because it's far fewer signals to match (even if it runs way faster) instead of RGMII.
The chips they're using might already have Ethernet PHYs built in anyway which might also be part of the reason they're using Ethernet.
Assembly isn't free, either an engineer or the PCB fabricator has to put that together. Also the design isn't free and it's certainly not necessarily going to match the behavior of the device on the other side.
But your laptop's Ethernet adapter comes free with your laptop (both in terms of money and waiting to get it since it's already on your desk) and possibly even more importantly you know the laptop manufacturer and users have QAed it for you so it's absolutely going to behave the way you expect which is important when the device you're designing isn't behaving.
A lot of this is pretty POC-y. Agree digital to analog to analog to digital is kinda inefficient, and in the abstract MAC to PHY (which is probably what you mean when you say MAC to MAC) with RGMII is probably better. My off the cuff guess is that it is likely the written-up interface is easier to access or requires less diving into internals. Not sure where the RGMII lines are, and depending on the design of the Starlink mini itself (I am ignorant of this) the lines might have been buried deeper and less accessible, who knows.
That connector is way cheaper than something that could carry an RGMII signal without major reflections. It's probably cheaper in the end to have the extra silicon than a better connector, and I don't think you need the magnetics if you don't need isolation.
RGMII isn't really designed to go board-to-board, fairly high data rates, and ideally all of the signals should be delay matched. That gets a bit trickier when there are two boards involved. Also I would expect EMI/EMC issues.
I know people do that sort of thing for evaluation kits, but it doesn't seem like a good idea for production.
I'm not sure I understand the entire point of the exercise. There's already an RJ45 jack on the Mini, so no need to hack the unit to get access to an Ethernet PHY. And the WiFi router can be turned off via the setup page.
Did they remove support for the Ethernet jack on the Minis available in Ukraine? It looks like it's still present on the WiFi board, next to the power jack.
They may want to make absolutly sure no wifi signal emit from the device. Turning it off in the setup page is definitely not enough.
The wifi chip may emit signal during boot. The device may get accidentally reset in the field. SpaceX may push an update that messes with the settings.
I mean, more power to them, certainly, but WiFi emissions seem like the least of your concerns when you're operating an antenna for satellite comms. There will be no shortage of side lobes at Ku band for anyone who cares to listen.
Cutting down on mass would make sense, though.
It will still draw power with wifi turned off, though much less. The most effective way of reducing the P in swap is to remove the unit entirely
This was great. I wish Starlink actually provided a dish+modem service exactly like this and real IPv4 not CGNAT nonsense. I think they do for business plans which are much more expensive though.
I know exactly what power-constrained application you have in mind, Oleg, and I like it.
Given that the blogger is based in Kiev, Ukraine? Good chance this goes on some sort of long range, Predator-style drone.
I wonder how SL plans vary in Ukraine / for use in Russia. Assuming US-like pricing and limitations, for low speed drones, this would work. The gotcha is that for jet or fast prop drones in the 250-478 kts range requires a very expensive aviation plan assuming it's similar to US plans.
I am not sure - afaik there is a speed limit (assumption of satellite visibility and specific latency?) over which starlink won’t work, right? It can however be useful for getting the internet without announcing yourself to a swarm of drones?
Wouldn’t this give Starlink the ability to track and/or turn off operations in real time?
Russians also use Musk's satellites and might find the information useful.
Also as I understand, satellites do not work over Russian territory so guess where this can be used.
Maybe just for front-line deployment, it would suck to be targeted by a glide bomb because the Russians located some WiFi signal.
Based on recent events I would guess an explosive-laden drone.
Maybe. So? That seems like a decade ago, a lifetime in this industry.
And it's not just vmware. They're predatory, they make Google or Oracle seem like good guys in comparison. They take acquire + squeeze customers to a new level.
If you have any contact with any broadcom product, you'll bleed.
I’m confused by the end. He implies that the “disablement codes” (geoblock, speed violation, etc.) are enforced by the user terminal, meaning they could be circumvented?
> The user terminal itself has no knowledge of service plans, countries, regional, or velocity restrictions – it simply follows commands received from the Starlink satellite
Surely this would be enforced at DHCP time? Or maybe not, since you could get an IP address then start going too fast… is this blog actually a ”wink wink nudge nudge” guide to bypassing Starlink policy restrictions?