dd-wrt is very a powerful firmware compared to ASUS Merlin, but the UI leaves a lot to be desired. It’s very close to editing a config file and there’s little help to what each setting. The developers of dd-wrt didn’t invest time in designing the web administration interface and used the most basic primitive HTML forms so there are no tooltip that explains the features and the interaction between different settings.
There are also some confusing (nonsensical) UI design that are a lot less work to the developer but confused users to no end. Here are the examples I’ve found so far:
Enabling remote admin through SSH (for embedded linux command prompt) is a two step process out of the box. You’ll need to first enable SSHd from Services -> Secure Shell before enabling SSH Management from Administration -> Management (otherwise it’s greyed out)
The router username (user modifiable) for dd-wrt applies to web UI only. SSH’s username remains root. They share the same password though (so login and password are decoupled in dd-wrt, they are effectively two passwords in practice except they don’t put asterisk over the username as you type). ASUS Merlin firmware’s login is consistent across both web page and SSH
Cron jobs is from a bare environment which means you need to manually define the paths and specify the user in the cron job syntax. e.g. PATH=/sbin:/usr/sbin:/bin:/usr/bin * * * * * root {command_to_execute}
I opened up my ATX Power Supply as I had it for quite a few years but it has been stowed away and used intermittently until I use it a lot more in my office computer in recent years. I just don’t trust any power supplies Made in China, even from a reputable brand as a couple of decades of working with computers tells me that they are bound to break after a few years, and very often it is the capacitor that rotted and the rest are collateral damages. Lo and behold there is one:
After I took the capacitor out, I noticed something odd: the polarity marker on the circuit board is the reverse of how the capacitor was installed! Holy smokes! I just want to verify if the PCB markings is right or the installer was right, so I installed wires to the capacitor to lift it up so I can connect the multimeter leads across it to measure the voltage polarity. This picture also shows the PCB’s capacitor orientation marking:
And the multimeter reads -5V following the original orientation of the capacitor before I took it out. This means the polarity was reversed!! No wonder the capacitor bulged. I was lucky that it didn’t blow up after a few years of use! Probably it was rated 16V yet only -5V was passed to it so the electrolytic capacitor rotted slowly.
To give XFX Force credit, they didn’t slap the power supply together with the cheapest white label components from the gutters. It uses proper Nichicon and Hitachi capacitor, so it might be the reason that reversed capacitor lasted so many years.
It’s the workmanship in China. If you go with a Red Chinese (Yellow-Soviets) brand, they might use junk components, but don’t think you are safe with foreign companies that has a solid process and design. The cheap labor in China who doesn’t give a crap can still manage to fuck it up. So trust nothing
Setting Redirect Internet traffic to “Policy Rules” opens a table where you can specify which computer goes through VPN and which ones uses direct connection. Leave the destination IP unspecified and it’ll pick the 0.0.0.0 as intended
However, there’s a logical trap when you blindly follow instructions setting “Accept DNS configuration” to “Exclusive” as given by most instructions assuming all computers go on the network through VPN. Setting it as “Exclusive” means even the computer not intending to use VPN will still need to go through your VPN provider’s DNS! For slow VPN connection, this will be painfully slow for ALL computers! Set it to “Relaxed” instead.
Aria2 is a convenient command line downloader that works like curl/wget on http/ftp, but it also support many other protocols, and it aria2 natively multipart download!
# Install the base (core) software first
# This example is for entware
opkg install aria2
# Download the package from Github zip to /opt/tmp
wget -c -O /opt/tmp/webui-aria2.zip https://github.com/ziahamza/webui-aria2/archive/master.zip --no-check-certificate
# Make sure you have some web server installed (nginx, httpd, apache, etc.)
# Nginx HTTP server instructions
# https://hqt.ro/nginx-web-server-with-php-support-through-entware/
# Make sure you know what {Webroot} is
# for Nginx, {Webroot} is /opt/share/nginx/html
# Unpack to the zip file at /opt/tmp and clean up the zip
unzip /opt/tmp/webui-aria2.zip -d /opt/tmp/ && rm /opt/tmp/webui-aria2.zip
# Move/rename to desired location
mv /opt/tmp/webui-aria2-master {Webroot}/aria2
Nginx defaults to port 82 (change it to where you set your web server). The WebUI can be accessed at http://your_server_here:82/aria2/docs.
/doc is inconvenient, so I created a redirection by placing this index.html under aria2’s root folder:
The RPC host breaks out of the box because the you’ll need to make a few adjustments to /opt/etc/aria2.conf before you can start the service without crashing it (so the WebUI of course will complain with a lot of cryptic error messages):
# Basic Options
dir={Change it to a viable folder that has enough space if /opt/var/aria2/downloads
is is not big enough}
# RPC Options
# Unless you want to get a certificate, you'll need to use unsecure mode:
rpc-secure=false
# Change your rpc-secret to be matched in "Connection Settings" in the WebUI
rpc-secret=whatever_passphrase_you_like
After you get the config file correct
# Start the installed aria2 service
$ (the package already have a service wrap over aria2c)
# aria2 seem to assume it's port 81 so the init.d script has a "S81" prefix, but aria2 does not control the port, where you put the WebUI in http. So it's just a cosmetic filename naming convention.
/opt/etc/init.d/S81aria2 start
If the service wouldn’t start (some bad configs might have the service reported as “done” and after you check again in a second with “S81aria2 check“, it’ll report as “dead”. You can debug by looking at what went wrong at /opt/var/log/aria2.log. That’s how I figured I need to turn off “rpc-secure” parameter.
My router only supported Merlin (Tomato) firmware up to 380.70_0 (2018-04-08) and there are no more updated from that branch.
Turns out the Namecheap DDNS client is not working. I searched its source code at Github for “Namecheap” to see if I can fix the HTTP 400 error (seen in router log) using “in:file” hoping to see if I can fix the bug myself (since it’s just a simple REST API, aka URL call) command and found this:
It means Asuswrt-Merlin (Tomato)’s firmware’s Namecheap DDNS service is broken UNTIL 384.7_2, which is for newer routers than what I have.
I compared the “namecheap” keyword search for the two versions and it seems like they are written very differently, so it might not be worth the effort to fix the obsolete Merlin branch. Doing a bit of additional search and discussions about John’s Merlin fork from the early days are still updated until 2019-04-17 :
It took me a while to find John’s forum post to get to the said 2019-04-18 release. The download link he provided has more updates up to Update-44EA (2020-07-12) and it still worked on my old router, so it’s not just the Update-39L3 previously discussed in the forum:
Do not get discouraged when John’s Merlin fork says version 374.43 instead of 380 (a lower number). All updates, even the latest one from John still use 374.43, which I suppose it’s to mark when the two code branches part ways. It’s not an older version.
