Technical Intercourse

NAT64/DNS64 on OpenWRT

The latest stable release of OpenWRT – Barrier Break – makes it a simple matter to add NAT64 and DNS64 capabilities to the router. This is particularly useful if one wishes to run an IPv6 only internal LAN network while dealing with the IPv4 + IPv6 world of the Internet.

DNS64

DNS64 provides a faux AAAA record for any existing A record. The easiest tool to use for this is TOTD, which is no longer in development but is found in the main OpenWRT repositories.

So, install TOTD and configure it.

# opkg update
# opkg install totd
# vi /etc/totd.conf

The totd.conf file should contain the following:

; substitute with your upstream DNS
forwarder 8.8.8.8 port 53
forwarder 8.8.4.4 port 53
; modify your OpenWRT ULA prefix here
prefix fd63:fab9:6ccf:64::
; this port is used later
port 5353

Enable and start TOTD, and check the logs for any errors:

# /etc/init.d/totd enable
# /etc/init.d/totd start
# logread

Finally, configure the built-in DNSMASQ to use TOTD as its upstream. Just remember to use 127.0.0.1#5353 as the upstream server. Note the use of a hash (#) symbol.

You should be able to verify that it works by querying AAAA records for pure IPv4 names. You should see that a fake IPv6 address be returned with your TOTD specified prefix.

# ping6 ipv4.google.com

You won’t be able to actually ping it over IPv6 yet at this point, until your NAT64 is setup correctly.

NAT64

NAT64 provides an IPv6 to IPv4 NAT mechanism which will actually transfer the IPv6 packets by converting them into IPv4 packets and back. The tool to do this is TAYGA and is also available in the OpenWRT repositories.

First, install TAYGA.

# opkg update
# opkg install tayga

Next, edit /etc/config/network and add a new interface.

config interface nat64
 option proto tayga
 option ifname 'tayga-nat64'
 option ipv4_addr 192.168.64.1
 option prefix fd63:fab9:6ccf:64::/96
 option dynamic_pool 192.168.64.0/24
 option accept_ra 0
 option send_rs 0

Next, edit /etc/config/firewall and add it to the LAN zone.

config zone
 option name 'lan'
 option input 'ACCEPT'
 option output 'ACCEPT'
 option forward 'ACCEPT'
 option network 'lan nat64'

Enable and start TAGYA, and check the logs for errors.

# /etc/init.d/network restart
# /etc/init.d/firewall restart
# logread

You should now be able to ping any IPv4 server using IPv6.

# ping6 ipv4.google.com

Voila!

RAID-1E Performance

As an addendum to a previous blog entry, I built a RAID-1E array with three identical 500GB disks and ran some benchmarks. As expected, the results fell somewhere in between the pure HDD and RAID-0 performance for both reads and writes.

RAID-1E

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
XXXX        23944M   888  96 178362  11 90639   5  5192  88 253139   7 557.7  11
Latency              8913us    4412ms    6268ms   17400us   38206us     764ms

Therefore, the advantage that it has over a RAID-0 array is the redundancy aspect as a RAID-1E is capable of withstanding a single-disk failure unlike RAID-0. However, performance suffers slightly. It is both faster and safer than a single HDD storage.

Therefore, a RAID-1E configuration is quite useful.

As for how to build a RAID-1E array, just build a RAID-10 array with an odd-number of disks. Useful, when I only have three identical disks.

XPS13 (9343) Ubuntu Linux

I broke my pre-Haswell XPS13 and had to quickly buy a replacement. Without much thought, I decided to get the new Broadwell XPS13. It was not until after I had made the purchase did I find out that there are a whole lot of complaints about the compatibility of this laptop with Linux.

Let me just say that I have full faith in Dell’s Project Sputnik and I’m sure that the team will get things ironed out soon enough.

However, I have to say that my Linux experience on this laptop is pretty good, far better than what I’ve read online. So, I thought that I’d document a few things of note here.

Bios Update
First thing I did when I obtained the new Broadwell XPS13 was to update the BIOS to A01. The way to do this is simple enough. Download the update from the DELL website and save it onto a USB drive. Then, start up the computer and hit F12 to access the boot menu. The BIOS can be updated from the boot menu itself, without having to boot into Windows/DOS.

Linux Install
Next, I opted to install the latest Ubuntu LTS (14.04.2) that went without a hitch. Even UEFI worked out of the box. Again, what I had to do was to download the ISO image from Ubuntu, flash it into a USB drive and reboot the computer while pressing F12 during boot up to get the boot menu.

Broadcom 4352 Wifi
The wireless AC wifi card that comes with the new XPS13 requires the proprietary Broadcom drivers to work. The good thing is that the bcmwl-kernel-source drivers are available in the Ubuntu repository. The command to install this is to run:
apt-get -y install bcmwl-kernel-source

Needless to say, this can only be done after installation by temporarily using a WiFi dongle since there is no wired ethernet port on this laptop. I used my old trusty TL-WN725N which uses the standard rlt8192cu driver in the kernel. After that, the wifi card worked like a charm.

Broadcom 216F BT
The built in Bluetooth module also requires a little tweaking. While the drivers are available in the kernel, the required firmware wasn’t. This required a little workaround to get the firmware from the Windows drivers. However, I had already wiped out Windows from my laptop. Good thing then that the drivers are available from Microsoft themselves.

The downloaded file is a CAB file that needs to be extracted. Then, the appropriate HEX firmware needs to be located and converted to a HCD file using the HEX2HCD tool.
# cabextract 20662520_6c535fbfa9dca0d07ab069e8918896086e2af0a7.cab # hex2hcd BCM20702A1_001.002.014.1443.1572.hex /lib/firmware/brcm/BCM20702A0-0a5c-216f.hcd

That’s it. Bluetooth worked like a charm.

Touchpad
There are reports of problems with the built-in touchpad freezing and keyboard experiencing stuck keys. This can be fixed according to the official DELL blog by adding some kernel parameters.
psmouse.resetafter=0

Audio
The last thing to get working is the analogue audio but since I pipe most of my audio through HDMI, I have not really bothered with this one. But it turns out that the kernel parameters worked.
acpi_osi=!Windows\ 2013

LTSP Client with HPLIP

I had a problem hanging a HP printer off an LTSP client. This printer – M1132 – requires a proprietary plugin.

First, I tried to setup the printer using USB-IP. This obviously worked. The LTSP server was successfully fooled into thinking that the printer was connected to the local USB port. However, this method was troublesome as USB-IP needs to be manually connected each time the client was rebooted.

Then, I tried the recommended way to do it by editing lts.conf to enable jetpipe and saned. Unfortunately, while both the daemons started up, it was not possible to neither print nor scan from the client. When I ran hp-setup from the LTSP server, it failed to even detect a network printer. While sane was able to detect the scanner, it too failed to scan.

Next, I tried to run hp-setup from within the LTSP chroot but that was not possible either as lsusb failed to return anything inside the chroot. Therefore, the HP software is unable to install the plugin nor configure the CUPS queue.

Finally, the way that I got things to work was to manually install the plugin and setup CUPS. This involves running hp-plugin from within the LTSP chroot. Then, I installed the PPD and configured both the cupsd.conf and printer.conf manually. Then, all I had to do was add a network connected IPP printer on the LTSP server and point it to the client.

Voila, both scanning and printing now works with the printer hanging off the client.

PS: In order to prevent CUPS from running on any of the other clients, I made CUPS listen to the specific IP address assigned to that specific client.

HD Video Streaming on LTSP

Our office uses a LTSP setup for workstations. On a lark, I decided to measure how well it worked with streaming video.

As can be seen from the screenshot of nmon running and measuring the network bandwidth, the maximum peak transfer is 120MBps which translates to about 1Gbps. This is the amount of bandwidth taken when streaming a Youtube video on full-screen.

At this bandwidth, the video is perfectly watchable with no noticable lag or refresh rate problems. However, if we merely watch the video in cinema mode, the bandwidth requirement drops to about half. If we watch it in the normal mode, the bandwidth reduces by another half.

So, to watch smooth Youtube videos on LTSP, we will need about 250Mbps network bandwidth. On a 100Mbps network bandwidth, video was choppy even at the standard Youtube video size. There were noticeable frame rate problems.

This also means that we will need high amounts of bandwidth at the LTSP server end to provide smooth videos to a number of workstations via a gigabit switch. Therefore, it is advisable for the LTSP server to have multiple nics in a bonded configuration.

RAID-0 vs iSCSI vs HDD

I had reason to set up some storage at the office recently. So, I got to experiment with regular HDD storage, iSCSI and RAID-0 configurations. The results proved to be rather interesting and will be useful for future reference.

The same machine was configured with a two-disk RAID-0 array, the single HDD storage, and as a iSCSI initiator. The iSCSI target was connected via a 1Gbps network over CAT-5e via a gigabit switch. The iSCSI target had to be configured with TCP window scaling disabled in order to achieve a high speed connection.

All results are obtained with regular bonniee++ benchmarking tool.

HDD
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP XXX 8G 973 97 115588 9 49174 4 4013 65 118067 5 259.3 3 Latency 9549us 778ms 1391ms 113ms 321ms 763ms

RAID-0
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP XXX 8G 1247 97 272885 14 122170 6 4006 96 333448 8 341.0 10 Latency 9564us 25945us 217ms 7244us 34189us 376ms

iSCSI
Version 1.97 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP XXX 8G 666 95 36609 3 24401 2 4598 96 90542 4 191.8 2 Latency 15935us 6439ms 4285ms 18451us 302ms 2075ms

There are some useful observations from this. The RAID-0 array has a higher read and write speed than any of the rest for both sequential and random access patterns. While the iSCSI device has the slowest read and write speed, its access speeds are still fairly acceptable. However, it has a significantly higher latency than the rest which makes it unsuitable for regular usage.

I’ve decided to configure the RAID-0 array for storage that requires high speed access as it has both high read/write speeds and low latency. The iSCSI storage is used only as backup storage, which is useful since it can be used to backup data across a network to a dedicated storage server. The regular HDD is used for regular OS storage.