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.