Subject: kern/24310: hme is sometimes SIMPLEX, and bpf ends up with dups
To: None <gnats-bugs@gnats.netbsd.org>
From: None <gdt@ir.bbn.com>
List: netbsd-bugs
Date: 02/03/2004 12:13:10
>Number:         24310
>Category:       kern
>Synopsis:       hme is sometimes SIMPLEX, and bpf ends up with dups
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 03 17:14:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Greg Troxel
>Release:        NetBSD 1.6.1_STABLE
>Organization:
        Greg Troxel <gdt@ir.bbn.com>
>Environment:
	
	
System: netbsd-1-6 on sparc64 (ultra2)
Architecture: sparc64
Machine: sparc64
>Description:
On an ultra2 with hme, SIMPLEX should be set only in full duplex mode.
-current does this, but netbsd-1-6 does not.  This should be pulled
up.

When running tcpdump on an hme not in fdx, transmitted packets are
shown twice.  This is due to the packet being tapped on the way out
and also when received.

>How-To-Repeat:

Run a hme not in fdx.  Note that IPv6 DAD falsely triggers.  Run
tcpdump, and observe duplicate pacets 

>Fix:

Note that the first hunk is new, and the second is a pullup from
-current.
Because the driver sets SIMPLEX by default, applying the first patch
without the second will be a no-op.

The first hunk should apply to current reasonably, but I haven't
tried.

This was tested on an ultra2 with builtin hme0 and qfe; there were no
DAD complaints and tcpdump showed 1 packet for transmitted packets
rather than two.

Index: sys/dev/ic/hme.c
===================================================================
RCS file: /NETBSD-CVS/src/sys/dev/ic/hme.c,v
retrieving revision 1.29
diff -u -r1.29 hme.c
--- sys/dev/ic/hme.c	5 May 2002 03:02:38 -0000	1.29
+++ sys/dev/ic/hme.c	3 Feb 2004 17:03:59 -0000
@@ -824,9 +824,17 @@
 #if NBPFILTER > 0
 		/*
 		 * If BPF is listening on this interface, let it see the
-		 * packet before we commit it to the wire.
+		 * packet before we commit it to the wire.  But if SIMPLEX
+		 * is not set (e.g. in other than full duplex), the receiver
+		 * will see the packet, so don't tap it.
+		 *
+		 * XXX There is some chance that the packet will be
+		 * dropped by the receiver and not tapped.  A more
+		 * complicated solution would be to identify looped
+		 * packets at the receiver and not tap them.
 		 */
-		if (ifp->if_bpf)
+		if (ifp->if_bpf &&
+		    (sc->sc_ethercom.ec_if.if_flags & IFF_SIMPLEX))
 			bpf_mtap(ifp->if_bpf, m);
 #endif
 
@@ -1139,11 +1147,16 @@
 	bus_space_write_4(t, mif, HME_MIFI_CFG, v);
 
 	/* Set the MAC Full Duplex bit appropriately */
+	/* Apparently the hme chip is SIMPLEX if working in full duplex mode,
+	   but not otherwise. */
 	v = bus_space_read_4(t, mac, HME_MACI_TXCFG);
-	if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_FDX) != 0)
+	if ((IFM_OPTIONS(sc->sc_mii.mii_media_active) & IFM_FDX) != 0) {
 		v |= HME_MAC_TXCFG_FULLDPLX;
-	else
+		sc->sc_ethercom.ec_if.if_flags |= IFF_SIMPLEX;
+	} else {
 		v &= ~HME_MAC_TXCFG_FULLDPLX;
+		sc->sc_ethercom.ec_if.if_flags &= ~IFF_SIMPLEX;
+	}
 	bus_space_write_4(t, mac, HME_MACI_TXCFG, v);
 
 	/* If an external transceiver is selected, enable its MII drivers */

>Release-Note:
>Audit-Trail:
>Unformatted: