Yearly Archives: 2013

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

SSDs with TCG Opal or IEEE-1667 support

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, but a version for OS X 10.9 was never released. Secude has announced FinallySecure Enterprise Full Disk Encryption with support for OS X and Opal; it hasn’t been released yet and was recently sold to a company named EgoSecure.

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.~~

Update May 2014: The SanDisk X300s also has both and includes a license for Wave Embassy in case your computer does not support eDrive. Glad to see that Opal and IEEE-1667 are finally making it into a significant proportion of new midrange mass-market SSD models.

Update June 2014: The Crucial MX100 is similar to the M550 with cheaper NAND and supports the same encryption standards. The ADATA Premier SP610 is supposed to get Opal 2.0 through a firmware update later this year, but not IEEE-1667.

Update July 2014: The Samsung SSD 850 Pro has TCG Opal and IEEE-1667. The Intel SSD Pro 2500 has TCG Opal 2.0 and IEEE-1667.

Update September 2014: The Crucial M600 has Opal 2.0 and IEEE-1667, just like its predecessors M500, M510, MX100, M550.

Update October 2014: The Adata SR1010 has Opal 2.0 and IEEE-1667.

Update December 2014: Samsung SSD 850 EVO has Opal 2.0 and IEEE-1667.

Update January 2015: The Crucial MX 200, which is quite similar to the MX 100, has Opal 2.0 and IEEE-1667. The BX 100 does NOT have encryption and is based on a different controller.

Update October 2015: The Samsung SSD 950 Pro is supposed to get Opal and IEEE-1667 with a firmware update at some point.

Update January 2016: The SanDisk X400 is supposed to get a firmware update for Opal in April.

Update February 2016: The Samsung SSD 750 EVO, apparently intended to replace the 850 EVO, has Opal and IEEE-1667.

Update April 2016: The Crucial MX 300 does TCG Opal 2.0, IEEE-1667 and thus also Microsoft eDrive.

Update June 2016: The Micron SSD 1100 was announced with TCG Opal 2.0 and eDrive support.

PXE-booting Knoppix 7.2

2 Replies

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:

Copy the DVD image’s contents to an NFS server
Boot the DVD
sudo knoppix-terminalserver, follow the assistant and select all network drivers

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"

Using Serva with an existing PXE server

1 Reply

A long time ago, I set up a PXE server on my network from which I can boot all kinds of Linux tools. It uses the PXELinux boot loader to provide a menu etc. When I came across an article on how to PXE boot a Windows 7 installer using Serva, I looked for a way to integrate that into my existing PXELinux configuration.

Serva takes a Windows installer CD, patches a few files, injects a small tool into the WIM, and fires up a TFTP server and DHCP proxy. It also supports Microsoft’s BINL protocol, which lets the boot loader find out which one of boot menu entries was chosen.

I went to my Linux server and created a folder named Serva in /srv/tftp and Samba shared that. I then mapped it to Z: on a Windows machine, fired up Serva, pointed it at Z: as its TFTP root and checked the TFTP, proxyDHCP and BINL check boxes. After copying the contents of the Windows 7 ISO to a subfolder of /srv/tftp/Serva/WIA_WDS and restarting Serva, the Windows side of it all was done already.

Next, I upgraded my PXELinux to version 6.0.1 and put the following files into my tftp folder: ldlinux.c32 libcom32.c32 libutil.c32 memdisk menu.c32 netbootme.0 pxechn.c32 pxelinux.0. Then I added the following entry to my pxelinux.cfg/default:

LABEL win7-32-de-install
MENU LABEL Windows 7 i386 DE Installer
KERNEL pxechn.c32
APPEND Serva\WIA_WDS\W7_32_DE\_SERVA_\pxeboot.0 -p Serva\WIA_WDS\W7_32_DE -o 252.s=Serva\WIA_WDS\W7_32_DE\_SERVA_\boot\bcd

-p sets the PXE root path to the install ISO root and -o 252.s sets DHCP option 252 to the full path to the BCD (making all the BINL stuff unnecessary). Two more symlinks and we’re all set:

cd /srv/tftp
ln -s Serva/WIA_WDS .
cd WIA_WDS/W7_32_DE/_SERVA_
ln -s pxeboot.n12 pxeboot.0

Now the only issue that I still have is that the network share path still contains the name of the computer that originally ran Serva. This can be fixed in the BCD using a hex editor.

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

22 Replies

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.

HP StorageWorks P2000 G3

5 Replies

Hardware

To replace a 2006 Xserve and a 7TB Xserve RAID at the university, we recently got a Mac mini server, an ATTO ThunderLink FC 1082 Thunderbolt to 8Gbit Fibre Channel adapter, and a HP StorageWorks P2000 G3 MSA FC Dual Controller LFF (specifically, model number AP845B).

The P2000 is not explicitly on ATTO’s compatibility matrix, but when I asked their tech support about it, they said it was compatible and provided me with a pre-release version of their Multi Path Director driver for the Thunderlink which is officially compatible.

Evidently, the P2000 G3 is an OEM’d version of the Dot Hill AssuredSAN 3000 Series (specifically, the 3730), which is on ATTO’s compatibility list, so I assume the standard driver would work just as well. Update 2018: Since Dot Hill has in the meantime been sold, their support page has moved to Seagate.

We chose the Thunderlink/P2000 combo over a Promise solution because it was cheaper, fully 8Gbit capable and had four host ports. Also, I know that HP’s tech support is good and they’ll have spare parts around for many years. Plus, the P2000 is VMWare ESXi certified.

The obvious downside to the P2000 is that the disk bays do not have standard SAS connectors but require an interposer board to convert to a SCA-2/SCA-40 connector. The included slot blinds are in fact blinds and cannot be used to mount an actual drive. You can get empty caddies/trays for the P2000 on eBay or from some used SAN equipment dealer for around 100 euros, or buy your hard drives from HP for a premium of around 100-150 euros over the plain drives. (The interposer board itself appears to get sold under the model numbers 371595-001 or 60-272-02 on eBay, but I haven’t found a model number for the caddy frame yet.) If you’re buying plain drives, you can check HP’s hard drive model matrix to see what model of drive an HP part number corresponds to. For example, the 3TB SAS drive QK703A is a Seagate Constellation ES.2 ST33000650SS and the 2TB SAS drive AW555A, which we ordered, is a Seagate Constellation ES ST2000NM0001).

Firmware

I have verified that the firmwares are interchangeable between the AssuredSAN 3000 and the P2000 G3: I downloaded and extracted the TS250R023 from both Dot Hill and HP and both contain a file named TS250R023.bin with an MD5 sum of 7b267cc4178aef53f7d3487e356f8435. I assume that’s the file that can be uploaded through the web interface.

To extract the HP firmware, download the Linux updater (e.g. CP020030.scexe) and use a hex editor to find the offset of the line break after the end of the shell script at the beginning, then use dd to skip the plain text: dd if=CP020030.scexe bs=1 skip=8602 of=scexe_tmp24664.tar.gz. Now you can tar zxf scexe_tmp24664.tar.gz and pull out the TS250R023.bin.

To extract the TS250R023.bin, simply tar xf TS250R023.bin. If you want to poke around the root filesystem of the Management Controller, unsquashfs mc/components/app.squashfs. You may need to compile squashfs-tools yourself to get LZMA support (edit squashfs-tools/Makefile, set LZMA_SUPPORT=1 or LZMA_XZ_SUPPORT=1 and apt-get install liblzma-dev zlib1g-dev liblz-dev).

Setup and configuration

After unpacking the device, I first updated the firmware to the most recent version available from HP. Before you do that (I used the Windows utility), make sure to set static IP addresses or DHCP static mappings (otherwise the update might fail due to changing addresses). After you set the password for the manage user, you’ll need to SSH into the device to change the password on a hidden admin account about which HP issued a security advisory back in December 2010 (but still hasn’t fixed it in the firmware).

I created a RAID5 out of 4x 2TB drives and dedicated a fifth one as a global spare. In the global disk settings, I enabled spindown so the spare would not be running unnecessarily. The RAID initialization took close to two days, but as that runs in the background, you can already start using it.

Then I created a couple volumes (setting the default mapping to not mapped) and mapped two of them to our Mac mini server (on the Thunderlink) and a third to our two VMWare ESXi servers (on Qlogic QLE2460 HBAs). This was much easier to do than on our old Xserve RAID and I love that I can start out with smaller volumes (sized appropriately that they’ll last for the next year) and expand them later on. The P2000 does not do thin provisioning, but you can’t really expect that at this price point.

Tracking DHL Freight packages

2 Replies

I recently got a shipment notification with a tracking number starting with JND and followed by 17 digits, half of them zero. After searching around for a while, I figured it was shipped by DHL Freight. It’s kind of hard to find the tracking page for that and it’s not supported by Delivery Status, so here’s the link: https://activetracing.dhl.com/. It’s hidden on the DHL web site; you can find it by going to the Logistics tab in the tracking section and clicking “Road and rail”.

Ich habe kürzlich eine Versandbenachrichtigung mit einer Trackingnummer erhalten, die mit JND anfängt. Wie sich herausstellt, gehören solche Trackingnummern zu DHL Freight. Die Tracking-Seite ist etwas schwierig zu finden und Delivery Status unterstützt DHL Freight auch nicht. Der Direktlink ist https://activetracing.dhl.com/ und er ist recht versteckt auf der DHL-Webseite: Man muss auf das Logistik-Tab gehen und dort auf “Land- und Schienenverkehre” klicken.

Two-legged OAuth between PHP and JIRA

7 Replies

If you want to use the JIRA REST API without storing plain-text passwords in your application, you need to use OAuth. If you want the application to directly talk to JIRA without binding it to a JIRA user account, you need to use 2-legged OAuth. JIRA requires RSA keys for 2-legged OAuth. Zend_OAuth supports RSA-signed requests, but this is somewhat undocumented. Also, the Java OAuth library used by JIRA appears to have a bug that requires the field oauth_token in the Authorization header to be present but blank for 2-legged authentication (if it’s not present, it raises uncaught exceptions…). Lastly, you have to use the exact server name that JIRA thinks it has. Finding out all this took me quite a while, so here is the full code:

PHP Code

require_once 'Zend/Oauth.php';
require_once 'Zend/Oauth/Consumer.php';
require_once 'Zend/Crypt/Rsa/Key/Private.php';
require_once 'Zend/Crypt/Rsa/Key/Public.php';

$jql = 'project = KB';
$max = 50;
$server = 'https://www.example.com/jira/'; // this must not be http://localhost:8080. It must match the proxyName, proxyPort and Context configured in ./conf/server.xml in JIRA. Otherwise you get signature_invalid exceptions
$query = array('jql' => $jql, 'startAt' => '0', 'maxResults' => $max, 'fields' => 'summary,assignee,duedate,priority')

$privkey = new Zend_Crypt_Rsa_Key_Private('jira.pem');
$pubkey = new Zend_Crypt_Rsa_Key_Public('jira.pub');
$consumer = 'samplescript';

$query['oauth_token'] = ''; // otherwise you get uncaught net.oauth.OAuthProblemException: signature_invalid exceptions
$oauth_config = array(
 'consumerKey' => $consumer,
 'rsaPrivateKey' => $privkey,
 'rsaPublicKey' => $pubkey,
 'signatureMethod' => 'RSA-SHA1',
 'siteUrl' => $server . '/plugins/servlet/oauth',
 'requestScheme' => Zend_Oauth::REQUEST_SCHEME_QUERYSTRING,
 );

$oauth = new Zend_Oauth_Consumer($oauth_config);
$oauth->setSignatureMethod('RSA-SHA1');
$oauth->setRsaPrivateKey($privkey);
$oauth->setRsaPublicKey($pubkey);

$token = new Zend_Oauth_Token_Access(); // 2-legged authentication doesn't use tokens, but this is the only way to get a HTTP Client that sets the proper Authorization headers
$oauth->setToken($token);
$client = $token->getHttpClient($oauth_config, $url);

$client->setUri(sprintf('%s/search', $url));
$client->setMethod(Zend_Http_Client::GET);
$client->setParameterGet($query);
$json = json_decode($client->request()->getBody());

print_r($json);

Generating the keys

openssl genrsa -out jira.pem 1024
openssl rsa -in jira.pem -pubout -out jira.pub

Registering them with JIRA

Go to the JIRA Administration, click Plugins, then Application Links.

Click Add Application Link, enter your server URL, enter the name of your application and select Generic Application.

Now configure it: got to Incoming Authentication, set a Consumer Key (I used samplescript above), set a name and paste the contents of jira.pub into the box. Now check Allow 2-Legged OAuth and enter a user name to which you want to map the key (i.e. which user’s permissions the OAuth client should have).

OpenWRT hardware recommendation: TP-Link TL-WDR3600

23 Replies

I recently replaced my WiFi access point, an ancient Linksys WRT54G v3.1. I was looking for something that supported simultaneous dualband, multiple SSIDs, and VLANs. I also wanted something that could run OpenWRT.

I ended up buying the TP-Link TL-WDR3600 because it met all these criteria and was available for less than 50 €. After using it for a few months, I can definitely recommend it: The wireless coverage is good, it supports Multi-SSID just fine, and the internal switch is fully VLAN-capable (and easy to configure using the OpenWRT LuCI web interface).

My only complaint is that in the 5 GHz band (5150 MHz – 5250 MHz), OpenWRT limits me to 50 mW of output power (the Linux kernel has a limit of 100 mW), even though I could legally run up to 200 mW. These lowest four channels of the 5 GHz Wifi band don’t even require TPC (transmission power control) or DFS (radar detection) in Germany, making the limitation completely unnecessary.

The TL-WDR3500, TL-WDR4300 and TL-WDR4310 are identical to the TL-WDR3600 save the radio module, so the instructions here should apply to them as well.

Here’s a short how-to on getting started with OpenWRT on the WDR3600:

Installing OpenWRT

Hook up your computer to an Ethernet port on the WDR3600.

Download openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin and upload it using the factory web interface at http://192.168.0.1 (do not rename the file or it might not update).

After it reboots, renew your DHCP lease (OpenWRT uses a different subnet by default) and telnet 192.168.1.1. There, run passwd to set a password, then hit Ctrl-D to disconnect. Now you can ssh root@192.168.1.1.

The first thing to do is backup the bootloader and ART partition, just in case:
dd if=/dev/$(grep '"art"' /proc/mtd | cut -c 1-4) of=/tmp/art.backup dd if=/dev/$(grep '"u-boot"' /proc/mtd | cut -c 1-4) of=/tmp/u-boot.backup
Now you can scp root@192.168.1.1:/tmp/*.backup ~/Desktop to get them off the device.

Next, install the web interface:
opkg update opkg install luci /etc/init.d/uhttpd enable /etc/init.d/uhttpd start
Now you can easily configure everything the way you want it (but please don’t ask questions in the comments about the specific configuration: the OpenWRT forums are a much better place for that).

Upgrading OpenWRT

cd /tmp wget http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin md5sum openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin # compare it against http://downloads.openwrt.org/snapshots/trunk/ar71xx/md5sums

sysupgrade -v openwrt-ar71xx-generic-tl-wdr3600-v1-squashfs-sysupgrade.bin
The device will eventually reboot and come up with the new firmware. Your configuration should still be present.

Failsafe mode

If you’ve locked yourself out, it’s easy to get back in: unplug the device, plug it back in and as soon as one of the LEDs on the front starts flashing, push and hold the WDS button. Release it when that LED starts flashing a lot faster.

Now, set your computer to a static IP of 192.168.1.x with a subnet mask of 255.255.255.0 and telnet 192.168.1.1. Now you can reset your password (passwd), change configuration variables (uci), or do a factory reset (firstboot). When you’re done, reboot -f to return to the normal operation mode.

Warning

It is possible to brick your device with OpenWRT. All the commands above are provided without warranty, so use at your own risk; if you don’t know what your doing, don’t do it.

Also, it’s not that easy to get back to the original TP-Link firmware (which you would definitely need to to if you wanted to return the device to TP-Link for warranty repair.

Note that depending on local laws, flashing an alternative firmware may void your warranty altogether. Even if it does not, screwing up such a flash process yourself is sure to void the warranty anywhere…

Xserve RAID and Atto Thunderlink FC 1082 are incompatible if used without an FC switch