The main reason why this blog has been so quite since my return from Bangalore: I'm spending every free minute in preparations for 22C3, the annual Chaos Communication Congress. As usual, my job is to take care of the audio and video recording and streaming.

So for the last days I've been hunting numerous bugs related to this, mainly in ffmpeg, but also radeonfb, vlc, Debian ffmpeg / x264 packages, etc.

I'll be back on track after 22C3 is over. More blog updates then, I promise.

Today I finally received PDF's of the Siemens BS-11 GSM BTS. This means that I'll now be able to actually connect the device to power, E1 and RS232.

Unfortunately I'm still lacking the configuration software for the device, and a corresponding E1 card for the Abis interface. Anyway, seems like we're slowly getting there. Maybe during Q1/Q2 2006 I can spend some time actually implementing code for that beast.

This means that there is now very little code duplication between the mysql and pgsql drivers, since all the high-level functionality is now 'abstracted away'.

I'm not going to write any more about FOSS.in, since everyone else has already written about anything that there is to say. If you want to read all of it, go to planet.foss.in.

One fact that hasn't very much publicized [yet?] though, is the financial trouble that the event formerly known as Linux Bangalore is going through this year. This apparently is almost exclusively to blame at the sponsors (or lack thereof).

Apparently in India it's quite normal that even if you start talking with Sponsors more than half a year in advance, they will not commit until a few days before the event starts. This is also the reason why the conference programme is announced before the sponsors show up on the website (if you checked it before the event, all the sponsor banners were empty).

Due to this strange culture, it could happen that a large Indian IT company dropped their sponsoring commitment almost immediately before the event - that is _after_ the organizers having committed to all the expenses. I don't think that given those conditions, any organizer could have managed without a big large gaping hole in the budget :(

In addition to that, it is is a pity that none of the internationally recognized (and also locally quite present) "open source" companies Novell/SuSE and RedHat didn't show up on the sponsors list at all.

Sometimes I really feel like I don't understand what's going on with some projects and/or developers. The last time I looked at libusb source code, it was the 1.0.7 release - and everything was working as expected. When you submit a bulk/interrupt read request, then it would do a blocking read until the user-specified timeout has expired.

When recently strace()ing a program using libusb, I found out that with my currently-installed version (1.0.10a), it actually does a non-blocking read (REAPNDELAY), then uses select to implement a 1ms sleep, and starts all over again until the user-specified timeout has expired.

This is really bad. Not only clutters it your strace output with lots of noise, but it actually uses CPU, wastes cache lines, and probably most importantly: eats battery on notebooks!

I'll ask the libusb folks what kind of madness this is. Probably it's time to publicize libausb at some point (the libusb-wrapper that I implemented for async URB handling in the ctapi-cyberjack drivers) - and which now uses a copy of the libusb-1.0.7 functions for blocking bulk read/write, too.

I've just checked in a userspace-only version of the cyberjack e-com (0x100) driver. This means that we'll finally be able to work around the many broken old (drivers/usb/serial/cyberjack.c) cyberjack drivers that almost all the distributions ship. Apparently almost none of them seem to bother merging upstream fixes into their trees.

One minor problem though is that both cyberjacks need asynchronous delivery of interrupt URB's, a feature that is not available by libusb. The libausb wrapper library that I developed for this purpose is specific to Linux usbdevio, so the userspace driver won't be working on other libusb supported platforms such as *BSD :(

This is in response to Oh my, this was from running yum update on a 2.6.13 FC3 system and had reached the transaction test but got OOM killed.:

I've seen this numerous times on FC3 (probably even older FC) systems, and no matter how large you make swap, it never really works. The only workaround I found is to manually split the update into tiny chunks, and then update those tiny chunks each itself rather than a full system-wide update.

This is the third day of FOSS.in 2005, for me it's the second day, since I arrived one day late.

I'm having a good time, and the conference has come quite some way since last years Linux Bangalore. To highlight some of the changes:

• Wireless Access almost everywhere on the venue!
• Enough halls (actually: tents!) to host BOF sessions and the like
• Lecture halls large enough to accommodate the whole audience
• A much wider scope, Free/Open Source software in general, rather than just Linux
• Lots of interesting presentations
• Way better quality of food (even though it wasn't really bad before)
• Sensible temperature instead of ridiculous amount of AC in lecture halls

Also, since the same amount of attendees are distributed over a wide area and more lecture halls, it is less crammed/crowded than the previous year. At least for people from a western country it therefore is way more relaxing, since there is more space between you and the people immediately surrounding you ;)

ulogd has practically always been a sub-project of the netfilter project, but was hosted at svn.gnumonks.org for historical reasons. I've now cleaned this up.

ulogd-1.x is now hosted at https://svn.netfilter.org/netfilter/trunk/ulog/ulogd/, ulogd-2.x at https://svn.netfilter.org/netfilter/branches/ulog/ulogd2/.

As the frequent reader of this blog will know: In order to keep track about all the alleged/confirmed gpl violations, and the progress in their resolval, we're now using RT (request tracker).

Since the request tracker was introduced about one month ago, we've received an incredible amount of reports. Today I opened ticket number 64 (!).

I don't really have those kind of automatic statistics on the number of reported violations before, but it was certainly less than that number...

Sometimes I really think that I'm insane. In the last week alone, I've spent some 7000 EUR in test purchases to prove GPL violations. Yes, I'll get reimbursed once those cases are over, but somehow I feel like giving loans to those companies who don't obey the license. If I'd put that money into a bank, I'd at least get some (crappy) interest rate.

There are so many cases that I would like to write/talk about, but cannot because they're still not over yet. *sigh*. Let's hope I can publish some news before I leave for my 11 day trip to Bangalore for FOSS.in.

When I'm back, I can be sure that there's a stockpile of devices to analyze. Wish I could spend that time with something more productive, though.

I've just done a quick browse through the FOSS.in schedule. I'm honored to give my two presentations in the "Stallmann Hall".

There's also an OpenSolaris track. I'm probably going to join that, since I know close to nothing about it (yet).

Finally, my ported/cleaned up Omnikey CardMan 4000 and 4040 (both PCMCIA smart card readers) kernel drivers have been included in 2.6.15-rc2 pre-release.

Ok, now I am in contact with one guy that managed to run a working kernel that he compiled himself from the source code that Motorola Hong Kong has published.

This finally confirms that the kernel (even though it was requested for E68) works on a A780 without further modifications. On the other hand, I'm a bit puzzled why it won't work here. To figure out where the problem is, I've asked him to pass me the exact source tar-ball that he was using, plus detailed information on his cross toolchain.

I've also started over again from a 'vanilla' Motorola kernel tree and will give it another try. If this works, I'll re-try with the serial console, and if that works, move on to the 2.6.x tree (which I'm planning to make public this weekend, btw).

Meanwhile, I have confirmed that the bootloader is actually based on blob, and thus also needs to be released under the GPL. This, in turn, should facilitate the development of a GPL licensed host-side replacement of PST for flashing the phones.

I'm a bit worried since I'm busy with many other things over the next couple of weeks. But even while travelling, I'll have the full toolchain, sources, and everything with me.

Starting today, I'm the 'proud' owner of a Siemens BS-11 GSM BTS.

If anyone has documentation on

• The polarity / signal / pin descriptions of the connectors
• The Siemens vendor specific extensions to Abis (The GSM protocol between BTS and BSC)
• Whatever other documentation/information on the BS-11

The whole purpose of this exercise is to do some [security] research in the GSM area, and to see whether it can be done to implement the BSC-side of Abis (and a minimum emulation of HLR, MSC, ..) in order to get a phone to talk to the BTS.

This is yet another of my many toy/pet projects, so please don't expect any even remotely useful code anytime soon. Chances are likely that this project won't go anyway due to lack of time.

It seems like DaveM was away, there was some communication problem that lead to the fact that none of the netfilter related fixes went into 2.6.14.y series (up to 2.6.14.2) so far. I'm sorry for that, and all the fixes have been submitted now.

So lets hope 2.6.14.3 will have no known netfilter related bugs.

Today I've finalized my preparations (paperwork, etc) for passing four more gpl violation cases off to my lawyer. As usual, I don't state the names of the vendors/products at this time.

There has been quite some amount of backlog piling up, as I've been busy with other (more interesting, to be honest) stuff in the netfilter, openmrtd and OpenEZX world. Luckily we're now using RequestTracker and hopefully don't loose any reports of violating products.

To be more efficient in flooding DaveM with netfilter patches, I've now hacked up a set of 'wrapper scripts' around my git tree. They enable me to efficiently apply patches to my tree, generate sequential sets, and send them off (actually not using a mail user agent).

This means, that for now my patch submissions are (like those of 99.9% of the other kernel hackers) not PGP/GPG signed. If I find some time, I'll add that feature to my script.

Anyway, I've sent off the first set of 10 netfilter patches and it worked like a charm.

Some of you might have already read it, Sony distributes a 'root kit' with their DRM-encumbered 'copy protected' Cd's. This basically allows Sony to control your computer, once you've installed the software contained on on of their audio Cd's.

While this in itself is already a security nightmare (especially since they don't inform and/or warn the user about this), it gets even worse: According to a number of sources, this software even contains a statically linked version of the LGPL licensed liblame homepage.

I guess this gives a really strong measure: In order to protect our valuable copyright on proprietary music, we don't give anything about the copyright of others, such as authors of free software.

Ok, finally. After David Miller has returned from his holidays, nf_conntrack has 'magically' ended up in the mainline tree. Stateful IPv6 packet filtering in vanilla 2.6.15 is therefore reality.

Thanks to Yasuyuki, DaveM, Acme and everybody else who has made this happen.

Today I had the honour of holding a guest lecture at the Institute of European Media Studies of the University of Applied Sciences in Potsdam. The lecture was entitled "Privacy, Data Protection and Surveillance - Risks and side effects of modern communication technology".

To my big surprise, the lecture was very well received, and members of the institute have suggested that they are interested in some follow-up lectures on other topics such as copyright / software patent / GPL issues.

I've managed to add support for 212, 424 and 848 kBps 14443A support. 214 and 424 seem to be running quite stable, 848 is not very stable. I'm not sure whether there's something wrong with my configuration, or whether this combination of reader and smartcard just are instable at 848k.

Fixed some data corruption bugs in libmrtd as well, and made both librfid and libmrtd use autoconf. There's still lots of cleanup work to be done, but basically one could now start to write a GUI application on top.

While working on librfid support for the Pegoda Reader (which is basically 50% done now), I've discovered what my problem with librfid's MiFARE classic support was: I was using the wrong keys. Apparently Transponders issued by Philips have { 0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5 } as their default key, whereas Transponders from Infineon have { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }.

I seem to have Infineon samples, and I always tried with the Philips key. After fixing this, reading sectors off a MiFARE classic card seems to be working.

ulogd2 has now reached beta stage, and it now has almost all the plugins of ulogd-1.x. Only the SQL database backends are missing. It also features a ctnetlink input plugin for flow-based accounting with 2.6.14 kernels.

Next, I'll be working on documentation, testing and on some simple IPFIX output plugin.

Today, I spent a lot of time doing releases of libnfnetlink, libnetfilter_log, libnetfilter_queue, libnetfilter_conntrack and the conntrack program.

The amount of manual XML editing, copying of files, checking in stuff, ... required to do a release is way too much. We definitely need some release automatization.

In order to make librfid cover more readers than it currently does, I've obtained a Philips Pegoda (aka MF EV700) reader.

It's based on the CL RC500, one of the predecessors of the CL RC632 (which librfid supports natively). However, the low level protocol processing is implemented on a Infineon C161U (C166 core with USB interface), so the interface towards the reader will be on a very different level than for the Omnikey one.

See the 1.3.4 release page and the ChangeLog.

There are chances that I'll be able to make it to FISL 7.0, the 2006 incarnation of the Forum Internacional Software Livre.

This is not just any other conference visit. This is the possibility to visit Brazil for the first time after my departure from Conectiva in 2001. This means I'll be able to meet all those cool guys again (folive, lclaudio, matsuoka, epx, ... you know who you are). Only few of them are still at Conectiva, but to the best of my knowledge still somewhere in Curitiba or Porto Alegre ;) or Rio Grande do Sul

Anyway, I'd better organize my schedule in a way that permits me to spend some three weeks in Brasil next year :)

After some massive hacking session yesterday, BAC is now working. I can now establish an authenticated and encrypted session to my passport samples, and read data off them.

Still remaining on the TODO list is: Passive Authentication, Active Authentication and a nice GUI frontend.

I have lots of netfilter and OpenEZX work pending, so it's unlikely that I'll continue with libmrtd during the next couple of days.

Northwest Airlines has been heavily advertising their Seattle-Amsterdam-Bangalore flight, including special offers. And what do they do two days before starting that flight? They postpone it indefinitely.

This is certainly the right thing to do if you want to piss off new customers. There was only one reason for me to go for NWA: Because they have a direct flight to Bangalore, with no stopover in Mumbai or Delhi. Now that reason has vanished. And since there's now only four weeks before departure, there's even no chance I could get some other direct ticket for a decent price.

I'm yet waiting with my travel agent getting back to me. Apparently NWA first informs the press, and then slowly their customers at some later point.

I've already received three different serious bug reports about problems with netfilter/iptables in 2.6.14. This is frustrating, considering how long the 2.6.14 development cycle was. People should try new features of a new kernel _before_ there is a release. Afterwards it's too late.

It seems like even though the specification looks quite verbose upon first sight, there are many tiny pitfalls in implementing basic access control according to the TR-PKI 1.1 specification.

Padding is such an issue. You always pad for DES en/decryption, _but not_ if you are in the mutual authenticate command ;)

I now have the key derivation, authentication and setup of session keys working. Secure Messaging still has some problems with regard to the DES retail MAC. Let's hope I get this finished soon.

According to this zdnet.com article, there is now an insurance against legal risks from violating Free Software Licenses.

Strangely, that article claims the insurance is about "the risk of using open source software". This is misleading, since there is no risk involved in _using_ the software. There is, like with any other software, a risk when you violate the license.

One wonders when we'll get such an insurance for "the risks of using proprietary software [without obtaining a license]".

This means that I've immediately pushed three netfilter related changesets, the biggest (307k unified diff, roughly 10k lines of code) was nf_conntrack.

Given the specific situation that David Miller is on holidays, and we have Arnaldo Carvalho de Melo maintaining the network stack meanwhile, Linus hasn't accepted that huge patch in the first round, since he lacked explanation why such a monster was required.

I hope my comments will convince him that nf_conntrack really is the way to go.... let's hope we'll have nf_conntrack mainline in one or two days.

I hope Yasuyuki (the main author behind nf_conntrack) will make a big party with his USAGI friends once that happens ;)

linuxdevices.com reports about OpenEZX. In that report, it quotes Motorola's chief architect of mobile devices: Motorola had no immediate plans to support native Linux applications on its phones, in part due to carrier concerns about network health, security, and interoperability..

This is just not true. In fact, the A780 as it ships in Germany comes with a native GPS navigation and routing application called "CoPilot". Also, since the whole GSM stack runs on a different CPU than the Linux OS, there are no security/interoperability/network health concerns that I could think of.

Also, I have received reports that Motorola actually distributes a Linux SDK to selected third party vendors. Parts of those SDK's (the header files for the EZX libraries) have actually leaked, which support the position that there is a SDK.

In many ways, the EZX phones are a combination of a traditional Neptune-based Motorola GSM phone, plus a Linux-based PDA. Therefore, if any native Linux apps on the PDA half could influence the 'network health' in a negative way, then any other Neptune based phone could, too.

To my surprise, Werner Koch (author of gnupg) has jumped into the 'librfid' project by contributing his USB CCID low-end driver to it. Using this driver, it should be possible to use librfid directly on the reader, instead of going via OpenCT. There's nothing wrong with OpenCT, as it is the only way to support contact-based and contactless operation at the same time. However, for development and testing, most people don't really need that feature.

Unfortunately it only works theoretically, must be some minor difference in device initialization that causes breakage.

If you've now thought about something sexual, I have to disappoint you. At least this time I'm talking about ISO/IEC 7816-4 SM (secure messaging) ;) For those not familiar with cryptographic smart cards: SM is similar to what SSL/TLS do for TCP.

The code for re-formatting the 7816-4 APDU's into further levels of ASN.1, including padding rules, encrypting, authentication, ... has become quite complex. It's also not finished yet, and I already fear testing/debugging of that beast.

The next milestone of the libmrtd project, a ISO/IEC 19794-5 parser. ISO/IEC 19794-5 is titled "Biometric Data Interchange Formats - Part 5: Face Image Data" and provides an international standard for facial images and related information (such as angle of the face, MPEG4 feature animation point, encoded information about medical glasses, eye patches, etc.).

Using this parser it is possible to extract all the image metadata plus the JPEG image itself from DataGroup2 of an ePassport. I've tested it with two passport samples from different vendors, and it works fine.

The next milestone are cryptographic routines for checking the document signature (Passive Authentication) and Active Authentication. Also, Basic Access Control needs a lot of testing.

Today, the sixth "Oscar awards for data leeches" will be awarded. The BBA is a "negative award" or "anti award" for persons, organizations, companies, government agencies that disrespect civil liberties, data protection and privacy.

I've always been a big fan of those awards (which are now even awarded in a number of countries outside of Germany, too). They provide an excellent opportunity to publicly point at (and rant about) those who further restrict the [digital] freedom of individuals.

This year I'm going to be present at the ceremony for the first time.

One of the best early design choices of iptables was its support for plugin matches and plugin targets. Over the last five years, we have seen some 100 of such user-developed special-purpose plugins.

Obviously quite dangerous, but the author includes a time stamp and a cryptographic signature, so replay attacks can only occur in a very small time frame.

It's definitely a cool hack, although I'm not sure whether I'd want to put this on a production system or not.

The FreeDOS project has discovered multiple GPL violations in the commercial and proprietary DR-DOS 8.1 product.

Readers of this blog will already know it since quite some time: I've been working on a RFID stack, a library for accessing electronic (biometric) passports, as well as a matching frontend application.

anyway, since librfid now has stable support for ISO14443A and B (both used for ePassports), and libmrtd now successfully parses EF.COM, EF.DG1 and EF.DG2, I think it was about time to do a public announcement and a homepage for OpenMRTD.org.

Today, FOSS.in (the event formerly known as Linux Bangalore) has released their first list of confirmed international speakers.

I could hardly believe my eyes, it is truly amazing. Is this the event that I've been to in 2003, as one of the only two non-Indian (and non-Indian origin) speakers?

Now they have a line-up including Jonathan Corbet, Brian Behlendorf, Jeremy Zawodny - and last but not least Alan Cox!

Please don't misunderstand me, there is no 'quality ranking' of conferences based on their number of foreign speakers. But this at least proves that FOSS.in has become an equal event in the line of Linux Kongress, UKUUG or even OLS.

As of now, the number of Indian Free Software developers, maintainers or even project leaders is still very small. This especially holds true when you consider the size of the Indian IT industry today...

So getting together the FOSS enthusiasts in India, and the international "FOSS veterans" should create a very creative environment and provide an excellent opportunity for lots of people to get motivated, to get involved, to write code, to join the Free Software community.

In his blog, Brian points out that the Barracuda Spam Firewall 300 seems to be violating the GPL.

It's not yet clear what kind of software they actually include, but if a customer (who has received a binary copy of the GPL licensed Linux kernel) calls them up and explicitly asks for the source and then gets fishy answers like those pointed out in Brian's blog, then there's certainly something wrong.

Thanks to my friends at maintech, The OpenEZX project now has a Wiki.

I've only added some very basic information, but I hope that developers and users especially from motorolafans will contribute soon.

One of the important things we need soon is a project logo, for both the website and the wiki. Volunteers welcome :)

After having finished Mifare ultralight support (and being able to read out a champions league ticket from last year), I've now implemented Mifare Classic support (i.e. Mifare 1k/4k) for librfid. Authentication and reading seems to work, I haven't looked into write/inc/dec support yet.

It seems like librfid is doing quite fine at the moment, I'll continue working on the ePassport related libmrtd tomorrow. So I hope there will be another interesting announcement tomorrow ;)

I've been in contact with Imre from openwrt.org for quite some time, especially since he's now actively maintaining a lot of stuff on the ftp.gpl-devices.org ftp server.

Today I had a look at the current status of OpenWRT, and I was delighted to see that there is a lot of progress. Apart from the 2.4.x kernels with proprietary WLAN drivers for Broadcom platforms (like the wrt54g), they now work on supporting TI AR7 based systems and also on soekris hardware.

What is even more interesting are

• The bcm43xx driver project, aiming at at free software Broadcom wireless driver
• The bcm-specs project, trying to write specifications for the Broadcom wireless chipsets

I really hope that those projects will receive all the support they need, and at some point in the future we'll have excellent free software support for all those devices. If only the vendors were more cooperative from the beginning...

I receive many emails indicating that my GPG/PGP key has expired.

This is not true, about a year ago I altered its validity to extend beyond the original expiry date at some point on October 2005. I chose this way since it was possible (rather than creaging a completely new key).

Please re-downlaod the key from your favourite keyserver. If the problem persists, please tell me which keysever still gives you a key with an expiry date, so I can fix it by re-sending my current key to that keyserver.

Thanks for your cooperation.

When I launched the OpenEZX page two days ago, I didn't expect such a massive (press) response to it.

All I did was to write a small announcement to my weblog, and it was picked up by a lot of press, such as lwn.net and golem.de.

Looks like this blog is read by a lot of people, and there's nothing I can't post here that doesn't get immediately distributed to a lot of places. Amazing ;)

Also, I've even received multiple requests for EZX-based consulting. Apparently there are companies who're interested in a 'fully programmable GSM phone'.

On a side-note, even Bruce Perens has now bought an A780 since he thinks it's "fun to hack". David Miller is pondering to buy one after his holidays in Korea... Let's only hope that they will actually find some time to get work on the EZX phone done. It's vital to have some basic running code ASAP in order to get more people to hack on stuff like the user interface.

After two days of full-time EZX kernel hacking, I now have a compiling 2.6.14-rc4 based kernel that has already half of the EZX-specific drivers merged.

I didn't really test to flash that kernel to a phone yet, mostly because I currently don't have an original E680 firmware that I could flash into the device if anything goes wrong. Also, before trying ti flash the kernel, I'd preferably like to have JTAG running. I'll publish my kernel tree as soon as I have confirmed it actually boots on the device.

Unfortunately I also have real work to do, and today is a full-time gpl-violations.org day, the weekend will probably be spent with some more librfid hacking. Stay tuned for some more OpenEZX news next week.

Since I'm getting that much coverage, I want to redirect some of that in the direction of the already-existing (and way more advanced, as of now) Linux phone projects.

There are multiple mobile phone projects at handhelds.org, esp. for the iPAQ H6315 and the HTC BlueAngel.

I didn't know about any of these projects so far, but I'll certainly look at their codebase and see whether any of the high-level (user interface) code could be re-used. But let me finish the low-level driver/operating system part first :)

Since a number of issues were already lost on the legal@lists.gpl-violations.org list, and there's now actually more people getting involved in the project (mainly Armijn), I've installed Request Tracker for the project.

Anyone who has new gpl violations to report, please contact license-violation@gpl-violations.org instead of the new mailing list.

Please do not report any old cases (that have been posted to the list) to the request tracker, I've already added all those old cases as tickets to the new system.

Since (as opposed to MiFARE Classic) the Philips proprietary MiFARE Ultralight RFID Transponder is actually documented quite well, I've added support for it to librfid. In theory it should work (I've implemented it just like the data sheet says), but unfortunately the transponder doesn't reply to READ/WRITE commands yet :(

The reason for implementing MiFARE ultralight is mainly to have a closer look at the Champions League Tickets from last year, since they are the "beta test" for the Soccer World Championship here in Germany next year.

Today I've started a small preliminary homepage about my A780/E680 hacking efforts at openezx.org. This also means that the old a780-hackers@lists.gnumonks.org list was renamed to openezx-devel@lists.gnumonks.org.

Expect no big news for some time, since I'm mostly working on porting/merging all EZX specific stuff into a 2.6.14-rc4 kernel.. a quite big job that will certainly take some time.

Stay tuned.

Some years ago, the netfilter project only had the kernel side netfilter/iptables code, and the userspace iptables program. Then we added patch-o-matic(-ng), and more recently there were a number of more sub-projects growing, like ipset, all the nfnetlink-related code, ctnetlink, etc.

Unfortunately the homepage design didn't really cope with the fact that there is now a more hierarchical structure with many sub-projects.

It was always my hope that some "new webmaster" would take care of it. Unfortunately we still don't have a webmaster, so I spent some time on it today. You can see the results at www.netfilter.org.

I've managed to obtain a 2nd hand E680 phone, which is based on the same Motorola EZX platform as the A780. The E680 are only sold in Asia, so the device I now have is actually a Chinese model.

Next on the plan for A780/E680 hacking is playing with the JTAG port, and trying to flash a non-OEM non-branded non-chinese firmware into the E680.

Once JTAG is running, I will be trying to port the drivers to a 2.6.14-ish kernel and compile and install that more recent kernel.

0sec 1.0 (the first incarnation of a security conference / hacker meet-up in Berne, Switzerland) has concluded today. Despite spending an enormous amount of time writing new netfilter and librfid code, I've had some interesting discussions and met a number of interesting people.

What I found especially interesting is all the work on syscall proxying that Uberwall are doing. I need to look into that stuff in more detail.

I'm unable to recharge any of my two A780 batteries, at least not via USB. Since I'm travelling, I cannot try with the real power-supply charger. Let's hope I can somehow resolve this, and it isn't really some damage to the phone's built-in charging controller :(

On the A780 hacking front, I've now successfully confirmed that there are indeed JTAG pads on the PCB, both for the PXA270 and for the ARM7TDMI, which is great news.

I also think there is still hope that the USB device port could actually be used as a host port. At least the PXA270 supports various options for OTG. Now the big question is only whether this is compatible with Motorola's overloading of the USB (called Enhanced Mini USB).

Since DaveM is on holidays, Acme is now in charge of running the net-2.6.15 tree. I've already submitted nf_conntrack, the ip_conntrack hash table resizing code from Rusty, as well as "revisions" support for {arp,ip6}_tables.

I'm also basically finished with x_tables now. Everything has been merged with a post-nf_conntrack tree, and all the conntrack related matches/targets have been ported to x_tables.

Now I need to do some serious testing (including nfsim), before it can be submitted, too.

After my delayed trip back from Seville, I'm now in Hamburg for Linux Kongress. This turns out to be an extremely busy event, I have two 'regular' presentations, one full-day tutorial, and also have to host a number of sessions as "session chair" on behalf of the organization committee.

This means that there is practically no progress in either the usbdevio fix nor in the current x_tables work. However, I found some time to fix a couple of 14443B related problems in librfid.

Somehow I have the feeling that Linux Kongress has lost some of it's spirit over the last couple of years, which is sad. Especially sad, since the first Linux Kongress 12 years ago was the first time that Linux Kernel hackers have ever met.

Tomorrow I'll be leaving for 0sec in Bern/Switzerland, which I'm looking forward to.

Iberia decided to reschedule my flight without informing me, even though that change was executed more than one month ago. They claim to have informed my travel agent. Not surprisingly, my travel agent claims never to have received such information.

This means that I'm stuck for one more day in Seville, since the next flight is only leaving at 7am tomorrow morning. Since Iberia claims it was not their fault, they're also not willing to cover any accommodation expenses.

Pablo Neira was friendly enough to invite me to stay at his place for the extra night, which means I don't have to fight with Iberia and the travel agent for any expenses.

Unfortunately I was scheduled to travel to Hamburg tomorrow, so I have to alter my train reservation and somehow make sure I'll still be in Hamburg at Linux Kongress for my tutorial.

I'm starting to get sick of those travel irregularities. This means I'm again back to my (old) plan of cutting down the number of conferences next year.

After having terminated the traditional workshop part, we've today had day 1 of the workshop.netfilter.org hacking sessions.

Despite the different topic, I spent the better part of the day with Michael Bellion and Henrik Nordstrom working out the details of nf-hipac / nfnetlink integration.

Apart from that, there's now a nf_conntrack header cleanup in my git tree, I've ported ebt_[u]log to nf[netlink]_log, fixed some minor Kconfig issues, merged some patches from Yasuyuki and Pablo, and pushed forward a round of fixes and updates to DaveM.

If I would start to write about everything that we discussed or only about the results from the discussions and presentations, I would probably need all night to write this blog entry.

It's been a very productive two days, and I'm looking forward to the hacking session that will happen on the next two days. Some of the TODO items for the hacking session will be:

• nfnetlink-enabling nf-hipac
• resolving some header file issues for 2.6.14 / nfnetlink
• using Gandalf's hashtrie as conntrack hash
• nfnetlink-enabling ipset
• using string search api for pattern matching in conntrack helpers
• completing userspace conntrack helpers using nfnetlink_{queue,conntrack}

Ok, have to stop for now, too much exciting stuff keeping me busy here :(

I've managed to bring ulogd2 to a state where it finally does something. The dynamic key resolval/linking of plugin stacks is working, and some basic plugins (NFLOG input, IPV4 packet interpreter (BASE), LOGEMU output) are working, too.

So the remaining work will mostly be in the plugin area. We're currently missing

• ctnetlink input
• packet->flow aggregation (basically 'nacctd')
• IPFIX input and output
• convert the old mysql/pgsql/sqlite output plugins

If you're interested, patches are always welcome. The code can be downloaded via svn from http://svn.gnumonks.org/branches/ulog/ulogd2/.

Tomorrow morning at 8am, I'll be leaving for workshop.netfilter.org, the annual netfilter developer workshop.

For the first year, we actually have presentations that are intended for sysadmins (aka 'users'). I'm missing the first day of this user event, but am obviously present for the two day workshop/discussions and the two days of hacking following up the official workshop.

I want to publicly thank Pablo Neira for organizing this years event. We've now had workshops every year since 2002. They've been very low-profile and small so far. But look at this year's event. It actually has a homepage that's worth mentioning, and the sponsors seem to be literally lining up..

Looking forward to meet lots of fellow hackers, especially those whom I haven't met since last years workshop.

Yet another of my projects that never received the amount of attention that was required is ulogd2. If you already know the ulogd-1.x series, then you know it as an efficient packet filter policy violation logging daemon, with backends for files, syslog and various SQL databases.

ulogd2 is much more than that. It's more abstract, and more universal. It's no longer limited to receiving packets from the ULOG target, but is fully modularized, with modules for ULOG, NFLOG (see linux-2.6.14), IPFIX, ctnetlink, ... Now you might wonder why there is something like IPFIX and ctnetlink? That's because ulogd2 can also process (aggregate, export) per-flow information.

The most difficult part of the implementation is the dynamic creation of "plugin stacks", but I think I wrote about this earlier in my blog.

The good news is, that just before I went to bed, ulogd2 compiled for the first time ;) This means I've waded through the tons of errors and warnings created by all the changes introduced since it forked off ulogd-1.x about a year ago.

Now there are some bits of missing functionality here and there, and certainly a large bunch of bugs. But if you are a software developer, you know it's much easier (and rewarding) once the beast actually runs :)

Today was a very exciting day of more A780 hacking. You know, from time to time it's quite good to do something else than stupid netfilter development or the like ;)

So what I've been able to do? Well, I analyzed most of the device drivers from userspace side. I now know the key-codes of every keypad or other button/wheel/dial on the device, I know the touch screen and framebuffer. I can control the three different backlights.

Then I've learned a bit more about the architecture of the phone. The Xscale processor (PXA270 Bulverde) actually uses USB to talk to the Neptune chip. Neptune is a DSP with a synthesized ARM7TDMI on-chip. The PXA270 runs in host mode, the Neptune in device mode.

Interestingly, the Motorola developers have debugging callbacks in the stock kernel. So by registering a simple kernel module with the USB rx/tx functions, I now have hexdumps of the USB traffic between those two chips (also called AP and BP).

Then I called the a780, and I immediately received some nice hexdumps in the kernel ring buffer. The first thing I could spot was "IP: "+4930xxxxxxxx",1\r\n". There it was, the incoming phone number :)

Some other nice guy at motorolafans.com has managed to replace the proprietary userspace Bluetooth code with the stock Linux BlueZ codebase. He's working on Bluetooth keyboard support... that would really be nice. Using a Bluetooth keyboard with the Qonsole terminal emulator (or even a framebuffer console) of your phone :)

I'm really confident that the AP<->BP protocol can be worked out fairly quickly. Once this is done, we can start developing our own "phone" programs, and get rid of all the bloated embeddedQT and Java crap that is running on the phone. It has 48MB of physical ram, and the database daemon has a resident size of 2.7MB, the address book 4.5MB, the "phone" program has 6.6MB. This is really ridiculous...

At the end of the road, I'm dreaming of something small and efficient, running uClibc, busybox, DirectFB, ...

The USB device port of the device is called "Extended Mini USB (EMU)", because it apparently can be switched in more than half a dozen of different modes (by assigning various pull-up/pull-down resistors). Apart from a USB device, it can for example run a UART on that port. However, since the USB host port is already used for Bulverde<->Neptune communication, I don't think it is possible to run the phone in USB host mode. This basically rules out attaching a stock 802.11 wifi USB adapter, which is very sad.

Yes, you're reading this right. I've managed to build iptables.o, ipt_*.o, iptable_filter.o, iptable_nat.o, ip_conntrack.o and the like for my Motorola A780 cellphone.

As of now, there's not really all that much need for it... but when I start running dozens of applications on the device, I better make sure to have a decent packet filter to the GPRS/HSCSD world.

But even then, in theory it should now be possible to NAT between the GPRS device one one side, and the usb-lan on the other side. Maybe I should try to bring my whole home network online via the A780 :)

OTOTH this doesn't fix the various security issues on the horizon. The A780 apparently ships zlib-1.1.3. I don't even know how many security vulnerabilities were fixed since then...

ftp.gpl-devices.org has been up and running for a number of months now. As usual, I never really had the time to take care of it (i.e. feed it with all the vendor-released and 3rd party source code for embedded devices running GPL licensed software).

Luckily, Imre Kaloz was interested in helping me out. He's now in charge of at least putting all the TI AR7 related source tar-balls on the ftp site.

I've already dedicated a 300GB hard disk for the source code, which should be fairly sufficient for some time. At this point, I have no more than 40GB of vendor-supplied source code images at home.. ftp.gpl-devices.org has only some 3GB as of now.

Thanks go to noris.net, the innternet provider where like for almost all of my projects, the server ftp.gpl-devices.org is colocated.

I've now successfully built a compatible toolchain for the Motorola A780, thanks to this good site with instructions.

Obviously, one of the first things to do was to build busybox with a config that enables all the missing tools. For some strange reason, the A780 does not ship with the usual uClibc/busybox combination, but with the straight GNU tools (glibc, fileutils, ...). Unfortunately important bits such as less, top, strace, etc. were missing.

I've also managed to build matching ext2,jbd,ext3,sunrpc,nfsd and af_packet kernel modules. The VFAT partition on the TransFlash card was shrunk, and an ext3 partition added. Some hooks into the startup scripts, and now the ext3 is mounted when the phone is switched on. Some PATH and LD_LIBRARY_PATH mangling in .profile, and I have a very workable environment on the phone.

Obviously the most important goal would be to port the EZX arm architecture support into a recent 2.6.x kernel, and then run a full-fledged 2.6.x kernel on the device. With embedded IPsec, packet filtering, etc. That goal is very far, due to stupid proprietary device drivers.

So for now, I'll be looking into the kernel/userspace API's and the userspace/userspace API's in order to develop native userspace applications that can actually use the phone (i.e. make voice/data calls, use the headset/speaker/microphone, ...

Following-up the recent site-wide installation of blosxom on people.netfilter.org, I've now also created our own planet.netfilter.org. At the moment, only three netfilter related blogs/journals/diaries are aggregated there, but with some luck (and your help, since you will have to tell me what other netfilter related weblogs) it will grow :)

Due to the importance of the subject, we will do the second Chaosradio show this year dedicated to electronic passports and biometric identification.

Germany will issue them starting with November this year... so now is about the last possible time to apply for a brand new, shiny, glossy, cheap "old-style" passport that doesn't contain any biometric information.

I first wrote about this in early 2005: Having developer blogs on people.netfilter.org. Unfortunately I never finished that project so far. I'm not really a web guy at all, so doing stuff related to (X)HTML and CSS always gives me the creeps. Why can't we just have a technically skilled web master volunteer for netfilter.org? *sigh*

For those who're curious, you check out a mirror of this blog, or the early beginning of Gandalf's blog.

Every netfilter developer with an account on people.netfilter.org can easily set up a blog, just by putting blog articles into ~/weblog/.

The organizers of FOSS.in have put together a planet site at planet.foss.in, featuring the weblogs of all speakers. Incidentally that includes this blog ;)

If you have trouble resolving the foss.in domain, that's probably due to broken nameserver responses from their current domain hosting provider. At least my bind9 cannot parse their responses... I've now set up a set of 'real' name servers, and Atul is trying to get the whois data updated... sorry for any inconvenience.

I've continued work on ulogd2, the next generation netfilter userspace logging daemon. In addition to packet-based logging, it supports flow-based logging.

It turns out my overly-flexible concept of plugin stacks ends up with quite some implementation complexity. The problem can be viewed similar to a linker problem (linking symbols of multiple objects), but in addition resolving dynamically changing dependencies, with some 'symbols' being optional, and with objects that you can ask "if I give you input symbol X, which output symbols can you give me" ?

I really need to do resolve some tax issues before the netfilter workshop, so I'm not sure whether I can finish it before.. especially since I've also started to merge years-old pkttables code into a recent kernel.

This triple-release is in anticipation of a 2.6.14 kernel release. The two libs as well as the conntrack program are userspace counterparts to the "next generation" subsystems inside the kernel netfilter part.

The release involved lots of painful learning-by-doing of autoconf/automake. I'm not a fan of them at all, but I sill think it's less burden than trying to invent everything on your own (like we did with the iptables package) and thus forcing more burden onto the package maintainers of the distributions.

I'll probably release libnfnetlink_log and libnfnetlink_queue tomorrow... but I really don't have any time to work on netfilter at the moment, despite this TODO list :(.

This morning I wanted to do something relaxing, so I looked at the ath-driver source code that I'm no hosting for Mateusz at ath-driver.org.

After some hours of digging (and trying to implement channel switching support), I decided that the whole approach of yet-another-driver seems deemed.

If I find some time for Atheros driver hacking, I'll build a Linux driver around the ar5k OpenBSD driver (yes, it will be dual BS/gpl licensed). It's just not worth the pain of re-implementing the HAL functionality for 5210, 5211 and 5212 from scratch...

... as usual in the last minute. I've now finally finished my two papers for Linux Kongress 2005 next month.

The DocBook source to those papers should however be a good starting point for reference documentation to {nf_,nfnetlink_,libnfnetlink_}{log,queue}.

Also, in the good spirit of recycling papers, I'll make a Datenschleuder article on RFID and biometric Passports from my librfid/libmrtd paper.

Let's hope I can get some real work done tomorrow.

One year after Germany decided not to have a national law on data retention, the European Union moves towards data retention legislation.

Apparently now the European Commission and the European Council are both competing with proposals for a directive on mandatory data retention of all telecommunication meta-data for up to three years. Meta-data includes MAC addresses, IP addresses, Email addresses, phone numbers, IMEI numbers, location of the base station from which a mobile system initiated the call, and many more (it's a two page listing!).

If you are a EU citizen and think that data retention is invasive, disproportionate and violates the European Constitution on Human Rights, please sign this petition at dataretentionisnosolution.com.

Since when has a trade secret (if there is any involved, I doubt it) become more important than the citizens' right to a transparent election process?

After a quick read through the respective laws such as the Election Verification Act (Wahlprüfungsgesetz) and the Federal Election Act (Bundeswahlordnung), there is not a single mention of any kind of electronic voting machines. To the opposite, they go into every tiny detail of how the ballots have to be formatted, what color of paper they are printed on, etc.

Apparently there is already at least one person who wants to challenge the election results in those counties where electronic voting machines are used. I'm more than motivated to join such action and/or start an initiative for transparency of electronic voting. Stay tuned.

The frequent reader of this blog will have noticed that I love Indian Bollywood cinema (and of course the corresponding music).

Unfortunately there are very little Bollywood movies in the cinemas in Germany, and other Bollywood events are almost as rare. However, Club Deewane now organizes more or less frequent parties in Berlin.

Due to my frequent travel, yesterday was the first time I was around when the event took place. It was quite an experience... I wouldn't have imagined that such an event could actually draw some 200+ people. I'd say no more than 20% of the guests did were of Indian origin/decent, the rest was the usual multicultural "Berlin mixture".

Anyway, I had a great time, and was surprised how much of the music I actually recognized ;)

It's quite amazing what kind of bogus ideas government agencies and operators of nuclear power plants have. According to this article, the German federal environmental agency has negotiated with the operators of not airplane crash safe nuclear power plants to install GPS jammers.

The idea is to make it harder to automatically guide a passenger airplane into such a power plant (as part of a terrorist attack). It follows the same awkward logic as the already-proposed "artificial disguise in fog".

It's incredible to see what to what extent they're willing to compromise the security. Either you think an attack to such plants is a danger that needs to be avoided, then you have to shut down those (three, I think) plants. Or you think all that terrorist panicking isn't worth such a measure.

But I don't think that anyone honestly believes that a bit of fog and some GPS jamming will prevent any such attack. At aircraft speeds, it doesn't really matter whether you have GPS 1 or 2 kilometers in front of the power plant. And in a country with a population density like Germany you cannot jam the signal for 100 or even 50km - especially since the highway toll system for tracks operates on the basis of GPS ;)

Apart from that, according to the Bundesnetzagentur (formerly RegTP, similar to the FCC), it is at this point not legal to operate any such jamming devices.

Ever since my first contact with the internet in 1994, my personal homepage and later (since 2000) the gnumonks.org project have been connected to the Intenet via KNF, a volunteer-based non-for-profit in southern Germany.

Initially I had a 33.6kbps leased line, in 1999 or 2000 that 33.6 line to my home was replaced with a 2MBit SDSL line to my (then new) office.

Meanwhile, I had moved to Brasil in 2001, came back to southern Germany 2002 and moved to Berlin in 2003. I sold all equipment in that office to a friend of mine, under the provision that the leased line and my systems may remain there indefinitely.

Sine recently 2MBit has become a not particularly high bandwith, I've always hosted larger projects such as netfilter.org at a hosting centre.

During the last week I migrated many of the services to either my Berlin office or that hosting centre. The services include important bits such as DNS primaries, so if you have any trouble contacting {gnumonks,gpl-violations,gpl-devices,librfid,openmrtd,dunkelromantk}.org, please let me know.

As of now, only this blog, ftp.gnumonks.org and two mailinglists are still behind that SDSL line. I intend to move those services during the next couple of days. At the end of November, I'm planning to pick up the by then totally yunused equipment.

Big thanks to KNF and TowerSoft for providing connectivity and housing for many of my machines over the last decade. It's time to say goodbye.

Following-up some serious testing today, I've finally submitted the latest version of the PPTP helper from the netfilter-2.6.14#pptp tree to the mainline kernel.

With some luck, it will be included before 2.6.14 gets final. It should go in, since it doesn't modify existing code but is merely an addition.

Also, please note that the "ip_conntrack_proto_gre.ko" and "ip_nat_proto_gre.ko" modules are gone with that 3.x version of the PPTP helper. The respective code has been integrated into ip_{conntrack,nat}_pptp.ko. My initial dream of doing some generic (non-PPTP) GRE connection tracking has evaporated, and thus the PPTP helper now really only handles the special case of pptp-GRE.

Today is one of those days where you want to get something "simple" done (like testing some new pptp conntrack helper code), and where everything goes wrong.

My test boxes are small embedded network booting devices. For some strange reason, they failed to obtain DHCP leases from the DHCP server.

Since I couldn't spot anything wrong while looking at the packets in ethereal, I added lots and lots of debug statements to the etherboot DHCP client code.

And there it was: etherboot refuses to accept a DHCPOFFER that doesn't have the "siaddr" field set in the DHCP/BOOTP header. According to the DHCP specifications (rfc1335, rfc2131), this indicates the address for the "next server in bootup process", i.e. tftp and alike.

A browse through the isc DHCP changelog indicated that version starting from 3.0.2 default this field to "0.0.0.0" unless "next-server" is explicitly set in dhcpd.conf.

Unfortunately the man-page states the exact opposite: That it defaults to the DHCPD's IP address.

After some more issues with some strange interaction between my USB2.0 hub, the ehci-hcd host and two different smartcard readers, I can probably finally start to do some real work..

I can proudly claim to never have done any windows development, despite using and program PC compatible systems for some 15 years.

Now I've started reading a book on MS(TM) Windows(TM) Device Drivers. No, I do not intend to write any such drivers. However, there are numerous cases where some i386 windows driver is all the "documentation" that a hardware vendor provides. So in order to more efficiently understand the disassembly of windows drivers, I'm now reading my first book on the evil empire.

I've recently acquired a Motorola A780 quad-band GSM cellphone. It's basically an Intel PXA270 based system with 48MB flash, a 256MB TransFlash reader, Bluetooth, a GPS receiver and MotaVista CEE Linux 3.0 (2.4.20 based).

As usual, the vendor tries to "lock down" the OS from the user. Luckily, some nice people of motorolafans.com have already found their way into the phone. Using their "linloader", you can put shell scripts on the TransFlash card and execute them by clicking on them in the explorer. Using that you can put the phone into a mode where it runs as usbnet 'device' with telnetd and samba.

By now I've already learned quite a bit about the phone. Interestingly, they are running glibc (not uClibc). The same goes for the rest of the device. No busybox, but rather the standard gnu programs. So it's much less of the typical embedded Linux environment, and more like a "regular" GNU/Linux system.

glibc-2.3.2, embedded QT, and some "ezx" class library on top. Add some J2ME runtime environment, a handful of different filesystems (vfat, cramfs, romfs, TrueFFS, mfs), a SD/MMC reader driver, a GPRS module, some strange "USB Logger" (looks like syslog-over-usb) and a number of userspace programs and there you go.

Oh, and yes, obviously the phone was delivered with no GPL license text, no source code and no written offer thereof. But that's a different chapter.

The OpenCT project has merged all my CardMan 4000 / 4040 code and thus the upcoming OpenCT-0.6.6 release will include support for those readers.

On the kernel front, I'm having a bit difficulties accommodating all the cosmetic changes that are requested by various people. Jeez, I always though the netfilter project had a quite strict policy on CodingStyle... I've proven to be wrong.

I'm still hoping to get the drivers into 2.6.14, though.

I've been doing quite some work on the kernel-side drivers for Omnikey CardMan 4000 and 4040 PCMCIA smartcard readers. Apart from a general overhaul (kernel coding style, get rid of 2.4.x cruft, ...) I also added support for the new 2.6.13 hotplug-style PCMCIA subsystem. I'm extremely happy that PCMCIA driver binding can now happen without some userspace daemon running...

On the userspace side, I'm tearing apart all the changes that I did to my local openct-0.6.2 fork. Now the per-feature patches are merged with current openct SVN, which means that I can submit them to the OpenCT project after some testing tomorrow.

Sometimes as part of my GPL enforcement work, vendors will make donations in order to settle things like a grace period, i.e. a time where they can still sell their stock of already-produced gpl incompliant devices.

Recently, as part of such a settlement, I was able to get EUR7000 which have been donated to FoeBud e.V., a registered German charity fighting against privacy-invading technology use such as RFID, and video surveillance. They hold the annual "Big Brother Awards" which give a "prize" to those individuals and organizations that hurt privacy and data protection most in that year.

This month's Chaosradio show (held today) will be looking into the plethora of embedded devices that are present in todays world.

CCC "residents" will be Tim Pritlove and myself.

The main focus will be on consumer embedded systems, especially those running free operating systems and those with good "hack value".

Some time ago, Jeremy Kerr wrote the patchwork program as a means to track patches sent to mailing-lists (specifically netfilter-devel in our case).

I'm now using it more-or-less frequently and it has already uncovered a number of patches that got lost otherwise. Therefore I consider it a very helpful tool. Hopefully reports of netfilter-devel being "a write-only mailing-list" will cease now..

Apparently we now have at least one corporate user of the ipt_CLUSTERIP target (allowing load balancing without a load balancer). Krisztian Kovacs has re-worked some of it's weak parts (like refcounting and procfs). I'll review the patches soon.

This means that all the code from my netfilter-2.6.14 tree (master branch) are now in the mainline kernel. The code in question mainly includes

• conntrack event notifiers
• nfnetlink layer
• ctnetlink interface
• nf_log API extension
• nf_queue and nf_log /proc files
• nfnetlink_log as successor of ipt_ULOG and ebt_ulog
• nfnetlink_queue as successor of ip_queue and ip6_queue

We'll see whether nf_conntrack will also go into 2.6.14, at the moment I have my doubts...

So I'm back from holidays and are half way through reading the incredible backlog of emails.

It seems like netdev has been a bit more quiet than it was before, and surprisingly there were no more bug reports on the recently introduced netfilter code (nfnetlink, nfnetlink_log, nfnetlink_queue, nf_log, ...). So things seem to have settled down a bit.

Organization of the netfilter developer workshop seems to proceed quite fine, too. Travel sponsorships are taken care of, however we're still lacking some EUR 1600 for the cost of accommodation. If anyone (any company/organization) is interested in contributing to the netfilter project by funding accommodation for the workshop, please let me know.

Most of the 'interesting' new email seems to come in on the GPL violations front. I haven't yet analyzed any of the new alleged violations, but there seems to be plenty. It's a pity since it will again keep me from interesting real work. Also, there's still some minor cleanup to do in order to fully close the last 11 cases that I've dealt with...

I've always intended to write a 100% free software driver for Atheros cards, based on the new IEEE80211 subsystem in the mainline kernel. I've even stated at OLS earlier this year that I'd start one. As with many of my projects, there was a significant lack of time.

Meanwhile, Mateusz Berezecki has written a beta-state driver for the ar5212 chipset based wireless cards. He has contacted me for hosting the driver on gnumonks.org. So this way I'll at least be able to provide some help with the driver this way ;).

I still intend to contribute to the driver (as time permits), as well as the core IEEE80211 stack in the Linux kernel. One of my must-have features is virtual access points, i.e. running as AP of multiple ESSID's with one card on one channel.

I'm off for holidays in Scotland, so please don't expect any email to be answered before Aug 25.

Don't send any important netfilter issues to me personally, but rather to the core-team or the respective lists.

Some time ago, I ran into GPL issues with the iRiver PMP-1xx series. For some reason, the Korean company chose to cease distributing their products in Germany, rather than making them GPL compliant.

Despite that, they've now sent me a CD-R with the source code. I've made it available to interested parties at ftp.gpl-devices.org. I did not yet have the time to do a full-scale analysis whether it is complete (as per gpl definition of "complete corresponding source code"). However, at least from a first quick look it seems fine (and even documented!).

Today I really felt like a systems administrator (which I've never been, at least never as daytime job).

On the software side, there were still a cuple of woody -> sarge upgrades to be made. Also, I finally have a running sparc64 setup at home again (all my other sparc's are hosted, and I recently crashed one during development).

On the hardware side, various pending repairs (broken fan's, bad memory, hard disk replacement0) lead to some shuffling of hardware pieces between my various machines.

As a result, I now have more storage capacity on my main NFS server, as well as on the main backup server. While planning the new backup strategy, I found out that all in all I own more than 4.6TB of hard disks. Sounds an awful lot, but most of it is lost due to various raid levels, and some 1.6TB of drives are only used for backups.

I wish tape drives with decent capacities were not all that expensive...

Tomorrow will be one day of accounting and taxes. So don't expect any further new netfilter stuff before I'm leaving for holidays in Scotland next week.

The next episode in my Gentoo rant.

Every time I do an "emerge -b -n world" to get the latest security fixes, I have several hours, if not days of cleanup.

A number of times glibc was somehow fucked up, so all dynamically linked applications would refuse to work.

This time, let me only pick the interesting examples:

• I don't have a "vi" anymore. It tells me "unresolved symbol: pthread_create".
• Proftpd doesn't start anymore ("unresolved symbol: setproctitle").
• spamd starts, but fails to do DNS lookups (missing dependency to Net::DNS)
• clamav regularly crashes (reason unknown)
• The linker/gcc (3.4.4) fails to detect unresolved symbols at runtime. This leads to the vi and proftpd issues described above

This is a _production server_. *sigh*.

I sincerely consider switching Debian-ppc (in 32bit mode) on that Dual G5 XServe now. If that wasn't such a terrible amount of work...

It's amazing! A person who claimed to be the Chief Designer of Vodafone's Global WLAN services has read my blog and stumbled accross my previous blog entry about the network problems at Linuxtag and sent a quite thorough email in response. And no, this was not in response to my proclaimed cancellation of credit card charge (which I obviously forgot, so it never happened).

Anyway, I'm amazed.

Pablo is working on workshop.netfilter.org. But at least the dates are fixed now:

• Oct 4th: some unofficial user-related event with the local lug
• Oct 5th-6th: The workshop itself. discussions, presentations.
• Oct 7th-9th: Hacking on code.

Expect more news soon...

Well, according to the organizers it's just a formality, but "just for the record", I've now officially been invited to the-conference-formerly-known-as-Linux-Bangalore. It will happen Nov 29 to Dec 02, but due to timing overlap, I'll probably only be there from the 30th onwards.

I've already tried to raise awareness for this fabulous event with almost everybody I met during my vivid conference travel. Let's hope I have managed to convince a number of high-quality Linux hackers to consider submitting a paper (and let's hope the CfP will be published really soon now).

Ok, we've seen a terrible amount of bug-fixes going into the net-2.6.14 tree after my new nfnetlink/nfnetlink_log/nfnetlink_queue/... stuff was merged. It is my belief that we've now covered most of it.

As of now, I'm not planning to make any other big netfilter-related patch submissions. So nf_conntrack will probably have to wait for 2.6.15, especially since there are still a number of ip_conntrack/nf_conntrack compatibility issues to be resolved.

Lately I've been working on the userspace side. At least libnfnetlink_log and the libipulog compat API are finished now. libnfnetlink_queue is getting there, and the 'big' missing part is the libipq compat API.

So now I'm heading for some work on ulogd2, libnfnetlink_conntrack and the virtual Ethernet device (vdev) code. And if I still have some time left, there's exciting non-netfilter stuff like my RFID stack.

Almost as expected, as soon as that code hits a somewhat more used tree (such as Dave m's net-2.6.14 and the -mm tree), there are numerous bug-fixes piling up.

That's a bit embarrassing, though I'd rather fix it now than later when it is already in the mainline tree :)

I've committed the last version of nf_conntrack, the layer-3-independent connection tracking code to my netfilter-2.6.14.git tree. It's a local branch called "nf_conntrack".

Yasuyuki and me have been working to port the latest mainline ip_conntrack changes to nf_conntrack. Now the tree should now be fully in sync with ip_conntrack of the same net-2.6.14 tree (this means that it supports CONNTRACK_ACCT and has it's own conntrack-event-api).

Major pieces that are missing from nf_conntrack are:

• IPv4 NAT for nf_conntrack
• nf_conntrack_netlink (aka ctnetlink for nf_conntrack)
• support for ip(6)tables 'state', 'conntrack' and other matches
• Finally, ct_sync

This week I'll be visiting parents and friends in Nuernberg. I'm telling you that because this implicitly means that I'll most likely not be able to continue the pace of netfilter development like in the last couple of weeks.

It also means that I'll probably be doing some scheduled maintenance of the netfilter.org boxes (which are located in Nuernberg, too). So don't be surprised by some shortly-announced downtime. If you're curious what I'm planning: ganesha needs a RAM upgrade (512MB->1GB), and lakshmi needs an upgrade to Debian sarge. Maybe I'll also have time to work on the fail over solution, too.

I expect to read my mails daily, so there shouldn't be any delay in that.

After having finished my work on the nfnetlink based subsystems, I've progressed to making the PPTP helper fit for mainline inclusion in 2.6.14.

First, it needed an update towards the 2.6.13 conntrack helper API changes (now that expect's have refcounts). Second, we don't have lockhelp.h anymore, and third I want to fall-back to ip_conntrack_proto_generic in case GRE version1 (RCF1701) packets are seen. Stay tuned.

I've submitted my nfnetlink_log patches to DaveM earlier today. So what is this about? It's a replacement for ipt_LOG, ip6t_LOG, ebt_ulog, ipt_ULOG. It introduces a layer-3 (AF_xxx) independent way of logging packets via a userspace logging process.

Again, one step towards code unification. One new piece of code that replaces four existing ones (of similar size), and obsoletes the need for any other such mechanisms that might have appeared for other protocols later on.

If you want to see how to use it from your favourite userspace app, please refer to libnfnetlink_log.

I've made public my netfilter-2.6.14 tree (based on DaveM's net-2.6.14 tree) at http://people.netfilter.org/laforge/scm/netfilter-2.6.14.git, also available via rsync://people.netfilter.org/users/laforge/scm/netfilter-2.6.14.git

Since this is the first time I'm making a public git tree available, please contact me in case you have any problems accessing it.

I still need to find out how to produce incremental git trees like the ipw2200 project does - this way I would not have to provide a full kernel tree, but only those changes that I do in the netfilter part of it.

Today I've released iptables-1.3.3. Among some minor fixes (such as for the extremely important feature to SNAT and DNAT to/from ICMP ID _ranges_), it contains one major fix for an embarrassing use-after-free problem that was only introduced with 1.3.2. What do we learn from this? I need to review patches more carefully.

It also includes the NFQUEUE target, which is basically an extension to QUEUE. QUEUE only supports one queue number (0), so there can only be one userspace process be attached to it. This lead to the ugly hack of ipqmpd, the IP QUEUE multiplex daemon. Combining NFQUEUE with nfnetlink_queue (which is already in DaveM's net-2.6.14 tree), you can now have 65535 different queues, each heading to a separate userspace process. This is again one step ahead towards supporting "100% userspace conntrack helpers" which are sort of a strange hybrid variant of transparent proxies.

EDRi and XS4ALL have started an online petition against the recent European Commission proposal on mandatory 12 month data retention of all telecommunications meta-data.

Much like the software patent issue, we again have a situation where the European Parliament (those who are directly elected by the public) is against the proposal, while the commission and some national governments are pushing it.

With your support (and at least your signature), there are chances that this data retention directive - like the proposed software patent directive - can be turned down. Please take your time and sign, thanks.

Please also consider supporting the EDRi. They recently announced that they're short of funding.

After one day for travel and sleeping-over-the-jetlag, I'm finally back on track at my home in Berlin.

I just decided to skip WTH, since it would require me to leave again in only two days (and I have another travel coming up on 1st August. So I'd rather spend the time to continue my current netfilter projects, taking care of accounting and tax declaration, etc.

Unfortunately I'm bound to using slower/older machines and my notebook, since the warranty replacement for my workstations' liquid cooling system has not yet arrived :(

Today I'll be moderating this months' episode of Chaosradio on the upcoming German Gesundheitskarte (Electronic Health Card, EHC).

This is the latest incarnation of the ever-increasing number of large-scale IT projects in public atministration. Following-up infamous examples such as TollCollect, the ALG2 software, INPOL-NEU, ELSTER, and last but not least the RFID enabled electronic Passport. And it will affect the data privacy and data protection of even more German citizens than any of the beforementioned systems!

I'm very pleased to announce Thomas Maus (ThoMaus), one (if not the) most prominent critical experts on the EHC as a live guest in the radio studio.

This subject is actually one that I think fits best into the idea of Chaosradio: Technical, but with vast implications on society. Even more than my last "favourite" data retention, but less than the upcoming Chaosradio show on "voting machines".

From my point of view there are too many issues currently at this border between technology, politics and society that need to be adressed. Too many to just talk about geeky technological stuff that is certainly also happening and woth covering it in Chaosradio.

Finally, within years, at least one hardware vendor does The Right Thing (TM): Intel releases hardware documentation about their Gigabit Ethernet Controller chips (known as 'e1000') in the Linux world. (For the curious ones: you can get it from the e1000 sourceforge page)

Even more surprising, they are doing it _despite_ providing a high-quality GPL licensed Linux driver. And by doing this, they show that they have understood that the many developers who are playing with their chip will in the end help them to perform even better, but only if they can actually read the hardware documentation.

There's a group of Linux networking developers who are constantly trying to optimize the driver and come up with new strategies on how to deal with high packet rates.. And at least until now, all the big current Gigabit Ethernet chips did not come with any kind of documentation.

Broadcom tg3 and Syskonnect/Marvell Yukon2 now have a severe competitive disadvantage. Let's see whether they get the clue, and release documentation, too.

I'm not a big fan of Intel, but what they're doing with regard to Linux and their e1000 and ipw2xxx chips is really good. Thanks, Intel!

In his blog, Richard Stallman writes that he had a very unpleasant experience visiting ASUS in Taiwan.

This is outrageous, considering they are using Linux and other free software programs in their products and making business from it.

Their WL500g routers are using Linux, and did not comply with the GPL. So in 2004, I used my copyright to enforce the license. I have obtained a declaration to cease and desist from ASUS Headquarters in Taiwan, and they modified their product promptly to bring it into GPL compliance. See this news item on the netfilter.org project homepage.

Even today, ASUS seems to be using Free Software in a number of their latest devices, as I indicated in this blog entry.

While writing on nfnetlink, ctnetlink, nfnetlink_queue and other bits of the 'new' netfilter infrastructure, I've run into a number of minor shortcomings in netlink that are surprisingly hard to overcome.

One of them is refcounting, i.e. making sure that the module implementing a particular functionality via netlink doesn't silently disappear by module unloading while sockets are still open from userspace.

I've now finished one implementation, but it might cause module refcount leaks if a kernel module implementing a netlink socket closes the socket in some other codepath but the module_exit() function.

The other problem (slightly harder) is module auto-loading. It's my position that the kernel should autoload the respective module once a userspace process opens a netlink socket. However, this can not be made obligatory, since multiple userspace processes might also just wish to communicate with themselves, with no listener/sender in the kernel at all.

James Ketrenos (the ipw2xxx maintainer) was running a BOF to get input on ideas for a new wireless kernel configuration API from the Linux community.

Due to excessive coding (see in some different entry of this journal), Patrick and me came in a bit late. We tried to convince the audience that netlink was the way to go, and that the current ioctl() interface could be served by some compatibility layer that converts the ioctl's to netlink messages.

Also, I raised the requirement for integrating this config interface with a unified userspace interface for association and authentication (i.e. management frames).

Unfortunately James had to leave quite early, so we couldn't finish the discussion in a more detailed way in a smaller group.

The IEEE is a standardization body. Being a Linux network developer, access to their 802.x standards is sometimes quite valuable. A couple of years ago they introduced the "Get 802" program, where they would make available the 802 standards family some time after publication. This is great.

However, I recently needed a copy of the current draft of the 802.11e standard. They charge USD60 for this, which is a reasonable fee that I was willing to pay.

However, they only seem to be offering in some proprietary DRM format. This is totally unacceptable, since it would requires installation of the purchase and installation a proprietary operating system.

Networks (and especially the Internet) are built upon open and publicly available standards. Free and Open Source projects can only implement industry standards if they can actually access those standards. The availability of such standards is therefore an important aspect of their fast implementation and adoption.

I very much understand the requirement of standards organizations to charge reasonable fees (such as USD60 for the 802.11E draft) for purchasing copies of it.

However, after obtaining such a copy, I would like to print it or pages of it, I would like to view it on all of my computers, and I wan to do so while staying offline without any authentication that (I suppose) your DRM system requires.

By putting such incredible obstacles between the developers and the standardization body, they will achieve nothing but frustration and hamper the adoption of the standards which they care about.

Patrick McHardy and me sat together for a number of nights, reading and discussing various current issues with the networking code. It's surprising how much fallout we get from these discussions.

Apart from tons of new code (nfnetlink, ctnetlink, nfnetlink_queue, ...) there are apparently still quite a number of interesting bugs in esp. the NAT code that have been there for 5+ years without anybody noticing them.

What comes immediately to my mind is Rusty's famous quote "When we do something wrong, the users just hit reload. Nobody will notice, you never get bug reports". Especially when the NAT or conntrack code are doing something wrong that doesn't disrupt the protocol, it's relatively difficult to find those bugs.

So what did we find? For example, that ICMP ID NAT [yes, we do support that] had a number of endianness bugs. So when you wanted it to NAT ICMP ID's to a particular range [instead of any free ID], it would use totally different numbers that the administrator or the helper plugin actually specified - but only on little endian machines.

Some other bug was more severe, since it can theoretically cause memory corruption [a stale pointer could have been used since it was accidentally added to a list of 'static' variable declaration].

Following-up meeting the other networking hackers at netconf, I got really extremely motivated and basically spent every single minute hacking code.

The projects include:

• skb shrinkage (already merged in DaveM's net-2.6.14 tree)
• nfnetlink (already merged in DaveM's net-2.6.14 tree)
• conntrack event notifiers (already merged in DaveM's net-2.6.14 tree)
• ctnetlink (reworked to use network byte order in all the payload)
• nfnetlink_queue (a nfnetlink-based queue implementation)
• vdev (a virtual device that allows you to use multiple mac addresses on one Ethernet device)
• mmio_test (include support for machine-parseable reporting)

I didn't actually visit any of the talks, but instead read some of the papers in the written proceedings, hacking lots of code and talking to various people.

I've also managed to convince GregKH that support for async URB submission from userspace needs CONFIG_BROKEN. libusb doesn't use it anyway, and the number of users of this interface is limited. Unfortunately one of my customers is one of the users, so I might be forced to implement a cleaner interface for the same purpose.

The first day of netconf went quite fine, but we basically lost quite some amount of time waiting. First waiting for free tables at breakfast, then waiting for the bloated enrollment procedures of the Security Guards at the Ericsson venue...

Added with technical issues with the 800x600-only projector and the amount of time spent travelling from the hotel to the venue, we lost a lot of time and therefore actually didn't have the time to fit all talks into their respective slot, but only 60%.

The most cool work I've seen at this first day is Thomas Graf's work on a unified Linux kernel networking configuration and statistics tool...

Later today I'll be heading off towards Montreal for netconf 2005. I'm really looking forward to that event and the interesting discussions with my fellow Linux networking developers.

I'm actually meeting Patrick McHardy in Paris, as we'll be on the same transatlantic flight. I hope we can get some of the pending netfilter/iptables issues discussion meanwhile ;)

After netconf, most of us are heading to Ottawa for Kernel Summit and OLS. I've turned down the invitation to the kernel summit, since usually there is nothing on the agenda that even remotely touches the packet filter or even the core network stack, so I'd rather make space for somebody else.

I'm supposed to have network connectivity almost all the time, so I don't expect big delays in email responses.

According to this German article (by Dr. Dirk Wetter), out of seven tested console servers (all Linux-based) of various vendors, only two even mentioned that GPL licensed software was used in the product. The majority of the devices did neither mention the GPL, nor make any source code offer.

The vendors have been contacted by the author of the article, and almost all promised to make their devices GPL compliant in the future. It has yet to be seen whether they actually fulfill that promise. I will ask each of them for a copy of the full corresponding source code, since the offer implicitly has to exist [the devices didn't ship with the source code, so 3a GPL is no longer possible].

It's really disappointing to see this happen again and again. Everybody seems to not care at all about the copyright of the code involved.

Apparently, the AAM6020VI, AAM6020BI, AAM6030VI and AAM5030BI devices all contain Linux (including netfilter/iptables) -based firmware images, but no source code is made available.

None of the devices is sold here in Germany, so I can't go after ASUS Germany.

Estampie is definitely one of my very favourite music bands ever. For the majority of my readers: They do serious medieval music. "serious" meaning they are doing this at the level of profession that you expect from classical musicians. Estampie is doing this for some 20 years, and they're not to be confused with the Spielmannsmusik that you recently find at any of the tourist-laden medieval festival.

At one of those dates when I was travelling to yet-another Free Software related conference, they played a programme called Marco Polo - Music of the Silk Route. Basically they tried to go beyond European medieval music and build bridges to other musical traditions of the same time, such as Khorasan Dotar music from Iran, traditional Mongolian music and some Indian Percussion.

They recently released a Live recording DVD from that project, and I am totally in love with the blend of music they have created. What they have created is "real" world music to me.

And there is more to come. As Michael Popp (the leader of the ensemble) points out in the interview section, "Marco Polo" was just the beginning of a trilogy. I'll definitely make sure that my travel schedule will adjust to the dates of the second and third part of the trilogy. There's no way I'll miss them.

The problems with this conference continue.

The social event libre supper costs real money, and about the only thing you get for it is a nice venue. It was held in the city hall.

The buffet was not set up in the middle of the hall, but in some separate room next to it. So the bottleneck was not the buffet itself, but the door between the hall and the buffet-room. This further prolonged the queue lining up unnecessarily.

So at the time I ended up at the buffet, there weren't even any glasses left - meaning that I had to "enjoy" my dinner without wine or water. Obviously everyone would line up for a second and probably third helping. People like me who refuse to line up for half an hour and only enqueue when the queue is shorter don't actually get any of the desert.

I've probably never wasted my money and time more efficiently.

Did I ever mention that having reliable and fast Internet access is the single most important factor for me (and other busy developers, especially those who are self-employed or run their own company) when visiting a conference or other event?

When visiting a conference, I basically have to leave all my work behind for a number of days. I can only do that if I at least respond once per day to customer emails, and deal with the most important things that pile up in the incoming queue of business-related email and faxes.

So at LSM the first issue with the network was authentication. You were required to enter your login name and password that you used to register for the conference [several months ago]. For those people who don't reuse the same password for multiple sites again and again, and who don't have monster brains, this means that the password is not something they will remember off their head. In my case that password is securely stored in an encrypted keyring on my nfs serve at home.

Obviously it wouldn't be a problem to bring that password to the event, if somebody actually had cared to spread the information that it would be required at the event.

After some discussion with multiple people, a new account was created for me. It was supposed to work within 15 minutes, but it didn't.

Even better, the wireless network was shut off at 6pm. Jeez. They don't get it. When at a conference, I need to use the nights in order to cover up for the lost working time during the day. If there is no Internet access in the evening or during the day, I'm unable to do so.

On Thursday it was even better: The wireless network was shut off at 12 noon. Somebody told me that this was to motivate the incentive for people to go to a speech by the mayor of Dijon. This speech would no doubt be very interesting - if only I understood a single word of French. So the best thing the foreign visitors (among them a number of speakers) could have done during that time was to catch up with their email and work - if only there was network access.

So as a matter of fact, I've now spent the longest period offline (four working days) for years. I can only imagine how upset some of my customers will be. Thanks, LSM.

This will be my last post about this horrible event. I only wish I had taken the first train back after running into the problems finding an accommodation on Tuesday.

After my voluntary 6-hour stopover in Paris, I finally arrived in Dijon at something like 7pm.

During the train ride there, I wanted to read the instructions on how to get onto the campus. I've received an email regarding that subject some time ago, but I didn't yet read it, since I have all my email synchronized to (an encrypted partition on) my notebook. Sadly it turned out that this email didn't contain any instructions but just a link. Obviously the link is useless unless you have online access. Ok, I can't blame the LSM/RMLL for not having read the email before - but it's also been the first time in all of the conferences I visit that such vital instructions haven't been sent by mail.

Luckily I ran into some LSM/RMLL attendees in downtown Bordeaux who told me how to find the campus.

At the campus, I found dozens of LSM/RMLL signs pointing in contradictory directions - and nobody there.

So I called the only other person at LSM/RMLL of whom I had the cell phone number: Werner Koch, one of the other speakers. He was lost, too :( So I made the only reasonable decision: Get back to the city centre and look for a hotel room. Obviously, the tourist information was long closed. So I walked from one hotel to the other. The first two were fully booked. At the instance of entering the third hotel, Werner called again.

Luckily he ran into some other attendees (not organizer!) who managed to talk one of (obviously non-English speaking) officials at the student dormitories into accepting the two of us for one night.

Obviously I didn't have the breakfast vouchers at the time of breakfast (since registration opens only after breakfast is finished, and it's a 15minute walk to the restaurant). So I end up at the conference venue without breakfast.

I think this is the way you _not_ want to organize a conference. I don't think there was any other event (even the previous LSM in Bordeaux I've been to) which had equally non-existent speaker care. At most events, you get picked up from the airport / railway station, brought to your accommodation, and at the hotel reception you receive printed instructions, such as a map of the campus, Instructions on when to be where, and (most importantly) some contact phone numbers in case you get lost or have any other problems in a country whose language you don't speak.

At my presentation (as the presentation of David Turner, FSF GPL Compliance Lab Engineer) were about 10-15 people in the audience. So I'm actually leaving an ever-growing pile of work behind in my office, choose to not do any paid work for three days, paying for the accommodation myself (travel is covered), going through all the hassle of the travel as described above, to talk in front of that small an audience. I guess this really was my last LSM.

And yes, I could continue this rant now about the wireless network, which requires you to log in with the account data you used to register for the conference. That data is securely stored on my hard drive at home. Why would I bring such data with me, if nobody tells me upfront that I would need it? *sigh*

If you want to do an online purchase of a SCNF (french national railway) ticket, the only option you get is: Pre-pay the ticket via credit card in their online store, and later pick up the ticket at some vending machine at the railway station.

So this is what I did for my Paris->Dijon travel. So I went to the first vending machine at the CDG Airport in Paris. For authorization you are required to enter the booking code, your name and the credit card you used to do the online purchase. The first machine was broken, since it wasn't able to read the magnetic stripe on my credit card. The second machine already had a sign attached that it is malfunctioning and cannot be used for pickup of pre-paid tickets. Al the other machines were out of service.

Then I went to the next machine and tried to buy a public transport ticket from CDG airport to Gare de Lyon. The fare is 8 EUR and according to the signs on the machine, you can pay cash (in coins, which I never have), by french debit cards (which I obviously don't have) or by VISA card. Unfortunately it refused to accept my perfectly valid VISA card. So I had to line up at the long queue in front of the ticket counters.

At Gare de Lyon, I tried again to pick up my train ticket to Dijon. Most of the machines would again have problems reading the magnetic stripe on the VISA cards, and the others could read it, but would just tell me: Cancelled, please retry at a different machine.

So I again had to line up for the extremely long queue in front of the ticket counters, wait in addition for the only English-speaking cashier to become available. I told her my story, and she said: Yes, it only works with french VISA cards.

I was outraged. The online shop for buying tickets is fully translated to English and German (among others). You can buy the ticket using a non-french VISA card, and the amount is charged to your credit card account at that time. The translated instructions tell you to pick up your ticket at the machines, and nowhere it was stated that you have to queue up in front of a counter with non-french VISA cards.

The sole purpose of reading the credit card at the ticket machine is to provide a third authentication factor ('is this person really the person who booked the ticket'). There is no technical reason for restricting this to credit cards of a particular issuing country.

I'm planning to write some letters about this, since this is actually against fair competition regulations. If I want to receive the same service and not wait for half an hour for every train ticket I buy than everybody else, I have to open an account with a french bank.

I've finished the port of pptp-conntrack-nat to the new 'rustynat' infrastructure of the 2.6.11 (and 2.6.12.x) kernels.

The frequent reader of this blog will have noticed my prior post. Despite being just a minor kernel release, the conntrack/nat core got some recent re-work which made porting of non-trivial helpers quite complex.

I've tested plain conntrack and SNAT/MASQUERADE so far. DNAT remains untested for now, but should work. It's not as common so I deferred testing and potential debugging - esp. since I'm going to be travelling again by tomorrow.

Thanks again to the cool guys from NetBoxBlue for funding this work. That made it a lot easier to put this in the top section of my TODO list.

I'm heading off towards LSM/RMLL (Libre Software Meeting) in Dijon (France) tomorrow.

I'm looking forward to this event, especially since I'm going to meet David Turner, the new head of the FSF's GPL compliance lab. We've got a lot to talk about with regard to cooperation/coordination between the gpl enforcement efforts of the FSF and gpl-violations.org.

Travelling will take me enroute to Paris, so I'll spend a couple of hours stopover in the city to visit some of its famous cemeteries. With some luck the weather will be ok for photography...

For those who are curious: I'll be back to Berlin by Friday evening.

In an article on linuxinsider.com, Heather J. Meeker of Greenbar Traurig LLP (don't miss the background info at FFII Wiki) makes false claims about the gpl-violations project and myself.

I've pointed out her mistakes in the following letter:

Dear Ms. Meeker,

it has come to my attention that you have authored an article entitled "Open Source and the Legend of Linksys", published at linuxinsider.com, in which you make false statements in order to discredit the gpl-violations.org project and myself.

There is nothing wrong with press articles and commentaries about the GPL, the gpl-violations.org project or myself, no matter how critical they are - as long as they are based on facts. Spreading lies is however not acceptable to me.

The most obviously wrong statement is "But, it so happened, that AOpen was actually compliant, having offered the source code on a German Web site, as Welte later noted in his blog. Never mind.".

The truth is: AOpen Germany offered the _object_ code of the GPL licensed software on their German FTP-server, without complying to the GPL license terms. My blog clearly states "Firmware" (which is by definition object code, not source code). This means that in fact they are even legally responsible, since they distributed GPL licensed software without adhering to the license conditions.

Two other quotes from your article: "The problem is that Welte apparently does not hold the copyright to the code that is the subject of these letters."

"Some of Welte's targets have complied voluntarily, but one suspects that is because they were simply unaware of the problem. Welte apparently has no authority to enforce these copyrights."

This is again wrong. I have never enforced any copyright that I don't own. What has happened is that some other Linux kernel developers have transferred their copyright to me, so I can take action in cases where my own copyright is not involved. [which by the way is also a good indication that gpl-violations.org is not some lone lunatic but backed by the development community].

Obviously I reserve the right to inform any organization about illegal copyright infringement they might be committing, even if I'm not the copyright holder. This must not be confused with legal GPL enforcement by an actual copyright holder through in or out-of-court legal action.

Specifically, regarding to the "CeBIT letter action", I could have started legal proceedings in all those cases. In fact, my legal team an I were planning to personally hand over a preliminary injunction at one of the CeBIT booths. Rather than doing so, I thought I could save the respective infringing companies the trouble of legal charges and legal expenses by first writing them an informal letter.

At this point in time, I do not know the legal situation of such easily-to-be-proven false statements in the US. In Germany we have laws that force the press to publish "correction statements" written by the person or entity that was subject of those false statements. I will consult my legal advise about this matter.

I would like to ask you to clarify those issues. Since it is an on-line article, it should be possible to amend it. If that is not possible, I'm sure there is some other way to let the readers know about those two "mistakes" in the article.

Sincerely, Harald Welte

I've posted some additional comments in the talkback section of the article. They yet have to be approved by the publisher.

Only three months after putting in place the Alphacool liquid cooling system for my dual Opteron workstation, it has already corroded severely.

I don't really understand why, since I only used a readily-packaged set as offered by the vendor, and I only used original anti-corrosion liquid from the same vendor.

Spent multiple hours getting rid of all the crystals in the system, dismantling the CPU coolers, etc.

I hope the vendor replaces some of the parts for free and comes up with a good solution to prevent this in the future. I don't want to give up my silent office anymore. (btw: I didn't tell you about my new managed VLAN-capable fan-less 16port gigE switch, did I?).

It's amazing how long it can take to set up a small "reasonably-secure" WPA wireless network.

I thought it would be pretty straight-forward. Just configure the AP to EAP, tell it the radius secret, apt-get install freeradius, distribute some X.509 certificates and start wpa_supplicant on the client machines.

In principle, that's it. However, practical issues I ran into:

• The AP crashes every so often
• The AP needs to reboot after every single config change (no chance to do multiple changes and then reboot
• The AP needs some 5 minutes to reboot
• The AP refuses to use certain totally valid IP addresses, be it via DHCP or statically configured in the web frontend
• The Debian freeradius package on AMD64 misses EAP support due to a libtool problem (missing -fPIC), known since January.
• The Debian freeradius package doesn't ship with EAP-TLS, since the EAP-TLS code is GPL licensed but links to openssl.
• wpa_supplicant doesn't work with the PowerBook built-in Airport (orinoco_cs) card

So I wasted the better part of a day to overcome the issues above, but I'm still not happy. My PowerBook now needs an Atheros Cardbus card, even though it has a built-in card. DHCP randomly fails for unknown reasons (I see the valid DHCP replies go into the AP, but it fails to pass them on).

I just received news from David Miller (the Linux kernel networking maintainer) that he has started a new Linux Kernel Networking Homepage.

Even more interesting to me personally is his blog. I hope to convince him to use some tool [or write one] that can generate RSS and have him listed at kernelplanets.org.

There's a recent uprise in the availability of handheld media player devices. Most of them come with a 240x320 / 16bit colour screen, FBAS output, USB, 20GB hard drive, etc.

A big part of them seems to be running based on Linux and other free software, which is great. However, the vendors once again forget about their obligations under the GNU GPL and do not tell their users about the GPL or make the source code available.

The first device I ran into was the iRiver PMP-120/140, on which I have reported earlier in this blog. It was based on a TI DSP with embedded synthesized ARM core.

Now we're seeing similar devices from iStation, iUbi, Sitecom and some other vendors hitting the marketplace. They are all based on the SigmaDesigns EM8511 chipset. Rumors have spread that Sigma actually tries to bind their customers under an NDA not to release the GPL licensed source code, which they would obviously have no right to. Please keep in mind that that's rumours, and I don't have any confirmation about this yet.

Following up some thorough testing and debugging, I finally got both (SNAT, DNAT) and MASQUERADe to work with ct_sync on a 2.6.10 kernel.

Apart from forgetting to disable TCP window tracking, there were some subtle mistakes in #ifdef/endif of the code that actually prevented whole sections from being built ;)

Debugging the problem however has forced me to update the ct_sync ethereal plugin (screenshot) to parse almost every bit within the ct_sync protocol.

Almost all homepages I maintain are built using docbook-website.

Unfortunately I'm not a big XSLT guru, so I'm having a hard time finding and fixing bugs in them. For that reason especially the netfilter.org homepage was suffering from problems with olinks.

Luckily, the 2.6.0 release of docbook-website seems to have fixed all the olink-related bugs I was experiencing. I just re-built the page and now all the cross-linking (including #localifo) is working fine now. Thanks to whoever fixed it :)

Just a quick status update:

I've tried to make most of the patches in netfilter patch-o-matic-ng work with 2.6.12 today. It's amazing how fast the code bit-rots there.

I've also applied tons of cosmetic cleanup fixes, such as %zu and %ti format strings to avoid compiler warnings on 64bit archs.

Now it's time to head back to the PPTP-conntrack-nat port for 2.6.11+. Once that is finished, I'm back to ct_sync work.

Oh, and yes, I almost forgot: ftp.netfilter.org will have start having daily snapshots of conntrack and ipset.

I'm back to netfilter hacking, and it's more fun than ever :)

libctnetlink was extended to provide an API function to add an expectation. Also, the cool new conntrack control program now has preliminary support to add expectations from the command line.

This means there is now the full chain in place (from kernel to userspace library to command line tool) to allow expectations to be created from userspace. I wonder how long it will take to see the first userspace ALG's to show up. It would be a pleasure to finally see complex protocol handling done in userspace rather than the kernel side.

While hacking at conntrack, I also added a man page and fixed some other bits and pieces. Once the "do we want an ID, and if yes which kind of ID" discussion has concluded on netfilter-devel, we can submit nfnetlink and ctnetlink to the mainline kernel and make a first libnfnetlink, libctnetlink and conntrack release.

Same procedure as every year. One of the hardest things at LinuxTag is to get Internet access. My experience this year is a follow-up to long discussions in the previous years following-up to my complaints. However, the problem seems to be persistent.

First of all, the WLAN is not working. WLAN access is provided by a different organization than wired Ethernet access, and nobody from the WLAN team was around to comment on why.

Wired access is almost impossible to get, since there are only _three_ public Ethernet ports available at this time - apparently due to a lack of multi-port Ethernet switches. The network admins were nice enough to allow me access at one of the non-public infrastructure switches, though.

Even after finally having access to an Ethernet port, I wasn't much more excited. The only thing that worked was HTTP via a proxy, and SSH. So no way to do speak commonplace protocols such as IMAP-over-SSL on port 993. Or to access Subversion-over-Webdav servers on non-standard ports. Or to build up an IPsec tunnel :(

Luckily I'm in the situation to be able to do SSH tunneling, but not everybody has shell accounts on their mailservers...

Then I tried the Vodafone hotspot available in the Conference Hotel. Not only do they charge ridiculous EUR 24,95 for 24h access, but they also offer something that barely can be called "Internet access". So far, I've only been able to establish HTTP(s) sessions and IMAP-over-SSL. There's no outgoing SSH working, and also no IPsec.

This leaves me now with the option to run between the two adjacent conference and hotel buildings. SSH works in one place, but IMAPS only in the other. Surprisingly, I never have similar problems at any other conference that I attend - and if you look at my schedule, you notice I travel to a lot of conferences.

I've already decided to have my bank cancel the Vodafone credit card charge since they promised me Internet access, but all I got was WWW-and-IMAP. They should have told me before, then I wouldn't have bought their services.

I've just confirmed yet another GPL Violation of Cisco Systems. This time it's not a consumer class product sold under the Linksys label, but an enterprise-class "Cisco" product.

More details will follow as soon as Cisco has been informed. I regularly don't make any details public before the respective opponent has received the first letter from my lawyers.

Sitecom apparently _again_ violates the GPL. This is now the third product in little more than a year.

Again, more details will follow soon, stay tuned.

I've just arrived in the south-west German city of Karlsruhe for three days Astaro and two days of LinuxTag.

In addition to that, there are several scheduled GPL-related meetings. The most important one is probably the meeting with Cisco Germany. I'm really interested in what they want to say with regard to the recent uprise in GPL-issues inside Cisco.

Unlike a lot of my recent travel, I have Internet access every day. This means there will be little [additional] delay in responding to email.

I just finished my first three-day-in-a-row training for quite some time. Seems like I almost forgot how exhausting it can be to talk for three full days. However, it seems like the biggest part of the training went quite fine, and the attendees were satisfied.

The most interesting part for me was to learn about the practical "real-world" setups in which those users were actually using packet filters, NAT, bridges, routers, etc. So basically it put me in touch with some of the more advanced users, and taught me about their particular requirements. This will definitely help during the further development process.

What is wrong with browsers displaying large HTML tables? Well, I had to look at a "CISCO global price list" (looking for the price of their latest alleged gpl violation). Of course that list is only available as .xls, so I used xlshtml to convert it to HTML. THe result is a 12MB HTML document.

Opening that HTML in w3m took quite some time on my dual Opteron 246, and I was wondering why it took so long (it indicated it was opening the file from the local hard drive at 9.6MB/s, though). Looking at top, I hardly believed my eyes. The total virtual size grew up to 760MB(!)

I then re-tried with Mozilla, and it did equally bad with 815MB. However, I would have expected something like this from Mozilla, being a monstrous GUI program... but w3m? I'm puzzled.

Mostly out of curiosity, I recently bought one of the cheap Intel PRO/Wireless 2915ABG cards. I tried to install it in my (obviously non-centrino) AMD Turion64 notebook, and it almost worked immediately with the ipw2200 driver.

The only issue remaining is the hardware RF_KILL pin. It's intended for those hardware-switches that allow the user to physically disable any RF input/output [for airplanes, hospitals and the like]. Intel is using Pin 13 of the miniPCI slot for that, and even though the TARGA notebook (manufactured by MSI) has such a switch, it seems to be using a different pin. So what I did is cut a tiny strip of adhesive tape and glue it on pin13. This prevents any electrical contact and makes the 2915ABG card happy.

Now I have working wireless in that notebook. However, at the expense of Bluetooth, since the original INPROCOMM 2220 card implemented both, 802.11 and Bluetooth.

Just as a reference, I also tried a Winstron CM9 Atheros 5212 a/b/g card, and though it electrically worked, I was unable to receive anything with the latest madwifi-cvs. Played some time with the debugging options - at no avail.

Now the TODO contains checking out Jeff Garzik's latest wireless-2.6 tree and see how Intel and SuSE are doing with the new generalized 802.11 layer.

For the third time, Linksys (now only a brand of Cisco) seems to be selling devices in a GPL-incompliant fashion. Following up the WRT54 case in early 2003, and the less-known WMA11B issues last year, they've now started to sell the ADSL2MUE.

I did a test purchase. It clearly contains the Linux kernel and other GPL licensed software. There is no mentioning of the GPL, no GPL license text, no source code, and no written offer anywhere in the package, manual or on the included CD-ROM.

I really don't get it. How could this happen again? Rumours say that the device was OEM'ed from somewhere else. Even in that case, Linksys should have enough GPL experience to include a statement like "if the product contains GPL or other copyleft-licensed software, the full corresponding source code has to be delivered" into their contracts with the upstream vendor.

Shortly after the warning notice had been sent by my legal team, some source code appeared on http://www.linksys.com/support/gpl.asp. I have not yet conformed that it is complete, but it looks like they even included the Texas Instruments' LZMA (de)compression bits, which no other vendor using TI's AR7 platform has been provided, even though they are a clear modification of the existing GPL licensed Linux kernel source code.

Linksys (Germany) officials have invited me to meet them. Due to restrictions of my travel schedule, the meeting will only happen in late July. I'm looking forward to that meeting and will remain curious about their interest in such a meeting :)

Some time ago I was interviewed as part of the preparation for a thesis on the motivation of Free Software developers. For those of you who understand German, the full paper (109 pages) by the Sociologist Thomas Breitner is now available online.

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?

After yet another break I'm now back at some librfid hacking. I've compiled the code from svn on my ppc notebook, and it worked straight ahead (as far as it is implemented). Quite surprising, since I didn't even think once about endianness so far. I suppose this will change when implementing the upper layers.

I've now also started work on libmrtd, which is to be a library implementing the functions typically required at a "border control application" of an ICAO-compliant MRTD (passport). This includes basic access control, encrypted communication with the MRTD, and parsing of the data (DG1, DG2) stored on the MRTD.

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

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.

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

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

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.

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.

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.

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

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.

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

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

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

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.

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.

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.

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!

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

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.

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.

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.

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.

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.

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.

Since the CeBIT letter action, I've received a surprisingly big press coverage, ranging from heise.de over zdnet.co.uk, zdnet.com to news.com.

That press coverage, together with the slashdotting on Tuesday last week have triggered an enormous amount of feedback, mostly from individual users reporting a myriad more of alleged gpl violations.

I'm sad that the number really grows that fast, but on the other hand happy that we now have the chance to collect all this information.

Last, but not least, a number of people have volunteered to help the project, e.g. with it's public database interface, as well as homepage XSL corrections for full XHTML validation.

If you have sent me mail regarding GPL violations and didn't receive a response so far, please be patient, I'm just not through all of them yet. Give me another week, thanks.

According to some reports the worlds most popular series of proprietary systems is suffering from a severe lack of a packet filter. This is also documented at another article plus discussion.

Now apparently Microsoft will invent the idea of having a packet filter integrated into the operating system with their WPF for Longhorn.

It's really amazing how innovative those guys are ;) Did I mention that Linux has an embedded packet filter since more than a decade?

The news about the CeBIT letter action yesterday has made it to slashdot.

While this is good news (since more people learn about my project), it also has the disadvantage that my SDSL line was fully filled. Now I moved the site to vishnu.netfilter.org, the main web-server of the netfilter.org project.

Also, I really regret that the amount of information at gpl-violations.org is still quite limited, especially the database of documented gpl violations and enforcement cases is still not there :(

The best source of information is probably my blog, and the slides of my various presentations.

The CCC has presented it's 2005 CCCeBIT negative award to the Bundesdruckerei, the formerly state-owned now-privatized company in charge of printing passports in Germany.

They are one of the strong forces in Germany behind the announced introduction of biometric information in passports. To understand this, you have to know that the law still requires passports being produced by Bundesdruckerei, even though they're now a private company.

So today I've personally handed over some 13 letters at the CeBIT trade fair in Hannover.

My experience varies from case to case. A number of the respective recipients simply received the letter and told me they would forward it to the respective department.

The best experience so far was X-Micro, where I met the Vice President and had some discussion with him about what this all was about. Apparently he was quite happy to hear that it is not about license fees and neither about patent infringement ;) Anyway, we'll have to see what kind of practical results we will see in the upcoming weeks.

Really bad timing. The USRP is sitting on my desk for about ten days now, but I still haven't really done anything useful with it. This is because I'm still reading up the theoretical background in digital signal processing.

That DSP book I'm reading is a real revelation, though. At the moment I've finished the discussion of LTI systemes and IIR filters, making my way through the z-Transform. It's really exciting, and I'm sure I need more of that kind of stuff :)

Please note the official gpl-violations.org CeBIT letter action press release.

ct_sync is now able to run multiple instances on one node, allowing vrrp-like setups! Thanks go to http://svn.netfilter.org/netfilter/branches/netfilter-ha/linux-2.6-actact/

The next couple of weeks will be focusing on testing and real active-active setups with multiple masters. My brain is already smoking from all the synchronization issues ;)

The frequent reader will know that I'm internally keeping a SQL database of all gpl violations and related data. Unfortunately I have still not found the time to write some scripts to generate a public web interface.

Anyway, even only entering the data is quite difficult, since there really is a significant lack of database related programs, or even something as SQL rapid application development IDE's, similar to FoxPro (yes, I've used that some six years ago...).

The gnu-enterprise project is heading that way, and at some point I was half through writing a fronted for the gpl-violations.org database. However, something has recently broken the gnue package on Debian, so that's not an option at the moment.

So for now, my data entering tool is 'psql' and hand-typing SQL statements. Gets sort of annoying after you're doing it for the better part of the day :(

For a number of months, there is now a forked version of mutt called mutt-ng. I just tried it today the first time, and I really like it. It's good to see mutt development is moving again.

I'm not even sure how much time mutt-ng will save me through it's maildir header caching. That saves the ridiculous delays when navigating through my 130+ folders 4GB maildir spool :)

Next item on my personal wish-list would be threading across multiple folders. I'm missing that feature ever since I stopped using CrossPoint (DOS-based mail-reader software for FIDO,Z-Netz,MAUS and UseNet) in 1994.

I've recently again picked up the work on ct_sync. The final goal ist to support real active-active fail-over setups. Before the real work on that particular issue can start, there are a number of prerequisites, like:

• multiple cluster instances on one node
• new sysfs-based configuration interface

2.6.11 is out for a number of days, and we still don't have the conntrack/nat helpers from patch-o-matic ported to Rusty's latest conntrack/nat helper infrastructure changes.

It turns out that there are more changes necessary than I though initially. It's strange that nat helpers now don't have a separate expectfn() anymore, only the expectation has one. So I guess at least for talk, we'll have to call back into ip_conntrack_talk.c from ip_nat_talk.c.

With some luck I'll be finished by tomorrow and can again concentrate on the fun stuff like active-active support for ct_sync.

this was probably one of my shortest conference visits ever. I took the train to arrive about three hours before my talk, and left two hours after it. It's a pity that I had to skip the social event, but I really don't have any leftover time at the moment.

The presentation went quite fine, though I now remember all the items that I wanted to add, but forgot during the presentation. Too many strange questions interfering throughout the talk.

Anyway, I almost forgot how nice CLT was. Apart from their very professional organization (they even send you paper printed city maps via snail mail!), their speaker care-taking is extraordinarily. I haven't been to any other event that provides free food for speakers throughout the day - ranging from freshly prepared sandwiches (no dull catering service)to pastries... at any given time in the speakers lounge.

So now I'm sitting in the train back from Chemnitz and am working on the Aftermath of Rusty's 'newnat2', hopefully the last rework of the conntrack/nat helper infrastructure.

A number of companies who don't fully oblige the GPL license conditions are going to be present at CeBIT. This provides the unique opportunity to personally hand them a letter about their licensing problems, and in some cases probably even enforce the license with vendors whose products are otherwise not sold in Germany, but who're present at the trade show.

For strategic reasons I cannot really say more at this time. Stay tuned.

The regular reader of this blog already knows what the USRP is. The infrequent reader is referred to this blog entry.

So it has finally arrived, although I really don't have too much time of playing with it at the moment. I guess I'll do some basic functionality tests and then have to put it aside for some time.

One of the important issues remains the lack of readily available RF frontends. With the BasicRX frontend, you can basically sample amplified signals of up to 32MHz bandwidth below 200MHz.

I've investigated a lot of options with regard to RF frontends, and none of them is really promising:

• A commercially available 20-3000Mhz tuner/down-converter WiNRADIO WR-G526e. That's what we all want. Unfortunately horribly expensive, I've read USD6k somewhere :(
• Using a commercially available radio scanner with 10.7MHz IF output. This sounds like a good idea. The problem is that most of them seem to have ridiculously small IF bandwidths:
  • Yaesu VR-5000 (+- 100kHz IF bandwidth): ~ 500-600 EUR
  • AOR AR3000A (IF bandwith unknown): 780 EUR
  • AOR AR8600MK2 (IF bandwith +- 2 MHz): 710 EUR
  • AOR AR5000A (IF bandwith +- 5MHz): 1600EUR
  So if you want to go for high-bandwith signals such as DVB or 802.11, only the AR5000A would be usable... again quite pricey.
• Using a DVB-{T,S,C} tuner to build your own USRP RF frontend. That sounds reasonably priced, but requires quite some amount of work. Issues include
  • Obtaining tuner samples from vendors like Sharp or Microtune
  • Designing the support circuitry (voltages, matching)
  • Writing software for tuning (mostly i2c bit banging)
  Possible Tuner Modules I've found so far
  • Sharp BS2S7HZ1204 (950 to 2150MHz, 10 to 30MHz IF bandwidth (I/Q))
  • Sharp BS2S7VZ1302 (950 to 2150MHz, 10 to 30MHz IF bandwidth)
  • Sharp VA1S1ED5056 (143 to 862MHz, 7 or 8 MHz IF bandwidth)

FOSDEM was a huge success, met lots of interesting developers working in various different areas. The conference facilities seemed more crowded than at any other conference - probably due to small hallways and really cold weather outside, combined with the lack for space where people could just sit and chill out.

One dinner with Alan Cox, one with the gnomemeeting crew and another one I ended up sitting next to the author of squashfs :)

I was a bit disappointed that Richard Stallman (although present at the event, delivering two speeches himself) did not attend my closing talk on GPL enforcement. Maybe he was already travelling home at that point, or he's really not that much interested in my first-hand experience on enforcing 'his' license.

Also, I got rid of the last batch of netfilter t-shirts, saving me from finding further excuses why I am not shipping them anymore ;) Also, this means we can now head for a new logo (stating Linux 2.6 instead of 2.4) and probably even black shirts, since I don't wear white shirts anyway ;)

I've made a new release of the ctapi-cyberjack driver for REINER-SCT. Until they put it up on their homepage, interested parties can always grab the latest source and rpms.

Due to the generous donation of TomTom, we were finally able to purchase a second hand digital oscilloscope.

The 54622D has two analog channels with 100MHz bandwidth (200Ms/s) and 16 digital channels with 200/400MS/s. The really nice features include stuff like CAN-, I2C-, USB- and SPI trigger modes :)

Let's see how this new toy is getting used to explore yet more technology...

I'm in the middle of my final travel preparations for Brussels (European Commission and FOSDEM, see the weblog backlog), and was just reading through th e final conference programme.

It's good to see familiar kernel developers like Alan Cox and Deepak Saxena (whom I've last met at Linux Bangalore in December). I'm also looking forward to meet some Ethereal guys (after writing an ct_sync ethereal plugin recently).

Of course there's also the gnomemeeting guys, who will be eager to hear some answers about how to get or not get h323 throug a netfilter/iptables firewall (STUN doesn't help, it's fully symmetric NAT). Not sure if I'll have answers, though ;)

Robert Olsson is doing very insightful high-performance networking research on Linux-based machines for many years. Little people know his huge collection of ASCII-snippets at http://robur.slu.se/Linux/net-development/experiments/. It's a real pity that he's basically doing all this research in his spare time, being a systems administrator at university. Intel and others should actually look at that and fund his invaluable research!

Recently he achieved 2.1Mpps aggregated packet forwarding rate over four Gigabit Ethernet ports using a Dual 2.4GHz Opteron 250 machine with a specially optimized NAPI driver patch.

Another interesting graph (almost one year old) compares the memory latency on Xeon vs. Opteron. Looking at the results, you will understand that really want to get Opteron CPU's with integrated memory controller if you care about network forwarding performance :)

Please note that this number is under very synthetic conditions only. This is single-flow UDP performance, so any routing cache misses / fib lookups are not yet in the picture. Also, due to the stupid nature of _all_ Ethernet cards, we have to do IRQ affinity and thus only achieve highest performance on the two interface pairs that are bound to the same IRQ.

I'm already in travel preparation mode. Buying the last couple of gifts, shutting down servers that I won't need, writing packing lists, and wading through the remaining two A4 pages of TODO items for the remaining four days.

I'm going to have three weeks of holidays. Contiguously. Not attached to any conference or other FOSS related event. At least two weeks of it without touching a notebook or PDA. I have no idea when I last did that. Probably while I still was with the boyscouts.

Well, yes, I will meet some hackers in the first couple of days, but those have become friends, and meeting will be strictly off-duty ;)

Elisabeth and me are heading for three weeks of Southern India. It has been suggested to me that details are not to be revealed beforehand, otherwise LUG members might approach me for giving speeches/talks/presentations. Not this time, sorry folks.

I only wish it had already started, and the next four days of TODO bashing had already passed...

Yesterday, I was attending the demonstration against software patents at the ministry of justice in Berlin.

This demonstration had to be called in on very short notice, because the European Council has yet again tried to quietly pass the legislation on software patentes (2002/0047 COM (COD)) as so-called 'B-item' on the agenda of the council (toe be more precise: the agriculture and fishing council). A B-item is one that requires no further discussion - which is absolutely wrong. The European Union has new member states that didn't participate in the previous discussion, and several member countries' parliaments have made decisions against patentability of software meanwhile...

I have the honor of presenting about my GPL enforcement efforts at the European Commission. No further details yet, I'll provide more informations ASAP.

The most interesting part is why are they interested, what is the intention of their interest, what kind of people will be listening to the presentation.

Since there's a severe lack of non-technical subjects in this blog, I decided to write something about a passion of mine that developed over the last two years: Bollywood Movies.

Most German readers of this blog will probably not have heard about Bollywood before, it's India's mainstream Hindi cinema, from Mumbai aka Bombay (guess that's where the 'B' is coming from).

Unfortunately Bollywood DVD's with English subtitles are very hard to get here in Germany, so I've had to order the initial couple of movies from Canadian NRI-oriented mail orders.

More recently, my friend Atul Chitnis was kind enough to bring a stack of DVD's every time he travelled to Germany - despite his personal dislike of Bollywood cinema. Thanks again, Atul.

Since a very short time ago, I also know DesiTorrents, a forum related to all kinds of Indian cinema, music, music videos, ...

Now you will ask yourself, "hey, isn't that the same guy who prosecutes copyright infringers?". Yes, it is. However, I have no way of legally obtaining the DVD's of the respective movies over here. I haven't found even a single DVD mail order specializing in those DVD's within .de. And ordering from abroad is very impractical, due to the high cost of shipping, and even more due the complicated customs procedure here in Germany.

So as soon as anyone can point me to a less problematic source of desi movies here in Germany, I'll immediately stop using DesiTorrents!

Recently my IPv6 setup became a bit more complicated, since I now have two sites with native IPv6 connectivity and two sites with tunnels, three in production prefix space and one still 3ffe. They're all connected via OpenVPN tunnels, and I _really_ need incoming and outgoing filtering of OSPFv4 LSA's, especially since one of the networks originate a default route.

The (new) opsf6d code has a completely different architecture than the ospfd, so I'm not really sure whether I understood it enough to put the filtering code in the right place. Just submitted the patch to the quagga-dev mailinglist, let's see what they say

I've coded a patch against 2.6.11-rc4 that allows dynamic (re-)configuration of the port assignment of connection tracking helpers. This has been a TODO item for at least three years on my TODO list ;)

After applying lots of updates that have accumulated in the last months, I've released ulogd-1.20. Changes include dozens of fixes and a new PCAP and SQLITE3 output plugin.

This will probably the last new-feature release for 1.x, since I'm already working on 2.x with included support for flow-based (ct_acct) logging.

Rusty's recent changes to the conntrack/nat helper API in 2.6.11-rcX have rendered all conntrack/nat helpers in pom-ng unusable.

I've created a new svn 2.6.11 pom-ng branch and started porting of all the helpers in there. The opportunity was also good to port all the 2.4.x only helpers to 2.6.x, so we won't have the big gap between 2.4.x and 2.6.x supported helpers.

I expect this to take a couple of days, and even after that, for most protocols I have no opportunity to test (proprietary protocols, proprietary software, ...), so I'll have to rely on your feedback.

I finally managed to get the iptables-1.3.0 release out.

As some of you may know, I've recently started to get more into electronics (again). It's been more than seven year since I finished my training as radio communications technician :)

Anyway, I wanted to do some research with regard to passive RFID sniffing, DECT (in)security and other subjects. You can build digital receivers the old-fashioned way: RF, Oscillator, Amplifier, Mixer, IF and Demodulator in hardware. This is what we all know and love ;)

However, recently so-called "software defined radios", a technology that was only available for government services and military (aka big money), are becoming cheaper and cheaper. Software defined radios take the complex IF signal and digitize it with high-speed A/D converters. All demodulation or other further processing can be done by signal processing software on the PC.

To my very big surprise, the Gnuradio project is already providing a very flexible python-scriptable software for doing such processing. Available code for demodulation is still quite limited (e.g. no FM stereo decoding, and only very preliminary NTSC b/w decoding). But well, this is just a matter of time.

What's even more interesting is the USRP (Universal Software Radio Peripheral), basically a USB2-connected FPGA-board with high-speed ADC and DAC's. It's available for less than 500EUR, so I immediately had to buy one. It hasn't yet arrived (shipping from the US), but maybe that's actually better... since experimenting with it will definitely occupy a lot of time that I don't really have :(

The latest bug (endless loop) was caused by one of my last bugfixes. Apparently I introduced an endless loop into a linked list (the nat bysource hash).

In very short amount of time, two 19" rack-mountable Ethernet switches went dead at the Berlin Chaos Communication Club.

The chairman of the friendly company Allnet was immediately willing to donate two replacements. Very kind of him :)

After about four months, the first Chaosradio radio show that I was participating in. Subject of the show was the telecommunications surveillance act (TKUeV) and the corresponding technical directive. Starting from 1st January 2005, any "provider of telecommunication services" has to provide lawful interception interfaces for government and police authorities.

The big issue is that it isn't only about providers, but about anybody who runs more than 1000 mailboxes on an email server, even if it is non-for-profit.

If you're interested in the full show, you can download it from the usual location on ftp.ccc.de.

The gpl-violations.org website now has a nice logo, thanks to it's designer Chris Huebsch.

Finally I've had the opportunity (and the time) to talk to Georg Greve of the Free Software Foundation Europe. It's good to know that they're very supportive of my GPL enforcement efforts, and it seems like we're going to coordinate our efforts at some later point this year.

This comes exactly at the right time, since I really want to get more development done and deal less with those legal issues.. believe me.

About a week ago the QSC SDSL line was activated. This is great news, and I just cannot describe the amount of difference it makes if you suddenly have eight times the upstream bandwidth.

I'm a bit in planning mood for conferences in the first 6 months of 2005. So far I'm going to visit FOSDEM (Brussels), CLUC (Zagreb), CLT (Chemnitz), LinuxTag (Karlsruhe) and obviously OLS (Ottawa).

If you happen to be at any of those conferences and want netfilter T-Shirts, please contact me beforehand so I can make sure to bring the required sizes and quantities.

Some time ago I started working on a small embedded Linux distribution. You will now ask yourself, why yet another one? Well, any free distribution you can find out there has either not a networking focus strong enough for my demands, or is using horribly outdated software (and especially no 2.6.x kernels).

So I'm now running that distro (still not sure whether I'll finally call it "gnumonks.org router (grouter)" or "Linux Wireless Router Application Platform (LinWRAP)") on three embedded production systems.

It's main features are

• Linux 2.6.10
• uClibc 0.9.27
• busybox 1.00
• iptables-1.2.11
• dropbear
• quagga
• openvpn
• iptraf
• siproxd
• dhcprelay
• in-kernel PPPoE
• fits in less than 15MB of flash

The only hardware supported so far is the PC Engines WRAP embedded x86 platform. More hardware support will be added over time, very likely candidates are IXP42x and probably even some of the Broadcom/ti/intersil consumer access point platforms.

The current state of the distribution can be followed in this svn repository. Please note that there is absolutely zero support or documentation.

The swiss company dremalab wants to sponsor me to work on an extension of ct_sync for active-active setups. More detailed news will appear very soon on the netfilter page and/or on this blog. Stay tuned.

There was s sudden surge in netfilter/iptables development in late December and early January. I'm still reviewing some of the changes, and am not yet convinced that all of them are the way to go.

About one week ago I had to apply for another preliminary injunction. Unfortunately the respective multi-billion company (name still undisclosed for strategic reasons) refused to sign a declaration to cease and desist before the deadline for obtaining injunctive relief has passed.

The injunction was meanwhile granted, basically banning the company from shipping their product in it's current form. I'm really sad that this happened, since I expect it to harm their business. However, I really see no reason why they couldn't just sign a statement "no, we won't do it again, and we will comply with the GPL from now on".

We're still waiting for their legal staff to get back to us, let's hope they have good news next time.

I've done some modifications to the mp4clip tool (part of the MPEG4ip software package) to do key frame accurate cutting/clipping of mp4 files. In general it seems to work, but from time to time it corrupts the source (!) files. Need to find time for debugging.

I'll release the patch as soon I consider it to be used safely. Don't want to be responsible for corrupting someones video collection...

The regular reader of this blog will have noticed the infrequent updates since december last year. There's a relatively easy explanation: lack of time. Or even more detailed: I used to write my blog at the time I went to bed. The data of the blog only existed on my notebook, and the notebook usually is in the bedroom.

However, during the last weeks I regularly don't go to bed before 2am to 5am - a time where my fiance, bound to university day schedule, is already sleeping. This means I cannot write a blog entry from the bed - you get the point.

This is set to change now, since the blog data will be checked into my personal subversion server.

After something like three years with asymmetric connectivity (less upstream than downstream), I've finally decided to order a SDSL line again. Even though it means I'll have to afford a 200% increase of ISP charges.

Back in Nuernberg almost ten years ago, I used to have an analogue leased line which ran at mind-blowing 33.600bps. Later I used the same line type with two Pairgain SDSL modems at about 1.5MBps... this is still the line where some of my old systems like coruscant.gnumonks.org, sungate.gnumonks.org and corellia.gnumonks.org are located.

After being invited to CLUC in Zagreb, Croatia and Chemnitzer Linux Tage 2005 I'm trying to decide which conferences to visit this year.

As usual, I'll be at LinuxTag, Linux Kongress, Ottawa Linux Symposium and Chaos Communication Congress.

Another likely candidate is this years hacker summer camp What the Hack in the Netherlands, even though it quite closely follows OLS.

If it wasn't for some user sending me email about the gpl-violations.org web-server being down, I wouldn't have noticed it. Apparently I made a stupid mistake while adding a new vhost to the apache2 config on that machine that went unnoticed until apache was restarted.

I'm not going into the embarrassing details here, but I would like to reveal that it was related to a new web-page called gpl-devices.org which I am about to launch. Let's see whether I can turn my ideas about it into reality, or if I never find the time, like with other interesting projects :(

Anyway, I'd like to apologize for the downtime. If someone had sent me an email earlier... *sigh*.

Since I now have the job of cutting (cropping/clipping) the A/V recordings of the more than 200 presentations of 21C3, I've been looking for a number of days for available free software to do GOP / key frame accurate cutting of MPEG2, mp4 and OGG/Vorbis files.

As for OGG/Vorbis, the vorbis-tools package contains a program called vcut, which basically does almost the full job. However, it's a bit clumsy to use, since it always splits a original file into two halves, before and after the cut position. I've modified it a bit in order to accommodate my needs better.

As for combined audio+video containers such as MP4, it becomes a bit more difficult, since you need to find key frames for both audio and video as close as possible to the user-specified cut point.

However, after learning a bit about Apple Quicktime and the MP4 container, plus the help of libmp4v2 from the MPEG4IP package, I was able to create a small tool for key-frame accurate cutting, too.

For MPEG2, there is lve (Linux Video Editor). This program even provides a graphical user interface for navigation through the video, creating clips and a cut&paste interface. Unfortunately the UI is not intrusive in any way, and it even seems to use it's own toolkit. After playing with it for more than 45 minutes, I wasn't able to actually cut a single video using it :(

Since MPEG2 is not a priority at the moment (we need to make .ogg and .mp4 available for download ASAP), I deferred this problem for now.

Maybe at some point I'll find the time to put together all the pieces and create some generic media cutting/clipping/cropping tool for any kind of format. However, judging from the differences of the media formats, there wouldn't be much more common code than parsing the command-line options ;)