CUPS-to-CUPS printing with server-side processing and page_log

March 30th, 2014

Printer sharing on Windows is easy: the client receives the driver from the server, presents the driver GUI and passes on an intermediate format along with the options selected in the driver to the server, which then renders the print job for the printer (usually into PostScript).

In the Unix (Mac OS X in my case, but Linux would be the same) world, CUPS is commonly used for printing. It’s very powerful, but I find the documentation severely lacks details about the exact way something is implemented in the code. Luckily, the code is open-source and Michael Sweet, the developer of CUPS who now works at Apple and still maintains CUPS, managed to create a very structured piece of software with code that’s reasonably easy to understand.

If you just add a CUPS server’s print queue as a new printer on a CUPS client, it will work fine, but you might run into some inconveniences:

Problems

  1. The job might get run through a vendor-supplied filter twice, once on the server and once on the client. This usually works fine, but the print job might significantly increase in size (observed on an HP LaserJet).

  2. The page_log on the server might not contain the number of pages and copies a job consisted of and list 1 for both instead.

  3. The page_log on the server might not contain things like page format, duplex status or attributes you manually added to PrintLogFormat.

Reasons

  1. This happens if the PPD both on the client and on the server contains a line starting with *cupsFilter, which links to a vendor-supplied filter. Such a filter usually produces a MIME type of application/postscript.

  2. This happens if the job does not get run through the pstops filter by CUPS. CUPS bypasses that filter if the client submits the job with a MIME type of application/vnd.cups-postscript, i.e. it was already run through pstops on the client.

  3. This is either caused by the same things as (1) or (2), but I’m not sure which one.

Solution

Simply add the following lines to the PPD on the client. That way, it passes the job straight to the server for server-side processing.

*cupsFilter: "application/pdf 0 -"
*cupsFilter: "image/* 0 -"
*cupsFilter: "application/postscript 0 -"
*cupsFilter: "application/vnd.cups-postscript 0 -"
*cupsFilter: "application/vnd.cups-command 0 -"

By the way, if you use Mac OS X and let the “Add Printer” wizard automatically add a print queue from a remote CUPS server discovered via Bonjour, this is exactly what it does.

Notes

If you append something like %{SelectColor} to your PageLogFormat because that’s the attribute your printer uses to determine whether it should print in color or grayscale and you’d like to log that, please note that the default value (either as specified by the PPD or as specified by you via lpadmin -d printername -d SelectColor=Grayscale or via the CUPS web interface’s “Set Printer Defaults”) will never be written to the page_log. Only deviations from the default value will be logged. The defaults set on the server-side CUPS do not matter here, this is determined by the client-side CUPS.

Per the filter(7) documentation (italic comments were added by me):

Options passed on the command-line typically do not include the default choices the printer’s PPD file. [...] use the ppdMarkDefaults [which sets all options to the defaults specified inside the PPD] and cupsMarkOptions [which sets the options to the values specified in the driver GUI] functions in the CUPS library to use the correct mapping, and ppdFindMarkedChoice [which reads from the options array composed from the defaults and the selected options] to get the user-selected choice.

WordPress Plugins

March 15th, 2014

After I recently set up a blog for a friend, I thought I’d post a list of plugins I use on the various WordPress instances I run for various people and myself.

  • Simple Custom CSS. Allows you to add custom CSS to your blog without having to modify theme files. This makes it easy to update themes in the future without breaking your customizations.
  • Include plus Shortcodes Everywhere. This allows you to create a Text Widget that displays a static page from your blog using a tag like [include id="15"].
  • Category Order. Allows you to reorder the list of categories in the sidebar.
  • KB Easy PicasaWeb. Converts Picasa links into embedded photo galleries.
  • WP Events Calendar. Gives you a simple calendar widget into which you can manually enter events.
  • Jetpack. Enables some useful features like infinite scrolling, custom CSS, sharing links, and mobile theme.
  • Akismet. A must-have spam filter if you allow comments on your blog.
  • Contact Form 7 plus Really Simple CAPTCHA. Highly flexible contact form including CAPTCHAs.
  • WP Permalauts. A must-have if you blog in a language that has accented letters or umlauts. It converts those letters to the non-accented ones in permalinks.
  • WP Hide Post. Lets you selectively hide posts from categories, front page, etc. while they remain accessible through other ways and direct links.
  • BackWPup. Does full backups of your WordPress data and database to a tarball on the server or your Dropbox. Can run on a schedule to automate the backups.

A theme that I quite like is Sunspot. You can display the featured image, title and lead text of two posts next to each other and customize how many posts you want per page in total. It also has enough space for widgets in its sidebars and is responsive. The downloadable version does not currently do infinite scrolling, but I believe hosted WordPress.com has such a version.

Calling the parent constructor in PHP 5

March 3rd, 2014

Say you write a PHP class that needs to call the parent constructor. At first sight, this is simple:
function __construct()
{
parent::__construct();
}

Say you want to pass some arguments to the parent constructor:
function __construct($arg1, $arg2)
{
parent::__construct($arg1, $arg2);
}

Now what do you do if you have default arguments?
function __construct($arg1 = NULL, $arg2 = NULL)
{
if ($arg1 == NULL && $arg2 == NULL) parent::__construct();
elseif ($arg2 == NULL) parent::__construct($arg1);
else parent::__construct($arg1, $arg2);
}

Not pretty, especially if you have many possible arguments. The obvious generalization would be
function __construct()
{
call_user_func_array(array('parent','__construct'), func_get_args());
}

However, this actually fails for two reasons on PHP below version 5.3: func_get_args() cannot be used as a function argument, and call_user_func_array does not treat parent correctly.
So here’s the entire constructor I ended up with that does absolutely nothing but calling the parent function:
function __construct()
{
$args = func_get_args();
if (version_compare(PHP_VERSION, '5.3.0') >= 0)
{
call_user_func_array(array('parent','__construct'), $args);
}
else
{
$refl = new ReflectionObject($this);
$method = $refl->getParentClass()->getConstructor();
$method->invokeArgs($this, $args);
}
}

Seriously, you have to use reflections for this seemingly simple task?!

VMware ESXi 5.5.0 panics when using Intel AMT VNC

February 13th, 2014

For compatibility with a new guest OS, I upgraded my ESXi  to 5.5 today. During reboot, it crashes after a few seconds (it briefly flashes a message about starting up PCI passthrough on the yellow ESXi boot screen). The purple screen of death (PSOD) I get looks like this:

VMware ESXi 5.5.0 [Releasebuild-1474528 x86_64]
#PF Exception 14 in world 32797:helper1-2 IP 0x4180046f7319 addr 0x410818781760
PTEs:0x10011e023;0x1080d7063;0x0;
cr0=0x8001003d cr2=0x410818781760 cr3=0xb6cd0000 cr4=0x216c
frame=0x41238075dd60 ip=0x4180046f7319 err=0 rflags=0x10206
rax=0x410818781760 rbx=0x41238075deb0 rcx=0x0
rdx=0x0 rbp=0x41238075de50 rsi=0x41238075deb0
rdi=0x1878176 r8=0x0 r9=0x2
r10=0x417fc47b9528 r11=0x41238075df10 r12=0x1878176
r13=0x1878176000 r14=0x41089f07a400 r15=0x6
*PCPU2:32797/heler1-2
PCPU  0: SSSHS
Code start: 0x418004600000 VMK uptime: 0:00:00:05.201
0x41238075de50:[0x4180046f7319]BackMap_Lookup@vmkernel#nover+0x35 stack: 0xffffffff00000000
0x41238075df00:[0x418004669483]IOMMUDoReportFault@vmkernel#nover+0x133 stack: 0x60000010
0x41238075df30:[0x418004669667]IOMMUProcessFaults@vmkernel#nover+0x1f stack:0x0
0x41238075dfd0:[0x418004660f8a]helpFunc@vmkernel#nover+0x6b6 stack: 0x0
0x41238075dff0:[0x418004853372]CpuSched_StartWorld@vmkernel#nover+0xf1 stack:0x0
base fs=0x0 gs=0x418040800000 Kgs=0x0

When rebooting the machine now, it reverts to my previous version, ESXi 5.1-914609.

A bit of playing around revealed: This only happens if I am connected to the Intel AMT VNC server. If I connect after ESXi has booted up, it crashes a fraction of a second after I connect to VNC. Go figure! Apparently it’s not such a good idea to have a VNC server inside the GPU, Intel…

Before I figured this out, I booted up the old ESXi 5.1.0-914609 and even upgraded it to ESXi 5.1.0-1483097.  Looking at dmesg revealed loads of weird errors while connected to the VNC server:

2014-02-13T11:23:15.145Z cpu0:3980)WARNING: IOMMUIntel: 2351: IOMMU Unit #0: R/W=R, Device 00:02.0 Faulting addr = 0x3f9bd6a000 Fault Reason = 0x0c -> Reserved fields set in PTE actively set for Read or Write.
2014-02-13T11:23:15.145Z cpu0:3980)WARNING: IOMMUIntel: 2371: IOMMU context entry dump for 00:02.0 Ctx-Hi = 0x101 Ctx-Lo = 0x10d681003

lspci | grep ’00:02.0 ‘ shows that this is the integrated Intel GPU (which I’m obviously not doing PCI Passthrough on).

So

  • ESXi 5.5 panics when using Intel AMT VNC
  • ESXi 5.1 handles Intel AMT VNC semi-gracefully and only spams the kernel log with dozens of messages per second
  • ESXi 5.0 worked fine (if I remember correctly)

I have no idea what VMware is doing there. From all I can tell, out-of-band management like Intel AMT should be completely invisible to the OS.

Note that this is on a Sandy Bridge generation machine with an Intel C206 chipset and a Xeon E3-1225. The Q67 chipset is almost identical to the C206, so I expect it to occur there as well. Newer chipsets hopefully behave better, perhaps even newer firmware versions help.

Leserbrief “Rentenpaket”

February 6th, 2014

Am 29. Januar 2014 beschloss die Bundesregierung die als “Rentenpaket” bekannte Rentenerhöhung. Unmittelbar darauf präsentierte Arbeitsministerin Andrea Nahles eine Werbekampagne dafür; über die am 30. Januar 2014 in der Süddeutschen Zeitung abgedruckte Werbeanzeige ärgerte ich mich so, dass ich einen Leserbrief zu dem Thema verfasste. Dieser wurde am 06. Februar 2014 abgedruckt:

Nachhaltige Politik ist das nicht 

Die Vorgehensweise der Bundesregierung, einen Tag nach dem Kabinettsbeschluss bereits eine Werbekampagne für das Vorhaben zu starten, ist schockierend. Hier wird das Parlament missachtet, das über die Gesetzesvorlage überhaupt erst noch zu befinden hat, und dem Bürger suggeriert, das Rentenpaket sei bereits beschlossene Sache. Ungeklärte Fragen werden einfach beiseitegewischt. Viel schwerer wiegt jedoch, dass der Bürger mit dieser Kampagne gezielt desinformiert wird und ihm eine komfortable Rente versprochen wird, ohne ihn über die massiven finanziellen und gesellschaftlichen Kosten zu informieren. Deren Großteil werden diejenigen tragen, die heute unter dreißig sind oder erst noch geboren werden; ebendie, die aus der gesetzlichen Rentenversicherung eine negative Rendite erzielen werden. Eine langfristige Umstellung vom Umlage- auf das Kapitaldeckungsverfahren wurde in den jüngsten Rentenreformen nicht einmal angedacht. Nachhaltige Politik sieht anders aus, aber an fehlende Nachhaltigkeit werden wir uns angesichts des zunehmenden Durchschnittsalters der Wähler gewöhnen müssen.

Michael Kuron, Frickenhausen 

Inzwischen ist auch bekannt, dass diese Werbekampagne über eine Million Euro kostet. In dem verlinkten Artikel zitiert die SZ u.a. M. Kurth von den Grünen mit “Dieses Vorgehen ist beispiellos [...]“, was ich in meinem Leserbrief ebenfalls geschrieben hatte (wenngleich es der redaktionellen Kürzung zum Opfer gefallen ist). Ebenso beklagt der Artikel, dass www.rentenpaket.de kein Wort über die Kosten verliert.

CUPS on OS X hangs after a few days, reports “Internal Server Error”

November 8th, 2013

If you set up CUPS on an OS X Server (version 10.8.5 in my case, but anything from 10.7 (where CUPS introduced sandboxing) through 10.9 (the current version) should exhibit this behavior), i.e. you enable Printer Sharing in System Preferences and run sudo cupsctl WebInterface=yes, and leave the system running for a few days, you’ll eventually run into the situation that http://localhost:631/printers will report “Internal Server Error”, and clients will no longer be able to print to the server.

Digging around CUPS’ debug log, you’ll see something like
D [27/Oct/2013:13:33:52 +0100] [CGI] sandbox_init failed: /private/tmp/05d735269fa67: No such file or directory (No such file or directory)
D [27/Oct/2013:13:33:52 +0100] PID 78980 (/usr/libexec/cups/cgi-bin/printers.cgi) stopped with status 1.

That missing file (named a different 13-digit hexadecimal name upon each restart) is the CUPS daemon’s sandbox profile.

Digging around further reveals that /var/log/daily.out contains exactly this file name:
Sun Oct 27 03:15:01 CET 2013
Removing old temporary files:
/tmp/05d735269fa67
[...]

All we need to do to prevent this from happening in the future is opening /etc/periodic/daily/110.clean-tmps in your favorite text editor and adding the line printed in bold:
set -f noglob
args="-atime +$daily_clean_tmps_days -mtime +$daily_clean_tmps_days"
args="${args} -ctime +$daily_clean_tmps_days"
args="${args} ! -group _lp ! -user _lp"
dargs="-empty -mtime +$daily_clean_tmps_days"
dargs="${dargs} ! -name .vfs_rsrc_streams_*"

Update February 2014: CUPS 1.7.1 is supposed to fix that issue; the release notes mention my reported bug. Now lets see how long it takes until Apple ships the updated CUPS with an OS X update.

Update March 2014: I just upgraded our server to OS X 10.9.2 and got CUPS 1.7.1 with it. Hooray, less than three months between bug reported and fix deployed. The sandbox profile now gets written to /var/spool/cups/tmp. In fact, that’s exactly what was changed in scheduler/conf.c in the CUPS source code: they added setenv("TMPDIR", TempDir, 1);

SSDs with TCG Opal or IEEE-1667 support

November 1st, 2013

Recently, a few SSD models have been introduced that support Full-Disk Encryption per the TCG Opal standard. Many older SSDs already support AES encryption and use the ATA password for this, which is settable in the BIOS. The advantage of Opal is that it divides the drive into a small read-only segment (technically not a partition) with a special boot loader (which prompts you for the encryption password and passes it to the drive) and the encrypted segment which contains your traditional OS and data partitions. These special boot loaders can do much more than a BIOS: for example, they can provide means for key reset and they can talk to a server on the network. They can also have multiple passwords for multiple users and they can be configured entirely from within the OS, which also allows for central management in enterprise environments.

The downside of course is that you need a piece of software to use Opal. This includes WinMagic SecureDoc (for Windows and Mac), Wave Systems Embassy Security Center (for Windows only) and several others, but also BitLocker/eDrive in Windows 8 (however, this requires IEEE-1667 support as well). This is also an advantage as it does not require hardware or OS support; so even Macs could use them (WinMagic SecureDoc already supports supported Macs until October 2013, a version for OS X 10.9 was never released).

Probably the first drive to support Opal was the Seagate Momentus FDE, which was a spinning disk. Toshiba, Hitachi and a few others also made HDDs with Opal support.

Later, the Samsung PM830 (but not the Samsung SSD 830) and the Micron C400 SED (but not the Micron C400 or the Crucial m4) came, which were only available to OEM.

The first Opal-compliant mass-market SSD was the Crucial M500 (it’s also OEM’d as Micron M500), which is also IEEE-1667 compliant. As the M500 currently offers the best GB/$ ratio of all SSDs on the market, it’s been selling superb in the five months it’s been on the market and I hope this drives more software companies to support Opal.

The just-announced Intel SSD Pro 1500 will also support Opal, but apparently not IEEE-1667.

As far as I know, these really are all TCG Opal drives on the market, currently and previously. I expect there will be more coming, but I am kind of surprised that it took this long.

If you know of any others, let me know in the comments.

Update Dec 2013: The Samsung 840 EVO also does Opal.

Update Jan 2014: Wave Systems has a list of Opal drives that work with their software. It lists some Adata XPG SX900 models, the Kingston KC300 (only certain part numbers) and some LiteOn models.

Update Mar 2014: The just-announced Crucial M550, which is very similar to the popular M500, still supports Opal 2.0 and IEEE-1667, and is explicitly advertised as Microsoft eDrive compatible. Same goes for the almost identical ADATA SP920.

Bachelor Thesis: Like-Charge Attraction in DNA

October 5th, 2013

My Bachelor thesis was published a few days ago. It is available at the Institute of Computational Physics at the University of Stuttgart as well as here.

Download

PXE-booting Knoppix 7.2

October 2nd, 2013

I have a PXE server on my network so I can easily boot Linux live images and tools when fixing computers. Knoppix 7.2 however is unable to load a network driver on most PCs (it only works with Intel E1000 NICs) after following the standard procedure:

  1. Copy the DVD image’s contents to an NFS server
  2. Boot the DVD
  3. sudo knoppix-terminalserver, follow the assistant and select all network drivers
  4. Copy the contents of /tftpboot to your PXE server and add something like this to your pxelinux config:
    DEFAULT knoppix
     TIMEOUT 2
     PROMPT 2
    
     LABEL knoppix
     MENU LABEL Knoppix 7.2
     kernel knoppix72/boot/pxelinux/linux
     append nfsdir=192.168.200.25:/data/shares/tftpboot/knoppix72 nodhcp lang=de ramdisk_size=100000 init=/etc/init apm=power-off nomce loglevel=1 initrd=knoppix72/boot/pxelinux/miniroot.gz libata.force=noncq tz=localtime lang=de apm=power-off nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 BOOT_IMAGE=knoppix

To fix the network driver issue, apply the following diff before running sudo knoppix-terminalserver:

--- /KNOPPIX/usr/sbin/knoppix-terminalserver 2013-02-12 04:21:16.000000000 +0000
 +++ /usr/sbin/knoppix-terminalserver 2013-09-30 18:52:16.055233746 +0000
 @@ -281,8 +281,7 @@
 mkdir -p "${MINIROOT}/static"

 # Check if we need the Kernel 2.6 insmod
 -INSMOD=""
 -case "$KERNEL" in 2.6.*) INSMOD=/sbin/insmod ;; esac
 +INSMOD=/sbin/insmod

 # Unfortunately, these are not integrated in ash-knoppix yet, so we need some shared
 # libs. :-(
 @@ -326,6 +325,7 @@
 for i in $MODULES; do
 awk -F: '{if($1~/'"$i"'/) {print $2}}' /lib/modules/$KERNEL/modules.dep
 done | sort | uniq | while read module relax; do [ -n "$module" ] && cp /lib/modules/$KERNEL/"$module" "${MINIROOT}/modules/net/00_${module##*/}"; done
 +cp /lib/modules/$KERNEL/kernel/drivers/pps/pps_core.ko "${MINIROOT}/modules/net/00_0_pps_core.ko"

 #umount "${MINIROOT}"
 #dd if="$RAMDISK" bs=${MINISIZE}k count=1 | gzip -9v > "${MINIROOT}.gz"

OpenWRT on TP-Link TL-WDR3600: enabling Wifi channel 12+13 and higher power on 5 GHz

August 11th, 2013

A few months ago I recommended the TP-Link TL-WDR3600 as an OpenWRT router. I did complain that it unnecessarily limits me to 50 mW in the 5 GHz. After I discovered that it also prevents me from using channel 12 and 13 (which are only available in Europe an Japan, but not in the US), I looked around for a solution.

The in-kernel regulatory database is not the issue. Running iw reg get on the router shows:

country DE:
 (2400 - 2483 @ 40), (N/A, 20)
 (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
 (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
 (5470 - 5725 @ 40), (N/A, 27), DFS

Some googling around reveals that the ath9k wireless chips have a bit in EEPROM that may be set to either US or worldwide. Apparently, there is a law in the US or an FCC regulation that requires all Wifi devices shipped to determine on the hardware level (in this case, in the driver) whether the desired frequency and power level is allowed.

Unfortunately, TP-Link simply sets the bit to US mode on all devices shipped worldwide. The stock firmware simply ignores it and offers frequency and power choice based on the selected country code. OpenWRT however (as would a stock Linux kernel) respects the bit and applies a logic AND over the selected regulatory domain and the US regulatory domain.

If you run iw phy phyX info, you can see the result:

* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)

Some earlier fixes that no longer work with the current OpenWRT involved editing the US regulatory domain in the userland regulatory database. Nowadays that’s part of the kernel itself and no longer easily possible.

Luckily, someone created a binary patch called reghack that replaces the in-driver US regulations with unrestricted ones by (as far as I can tell from the source code) permitting both 2400-2483 and  5140-5860 MHz with 40 MHz wide channels at up to 30 dBm and without any restriction flags. Only channel 14 still seems to be unavailable, but that’s not a big deal as it is only available in Japan for use with 802.11b (that 14-year-old protocol that did a maximum of 11 Mbit/s). Applying the patch is simple (it is downloadable in both source code and binary form), though I needed to perform a cold reboot after the reboot.

In Germany (country code DE), this gives me the following channel map:

* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (27.0 dBm) (radar detection)
* 5520 MHz [104] (27.0 dBm) (radar detection)
* 5540 MHz [108] (27.0 dBm) (radar detection)
* 5560 MHz [112] (27.0 dBm) (radar detection)
* 5580 MHz [116] (27.0 dBm) (radar detection)
* 5600 MHz [120] (27.0 dBm) (radar detection)
* 5620 MHz [124] (27.0 dBm) (radar detection)
* 5640 MHz [128] (27.0 dBm) (radar detection)
* 5660 MHz [132] (27.0 dBm) (radar detection)
* 5680 MHz [136] (27.0 dBm) (radar detection)
* 5700 MHz [140] (27.0 dBm) (radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)

Note that this is still not entirely what is permitted in Germany: 5150-5250 and 5250-5350 MHz may go up to 200 mW and 5470-5725 even up to 1 W. Since radar detection is not currently supported on the OpenWRT, the latter two ranges are not usable anyway. I’d have liked to turn up transmission power to 200 mW, but as it turns out, TP-Link saved a few cents on the 5 GHz power amplifier, which doesn’t even do more than 63 mW…

Warning: Before you change channels and transmission power on your Wifi devices, check with the regulation authority what is legally allowed in your location. The hardware is capable of things that can interfere with radar etc. and you should never set it to a country code other than your current location. Even then, you might be able to choose options that are not legal to operate.

For Germany, the Bundesnetzagentur has the official frequency allocation documents on their website: 2.4 GHz and 5 GHz. Other European countries should have similar authorities and similar allocations. If you’re in the US, don’t even bother applying these changes as the FCC does not permit anything beyond what OpenWRT is already capable by itself.