NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/40684: 're' driver corrupts IPv6 packets on output.



>Number:         40684
>Category:       kern
>Synopsis:       're' driver corrupts IPv6 packets on output.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 18 23:40:00 +0000 2009
>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@localhost:/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.



Home | Main Index | Thread Index | Old Index