The Advisory Boar

My headphone cable has become flaky, so I've been using a small external speaker for a while. I now need to change my volume settings so often that running alsamixer in a terminal each time was beginning to annoy me. So I looked for a systray-based mixer (I use xmobar with xmonad), and I found volumeicon (packaged in Debian as volumeicon-alsa).

I really like volumeicon. The default behaviour is perfectly sensible. Click the icon to mute, click again to unmute. Hover to see the current volume level, use the scroll wheel to change it. Middle click to "Open Mixer", which runs alsamixer in a terminal. Right click to set "Preferences".

What's more, the preferences are also remarkably sensible. You can pick the ALSA device and channel to control, and there's a straightforward menu to change the appearance and behaviour of the icon.

It's been quite a while since I encountered a new program that did exactly what I wanted with so little fuss.

I use xmonad, which needs ghc.

On my Debian 9/stretch machine, the manpages-dev package is declared to break libbsd-dev, which ghc depends on. So in practice, one must choose between xmonad and manpages-dev, which has annoyed me for a long time.

Today I tracked down a related Debian bug report and happened to notice that my libbsd-dev 0.8.3 was just one minor revision too old to avoid the conflict declared by manpages-dev 4.10-2:

$ apt-cache show manpages-dev|grep Breaks
Breaks: libbsd-dev (<< 0.8.4-1), manpages (<< 4.13-3)

I also noticed that libbsd-dev 0.9.1-1 packages were available in unstable/sid, and followed the instructions to create a backport of the package to stretch.

$ dget -x http://http.debian.net/debian/pool/main/libb/libbsd/libbsd_0.9.1-1.dsc
$ cd libbsd-0.9.1
$ sudo mk-build-deps --install --remove
$ dch --local ~bpo9+ --distribution stretch-backports "Rebuild for stretch-backports."
$ dpkg-buildpackage -us -uc

I installed the updated libbsd0 and libbsd-dev packages, and was then able to install manpages-dev for the first time in… several months, at least.

I have manpages again!

Here's how I configured Postfix to relay mail from x@example.com through smtp-relay.gmail.com:587 using the credentials set up for x@example.com on Google Apps.

There are three parts to this: making Postfix relay mail based on the sender address, teaching it to authenticate to gmail, and configuring gmail to accept the relayed mail. (Postfix was already configured to send outgoing mail directly.)

Sender-dependent relay

I created /etc/postfix/relay_hosts with the following contents:

@example.com smtp-relay.gmail.com:587

Then I ran «postmap /etc/postfix/relay_hosts» and set sender_dependent_relayhost_maps in /etc/postfix/main.cf:

sender_dependent_relayhost_maps =
    hash:/etc/postfix/relay_hosts

SMTP SASL authentication

I created /etc/postfix/sasl_passwords (mode 0600) with the following contents:

smtp-relay.gmail.com x@example.com:xpassword

Then I ran «postmap /etc/postfix/sasl_passwords» and added the following to /etc/postfix/main.cf:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps =
    hash:/etc/postfix/maps/relay_passwords
smtp_sasl_security_options = noanonymous

That enables SMTP AUTH in the Postfix SMTP client and tells Postfix where to look up the username and password for a domain.

Gmail will accept SMTP AUTH only in a TLS session, so TLS client support must be configured in Postfix (which means setting smtp_tls_security_level to "may"). But even once that's done, gmail advertises only the following authentication mechanisms:

250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH

I didn't want to worry about OAUTH, so I was left with PLAIN was the only reasonable choice. Postfix will not use plaintext authentication mechanisms by default, so I also had to remove "noplaintext" from the default value for smtp_sasl_security_options.

As an additional precaution, I also set smtp_tls_policy_maps to change the default TLS policy from "may" to "encrypt" for smtp-relay.gmail.com.

Gmail configuration

When I tried to send mail through the relay, Postfix wasn't able to authenticate:

SASL authentication failure: No worthy mechs found

SASL authentication failed; cannot authenticate to server smtp-relay.gmail.com[74.125.206.28]: no mechanism available

Google considers password authentication to be “less secure”, and you have to explicitly enable it on the less secure apps settings page. There are some other alternatives, but I was happy to take the path of least resistance here.

I did that and tried again, only for mail to bounce with this error:

Invalid credentials for relay [136.243.148.74]. The IP address you've registered in your G Suite SMTP Relay service doesn't match domain of the account this email is being sent from. If you are trying to relay mail from a domain that isn't registered under your G Suite account or has empty envelope-from, you must configure your mail server either to use SMTP AUTH to identify the sending domain or to present one of your domain names in the HELO or EHLO command. For more information, please visit https://support.google.com/a/answer/6140680#invalidcred

This message is misleading, as I found out by using openssl's s_client to establish a TLS session and then authenticating by hand. SMTP AUTH succeeded, but MAIL FROM was subsequently rejected. I followed the link in the message, which led me to the SMTP relay service support page.

The Google Apps admin console doesn't use sensible URLs, but I followed the breadcrumb trail to an “Advanced settings” page where I was able to edit the SMTP relay service settings to set “Allowed senders” to “Only addresses in my domains”, as well as to “Require SMTP authentication” and “Require TLS encryption”. Remember to “Save” the changes.

The error I got was because the “Only accept mail from specified IP addresses” option was checked for this particular domain. I could have added the IP address of my server to the list, but SMTP authentication was what was I wanted to use anyway.

I wanted to restore a clean Raspbian image on the Raspberry Pi that was running in the battery room. I could have gone and got it, but I would have had to climb a ladder.

So I thought “Why not just remount the filesystems 'ro' and dd the image to /dev/mmcblk0?”

I remounted / and /boot (after "systemctl isolate rescue.target", which stopped sshd but left my ssh session running) read-only, and dd'ed the image from an NFS mount onto /dev/mmcblk0. The dd worked fine. I used /proc/sysrq-trigger afterwards to sync and reboot (I couldn't run any binaries after the dd, which wasn't much of a surprise). The machine fell off the network as expected…

…and never came back up. So I climbed up the ladder and brought the Pi down to my desk and plugged it into my monitor. It did start to boot, and got a fair distance before the kernel panicked. I didn't bother to try to figure out the problem, just extracted and rewrote the SD card; and all was well thereafter.

But I still think my plan ought to have worked.

My mother called to tell me that people were complaining that mail sent to her address at one of my domains (menon-sen.com) was bouncing. Here's an excerpt from the bounce message she sent me:

DNS Error: 27622840 DNS type 'mx' lookup of menon-sen.com responded with code SERVFAIL

I thought it was just a temporary DNS failure, but just for completeness I tried to look up the MX for the domain, and got a SERVFAIL response. I checked WHOIS for the domain and was horrified to find this:

Name Server: FAILED-WHOIS-VERIFICATION.NAMECHEAP.COM
Name Server: VERIFY-CONTACT-DETAILS.NAMECHEAP.COM

In a near-panic (because this meant email to one of my work addresses was also being bounced), I checked a bunch of stuff: No, the whois details for the domain were not incorrect (nor had they been changed recently). No, Namecheap had not sent me any whois verification mail about the domain. No, Namecheap had not sent me any notification that it was going to suspend the domain. No, the Namecheap admin page didn't say anything about the domain having been suspended.

I couldn't find any relevant articles in the support knowledgebase, so I opened an emergency ticket with Namecheap support. They responded in an hour, and helped to resolve the problem immediately. They did admit that I didn't receive a notification because of an error on their part:

We have double-checked contact details on the domain in question and registrant details appeared to be missing on the domain due to a one-time glitch at our end. That is the reason you have not received verification email. Please accept our most genuine apologies for the inconvenience caused you.

I have always found Namecheap support to be responsive and helpful. I do appreciate their candour and the prompt response in this case as well, but I am deeply shaken that their system has no controls in place to prevent a domain from being suspended without any sort of notification (especially since they were sending me notifications about other domains registered under the same account in the same time period).

I don't know when exactly the domain was suspended. I have actually lost mail because of this incident—and at least one of them was an important response to some mail I sent. But thanks to my mother's correspondents, I think the problem was discovered before very long. I cannot afford to worry about this happening for my other domains that are up for renewal in the near future. If the same thing had happened to toroid.org, it would have been catastrophic.

I have been a happy customer of Namecheap for more than five years, and recommended it to any number of friends during that time. Along with EasyDNS (which is much more expensive), it's by far the best of the dozen or so registrars I've used over the past two decades. I have no idea where to move my domains, but I'll start keeping an eye out for an alternative.

Update, moments after writing the above: my friend Steve points out that there's something to be said for having a vendor who admits to their errors honestly; and only a pattern of errors rather than a single incident would justify moving my domains away to an unknown registrar. A few days from now, I hope to be able to properly appreciate Steve's wisdom in this matter. Meanwhile, I'm saved from precipitous actions by the fact that I haven't the faintest idea where to migrate anyway.

I have more than a passing interest in VPN software, and have looked at and used many different implementations over the years. I haven't found much to cheer about, which led me to write tappet for my personal use.

I've been reading about Wireguard for the past few weeks, and I really like it so far. It follows through on many of the same goals that I had with tappet, and goes much further in areas important to more widespread adoption. The author, Jason Donenfeld, articulates the project's design goals in this presentation.

Keeping the code small and easy to review was a primary consideration for me (tappet is under a thousand lines of code, not including NaCl). By this measure, Wireguard does an admirable job of staying small at around 15,000 lines including crypto code and tests.

When I wrote tappet, the Noise Protocol did not exist in a usable (or recommended) form. Wireguard's adoption of this framework brings a host of desirable properties that tappet lacks, notably including perfect forward secrecy.

One of my major frustrations with OpenVPN is the extraordinary time it takes to establish a TLS connection on a high-latency link. Very often, when tethered via GPRS, it will retry forever and never succeed. Tappet goes to the other extreme—it requires zero setup for encrypted links (at the expense of perfect forward secrecy). Wireguard restricts its handshake to a single round-trip, which is an entirely acceptable compromise in practice.

Wireguard runs in the kernel, thereby avoiding the need to copy packets in and out of userspace. I didn't care nearly as much about performance. Tappet is fast enough in userspace that it keps up with the fastest link I've tried it on (42.2Mbps DCHSPA+), and I didn't need anything more.

Wireguard accepts multiple peers per interface, while tappet is limited to setting up point-to-point encrypted links. The former is obviously more practical in realistic deployments. (On the other hand, Wireguard is a Layer-3 VPN, while tappet operates at L2 and forwards Ethernet frames instead of IP packets. How much that matters depends on the circumstances.)

I look forward to a time when I can use Wireguard in production.

Hassath's birthday present this year was an Intel NUC5PPYH (with 8GB of Kingston DDR3L RAM and a 250GB Samsung SSD 750 Evo) to stand in at home for her ageing Thinkpad X131E.

It took some time for the machine to reach our remote mountain abode, but we have it working nicely after spending a few hours wrestling with it. Here's a quick summary of our experience (InstallingDebianOn/Intel/NUC5PPYH wasn't really useful).

Display problems

Hassath loves her old Samsung SyncMaster 172s monitor (1024x768, VGA) and resists the idea of a new wide-format monitor. Getting the NUC to work properly with this display took the most time (but none of it was the display's fault).

We connected the monitor to the NUC's VGA port and were greeted with a "Video mode not supported" error on the monitor. The debian installer's text-mode display worked fine after boot, but we couldn't see any of the UEFI setup menus. Fortunately, we were able to sidestep the problem by using an HDMI→VGA adapter that we had ordered “just in case”. Using the HDMI output resolved the display problems with the UEFI menus.

After we installed Debian (8.1 from a USB stick created from the DVD image), X wouldn't start. The intel driver didn't work, and Xorg fell back to the VESA driver, and died while trying to set the video mode. (Also, virtual terminals didn't work at all until we added an xorg.conf snippet to force the resolution to 1024x768.) It didn't work even with the DVI-D input (via another “just in case” HDMI→DVI-D cable) on my monitor.

We stumbled around for a while, but we eventually got it working. The key was to apt-get dist-upgrade against jessie-backports to install a new kernel and drivers (e.g., libdrm-intel1). We also updated the BIOS from revision 0054 to revision 0058, but I am not sure that this was necessary, or even helpful. Xorg works with the new kernel and Intel driver. We didn't bother to check if the VESA driver would also work if we forced its use.

(Aside: we had no UEFI boot-related problems at all. We didn't even need to try the legacy boot option, either for the installation from the USB stick or to boot the installed system.)

Everything else worked

The Ethernet controller is a Realtek RTL8168h, which works out of the box with the r8169 driver. Installing the firmware-realtek package got rid of an “unable to load firmware patch” message, but the adapter worked fine without it.

The wireless controller is an Intel dual band wireless-AC 3165, which required the new kernel from backports (4.8, though 4.2+ should have worked from what we read) and the firmware-iwlwifi package to be installed. It worked fine thereafter.

The audio controller is an Intel "Braswell" 2284, which works out of the box with the snd_hda_intel driver. Audio output goes simultaneously to the headphone connector on the front panel and the glowing red S/PDIF plus headphone connector on the back. We did not try S/PDIF audio (no cable, no devices) or HDMI audio (no audio port on the HDMI→VGA adapter) or recording (no mic—or at least, no mic on my desk).

The Intel Bluetooth 4.0 controller (8087:0a2a) works out of the box with the btusb driver. We were able to pair with an Android phone and a Bluetooth speaker. We were not able to play audio to the speaker, but that is probably not a problem with the NUC, because we didn't manage to get it working with any of our other machines either.

We didn't try the SDXC card slot or the infrared sensor.

Update (2017-01-18): The SDXC card slot works fine. I used it to write a Raspbian image.

A friend had a domain registered at 123-Reg that he no longer wanted. It was coming up for renewal later this month, and he offered to transfer it to me. The domain was not locked, so I asked him for an auth code, and immediately submitted a request to transfer it to Namecheap, my preferred registrar.

The transfer failed, and Namecheap sent me mail saying the domain was locked. I checked, and it was. It had also already been transferred to another sponsoring registrar (Mesh Digital, the company that owns both 123-Reg and Domainmonster). My friend contacted support to unlock the domain, but by then of course the domain had entered the sixty-day period during which it could not be transferred again. I was forced to pay the renewal fee to them, and will now have to retry the transfer after the embargo expires.

I suppose I could think of benign explanations for the above if I tried, but I'm not feeling especially charitable about it.

I got my dad a Lenovo Yoga 300 a few days ago, and installed Debian 8 on his old Ideapad S206 before giving it to Ammu, who has been using my old (and increasingly broken) Thinkpad X120e for months now.

The Linux Laptop Wiki has a page about the Ideapad S206; the quick summary is that everything works with only a little tweaking.

Wifi worked out of the box with brcmsmac. Bluetooth worked fine after installing the firmware-atheros package. Sound input and output worked fine out of the box. The hotkeys to change the volume (and brightness, etc.) also worked. I didn't try the card reader or the webcam.

I didn't bother with the fglrx video drivers, but I had to install firmware-linux-nonfree to enable KMS (kernel mode setting) to get suspend/resume to work properly. (Hibernation worked fine anyway.)

This is a sleek and light machine, quite a step up from the earlier Ideapad models I've used. The screen is a bit shiny, but stops short of being annoying. The keypad is unfortunately very jittery—unless you are very deliberate about tapping-to-click, you'll most likely just move the pointer a bit rather than clicking. This was my father's biggest problem with the machine (and it wasn't just a matter of acceleration settings).

But it's working nicely otherwise, and I hope Ammu gets some good use out of it.

An article about Vodafone injecting javascript into web pages reminded me of a problem I investigated last year when Hassath couldn't send mail when connected through her phone's mobile hotspot.

My first response to any network problems is to run tcpdump, and I saw the following EHLO response from my own SMTP server.

250-raven.toroid.org
250-PIPELINING
250-SIZE 307200000
250-VRFY
250-ETRN
250-XXXXXXXA
250-AUTH PLAIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Vodafone is transparently proxying outgoing SMTP traffic and replacing STARTTLS in the EHLO response with XXXXXXXA, so that the client doesn't try to negotiate TLS. If you issue STARTTLS anyway—which no normal SMTP client would, but openssl's s_client can do—the TLS negotiation fails. So it's not just a downgrade attack, it's actively sabotaging TLS connections too.

This was the case in mid-2014, and it's still the case at the time of writing. I wonder how many terabytes of email logs they have collected in the meantime, how they are stored, and who is reading them.

While I was tethered to my phone, I did a bit more testing. Vodafone India doesn't seem to mess with HTTPS connections, and IMAP connections are not downgraded either (i.e., the server's STARTTLS advertisement is not modified, and the TLS negotiation succeeds). Nor did it inject any Javascript into the web pages I tried (yet).

Update (2017-10-01): I happened to read a 2014 post by Steve Atkins titled STARTTLS and misplaced outrage, which says this is a "very, very, very well known" problem with the configuration of a PIX firewall feature named "MailGuard". He writes:

The most likely scenario, by far, is that the mailserver operator is behind a PIX, and has it configured like that. As port forwarding is specific to the interface that traffic comes in on, it’s quite possible that it’s only misconfigured for traffic coming over some networks. Drastically less likely is that there was a PIX installed – backwards – on the cellular providers network. Somewhat less likely still is that they’re simply lying about what they’re seeing. But those are the only three options.

In this case, I'm the operator of the mail server in question, and I know there is no PIX involved anywhere, and I know I'm not simply lying either. I also know that the problem happens only on Vodafone's network, so—unlikely as it may be—maybe there's a PIX installed backwards on the Vodafone network?