OLS: Wireless Kernel Configuration BOF

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 and their policy on publication of standards.

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.

OLS: netfilter hacking with Patrick

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