Category Archives: system administration

ddwrt router refusing to forward multicast packets over an OpenVPN tap device joined to a bridge

Trying out the go-chromecast CLI, I was able to see mDNS requests coming to my home network over OpenVPN (a L2 tunnel using a TAP device bridged using br0 on both ends). I could also see responses being generated, but none of them were seen on the other end. The build of dd-wrt I use has no tcpdump, making it hard to observe both ends of the tunnel.

There's a lot of sources suggesting a bunch of actions:

However, that was all tapping in the dark.

But when someone mentioned ebtables, nat and PREROUTING, this led me to the right path: what if one of the chains in one of the tables was dropping outgoing packets?

# ebtables -t nat -L POSTROUTING
Bridge table: nat

Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
-o tap1 --pkttype-type multicast -j DROP

Voila. All multicast packets were being dropped on L2.

# ebtables -t nat -D POSTROUTING -o tap1 --pkttype-type multicast -j DROP

This is fine because I happen to control both ends of the tunnel. Because my systems use multicast only for mDNS, I don't expect traffic to require drops.

On the bridge device (br0 on both ends), I currently have multicast_router set to 2 on both ends; I have multicast_querier set to 1 on both ends; non-ddwrt system has multicast_igmp_version set to 2; and multicast_snooping is set to 1 on both ends. I don't claim correctness of any of these, nor do I claim them to be optimal. But, getting mDNS traffic through is exactly what I wanted, so I'm happy right now.

Exploring the sudoers file: "sudo: sorry, you are not allowed to preserve the environment"

On my NAS I've received sudo: sorry, you are not allowed to preserve the environment today when running sudo -E to transfer the environment from whatever the current shell allows sudo to see, into the new shell.

That's because I was copying something from a remote machine to my NAS, and I (temporarily) wanted to tell remote rsync to use sudo rsync on my NAS to be sure files will be replicated correctly. While this is an absolutely horrible idea to do permanently, a temporary workaround in a safe environment is that sudo rsync should not require a root password:

ivucica ALL=NOPASSWD:/usr/bin/rsync

However, compare this to some of the defaults in /etc/sudoers:

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Without reading the sudoers(5) manpage, I decided to add ALL at the end:

ivucica ALL=NOPASSWD:/usr/bin/rsync ALL

This seemed to work, but despite a lack of a syntax error, it's wrong (see below): now no password is required for rsync nor for any other command.

# Wrong order:
 ALL=NOPASSWD: /usr/bin/rsync, PASSWD: ALL
# Correct order:
ivucica ALL=PASSWD: ALL, NOPASSWD: /usr/bin/rsync

The best option, however, is to remove the entry completely given that allowing rsync root without a password is dangerous; even if someone managed to hijack my own account's non-password NAS credentials, without the password itself they can't do much.


However, looking online for this error, I realized I've never looked into the syntax of the sudoers file. What's Defaults env_reset, for instance? Turns out sudoers(5) is an interesting read. If you're seriously going to play with editing /etc/sudoers beyond just adding a user (even just specifying the NOPASSWD tag), please read the manpage and carefully experiment. Cover all the edge cases you can think of. Have someone else review your changes.

Here's some interesting stuff:

  • #include (and presumably #includedir) directive to include a file can contain %h (a hostname) in file path
  • to match all users except root, instead of ALL we can specify ALL,!root
  • you can do things like disable setting utmp (set_utmp) or prohibit the capability to disable env_reset (setenv) — which is what I did
  • the first-time "lecture" status ('has this user seen the sudo lecture?') is in /var/lib/sudo/lectured and configurable using lecture_status_dir
  • the password prompt can be overridden with passprompt and can include %H FQDN, %h hostname, %p the user whose password is requested, %U the user whom we're switching to [caveat: PAM module's output must match Password: or username's Password:
  • there are ways to specify directives per running host (important for standardized configs deployed across an org), per requesting user, per run-as user, per command
  • there are tags to tweak execution of a command

While I haven't actually tried all of the following, here are some "notes-to-self" on what individual fields mean. Please prefer learning the details from the manpage.

What does ALL before = mean? Those are the hosts. For instance, we can let roger run anything on all the fileservers:

Host_Alias FILESERVERS = fs1, fs, fs3
Host_Alias INTERNAL_NETWORK = 192.168.55.0/255.255.255.0
Host_Alias FINANCE = 192.168.75.128/25, 192.168.75.15

roger FILESERVERS = ALL

(Just like Host_Alias, there's User_Alias, Runas_Alias and Cmnd_Alias.)

What's (ALL:ALL) after =? That's called a Runas_Spec and it's saying "You can pretend to be any user of any group." Let's only allow roger to run only /usr/bin/rsync and only to do it as mainweb:

User_Alias     FINANCE_DEPLOY      = james, mike
roger          FILESERVERS         = (mainweb) /usr/bin/rsync
richard        richard-workstation = (www-data) ALL
FINANCE_DEPLOY FINANCE             = (financeweb : financeservices) /usr/bin/rsync

And what's the ALL after (ALL:ALL)? As demonstrated, that's the command specification.

Alright, so what's NOPASSWD:? That's a Tag_Spec. Each command may be prefixed with zero or more tags associated with it, such as EXEC, NOEXEC, PASSWD, NOPASSWD, MAIL, NOMAIL. For instance:

# Allow ls and cat without password, but require a password for vi.
richard richard-workstation = (www-data) NOPASSWD: /usr/bin/ls, /usr/bin/cat, NOEXEC: PASSWD: /usr/bin/vi
richard richard-workstation = (www-data) NOPASSWD: /usr/bin/ls, /usr/bin/cat, PASSWD: /usr/bin/vi

Allowlisting only some commands results in the following when a non-allowed command is run:

Sorry, user richard is not allowed to execute '/bin/bash' as root on my.machine.hostname.

And attempting to run a command from within vi when NOEXEC is specified results in:

Cannot execute shell /bin/bash

There's even a way to set things like timeouts. But, again, read the manpage for details.


As usual, this is not advice; these are personal notes from trying to resolve an immediate issue. As this is a security-sensitive feature, for even one person that reads this and configures an important system incorrectly, please note: these notes are written as a hobby. Just like you would with PAM, NSS, LDAP, Kerberos and other things, please carefully read more authoritative documentation sources; I'm not responsible for breakage you may cause with my non-advice.

Ubiquiti mPower PRO (EU): First steps after unpacking

I've been happy enough with my mid-range mPower (EU edition) that I bought an mPower PRO (again, EU edition). I finally got around to unpacking it and setting it up.

mPower mini, mPower and mPower PRO are Ubiquiti Networks' IP power outlet product. They run Linux on them. There's web UI, and it's also easy to SSH into the device out of the box (username is ubnt and password is ubnt). This makes the device easy to script for: all power use statistics and remote control are exposed as files in /proc/power. An app for Android exists as well.

I purchased the mPower PRO simply because I needed a few more plugs to control. Difference between mPower and mPower PRO is that the latter has six instead of three plugs, and it has both WiFi and an ethernet port (all smaller models have just WiFi).

Since my previous post) was originally written in August 2014, I discovered that a newer firmware has a nicer web UI, and changing the default username and password is not really a problem anymore either. So I ended up flashing the device, then factory-resetting it. Given how nicer web UI is important to me, this means this will be the first step with my today's setup of mPower's "bigger brother".

Unboxing and connecting

The box contains the device, a wall-mount and a small manual. I'm interested in just the device, of course.

First difference is that mPower PRO will not bring up a wireless network you use to set it up. Instead, you must connect it via the ethernet port. This is fine; I'm happy that I lucked out and had an extra ethernet cable lying around.

mPower PRO picked up an IP address over DHCP immediately. To find out what to punch into the browser, I just looked at my router's DHCP leases and saw what device is outside the statically-assigned range (I hand out IP addresses based on known devices' MAC addresses). I then added the new MAC address to the list of known ones, and assigned a new static IP to it. (By the time I am writing these lines, the original lease expired and the device already has the new IP address.)

Upgrading firmware

This mPower PRO shipped with v1.2.6 firmware, which means I have to use the manual upgrade method. So I've downloaded the 2.11.1 firmware and:

scp firmware.bin ubnt@198.51.100.84:/tmp/fwupdate.bin  # RFC-5737 example IP range \o/
ssh ubnt@198.51.100.84 -t /sbin/syswrapper.sh upgrade2

Password is, as previously mentioned, ubnt. This will take a while. Don't unplug the device while it's being flashed. After a few minutes you'll probably get something like Write failed: Broken pipe. This is fine.

In future, you can use web UI to flash an upgraded firmware.

Logging in and changing password

If your device is at 198.51.100.84, then just visit http://198.51.100.84/ and log in with username ubnt and password ubnt. You probably don't want others to be able to log in with the same credentials, so change them as soon as feasible.

On the System tab, next to the field 'Administrator Username' and its value ubnt, there should be a small icon of a key. Click on it. Then, change the administrator username, enter the old password ubnt, then enter the new password twice. Then click the 'Change' button which is above the 'Management' section and below the 'NTP' section. You'll get asked whether to apply the changes. Do apply them.

Hooray! mPower PRO is sufficiently ready for basic use. At some point I'll go ahead and assign port names which doesn't seem to be doable through web UI.

mFI mPower basic use without cloud and controller

Updated 29 December 2014: With the latest software (currently 2.1.4) there is actually a decent, password-protected standalone web UI. I'd recommend you to factory reset the device, set it up from scratch, and set a new username and password from the web UI. You'll still be able to log in over SSH and telnet, and while I no longer need to access the device directly, I'm sure most of the article below applies.

To upgrade from 1.x series software, which is what I had, you should use scp to upload the new firmware to /tmp/fwupdate.bin. To upgrade from 2.x series software, which has the nicer web UI, just use the web UI. Details.

Just to note: Of course, while I don't need to use connectivity over terminal, this seems to be used by software such as this nice Android app. The app seems thirdparty (despite the ID being set to com.ubnt.mpower), so it would have been harder to put together if there was no terminal access. Heck, I can even envision management software using not much more than sshfs and ssh to manage a fleet of mPowers (if you happen to need and have such a fleet)…

Original text follows.


After getting the mFI mPower unit, I saw that it really wasn't planned for standalone use. I was also surprised at seeing no ethernet port; I'm not sure why I thought it's going to have one.

This is a wifi IP power strip that seems to be designed neither fully for a consumer (why would a consumer need a IP power strip?) nor for an expert. After plugging it in and waiting for it to boot, you're greeted with a new completely unprotected wifi network. After connecting to it, you're hijacked in the same way captive portals technologies work. It seems pretty painless to configure a device to connect to a wifi network, and then either to cloud or to a local controller — a chunk of proprietary software that, based on the quick guide booklet, seems to be written in Java. Booklet mentions versions for Windows and OS X, but the website offers download for Linux as well.

I'm however uninterested in having a home machine run 24/7 and waste electricity just to occasionally control a power strip. I opted for the (for obvious reasons less secure) variant of going into the cloud. Unfortunately, the built-in web UI doesn't give you an option to register nor a hint on doing so. Quick guide does mention the website, which reveals a login panel but no registration.

At least I could configure wifi connectivity without either controller software or cloud — but that seems to be all.

That's because in October 2013 the service was shut down for new registrations, with promises of coming back. Seeing that was 10 months ago, I began to think I may have purchased a brick.

Luckily, apart from what's served to the customer on the surface, the device seems to be rather open. I'm unfamiliar with how free and open source it is, but it seems to be built out of relatively understandable components. BusyBox is there, the usual UNIX-like directory structure is there. I also spotted dropbear, which means aside from a telnet daemon, it's also providing an SSH service.

Default username and password set is ubnt/ubnt. Ouch. First obstacle: How do we change that?

We can use vi to edit /tmp/system.cfg. There it is! Username and password. But wait — what kind of a password hash is that?

Turns out it's the output of crypt(3). This gets used to generate /etc/passwd.

PHP has the crypt() function as well. PHP's numerous flaws are irrelevant for such simple use case, so we'll be forgiven for using:

php <<< '< ?php echo crypt("my_password", "SL");'

where "SL" is the salt. (In the stock password, it was "KQ".)

You can add new users as well (although I'd highly advise changing at least the password of the default user), like so:

users.1.name=ubnt
users.1.password=KQiBBQ7dx8sx2
users.1.status=enabled
users.2.name=ivucica
users.2.password=AEPbWtbh7XaS.   
users.2.status=enabled

That's really nice and flexible. But they could have either documented all this (and in an obvious place), or created a web UI (of course, while letting us deal directly through telnet and ssh, too).

To save these settings, punch in save. (Alternative command seems to be cfgmtd -f /tmp/system.cfg -w.) To give the system a chance to apply the settings, reboot.

While at it, you may want to disable the default unprotected wifi network, which for me was numbered 2:

wireless.2.status=disabled

What I also like in this device is that it seems to have the Linux-friendly Atheros chipset in it.

So next. How do we actually read stats or switch an outlet on or off?

cd /proc/power
# enable outlets we want to read stats from or that we want to control
for i in $(seq 1 3) ; do
  echo 1 > enabled${i}
done
# get current power usage
for i in $(seq 1 3) ; do
  echo "active_pwr$i: ${i}"
done
# turn off and on a slot
echo 0 > relay1
sleep 1
echo 1 > relay1

Other functionality is demonstrated and explained by forum member Sequim.

  • active_pwr – power factor corrected power demand
  • v_rms – RMS voltage – zero if outlet is off
  • i_rms – RMS current, as currently delivered
  • pf – power factor
  • energy_sum – totalized energy in Watt-hours delivered via this outlet, probably since last boot

And the /proc/led directory contains some nice controls for the LED.

Really lovely design. It'd have been even nicer if it had been properly documented and if it had a proper web UI shipped in case you don't feel like dealing with all the power that these controls exposed as a filesystem provide.

Mails appearing from d1stkfactory

If you have a Debian machine and emails appear to be coming from hostname @d1stkfactory, edit /etc/mailname and set this to your actual FQDN. Another instance where I found it locally is in /etc/exim4/update-exim4.conf.conf, which is almost certainly not read by my installation of Postfix (which does explicitly refer to /etc/mailname in one place).

This appeared on a machine running on DigitalOcean, so I presume "d" refers to DigitalOcean, and "factory" refers to their internal disk image building service. That's just speculation though.

Switched to nginx

I've switched the server to nginx. I don't have too many htaccess-based rules, and overall the Apache2 configuration was very simple to begin with. I installed php5-fpm, followed tutorials on configuring nginx (moving what'll be common among 15ish virtual hosts into a separate file), configured proxying for XMPP BOSH and finally improving SSL security.

Apache2 now sleeps quietly and the RAM usage is down a bit. Hopefully the server won't suffer any more hard crashes due to lack of RAM like it did immediately after I moved to the new host.

Overall, nginx seems like a much lighter and easier to understand solution for my very simple needs; if you're running a simple server, I recommend it (as long as you read a bit about its security, if you intend to use it for serving PHP!).