Namecheap Dynamic DNS setup in dd-wrt

Namecheap support page explained the process of configuring your dd-wrt router firmware to use Namecheap’s REST (HTTP URL) update interface to dynamically update the IP of your (sub-)domain. The instruction works, but there are few items which doesn’t quite make sense to me as a programmer, and I did a few experiments to figured that it’s bogus and developed a few insights about what’s necessary and why they do it.

Their instructions looks like this:

and specific verbal instructions are:

  • DDNS Service: Custom
  • DYNDNS Server: dynamicdns.park-your-domain.com – the name of the server should not be changed
  • Username: yourdomain.com – replace it with your domain name
  • Password: Dynamic DNS password for your domain (Domain List >> click on the Manage button next to the domain >> the Advanced DNS tab >> Dynamic DNS)
  • Hostname: Your subdomain (@ for yourdomain.comwww for www.yourdomain.com, etc.)
  • URL/update?domain=yourdomain.com&password=DynamicDNSPassword&host=

I stroke out Username and Password fields because they are not used!

If you look at the URL, namecheap’s instructions are asking you to re-enter the domain and the password key-value pair AGAIN, which means Username and Password fields are not used.

My programmer instinct immediate screams the updater is assuming certain REST API syntax that are not properly substituted so they need to be entered manually, exposing the password without the benefit of the masks (forget about keeping the password top secret, router firmware guys aren’t top security engineers. Just re-generate one in Namecheap’s admin interface if it gets compromised).

I checked by entering bogus Username and Password fields (the web’s GUI/forms checks if they are blank, so you can’t get away with not entering). It worked as expected. This means the two fields are dummies with Namecheap’s instructions.

Based on the fact that Namecheap’s instructions being unable to substitute Username and Password fields and the host key must be put at the end for Hostname field to substitute correctly, I can safely speculate that the one who wrote this couldn’t find out what the syntax for the variables are, and exploit that the last parameter hostname gets attached at the end in the absence of substitution variables in the URL syntax.

Apparent people are doing something stupid like this because nobody in the chain remember to document the substitution variable names! It’s not in dd-wrt’s user interface (should have that printed the ‘usage’ info next to the URL box) and neither it’s in INADYN’s github readmes!

I decided to dig deeper and go after the dynamic DNS updater package in question. dd-wrt is using inadyn package to do the dynamic DNS update, as “INADYN” is shown in “DDNS status” box gives it away (confirmed by dd-wrt’s docs):

The service itself is called ddns though.

I ended up reading the /examples folder on the repository and found this:

Bingo! Here it is:

URL substitution stringdd-wrt fieldsNamecheap REST key
%uUsernamedomain
%pPasswordpassword
%hHostnamehost

generic.c is a plugin also shows the above table as well


Since namecheap’s dynamic DNS service do not mandate how frequently you can update nor they charge per update, it’s easiest and most reliable to just blindly update the IP every N minutes instead of checking against a local cache to see if the external IP has really changed before updating at each poll interval

This user interface does not have the option to set the updater to run every 1 minute, so why bother since it’s just a simple program that creates a simple URL and do a curl/wget? At the end of the day, I decided to just do a cron job:

PATH=/sbin:/usr/sbin:/bin:/usr/bin
* * * * * root curl "https://dynamicdns.park-your-domain.com/update?host={subdomain or @}&domain={domain name bought}&password={generated by namecheap's account management page}"

There are 3 things that you will need to know:

  • Paths is from a clean slate. Need to define it first
  • * * * * * means every minute. Specify numbers/range for each time unit (minute, hour, day of month, month, day of week) if desired. Asterisk means ON EVERY.
  • Need to specify the user after the time syntax and before the actual command

Loading

dd-wrt gotchas

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}

Loading

Remote Desktop INTO Linux GUI (xrdp)

To serve Linux Desktop just like other Windows computer through Windows Remote Desktop (formerly Terminal Services), so far I have found xrdp (xorgxrdp). VNCs, NX (NoMachine)/TeamViewer does not count because they share the screen of an existing session, instead of creating a new one for you.

Xrdp does not follow the use pattern as Microsoft’s RDP. When you log in to a Xrdp host (server) through a RDP client, you go into an intermediary (welcome interface) called sesman (Session Manager), which is a multi-protocol remote graphical session client (think of it as a very rudimentary Remmina).

“Session” is the roughly same as protocol, which formerly and internally it’s called “Module” as the client programs are in implemented lib*.so object module file.

The two session modules we are interested in here is

  • Xorg (libxup.so): Xorgxrdp is the MS-RDP-like mode that starts a new X session without first attaching to a screen.
  • Xvnc (libvnc.so): basically a VNC client. You start a VNC server (like X11vnc) with a display/screen (can be started in any X session you logged in, or the local user screen if you set the VNC server as a service) and connect to it in this RDP intermediary (welcome interface) without installing VNC client software.

In Windows, RDP do not distinguish between local and remote users and sessions with the same login account will take over other existing sessions. If you want each session to start fresh and leave other sessions alone, disable this in Group Policy Object editor under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections -> "Restrict Remote Desktop Services user to a single Remote Desktop Services session“.

I am usually fine with this arrangement as well, but often prefer to connect to my remote sessions work in the background leaving the local user alone (i.e. if I want things to show up on the local monitor screen, I’ll use VNC instead). I’d also like to resume my remote sessions if I log in from another computer instead of starting from scratch with each new RDP connection. Turns out given a bunch of quirks of xrdp, this is much easier to do so than reproducing MS-RDP’s default behavior.


Allow overtaking of locally logged-in session

First of all, out of the box, the same remote user cannot overtake locally logged-in desktops nor be simultaneously logged in! It’s either one way or the other! I got bumped out immediately after logging in through sesman, or if I logged in remotely first, I get bumped out when I try to log in locally.

Found somebody suggested that certain desktop environment might have added code to prevent the second session from opening. And this blog suggested you edit the windows manager launch script

sudo nano /etc/xrdp/startwm.sh

to add EITHER

unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR

OR

export $(dbus-launch)

RIGHT BEFORE the last lines which checks and calls the Xsession

test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession

This only solves the part of simultaneous local & remote logons


In the newer version as of writing, the default behavior is that locally logged in sessions are independent of remotely logged in sessions, yet the remotely logged in sessions resumes by default (if you log in as the same user).

Turns out this is what I preferred as the local sessions should be reached with VNC instead and I’d prefer my remote sessions happen at the background without showing it on the local screen.

As of now (2020-03-17), the author of xrdp mentioned in his blog that a remote session cannot take over a locally logged in session like Windows RDP does:


Generic VNC client hosted on RDP server

The interface also offer a built-in VNC client that you can use it to connect to your current session if you have VNC server enabled so you don’t have to install a separate VNC client from the client machine you are connecting from. In other words, xorgxrdp self-hosts a VNC client within xrdp so you can use your RDP as a VNC client.

Since the VNC server (like x11vnc) only has a password (not using system’s active directory or user management system), there is no user name. I went to [Xvnc] section of xrdp.ini and replaced username=ask with username=na. The port number -1 no longer applies as we aren’t emulating RDP with VNC anymore (where sesman creates a new VNC server instance if not previously done). Given that I’m running VNC as a service at default port 5900, I also changed it to port=5900.


Other less important features in xorgxrdp

Session/Module “vnc-any” uses the same libvnc.so as Xvnc before it, and they are pretty much the same thing except it exposes ip:port entry so you can use it as a gateway to connect to VNC servers hosted on other machines (can be used to connect to the VNC server on the current machine you just connected to through RDP if you stick with 127.0.0.1:5900). It’s more like a convenience thing that hosts the VNC client software that you can RDP into (so you don’t need to install a VNC client from where you are).


There is also a RDP client module/session called ‘neutrinordp-any’, which basically uses the linux machine you just connected to as a gateway to visit another machine hosting RDP. It’s rarely useful and it doesn’t work out of the box when I tried it (does nothing after I press OK despite entering all the info correctly). So I removed it from my xrdp.ini


Minor annoyances to deal with in xrdp

There’s also a minor annoyance that if you connect remotely, “Authentication Required…” message box will show up on start since remote user is a little more restrictive than local users. This can be solved by creating this file with nano

sudo nano /etc/polkit-1/localauthority/50-local.d/46-allow-update-repo.pkla

and paste the contents there and save it:

[Allow Package Management all Users]
Identity=unix-user:*
Action=org.freedesktop.packagekit.system-sources-refresh
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Loading

Run VNC server before logging to Linux GUI

I installed X11vnc and to my dismay, there isn’t a easy option that automatically configures VNC as a service like most Windows VNC software does (so you can VNC into a computer before you login as a user graphically and launch the X11vnc executable).

I had to manually create a service and I ran into a few problems as the instructions on StackExchange and other forums are missing critical pieces.

In here, I will use X11vnc server on Ubuntu Cinnamon (systemd) as an example. Instead of blindly pasting code here without context, I’ll sketch out the ideas here:

  1. Establish a password in a password file stored in common areas such as /etc/x11vnc.pwd instead of using the user-specific home folder default ~/.vnc/passwd
  2. Create a service (such as systemd) pointing to x11vnc program with the right parameters, which includes the path to the password file stored in common areas
  3. Start the service

It’s worth nothing that the X11server connection is unencrypted. I tried the -ssl options but my RealVNC clients complained about their version


First of all, x11vnc -storepasswd creates the encrypted password file at the current home folder where you run the code. You are going to call the said password file with x11vnc -rbfauth {path to password file} parameter when launching the X11vnc server program.

One way to do it is to copy the created password to a system-specific configuration folder instead of user’s home folder:

sudo cp ~/.vnc/passwd /etc/x11vnc.pwd

Alternatively (which I do not recommend), is to specify the password AND the password-file path directly with optional specifiers of the -storepasswd parameter.

# Directly create the password file without a prompt that hides the password entry
x11vnc -storepasswd my_pASSword /etc/x11vnc.pwd
# Clean up your terminal command history since you've exposed the password visually
history -c

Unfortunately, if you want to specify the path to the password-file, you have to specify type the plain text password in the command line, which you should do it when nobody’s watching and clear the history immediately afterwards. If you are in a public place, just do it the old way and copy the password file over


The core part of setting (doing the data-entry) for registering a service is the figuring out the command line parameters executing x11vnc program. At minimal, you’ll need

  • -rfbauth specifies where the password file is (or you can directly specify the password with -passwd, which I do not recommended)
  • auth: authentication means (prefers –auth guess, but you can specify where your .Xauthority file is)
  • -display: 0 connects to the X11 server display, which is usually 0
  • -create is the missing link! you must absolutely use this tell the VNC server to make a Xvfb (X virtual framebuffer) session if no display session is found (which is the case when you are running X11vnc as a service before logging in the a Desktop Environment like Cinnamon)

You’ll typically want this for a constant-on VNC server

  • -forever: x11server instances are by default (-once) killed after the client disconnects. -forever option keeps it there

My personal preferences

  • -shared: I might have a few computer VNC’ing into the linux computer and I don’t want to make sure I remember to close the ones I’m not using.
  • -noxdamage: XDamage is a system that only updates the changed parts of the screen. Don’t need it when bandwidth isn’t super tight.
  • -repeat: allow hold and repeat keystrokes just like what we are used to. By default it’s set to -norepeat to avoid stuck key scenarios.

For debugging (useful! that’s how I figured out the missing part that I have to use -create to make a dummy screen when using x11vnc as a service):

  • -o {output log file}: typically -o /var/log/x11vnc.log
  • -loop: if the program crashes for any reason, it’ll try to auto-restart for robustness. Might not need it if you use -forever

So the core command needed is:

x11vnc -repeat -noxdamage -create -display :0 -auth guess -rfbauth /etc/x11vnc.pwd -shared -forever

Now after we’ve decided the exact launch command, we will have to create the service entry. In systemd Linux, it’s done by writing a service configuration file in text format very much like Windows INI files under /etc/systemd/system and the filename MUST end with suffix “.service

In short, create /etc/systemd/system/x11vnc.service. Basic file without logging is like this:

[Unit]
Description=VNC Server for X11
Requires=display-manager.service
# The two below are for performance (make sure everything is ready before launching)
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/x11vnc -repeat -noxdamage -create -display :0 -auth guess -rfbauth /etc/x11vnc.pwd -shared -forever
# The 3 lines below are option, but for robustness
ExecStop=/usr/bin/x11vnc -R stop
Restart=on-failure
RestartSec=2

# For automatically creating symlinks with "sudo systemctl enable" only
[Install]
# Start at runlevel 5 (multi-user)
WantedBy=multi-user.target

This is the minimum skeleton that does the same less robustness against the unexpected:

[Unit]
Description=VNC Server for X11
Requires=display-manager.service

[Service]
ExecStart=/usr/bin/x11vnc -repeat -noxdamage -create -display :0 -auth guess -rfbauth /etc/x11vnc.pwd -shared -forever

[Install]
WantedBy=multi-user.target

The default permissions 644 (everybody reads but only root can write is standard for services. 640, denying unknown people the read access is also acceptable if you are paranoid) should be correct if you use sudo creating the file in the /etc/systemd/system folder.

There are some older tutorials using the (/usr)/lib/systemd/system folder, which are now reserved for automatic entry by programs instead of manual service entry like what we are doing now. Technically either way works, but follow the convention so people know where to find the entries.


After that enable the service file you’ve created (the “.service” suffix is optional when calling), preferably do a daemon-reload to make sure edits in the service file is reflected. If you don’t want to wait until the next book, you can start it with systemctl

sudo systemctl enable x11vnc
sudo systemctl daemon-reload
sudo systemctl start x11vnc

This kind of stuff in Linux is bitchworthy. It’s 2021 now. How come users need to mess with defining their custom services for such a common VNC use case (start before logging in graphically)? Never have to deal with this kind of shit in Windows with VNCs: they always expect users has the computer to themselves and always offer the option to set up the service automatically!

Loading

XFX TS Series 550W Power Supply – Made In China – Bulging Capacitor because it was installed backwards

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

ElectroBOOM!

Loading