WeSearch

Its always DNS: Why the default BIND setup is failing to resolve

·3 min read · 0 reactions · 0 comments · 0 views
Its always DNS: Why the default BIND setup is failing to resolve

Linux, FreeBSD, networking, etc.

Original article
smallhacks
Read full at smallhacks →
Full article excerpt tap to expand

Broken serial port To start the experiment I decided to start with the soldering serial port on the router. That was a bad surprise, none of my UART TTL adapters have been able to get any output from it. Led on the UART was blinking but nothing was on the terminal. I tried with 3 different UART/TTL to USB adapters with the same outcome, and as the loop test was passing just fine it was clear that the problem is with board hardware. So I decided to give it a last chance with a cheap USB Logic analyzer and PulseView as a UART decoder. Surprisingly it was working! Using 500Khz sample rate and default (115200/8N1) decoder settings I was able to read from the port. Likely analog circuit in the serial is kind of broken and not generating TTL levels expected by the UART adapter, but still readable with Logic Analyzer. So at least we have now the read-only port, hooray. Hacking the router As I had read only access to console I decided to use web interface hack method from the OpenWRT wiki. Idea is to modify the backup configuration which will force the router to run telnetd. I was not able to get it working with Python code, but the java app was working just fine. And I was able to telnet to the stock firmware and login as a root user. So I can try to install OpenWRT firmware to it 🙂 Bricking and debricking As the article suggests I backed up all mtd (mtd0-mtd6) partitions to the FAT32 flash using the telnet interface. I decided to install OpenWRT by using hack from a similar deviceby writing part of the firmware to mtd1 and rest of it to the mtd2 using dd and cat command. Loader is living in mtd0, so we are not overriding it. For me the result was a broken router – it seems that this is not a reliable way to flash it. From UART I saw that u-boot fails to unpack the kernel image, which makes me think that flash was written with errors. To de-brick the router I used the ch340 programmer. Initially, I desoldered flash (don’t do that :)) but later found that it perfectly works with a clip when soldered on the board. I flashed old firmware (by doing cat mtd0 mtd1 mtd2 mtd3 mtd4 mtd5 mtd6 > fw.bin) to the flash, soldered it back and the router started normally. Finally flashing OpenWRT As the router (with the telnet hack) was online again, I decided to flash OpenWRT using CH340. To generate an image I replaced mtd1 and mtd2 with OpenWrt squashfs image. Partition mtd2 was padded by zeros to ensure that size matched the original one. So I flashed it with fw-new.bin, enabled serial console monitoring and in a minute OpenWRT was started! I used the version from the article (15.05) as it was tested already and I have no idea if this ancient device is not broken in the recent builds. When the device started I was able to telnet to the 192.168.1.1 from the one port. I had to install some packages from the OpenWRT RNDIS user guide to make OS aware of the USB LTE Dongle. After reboot dongle was recognized as eth1, so I was able to assign it as a WAN device using Luci. I tested performance and it seems that I can get dongle speed (~30Mbit on this plan) using wifi, so the problem is solved and the device got a new life. Was it easier to just buy a new router? Likely yes. But here I had much more fun )

This excerpt is published under fair use for community discussion. Read the full article at smallhacks.

Anonymous · no account needed
Share 𝕏 Facebook Reddit LinkedIn Email

Discussion

0 comments

More from smallhacks