Help for shell on zte modem fastweb

Hardware Questions and Recommendations
1

Full report — Reverse Engineering Fastweb NeXXt One (ZTE ZXHN H1620P)

Device

  • Model: ZTE ZXHN H1620P ("NeXXt One", Fastweb)

  • Wi-Fi 6, VDSL2/xDSL gateway

  • Obtained without an active Fastweb contract

Real hardware identity (key discovery of the evening)

The chip was always labeled "TC3162" in the boot logs, but after a thorough search:

  • "TC3162" is not the name of a specific chip — it is the name of a userland interface (/proc/tc3162/...) recycled by EcoNet/TrendChip on different generations of SoC over time. Confirmed by comparing with a similar project (Repo GitHub q3k/vraytekdigor), where the same "TC3162" appeared on a physically different chip (EN751627).

  • The real chip is an EcoNet EN7517, confirmed by the string in the logs: ! Parsing EN7517 MAC addr.

  • Core architecture: NDS32 (Andes Technology), not MIPS — confirmed by: CPU: NDS32 N1068, AndesCore ID(wb), CPU_VER 0x1a400017.

  • This is IMPORTANT: the active OpenWRT project for EcoNet chip (target "en75", developer Caleb James DeLisle, PR accepted in the upstream Linux kernel in June 2025) supports only the MIPS family:

  • EN751221 (34Kc MIPS): EN7512, EN7513, EN7521, EN7526

  • EN751627 (1004Kc MIPS): EN7516, EN7527, EN7561

  • **EN7517 with NDS32 core does not fall into any of these families. ** It is an older/different chip line, probably a previous generation of SoC ADSL/VDSL Trendchip based on Andes NDS32 IP license, not MIPS. No existing public porting work concerns him.

Session history

Step 1 — Hardware identification and first UART access

  • Opened the case, identified two separate groups of 4 unpopulated pins on the board:

  • Group 1: near the smallest chip (network coprocessor/DSL)

  • Group 2: near the main SoC (marked "PB1"), 4 cores

  • With multimeter (continuity + DC voltage), pin identified GND, VCC, TX, RX on both groups, by trial and error (including various false alarms for low multimeter battery, unstable contacts, etc.)

  • First success: UART working on Group 1, baud rate 115200, with full boot log up to root shell (/ #), including BusyBox v1.26.2, filesystem squashfs, DSL/VDSL modules.

Phase 2 — Discovery of the second SoC and CPU freeze

  • Fixed pins welded also on Group 2 (Main application SoC, 4 cores, DDR4 2133Mbps, CPU freq 1100MHz).

  • Group 2 boot log shows: DDR4 initialization, SPI NAND reading, kernel CRC verification (always valid, 0x9e9fdc40), then:


First spin (x4)

CPUID:0 cpunoline 1 nucpus 4 try wake up secondary cpu from rom.

CPUID:1 wake up from rom.

CPUID:2 wake up from rom.

CPUID:3 wake up from rom.

CPU 1 power on

Cpu 1 has been powered on

**The boot always crashes here. ** CPU1 wakes up successfully, but the system never proceeds to CPU2/3, nor to the full Linux kernel. It is not a loop with automatic restart: it is a real permanent freeze, verified by waiting even 2+ minutes without changes. It unlocks only with manual power-cycle.

Phase 3 — Exclusion checks on CPU2 freeze

Tested and excluded as a cause:

  1. UART reading tool: exact same freeze confirmed with 3 different tools — USB-serial adapter style CP2102, ESP32 naked (permanent reset via EN-GND jumper), Freenove Uno-style board with integrated ESP32.

  2. Power Supply: no voltage drop observed on VDC (3.3V) at the exact moment of freeze.

  3. Wi-Fi antennas: Disconnect and reconnect the two U.FL cables (labeled "H1620P/V.01, 2.4/5.8G", ports 1 and 2) — no change in behavior.

  4. Pin combinations: tested various TX/RX assignments on Group 2 — the freeze always occurs in the same phase (secondary CPU wake-up), with minimal variation in the exact point (sometimes it stops immediately after "CPUID:3 wake up from rom", other times after "cpu 1 has been powered on" — plausibly due to small variability/measurement noise, not really different behavior).

  5. Bootloader interrupt tries: Ctrl+C spam and Enter during various boot points — no effect, the system does not respond to input at that stage (probable low-level blocking firmware, not a real interactive prompt).

Phase 4 — Causal relationship between the two SoCs (important discovery)

Key observation: the behavior of Group 1 has changed during the evening:

  • Before working on Group 2, Group 1 always and steadily arrived at the full shell.

  • After starting the tests on Group 2 (freeze CPU), Group 1 started to stop in a loop on repeated [iNIC_client]resend notify, requiring to physically disconnect and reconnect the UART cables several times before "unlocking" and proceeding up to the shell.

Assumption (not demonstrated but consistent with all observations): The network coprocessor (Group 1) is waiting for a response/handshake from the application SoC (Group 2) as part of its startup. If the application SoC is stuck in the CPU2 freeze, the network coprocessor remains on hold, repeating "resend notify" (literally: "re-send notification") in a loop. The physical disturbance of disconnecting/reattaching UART pins could generate electrical transitions that the firmware interprets as unlocking/timeout, forcing an alternative path that still reaches the shell (but with the production script "The test lab" starting automatically, see below).

Important note: despite these problems on the two sub-systems monitored via UART, the web administration panel of the router (stock Fastweb/ZTE) always remains reachable and working via Ethernet, with Wi-Fi/LAN/DSL operating — indicating that there is an operating path that does not require the completion of the multi-core boot on the application SoC.

Step 5 — Factory testing firmware discovery

Once the Group 1 shell is reached, it is observed that the system runs automatically (not on interactive request) a script that defines itself:


/ # The test lab:55

Lpr_msg_send on

AELEM on

Followed by repeated configuration commands (wan tcif set sysserno, wan tcif set version, wan adsl reset, reading a serial number byte byte in system_sirial_no_eoc[N]).

This is almost certainly a remnant of factory testing/production firmware, never replaced with the final consumer image on this specific example (compatible with the assumption that the device comes from a batch of tests or refurbished).

Feiled attempts to get a stable interactive shell while this script rotates:

  • Injection of commands (cat /proc/mtd) via screen -X stuff, both manually and with automatic spam script every 0.5-1 second

  • Attempts to interrupt with Ctrl+C (character \x03) spammed

  • Full session recording with script to capture any responses — never appeared output of the injected command

Conclusion: the "test lab" script seems to be launched directly from the init process in a way that does not really read the user's interactive stdin (or has redirected it elsewhere), making it impossible to intercept it so far with the available tools (no JTAG, no oscilloscope).

Technical data collected (useful for anyone working on this chip)

Bootloader/kernel command line (Group 1):


Root=/dev/mtdblock1 ro console=ttyS0,115200n8 earlycon init=/sbin/init ethaddr=000aabb012345 qdma_init=3b

Kernel:


Linux version 3.18.21 (chuxiaoli@host-10-57-82-136) (gcc version 4.9.4 (2018-05-03_nds32le-linux-uclibc-v3))

CPU: NDS32 N1068, AndesCore ID(wb), CPU_VER 0x1a400017(id 26, rev 64, cfg 23)

MTD partitions created (identical names, probably the same physical offset with software overlay):


Creating 4 MTD partitions on "tc3162":

0x000000000000-0x0000002bc000 : "kernel"

0x000000000000-0x0000002bc000 : "rootfs"

0x000000000000-0x0000002bc000 : "tclinux"

0x0000002b5000-0x0000002bc000 : "reservearea"

MAC Ethernet: E0:B6:68:D7:35:C5

Serial device (from script test lab): ZTEEGAFPAT03041_H1620P_V2.0.0_R

DSL firmware version: V5.16.17.8 / 65.16.17.7517

Init system: BusyBox v1.26.2 (2021-11-17 17:44:24 CST)

Where to look for help (verified tonight)

  1. OpenWrt Forum — specific existing thread: forum.openwrt.org/t/support-for-trendchip-tc3162p2-soc/61421 — thread from 2020-2022, never solved, last question ("did you manage to get OpenWRT to work?") Without an answer. **Account awaiting approval to post. **

  2. OpenWrt Forum — active thread on EcoNet/Zyxel PMG5617GA: forum.openwrt.org/t/openwrt-support-for-zyxel-pmg5617ga-and-econet-socs-first-gpon-support/144231 — active community, but focused on MIPS family (EN7512/13/21/26), not NDS32. Useful however to ask questions, the developers there have general experience with EcoNet.

  3. Mailing list openwrt-devel: developer Caleb James DeLisle active on EcoNet porting, responded to recent technical discussions (June 2025) — contactable there for a specific question about multi-core freeze, although his work concerns MIPS not NDS32.

  4. No dedicated Discord found for EcoNet/TC3162/NDS32 specifically — only generic hardware hacking/cybersecurity communities, not targeted.

  5. Repository GitHub reference: q3k/vraytekdigor (similar context, different chip but same "false clue" TC3162), project econet-linux.pkt.wiki (general documentation EcoNet family, although it does not cover NDS32).

Final status and suggested next steps

  1. Publish the full report on the OpenWrt forum as soon as the account is approved, clearly specifying that the real chip is EN7517 with NDS32 core, not MIPS — to avoid confusion with existing MIPS porting projects.

  2. Try to contact Caleb James DeLisle (active EcoNet developer) asking if he has ever encountered NDS32 variants of the EcoNet family, and if he recognizes the multi-core freeze pattern.

  3. If you want to continue hardware debugging: you would need a logical analyzer (10-20€) to capture UART signals with real temporal accuracy (instead of the multimeter), and ideally a NDS32 compatible JTAG debugger (Andes sells "AICE", with OpenOCD support) to stop the CPU during the freeze and inspect the registers — estimated investment 50-150€, not available at the date of this report.

  4. The complete dump of the NAND flash (kernel, rootfs, tclinux) remains the most valuable subsequent goal, but requires stable shell access that so far has not been obtained interactively (passive boot log only).

*Report compiled at the end of a hardware reverse engineering session, with multimeter testing, three different UART tools, and public documentation research on the EcoNet EN7517/TC3162 chipset. *

2

Looks like NDS32 is not supported in mainline linux anymore due to lack of active maintainers / users.

3

EN7517 is very likely not the main SoC. EN7517 is Airoha's solution for adding DSL support to newer SoCs. Previously they used full-fledged MIPS SoCs like EN7516 for that, but I guess there were enough customers still requiring DSL, so they sell EN7517 as a way to add DSL support to their more modern SoCs. I don't think it makes much sense to focus on this part as long as there is no DSL driver for the MIPS SoCs. Why they switched to NDS32 for this stripped down DSL-SoC, I do not know either. There should be a userspace daemon on the main SoC talking to the EN7517. All the logic for configuring the DSL happens by communication with EN7517. The fact that it is running Linux can be considered an implementation detail from the main-SoCs view.

So, I would suggest you to focus on the main SoC instead. Do you have pictures of the PCB with heatsinks removed? Do you have full UART logs of the main SoC booting?