--NextPart-20050120231955-0111700
Content-Type: Text/Plain; charset=us-ascii

hi,

> 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!

i think the attached diff fixes your problem
although i'm not sure if it's an ideal fix.

YAMAMOTO Takashi

--NextPart-20050120231955-0111700
Content-Type: Text/Plain; charset=us-ascii
Content-Disposition: attachment; filename="a.diff"

Index: udp_usrreq.c
===================================================================
--- udp_usrreq.c	(revision 1000)
+++ udp_usrreq.c	(working copy)
@@ -969,9 +969,11 @@ udp_output(struct mbuf *m, ...)
 		    ui->ui_dst.s_addr, htons((u_int16_t)len +
 		    sizeof(struct udphdr) + IPPROTO_UDP));
 		if (__predict_true(ro->ro_rt == NULL ||
-				   !(ro->ro_rt->rt_ifp->if_flags &
-				     IFF_LOOPBACK) ||
-				   udp_do_loopback_cksum))
+		    !(ro->ro_rt->rt_ifp->if_flags & IFF_LOOPBACK) ||
+		    !(ro->ro_rt->rt_flags & RTF_UP) ||
+		    satosin(&ro->ro_dst)->sin_family != AF_INET ||
+		    !in_hosteq(satosin(&ro->ro_dst)->sin_addr, ui->ui_dst) ||
+		    udp_do_loopback_cksum))
 			m->m_pkthdr.csum_flags = M_CSUM_UDPv4;
 		else
 			m->m_pkthdr.csum_flags = 0;

--NextPart-20050120231955-0111700--