2.6.14 is out, 2.6.15 has opened.

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 reports on OpenEZX, quote from Motorola executive

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.

librfid gets native CCID support

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.

Adding S/M support to libmrtd

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.