Re: 4.0.1 NAT checksum failure?

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

>> Also, it's not just checksum offload; [...]

Okay, I believe I know what was going on here.

In my tree, if_srt.c has code to call pfil_run_hooks, so that you can
configure srt to point out an interface and then configure NAT for
outgoing packets on that interface and have it work.  (Without this,
the NAT code will run for the srt interface, not the forwarded-to
interface - but, because the return traffic comes in on the
forwarded-to interface rather than the srt interface, return traffic
won't be handled right even if you configure the NAT on the srt.)

Turned out the actual relevant difference between my "works" and
"fails" cases were that the "works" cases were hitting host routes that
bypassed the relevant srt - nothing to do with primary versus alias
addresses anywhere.

I've added code to recompute checksums after running pfil hooks

--- a/sys/net/if_srt.c
+++ b/sys/net/if_srt.c
@@ -298,6 +298,13 @@ static int srt_if_output(
   { simple_unlock(&sc->lock);
     return(rv);
   }
+ if (dst->sa_family == AF_INET)
+  { struct ip *ip;
+    ip = mtod(m,struct ip *);
+    ip->ip_sum = 0;
+    ip->ip_sum = in_cksum(m,ip->ip_hl<<2);
+    m->m_pkthdr.csum_flags &= ~M_CSUM_IPv4;
+  }
 #endif
  /*
   * We have to hold sc->lock across the underlying interface's output

and now NAT works just fine in conjunction with srt.

Not directly relevant to NetBSD, because, as far as I can tell,
NetBSD's srt doesn't have the pfil hooks calls to make NAT even *try*
to work with srt-based routing.  (If anyone is interested in changing,
that, I'll be happy to do what I can to help, though the code has been
mangled badly enough by things like KNFification that it probably will
require some human-layer intelligence, not just diffs.)

/~\ 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