6 ms·
Starlink User Terminal Teardown
- walterbell 1y agohttps://web.archive.org/www.darknavy.org/blog/a_first_glimpse_of_the_starlink_user_ternimal/ https://web.archive.org/www.darknavy.org/blog/a_first_glimps...
- latchkey 1y agoDiscussions on similar submissions: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 https://news.ycombinator.com/item?id=25277171 (December 2, 2020 — 158 points, 138 comments)
- londons_explore 1y agoI'm surprised to hear all packets are processed in userspace... If one is doing 1Gbps of traffic which is 100 byte UDP packets, that's a million packets per second you're gonna need to process. A 1Ghz CPU only then gets 1000 cycles to process each one... Very doable, but certainly not easy unless your engineers like hand coding assembly and having to think about every lookup table trick in the book...
- hackernudes 1y ago> Drawing on existing research [3], our preliminary analysis of these programs and configurations suggests that the network stack architecture is somewhat similar to DPDK [4], mainly relying on a user-space C++ program to bypass the kernel for handling network packets. The way it usually works is that the initial packets are handled in software but once the endpoints are established it flows through hardware. Sometimes certain patterns are always handled in software. The software could be a patched kernel or a XDP style kernel bypass. Source: worked peripherally on an Intel Puma cable modem router/gateway that used DPDK or something like it. So I'm not 100% sure, but it is an educated guess.
- riehwvfbk 1y agoWhy would it be any less efficient than processing the packets in the kernel? There's a way to map the hardware queues into userspace (the article talks about the system being DPDK-like). At that point why does it matter that the polling code isn't in the kernel?
- deleted 1y ago[deleted]
- londons_explore 1y agoMost hardware >100Mbps has hardware offload - ie. the hardware is told which packets to send where, and software doesn't touch individual packets (except rare packets like ping).
- Hikikomori 1y agoNot really, you can easily find CPU only routers in every product segment from home routers to enterprise for that speed, even many years ago.
- riehwvfbk 1y agoYes, but you can have GSO and GRO in combination with userspace protocol processing.
- rapsey 1y ago> which is 100 byte UDP packets 100 byte?? Starlink has regular 1500 byte MTU.
- Tepix 1y agoWith RTP traffic you often have lots of small packets.
- tuetuopay 1y agoIn networking, it is the norm to measure performance in packets per second, so with small packets. Unless you're performing DPI or encryption, routers only use the headers to take routing decisions, so whether the payload is 10 bytes or 1000 bytes does not matter: the processing cost will be identical. Only the hardware bandwidth will matter for large packets, though this is rarely the issue (I've hit DDR4 limits once using XDP, and fixed by adding another stick of memory);
- fucker42069 1y ago[dead]
- dilyevsky 1y ago> I'm surprised to hear all packets are processed in userspace... Specifically for cases of forwarding DPDK-style approach can be faster because it will incur fewer buffer copies. Starlink only does 25-200Mbps and average packets are like 7-8x larger so at most you're doing ~36000 PPS which is pretty manageable even on 1Ghz
- _joel 1y agoDoing it in userspace aviods another memcpy, it's much faster.
- jcalvinowens 1y agoModern Linux can do zero-copy network I/O through the kernel, although it requires some effort.
- jwrallie 1y ago> During device initialization, if the system identifies itself as a user terminal, the initialization script automatically writes 41 SSH public keys into /root/.ssh/authorized_keys. Notably, port 22 on the UTA remains open to the local network at all times. Forty-one? So who does not have root access to "your" user terminal?
- ronsor 1y agoYou, of course.
- yonatan8070 1y agoYou, probably. On a more serious note, is this any different from ISPs having a remote management system for ISP provided routers? In terms of privacy, if SpaceX didn't have access to the user terminal, they could still just capture your traffic on the sattelite or the ground stations
- ronsor 1y agoIf they have access to the router, they can capture local network traffic as well as internet traffic.
- arghwhat 1y agoNote that such capture would be quite terrible for performance, not only requiring disabling any hardware offload (a great router might be able to route a few hundred megabit in large packets without offload assuming it doesn't do anything else) to make packets visible for capture, but it would also have to stream the output back to the adversary over the uplink as you would be limited to at most a few gigabytes of local, extremely slow storage, giving no means for local offline analysis... The risk of access to the router is more that they can access your network and touch unprotected and vulnerable things rather than active monitoring.
- db48x 1y agoAnd most of that wouldn’t be useful. We use encryption for almost everything now for a reason. No, wiretaps on modern networks do not rely on backdoors, or even big labeled front doors like SSH, on individual subscriber devices. Instead it is built into the lower level routing. When an ISP gets a warrant (or whatever relevant document your country uses) they configure their routers to tag all of your traffic and mirror it to a server to be recorded. It’s entirely invisible to the subscriber, and highly automated.
- nine_k 1y agoDear author, please consider fixing the typo in the title, it currently reads "Ternimal".
- philipwhiuk 1y agoClassic keming issue.
- jraph 1y agoJust classic letter inversion (the m and the n) :-)
- breppp 1y ago> DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware Anyone has links to resources about how to emulate a firmware that connects to external devices (GPS here), any ready solutions?
- walterbell 1y agohttps://android.googlesource.com/platform/external/qemu/+/2db80f7c1921a6f5d48b998378e3792e16c968a4/README.md https://android.googlesource.com/platform/external/qemu/+/2d... > Android Emulator is downstream from the QEMU emulator. It adds support for booting Android devices, emulates typical Android hardware (OpenGL, GPS, GSM, Sensors) and a GUI interface. The android emulator extends qemu in various ways.
- breppp 1y agoThanks, very interesting as a source for new devices to emulate I was looking for some overall guide of taking a firmware that interacts with the external environment and how to emulate it
- walterbell 1y agoAre you looking for software to? (a) emulate platform (e.g. x86/Arm SoC) running "firmware" = OS/drivers/userspace (b) emulate devices (e.g. MCU, sensors, gateware, firmware) communicating with (a) (c) simulate behavior of OS+userspace software running on (a) (d) other Variations of (a) are available from: QEMU (OSS) Ant Micro Renode (OSS) Arm FVP (commercial) Intel SIMICS (commercial)
- breppp 1y agoa+b for an existing embedded firmware, for testing mostly
- purpleidea 1y agoPost the 41 public keys, we can see which devs use them probably.
- alextousss 1y agoI’m interested in how to secure the firmware from reverse-engineering in a product. Is there somewhere an introduction to the techniques used by SpaceX there?
- wepple 1y agoStep 1 is things like encrypted firmware, so I’d suspect SpaceX does nothing or is reactive - they had debug pins until someone published attacks utilizing them.
- doawoo 1y agoAt a minimum you'd want to encrypt your rootfs using secrets that are hard to extract from secure elements. To go a step further you can employ something like ARM's TrustZone to hide away the sensitive operations (bootloader, decryptions, image signing, etc.) The fact that they could just dump the filesystem tells me there's no protection employed at SpaceX aside from the boot loader mentioned in the article.
- drdaeman 1y agoAs someone who used a bunch of good products with less than great firmwares I would like you to ask to please consider not doing this, unless you have a strong, real and well-analyzed reason. Rather, please consider spending your resources wisely, on something that benefits everyone and makes your product better. For power users, a theoretical ability to modify your product (possibly, in a ways you've never even thought about) can be a valuable benefit. So, unless you're certain to be seriously harmed by this in some way, please consider not wasting your (and your users') time on something of questionable value. Just saying how it looks like from a technical end-user perspective. I'm just really tired and even somewhat depressed of having to hack my devices (lights, cat feeders, now a rowing machine) to make them work properly.
- pabs3 1y agoIf you are using Linux, that would probably lead to GPL violations.
- numpad0 1y agoIs this based on a shared code base with their rockets!? That's cool!
- antidumbass 1y agoNo, it's based on OpenWRT.
- axus 1y agoI'd say even cooler, it's a shared code-base with the satellites; or maybe just a satellite simulator. Something that has to send telemetry.
- account-5 1y agoHow do you even get into doing this sort of thing? Reverse engineering stuff is hard and all trolling is either really expensive, or old and no longer developed; with a few exceptions, I'm sure.
- dfedbeef 1y agoLearn some hardware engineering first? Going to be hard to reverse engineer things if you don't know what components do or how to work with them.
- immibis 1y agoFirst, you have to buy the thing. Second, take it apart. Third, think of ways to break in. Fourth, actually do them. Fifth, swear because you broke it. Usually there's a UART. Apparently Starlink terminals don't have a UART, so the guy took off the eMMC memory chip (which is basically a soldered microSD card) instead.