This weekend was supposed to be boring. The only thing on the list was deep-cleaning my room, which mostly meant clearing out the packaging that I've been hoarding for everything I've bought in the last two years.
Then, in one of the drawers, I found it: an Altai C1AN Super WiFi CPE/AP. This was the thing that gave me wireless internet from Broadlink about 12-15 years ago. I still remember climbing up to the terrace with the installation guys to mount it, and being endlessly curious how this little device pushed such fast internet at the time. It was I think 2 Mbps when the ADSL guys would be pushing speeds in the Kbps range.
I'd always wanted to get inside it and see what made it tick. Over the years I had tried a few times, digging through forums for a way in, but never had the skills or tools to pull it off.
This time was different. This time I had AI.
Round one: just plug it in
I started the way I always had: power the device with a PoE injector, connect it to my PC over Ethernet.
Then came the actual hard part: figuring out the device's self-assigned IP.
I asked ChatGPT. It said 192.168.1.20. Didn't work.
I asked Claude. Same answer. Also didn't work.
I burned over an hour on finding its IP.
Eventually, out of curiosity more than strategy, I fired up Wireshark, pointed it at the USB Ethernet interface connected to the C1AN, and power-cycled the device. A few seconds in, this showed up:
Who has 192.168.1.1? Tell 192.168.1.222
That was it. Real IP, no guessing required. Sometimes the answer isn't in a chatbot's training data, it's sitting right there in the traffic.
Poking at the open ports
A quick nmap scan showed SSH, HTTP, and HTTPS all open. The HTTP service turned out to be a LuCI interface, the standard OpenWRT-based web admin UI, which meant it was at least theoretically brute-forceable.
Starting Nmap 7.99 ( https://nmap.org ) at 2026-07-26 11:00 +0545
Warning: 192.168.1.222 giving up on port because retransmission cap hit (2).
Nmap scan report for 192.168.1.222
Host is up (0.00026s latency).
Not shown: 756 closed tcp ports (conn-refused), 240 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 32.97 seconds
I asked ChatGPT and Claude for credentials first, on the off chance either one just knew them. A few guesses, no luck.
So, brute force. Both models declined to write me an actual brute-force script, fair enough, but Claude was willing to generate a username:password combination list. I wrote a bash script around it that curled the login endpoint until something stuck. No luck.
It was 7pm. I'd started around 2-3pm.
Taking it apart
Ethernet wasn't getting me in, so I went for the UART pins I knew were inside. Took the device apart, found the pins, and then realized I had nothing to actually connect my PC to UART with. Almost gave up right there.
Then I remembered I still had a Raspberry Pi sitting around, and hoped that its GPIO pins could talk UART. Back to ChatGPT: apparently it did talk UART, installed minicom, tried to connect. No device found.
Claude's turn: apparently you need to disable Bluetooth on the Pi for the serial UART to work properly (the Pi shares its good UART between Bluetooth and GPIO by default). Disabled Bluetooth, rebooted the Pi, ran minicom again, and got dropped into a console. Booted the C1AN and started seeing its boot log for the very first time.
Then it hung, right after the DDR/relocation step.
Asked Claude again, got told to disable hardware flow control. Disabled it, retried, still hung in the same place. Tried a handful of other things. Nothing worked.
It was 11pm now.
Back to the old ways.
Still not ready to quit, I went back to scouring old forums, the way I had years ago. About 30 minutes in, buried in page 2 of google, I found an OpenWRT forum thread for this exact device and firmware combination, with a default credential pair: root:superwifi123.
At this point I'd already sunk hours in, so what's one more login attempt. I rebooted the device with one of the UART pins pulled and tried logging in. Instead of an "unauthorized" message, the whole thing just power-cycled.
Assuming I'd shorted something in the excitement, I rebooted again, this time pulling off all the pins and keeping the board clear of every stray screw and wire on my desk. Then, instead of the LuCI interface, I ran the curl script Claude had written earlier, now with the real credentials.
It worked. The credentials were good.
One more power cycle, and I tried the same credentials on the LuCI web interface.
Success.
Twelve years after that box first went up on my terrace, I finally actually own it.
Takeaways
A few things stood out from an otherwise chaotic seven-hour detour:
AI was consistently better at helping me debug than at giving me the answer. Both ChatGPT and Claude were flat wrong about the device's default IP, and neither had the actual login credentials sitting around. What they were genuinely useful for was the iterative stuff: figuring out why minicom couldn't see the Pi's UART, why the boot log was hanging, and turning a wordlist into a working script once I had real credentials to test.
The models also drew a clear line on the brute-force request: neither would hand me a ready-to-run brute-force script, but both were fine helping with adjacent pieces, like a credential wordlist I could wire up myself. Not a workaround so much as a reasonable place to draw the line.
And, as usual with hardware, the actual breakthrough came from decidedly non-AI sources: a Wireshark capture and a forum post from someone who'd cracked this exact device years ago.
Top comments (0)