I cleared it with the bank, but after that I could no longer buy applications through the Android Market application. When I attempted to do so, the Market required me to check “I agree to the Payments for Android
Market Terms and Conditions”, then failed with the message “Error while retrieving information from server.”

If you don’t care to read the grimy details, perhaps you should skip to the solution.

I reported the issue to Android Market technical support, who replied to me the following day requesting steps to reproduce. I gave them a full bug report:

1. Open Market.
2. Navigate to any app. Press the amount button, such as “£0.10″, button on the upper right.
3. The confirmation page loads, listing my credit card, gmail account, and total. “Accept & Buy” is grey, and the statement “I agree to the Payments for Android Market Terms and Conditions” is displayed, unchecked.
   
4. Check next to “I agree …”. “Accept & Buy” becomes blue.
   
5. Press “Accept & Buy”.
6. The error message “Error while retrieving information from server” appears.
   

What immediately stood out is that I had never previously seen “I agree to the Payments for Android Market Terms and Conditions” appear during a purchase. The Market normally prompts you to accept this the first time you run it after factory reset. My wife’s phone did not have this message.

Also of interest, I could purchase Android apps through the Android Market website, and send them to the device (or install them via the Market). The problem was only with purchases made via the Market app.

I provided all these details, including the fraud problem to Android Market technical support. Unfortunately, I also identified my devices as running community-build Android ROMs. My HTC Desire HD phone runs MIUI, and my Nook Color tablet runs CyanogenMod. That caused another day of delay while technical support insisted that they could not help me because “unauthorized operating systems (custom ROMs) may have limited functionality due to the compatibility of the device.”

I asked technical support to check that my Market account is functioning normally, and they responded with “I’ve taken another look at your account, and can find no reason you shouldn’t be able to access Android Market. Please remember that Android Market may not work well with devices in a modified state as far as operating system or user access privileges. I can only recommend using Android Market with your device in its factory default state.”

I did not expect technical support to support a modified ROM. And before anyone accuses them of refusing to help for that reason, they did not blame the ROM outright and they did try to help. However, they did not solve the problem.

So I spent another day testing. I purged Market settings from /data/data/com.android.vending. I compared to friends’ devices. I arranged to borrow a stock, unmodified phone from a friend and test the following day. And then I realised something – my wife’s phone showed a different credit card number in the purchase screen. We have the same joint account and credit card number, which means that she was able to make purchases with a different credit card.

I logged in to Google Wallet and deleted my credit card, and added it again. The problem was immediately solved. The Market no longer displayed “I agree to the Payments for Android Market Terms and Conditions”, and I’ve been able to buy apps ever since.

Conclusions:

1. The Android Market error message “Error while retrieving information from server” apparently means “Your credit card with Google Wallet once refused a charge”. Or at least indicates a problem with Google Wallet. This error message is totally unhelpful and should be corrected.
2. If you get this error message, try logging in to Google Wallet, remove your credit card, and add it again.
3. If you are running a custom ROM, Android Market technical support may pause because the ROM could be at fault. I appreciate that they did try, and they were polite and courteous the whole time. But it still sucks that they believe the CyanogenMod team is any less professional than HTC. And it especially sucks when you provide professional-quality steps-to-reproduce which clearly indicate the ROM is not the problem.
4. Android Market technical support does not know about this error message or issue with Google Wallet. This is especially disconcerting, as it probably happens all the time and they are exactly the people who should know about it.

I found only a handful of references to this error via Google searches, none with solutions. So I’m writing this all up here, in hopes that it will help other people.

(In case you miss it the first time, try reloading or clicking the button.)

If you’d like to know more about our awesome card, see a previous year’s post. Hey Mark, have you stolen my idea yet? You’re becoming rather tardy, mate.

$happy $holiday, everyone!

This time the upgrade preserved most of my settings. I still had to reinstall my usual software, and fix a few things. Use the following to install my original list of useful software. This should be handy when rc7 or, haha, the “final” 10.03.1 is released.

opkg update
opkg install kmod-fs-btrfs kmod-fs-ext2 kmod-fs-ext3 kmod-fs-ext4 kmod-fs-isofs kmod-fs-reiserfs kmod-fs-vfat kmod-fs-xfs
opkg install kmod-nls-cp1250 kmod-nls-cp1251 kmod-nls-cp437 kmod-nls-cp775 kmod-nls-cp850 kmod-nls-cp852 kmod-nls-cp866 kmod-nls-iso8859-1 kmod-nls-iso8859-13 kmod-nls-iso8859-15 kmod-nls-iso8859-2 kmod-nls-koi8r kmod-nls-utf8
opkg install kmod-usb2 kmod-usb-storage kmod-usb-storage-extras block-hotplug block-mount hotplug2
opkg install --force-overwrite avahi-daemon bwm conntrack-tools fdisk fping iftop ip kmod-ipv6 libnl lft lsof luci-app-ntpc luci-app-openvpn luci-app-upnp luci-ssl miniupnpd mtr net-tools-hostname ngrep nmap ntpclient openssh-client openvpn rsync screen snmpd sshfs tcpdump vim
mkdir /mnt/usbstorage -p

This list no longer includes iptables-utils, which has been merged into iptables and is now simply a dummy package.

After that, I also had to:

1. Restore my OpenVPN certificates to /lib/uci/upload/
2. Delete duplicate configurations in “LED Configuration”
3. Go to System -> Startup and enable the newly-installed daemons

Warning: do not restore to /overlay, even if that is what your BackupPC server is archiving. Restore to the root directory.

I tested wireless throughput on rc4 and rc6 on my Buffalo WZR-HP-G300NH, and also on a Linksys WRT-54-GL with DD-WRT v24-sp1 for comparison. Since rc5 was unstable (except in 802.11b-only mode), I didn’t bother with full tests. All wireless networks had an identical configuration, from ESSID to channel to encryption settings.

I used iperf to transmit 10-second UDP streams from my laptop (on wireless) to zuul (on gigabit Ethernet). When testing between two directly-connected nodes, iperf will scale its burst rate until it finds the maximum link speed. Example: iperf -u -c zuul -b 35M -t 10. The results, averaged over 5 tests each:

Linksys WRT-54-GL with DD-WRT v24-sp1 – 28.5 mbit
Buffalo WZR-HP-G300NH with 10.03.1-rc4 – 23.9 mbit
Buffalo WZR-HP-G300NH with 10.03.1-rc6 – 26.8 mbit

I’m glad to see improved throughput since rc4, but it still doesn’t quite reach the WRT-54-GL, which is surprising. The difference is small enough to ignore. So far, I’ve had no issues with drops in wireless. I’ll update this post after I’ve had time to observe wireless stability.

Note: The 10.03.1 “Release Candidate” series aren’t true RCs. They are reasonably stable snapshots of current development, rather than iterations of bug fixes of the same stable code base. rc5 includes a new Luci web interface and newer kernel and hardware drivers since rc4. This makes experimenting with these releases that much more exciting.

What went wrong:

1. The LAN IP address changed to the default, 192.168.1.1/24. The Luci interface showed the DHCP server disabled, although it gave me an address (from the new range) when I connected. It stopped doing so after I changed the interface IP, which means the “no DHCP” setting took effect when I hit Apply.
2. A number of other settings reset to defaults: hostname, domain name, all DNS and DHCP options, remote syslog server IP, LED configuration, and wifi settings.

What went right:

1. It is no longer necessary to install the kmod-ath9k and wpad-mini drivers after installation. Wifi just works without additional packages.
2. My custom firewall configuration survived, as did my .profile for root.
3. The new Luci interface really is better than the old one.
4. Multiple wireless networks with different encryption settings now works. I can again have a hidden WEP network for my Nintendo DS.

After the upgrade, I followed the steps in my original post and reconfigured the lost settings. Since my BackupPC server takes regular backups of /overlay, it was trivial to restore most of what was lost from /etc/config. That was especially useful for my OpenVPN configuration.

The problems began when I tried to enable wifi. I found that it was stable in 802.11b-only mode, but when I tried to use “auto”, “b+g”, or “g+n” mode, both of my laptops repeatedly lost their connections. I tried many combinations of options before giving up and using another AP (as I have done since a week after buying this router). I have hope that this will one day be unnecessary.

iperf is a tool for measuring bandwidth and reporting on throughput, jitter, and data loss. Others have written handy tutorials, but I’ll summarise the basics here.

iperf will run on any Linux or Unix (including Mac OSX), and must be installed on both hosts. Additionally, the “server” (receiving) host must allow incoming traffic to some port (which defaults to 5001/UDP and 5001/TCP). If you want to run bidirectional tests with UDP, this means you must open 5001/UDP on both hosts’ firewalls.

iptables -I INPUT -p udp -m udp --dport 5001 -j ACCEPT

A network path is really two paths – the downstream path and the upstream (or return) path. With iperf, the “client” is the transmitter and the “server” is the receiver. So we’ll use the term “downstream” to refer to traffic transmitted from the client to the server, and “upstream” to refer to the opposite. Since these two paths can have different bandwidths and entirely different routes, we should measure them separately.

Start by opening terminal windows to both the client and server hosts, as well as the iperf man page. On the server, you only have to start listening. This runs iperf as a server on the default 5001/UDP.

root@server:~# iperf -s -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   124 KByte (default)
------------------------------------------------------------

The server will output test results, as well as report them back to the client for display.

On the client, you have many options. You can push X data (-b) for Y seconds (-t). For example, to push 1 mbit for 10 seconds:

root@client:~# iperf -u -c server.example.com -b 1M -t 10
------------------------------------------------------------
Client connecting to 172.16.0.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.1 port 37731 connected with 172.16.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.19 MBytes  1000 Kbits/sec
[  3] Sent 852 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  1.19 MBytes  1.00 Mbits/sec  0.842 ms    0/  852 (0%)

You can request that the server perform a reverse connection to test the return path, either at the same time (-d, dual test) or in series (-r, tradeoff). This causes both ends to temporarily start both a client and a server.

root@client:~# iperf -u -c server.example.com -b 1M -t 10 -r
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 172.16.0.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.1 port 46297 connected with 172.16.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.19 MBytes  1000 Kbits/sec
[  4] Sent 852 datagrams
[  4] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  4]  0.0-10.0 sec  1.19 MBytes    998 Kbits/sec  0.250 ms    2/  852 (0.23%)
[  3] local 192.168.1.1 port 5001 connected with 172.16.0.2 port 34916
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  1.19 MBytes  1.00 Mbits/sec  0.111 ms    0/  851 (0%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

The above shows first the client->server transmission, then the server->client transmission. If it seems hard to read, each simultaneous link has an ID such as “[ 3]“, and look for port 5001 to identify the host that is receiving data.

You can also specify the datagram size. Many devices have limits on packets per second, which means you can push more data with 1470-byte datagrams than with 64-byte datagrams. The same link tested with 64-byte datagrams (requiring nearly 20,000 packets where previously we needed only 852) showed 6% packet loss:

root@client:~# iperf -u -c server.example.com -b 1M -t 10 -l 64
------------------------------------------------------------
Client connecting to 172.16.0.2, UDP port 5001
Sending 64 byte datagrams
UDP buffer size:   110 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.1 port 47784 connected with 172.16.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.19 MBytes  1000 Kbits/sec
[  3] Sent 19533 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec  1.11 MBytes    933 Kbits/sec  0.134 ms 1294/19533 (6.6%)

To find the total packet size, add 28 bytes to the datagram size for UDP+IP headers. For instance, setting 64-byte datagrams causes iperf to send 92-byte packets. Exceeding the MTU can produce even more interesting results, as packets are fragmented.

iperf provides final throughput results at the end of each test. However, I sometimes find it handy to get results as the test is running, or to report on packets/second. That’s when I use bwm-ng.

Try opening two more terminals, one each to the client and server. In each, start bwm-ng.

root@client:~# bwm-ng -u bits -t 1000

  bwm-ng v0.6 (probing every 1.000s), press 'h' for help
  input: /proc/net/dev type: rate
  |         iface                   Rx                   Tx                Total
  ==============================================================================
               lo:           0.00 Kb/s            0.00 Kb/s            0.00 Kb/s
             eth0:           0.00 Kb/s         1017.34 Kb/s         1017.34 Kb/s
             eth1:           0.00 Kb/s            0.00 Kb/s            0.00 Kb/s
  ------------------------------------------------------------------------------
            total:           0.00 Kb/s         1017.34 Kb/s         1017.34 Kb/s

By default, bwm-ng shows bytes/second. Press ‘u’ to cycle through bytes, bits, packets, and errors per second. Press ‘+’ or ‘-’ to change the refresh time. I find that 1 or 2 seconds produces more accurate results on some hardware. Press ‘h’ for handy in-line help.

Now, start the same iperf tests. Any packet losses will be immediately apparent, as the throughput measurements won’t match. The client will show 1 mbit in the Tx column, while the server will show a lower number in the Rx column.

However, bwm-ng will not differentiate between traffic from iperf and other traffic at the same time. When that happens, it is still useful to use the packets/sec display to find the maximum packet throughput limits of your hardware.

One warning to those who want to test TCP throughput with iperf: you cannot specify the data rate. Instead, iperf in TCP mode will scale up the data rate until it finds the maximum safe window size. For low-latency links, this is generally 85% of the true channel bandwidth as measured by UDP tests. However, as latency increases, TCP bandwidth decreases.

Download Tolarski v.1.3.2 here.

To install, login to WordPress as admin and browse to Appearance -> Themes -> Install Themes -> Upload. I’d appreciate it if someone else could test this and leave feedback with any issues.

I don’t intend to turn Tolarski into a fully supported theme. But I am happy to answer questions. Some notes:

1. Tolarski displays the full date and time on posts. Tarski only prints the date, and this is not configurable. You can disable this by commenting out the “add_action … init_tolarski_post_metadata” line at the bottom of functions.php.
2. You must modify tolarski_headerimage() in functions.php. This specifies the 7 header images by filename, which should be placed in tolarski/headers/. Please don’t use my images on your live blog, but if you just want to play with the theme you can find links in the page source and manually download them. If you want to change the floating positions of the images, or use more/less of them, edit style.css.

Full disclosure: I’m one of those people who assembled such a NAS. And I was one of those people who spent an inordinate amount of time worrying about the 4K alignment problem. I eventually learned that I’d been wasting my time. When you find people on various mailing lists, forums, and blogs talking about this, please point them here.

The fundamental problem is the need to align data structures to the physical storage device’s boundaries. If your device stores data in block of 4K, then you want to begin writing your data at a multiple of 4K. You do not want to start writing 4K of data beginning 2K from the start of the device, because that will mean reading and writing two blocks of data. It would be more efficient to align to the boundary and write only one block.

All low-level storage systems, from filesystems (ext4) to logical volume managers (lvm2) to software raid (mdadm) use various block sizes. The terms vary from blocks to chunks to stripes, but the concept is the same. We want these blocks to align to what is best for the underlying layers, from any RAID configuration down to the physical devices.

To solve this problem, libblkid provides topology information for block devices. This includes physical and logical block sizes. As of spring 2010, support for libblkid is available in all the standard tools:

1. fdisk, since util-linux >= 2.15. You should start with ‘-c -u’ to disable DOS compatibility and use sectors instead of cylinders.
2. parted, since parted >= 2.1. Parted defaults to 1 MiB alignment for unknown disks, which should align to just about any sector size. This includes gparted and other graphical tools such as the partitioner used in the Ubuntu desktop installer.
3. mdadm, since util-linux >= 2.15. It is no longer necessary to manually specify stride and stripe-width. All MD superblocks are positioned either at the end of the array (0.9 and 1.0) or in multiples of 4K from the beginning (1.1, 1.2).
4. lvm2, since util-linux >= 2.15.
5. mkfs.{ext,xfs,gfs2,ocfs2} all support libblkid directly.

If you’re uncertain, verify that your tool depends on util-linux or libblkid. You can use the package manager, although you may need to examine a dependant library:

user@server:~$ dpkg -s libparted0debian1 | grep libblkid
Depends: libblkid1 (>= 2.17), libc6 (>= 2.8), libdevmapper1.02.1 (>= 2:1.02.36), libuuid1 (>= 2.16)

Or use ldd, which is more direct:

user@server:~$ ldd /sbin/parted | grep libblkid
        libblkid.so.1 => /lib/libblkid.so.1 (0x00007f5833228000)

Conclusion: if you are running Ubuntu 10.04, Fedora 13, or RHEL 6 or later, you do not have to do anything to use your 4K disk efficiently. Create the RAID array, logical volume, and filesystem exactly as you normally would.

When you login via SSH with agent forwarding enabled, the SSH server creates a socket in /tmp/ssh-[HASH]/agent.[PID]. This allows SSH sessions on the remote host to access your agent back on your workstation. Commands that use the agent, like ssh, scp, and rsync, find it by reading the SSH_AUTH_SOCK environment variable.

root@server:~#  echo $SSH_AUTH_SOCK
/tmp/ssh-NshdZD1538/agent.1538

This path is readable only to the current user (and root, which is why agent forwarding is dangerous if you don’t trust the root users of servers you access). GNU Screen inherits SSH_AUTH_SOCK like any other process. However, what happens when you detach your screen session and logout? When you login again and re-attach to screen, SSH_AUTH_SOCK is pointing to the wrong file:

root@server:~# screen -r
root@server:~# echo $SSH_AUTH_SOCK
/tmp/ssh-NshdZD1538/agent.1538
root@server:~# ls /tmp/ssh-NshdZD1538/agent.1538
ls: cannot access /tmp/ssh-NshdZD1538/agent.1538: No such file or directory
root@server:~# ssh localhost
root@localhost's password:

I have found a number of solutions of varying complexity. But here is a simple one-liner which finds an agent socket and attaches to it. This works in the current screen session (not just new shells within that session), and you don’t have to modify .bashrc or switch to zsh to use it.

export SSH_AUTH_SOCK=$(find /tmp/ssh-* -user `whoami` -name agent\* | tail -n 1)

This finds the most recent SSH agent owned by the user, and assigns it to SSH_AUTH_SOCK. This doesn’t guarantee that you’ll attach to the socket created for your current SSH session, only the most recent one. For instance, you could login with three SSH sessions and this will find the latest one. But if you’re using screen, you only really need one SSH session anyway.

This is a known issue, but isn’t really XBMC’s fault. Basically, this TV (and many like it) doesn’t start playing sound right away. But there is a simple workaround – keep the channel open, by always playing silence. You can do this without any performance penalty.

Run this in a terminal (or in /etc/rc.local, or ~/.gnomerc, or however you like):

aplay -c2 -r48000 -fS16_LE < /dev/zero &

This will constantly play silence to the ALSA sound system (in the case of Ubuntu, via Pulse). As far as I can tell, the sound server just drops it, or consumes very few resources to do it. The system load never increases nor does it appear as active in top.

I've implemented this as a more sophisticated solution. I have created my own xbmc script, which then calls the real XBMC.

#!/bin/bash
# if xbmc already running, exit
if (ps -ef | grep '[/]usr/lib/xbmc/xbmc.bin' >/dev/null 2>&1) ; then
   zenity --error --title "XBMC" --text "XBMC is already running. Please select it from the task bar above."
   die "XBMC is already running!"
fi

# Keep sound channel open (play silence), to prevent 2-second HDMI delay
aplay -c2 -r48000 -fS16_LE < /dev/zero &
APLAY_PID=$!

/usr/bin/xbmc "$@"

kill $APLAY_PID

Copy this script to ~/bin or /usr/local/bin and make it executable. It does two things:

1. Prevent launching more than one copy of XBMC. An easy mistake to make since Gnome provides no launch feedback and XBMC takes some time to start. A more elegant solution would restore the other XBMC instance instead of nagging the user.
2. Starts playing silence before starting XBMC, then kills it afterward.

A better solution would be for XBMC to maintain the channel itself (which must be what my DVD player does), but I'm happy with this until they release an official fix.