Apply Darren's more complete reworking of hash code computation.
Ensure that the struct containing the red-black tree head is properly initialized.
From Geoff Adams
The problem was that ipf_nat_delete wasn't swapping inbound and
outbound hash codes for inbound NAT entries, so it was essentially
always looking in the wrong buckets in those cases. But because of
the way the linked list works, I don't think any NAT entries were
actually leaked. But since all the bucket counters and chain count
were getting messed up, things did start to go bad after a while.
(New NAT entries wouldn't be created, for instance.)
The fix is in the ipf_nat_delete function, itself; the other changes
are a slight refactoring of one method and adding some comments
that helped me figure out how the linked list with pointer-back-pointers
worked.
Also note that I haven't looked through the logic in ipf_nat_rehash;
it's likely that that might miss some things for the same reason.
I also haven't yet looked into the ipf_nat_newrdr problem with mappings
already existing. That'll be next.
1. check for NULL before de-refencing; in particular sel is assigned to NULL,
in the default case, and then couple of lines down we do sel->
2. gcc appears to optimize u_32_t hash[4], to u_32_t hash, since we only
use hash[0], disregarding the fact that we pass it to MD5Final() leading
to stack corruption. Use an explicit union, so that the compiler stops
butting its head where it shouldn't.
XXX: pullup to 6
#define FOO defined(BAR)
#if FOO
[conditional code]
#endif
is "undefined", according to C99 6.10.1 note 4. So, change code like
that to use the following paradigm
#if defined(BAR)
#define FOO 1
#else
#define FOO 0
#endif
#if FOO
[conditional code]
#endif
