Trying to get some work done (and meanwhile all hardware items of my new notebook running) has prevented me from going to reboot7 in the morning.

While I then tried to get to reboot7, part of the metro train ride was supposed to be replaced by busses because of construction. The authorities somehow forgot to put any signs or instructions _where_ exactly the replacement bus line is supposed to go. After some searching I decided to go back to the hotel for some more stupid hacking.

I've already discovered the location of the main cemeteries here in town. I'm planning to start my mandatory cemetery tour tomorrow morning.

I'm trying to get all hardware in the Targa MT632 notebook working, and am running into serious problems with both audio and cardbus.

The Audio (atiixp and a realtek AC97 codec) is detected and initialized fine, you can see the DMA proceed while playing. You can even adjust all the buttons and levers of the mixer - but still there is no single bit of sound (or even noise) at the speakers.

I've tried to play with some of the ac97 quirks, but they also failed.

So after some two hours twiddling with various bits of the alsa driver, I'm at the end. I'll try to file a detailed bug-report with the ALSA developers, maybe they have some idea...

As for Cardbus, the PCI code fails to detect a device behind the cardbus bridge. If you plug in a card, the respective event is received and processed. cb_alloc() then (indirectly) calls pci_scan_single_device(), which aborts because of vendor id 0xffffffff :(. PCMCIA (16-bit) is working, though. but who wants slow 16bit ISA compatibility cards these days?

I just arrived in Copenhagen for the reboot 7 conference. Travelling went fine, actually the first time I was using easyJet (one of the new European low-cost airlines). The flight was in the evening, so I don't know if they also try to sell you beer at 6:30 am (like AirBerlin) ;)

reboot7 seems to be quite different from the usual conferences that I'm attending. It's way less technical, so I actually reorganized my gpl-enforcement slides adding some more high-level overview on the subject of the GPL, motivations for copyleft licensing, etc.

I've started to port the PPTP conntrack and NAT helper to the 2.6.11-and-later API changes. Obviously that forced me to look at the code deeper than I did for quite some time. That in turn led me to the discovery of a bug. Obviously, the bug was not hit in most installations, because it's only a bug in the error path.

Expectations used to be kmalloc()ed, so the helper could directly kfree() them without a problem. Some time ago, we introduced a slab cache for expectations, so that would no longer work. Now the code in svn was changed to use ip_conntrack_expect_free().

One of my all-time favourite groups QNTAL has recently released a new album called "Ozymandias". QNTAL is known for their advantgardistic combination of medieval music with electronic sound. The medieval background is easily explained if you note that two of the three QNTAL members are well-known from the medieval ensemble Estampie.

Since I've just seen QNTAL live at WGT 2005, I wasn't expecting too much of the new album. IIRC they were playing three songs of the new album, of which one was the usual QNTAL style, the other two were way to "normal" for my taste.

Now that I've received my latest EUR180 CD order [seems like I'll be again spending more money on CD's this year], I'm amazed by this exceptional new album.

I think the songs can be grouped in three categories. One category (e.g. Flamma, Noit E Dia, )is what I would consider the "usual QNTAL style", which is in the spirit of the first two albums. However, I think it can be clearly recognized that it's no longer Ernst Horn at the synthesizers, and sometimes the digital effects just sound too "digital" compared to the old stuff.

The second group (e.g. All for one, Flow), reminds me a lot to the style of the "Futura" album of Cosmic Baby from about a decade ago. A single classical female singer dominating the overall sound, accompanied by electronic background sound. No strong percussion.

The third group (e.g. Amor Volat) sounds way more "normal" than the other QNTAL stuff. Saying this is not a negative judgement, merely an explanation of how I perceive the sound. More specifically: Less medieval influence, regular percussion, E-guitars, standard "wave" style rhythm.

My personal favorites of the new album are definitely the songs of "group two", i.e. All for one, Flow, Remember Me.

Vienna is well-known for it's historic cemeteries. I always wanted to take some pictures there. Now that I'm in Vienna for business reasons, I at least wanted to visit one of them, the Zentralfriedhof (central cemetery).

The first thing you notice is the magnitude of this facility. Coming from the next railway station, you enter through gate 11. Yes, that's _eleven_. Next curiosity is that there is a dedicated bus line taking you to different parts of the vast area.

I must have spent some four hours there, and it was definitely just a quick browse, I could barely scratch the surface of this beauty.

My photography was hampered by the weather. It was very cloudy, resulting at quite long exposure times even at 400 ASA films - and every so often I had to make a break because of rain.

After getting back to the hotel I discovered a most embarrassing truth. The pictures from the digital SLR turned out fine, but the chemical camera was lacking a film. I was (and still am) totally devastated.

How could this beginner's mistake happen to me? Well, I have two SLR cameras for old-fashioned chemical film. The one I took this time apparently advances the picture counter even if there is no film inside. Despite using that camera for numerous years, I didn't figure that so far. *sigh*.

This means that I definitely have to come back at some later point. Maybe I can manage to get some cheap flight tickets at a time when the weather is better, and I'm less stupid...

Following-up to TomTom (who have ever since our "GPL issue" been very friendly, helpful and cooperative) more than half a year ago, we've now discovered that the NaviFLASH personal car navigation system also runs Linux (and is not distributed GPL compliant).

As it seems, the same or a very similar device from THB Bury might be installed in Bugatti cars. Obviously we have no way to tell whether those cars were sold with a copy of the GPL or not. Anyone wants to do a test purchase? ;)

NaviFLASH have been contacted, let's see how they will respond.

Peppercon "LARA eco" and probably other devices run Linux and other Free Software and do not ship GPL compliant.

Apparently they've been at Chemnitzer Linux Tage, where I've also given presentations for a number of years (including the subject of GPL violations).

It's a pity that a company involved with the Linux community still has license issues nevertheless :(

Ok, now travel season has started. I'll start with a quick visit from 3rd to 6th of June in Sofia. 7th and 8th will be spent in Vienna, 9th to 13th in Copenhagen. 19th to 24th in Karlsruhe. 5th to 7th July in Dijon, 13th to 18th in Montreal, 19th to 24th in Ottawa.

If I'll survive that, I'll probably continue with WTH in the Netherlands - but I honestly fear that I'll be more than exhausted and wish to remain at home at that time. So don't count on meeting me there.

Yes, it has come that far. I just wen to LIDL earlier today, making a test purchase of their latest notebook model, the Targa Traveller 826T MT23. It's a nice piece of hardware, no doubt. 1.8GHz AMD64 with 1GB RAM...

For those who don't know who LIDL is: It's one of Germany's largest budget retail stores (comparable to Walmart, although not in size of the enterprise).

However, I didn't buy the device because it was nice hardware, but because several people had informed me that this might be yet another incarnation of the ever-so-popular "Instant-On Media" devices. The idea is that you avoid booting into Windows by pre-installing a small custom-tailored Linux distribution with a media player (sometimes mplayer or xine, sometimes proprietary).

And obviously Targa is now the third notebook vendor offering such a feature without being GPL license compliant. I've recently figured that the Medion MD95500 and MD95800 (sold at ALDI, LIDL's biggest competitor) had the same issue. As had devices from one of the largest international notebook vendor, whose Name I shall not disclose at this time.

I cannot tell you how sick I am of all of this. Why doesn't anybody care to read the license? On a side note, I once asked an audience of lawyers if they had ever read the full MS EULA. Almost none of them did. Not even the lawyers(!).

I've now given the RFID stack project a new name "librfid". Therefore it now has moved to svn.gnumonks.org/trunk/librfid.

Not much progress over the last couple of days, had other work to do... but I've now a not-yet-committed T=CL transceive function including support for chaining and ack/nack retransmissions.

Imagine you have a RFID reader ASIC that can deliver interrupts at certain events (like transmit timeouts, FIFO watermarks, ...) like the CL RC632. Imagine, you have a USB-attached micro-controller with an IRQ input, like the 89C5122. Now why in god's name would you _NOT_ connect the IRQ output pin of one chip with the IRQ input pin of the other?

That would be too good for this world. The device would be able to signal the interrupt on an USB interrupt endpoint, just like we all know and love.

But there goes the hardware vendor (Omnikey in this case). He doesn't connect those two pins (though there is plenty of space on the PCB, and therefore the driver has to poll the ASIC's status registers all the time. *sigh*.

If the RFID stack (now called librfid) is finished and I still get upset enough about this broken hardware design, I'll connect the two pins myself and use FLIP to flash a different firmware image into the 89C5122.

I've been invited by multiple people to visit ph-neutral, a small but nice meeting of hackers organized by phenoelit. Since I've already been invited (and registered) last year but somehow missed it, I had to be there this year.

The strength of the event seems to be in the "meeting, having fun" part, since at least those two talks/presentations that I've been to were a huge disappointment. I don't want to be more specific and hurt anyone's feelings... but in both cases most of the audience knew more than the self-designated "expert".

Lots of T=CL features such as chaining are still missing, but the code evolves constantly, as is the API (which now starts to become easy and nice). I'm constantly committing to svn.gnumonks.org, for those of you who can't wait.

I'm now also in (temporary) possession of two other readers, as well as a 14443 B-type passport sample (in addition to my 14443 A) sample.

Meanwhile I've also confirmed that the Omnikey 5121 windows reader driver has the same (or a similar) bug as the Linux driver, too. It also refuses to work with any MTCOS based card. I hope the MTCOS sample card I sent them will help them debugging - even though I don't need their proprietary drivers anymore at this point.

Some low-level networking guys (Lennert Buytenhek, Robert Olsson, ..) have figured yet another reason why network performance with high pps (packets per second) rates sucks so much on commodity hardware (all PCI / PCI-x / PCI express based systems).

The 'new' culprit is MMIO read latency. When you're inside a network driver interrupt handler (well, same is true for about any such handler), the first thing you usually do is read the devices' "Interrupt Status Register(s)" to find out whether the device really originated that interrupt, and which condition (TX completion, RX completion, ...) caused it.

Depending on the NIC and driver design, you do multiple reads (and writes, but writes are not that bad) within the IRQ handler.

Lennert has hacked up a tool called mmio_test to benchmark the number of CPU cycles spent. Robert improved it a bit, and I've now added support for multiple network adapters, scheduling on multiple CPUs and other bits.

In case you're interested, it is (as usual) available from my svn server. In case you want to send me some numbers, please always include /proc/cpuinfo and "lspci -v -t" output, otherwise the numbers are useless.

GREAT NEWS! The generic RC632 driver and the CM5121 backend is working, as is the ISO 14443-3 Type A (anti-collision)layer. This means that I'm actually talking to cards, etc.

The next big step is to code the 14443-4 (also known as T=CL) protocol, which is the last element in the chain to use industry standard ISO 7816-4 commands to talk to the chip.

I've also been thinking of what might be an appropriate interface for applications to interface the stack. It's probably because I'm having so much of a kernel-level networking background... but where is that whole RFID stack different from a network? You have packets being sent back and forth, you have anti-collision, you have multiple devices sharing a single 'ether', ...

The whole "7816-4 on top of 14443-4 on top of 14443-3 on top of 14443-2" issue also resembles the OSI model quite a lot, so this could actually map onto the different SOL (socket layers) in the stack.

And after all, why would a socket API like interface be so bad?

Of course this all comes with a severe disadvantage: who wants to have all this stuff in the kernel, if it also works from userspace? Well, the same was true for the first TCP implementations when they were in userspace...

For those who are curious: I've made my current state of development on a Philips CL RC632 driver4 available from svn.gnumonks.org.

Due to lucky circumstances I've been able to get back to do some photography in this area. This also means that I'm actually going to spend a number of hours in the darkroom, developing prints. Didn't do that for more than a year now, and I'm looking forward to having some fun with that again...

The (still incomplete) Fortinet source code has finally arrived. For those of you who're curious, I've made it available at ftp.gpl-devices.org. I'm planning to publish all "GPL code releases" by various vendors on that ftp site in the close future. This way you can avoid the hassle (and cost) to order a physical media via snail-mail.

The Fortinet Linux kernel seems quite a bit modified, especially looking at the network stack. No time to comment on that right now. If you're interested, RTFS :)

I've been spending quite some time lately to re-implement the host-side driver for the Omnikey CardMan 5121 RFID part.

The 5121 is an Atmel AT89C5122 based USB CCID reader, extended by a Philips CL RC632 RFID reader ASIC. The RC632 is a quite common reader ASIC found in many ISO 14443 A/B and ISO 15693 readers of today.

Since the RC632 is common, I'm actually writing a generic RC632 driver. Below the driver there is a "transport layer" that is specific to the CardMan 5121. It's my hope that over time it will be possible to support other readers by adding device-specific transport layers. Above the RC632 driver, there are implementations of the ISO14443 A and B anti-collision algorithms, as well as some code specific to the I*CODE and Mifare proprietary transponders.

So far I think I've written about 60% of what's required to access my MaskTech MTCOS 1.1 (14443A) card.

One of my major obstacles was not related to the RFID stuff at all. I've never learned as much about ELF PIC (position independent code) in its x86 incarnation. For some reason IDA Pro's code analyzer doesn't fully recognize the PIC format of the proprietary driver. It always works for any other .so file I open, but not for ifdokrfid.so from Omnikey. Maybe they're using some strange compiler (or compiler options)...

I'm confident that within the next couple of days I'll have the system running.

As an interesting side note, the RC632 seems to be able to just passively receive, too. I didn't have a chance to confirm this yet, but looking at the docs I have, it should be possible to demodulate/decode without actually sending the main carrier or any commands to the PICC / tag. I always thought that vendors would build their chipsets in a way that no easy eavesdropping was possible. Well, we'll see.

Even though I'm physically back from Leipzig, my thoughts haven't yet arrived. It has been a wonderful time, despite the sometimes troublesome rainy weather.

My personal favourite was the Estampie concert. Open air, in full rain, but an incredible spirit :) Very interactive though, since everybody seemed to gather very close to the stage, me being in the first row.

And since everybody else seems to have gone totally photo-crazy, I didn't even take a single pic this year. One item less to carry :)

After a break last year, I'm this year again vising WGT.

I'm a bit curious on how much I'll be able to enjoy it. For one part, the weather is anything but nice. For the other part, the bands this year seem a little bit less matching my taste than let's say two to three years ago. There seems to be an increasing trend towards 'goth metal' 'nordic metal' and the like :(

Anyway, I'll try to not be preoccupied and enjoy myself. I guess this is also the first time for years that I'm travelling without notebook for four days... so expect even more delayed replies than usual.

I've now started to write some code for the ICAO MRTD LDS and PKI. If you know what that is, stop reading here. If you don't know: It's the crypto and data structures that are going to be present on the new "RFID passports" that will be issued in Germany (and elsewhere) soon.

Nothing seemed to work. Then it turned out to be a driver issue with the Omnikey 5121 proprietary Linux driver. Did I tell you that I hate proprietary software, especially drivers? Well, I'm on my way to re-implement that driver (actually, a generic Philips RC632 driver), too. But I better wait until it works before I start to re-implement the broken one...

So getting back to our RFID sniffing tests, I think the card was probably not even transmitting as expected. All the responses we got from the driver were bogus. This obviously results in no sub-carrier being broadcasted, and would explain why it was impossible for us to catch it in the spectrum analysis.

As it was to be expected from the previous performance of Buffalo, those three CD-R's contain anything but the "complete corresponding source code" for the requested product firmware versions.

I'm going to consult my legal advise on how to proceed.

Adaptec is willing to offer the full corresponding source code of the GPL licensed components of the iSA1500 (and probably other products) online instead of requiring their users to send letters to their legal department.

I'm very happy about this step, since it makes it easier for the users to exercise their right for source code access.

Making it available on the net is not required by the GPL [since it predates todays Internet], so Adaptec actually plans to go beyond what is the absolute minimum requirement. Great!