Interim steps to the end destination are often a wise policy, economically if for no other reason. And, it turns out, non-bleeding-edge gear can be made wiser in the process, too.
As recently mentioned, I shortly plan to begin migrating my LAN from 1 to 2.5 GbE (and 10 GbE in some spans). That said, to be clear, I don’t plan to do so in one fell swoop. And frankly, I may never complete the transition.
Most of my LAN clients connect to either the main router or mesh points over wireless, and it doesn’t make sense to update any switch hardware tethered to them until they’re upgraded beyond the Wi-Fi 5-plus-1 GbE backhaul technology threshold. And even if a LAN client hooks into the LAN fully in a wired fashion, most of them are 1 GbE-only.
There are exceptions, of course; my Apple Mac Studio in the office is 10 GbE-supportive, and I’ve upgraded the highest-end of my three QNAP NASs in the furnace room below it for 10 GbE cognizance, too. And then there are the multiple MoCA 2.x adapters, one in the furnace room, that I may reintroduce in the future. Perhaps obviously, therefore, the multi-port switches in both locations will get upgraded first; if the Cat 5e span between them turns out not to be 10 GbE-reliable, I’ve got 50 feet of optical cable and two SFP+ modules ready to replace it.
For the switch in the furnace room, sitting right next to the router and cable modem, and therefore acting as the LAN nexus, the mix of legacy and more modern, higher speed clients proved to be manageable in combination with an open-box (truly so, it turned out; never unpacked, far from used) Zyxel device, the XGS1010-12, that I bought for $49.99 on eBay.
As you can see from the photo, it baseline-integrates eight 1 GbE ports, the same quantity and speed as with the switch I’m currently using, a TRENDnet TEG-S81g. But there are also two 2.5 GbE ports, along with two 10G SFP+ cages. Not only will the XGS1010-12 expand my total port allotment at that location, its RJ-45 and SFP+ additions will deliver higher speeds, too. And, it turns out, another pleasant surprise also awaited me post-purchase.
Switch types
Both my existing switch and the Zyxel XGS1010-12 (at least in the latter’s from-factory mode…hold that thought) are unmanaged, meaning (to quote Wikipedia) that they “have no configuration interface or options. They are plug and play. They are typically the least expensive switches, and therefore often used in a small office/home office environment.” Although likely running firmware, it’s usually non-upgradeable, and no settings or broader graphical user interface (GUI) exist for the user to access, either. Therein the lack of a MAC address on my XGS1010-12’s underside.
Managed switches, on the other end of the spectrum, are (as the name implies) user-configurable and -updateable. Why would you want such a thing? One example is virtual LAN (VLAN) support, the ability to isolate various clients (and clusters of them) so that they can’t access other client groups and, in some cases, the WAN either. One well-known example here is the “guest network” feature bundled with many modern routers, which provides visitors with the ability to use the Internet without allowing them to “see” devices on the main LAN.
You might also want to, for example, be able to isolate “smart home” IoT devices from the rest of the LAN so that, should one of them get hacked, the infection can’t then spread elsewhere. Managed switches also enable you, for example, to prioritize traffic flowing through a particular port (for VoIP applications, say), to hard-wire various ports’ bandwidth and duplex settings, to implement MAC filtering and other network access rules, to aggregate multiple ports for the same connection (to a multi-port NAS, for example), and to more broadly monitor real-time network traffic conditions, along with other features.
And between these two extremes is the “smart” switch, implementing a subset of the fully managed switch’s capabilities, across a subset of the total available ports, but in a more user-friendly fashion. Take, for example, the front panel multi-position configuration switch offered with this low-priced Tenda device.
The lion in sheep’s clothing
All of which leads to the XGS1010-12’s managed “big brother”, the XGS1210-12. Notice the familial name similarity? They could, in fact, be twins, judged by their visual commonality (aside, of course, from the respective product names on the front panels, and the MAC address stamped on the XGS1210-12 underside).
It turns out, in fact, that the hardware allotment is identical between the two, aside from one other front panel deviation; the XGS1210-12 extends a PCB-mounted reset button to the exterior for easy user access. They otherwise differ (I’m speaking specifically of my XGS1010-12 with hardware version A1; hold that thought) only in the software running inside. Have you guessed yet where this tale is headed?
After purchasing the XGS1010-12 unmanaged switch, and while waiting for the eBay to ship it to me, I did a Google search on the product code to see what else I could find out about it. Near the top of the results page, I excitedly learned, was a Reddit post (along with subsequent follow-up posts from the original poster, and broader r/homelab community discussion) describing how to hack the XGS1010-12 and upload the XGS1210-12 firmware to it, converting it to the managed-switch version in the process.
“But Brian,” you might be thinking right about now, “I thought you said that unmanaged switches don’t have user-accessible GUIs?” I did, actually, but I never said anything about a command-line user interface (CLI), did I? What Redditor zeda1ert realized was that in-between two of the side passive airflow vents was a standard UART console header.
The Reddit post has detailed instructions; you’ll see in the ensuing conversation that three years later I chimed in with a bunch of questions. Fortuitously, zeda1ert was still monitoring the post and graciously helped me. The following few paragraphs summarize the process.
Connect a USB-UART adapter (I own both this 3.3V one and this 5V one and can use either, because the switch’s 3.3-V UART circuitry is self-powered, so only the adapter’s Tx, Rx and GND need to be hooked up, although the latter’s cable is conveniently longer) to the switch and your computer, start up a CLI terminal session (I used MacOS’s built-in command-line “screen” utility), and issue a timing-critical ESC to terminate the switch’s boot sequence before it finishes.
Now configure a MAC address for the switch, along with static IP addresses for both the computer and switch (different, but on the same subnet), then fire up a TFTP server session on the computer (MacOS has a built-in one, but it’s also command line-based and fairly cryptic, so I instead went with SoftPerfect’s excellent freeware GUI utility, which I’ll include in the next best-of list). Use it to download and install the most recent v1 XGS1210-12 firmware to the switch. Then reboot, and the switch is now managed.
And speaking of “re”(boot), the missing hardware “re”set button isn’t a problem in practice, as you can alternatively accomplish the same reset outcome through either the switch’s CLI or GUI.
Hardware fortuity
I’d earlier explicitly noted that mine was an A1 hardware version unit. The distinction was initially important, and remains so for “stock” firmware, although broadly no longer (stay tuned). Partway through its ongoing product life, Zyxel redesigned the XGS1010-12, switching from Realtek’s RTL8226 2.5 GbE PHYs to the newer RTL8221B with reduced power consumption, therefore also lower heat dissipation.
Unfortunately, this caused an incompatibility with the legacy firmware for the XGS1210-12, which wasn’t similarly hardware-updated. Installing XGS1210-12 firmware on a version B1 XGS1010-12 resulted in nonfunctional multi-gig ports.
A further nuance involves the various A1 revisions, A, B, and C. Originally, it was not possible to install any newer v2 XGS1210-12 firmware (patch 0 link, patch 1 link with OpenSSL vulnerability fix) on a version A1, revision C XGS1010-12 unit such as mine.
Scroll down in the Reddit thread, though, and you’ll see that another contributor later figured out how, via resistor relocation, to spoof the board identifier, enabling successful v2 firmware update. But I haven’t bothered doing so, because I have a more robust alternative next step planned for eventual implementation.
Open source once again saves the day
Three years back, when the original Reddit thread post was published, OpenWrt development for the XGS1010-12 was immature and insufficiently staffed, with the resulting available build functionally incomplete. A lot has changed since then, notably including the inclusion of support for version B1 units’ RTL8221B PHYs (in spite of Realtek’s longstanding and ongoing open-source reticence) beginning in mid-2026.
Right now, the v1 “stock” XGS1210-12 conversion does everything I need, and since the switch isn’t exposed to the Internet, I’m not worried about its ongoing “Heartbleed” OpenSSL compromise. But at some point, I’ll probably take the plunge and further migrate to OpenWrt instead. If and when I do so, I’ll report the result here in the form of another blog post. And until then, I as-always welcome your thoughts in the comment on what I’ve discussed in this post!
—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.
Related Content
- The multi-gig migration: Motivations and implementations
- NAS upgrades: proprietary lockouts and surmounts
- The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
- SFP: Add-in module delivers diminutive performance, flexibility
- Heartbleed: the wakeup call the open-source community needed?
The post Hacking a network switch for management enhancements appeared first on EDN.