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?

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.

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

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.

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.

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

Belkin seems to be one of the hardest cases we've had so far. It always seems like they're now in compliance, but then something else happens or a new fact appears, and the whole story starts all over again.

Their firmware is compiled with a modified version of gcc-3.2.3 ("Broadcom modifications"). Thus, they need to ship that modified version of the gcc, which is what Belkin now does. However, gcc itself is again GPL licensed, and they need to provide the full corresponding source code of gcc, including any 'Broadcom modifications', too.

It's not really our job to look for every piece of code they release and check it thoroughly for license compliance. It's their job.

Btw, Linksys seems to have similar issues, too.

When will they ever get it?

Adaptec is shipping a number of products in an GPL in-compliant way. We've already enforced the first infringing product that I learned about, the Adaptec iSA1500, an iSCSI storage array.

Instead of showing the community their support and at least providing the full corresponding source code on their download page, they now require you to send a written letter to their legal department to a US postal address in order to get the source code for a specific product.

This really looks like they're trying to make it as hard as possible for anyone to get the sources, while still staying withing the boundaries of the GPL.

I don't really know what they gain by that.

So this was my first day of Curitiba, after being on a scheduled-11hrs but finally 13hrs bus ride from Porto Alegre through the interior of Rio Grande do Sul and Santa Catarina. The bus ride was really nice, something that I could be doing every day ;) Lots of interesting landscape passing by, very comfortable seats and an extremely quiet atmosphere. I had lots of time to listen to music, do a bit of hacking (though typing is a bit difficult considering the condition of many roads), reading as well as thinking about various aspects of life, the universe and everything ;)

I've also encountered to signs that are note mentioning: One was translated to "smile! you are being filmed by surveillance cameras". The other one was "This hard shoulder is provided by the federal government". ;) Unfortunately in both cases I didn't have the time to get my camera out and ready to take a picture. SLR's are just not the right tools for quick snapshots.

In Curitiba itself, it was nice to recognize the various places once again. I yet have to go to my former apartment, but I've seen the former office of Conectiva, the commercial center, etc. Everything has changed quite a bit...

First I was thinking of hiring a motorbike here for a bit of travelling - but then I recalled that riding a bike while having a bit of a flu is not really a good idea, so I'm actually hiring a car for two days now. Planning to visit Vila Velha and Santa Felicidade (which apparently claims to have a beautiful cemetery, for Brazilian standards).

At night went out for dinner with Claudio Matsuoka and Helio Castro. Talked a lot about my travels to India and got them interested in travelling there at some point.

Tomorrow I'll probably be mainly working. Having broadband at the hotel always has a good and a bad side. There's always a pile of work waiting...

Following up my recent patch implementing support for CardMan 5121 and 4000, I'm now currently working on adding support for the latest PCMCIA version, the CardMan 4040 to OpenCT.

The CM4040 seems to be a CCID USB reader with some glue to attach it to the PCMCIA interface. So instead of receiving URB's via the USB stack, you pull them out of a FIFO in the card's I/O address space.

So the first issue is that the CCID code in OpenCT (as much as everywhere else, AFAICT is USB dependent. I've now tried to separate the CCID code from the USB dependent part, and I must be very close to the final solution, since I already see the ICC POWER ON request being sent to the card, and the reply coming back from the card. Now OpenCT calls poll() which is not supported by the kernel, we get -EXIO and disregard the reply from the kernel.

So with some luck, I'll have it running at some later point today.

12 hours after leaving my apartment in Berlin yesterday I finally arrived in Zagreb, Croatia. No, I didn't go by car, but I was using planes.

First I took a MALEV Berlin -> Budapest flight, only to learn in Budapest that the connection to Zagreb has been cancelled. After a four hour delay, they got me onto a Flight back to Germany (this time Frankfurt), where after two more hours I was scheduled to connect to Zagreb.

When arriving in Zagreb, my Luggage didn't appear, so I went to the lost luggage office. To my surprise, the luggage had arrived before I did. This despite the fact that the Malev representative in Budapest re-routed the luggage to assure it would always accompany me on my trip.

Anyway, I finals arrived at about 8pm and went for some dinner and beers with Vlatko, one of the organizers of the CLUC conference.

Today I gave a four hour workshop on netfilter/iptables firewall administration. To the best of my knowledge that went quite well.

Tomorrow I'll be giving a regular netfilter/iptables presentation, something that I didn't do for quite some time. Feels good to talk about technical stuff again, after all the presentations on legal issues and gpl enforcement.

Fortinet has sent out some information to their partners on the preliminary injunction.

They make the following wrong statements:

• The GPL open software project. There is no "open software" and no "GPL open software" project. It's the gpl-violations.org project, and it's about "free software"
• GPL is targeting pro-actively many leading firms. The gpl-violations.org project is not targeting anyone. It just wants to bring commercial users of free software into compliance with copyright and the license terms.
• a very small piece of FortiOS contains GPL software. That is ridiculous. The FortiOS is based on a full Linux kernel, therefore the most important and largest piece of FortiOS is the GPL-licensed Linux kernel.
• We recently [...] have [...] been diligently working with him to resolve this matter [...] and [were] surprised that Mr. Welte pursued a preliminary injunction. Fortinet has not signed a declaration to cease and desist even until today. They were very well informed and warned multiple times that we would seek injunctive relief if they didn't sign such a declaration within a four-week deadline.

As you can see, they're trying to hide the extent of GPL licensed code they use, and they make wrong statements about the gpl-violations.org projects and it's actions.

As indicated in one of my previous blog entries, I've managed to replace the obnoxious Omnikey binary-only i386 driver for CardMan 4000 (PCMCIA) with OpenCT and some glue code.

I've now managed to get the CardMan 5121 running with OpenCT, too - at least the contact based reader (it's a dual interface reader for RFID and contact based ICCs). This was even easier, there was only one minor bug in the OpenCT CCID implementation that prevented this.

The patch has been set to the OpenSC-devel mailing-list.

Whenever my time permits, I'll be hacking RFID support for the 5121, and a driver for the 4040 PCMCIA reader. With some luck, we'll soon see real Linux (i.e. free software) support for all their devices.

Some months ago, I included per-connection packet and byte counters to ip_conntrack (CONFIG_NF_CT_ACCT) into Linux-2.6 mainline. However, reading the entries from /proc/net/ip_conntrack is not really a useful interface to access those counters.

I've now merged Pablo Neira's latest ctnetlink/nfnetlink changes with mine, and patch-o-matic-ng now includes support for dumping the counters to userspace.

With any userspace program (using libctnetlink) you can then retrieve the counters. Either you wait until a connection dies (and receive the DELETE message from the netlink socket, containing the counters), or you regularly issue a request to list-conntracks-and-reset-counters-to-zero request.

The conntrack tool in subversion now already includes support for this, see the conntrack -E conntrack and conntrack -L conntrack -z commands.

I've also picked up working on ulogd2 again, to provide a all-in-one solution that allows you to create IPFIX (aka NETFLOW) records or put the per-flow accounting data directly into a SQL database. If everything works fine, I'll be finished in a week or so.

TVRX is the first real HF frontend by Ettus Research for the USRP. It is based on a microtune tuner and covers 50 to 850 MHz RF.

I'm still intending to build a couple of frontends on my own. One of the most important ones would be a 15.6MHz frontend for ISO 14443 and 15693. Also, I have already obtained a number of tuner samples with I/Q output, which would make perfect match to the USRP.

Meanwhile, I'm still experiencing a lot of problem with gnuradio. While the USRP communication seems to work fine, gnuradio segfaults all over the place. Maybe this is related to x86_64, but I cannot say more about it at the moment.

Yesterday, the Munich district court granted a preliminary injunction against Fortinet's GPL in-compliant use of Free Software.

Fortinet is shipping a series of Firewall products (FortiGate and FortiWiFi) running on Linux without complying to the GPL.

Legal action was made possible via the "initrd" code, on which Werner Almesberger signed me his rights a couple of months ago.

To the best of my knowledge, Fortinet is not using any of the iptables/ip_conntrack/... code, but something different. We'll see how that is integrated into the kernel network stack as soon as they release the full corresponding source code in accordance with the GPL.

I'd like to thank my lawyer Dr. Till Jaeger from JBB Rechtsanwälte and Jürgen Lüters from Intranet Engineering, the technical expert in this case.

Obtaining (better: Applying) for a preliminary injunction is a tremendous amount of work, so this really is the last possible option if all other options have failed.

Also, making this issue public with a press release was a very well-thought action. Fortinet did not even sign a declaration to cease and desist within four weeks after receiving the warning notice. They apparently didn't want to believe that this is a serious issue. Maybe the public pressure will help getting them back to negotiations.

It's amazing what kind of websites people are starting. This one is definitely one of the most geeky subjects I've seen so far.

Unfortunately most of the conntrack/nat helpers in patch-o-matic were broken ever since 2.6.11 was released. The reason is the new semantics of the redesigned conntrack/nat helper API by Rusty Russell and Pablo Neira.

It's not an easy and straight-forward port, and as usual there were not many people volunteering for that job. Max Kellermann is a positive example, he ported the h323 helpers.

I've now ported the all remaining ones BUT the PPTP helper. At the moment I'm not sure whether the PPTP/GRE helper can be ported/used at all with the new infrastructure :( This will need some serious amount of thinking.

All the ported helpers are available from pom-ng. I don't have the possibility to test them, since I don't actually use most of those protocols. Testing / debugging / bug reporting is therefore very welcome. Anyone writing a test case for nfsim would be my personal hero.

The last two days I was at a network performance lab in Stralsund, Germany. We were testing dual Opteron 250 (2,4GHz) machines with e1000 cards and Linux.

One of the interesting results was that ip_conntrack [again] scales better as the load generators. The generators couldn't establish more than 25,000 new TCP connections per second and no more than 1 million total concurrent connections ;)

Thus I'm now pretty much convinced that ip_conntrack scales quite reasonable, and we should concentrate optimizations to other areas of netfilter/iptables.

I don't usually join the never-ending discussion on proprietary vs. free software, since I know what I think is best for me anyway.

But there is one quote that I'd like to add to this blog, because it's [unwillingly] funny:

That is the literal translation of one of the headlines on the German Microsoft homepage ("Windows-Benutzer haben weniger Sicherheits-Schwachstellen als Linux-Benutzer").

Today we again had our monthly chaosradio live show. The subject that we picked from the list of suggested topics, and it definitely was worth doing a 3 hour show on it.

Computers always get faster. The downside of this is that they always consume more energy. From 1W of a 80386 to 15W of a Pentium I, we've now arrived at more than 100W for the latest PC CPU generations. The PowerPC architecture was quite promising for some time, but at least since the G5, power consumption is almost equal with the Intel world. About the only promising figures come from ARM based CPU designs at the moment - something that you will find in PDA's and embedded devices, but not in desktop machines.

Apart from the power consumption we're also talking a bit about the ecology in general, like the amount of energy and raw materials required to build a new PC. It is quite considerable, especially taking into account that most PC's are not used for more than two to three years.

In case you're now interested (and understand German): A recording of the live is available for download.

Actually I bought the machine including a liquid cooling system, since I've become very sensitive towards noise over the years. However, I also wanted to have a very specific (small) case, probably the smallest EATX case that exists.

Oh yes, btw, the workstation is a very decent dual Opteron 246 Machine, with 2GB of DDR400 RAM on a Tyan S2885 mainboard and three SATA drives (of which usually one one is actualy spun up). The system was actually provided by Astaro, since I've complained about their previous way-too-loud Sun v20z test machines that I used to have in my kitchen for some time ;)

Then something unexpected happened: The producer of the cooling system went out of business, and I had to get another one from Alphacool. That system is different to the previous one in that it uses a radiator with two 120mm low-rpm papst fans. The intended original system would have had a totally passive system, no fans at all.

So in the end the system was shipped standard, with air-cooling, large zalman CPU fans, etc. The Alphacool cooling system was DIY and would have never fitted in the case that I chose.

Now, a few months later, I've finally managed to install the liquid cooling system. It required quite some amount of 'case modding', since both the radiator and the compensating reservoir had to be installed externally,requiring some four 12mm holes to be drilled for the tubes, plus an additional number of 20 mounting holes.

I'm very satisfied with the results. The only thing you can still hear is the little noise emitted by the pump. The CPU's are running at 28 to 32 centigrade under full load.

Some months ago, when I first discovered bwtorrents, but that's "full" with 40k users... seems like a strange idea to me, since the torrent distribution mechanism works better the more users you have.

Since I'm doing some work with cryptographic smart cards, I wanted to get some PCMCIA/PC-Card smartcard adapter. This would save me from carrying the somewhat large USB-based devices that I have.

So I found reasonably priced Omnikey CardMan Mobile 4000 and Omnikey CardMan Mobile 4040 devices.

The vendor claims in the download section of his homepage to have "Linux Drivers, Source Code". That was enough for me to actually buy the device.

I should have read the "source code" first, since what they actually ship is a BSD/GPL licensed kernel module together with a binary-only i386 ELF library. So now the device is totally useless to me, since the only machines with PC-Card or PCMCIA slot that I own are non-i386 (ARM, MIPS, PPC, x86_64) - including my Notebook, for which I actually bought the device.

So I contacted their support, but all they told me is that they wouldn't release the source code to their library, since it contains "valuable driver know-how". I explained in deep detail how that actually harms their users, tow which they just responded with "we know that we cannot make all users happy". Then I explained to them that EU copyright explicitly allows reverse engineering for the purpose of interoperability.

And that's what I actually did. So their "valuable driver know-how" came down to the implementation of the ISO/IEC 7816-3 T=0 and T=1 protocols, of which there are plenty closed and open source implementations, for example in the REINER SCT CyberJack driver that I happen to maintain, or in the OpenCT package.

A couple of hours later I wrote an OpenCT backend for the CardMan 4000. It works, at least I've successfully managed to issue basic commands with both T=0 and T=1.

So what does this tell us about Omnikey AG? That they are a bunch of corporate suits who'd rather trick their users with wrong advertising statements ("source code driver") than to release a shared library that has been replaced by something like four to six hours of work.

I'm likely to add OpenCT support for the Omnikey 4040 and 5121 devices, too. They're a bit more tricky to interface, but apparently they're somewhat designed with the CCID spec in mind, although not fully compatible.

Hopefully within short time, the users will be freed from Omnikey's Intel lock-in policy., and nobody will have to use their non-free software anymore.