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