The latest revision of udp_usrreq.c (1.129) seems to introduce changes
to the logic surrounding UDP checksumming, so I assume that's the
culprit in my scenario, which looks like this:

My machine "barsoom" is a DNS server, and has two vlan connections
over the same trunk -- one to the world, one to the local network
where it lives.  It also has OpenVPN running a tunnel (using a tun
device) to my laptop, "dejah", over wi-fi.  So dejah queries barsoom
for DNS information over the VPN tunnel, and barsoom answers (from
cache, or after querying the world, as needed).  This has been working
great until the new code bits went in, at which time quite a few
responses from barsoom to dejah arrived with bad UDP checksums.

Studying the traffic with tethereal, I soon realized that it was only
UDP traffic that was affected, and I couldn't even get it to happen
for other UDP traffic: it was just DNS responses that were damaged.
Furthermore, the packets seemed to be quite correct; only the checksum
field was obviously wrong.  Looking at the traffic *leaving barsoom*,
I saw that the checksums were wrong as it put them into the tunnel!

Grubbing through the code that had been updated by cvs, looking for
relevant bits, soon uncovered the changes to udp_usrreq.c.  So I did a
quick "sysctl -w net.inet.udp.do_loopback_cksum=1" on barsoom.  Sure
enough, the problem was immediately resolved.

So it seems that the logic that avoids calculating checksums when it
shouldn't be strictly necessary, is a bit too optimistic.  :-)

-tih
-- 
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway Hosting
www.eunet.no  T +47-22092958 M +47-93013940 F +47-22092901 FWD 484145