NetBSD Problem Report #40684

From tls@panix.com  Wed Feb 18 23:36:35 2009
Return-Path: <tls@panix.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 890AE63B8C3
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 18 Feb 2009 23:36:35 +0000 (UTC)
Message-Id: <20090218233634.1800424215@panix5.panix.com>
Date: Wed, 18 Feb 2009 18:36:34 -0500 (EST)
From: tls@NetBSD.ORG
To: gnats-bugs@gnats.NetBSD.org
Subject: 're' driver corrupts IPv6 packets on output.
X-Send-Pr-Version: 3.95

>Number:         40684
>Category:       kern
>Synopsis:       're' driver corrupts IPv6 packets on output.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 18 23:40:00 +0000 2009
>Closed-Date:    
>Last-Modified:  Sat May 19 10:29:45 +0000 2018
>Originator:     Thor Lancelot Simon
>Release:        NetBSD 5.0_RC2
>Organization:
Not much.
>Environment:
System: NetBSD hotpoint.hvg.tjls.com 5.0_RC2 NetBSD 5.0_RC2 (SCREAMER) #0: Wed Feb 18 10:49:56 EST 2009 root@tls-nb5.localdomain:/usr/src/sys/arch/i386/compile/SCREAMER i386
Architecture: i386
Machine: i386
>Description:
	A realtek 8110SC on a Jetway motherboard with VIA C7 processor,
	was observed to produce damaged IPv6 frames on output about 50%
	of the time, though the frames are intact at the bpf tap point
	for this interface (tcpdump -i re0 -vvvv -l -e icmp6 shows
	good icmp6 checksums on output frames, but tcpdump at the far
	end of the network cable shows bad icmp6 checksums on approximately
	every other frame).

	The problem may only -- somehow! -- impact forwarded frames, or
	frames with certain upper-layer protocols; router solicitations
	and advertistements appear to work correctly on this interface.

	It was hypothesized that there might be some problem with the
	mbuf chains being produced by the gif driver, which is used
	for ipv6 uplink on this host, such that forwarded ICMP6 packets were
	damaged by 're' on transmit, though locally generated frames were
	fine.  This appears to not be the case: replacing the 're' card
	with a 'bge' caused everything to work normally.

	The re interface in question does not appear to damage ipv4
	frames under any circumstances.

	Neither checksum nor segmentation offload was enabled on any
	interface on the system.

>How-To-Repeat:
	Try to ping ftp6.netbsd.org through a system with a rtl8110SC
	ethernet interface on the side facing the host sending the ICMP6
	echo request packets.  Observe that tcpdump on the gateway system
	shows undamaged icmp6 echo reply packets on the realtek interface
	but that they actually exit that interface onto the wire with bad
	icmp6 checksums.

	Flail around.  Curse Realtek.  Rebuild your home network.  Take
	a deep breath and have a beer and some chocolate chip cookies.
>Fix:
	Realtek's product page for the newer members of the 81xx family
	lists TCPv6 and UDPv6 checksum and segmentation offload as a
	feature.  This is only explicitly listed for the PCIe 8102
	and 8111, but may be present on the newest PCI-X chips such as
	the 8110SC as well.  If it is, perhaps it somehow damaging IPv6
	packets even though we have done nothing to configure it, since
	we do not know how.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Sat, 19 May 2018 10:29:45 +0000
State-Changed-Why:
Does it still happen? A lot of things have changed since...


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.