This entire site is under construction and thoroughly incomplete! (July 2008)

home of the madduck/ blog/ feeds/
madduck's Planet Debian posts

The following blog posts appear on Planet Debian. Please visit my main blog page for all my posts.

Shortcomings of the Nokia E51

I put the Nokia E51, which I had previously acquired, onto Ebay last night, and it sold within minutes. Even though I made a 50€ loss on the whole affair, this made me very happy! The phone is crap in so many ways that it made me quite angry. I now consider those 50€ the investment I had to make to bring you this post:

First of all, the reason why I bought the phone was because it sports wireless LAN as well as Voice-over-IP. Since I’ve recently gotten into VoIP, I was looking for reasonable VoIP phones and even though the Siemens C450IP DECT phone works very well, it only does so at home, or where I find a switch port for it. So my theory was to get this Wifi+VoIP phone and be able to use my VoIP infrastructure from anywhere around the world. Penny has the Nokia E65 and loves it, so I went for the E51, a newer model that promised to address some of the issues she had with hers.

All of the following is based on the E51 with the 100.34.20 firmware dated 29 September 2007, which runs the (crippled) Symbian S60r3 operating system.

Good things

Let’s start with the few good things up front: the E51 comes with a regular USB jack, allowing you to plug it into any computer and use it as mass storage device without the need for any Nokia-specific cables.

I also liked the remote lock functionality: in the event of a stolen phone, you could send it a pre-defined “passphrase” that would cause the phone to lock itself. Also, the phone could be configured to lock itself (like a screensaver) after a given amount of idle time.

Other than that, I could not find anything outstanding, so let’s turn to the downsides, of which there are many more:

VoIP/SIP shortcomings

I had previously dismissed the E series phones for good reasons, but both the E65 and the E51 improved their SIP clients a fair bit, and with the SIP VoIP settings utility, it was even possible to configure STUN. But unfortunately, the SIP client, while a nice toy, ended up being unusable in production. Here are some of the reasons:

I got VoIP working at home and in some other places, but definitely not everywhere. It may be that some of those networks blocked the SIP port (5060/udp), or that the phone didn’t feel well on the day, but in the majority of cases, I could not get the SIP client to connect. And there was no way to find out what was going on, as the client would just claim that “registration failed” without any additional information. It was also hard to retry, often requiring the phone to be restarted. Whenever if failed, the client would helpfully tell me that it “could not establish a connection to the connection network”.

To get the phone to log on to the SIP server automatically, I had to define a home network for the SIP profile. Changing the access point for that network required a phone reboot to get SIP working again. It was possible to define multiple SIP profiles with different access points and add them all to the one, global VoIP profile, and theoretically get auto-login to work across multiple Wifi networks; unfortunately, I cannot say that this worked, there were always some problems requiring me to change defaults and shift things around. Also, after I had defined a few of those profiles and needed to make a change to the SIP settings (move the SIP port to 53/udp), I had to modify all profiles in turn; it was not possible to share settings. On the other hand, NAT traversal settings and timeouts, which can only be configured with the aforementioned SIP VoIP settings utility, applied to a VoIP profile and thus to all SIP profiles, without exception.

I found it mildly annoying that I couldn’t use # and * as part of the number/SIP address to call, nor was it possible to dial single-digit extensions — the phone will ask you to associate a “quick dial” number with the key, even if “quick dial” has been explicitly disabled). I could also not “dial” a SIP address ad-hoc — if I wanted to call sip:someone@sip.somewhere.org, I had to define a contact and add the “Internet phone” address.

One can define “Internet calls” to be the default call type, thus routing all calls via VoIP if available. Unfortunately, once I dialed a number, the event was hardwired to the call type: I could not redial a number used previously for a VoIP call when all I had available was GSM coverage.

Gripes with the IMAP client

The IMAP client, while an interesting addition to my day, turned out to be pretty unusable. The first mistake I made was to tell it to synchronise all messages in some of my larger mailboxes, which caused the phone to take tens of seconds until it switched a folder, and a few seconds just to scroll to the next screen in any given folder. I found that once any mailbox accumulates more than 100 messages, the client turns useless (Nokia’s default is to synchronise 30 messages).

I could tell the client to synchronise every hour, but only if I locked it to an access point, the “home network”. If I roamed to a different Wifi network, I could no longer connect to the IMAP server, as this access point would not be found. The phone would not let me use a different access point unless I changed the home access point, but changing that turned off the automatic mail sycnhronisation.

If I say mail synchronisation, I mean header synchronisation. Even though there is an option for “Headers only”, it only applies to POP3; it is impossible to have the phone download message bodies automatically, only manually and then only per-message or per-folder, not for all folders at once.

The IMAP client could delete messages, but it could not move a message to a different folder, nor create or delete folders.

And even though I could turn off the message tone the phone would play when it received new email, it insisted on vibrating nevertheless.

The only other IMAP client I found for Symbian phones is ProfiMail, which looked interesting and much more powerful, but which would randomly crash on me while browsing or operating on larger mailboxes.

Connection hickups

While the an application was running that was using the network, the Wifi connection stayed open, but I could not make it stay open between sessions. The phone would obtains an IP, do what I asked it to, and then immediately close the connection. From a power management perspective, this makes sense, but not from the usability angle.

I could not make the phone connect to a Wifi network that advertised both, WPA and WPA2 and had to disable WPA at home to let it connect.

At times, it was not possible to reuse an existing connection. I haven’t been able to figure out the details, but it seemed to me that whenever an application like the IMAP client was locked to an access point, it would be unable to make a connection to the IMAP server, even if e.g. the VoIP client was connected to the server by way of exactly the same access point. The phone would just say that “a connection was already active” and that I should “close it and try again”.

I had a really hard time working with SSL-enabled websites and IMAP servers, because even though the phone presented me with the server certificate and offered the choice of accepting it permanently, it didn’t and would ask the question again and again (which made the phone pretty unusable if the IMAP client was running in the background). Only after I had found out how to import the CACert root certificates, did this problem become irrelevant.

Other pet-peeves

The phone came with a lot of smaller issues that made me ask the question of whether its designed ever had to use it too often.

Possibly the most annoying aspect of the phone was its speed. It’s a lot faster than the E61, but it still takes on the order of seconds to update screens or display simple text messages.

Speaking of text messages, I am a little spoiled by the Sony Ericsson K610i (to which I now return), which would offer the contacts with whom I’d recently interacted instead of presenting me with the full list, like the E51 does. I could filter the full list, but only by typing the start of the name — substring matching was not implemented.

It was impossible to receive text files via bluetooth and have them put onto the filesystem. On receipt, the phone just said “text file saved”, and it took me a while to figure out that it had stored them into the notepad, from where it could not be exported. To get my SSH identity onto the filesystem for PuTTY to use required me to access the phone via USB.

The phone could receive vCards with new contacts, but it only offered to import the first contact, even though the standard allows for an arbitrary number of contacts per file. What’s even worse though is that the phone silently failed to import contacts with non-ASCII characters in their name, such as Ä or Å — they just didn’t show up even though the phone gave every indication of a successful import; creating such contacts on the phone worked, on the other hand.

Each time I started the phone, the Nokia greeting screen would show up, accompanied with the Nokia tune, which could not be disabled. Enough said.

The last problem I feel worth mentioning is hardly a Nokia or Symbian problem: battery life. With Wifi turned on, the phone would last about 24 hours on standby, which makes it pretty unusable for roaming Wifi or even VoIP usage.

Summing up

I am happy to have sold the phone and look forward to returning to my Sony Ericsson K610i. After checking out the E61/E71 a bit, playing with the E65, and trying the E51 out for several weeks, I can conclude that Nokia has a long way to go before they can offer a usable smartphone with Wifi/VoIP capability.

It would be a good step forward if they would open-source the Symbian operating system, but until that’s done, I am going to look at the OpenMoko FreeRunner next. The E51 once again made it perfectly clear for me that proprietary software is no alternative for my use case.

NP: Fat Freddy’s Drop: Live at the Matterhorn

Posted Sat 28 Jun 2008 13:18:21 CEST Tags: ?cellphones ?nokia-e51 ?rant ?voip
Tatort: quality television

When I got home last night, I couldn’t sleep and instead popped a DVD into the drive and sat back to watch an episode of the famous Tatort series (German only).

Tatort (“crime site”) episodes tell the tale of police investigations, but without stuntmen and special effects, without sci-fi elements or threadbare settings and stories, without technology and gadgets. In fact, it just feels plain as if it could happen next door tomorrow. The characters are normal as you and I, but played beautifully, with witty and enjoyable dialogues, which seem familiar and natural to me as a German, rather than trying to be funny or cool. Yet, the two main investigators, Batic and Leitmayr, are awesome and it’s good fun to watch them inch towards solving the mysteries.

I watched the episode “Norbert”, and I really enjoyed it. The plot is full of surprises, and the viewer is (purposely) mislead on various occasions. It was suspenseful until the end. I’ve seen maybe 20 of the thousands of episodes (it airs every Sunday night since 1970), and this one was so far my favourite.

Quality television! It’s a shame the (Dutch) DVDs I have do not have English subtitles.

NP: Dimmer: I Believe You Are a Star

Posted Sat 28 Jun 2008 11:16:28 CEST Tags: ?culture ?de ?quality ?tatort ?television
Euro 2008 rage

As some of you may know, the Euro 2008 football championships are on in Austria and Switzerland at the moment. I am not a football fan at all, although I won’t mind watching a game between two skilled and fairplaying teams (which is becoming a rarity, I heard). But I don’t care much about it, unless it negatively affects those who don’t care (which includes myself).

For instance, last night, after Germany beat Turkey in the semi-finals, a group of hooligans roamed about in Dresden and vandalised Turkish food shops and hurt the people working there (German only). I can kind of understand fans getting overly excited and driving their cars madly through the city, honking the horns at frequencies directly proportional to their cumulative personality disorders (or inversely proportional to their penis size), but violence in reaction to winning? Fuck you, you low pieces of shit.

!

Update: there seems to be no information on whether the attackers were German. A foreigner living in Berlin has written in to complain that my blog post casts a negative light onto Germany in terms of hostility towards foreigners, which he disputes. Germany has had to fight that image for decades, and my blog post puts fresh petrol on the fire.

I do not intend that. I leave it up to each individual to make up their own mind, and to me, a group of hooligans is in no way representative of an entire nation. End update

Quite clearly, there are people on the street who should be locked up. I won’t go there though, at least not in this post.

Instead, let’s talk more about football and its effects, because encouraging this sort of violence is only one of many consequences, which we are forced to tolerate in the interest of the public. Everyone wants football, right? What follows are somewhat related, but otherwise incoherent rants. Enjoy, or stop reading. I’m not a misanthrope, I think.

There are many other aspects of this football event which make me want to throw up. One of them is the (sight of the) average organism who participates in the craze. Look at them! Monkeys are more intelligent than that! Has evolution taken a 180 degree turn?

Of course, you can’t blame the individuals, as their brains have been flooded and effectively shut off, so they don’t make any trouble when they trott along the path to dumbification. It’s the big companies and the media industry, blinded by short sight, do everything in their power to speed up this decline, fueling the consumerism of the stupified morons making up our the populace, just for the paycheck at the end of the day.

The UEFA is primarily a huge money-making machine, and if you want more information on that I suggest that you look a bit into the distribution of media rights for the event. Another instance, which has a little more relevance to the normal person on the street is their ticket distribution: people have to pay hundreds of Euros to UEFA a year before the event for a “chance” to be given a ticket for any random day. The ticket is made out in their name and cannot be transferred. If you can’t make the game, you can return the ticket to get you money back… after the event. If you don’t get a ticket, you’ll also get your money back… a year later. Interest-free loans, anyone?

But hey, I actually don’t care about most of that. Let those who want to consume consume, let those who can’t entertain themselves watch television, let the UEFA and media people get rich by making people stupid, and let me go about my daily business.

We held a small barbeque party some days ago, and I went out to buy a few kegs of beer from a local brewery. That was my first confrontation with the football circus, as the brewery happens to be about half a kilometre from the stadium where a match was on that night. It took me at least 40 minutes until I had argued successfully with five police officers and could pick up the kegs. Swap brewery for any of the other shops in the area, who did not receive any compensation whatsoever, and you’ll note how the football circus takes priority over everyone’s everyday life, even if you don’t give a single flying food for the sport.

I love Zurich, and just like most people, taking a stroll along the lakeside, between Bellevue and the Chinese Garden on a sunny afternoon is one of the more delightful ways to spend time in the city and enjoy its beauty… unless they are putting up massive “public viewing areas” everywhere (and make shitloads of noise in doing so), and even dump elevated “VIP platforms” into the lake to add noise in the view to the noise in the ear.

The official entities of Switzerland surely pushed for the event, as it drives tourism and brings money into the country. But were the people actually considered? Could we have done anything against this craze? I bet noone ever asked.

I find it very sad how much garbage these fan monkeys produce. Switzerland is well-organised, and there are plenty of garbage cans around, many of which have been put in place specifically for the event, but it’s already too much to ask of these low organisms to put the shit left from their consumption into those bins.

And I won’t even go near the question of how much energy this entire event wastes. Yay entertainment! Yay stupification of the populace! If you have football to celebrate, you don’t have to consider the environment, or poverty, or other such annoying issues.

Sunday night, the circus will come to an end, and what’ll be left is a few days of cleaning and tearing down all the structures. Then this place will finally retun back to normal, and there’ll be a little less idiots on the street, at least in the places I frequent.

NP: Dimmer: There My Dear

Posted Thu 26 Jun 2008 12:39:22 CEST Tags: ?ch ?de ?football ?media ?rant ?society ?zurich
Samsung Q-series laptops and Linux

Dear lazyweb: I’ve been a satisfied IBM Thinkpad X40 user for about three years, and the fact that the X40 is still one of the most commonly seen laptops at geek conferences speaks for the machine. However, as my baby’s end-of-warranty approaches, I am toying with the thought of a new laptop, with which I’d also like to address some of the issues I have with the X40, namely that it supports at most 1024x768 pixels on the screen, is limited to 1.8” harddrives (which to my knowledge come in 40Gb and 60Gb variants only and are quite slow), and whose Pentium M 1.4GHz processor often reaches its limits, even though I rarely do very computationally-intensive stuff. On the other hand, I get a good 4 hours of battery run-time out of the machine.

The Lenovo Thinkpad X61 would be a logical successor, but it has not won me over: it looks and feels a bit clunkier, has under 3 hours of battery time, and the screen is still limited to 1024x768 pixels. There’s the Lenovo Thinkpad X300, which comes with a 64Gb solid-state disk which will weigh even less on the battery, but the the machine is still too expensive, it’s first generation (meaning it’ll have more problems than a second generation issue), and the options for extending the storage capacity seem limited.

While visiting Penny in London, we passed by a number of electronics stores, and the Samsung Q45 and Q70 models attracted our attention. We would love to hear any feedback from owners out there (and maybe you could send us the output of lspci -vv, lsusb -vv and the file /var/log/dmesg, please?). After Lenovo has switched the Thinkpad power adapter plug format, I have very little reason not to look elsewhere…

The “ultra-mobile” Q45 (which would be a Thinkpad X-series competitor) comes with an Intel Core Solo, Duo, or Duo 2 processor, clocked at 1.6GHz, an Intel graphics card and the 3945BG wireless chipset (or its 4xxx successor), uses a 2.5” harddrive, and its 12.1” screen can display a resolution of 1280x800 pixels. It weight just under 2kg. We’ve seen models with 3Gb of RAM and a 320Gb harddrive for a little over 1000€.

The “business class” Q70 (a Thinkpad T-series competitor) has an Intel Core 2 Duo processor clocked between 1.8GHz and 2.4GHz, and its 13.1” display can also display 1280x800 pixels. It seems like it will require a bit of effort to find one with an Intel graphics card, though — I am not going to get a laptop with anything else, mainly because of Intel’s excellent dedication to open source. The devices are over 2kg in weight, and a 3Gb RAM, 320Gb harddrive version costs about 1400€.

Does anyone have experience with these laptops and could speak for or against them? Also, what other laptops (not desktop replacements or lap warmers) might be worth looking at? You can leave a comment, or write to me. Thanks!

NP: Oceansize: Frames

Posted Sun 22 Jun 2008 22:04:47 CEST Tags: ?laptops ?lazyweb ?lenovo ?samsung ?thinkpads
Preventing mail loss due to braindead IMAP clients

It happened a number of times now that my inbox would shrink in message count without my explicit doing. Generally, your inbox automatically emptying should be conceived a good thing, but it isn’t always. It took me a while to put together the pieces:

I think I unvealed the mystery: some IMAP clients automatically mark read messages as deleted. Don’t ask me why, I did not configure it, and even though I told Thunderbird specifically not to do it, I have no other explanation than to assume that it doesn’t care about what I want, but marks them for deletion anyway. Firefox decides to block cookies several times a day, despite my explicit requests to store them, and the two are from the same project, so it seems plausible.

Once marked for deletion (by way of an IMAP flag), offlineimap propagates the flag to all clients. Since I set delete=yes for mutt, if I then open and close a mailbox with such messages without noticing them, the messages are purged.

I gave up fighting and solved the problem at a different point, namely mutt (which was doing the deleting anyway):

folder-hook . push '<undelete-pattern>~D<enter>'

Since mutt deletes mail marked for deletion when I close a mailbox, finding those messages at time of mailbox opening must mean that they have been marked outside of the mailer — I use mutt for everything, exclusively. So let’s undelete them.

I can’t see any negative consequences of the above hook.

NP: Oceansize: Efflorescence

Posted Sat 21 Jun 2008 08:06:30 CEST Tags: ?mail ?mutt ?offlineimap
Auto-subscribing to Debian bugs I file

It happens from time to time that bug reports I file receive attention, but I don’t notice because our bug tracking system still does not auto-subscribe bug submitters to their own bugs (see bug #37078 and bug #351856). I thus decided to take the matter into my own hands.

Just in time, before I started hacking this up myself, I found Justin Pryzby’s procmail recipies, which are installed to /usr/share/doc/devscripts/examples/bts_autosubscription.procmail by the devscripts package. The result is available in my mailfilter git repository. So far, I only auto-subscribe in response to bugs I file; Justin also auto-subscribes to bugs he manipulates via the control bot.

For completeness, I also wanted to subscribe to all bugs that I have submitted. This turned out to be easier than I thought, thanks to bts in the devscripts package; note the sleep instruction in the loop to prevent hammering the system:

bts select submitter:madduck@debian.org \
  | while read bugno; do
      echo X-debbugs-autosubscribe: madduck \
        | sendmail -f madduck@debian.org ${bugno}-subscribe@bugs.debian.org
      echo subscription to \#${bugno} sent
      sleep 30
    done

NP: The Dukes of Leisure: The Dukes of Leisure

Posted Fri 20 Jun 2008 12:17:37 CEST Tags: ?debbugs ?devscripts
IPv6 with Debian

Even though I’ve dealt with IPv6 for almost a decade, have delivered presentations, and given multi-day courses on IPv6 security aspects, I’ve never actually added IPv6 to my own server/home network infrastructure because it seemed that Linux and/or Debian just weren’t ready for it. This seems to have changed (although there are still a number of problems) and in less than a day, I put a few of my machines online. In the following, I’d like to share with you how I did it.

Kernel versions and stateful connection tracking

Unfortunately, I have to start off with some bad news: even though Debian etch, our current stable release, which uses a Linux kernel version 2.6.18, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now.

For me, a remedy is almost around the corner: the 2.6.24 kernel seems to support stateful connection tracking for IPv6, and it’s even available for etch as it will be included in the upcoming etch-and-a-half release. I simply ended up using the kernel packages pre-release, and so far have not had a problem with it.

To do so, add the following line to your /etc/apt/sources.list, making sure to use a close archive mirror:

deb http://ftp.xx.debian.org/debian etch-proposed-updates main

I then just upgraded the system and pulled in all proposed updates. As that may have let in software that won’t be part of etch-and-a-half, or even lenny, you may want to pin the archive and only upgrade the kernel packages, by adding to /etc/apt/preferences (replacing amd64 with your architecture):

Package: *
Pin: release a=proposed-updates
Pin-Priority: -1

Package: linux-image-2.6.24-etchnhalf.1-amd64
Pin: release a=proposed-updates
Pin-Priority: 600

Alternatively, you could use the 2.6.24 linux kernel packages on backports.org.

Xen and IPv6

One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Configuring the packet filter

The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because — to quote one of the netfilter developers — “when ip6tables was conceived, someone had a big bad brainfart”: rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it’ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I’ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured.

Anyway, we want to get stuff working now! Thus, let’s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said “almost”). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]

### INPUT chain

# allow all loopback traffic
-A INPUT -i lo -j ACCEPT

# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT

# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT

# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new

# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT

# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "

### OUTPUT chain

# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT

# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT

### FORWARD chain

# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT

# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT

COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking.

The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP — after all, you’ve heard for the past 30 years that ICMP is a “bad hacker protocol”, and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they’re simply not allowed.

Well, to hell with all that! I don’t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it’s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it’s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn’t suggest to a hacker that something’s hidden here.

Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let’s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected

If you already have an IPv6 address, you’re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net.

If you are reading up to here, I assume you are connected to the ‘Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it’s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach.

With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they’re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 (“ipv6”), which is why we need those -p ipv6 -j ACCEPT rules in the iptables ruleset.

There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts.

Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs.

I suggest to use the first type of tunnel that fits your situation. Debian’s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones.

During registration, you will also need to choose a “PoP”, which stands for “Point of Presence”. If your country only has a single PoP, that’s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created.

Once your tunnel request gets approved, you’ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You’ll also be told the IPv4 address of your PoP “endpoint”.

Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity.

Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won’t report any errors. A future version will have a switch to prevent it from configuring the interface.

Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn’t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn’t work, you have an upstream packet filter that needs some of those holes poked. Good luck.

In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly.

Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway

Your IPv6 connection works, but it’s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don’t worry, this is not really very difficult.

First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 — 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire.

The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface’s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run ip -6 addr add 2001:41e0:ff12::1/64 dev eth0. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain.

The /64 prefix is only one of 65536 different /64 prefixes you can use from your /48 prefix. Since it’s unlikely that you’ll use them all, it’s a good idea to route unused ones to an unreachable destination, such as the loopback interface, which conveniently causes packets to any addresses outside the used /64 networks to be answered with ICMP destination network unreachable. You could route them to the special unreachable target instead, which would cause host unreachable messages, but the following is more explicit:

up ip -6 route add 2001:41e0:ff12::/48 dev lo
down ip -6 route del 2001:41e0:ff12::/48 dev lo

Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let’s just set it to accept all traffic between the local network behind eth0 and the Internet behind eth1. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -i eth0 -o eth1 -s 2001:41e0:ff12::/64 -j ACCEPT
# ip6tables -I FORWARD -i eth1 -o eth0 -d 2001:41e0:ff12::/64 -j ACCEPT

Bringing IPv6 to your local network

The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines.

On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won’t explain it:

interface eth0
{
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
  {
  };
};

Note again how we advertise a /64 network rather than the /48 we “own”. You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you’ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts.

Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work.

If you don’t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names

Take note of the IPv6 address of each host. There’s a way to determine it given the host’s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries.

If you’re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace.

Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.

% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you’re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

  1. inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
  2. flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
  3. removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
  4. concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by “privacy features”.

Remaining issues

Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network

I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what’s going on.

Mapping names to laptops

Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network.

I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

The second solution works for me for now, but I am interested in the third.

In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (radvd) with stateful configuration, using DHCPv6. I have yet to investigate this option.

Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits

Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

Posted Thu 19 Jun 2008 19:24:39 CEST Tags: ?documentation ?howto ?ipv6 ?networking
Tips for those trying to blow up planes

If you’re trying to blow up an airplane, and you’re hip and plan to use liquids to take down the silver bird, the following tips may be useful to you:

Of course, if you’re serious about blowing up an aircraft, you’re probably not going to need any of the above, as you’ll already have a more convenient way to get your substances on the plane. At the checkpoint, you’ll behave like the perfect citizen abiding by all rules; you wouldn’t want to arouse suspicion, now would you?

PS: this post purposely avoids the use of the word “terrorist”.

PPS: of all the great experiences in airports this week, I especially loved how passengers, who checked in at the counters (and had to present their passports there), were again checked after border control in Düsseldorf, while passengers like myself, who used the quick check-in terminals, were just waved through.

NP: Disturbed: The Sickness

Posted Wed 18 Jun 2008 12:11:06 CEST Tags: ?airports ?security ?security-theatre ?travel
Setting up an encrypted Debian system

Even though the Debian installer can set up encrypted partitions, it is optimised for systems with a single data partition, unless you want to enter multiple passphrases when the system boots. The installer configures a LUKS volume using cryptsetup, but it provides no mechanism for the use of key files, only interactive passphrases.

I like partitioning my disks and use different filesystems for /tmp, /home, /var, and /usr/local for a number of reasons. I don’t like entering more passphrases than necessary. If you can identify with that, the following is for you.

Several people have pointed out to me that one can simply create a single encrypted “physical volume” with the Debian installer and place “logical volumes” for the various filesystems in there. You still need a separate /boot partition, in any case. Kapil Hari Paranjape has described the approach.

This method is much cleaner and to be preferred. It’s quite likely that it also improves the speed since only a single kcryptd process takes care of all of the decryption and encryption needs.

Nevertheless, the following is still useful with that approach, although it’ll be less complicated.

Installing the system

The first step to setting up an encrypted Debian system is to perform a normal Debian system installation. When you are asked to partition your harddrive and create filesystems, set up all partitions as encrypted volumes (I suggest to go with the installer defaults and use dm-crypt and AES with the default settings, simply because I have no reason to doubt the installer dveeloper team’s choices). Make sure to erase the disks in the process — the installer has an option for that.

Set up the swap partition as an encrypted volume too, but don’t worry too much about the settings at this point; we will recreate the swap partition later.

Unless you want to boot off an external medium, such as a USB stick, you will need to create an unencrypted partition for /boot. I will return to this topic, which has security implications, further down.

The installer will ask you for passphrases for each of the volumes you create. I suggest you pick a secure passphrase for the root volume (/), but simple passphrases for all the other ones (such as “a”), since we will reconfigure them to use key files instead.

Using key files

A key file is like a passphrase stored in a file on disk; as opposed to “what you know”, it’s a “what you have” security asset. Thus, you need to store the file somewhere. When I boot up my system, I unlock the root partition with a passphrase entered interactively, which makes the root filesystem available. I store key files for all other volumes in /etc/keys. Obviously, I need to tell cryptsetup to use those.

The first step is to create a key file for each partition and to add it as a decryption key to the LUKS volume. You can do all of the following without unmounting the filesystems. See the following example for hda6, which will prompt for the simple passphrase we entered above to unlock the key ring when adding the key file:

umask 077
mkdir /etc/keys
dd if=/dev/urandom of=/etc/keys/hda6.luks bs=4k count=1
cryptsetup luksAddKey /dev/hda6 /etc/keys/hda6.luks
cryptsetup luksKillSlot /dev/hda6 0 --key-file /etc/keys/hda6.luks

The last command wipes the simple passphrase from the key ring and thus makes it unusable.

Now we need to tell cryptsetup to use the key file by editing /etc/crypttab and ensuring a line such as the following exists:

hda6_crypt /dev/hda6 /etc/keys/hda6.luks luks

This tells cryptsetup to create the cryptographic volume hda6_crypt from the base device /dev/hda6, using the key file we created above, and letting it know that it’s dealing with a LUKS volume.

Repeat this for every partition except your root and swap partitions.

Encrypting the swap partition

If you are using an encrypted Debian system, you likely have some security requirements to meet. If that’s the case, you must also use an encrypted swap partition.

The swap partition can be encrypted in two ways:

If you want to use suspend-to-disk, you cannot use the first approach as it would overwrite your memory footprint stored in the swap partition. Furthermore, you cannot use a key file like the other partitions, since the root filesystem is not (and must not) be mounted by the time the resume process starts and needs to read the decrypted swap partition.

The way I solved this is by telling cryptsetup to compute the passphrase of the swap partition from the decryption key of the volume holding the root filesystem; the cryptsetup package implements this with /lib/cryptsetup/scripts/decrypt_derived. Thus, to set up the swap partition, I do the following, assuming hda2 is the partition holding the encrypted swap and the root filesystem is in hda5_crypt:

swapoff /dev/mapper/hda2_crypt
cryptsetup luksClose hda2_crypt
dd if=/dev/urandom of=/dev/hda2
/lib/cryptsetup/scripts/decrypt_derived hda5_crypt \
  | cryptsetup luksFormat /dev/hda2 --key-file -
/lib/cryptsetup/scripts/decrypt_derived hda5_crypt \
  | cryptsetup luksOpen /dev/hda2 hda2_crypt --key-file -
mkswap /dev/mapper/hda2_crypt

To tell the system about this swap partition, we need to add it to /etc/crypttab and /etc/fstab; make sure, those files contain lines like the following:

/etc/crypttab:
  hda2_crypt /dev/hda2 hda5_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

/etc/fstab:
  /dev/mapper/hda2_crypt swap swap sw 0 0

With this in place, as soon as you configure the system for suspend-to-disk, the swap partition will be automatically set up alongside the root filesystem very early during the boot sequence. To figure out which swap partition to make available at that point, cryptsetup checks the following:

You can inspect /usr/share/initramfs-tools/hooks/cryptroot if you want to know more about this.

Using UUIDs

Even though the above is all you have to do, you might want to consider replacing the device paths in /etc/crypttab with persistent ones. One motivation might be the ability to boot off your drive via a USB adapter, which might cause it to appear as /dev/sda instead of /dev/hda.

udev is installed by default on Debian systems and it makes persistent links to partitions available under /dev/disk/by-uuid, using the UUID of the content structure (e.g. the LUKS header). It uses /lib/udev/vol_id to determine those link names.

If you replace the entries in /etc/crypttab, make sure to update the initramfs (update-initramfs -u -k all) and consider to use the same approach for the /boot filesystem in /etc/fstab; you’ll note that all other filesystems use persistent device paths thanks to the dm-crypt layer.

If you ever end up booting off the disk through a USB adapter, you might face the problem where the usb_storage subsystem takes too long to activate, so that the cryptsetup script does not find the devices in time. You can either solve this by adding the rootdelay=x parameter or break=mount to the kernel command line. The first will cause the scripts to wait x seconds before trying to configure and mount the root filesystem; the second would give you a shell that you can exit as soon as the kernel spouted its device initialisation messages at you.

If you got this far, you might even want to take it further and replace hda5_crypt with cr_root or the like to abstract those silly partition numbers away even further. This is easier than it sounds, but does require several steps. Do not do this if you’re not comfortable reviving your system in case it fails to come back up!

  1. replace the old names with the new names in /etc/crypttab for all volumes except the root volume. If you are using a derived passphrase for the swap partition, make sure to put the new name for the root volume into the third column of the swap partition’s configuration line.
  2. modify /etc/fstab accordingly, leave the root filesystem’s device path alone.
  3. call update-initramfs -u
  4. modify your bootloader to ask the kernel to boot off the new root volume.
  5. replace the root volume’s old name with the new one in /etc/fstab.
  6. reboot, and add break=mount to the kernel command line.
  7. at the busybox prompt, edit (vi) /conf/conf.d/cryptroot and change the first field of the root volume’s line to the new name.
  8. exit the shell and watch the boot process complete.
  9. finally, replace the root volume’s old name with the new one in /etc/crypttab.

If the system fails to boot up again, you can use the backup initial ramdisk, which update-initramfs left in /boot.

Security implications

Apart from the usual security implications related to cryptosystems, passphrases, mathematics, user stupidity, and so on, the approach I outlined will leave you with a pretty well-secured system. Obviously, you should make sure to lock your screen whenever you leave the system unattended or the entire encryption is basically useless.

There are two attack vectors on your system, both involving physical access to the machine:

Other than that, you should be careful when travelling to totalitarian countries, like the Excited States of America, China, and probably the UK. First off, encryption arouses suspicion, and second, border agents might ask you to decrypt the partitions for them to copy or scan, and refusal to do so might get your turned away at the border. When travelling to those countries, make sure to hide your data properly.

Speed implications

Obviously, having your entire system encrypted (including swap) will slow it down. I don’t have any quantitative information on that, but after several years of using full-disk encryption on my laptop (an X40, which isn’t very powerful), I can say that it remains usable, if you don’t rely on disk-intensive operations, such as compiling kernels and the like.

Alternative approaches

Several alternative approaches exist, all involving an additional device:

I have chosen neither of these approaches, because the extra security does not make up for the inconvenience, and the danger of an unbootable system in case of loss of forgetting of the additional device.

Posted Mon 16 Jun 2008 11:43:40 CEST Tags: ?cryptsetup ?dm-crypt ?documentation ?encryption ?howto ?privacy ?s2disk ?security
How Lenovo freely interprets 'next-business-day' warranties

I decided to purchase a three-year on-site warranty extension with next-business-day response time for one of the Lenovo systems I administer. I get this kind of extension for most systems that aren’t critical, but whose downtime would be inconvenient.

My understanding of the contract has always been that, assuming the problem requires on-site service, a technician gets in touch with you by the end of the next business day to agree on a time for the on-site visit. The contract does not guarantee that there will be a technician on-site on the next business day, but for two or three hundred Euros, that would be too much to ask.

However, it turns out that I assumed too much. First of all, Lenovo sells you a “next-business-day response time objective”, meaning that they aim to respond by the end of the next business day, but (obviously) can’t be held liable if they fail to do so. Apparently, they don’t even have to provide a reason for missing the objective.

What’s even more curious, however, is their interpretation of “response”: the term stems from the time when operators would log calls and technicians then processed the queue. Nowadays, Lenovo prides itself with “skilled technicians resolving more than 30% of all problems already on the phone”, so the technicians log the calls and then immediately respond to them.

According to Lenovo, it is thus completely acceptable and within the bounds of the contract if the phone technician logs a call on Thursday (and thus responds to it righ away), an the on-site technician calls to arrange for a visit on the following Tuesday, and the first available slot would be Friday — 6 business days after the call was logged.

I could not find any relevant information about this on their website, nor can you retrieve the agreement which you had to accept as part of the warranty registration later.

Of course, I am not surprised by any of this. The world out there seems to be full of asymmetric arrangements. I just wonder why we put up with them. I certainly don’t, and that’s why Lenovo is getting an angry letter from me with a reference to this blog post.

PS: in fairness, I should point out that I have been please by their support before, but have also questioned it in the past.

NP: Contriva: Tell Me When

Posted Thu 29 May 2008 17:23:55 CEST Tags: ?asymmetry ?consumers ?lenovo ?rant ?warranties