Recently, I decided to upgrade my ADSL subscription to VDSL, and the deal included a ZTE ZXDSL 931WII CPE box (VDSL2 modem + NAT + WLAN AP). Attached with the box were instructions stating that configuration settings could be managed from a private web page provided by the ISP. And was one able to do so? Of course not. Much to my annoyance, it also turned out that all ‘outside the box’ local configuration had been disabled in the firmware (no response to LAN http, ssh or telnet). So, a quick call to the ISP helpdesk:
“Hi! I upgraded to blablabla and would like to configure it but there’s nothing else on the remote admin panel than a save -button”
“Ok let me check”
“It doesn’t accept any http or telnet connections to the local admin interface either..”
“What would you like to configure?”
“Well you know, the usual stuff people configure on their home router; static IPs, port forwarding, admin password etc..”
“Hmm well I can see that implementing the feature is pending, but I can check details about this with someone. Is it ok if I text you shortly? Kthxbye!” *CLICK*
Some minutes later, there’s a text on my mobile saying “There is no known schedule for adding remote configurability for the current firmware at this time”. W-T-F and thanks a fucking bunch! :D
Seriously: Do they think that I’m going to run this box in my home without having any access to feature configuration?
Sure I can understand that, given the increasingly technical times we live in, the need might arise for the ISP to be able to remotely check the CPE configuration of some less-technically-inclined subscriber using their ACS server. But why-oh-why disable all local configuration options? Surely, the option of configuring the hardware could be kept available to those who wish to do so?
Not happy with the situation at all, I decided it was time to take a look whether local configuration could be performed from inside the box.. I’d rather have a bit of my own fun with the box instead of paying xx€ for queuing +15 minutes on the phone just to be walked through a “Did you check cable connections” check list (or whatever). Should my “playtime” result with a bricked box, no problem. The ISP can then have the box back accompanied with a “the lights just went out” fault description and I’ll go buy something more decent :)
After opening the enclosure, board gets the usual ‘scanning glance’.. and what do you know?! On the front edge close to the status LEDs there’s a standard 4-pole pin header. Easy guess; one pin for GND, one for +VDC, one for RS232TxD and one for RS232RxD. Sort of screaming “hello, I’m a serial port” all over. Not that it turned out to be exactly plug’n’.. err.. hack.
As +3.3V logic levels are used, a RS232 line level driver is needed in-between to interface with a standard serial port. I have plenty of Intersil HIN202 transceivers available, so that’s what I used and will discuss here. Any other RS232 transceiver (f.e.x something by Maxim) should work as well. If you have some other chip, just pay attention to its datasheet / app notes how to connect it.
 |
| Basic application of HIN202. Image courtesy of Intersil. |
What I put together was rather directly lifted from the HIN202 datasheet (picture above). HIN202 actually uses +5V logic levels, but as the specced low/high signal transition thresholds are 0.8V / 2.0V (respectively), the chip works just fine with 3.3V signal levels too. What of course needs to be accounted for is the RxD output connecting to the CPU. Remember, that the transceiver outputs +5VDC high signal state whereas the CPU prefers 3.3V! Thus, a series resistor is needed to lower the signal level. My choice here was 10k.
As you can see from the datasheet schematic above, electrolythic capacitors are used for the 10V on-chip voltage charge pumps. So why does my circuit use regular ceramic (1206 SMD) capacitors? Well, being the lazy me with certain things (like doing a quick hack such as this) is really about what suitable is ‘on the desk’.. and here, it was the ceramic capacitors. I have no idea if the electrolytics allow the pumps to work better in some specific conditions, but at least on my desktop/living room setup the RS232 connection works just fine like this. So, leave it at that and move on.
 |
| Lower side connections of the RS232 transceiver |
 |
| Upper side connections of the RS232 transceiver |
 |
| The completed adapter |
The transceiver needs +5VDC operating voltage. Luckily there’s a +5V switch mode regulator stage on-board, so there’s no need to build a separate one just for the transceiver alone. I chose to tap into the supply by connecting parallel to D3, but there are plenty of other places on-board too.
 |
| Connected to the +5VDC supply.. |
Ok, adapter all wired up.. Hook it up with the PC, open a port connection in HyperTerm using 115k 8-n-1 and yay, bootup texts scrolling on the screen \o/.
In case you’re wondering about the enclosure looking different on the picture above than what it is at the
ZTE website (and the beginning of this post) .. It’s because it is! :) Apparently, ZTE offers at least these two types of enclosure, allowing for a little bit of ISP “branding flair” or whatever. The manuals shipped with the unit have pictures of both enclosures and with a ZTE logo on it, whereas the box itself carries the ISP logo. How classy.
Hardware-wise, the box has a
BCM6368 400Mhz processor, 4Mb flash and 64Mb DRAM. For WiFi, there’s a BCM4138 chip. I didn’t really want to bother with removing the RF shielding around the processor to see what else there might be underneath. The ground layer on the bottom of the board is pretty big, so the board and the shielding plate would have to be heated to extremes for removal.
Considering embedded systems as a whole.. Whereas hardware I can manage, Linux I however don’t. I do have some experience with distro installations (Debian, Ubuntu etc.) and basic command line usage, but this doesn’t really get you anywhere on a embedded system that’s optimized for a specific use. So, as you can probably imagine, ending up on the command prompt of the 931WII was somewhat a baffling moment. Steep learning curve right up ahead and all that.. :)
Luckily, hints given by friends combined with a plethora of internet searches pointed me the way. After fiddling around a while, I had a tftp server (
TFTPD32) running on my laptop and was able to transfer the flash config to and from the box. The kernel is configured to automatically reboot the system after a valid config file has been uploaded, so no additional command line trickery is required for applying the new settings.
The settings themselves use some Broadcom xml markup (tags starting with X_BROADCOM_COM). I’m sure some kind of developer documentation must exist, not that I was unable to find anything from
Broadcom’s online resource library. But once again, searching the net with some of the markup tags gave ideas how to go about configuring some of the settings. First tweak (of course), remove everything between the ManagementServer -tags ;).
After having my share of fun playing “the master of the system”, the first problem surfaced. No matter what parameter switches I passed to tftp, transferring the entire firmware didn’t seem to be possible. The system just kept persistently dumping/fetching the flash config! So there I was, trying to figure out what’s wrong with my tftp setup.. right about until a friend suggested that I could try starting the shell! Being used to desktop systems, I assumed shell would be running (BusyBox is mentioned on the startup texts, and all) but it actually wasn’t. No wonder the basic file system commands (like ‘cd’) were missing :D
 |
| If only someone had mentioned earlier that I'm supposed to do this.. ;) |
So, after launching the BusyBox shell suddenly tftp has no problems transferring the firmware binary. No idea why it is like this (or did I do/type sth wrong?) but “yeah whatever”, as long as tftp is fully functional. The ZTE firmware binary I uploaded is of version 1.5.0c and it contains
CFE bootloader and some vmlinux (2.6.21.5 kernel). The binary is available at the
ZTE Finland website along with 1.5.0b. Both of these are for ISP other than mine, but they seem to work. There is 1.5.3something available
here, but my box doesn’t accept this. ZTE doesn’t (at least currently) share firmware binaries with end-users, so I have no idea how much newer versions there might be.
Despite now having both the telnet and http admin interfaces accessible, what remains to be figured out is why certain ethernet connections timeout too quickly with the current firmware. This doesn’t seem to happen when using WLAN, so the problem is definitely somewhere with the LAN router settings. I tried modifying some of the nf_conntrack TCP values found under /proc/sys/net/ip4v/netfilter/, up to no avail. Not that it looks like the IP table is getting full either (as in, packets dropped). More learning curve for yours truly, so to say..
Big thanks to everyone who had enough patience to help me with Linux, it’s networking features and other related stuff! If you happen to read this and have a pdf on the Broadcom XML, I wouldn’t mind a download link in the mail. Most of the stuff in the config file seems to be accessible through the http admin interface anyway, so it’s not like my need for the documentation is critical. Call it more of a “nice-to-have” bonus ;)
The factual content ends here, but just to continue a bit on bonuses this is the “real one” of the topic..:
Only after I had the box running on the downgraded firmware, I came across some forum posts stating that the stock firmware is accessible by using the public WAN IP.. Grrrrrr, motherfuckers! If it is so, why the fuck DIDN’T HELPDESK OR THE MANUAL MENTION ABOUT THIS?
More importantly, if it is so, this also sounds like a security risk of sorts. Basically, all you’d have to know is the public IP of some subscriber using this particular CPE (f.ex. take a look at the ISP forum where they conveniently log user IPs), and you’d gain access to their router configuration in no time thanks to the very “default” admin password. Classy *2, if so.
Then again, a friend in-the-know tells me that some ISPs have certain modems that’ll give you access to admin interface from the WAN side if you simply change “login.html?success=0″ to “login.html?success=1″ on the browser address line! So yeah, maybe things could also be worse.. ;)
