Updated: Never -- Philip's Blog

BSD Certification schedule

Mon, 25 Jan 2010 08:39 GMT

Looking through my calendar (yes, I have one) for 2010 this morning, I discovered that I will be proctoring quite a number of BSD Certification sessions this year. Plenty of opportunity for people (you?) to sign up!

Chances are there will be other opportunities throughout the year too.

Whisky tasting

Fri, 22 Jan 2010 20:27 GMT

Keeping up the appearance that planet grep is a collection of drunks, I accepted Elise's invitation to join a whisky tasting with a group of people able to compress their thoughts into 140 bytes or less.

First of all, I was impressed at the decompressed presence of all participants. They failed to depict even a single stereotype! Except maybe taking pictures of bottles, but I think that can be forgiven. ;-)

I was particularly impressed by the Caol Ila and perhaps even more by the Black Bush. The Sazerac Rye was also highly tasty, but I felt it was no match for the Templeton Rye Brooks introduced me to a while back.

In addition to whisky, the tasting session also included an amazing stilton and cheddar (not of the radioactive orange variety). I found these went very well with whisky.

In the end, I bought a bottle of Laphroaig 19 year old tastiness. Yum!

I don't think this will be my last whisky tasting session.

New gadget: ThinkPad x200s

Thu, 14 Jan 2010 20:58 GMT

My trusty x60s is "written off" this year, so it was time to get a new machine. Blatant consumerism and all that.

Unless you drink the Apple kool-aid and are able to put up with their programmer-unfriendly keyboards (though that's gotten better of late), ThinkPads are still the only reasonable choice for a laptop. The logical successor to x60s was the x200s.

While I'm generally very happy with the machine (it's even lighter than the previous one and the nine-cell battery lasts even longer - about 10 hours, PXE just works, suspend/resume just works, it still has a proper nipple instead of a silly touchpad -- basically, it's still a ThinkPad) Lenovo made some really strange design decisions this time round.

Why does it have to be so wide? As far as I can tell, the extra width is mainly caused by a wide bezel on each side of the screen. It's still very compact (about the size of a sheet of A4 paper), but it makes you wonder.
The increase in width has subtly changed the keyboard dimensions in a way I can't quite put my finger on. I seem to be making the strangest typos on this keyboard. I'm sure muscle memory will catch up eventually.
Why would you put a camera on a business laptop? Does anyone else feel uncomfortable staring at a camera all day long? I know it's not doing anything (because I don't put drivers for that useful thing in my kernel), but it's just "there". All the time. I'm looking for a sticker to put over it.
The nine-cell battery sticks out the back a bit, like the extended batteries on X-series ThinkPads have always done. It no longer sticks out over the entire width of the laptop though. Which again makes me wonder why the laptop is wider. Surely they could have made a 12-cell battery that sticks out over the entire width, or just preserved the previous width?

I have basically come to terms with the idea of "wide screen", even though it's unnatural and crazy. I find myself using :vsplit more than split, but I still think it's nuts.

This particular model comes with an Ericsson F3507g Mobile Broadband Minicard, which is a very fancy gadget. I haven't tried it yet, because I don't have a spare SIM, but it brings an amazing collection of radios with it. It also adds a privacy concern: "theft deterrents" in the BIOS. I don't particularly want my laptop reporting my location (there's a GPS radio in it) to anyone who listens at all times.

Presumably, these things need operating system support and I can turn them off in the BIOS, but how do I know they're really off? Time to spend some more quality time with the bootloader to make really sure.

Overall, I'm very happy with the new gadget. It does what I need it to do and will presumably do it until it's written off.

I'm still trying to decide what to do with the x60s now. Other than the keyboard, which is predictably beaten up, it's in fairly good shape. Probably donate it to a school or a geek in the larval stages.

FOSDEM 2010 keysigning

Tue, 05 Jan 2010 23:36 GMT

Of course there will be a Friday Beer Event at FOSDEM this year. Only this year, it won't be me organizing it. I felt it was time to do something different and it looks like Jochen has a very firm grip on things. I'm looking forward to attending the beer event as a participant.

What to do with the so-called free time now though?

It seems I've inherited the keysigning bits.

Setting up a very basic key submission server required a mere couple of hours of remembering why Perl is a write-only language. The results of that exercise can be admired at http://ksp.fosdem.org/kspd.pl.txt. Announcing the existence of this service to the world was rather more involved.

The ordeal reminded me -- again -- of primitive cavemen.

Every time someone wanted to paint a woolly mammoth on a cave wall, they'd have to draw it from scratch, either with reference to a previous drawing, or from memory. It was impossible to reuse previous mammoths.

One glorious day, a bright caveman discovered that certain rocks can be rubbed against thin sheets of skin to leave an impression, and the impression can then be used to draw new woolly mammoths. Even more (haha) impressive was that the impression could be used to make a new, slightly modified (longer tusks, who knows?) mammoth-template. Previous impressions could be saved for future generations, to teach them what woolly mammoth looked like in grandpa Thag's youth.

And thus version control was born.

Fast-forward many centuries. People no longer live in caves. Mammoths are now stored in "the cloud". Someone comes up with the wonderful idea of "content management".

One day, someone creates a mammoth and pastes it on the proverbial cave wall. A couple of days later, the mammoth needs changing a bit. In these modern days of the cloud, where mammoths fit in 140 characters or less, this can now be accomplished without going through the pesky process of archiving previous mammoths. Of course, the cave wall could be "configured" to keep old mammoths around, but why bother? In ten minutes time, there will be a new mammoth, and no one could possibly care about the previous one.

And thus version control died.

And mammoths are drawn from scratch again.

As technology advances, humans regress to compensate.

The keysigning announcement is now online. Being the caveman I am, I've also put it in a version control system, far away from any clouds. Just on the off chance that it may come in handy. You know, in a year or so?

Newtonmas revisited

Mon, 04 Jan 2010 10:41 GMT

Google is celebrating Newton's birthday today. Better late than never, but in the interest of historical accuracy, I feel it should be celebrated on 25 December and not on 4 January.

I am aware of the fact that the calendar was fiddled with around the time of Newton's birth, but I think the key defining element of a "birthday" is the day one is born (or birthed, depending on perspective). I'm sure Sir Isaac's mother thought it was 25 December.

If Newton was born in the 21st century, his mother would have had to fight her way through a forest of "christmas" trees to get to the delivery room.

FOSDEM politics ... again

Fri, 04 Dec 2009 16:10 GMT

It has become a yearly tradition for people with strong opinions about certain aspects of the open source ecosystem to suggest very noisily that FOSDEM should share these strong opinions. I don't think I need to remind anyone about the excitement earlier this year regarding one of our sponsors.

This time, Martijn is upset that there will be a Mono developer room at FOSDEM 2010.

Martijn's reasoning seems to basically boil down to we don't need Mono. He doesn't mention who those "we" are though. Mono looks like a very active open source project. Clearly the people working on it feel that it is needed. Martijn seems to feel that the open source software they are producing is not worthy of being produced. By that reasoning, why is there a need for the Linux kernel? Aren't there enough open source operating systems already? The BSD projects have been around for decades. Why have Python and Lua? Perl has been around forever.

I'm sorry Martijn. It's not because you don't feel a certain open source project is necessary that everyone feels that way.

The FOSDEM organization solicits motivated requests from open source projects who feel they would benefit from a developer room. The algorithm for deciding which projects are allocated rooms does not take into account the fact that some people may selfishly feel a project is "unnecessary". Our concern is to get the maximum benefit to open source development from the limited space we have available.

FOSDEM is not interested in politics. We don't want to be a forum for people to tell other people that their work is unnecessary. Strong language about "battles", "victories", "defeats" and "allowing to sneak" should be left at home.

FOSDEM wants to be a productive environment for open source developers to collaborate on their projects. Whatever those projects may be.

Real programming?

Mon, 23 Nov 2009 18:51 GMT

Frank's iPhone developers are stupid! post on Planet Grep today made me a little grumpy.

Stating that iPhone developers are "stupid" because they target a restrictive environment is a bit blunt. Further suggesting that all their problems would magically go away if only they'd write "web applications" is criminally short-sighted at best.

While I'm happy to accept that some aspects of "web development" are "real programming" (and I have great respect for some of the people who identify themselves as "web developers"), I'm not so happy with the implication being made that "web development" has somehow obsoleted or replaced what has traditionally been considered as "real programming".

Frank seems to feel that all the things people want to implement natively could just as well be expressed as "web applications". I beg to differ. "Web applications" may be a reasonable choice for applications involving the manipulation of data in some way, but they're inherently unsuited to many other things.

The iPhone provides a lot of interesting hardware in a fairly compact battery-powered package. I can easily see people imagining things for it to do which Apple did not intend it for. Asserting that "web applications" could be used to implement all these things suggests a very unrealistic worldview.

I don't see "web applications" being used for interrupt handling or DMA or for that matter anything that involves networking on any level beyond the payload of a TCP stream. While those low-level things can conveivably be driven by "web applications" on the presentation layer, perhaps even down to the session layer, something underneath still needs to "be there".

It must be incredibly frustrating to target an environment which only allows "blessed" code to run, especially if the requirements for blessing are not all technical and the organization responsible for the blessing has commercial interests in not blessing code it deems to be threatening in some way.

I'm not very impressed with the "stupid" label being applied to people who can motivate themselves to target such restrictive environments and by extension to everyone who is (still?) not writing "web applications".

When location detection goes very wrong

Fri, 20 Nov 2009 13:36 GMT

Android-based phones use a lot of databases in the sky to determine where people are. Not only does it use tower information, it also uses information from nearby access points. Presumably, Google has a small army driving around all over the world, noting access points it finds. Maybe they're the same people who also take pictures of every building they see?

Today, my phone suddenly decided that I was in Beijing. Strange, I thought. I had no recollection of getting on a plane, the air was breathable and the people around me didn't look particularly Chinese. Indeed, there was overwhelming evidence that I was not in Beijing.

A short while later, my phone decided that I was in Brest. The one in Belarus, on the border with Poland not the one in France, or the one in Germany, both of which are at least in the same timezone as where I really am.

From Beijing to Brest in under ten minutes and yet, I don't think I went through any wormholes. In fact, I was quietly sitting at my desk near Antwerp.

Highly entertaining.

Of course, the building I'm sitting in contains an unusually high number of access points. Usually more than fifty, sometimes more than a hundred. Have Google's location soldiers been a bit too thorough collecting data near factories where wireless access points are built? Or do the databases get confused when you give them too much data? No idea. I don't think the databases or the source code used for location are publically available.

There are a number of interesting drawbacks to the phone thinking it's in the wrong location. It gets the weather (very) wrong, but I can look outside to know what the weather is like. It also helpfully adjusts the clock to its perception of local time. This would be annoying if I used Google Calendar or a similar application which (stupidly) keeps times for events local to where you add the event to your calendar, rather than local to where the event will take place. Certain websites also feel they should speak to me in a different language (and in this case, different scripts too).

Unfortunately, while you can tell the phone not to use wireless location at all, you can't tell it that you want GSM location but not WiFi location. While WiFi access points move around (possibly quite a bit) between manufacture and deployment, GSM location is a bit more deterministic.

Because the access points may move again, there's probably not much point in reporting the access points and their real location to Google. It would be much more useful to have the option to selectively disable sources of location information with more granularity.

I am realistic (cynical?) enough to know that turning location detection off probably adds zero privacy benefit to compensate for the reduced functionality (getting the right time as soon as you get off a plane, for instance) that I just leave it on.

If you're on the run for agents of an Evil Repressive Government, the first thing you need to do is ditch your mobile phone. Buy a new one (cash) if you really need to call someone. Or use a pay phone.

NMBS very thorough

Tue, 17 Nov 2009 10:05 GMT

A couple of weeks ago, I cycled past a sign on my way to the station stating that there would be "significant" traffic problems as they closed a crossing for repair. Of course, the sign didn't mention how these works would impact train schedules or the ability of cyclists to cross the tracks.

I sent an email off Infrabel, who supposedly maintains the rail infrastructure, and got no fewer than three emails back to tell me that my query was important to them and that I was assigned a "file number". Very useful.

More useful was the fact that my questions were actually answered the next day by a very thorough Infrabel employee (with a title like "arrondissementschef", you presumably have to be thorough) and all was well: trains would run as usual (note that this does not imply "on time") and cyclists could cross the tracks.

This morning, I received yet another email noting that my "file" was still open. Uh...

My question was very thoroughly answered
Why would I still be interested in the impact of roadworks between 30 October and 8 November on 17 November?

I guess the answer email just didn't cite the file number.

Now if only the trains could run on time for a change...

Fixing strange DHCP behaviour

Thu, 22 Oct 2009 09:33 GMT

Someone -- I thought it was Kristof, but he claims not to have this problem so it must be someone else -- told me a while ago that Telenet's DHCP server "exhibits weird behaviour". That sort of mystery certainly gets the hyperactive mind interested.

For totally unrelated reasons, I found myself looking at a packet capture of DHCP traffic on a Telenet connection. Indeed, there was something very strange in there. The DHCP client would get a perfectly fine lease with perfectly reasonably renewing and rebinding times. When the renewing timer (T1) expired, the client would unicast a DHCPREQEST to the server and expect a unicast DHCPACK back. Only the DHCPACK would never arrive, and the client would retransmit the unicast DHCPREQUEST messages until the rebinding timer (T2) expired. At that time, the client would broadcast a DHCPREQUEST after which the DHCPACK would arrive.

The fact that the DHCPACK messages came through the DHCP relay server put me on a side-track briefly. I discovered that the DHCP server (mentioned in option 54) would not respond to my DHCP requests. While it makes perfect sense to protect a DHCP server from clients, you do want your clients to be able to get packets to them somehow.

I sent some packet captures to a contact inside Telenet (thanks ;-) I couldn't imagine trying to explain this to a helldesk!) wondering if they'd put too sharp an access control list between me and the DHCP server (recently -- because I hadn't seen the problem before). After some digging, they found that I was sending my unicast DHCPREQUEST messages with a random source port number. From my reading of the RFC, this is "allowed", but no one else does it. It turns out that Telenet does some sanity checking (sensible precaution) on DHCP messages before allowing them to go to the DHCP server. This sanity checking does not like (or recognize, presumably) DHCP messages with a source port other than bootpc (68).

FreeBSD's dhclient is a rather old version of ISC's reference implementation, simplified by OpenBSD. I found that OpenBSD has had a patch for a couple of years that purported to fix this behaviour. When I ported this patch to FreeBSD however, I found that sendmsg would return EINVAL, which was not documented to ever happen.

Again I wondered how people without source code to their operating systems get through the day? Do they resort to alcohol and panic at this stage? I used DDB to set a breakpoint on sendmsg and stepped through briefly, expecting it to blow up somewhere quickly when copying in the iovec or so. No such luck however, and I found myself in sosend_generic, which is not so much fun to step through without symbol information, so I set up remote debugging so I could use ddd.

Eventually, I found my way to rip_output and found that my EINVAL came from here:

if (((ip->ip_hl != (sizeof (*ip) >> 2)) && inp->inp_options)
    || (ip->ip_len > m->m_pkthdr.len)
    || (ip->ip_len < (ip->ip_hl << 2))) {
        INP_RUNLOCK(inp);
        m_freem(m);
        return (EINVAL);
}

Oh dear...:

(gdb) p m->M_dat.MH.MH_pkthdr.len
$6 = 328
(gdb) p ip->ip_len
$7 = 18433

Obviously (to the trained -- or strained -- eye which sees this kind of thing often), 18433 and 328 are strikingly similar. Indeed - it helps if you put the bytes in the right order!

For hysterical raisins, the raw socket interface on BSD-derived network stacks expects the ip_len field of the IP header included when IP_HDRINCL is sent to be in host byte order. dhclient used to only send packets with headers through the BPF, which will put the packet on the wire exactly as given (ie: the ip_len needs to be in the right order). For reasons which don't seem to be explained in CVS history, OpenBSD decided to change this behaviour in their network stack (making it differ from every other network stack and many books written about sockets).

To make a very long story short: I committed revision 198352 to make dhclient on FreeBSD work in networks which put sharp teeth between DHCP clients and servers. Debugging the problem also kept me out of trouble for a couple of hours.

I'm told that finding the cause of weird errors in the protocol stack is now significantly easier with DTrace. I will have to find some time to play with that. While ddd "works", it's not exactly the most pleasant tool to work with.

Entirely aside: I'm still not convinced that "sharp teeth" should care about the source port of unicast DHCPREQUEST messages, but I'm happy to accept that if everyone uses port 68, there's no reason to gratuitously differ from that. Thanks to the Telenetists for helping me look into this.