DEV Community: Ashwin Belbase

12 Years Later, I Finally Own My Old WiFi CPE (With Some AI Help)

Ashwin Belbase — Sun, 26 Jul 2026 05:22:38 +0000

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.

Setting up a Homelab: Part 1 Proxmox and LetsEncrypt

Ashwin Belbase — Fri, 26 Apr 2024 13:51:40 +0000

As someone who likes to tinker around with stuff, I tend to break my system quite often. For a long time, I have wanted to allow myself to test applications and operating systems without breaking my ongoing OS install.

One way to test application is by using virtual machines or docker. While I use docker quite a lot for testing and for production workloads, testing an entire operating system on docker is not feasible. For this reason, I wanted to use virtual machines. But I also did not want to run Virtual Machines on my laptop, as I do not like my laptop getting hot everytime I want to test something new. Recently, I got my hands on a used desktop, a decent machine on which I could start building my home lab.

As I wanted to run a bunch of Virtual Machines and containers on the server, Proxmox seemed to be a good fit as it supports both VMs and Containers using KVM and LXC.

P.S. This is not supposed to be a tutorial. I only wrote this piece so that I can look back on it after a year and hopefully remember how I did stuff.

Installation

To install Proxmox VE, I just followed the documentation on the Proxmox website and completed a standard installation. As the installer is straightforward, the installation itself was quite easy.

Configuration

Right after I installed Proxmox, I tried logging into the web console, and I saw this.

A self-signed certificate was generated and used by Proxmox which will always generate a warning on the browser. I did not like seeing this when trying to work on my home lab. So, I started looking for ways to put a valid SSL certificate in Proxmox.

During my research, I found that Proxmox could be made to integrate with acme.sh; a free SSL certificate generator powered by ACME(Let's Encrypt).

Generate and Apply SSL Certificate

Docs: https://pve.proxmox.com/wiki/Certificate_Management

After skimming through the documentation, I thought that the integration would be quite easy, and indeed it was, after a couple of failed attempts.

You can register and deactivate ACME accounts over the web interface Datacenter -> ACME or using the pvenode command-line tool.

Following this excerpt from the documentation, I went to Datacenter -> ACME -> Accounts -> Add, and registered an account with Lets Encrypt V2.

Since The Proxmox instance was not accessible directly from the public internet, I proceeded to add the plugin for DNS challenge based verification.

To add a Challenge Plugin:

In the challenge plugins section, click on Add.
In the popup that appears, give a name to the plugin that you will create in the Plugin ID section. Remember this value as the PLUGIN_NAME.
Set the DNS API option to DNS provider, and fill in the generated form as required. Then clock on save.

In my case, I am using Cloudflare, so I filled in the CF_Account_ID, CF_Email, CF_Token and CF_Zone_ID fields.

You might only need the CF_TOKEN but the process failed due to some reason when only the CF_TOKEN was used. So I filled in all the applicable fields.

Now, to generate the certificated for a node, you need to go to the Datacenter -> NODE_NAME -> System -> Certificates to generate/setup the certificate.

In the ACME Section, Click on Add.
In the popup that appears, select challenge type as DNS, and the Plugin type as the name that you used when creating the DNS plugin (PLUGIN_NAME).
In the domain field, fill in the domain name that you want to generate the SSL certificate for. Now click on apply.

The certificate should be generated and applied. Proxmox will restart the webproxy to apply the new certificate.