blog / research notes | code | music | recipes | zv.is network research lab

Residential internet connections at gigabit (or higher) speeds are increasingly available in some countries, but it isn't always feasible for ISPs to run fiber into homes or apartments. There are a number of different technologies in use:

• DOCSIS 3.1/4.0 - common upgrade path for existing cable networks, fiber run to a nearby node, coaxial for the last < 1km. Rarely offers symmetric speeds, usually has a severely limited upstream capacity.
• G.hn - also commonly delivered over existing coaxial cable, but also used over legacy telephone wiring and powerline extenders. More commonly seen in large apartment buildings or other multi-tenant environments. Conceptually similar to DOCSIS, but uses OFDM for both upstream and downstream channels, while DOCSIS uses OFDMA for upstream in a much smaller spectrum range.
• VDSL2 - an older DSL standard (~2005), still fairly common from ISPs that run fiber to local DSLAMs, but not to residences. Like DOCSIS, it's rarely used with a symmetrical profile. It maxes out around 500 Mbps.
• G.fast - a newer DSL standard (~2015), using up to 7x the spectrum allocation of VDSL2 (up to 212MHz compared to VDSL2's 30MHz). Capable of up to 2 Gbps when deployed with the 212MHz profile on loops < 100m. Supports symmetrical profiles.

CenturyLink (aka Lumen and Quantum Fiber) is a US ISP serving many states and has traditionally provided DSL-based services. In the last decade, they've started offering real FTTP service instead of VDSL2, with surprisingly good performance for a US ISP. Unfortunately they seem to be rather inconsistent regarding FTTP installs - many homes and apartments will get fiber run directly into their premises and an ONT provided, but some residences aren't eligible for mysterious reasons. I recently moved into a new apartment and moved my service, hoping for the same type of install we had at our old place where the installer was more than happy to drill holes into the building and run fiber through our basement.
The neighboring units at my new place visibly had fiber running into them, but when my installer showed up, I was greeted with "Hello, I'm here to install your new DSL service." Considering I ordered their symmetric gigabit plan, I was immediately worried and asked for clarification - was this going to be an FTTdp install or did I get bait-and-switched? It wouldn't be the first time CenturyLink pulled a fast one on me. When I used to live in Las Vegas, they sold me on "symmetrical 1 Gbps service" and then came in with a VDSL2 modem that was barely able to sustain 200 Mbps.
After repeated back and forth ("No, it's fiber." "But why do you need my phone lines, then?") I eventually got a look at the equipment and saw that it was indeed a DSL modem of some sort, manufactured by Casa Networks, a seemingly defunct manufacturer that went bankrupt in mid 2024. The device was a Casa NDD-0305 which turned out to be a G.fast 212a FTTdp modem/ NTD. It's an interesting device - the fiber is indeed run to the premises, but terminated outdoors on what's called a DPU which is then connected over the existing copper telephone wiring (a single pair) to the modem inside the building. The modem powers the DPU using the same single telephone pair.

Anyway, fast forward several hours (the installer had to call out a bucket lift team, since apparently an earlier appointment to connect my drop to the GPON splitter up on the pole was never completed) and the service is finally up and running. I hooked up my router, dropped the old PPPoE configuration from the interface (CenturyLink's legacy service, while seemingly ethernet all the way, still required PPPoE authentication) and immediately got an IP assigned. Surprisingly, performance was actually pretty good - solid 980 Mbps both downstream and upstream when running unidirectional tests, but the G.fast limitations became evident when trying a bidirectional test, maxing out around ~1.5 Gbps aggregate, about 900 Mbps downstream and 600 Mbps upstream. It's still significantly better than what Comcast (the only other option in the area) could offer, so I was happy.

A few weeks later while in a meeting at work, the call dropped and I noticed my SSH sessions were frozen. The modem showed no sync, but the DPU was powered. Long story short, the GPON splitter I was connected to suffered some failure and the upstream link was at a puny -38dBm, taking down 8 customers on our block. It took nearly 2 weeks for Quantum to even send somebody out to fix it, and in the end, our connectivity was only restored because the original installer came out on his own time to swap my uplink over to a working splitter. Props to Quantum's installers, shame on their customer service and repair teams.

The Casa NDD-0305 is truly a transparent network bridge - it takes G.fast over copper in, and has a single ethernet handoff. There's no management interface, hell, it doesn't even have an IP assigned to it. When the G.fast link is down, it shuts the ethernet port as well, so there's absolutely no diagnostics available outside of "is the sync light lit?". Since my home network is completely tunneled across the zv.is network lab I wanted some better details on connectivity status and easier fault detection. With no IP address assigned to the modem at all, the next best option was to crack it open and see if there was a serial console on the device. I found a used modem on eBay for $10 and ordered it, as a sacrificial lamb.

The insides are fairly simple by historical DSL modem standards. There are two PCBs connected by two sets of pin headers - one that contains the power supply, a small MCU (NXP/Freescale MKE02Z64, a Cortex-M0+, probably for power sequencing?), the RJ11/phone jack connector, and the power delivery for the DPU. It also looks like at least part of the analog frontend is on this board. The PCB silkscreen is nicely labeled, with each logical section clearly marked and labeled. The board I have is labeled NDD_030X_ETSI REV 1.20 EPCB-00107

The upper board is simpler, but holds all of the "smarts" of the device. The rear side holds the RJ45 jack and its magnetics, a reset button, and the flash for the main SoC. The flash appears to be a Macronix MX30LF1G18AC-TI, a 1Gbit/128MiB SLC NAND flash chip. There's also two pin headers that connect to the lower board, a 1x2 header labeled J4 and a 2x5 header labeled J5. This board is labeled 56XX15-012

The top side of the upper board has a heatsink, which when removed reveals a Winbond W632GG6MB-12 2Gbit/256MiB DDR3 SDRAM chip, a SoC labeled S0243N03 / SLMQ2, which is an Intel GRX350 SoC (previously Lantiq, at one point Intel, now MaxLinear, but this SoC has an Intel S-Spec on it) and a completely unmarked RF can, which likely contains a MaxLinear VRX619 G.fast/xDSL transceiver. There are also a few support chips: a Microchip LE87285 G.fast/xDSL line driver (labeled D1_FAST) and a MaxLinear VLD600A1VI which appears to be part of the VRX619 chipset (labeled D1_DSL).
Just below the SoC there's a 2x2 set of unpopulated vias labeled J2 which is connected to the SoC's UART. The pinout (from the rear side of the board, with the flash chip at the top and the yellow RJ45 at the left): [ TX ] [ RX ] [ GND? ] [ 3V3 ]
The bottom left pad seemed to be ground, but I wasn't able to get a clear connection to the UART when using it, so I connected a wire to C346 on the left, which appears to be an unpopulated space for a capacitor. Yes, those are solid core wires I pulled out of a piece of CAT5. Yes, I need some better fly leads.

The SoC's label SLMQ2 ended up being an Intel S-Spec as I originally suspected, as the console confirmed it was a GRX350. The modem is running kernel 4.9.109 built on 2020-07-28, and the SoC appears to be a quad-core MIPS CPU at 600MHz. Three of the cores are available in Linux, while the fourth appears to be dedicated to something called "MPEFW". Intel doesn't seem to have really touched the software running on this device, as almost everything is still labeled Lantiq. The early boot logs curiously list the machine identifier as a Netcomm NDD-0300, despite being physically badged as a Casa Networks device. The NDD-0300 seems to be a full blown modem+router+WAP combo, so not quite the same device, but clearly the same platform.
The VRX619 G.fast transceiver connects to the GRX350 via PCIe and loads its own firmware at boot time, so it really does seem like the SoC is just acting as a controller and bridging the ethernet to the G.fast uplink. I saw no evidence of any management interface being configured, and unfortunately, neither U-Boot and Linux are configured to expose a shell, so I couldn't break into it to poke around. There don't seem to be any pins on the PCB that might act as a boot device selector, and the reset switch seems to just be connected to a GPIO that triggers a script to reset the device, it had no effect when pressed during the early boot process.
The full UART log is available here.

Given that Casa seems completely defunct and NetComm (also recently sold to another company) doesn't even list the product on their site, the only chance to peek at the firmware would be to pull the flash chip and dump it, which I unfortunately don't have the tools nor skills to do. If anyone is interested in doing this, get in touch and I'll gladly ship you the sacrificial modem. Update 2025-07-07: @mxshift@social.treehouse.systems offered to pull the flash and dump it. I'll be making a new post in the near future covering booting the image in qemu and making the modifications to get it on the network with sshd available.
It's a bit sad considering the firmware appears to be at least partially based on LEDE and indeed many of the Lantiq drivers are in the OpenWRT/LEDE source tree, customizing the firmware to expose a diagnostics interface doesn't seem like an unreachable goal, but without any network interface, touching the flash directly is too much to ask for most folks.