Launchpad PPA builder status

I uploaded some packages to my Launchpad PPA today. Normally they would build in not less than 20 minutes, however 2 hours later I was still waiting. All my googling for a build bot status page led to nothing useful. wgrant on #launchpad pointed me at https://launchpad.net/builders/ which I though I would note here to help others.

Bzr keeps easing my pain

There has been a trend in the Annodex community lately to move towards using git rather than SVN for source code management. Now while I applaud the move to a DVCS, I hate having to use git. It is just extremely painful IMHO.

I just shouldn’t have to look up a man page or tutorial every time I want to use a tool. Something I don’t have to do with any of CSV, SVN, bzr or mecurial. Git may have some benefits under the hood but I think its user interface still has a long way to go. I can totally understand how git is the perfect tool for the kernel community but I just don’t think it makes a lot of sense for some other communities who have jumped on the badwagon.

The nice folks over in the bazaar community have found a way to ease my pain. Some of you may be familiar with the bzr-svn plugin written by Jelmer Vernooij. Well he has recently expanded on the work started by Rob Collins and now we have a working bzr-git.

johnf@zoot:~$ bzr branch git://git.xiph.org/liboggz.git
Branched 734 revision(s).
johnf@zoot:~$ cd liboggz.git/
johnf@zoot:~/liboggz.git$ bzr log -r -1
------------------------------------------------------------
revno: 734
git commit: ef3b0ebc1fdc299a09119df01fbd1c8867f90d8b
committer: Conrad Parker
timestamp: Wed 2009-04-01 00:59:36 +0000
message:
  Update the link to the theora spec
  Patch by Ralph Giles

Joy!!! Many thanks to the wonderful guys in the bazzar community for making my life so much easier. All we need now is bzr-hg and I’ll never have to leave my comfort zone 🙂

OLPC Library – Trying to get XOs out of people wardrobes

XOs at LCA08

This time last year was a very exciting time at linux.conf.au 2008. The conference organisers had arranged for 100 XO laptops to be given away to conference attendees.

The XOs came with the following message attached.

Please do something wonderful with this XO, or inspire someone else and pass it on.

I was fortunate enough to get one of these XOs. I knew however that I wouldn’t have any time in the foreseeable future to actually do anything cool with my XO. At the same time I didn’t simply want to give it away to someone, since I knew at some stage I would actually want to do something with it.

After chatting this over with a few other people I came up with the idea of putting together an OLPC Library. (It was originally going to be OLPC Bank but after chatting it over with Pia we decided that a Library seemed to fit the ideals of the project much better).

So as part of the work I’m doing with OLPC Friends we have finally launched OLPC Library. At the moment this is just a place holder page but hopefully soon we will have a site up to actually enable people to loan out OLPCs whether that be to a developer wanting to write a new piece of software/port an application or a community advocate putting on a demo at a school or trade show.

If you are interested in helping out you can see the beginnings of the ideas for the website at the OLPC Library Project page and you can also join the mailing lists.

Mac OS X L2TP VPN to Cisco IOS

Just spent a couple of hours trying to get a Mac OS X laptop connected to a Cisco IOS IPSEC/L2TP server. The existing configuration worked fine for windows and linux servers but the Mac just refused to establish a connection. The Cisco logs contained the usual cryptic message.

Dec 16 16:53:47.955: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 117.53.171.241, remote= 124.171.30.131,.
    local_proxy= 117.53.171.241/255.255.255.255/17/1701 (type=1),.
    remote_proxy= 124.171.30.131/255.255.255.255/17/1701 (type=1),
    protocol= ESP, transform= esp-3des esp-sha-hmac  (Transport-UDP),.
    lifedur= 0s and 0kb,.
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x800
Dec 16 16:53:47.955: Crypto mapdb : proxy_match
    src addr     : 117.53.171.241
    dst addr     : 124.171.30.131
    protocol     : 17
    src port     : 1701
    dst port     : 49561
Dec 16 16:53:47.955: map_db_find_best did not find matching map
Dec 16 16:53:47.955: IPSEC(validate_transform_proposal): no IPSEC cryptomap exists for local address A.B.C.D

After much googling I discovered that the problem was dst port: 49561 . Unlike most other L2TP clients the Mac uses a random source port for the L2TP part of the connection. Most others use 1701 for source and destination.

So relaxing this

ip access-list extended L2TP
 permit udp host 117.53.171.241 eq 1701 any eq 1701

to this

ip access-list extended L2TP
 permit udp host 117.53.171.241 eq 1701 any

solved the problem.

It would now normally be the time for me to rant about how IPSEC has to be one of the most badly implemented protocols by all vendors and how getting two different implementations to talk to each other always takes a minimum of 2 hours even if you’ve done it before but it would just be too exhausting.

OLPC Wireless packet loss

Last week Pia asked me to help her out with her yet to be name Australian OLPC deployment. The deployment involves two remote sites connected by an ADSL WAN and one of the key applications across this LAN is the use of the VideoChat activity.

The children at the site were experiencing audio blips and video artefacts, a sure sign of some sort of network related packet loss. With Pia at one site and myself at the other we did some testing to try and rule out the WAN itself as the problem and determine what the issue was.

It became quickly obvious that the WAN wasn’t at fault. We setup some pings with an interval of 1/10 of a second from the XO’s to their respective default gateways and between the default gateways themselves. Pia and I then started counting out loud, which got us a couple of strange looks from children playing around us :). During the audio blips there was no loss across the WAN but there was loss to the default gateways.

Now here comes the interesting part, the packet loss to the default gateways seemed to be syncronised. Now remember these are totally independant wireless networks sitting a couple of 100 kilometers apart. At this stage I was cooking up crazy theories about difficult to decode/encode video packets hitting both XOs at the same time but I was fairly dubious.

We did a little testing on XOs at the same site and while the problem didn’t seem to manifest in as obvious a manner it was still there (I think the latency involved across the WAN exacerbated the symptoms).

Back at home I did some further testing for a few days, trying all manner of different loads and writing various script to watch tcpdump output. To cut a long story short eventually while glancing at the XO during packet loss I noticed the antennae light was flashing which would indicate the XO is disassociating from the network.

A few minutes later I was able to verify that wireless scans were causing the problem and that it is easily reproducible by doing

ping -i 0.1 GATEWAY_IP &

iwlist eth0 scan

You should notice the drop of about 4 packets.

I’ve filed the bug on the OLPC bug tracker

Ticket #9048 – Wireless scanning causes network pauses

A temporary work around is to get Network Manager to stop performing scans, although I assume this means the network view probably won’t get updated. You can do this using wpa_cli.

wpa_cli
> ap_scan 0