Picture of Jürgen Kreileder

Archive for the ‘Config’ Category

Speedport Routers Eat Your DNS SOA Requests in Modem-Mode

Some years ago I switched to using a Speedport W701V from Deutsche Telekom on my ADSL line at home. I set it up in modem-mode and let a small Linux box handle everything else. This setup had worked fine with other modems but shortly after switching to the Speedport I noticed that my local caching DNS server didn’t work correctly anymore. I didn’t really connect the dots at this point, though.

That happened a few days later when I tried to use Apple’s Back to My Mac — it just didn’t work. After some network tracing I found out that the Apple machine sent DNS SOA requests but never got a reply back. It turned out that all SOA request got blocked somewhere. Sending requests to my own name server (host -t soa blackdown.de ns.blackdown.de) and tracing DNS there showed that no packet ever arrived.

I put the Speedport back into router-mode at this point and, who would have guessed it, SOA requests worked fine again.

After fruitless discussions with Deutsche Telekom support (it was impossible to find anyone who even remotely understood what I was talking about) and sending a bug report to AVM (the 701V actually is a FRITZ!Box) which never got an answer, I finally solved the problem by putting a Freetz firmware on the Speedport. This firmware had an option to disable the PPPoE-Filter. After disabling the filter the device worked flawlessly in modem-mode.

Now, a few days ago, I switched to VDSL and got a new router: a Speedport W920V.
First thing I did was to put it into modem-mode. And there it was again, the DNS SOA problem!

Knowing what the problem was, I found a simpler fix this time:

  1. Download the configuration from the device
  2. Manually change dnsfilter_for_active_directory = yes; to dnsfilter_for_active_directory = no; in the pppoefw section
  3. Manually change ipnetbiosfilter = yes; to ipnetbiosfilter = no; in the pppoefw section
  4. Insert a NoChecks=yes line after the Country=… line in the header to make the device accept the modified file although its checksum is wrong now
  5. Upload the modified configuration to the device

(If you have a local NTP server, you also might want to add it to the server_list in the ntpclient section while editing the configuration of the Speedport.)

WordPress SSL Patch Update

The recently released security update for introduced some changes that broke my HTTPS patch for it. I have updated the patch for WordPress 2.0.6 and 2.0.7-RC1 now: wp2-ssl.patch.

Read the complete SSL setup guide here: Securing WordPress 2 Admin Access With SSL

Regarding WordPress security, please note that there still is a possible exploit for 2.0.6: New WordPress exploit also affects version 2.0.6
Make sure you use safe a PHP version and set register_globals = off.

Miscellaneous ALSA Patches

I got a new PowerMac G5 Quad a couple of weeks ago. Nice machine, except for the weak graphics and non-existent sound support on Linux.

The built-in sound card is completely unsupported at this time. As I did not feel like writing a driver for it, I plugged in an old USB sound device (Creative Sound Blaster Audigy 2 NX). At first this did not work, I just got oopses. But with a small fix (included in the kernel since it started to work.

Next I tried to set up ALSA‘s dmix plug-in with S16 which resulted in horrible crackling: The byte swapping code was broken.

Also, ALSA’s softvol plug-in (not strictly necessary but nice to have with GNOME’s volume control applet) didn’t work, it did not support any format available with snd-usb-audio on big-endian machines.

Here are the fixes for these two problems (against alsa-lib-1.0.11rc3):

If somebody is interested, here is the USB-Audio.conf I use with my Audigy 2 NX.

By the way: Is it normal that the dmix plug-in consumes 100% CPU?

April 9th, 2006: The patches have been integrated into alsa-libs 1.0.11rc4, the 100% CPU issue is fixed in that version too.
There’s also a ALSA driver for the chip in the PowerMac Quad now, see this mail from Johannes Berg.

Securing WordPress 2 Admin Access With SSL

A few people have asked for an updated version of my Securing WordPress Admin Access With SSL guide. So here is an updated version for 2!

The situation has not changed much since WordPress 1.5: WordPress 2.0 still does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP and I still do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:

The Goal

All communication involving passwords or authentication cookies should be done over HTTPS connections. wp-login.php and the wp-admin directory should only be accessible over HTTPS.
Normal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.

The Plan

  • Add an HTTPS virtual host that forwards requests to the HTTP virtual host
  • Modify WordPress to send secure authentication cookies, so cookies never get sent over insecure connections accidentally
  • Require a valid certificate on HTTPS clients. That means to log in to WordPress you need both a valid certificate and a valid password. If someone manages to get your password, he still can not login because he does not have a valid certificate.

The Implementation

Note: This documentation assumes a Debian sarge installation with 2. Some things, in particular Apache module related ones, will be different on other systems.
The server used throughout the instructions is example.org/ The server’s DocumentRoot is /blog and WordPress resides in /blog/wp. The value of WordPress’ home option is ‘http://example.org’ and the value of its site_url option is ‘http://example.org/wp’.

  • Prepare the SSL certificates:
    • Generate your own certificate authority (CA) if you don’t have one already (I’m using the makefile from OpenSSL Certificate Authority Setup for managing mine) and import it into your browser.
    • Generate a certificate for the SSL server and certify it with your private CA.
    • Generate a certificate for your browser and certify it with your private CA. Most browsers expect a PKCS#12 file, so generate one with
      $ openssl pkcs12 -export -clcerts \
          -in blogclient.cert \
          -inkey blogclient.key \
          -out blogclient.p12

      Then import blogclient.p12 into your browser.

  • Make WordPress SSL-ready:
    Apply this patch to the WordPress code. It makes the following changes:
    • Use secure authentication cookies in wp_setcookie()
    • Make check_admin_referer() work with HTTPS URLs
    • Use HTTPS URLs for notification mails
    • Use HTTPS URLS for redirects to wp-login.php
    • Only allow XML-RPC logins from the local host (ie. the HTTPS proxy)
    • Add the Mark-as-Spam feature from trunk

    The patch is against svn version 3825 of WordPress (ie. WordPress 2.0.3), when you apply it to a newer version, you will likely get some harmless ‘Hunk succeeded’ message. If you are getting ‘Hunk FAILED’ message, just send me note and I’ll update the patch.

  • Enable the necessary Apache modules:
    • Install mod_proxy_html. It will be used to replace absolute ‘http://example.org’ HTTP URLs in the WordPress output with ‘https://example.org’ HTTPS URLs:
      $ aptitude install libapache2-mod-proxy-html

      The module gets enabled automatically after installation.

    • Enable mod_proxy and mod_ssl
      $ a2enmod proxy
      $ a2enmod ssl

      Debian provides sane default configurations for both modules. You might want to take a look at the configuration files (ssl.conf and proxy.conf) nevertheless.
      I have changed SSLCipherSuite to


      in ssl.conf in order to just allow TLS v1 and SSL v3 ciphers which provide strong encryption and authentication (see ciphers(1)).

    • If you are compressing WordPress output (that is if you enabled the ‘WordPress should compress articles (gzip) if browsers ask for them’ option) then also enable mod_headers:
      $ a2enmod headers
  • Configure Apache to listen on the HTTPS port
    $ cat > /etc/apache2/conf.d/ssl.conf << EOF
    <IfModule mod_ssl.c>
    	Listen 443
  • Modify the blog virtual host to limit access to wp-login.php and wp-admin to the local host. Also completely deny access to files which should never be accessed directly. Here is an example: 10-wp2-example.org
  • Now setup the HTTPS virtual server: 20-wp2-example.org-ssl
    If you are compressing WordPress output you have to enable the RequestHeader line.
  • Enable the site and restart Apache
    $ a2ensite 20-blog-ssl
    $ /etc/init.d/apache2 restart
  • Remove the old WP cookies from your browser
  • Test the new setup!

February 1st, 2006: wp2-ssl.patch updated for WordPress 2.0.1

March 11st, 2006: WordPress 2.0.2 has been released, fixing some security issues. The HTTPS patch still applies fine to that version.

March 19th, 2006: Updated wp2-ssl.patch. Changes: Fix bug in list-manipulation.php, use HTTPS for ‘Login’ and ‘Register’ links, backport ‘Mark-as-Spam’ feature from trunk

May 1st, 2006: WordPress 2.0.3 has been released. Here is the updated wp2-ssl.patch.

July 29th, 2006: WordPress 2.0.4 has been released, fixing some security issues. Here is an updated version of the wp2-ssl.patch.

January 12st, 2007: wp2-ssl.patch updated for 2.0.6 and 2.0.7-RC1

January 15st, 2007: WordPress 2.0.7 has been released. The patch still applies fine to that version.

Updated Logitech MX1000 Configuration

XOrg 6.9 and later come with a new evdev driver. Configurations using the old evdev protocol hack no longer work. So here’s an updated version of my old MX1000 configuration:

  • Build a udev rule to give the mouse device a static name: I’m using
    ACTION=="add", \
      KERNEL=="event*", \
      SUBSYSTEM=="input", \
      SYSFS{manufacturer}=="Logitech", \
      SYSFS{product}=="USB Receiver", \

    in /etc/udev/rules.d/010_local.rules.
    After restarting udev and replugging the mouse, you should see a device named /dev/input/mx1000.

  • /etc/X11/xorg.conf:
    Section "InputDevice"
     Identifier "MX1000"
     Driver     "evdev"
     Option     "CorePointer"
     Option     "Device"    "/dev/input/mx1000"
  • ~/.xbindkeysrc:
    (You have to install xbindkeys and xvkbd for this; I’m starting xbindkeys in ~/.gnomerc)
    # Backward and Forward buttons
    "xvkbd -text "\[Alt_L]\[Left]""
      m:0x10 + b:8
    "xvkbd -text "\[Alt_L]\[Right]""
      m:0x10 + b:9
    # "Cruise Control" disabled:
    #"xvkbd -text "\[Page_Up]""
    #  m:0x10 + b:11
    #"xvkbd -text "\[Page_Down]""
    #  m:0x10 + b:12
    # "Cruise Control" enabled:
    # Work-around extra events
    "~/bin/click 4"
     m:0x10 + b:11
    "~/bin/click 5"
     m:0x10 + b:12
    # Application-Switch button
    # A-Tab doesn't work
    # Use it as another Forward for now
    "xvkbd -text "\[Alt_L]\[Right]""
      m:0x10 + b:10

    Using the Application-Switch button for switching windows in GNOME doesn’t work because it would require holding down the Alt key while pressing Tab several times, xvkbd can’t do that. I’m using the button as another Forward now, it’s easier to reach than the real Forward button.
    Defining actions for the Cruise Control buttons only makes sense when Cruise Control is disabled (you can disable it with lmctl or the Logitech Mouse Applet). If it is disabled, the buttons generate 11 and 12. When it is enabled, they generate a single button 11 or 12 event and then a series of button 4 or 5 events just like scrolling the wheel does.
    I have no idea why the mouse generates 11 or 12 before starting normal scrolling in Cruise Control mode. I’m mapping 11 and 12 to a little utility (click by Jeremy Nickurak) which replaces these bogus events with normal scroll events.

  • At this point the Backward and Forward buttons should work in GNOME, KDE, and -based browsers. Horizontal scrolling should work in GNOME and KDE.
    Mozilla-based browser like need two additional changes to get horizontal scrolling working with the tilt wheel: Open about:config and set
    mousewheel.horizscroll.withnokey.action = 0
    mousewheel.horizscroll.withnokey.sysnumlines = true

January 18th, 2006: The evdev driver in XOrg 6.9 is broken on big-endian machines like powerpc. Here’s a fix.