[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
4.0.1 NAT checksum failure?
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  (dropping 2 trailing bytes)
1a d8 ip_id
00 00 ip_off 
fe ip_ttl 
01 ip_p [ICMP]
18 82 ip_sum
45 c4 b5 1d ip_src [18.104.22.168]
d8 2e 05 0d ip_dst [22.214.171.124]
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
media: Ethernet autoselect (100baseTX full-duplex)
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
media: Ethernet autoselect (10baseT)
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
Main Index |
Thread Index |