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

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.

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.

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

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.

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

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

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

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.

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

See the 1.3.4 release page and the ChangeLog.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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

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.

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

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

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

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

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

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.

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.

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.

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.

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.

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

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

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

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.

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.

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'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!).

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

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.

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

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.

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

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.

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.

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 me