4.0.1 NAT checksum failure?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I'm seeing something which looks like failure to recompute the IP
header checksum when NATting packets with 4.0.1.

I can't believe this wouldn't've been noticed long ago if it were a
generic problem (I'm even on i386), so there's obviously some respect
in which I'm pushing an envelope here.

For example, here's the post-NAT header of a NATted ping:

45                       ip_hl=5 ip_v=4
00                       ip_tos [Routine]
00 54                    ip_len [84] (dropping 2 trailing bytes)
1a d8                    ip_id
00 00                    ip_off [0]
fe                       ip_ttl [254]
01                       ip_p [ICMP]
18 82                    ip_sum
45 c4 b5 1d              ip_src [69.196.181.29]
d8 2e 05 0d              ip_dst [216.46.5.13]

ip_sum is definitely wrong.  But the pre-nat source address was
172.16.0.3, and if I compute the checksum with 45 c4 b5 1d replaced
with ac 10 00 03, I find that 18 82 is correct.

There's another machine (also i386 4.0.1) which is set up to do NAT for
two others, and it works for one of them and doesn't work for the
other.  The only thing that I can see that could be related is that in
each of the failure cases, the failing address is an alias address on
the interface in question rather than being the principal address.

For example, to return to the ping whose header I quoted above, the
ping arrived on the NATting machine via ex0:

ex0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        
capabilities=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=0
        address: 00:b0:d0:24:eb:c9
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.7.1 netmask 0xffffff00 broadcast 10.0.7.255
        inet alias 172.16.0.1 netmask 0xfffffff0 broadcast 172.16.0.15
        inet6 fe80::2b0:d0ff:fe24:ebc9%ex0 prefixlen 64 scopeid 0x2

Note that 172.16.0.3 is on an alias network.

On the "one works, one doesn't" machine, the relevant interface is also
ex0, configured

ex0: 
flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> 
mtu 1500
        
capabilities=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=0
        address: 00:10:5a:71:ba:b0
        media: Ethernet autoselect (10baseT)
        status: active
        inet 10.0.4.1 netmask 0xffffff00 broadcast 10.0.4.255
        inet alias 10.0.255.1 netmask 0xffffff00 broadcast 10.0.255.255
        inet6 fe80::210:5aff:fe71:bab0%ex0 prefixlen 64 scopeid 0x3

and the working NAT is for 10.0.4.128 while the failing NAT is on the
10.0.255.* network (I can't recall the last octet offhand, the machine
isn't alive right now, and I'm not there to kick it).

Can anyone confirm or refute the theory that 4.0.1's NAT simply doesn't
get checksums right for addresses on alias networks in this sense?
I'll be digging through the code, but I don't know that code, and
strengthening or refuting my guess would help me focus my search.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B