# RTL960x, the GPON ONT firmware project, and what happens on a live PON > Anime4000/RTL960x documents how to re-flash Realtek based GPON ONT sticks so they can register on an OLT you control. It is a reverse engineering and documentation project, and it comes with a safety notice that the hardware can take down a whole fiber segment. **Anime4000/RTL960x** — Hacking & Reverse Engineering RTL960x-based xPON ONTs to suit your OLT - Repository: https://github.com/Anime4000/RTL960x - Stars: 1,061 · Forks: 158 - Language: Classic ASP - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/anime4000-rtl960x ## A documentation project for Realtek ONT hardware, not a firmware image The stated goal is narrow and honest: the repository aims to document and demystify the RTL960x platform for the global xPON community. It is not selling a product, and it is not a fork of a vendor firmware tree. What it holds is accumulated knowledge about a specific chip family, the sticks built on it, and the procedures that make those sticks work with an OLT. That audience is narrow too. The people who benefit are xPON experimenters, homelab operators with their own optical line termination equipment, and vendors who need to know why a cheap SFP ONT will not register. The topics listed for the repository run from firmware and busybox to GPON stick hardware, Realtek and Lantiq SoCs, and ONU and OLT terms, which is the vocabulary you would expect from a field that mixes optics with embedded Linux. The community structure is worth noting because it explains where work is meant to happen. Structured development discussions stay on the main GitHub repositories, while a forum, the Pururin Collective Forum, is where non-neutral discussion, ISP specific tweaks and informal experiment logs live. A contributor documenting a strange boot log is expected in the forum; a contributor proposing a repeatable procedure belongs in the repository. The repository itself has no GitHub releases, so there is no versioned artifact to download and pin. The content is the documentation, the firmware folders and the tools. ## The device matrix that decides whether your stick is even a candidate Before any procedure matters, there is a table that decides everything: which stick, which SoC, how much NAND, which mode, and what state the vendor's firmware is in. The RTL9601x section lists the SFP sticks the project works with. The VSOL V2801F runs an RTL9601CI with 8MiB of NAND and supports both VEIP and PPTP modes, with 4-port EthUni forced on and 2.5Gb marked as modified. The T&W TWCGPON657 is also an RTL9601CI with 16MiB, and its 4-port EthUni links to a specific firmware tarball, version V1.9.0-240204, in the Firmware folder. The UFiber Instant is an RTL9601CI with 8MiB in PPTP mode only, with LAN 1 for the EthUni and 2.5Gb marked as not present. The DFP-34X-2C2 in A and UPC variants is an RTL9601D with 8MiB, supports VEIP and PPTP, offers selective 4-port EthUni and lists 2.5Gb as supported. The Nokia G-010S-Q entry is an RTL9601CI with 16MiB in PPTP mode, and its final column is a question mark rather than a check mark, so its status is genuinely unknown. The note under that table is the most consequential line in the document. The OEM has no plan to release new firmware, and the effort reaches as far as a private community build at V2.0, which the note says is illegal to release publicly. That single sentence is the reason this repository exists and the reason it will keep existing in some form. ## Four architectures, two box shapes, one last of the line chips The family table widens the picture beyond the sticks people actually buy. The SoCs are grouped by CPU architecture and by type, and the naming maps almost directly onto product generation. The Lexra parts are the older, first generation group. The RTL9601B is described as the first generation GPON ONT on SFP with 1G only. The RTL9601C1 is the second generation, offering 1G and partial 2.5G. The RTL9601D is the third generation, with stable 2.5G, and it is the chip in the DFP-34X-2C2 entry. The RTL9602C sits in the same architecture but is only available in box form factor, so it is not something you will find in an SFP cage. The MIPS parts are the all in one units. The RTL9603C is a single core at 900MHz, and the RTL9607C moves to two cores at 1.15Ghz and adds USB and POTS. The ARM64 entries continue the line: the RTL9607DQ has four cores at 1GHz with optional 2.5GbE and POTS, and the RTL9607F has two cores at 1GHz with optional USB and POTS. The types in the table are SFU and SFU/HGU, so the same silicon appears both as a plain bridge and as a router capable of serving subscribers locally. That is the architectural difference that matters when you decide whether a given stick can be reconfigured for your network, and it is why the type column, not the generation number, is the field to look at first. ## Lantiq and ZTE sticks: the used option with narrower OLT support A second table covers GPON ONTs that are not Realtek based, and it is where the project's advice gets blunt. The DFP-34X-2C2 appears again here, this time with a ZTE SoC and a question mark for NAND, with the UNI column reading no 4-port EthUni and no OMCI edit. The Huawei MA5671a and the Nokia G-010S-P and G-010S-A are all Lantiq parts with 16MiB of NAND, running PPTP or VEIP with LAN 1 for the EthUni. Every entry in this table carries a check mark in the final column. The note attached to the table is the useful part: Lantiq SFP units are used or second hand, they have limited OLT support, and some OLT sticks reject them outright. So even a device that appears in the support matrix may still fail to register, for reasons that have nothing to do with your configuration. This is where a buyer should slow down. A Lantiq stick that is cheap because it is second hand is a poor candidate for this project compared with a Realtek part that has a documented firmware folder, because the failure mode is not something the documentation here can walk you through. A third table covers 10G xPON ONU hardware, listing the Hisense LTF7263-BH+ and LTF7267-BH+ and the Maxlinear PRX126, with most fields marked unknown. For that class of hardware the project points elsewhere, to the CA8271x XGS-PON stick work and to the 8311 repository for the Maxlinear line. ## Reading and writing flash: flash get, flash set, and three partitions to back up The core mechanism of the project is direct access to the ONT's flash storage, and the documentation names the two commands that do it. ```bash flash get flash set ``` Those two operations are the whole interface: one reads values out of the ONT's flash, the other writes them back, and the guide for them lives in Docs/FLASH_GETSET_INFO.md. That document is also where the individual keys are described, including the xPON Model Id field, which is limited to four ASCII characters, and the LAN SDS Mode setting, which determines how the Ethernet side is presented. Before any write, the repository points you at a backup guide for the env, env2 and config partitions, contributed in a discussions thread. The partition names are the significant part: the environment and configuration partitions hold the identity of the unit, and an ONT that cannot be read back is an ONT that cannot be restored. The related documentation is spread across the Docs folder rather than collected in one place. Docs/StickSetup.md covers setting up an xPON ONU SFP stick, Docs/Stock_ONU.md covers cloning stock ONU OMCI information, Docs/ISP_specific_configuration.md covers operator specific configuration, Docs/TroubleshootSetup.md covers the failure cases, and Docs/2.5Gb.md covers 2.5GbE compatibility, including a guide for making the work on the Intel 82599es. ## Getting an ONT to register: OMCI cloning and operator specific settings A GPON ONU does not simply power up and join the network. It presents itself to the OLT, and the OLT decides whether to serve it. The project treats that handshake as the interesting part, and the documentation for it is spread across a small number of files. Cloning stock ONU OMCI information is the procedure in Docs/Stock_ONU.md, and a note in the guide points to an issue comment for Fiberhome users, with the warning that some of those units sit under a Fiberhome OLT standard rather than a universal one. That distinction decides whether a cloned identity is even valid for the OLT in front of you. Operator specific configuration has its own file, and a troubleshooting file exists for the cases where registration does not happen. Between them they cover the whole registration path: the setup file for the initial procedure, the OMCI file for the identity, the operator file for the values that must match the network, and the troubleshooting file for when the first three do not settle it. The xPON Model Id key is the concrete lever here, capped at four ASCII characters, and it is one of the values in the flash key documentation rather than something set through a menu. That is the mechanism: an SFP ONT with no vendor identity of its own is given one that the OLT will accept, through the same flash write path used for the LAN SDS Mode and other keys. The 2.5GbE question is separate and has its own file, plus a third party guide on the Intel 82599es for the host side of the link. ## The safety notice is a technical constraint, not a disclaimer The repository carries a safety notice, and it is worth reading as engineering information rather than legal boilerplate, because the failure modes it lists are network level rather than device level. Custom GPON SFP ONTs operate outside standard ISP-controlled environments. The notice warns that improper configuration or non-compliant behavior can destabilize the optical network, and that a single faulty ONU may trigger a PON-wide disruption affecting multiple subscribers on the same fiber split. The listed operational risks are PON blackout events through broken upstream synchronization, ISP enforcement actions such as immediate disconnection, blacklisting or penalties, and unpredictable stability where custom firmware leads to intermittent connectivity or complete service failure. This is the real constraint on the project and it is not a software engineering problem you can debug. A broken configuration on a lab OLT is a broken configuration on a live PON. There is no isolation between your device and the other subscribers on the same split, and the failure is measured in the operator's network rather than in your own. The project also states that experimentation is performed at your own risk, that contributor support is voluntary, limited and not guaranteed, and that the goal is open knowledge and interoperability rather than deployment. Those lines are the difference between this being a research platform and being a consumer product, and the wording leaves no room for the second reading. ## Health reporting, licensing, and what the last commit means for you The operational side of running a custom ONT is monitoring, and the repository has community written tooling for it. Health reporting through Telegram is covered in two places: an issue thread with a MikroTik script by one contributor, and a discussion thread with a Linux bash script by another, both sending reports through a Telegram bot. A Grafana based option is linked as well. A custom ONT that is online for hours between visits is exactly the kind of device that benefits from reporting. The top level layout reflects that the project is documentation plus artifacts rather than a single piece of software: a Docs folder, a Firmware folder, separate Firmware_Mod and Firmware_Router folders, a Tools folder and a WebGui folder. The listed primary language is Classic ASP, which is a fair signal that the web interface work is separate from the embedded side. The licence is the Unlicense, which is a dedication to the public domain rather than a permissive grant with conditions. That keeps the reuse question simple, with the exception of the private community firmware build mentioned in the device table, which the project itself flags as illegal to release publicly. There are no GitHub releases, so upgrades are a matter of pulling the main branch, and the last push was on 2026-10-19. The repository is not archived. For a project whose value is a growing body of field knowledge, that is a reasonable cadence, and the forum carries the day to day discussion that a release cycle would not. ## Conclusion Adopt this repository if you own a Realtek based GPON ONT stick and an OLT you are permitted to run, and you want to replace vendor firmware that will never be updated again. Do not treat it as a general purpose firmware toolkit, and do not deploy a modified ONT onto a network shared with other subscribers, since the project itself warns that one misbehaving ONU can disrupt a whole PON segment and can trigger ISP sanctions. Before you start, confirm your exact stick model and SoC appear in the device table, read the safety notice in full, and back up the env, env2 and config partitions before writing anything with flash set. ## FAQ ### What does the RTL960x repository actually do? It documents and demystifies the RTL960x platform for the xPON community. It holds documentation, firmware folders, tools and a web interface, and it is not a fork of a vendor firmware tree. ### Which GPON ONT sticks are covered by RTL960x? The device table lists the VSOL V2801F, the T&W TWCGPON657, the UFiber Instant, the DFP-34X-2C2 and the Nokia G-010S-Q, each with its SoC, NAND size and supported modes. A separate table covers Lantiq based units such as the Huawei MA5671a and the Nokia G-010S-P and G-010S-A, which are used or second hand and have limited OLT support. ### How do I back up an ONT before modifying it? The repository links a guide for backing up the env, env2 and config partitions before any firmware write. The flash key documentation is in Docs/FLASH_GETSET_INFO.md. ### Is it safe to run a custom ONT on my ISP's network? The project's safety notice says a single faulty ONU can trigger a PON-wide disruption affecting other subscribers on the same fiber split, and that operators may respond with suspension, bans or penalties. It also notes that custom firmware can cause intermittent connectivity or service failure. ### What licence does the RTL960x repository use? The repository is released under the Unlicense. The device table notes separately that a private community build at V2.0 is illegal to release publicly. ## Sources - [Anime4000/RTL960x on GitHub](https://github.com/Anime4000/RTL960x) - [Issues](https://github.com/Anime4000/RTL960x/issues) - [License: Unlicense](https://github.com/Anime4000/RTL960x/blob/main/LICENSE) - [README](https://github.com/Anime4000/RTL960x/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/anime4000-rtl960x