Bitcoins in Doha

I’ve finally decided to try to transact bitcoins in Doha. If you want to buy or sell bitcoins them either drop me an email or go to I’ll make a few percent but it will be less then bank transfer fees for small transactions. You can buy or sell bitcoins in most countries.

If you just want to move money around them you can find people using You meet up in the first country, hand over money and get bitcoins and then transfer them to the person you want to send money to who sells them and gets cash in return. No banks involved and no annoying forms.

If you are worried about handing over money and not getting your bitcoins then use the transaction service where the website holds onto the bitcoins until both parties have confirmed the transaction.

Unless you are planning to hold onto bitcoins it is a good idea to buy and sell fairly quickly (within a day or so) to avoid exposure to variations in exchange rates.

Posted in Blog, Qatar | Tagged | Leave a comment

Dual stack using a routerboard

At the Linux beer hike this summer I gave a short presentation on how to use a routerboard to tunnel to a SSTP server and enable IPv6 via a 6in4 tunnel onto your local LAN.

The notes of the presentation can be found here.

Posted in Music | Leave a comment

The firemen in Villaggio

I was very sad to read the news from Doha earlier today – A fire in Villaggio shopping mall 3 km from where I live has killed 19 people including 13 children, 4 teachers and 2 firefighters. It looks like the result of (unfortunately), normal in Qatar, deficiencies in safety design, construction, management, documentation and fire suppression systems. Villaggio is a huge site – The distance from Virgin at one end to the ice rink at the other end is around 600m. I have some doubts the full report will be made public as the normal tendency in Qatar is to suppress bad news, what will be published will be a sanitised version for public consumption.

We have had several fires in Qatar over the last few years, in one case one new tower block was engulfed in flames twice in 6 months even though flammable materials were supposed to have been replaced after the first fire. I’ve also heard stories about another tower block where the fire suppression system was not fully installed before occupation.

I’m sure that the events in Villaggio are the result of many factors, not least a complete disregard of safety procedures by management and education of the security staff who only appear to be capable of enforcing an apartheid in which coloured single men are prevented from entering the shopping mall to spend their meager wages on food from the supermarket. I don’t expect the top management and owners of Villaggio to be hauled up in court charged with safety offenses. There may be a couple of low level guys deported but that will be all, as the saying goes – “money talks”.

The people I really feel sorry for are the firefighters. It is one thing to be in a fire where people are killed but it is something else to willingly enter into harms way to try and save others and in the case of Villaggio for 2 of them to lose their own lives with others receiving injuries in the process. To do this takes a degree of courage and dedication which I’m not sure I have. The thought that they have died as a result of what is almost certainly a flagrant disregard for basic safety design and procedures by the building owners and their management makes me extremely angry.

I’ve spent the last 10 years working with public safety organisations to deliver reliable wireless communications. Like anywhere else you see good people and bad people but in the fire service you see a higher proportion of good people, its probably a side effect of them sometimes having to put everything on the line to help others and on occasion paying the ultimate price.

Posted in Blog, Qatar | Tagged , | Leave a comment

Adventures in IPv6

I posted this on the Linux Beer Hike list this evening, its probably of interest to a wider audience..

I’ve been working with IPv6 a bit recently and have been discovering lots of interesting implementation issues with both Windows and Linux. Generally dual stack where interfaces have both IPv4 and IPv6 enabled works fine on most systems. However running on a pure IPv6 network with NAT64 and DNS64 shows a few issues with several operating systems. I’ve focused on stateless autoconfiguration for the moment, DHCPv6 is on my todo list

Windows XP is the worst offender on pure IPv6 networks because it appears to be impossible to get the DNS resolver to query non-IPv4 DNS servers. I’ve seen several ‘fixes’ which involve manually configuring the DNS but they have failed to work on the XP systems I’ve had the misfortune to encounter, maybe a different set of updates and service packs are required. XP comes with a set of site-local IPv6 addresses preconfigured for the DNS resolver but it doesn’t appear to be able to query them either. I’m of the opinion that the only way to get XP to work properly on pure IPv6 networks is to install an IPv6 capable DNS server on each machine and point the XP DNS resolver at the IPv4 localhost ( Its certainly the approach I’m going to be exploring in the future.

Windows Vista and Windows 7 both appear to behave reasonably well on pure IPv6 networks, all machines appear to stateless autoconfigure reasonably well and pick up the router advertisements. Some systems don’t pick up the DNS and I’m still trying to work out the conditions under which this happens. However it can always be fixed by a quick manual setting in the interface IPv6 configuration.

In the Debian Linux world things are generally much better apart from the Debian squeeze installer which is unable to pickup any networking from IPv6. The only way I’ve managed to install successfully on a pure IPv6 network is to do a non-networking install, bring up the system then configure networking, set the aptitude repositories followed by a quick “apt-get update”, “apt-get upgrade”. After this everything works just fine. I’ve not tested the Ubuntu installer on a pure IPv6 network but I expect it to be the same story.

Getting access to the IPv4 world from an IPv6 only network is best achieved using NAT64 and DNS64. Once it is properly setup things work smoothly and completely transparently to the user. The only times they will notice the difference is when they want to go to a system which is not in DNS and they try to type the IPv4 address in the form The problem is their machine will try to open an IPv4 connection and discovers that there are no network interfaces configured with IPv4. This is easily rectified by either putting the target host into DNS or prefixing the IPv4 address with the 96 bit IPv6 prefix for the NAT64. Its a little annoying at first but becomes second nature after a while.

Both NAT64 and DNS64 are very new and implementations are still trying to catch up with the recommendations. For NAT64 I’ve settled on Tayga which is easy to compile and doesn’t require any kernel hacking. DNS64 is best done using Bind 9.8 or later. In both cases with Debian stable you have to manually build them from sources. To get your gateway system to transmit IPv6 router advertisements you need to install and configure radvd. Again the Debian stable version is a little out of date and if you want the client machines to pickup the DNS server information you will have to upgrade radvd to a later version (Debian testing). Make sure you install rdnssd on your client Linux systems if you want them to pick up DNS from the radvd advertisements.

Getting an IPv6 connection from your ISP is a little harder, in my case in Qatar it is impossible, so I am using the Hurricane Electric tunnelbroker service. They offer a free 6 in 4 connection where IPv6 is delivered over the normal IPv4 connection but uses protocol 41 instead of TCP/UDP etc. I’ve configured my home gateway machine to DNAT any packets with protocol 41 to a VirtualBox VM on my home network which does all the IPv4 tunnel, NAT64 and DNS64 stuff. I now have a home LAN which runs dual stack on and Ipv6 only on a VLAN. Hurricane Electric will delegate a /48 address block to you so you can setup the rest of your IPv6 network and make it properly routable which is what I did. 64K subnets of /64 should be enough for (almost) anyone!

During testing with Oracle VirtualBox I noticed a strange thing when I tried to bridge the raw Ethernet device into the VM and setup VLANs within the VM. This was that the radvd IPv6 advertisements did not get the VLAN packet headers attached and they were all coming out as untagged (native) packets. Other IPv6 traffic behaved as expected. I solved this by creating the VLAN interfaces in the host machine and bridging them to the VM which then saw them as eth0, eth1 etc. I’ll have to investigate this later when I get time, something very strange was going on.

Once you have your IPv6 connectivity up and going your entire network is fully accessible to the rest of the IPv6 world, this includes your printers and your NAS box with those compromising photographs. Fortunately ip6tables is fully developed and it is an easy matter to control incoming connections on your IPv6 gateway. Its prudent to check incoming traffic from the Internet to ensure that it doesn’t have a source address within your delegated address block (spoofing) and to add a blackhole route for your delegated address block to prevent you sending your internal traffic up the link back to your provider.

If you are wanting to use QOS on your IPv6 interfaces don’t be fooled into thinking that the U32 classifier only supports IPv4. I went digging into the IPROUTE2 code for tc and found complete, but undocumented support. If you want to know how to use it with IPv6 see my last posting on this blog on IPROUTE2. Please let me know if you find any errors.

I’ll write this up properly when I get some time along with details about ip6tables, NAT64 and DNS64.

Posted in Blog, ipv6, Linux | Tagged , , , , , , | Leave a comment

IPv6 support in IPROUTE2 U32 classifier

I’ve been playing with traffic shaping (iproute2) for a while now, unfortunately it is the worst documented part of Linux and “tc filter” and “U32 classifier” are no exception. Adding queues (HTB) to the tunnel interface is easy enough but the U32 traffic classifier is a real pain as it doesn’t support IPv6 in the address specifiers, or rather the documentation says nothing about IPv6. The net is full of pages where people say you have to chop IPv6 addresses into 32 bit chunks by hand and match separately on the chunks.

I thought that this is a stupid situation and started to dig into the iproute tc sources with a view to adding IPv6 support and feeding the changes back to the maintainer. During my digging I was astonished to find that U32 has full support for IPv6 already in the code and fully functional (see f_u32.c). Simply use “match ip6″ instead of “match ip” and away you go. The code is clever enough to chop up the IPv6 address into 32bit chunks and only match as many as required to satisfy the netmask. You have the following ip6 directives available to you (addresses are examples):

  • src 2001:0DB8:100:1::0/64
  • dst 2001::0/16
  • priority 123 0xff
  • protocol 2 0xff – This is the IPv6 next-header field
  • flowlabel 123456 0x000fffff
  • dport 53 0xffff – Looks in the TCP/UDP header, make sure you check protocol first!
  • sport 53 0xffff – Looks in the TCP/UDP header, make sure you check protocol first!
  • icmp_type 1 0xff – Looks in the ICMP header, make sure you check protocol first!
  • icmp_code 1 0xff – Looks in the ICMP header, make sure you check protocol first!

Some values for the protocol field:

  • 6 – TCP
  • 17 – UDP
  • 58 – ICMPv6

An example tc filter:

# clean out existing filters
tc qdisc del dev wlan0 root
# Create root to attach filters
tc qdisc add dev wlan0 root handle 1: htb default 20
# example filter: checks for a DNS packet between two specified subnets and assigns it to a queue
tc filter add dev wlan0 parent 1:0 prio 10 u32 \
match ip6 dst 2001:0DB8:101:0::0/48 \
match ip6 src 2001:0DB8:10::0/64 \
match ip6 protocol 17 0xff \
match ip6 dport 53 0xffff \
flowid 1:1
# have a look at the generated u32 filters
tc -s -d filter show dev wlan0
filter parent 1: protocol [768] pref 10 u32
filter parent 1: protocol [768] pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol [768] pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
match 20010db8/ffffffff at 24
match 01010000/ffff0000 at 28
match 20010db8/ffffffff at 8
match 00100000/ffffffff at 12
match 00001100/0000ff00 at 4
match 00000035/0000ffff at 40

The Linux kernel TC classifier code only performs 32 bit matches. 8 bit (U8) and 16 bit (U16) tests are converted to the appropriate U32 match aligned on a 4 byte boundary by the tc command. As we move towards a IPv6 world there would be a lot of sense in creating a U64 lump of code which could take advantage of the 64 bit architecture now becoming common, this would allow a complete 128 bit IPv6 address to be tested in 2 matches in place of the current 4 matches and most of the time a single match on a /64 would suffice. It would involve hacking the kernel and TC then trying to get the different maintainers to accept the changes which appears to be a very lengthy process. The increased throughput on a heavily loaded router running QOS could be substantial though.

I can’t find a manpage for the U32 classifier on my system at and at present there is no official place to put this description. I’m open to suggestions if someone can point me at a place to formally document the IPv6 support in the U32 classifier.

Posted in ipv6, Linux | Tagged | 2 Comments

Linux Quality of Service (QOS)

I delivered a short presentation on how to do Quality of Service (QOS) under Linux at the 2011 Linux Beer Hike. I covered the following:

  • Types of queues
  • Use of HTB to manage bandwidth
  • Inbound traffic policing
  • Use of Intermediate Queues (IMQ)
  • Traffic classification using “tc filter” and IP tables

I’ve not covered TOS/DSCP marking or how to set the required QOS in the application. Maybe I’ll cover it in the future if there is sufficient demand.

You are welcome to
download and share the PDF.

Posted in Linux | Leave a comment

Linux VLANs

I delivered a short presentation on how to manage VLANs under Linux at the 2011 Linux Beer Hike. I covered how VLANs work and the methods of configuring them. Its all very simple and you are welcome to download and share the PDF.

Posted in Linux | 2 Comments

Battery Charging

A couple of days ago I was going through Athens airport when I saw something which at first glance failed to make any sense. The airport has charging stations for cellphones – free for anyone to use.

The person setting up the stations didn’t see the obvious joke in the sign.

Battery charging station at Athens Airport

Posted in Blog | Tagged | 1 Comment

How to defend a NTP server against abusive clients

I’ve been running a NTP server in the pool project for several years now. However I’ve always been plagued by a few clients who put a continual stream of NTP requests into my server. Eventually I decided to do something about it using the IP tables recent module.

The idea is that I drop incoming NTP packets from offenders who exceed a given number of packets per second averaged over a period. After a while they will give up and try a different server.

This has the advantage that it self resets once they get below the threshold, the two lines below will do this with my Debian server (adjust -i to match your interface)

# iptables -A INPUT -i eth0 -p udp -m udp --dport 123 -m recent --set --name NTPTRAFFIC --rsource
# iptables -A INPUT -i eth0 -p udp -m udp --dport 123 -m recent --update --seconds 60 --hitcount 7 --name NTPTRAFFIC --rsource -j DROP

You can view the connecting hosts by looking at the conntrack table:

# cat /proc/net/ip_conntrack | grep dport=123

And you can see what sort of performance you are getting by looking at
the iptables stats

# iptables -n -L -v | grep 123

I’ve been running this for a while and the abusive clients disappeared almost instantly. If I check now it shows very few attempts:

# iptables -n -L -v | grep 123

1038K 79M DROP udp -- eth0 * udp dpt:123 state NEW recent: UPDATE seconds: 60 hit_count: 7 name: NTPTRAFFIC side: source
74M 5613M udp -- eth0 * udp dpt:123 state NEW recent: SET name: NTPTRAFFIC side: source

But I’m serving a lot of ntp clients (between 5k and 8k different IPs per minute):

# cat /proc/net/ip_conntrack | grep dport=123 | wc -l

There is a balance between conntrack table size and count period. A limit of 7 packets in one minute for a client appears to work well and allows clients to use iburst without being dropped.

Posted in Blog | Tagged , | 2 Comments

Getting around Athens Airport WiFi time limits

Athens airport (code ATH) offers free wireless which can be very useful. The only problem is it is time limited to 45 minutes at a time. After that time it stops you accessing the Internet.

The solution to this is to change your wireless MAC address every time it locks you out then reconnect. I’m running Ubuntu so the easiest way is to use macchanger-gtk. The procedure is simple:

1. Disable wireless
2. Run macchanger as root and set a fake MAC address
3. Enable Wireless
4. Reconnect to the Internet and accept the new 45 minutes.

I also flushed the browser cache and cookies just to be safe.

Hope it works well for you too. There are a lot of programs out there to change your MAC address.

Posted in Blog, Wireless | 1 Comment