The difficult task of designing simple and efficient hardware

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.

My RFID stack now reads the ATS via T=CL

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.

Network performance woes continue: MMIO read latency

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.

Impressions from ph-neutral

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".

CardMan 5121 / RC632 driver and 14443-3 layer working

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...

Preliminary RC632 / CardMan 5121 code released

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

Doing some fetish / erotic / alternative photography again

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...

Fortinet Source code has arrived

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 :)

Rewriting CardMan 5121 RFID driver software

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.

WGT2005 over

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 :)

Problems with RFID sniffing due to bad driver?

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.

I'm off for Wave Gotik Treffen 2005

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.

The first three Buffalo Source Cd's arrive

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 will be offering source code online

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!

New 'cardshell' project started

The idea is to pick bits of zebra/quagga (the interactive tab-completion command-line based user interface), bits of SCEZ, write the intermediate code and link against pcsc-lite ;)

The result is an interactive tool for ISO 7816-4 based chipcards (aka smartcards) that anyone can use to explore such cards. Instead of putting together APDU's by yourself and entering hex code, you can specify easy commands such as "select file absolute fid 1234".

The cardshell core will support plugins for new commands and especially card-specific bits, so you can load a plugin for the specific card you're using.

At the moment I have implemented a couple of basic commands, but I'm lacking important features such as secure messaging. Stay tuned...

It's extremely surprising that up to now there is no such application around. How are people developing smartcard based applications? typing hex bytes by hand?

More news on AOpen

Following up to my post two days ago, the news has now made it to golem.de.

AOpen wasn't quite happy about the bad press, so I was immediately contacted again. They're now working closely with their Taiwanese mother company to become GPL compliant ASAP. I'm eager to see the results, and hope that this issue can be put behind us soon.

However, I now re-discovered that the firmware image is actually download-able from ftp.aopen.de, a domain registered to the German subsidiary. So while the product might not have been sold in Germany, the firmware was actively distributed by Aopen Germany GmbH.

gpl-violations.org related press interviews

The spike of press coverage continues, which is good. There have been interviews and articles in magazines such as Infoweek and Computerwoche. This actually leads to people from outside the Linux / FOSS community recognizing the efforts of the project, and the licensing issues that many companies have when using GPL licensed software.

The FOSS community itself knows about the GPL and it's rules. We need to get this into the heads of product managers and the like. As soon as this happens, we'll probably be at a point where we'll see more GPL compliant products entering the market.

This press coverage has already triggered some interesting replies, on which I do not want to disclose more details at this point.

Back to ct_sync

I've managed to get back to work on ct_sync again. The final steps towards full multi-master operation are underway. Apart from some changes to the protocol on the wire, there is a major reorganization of almost all involved data structures.

I'm deeply sorry for not having been able to continue at the pace that I wanted (and promised some customers), but there have been lots of issues that I couldn't push back and had to deal with them immediately.

Both Acer and iRiver still have issues

Acer has now put up a mirror of all 2.4.x kernel versions on their support website. Clearly they do not understand what the GPL is about, despite our efforts. I fail to understand what is so difficult to grasp while reading a phrase like "complete corresponding source code, including scripts used to control compilation and installation".

Clearly, Acer's Aspire 1800 and 2000 series notebook don't only come with some unconfigured vanilla Linux kernel preinstalled, but with a custom-tailored Linux distribution containing lots of other GPL licensed software.

iRiver seems to claim that they're no longer selling the product in Germany, and therefore don't need to release the source code. AFAICT, there are dozens of online stores who still sell PMP-1xx devices, and even iRiver Germany's homepage still advertises this series of players on it's front page (!).

What is this to tell us? They are not taking the issue of GPL licensing serious. Even after receiving warning notices and having signed declarations to cease and desist.

I'm going to make more and more open statements about such embarrassing details, which I didn't do in the past. Apparently it only helps to put the maximum amount of pressure onto those companies. Sad, very sad. I have no intentions of harming their business...

12h trials of RFID sniffing with no success

Milosch and me were trying for the better part of last Saturday to passively receive and demodulate the ISO 14443 signal sent from a tag/icc to the reader on the 847,5kHz subcarrier that is load modulated onto the 13,56MHz main carrier.

This proves to be more difficult than we thought. Well, we both only have limited experience in practical RF design, so somebody with better skills would probably have helped a lot.

So what did we do? We've built a h-field magnetic loop antenna tuned to 13.56MHz, and tried to get hold of the subcarrier, either by hardware mixing/demodulation or software demodulation using USRP and Gnuradio.

The digital (software) demodulation seemed easy enough, but actually it is limited by the dynamic range of the A/D converter. The subcarrier is only 475kHz away from the main carrier, and it has at least 60 dB less signal. So by doing a FFT on the input signal, you can very nicely see the 13.56MHz carrier, but no subcarrier :(

We've then tried to put a impedance matcher (the opamp way) between the antenna and the USRP (which has roughly 50Ohms input impedance at the BasicRX board). However, apart from lots of distortion, the AD822 based solution didn't make any difference. The subcarrier just seems to be covered by noise.

Our hardware approach was to mix the input signal (especially the subcarrier's upper sideband) with a local oscillator of 3.8486MHz, which should result in an IF of exactly 10.7221MHz. This allows the usage of stock ceramical 10.7MHz IF filters with 280kHz bandwidth. However, we got no noticeable signal at the IF amplifier output of our SA615 based circuit.

So something went really wrong, and probably something that we didn't consider as much as we should have. Probably our test setup using a MTCOS based 14443A ICC and a RC632-based Omnikey CardMan 5121 reader was not a good choice. It was basically running an endless loop with the "Select MF" ISO 7816-4 command. Probably the response to that command was just too short (as compared wit the gap until the next command response is received), and thus we actually had a signal, but not long enough to show up in the FFT. or on the scope screen at the IF output.

Next step will be to build a 14443A card replica, basically a piece of hardware that does a constant load modulation at the right subcarrier frequency. This way we can eliminate too many variables. So when we run our next RFID playground session, we MUST be able to see the subcarrier...

The whole issue has one advantage: I've now actually modelled a 14443A signal (13.56MHz carrier with 847.5kHz AM subcarrier which is in turn ASK'd by a 106kHz signal) in gnuradio. I can TX that signal on the BasicTX output... we'll see if that simulated spectrum actually produces any reasonable result with the SA615based mixer..

AOpen finally responds

AOpen was one of the companies to whom I tried to hand over a friendly letter on GPL licensing at the CeBIT trade show earlier this year.

One of their high ranking managers refused to accept my letter there, asking me to send it to the German subsidiary via postal services. I did so immediately after the trade show, which was in march.

Now (it's May!) they have decided to respond with a phone call. They told me that I should have directed that letter to their Taiwanese mother company, since the products that I claim are in violation of the GPL are not sold in Germany.

They don't get it. Its _THEIR_ problem if they don't comply with the license. Its _THEM_ who are liable for copyright infringement. I don't care which particular subsidiary of a multinational corporation is responsible. It is in the best mutual interest of any subsidiary to assure that they comply with license conditions.

The best I could get was to make them agree to talk to their German management whether they would actually forward the letter to their .tw mother company.