Date: Mon, 18 Dec 2006 00:08:56 +0300 From: "Andrew Pantyukhin" <infofarmer@FreeBSD.org> To: "Kris Kennaway" <kris@obsecurity.org> Cc: current@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: vge(4) bad checksum Message-ID: <cb5206420612171308o4c8f2373g26986c5722e606e1@mail.gmail.com> In-Reply-To: <20061217205249.GA73132@xor.obsecurity.org> References: <cb5206420612171246q54ac783h1fd9d420b80ba84c@mail.gmail.com> <20061217205249.GA73132@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/17/06, Kris Kennaway <kris@obsecurity.org> wrote: > On Sun, Dec 17, 2006 at 11:46:24PM +0300, Andrew Pantyukhin wrote: > > I'm not sure what it's all about, but with today's > > current whatever goes out my vge interface (icmp/ > > tcp/udp) has bad checksum: > > This is a FAQ; it's probably using hardware checksum offloading. > > Since the packet passed down to the NIC does not yet have the checksum > computed, it looks to tcpdump like the checksum is incorrect. However > if you look at the packet actually transmitted by the NIC > (e.g. tcpdump on another host), you'll see that it has the correct > checksum. I wouldn't even notice the checksum issue if my ipsec connection to another host hadn't stop working. The host has ipsec(4) and a re(4) interface. dmesg on the box showed issues with AH checksums. The problem is whenever I run tcpdump (promiscuous or not) on re(4), the box (amd64 current) drops to kernel debugger with messages like: panic: mutex Giant not owned at /usr/src/sys/net/bpf.c:1399 But that's another story. So I guess my fast_ipsec/vge/checksum problem is either fast_ipsec or fast_ipsec+vge bound. Again, there was no problem with 20061210-current+ipsec+vge (not fast_ipsec).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb5206420612171308o4c8f2373g26986c5722e606e1>