ipv6 mcast trouble with Broadcom NetXtreme II BCM5708

hello,

At my test system I have installed NetBSD 4.0_RC5 amd64.

After startup the interface doesn't get an ipv6 address via stateless 
address config. tcpdump (no promisc mode) shows only ipv6 unicast packets 
but no ipv6 multicast packets like router advertisements.

If you switch the interface to the promisc mode, everything works well. 
tcpdump shows all packets and the stateless address config works fine.

The problem occurs only with Broadcom NIC's but not with INTEL NIC's

Any ideas?
Uwe

Re: ipv6 mcast trouble with Broadcom NetXtreme II BCM5708

On Tue, Dec 04, 2007 at 12:15:59AM +0100, 6bone <at> 6bone.informatik.uni-leipzig.de wrote:
> hello,
> 
> At my test system I have installed NetBSD 4.0_RC5 amd64.
> 
> After startup the interface doesn't get an ipv6 address via stateless 
> address config. tcpdump (no promisc mode) shows only ipv6 unicast packets 
> but no ipv6 multicast packets like router advertisements.
> 
> If you switch the interface to the promisc mode, everything works well. 
> tcpdump shows all packets and the stateless address config works fine.
> 
> The problem occurs only with Broadcom NIC's but not with INTEL NIC's

Is the product supported by bnx(4) ?  It looks to me like bnx_ioctl()
does not implement SIOCADDMULTI / SIOCDELMULTI properly.  I have attached
a patch that I have only compile-tested.

(I believe that a Dell server that I ordered has this same ethernet,
so I hope that the driver works!)

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933 ext 24

Index: if_bnx.c
===================================================================

Re: ipv6 mcast trouble with Broadcom NetXtreme II BCM5708

On Mon, Dec 03, 2007 at 05:29:53PM -0600, David Young wrote:
> Is the product supported by bnx(4) ?  It looks to me like bnx_ioctl()
> does not implement SIOCADDMULTI / SIOCDELMULTI properly.  I have attached
> a patch that I have only compile-tested.
> 
> (I believe that a Dell server that I ordered has this same ethernet,
> so I hope that the driver works!)

Oops.  This patch will work better.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933 ext 24

Index: if_bnx.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.10
diff -p -u -u -p -r1.10 if_bnx.c
--- if_bnx.c	9 Nov 2007 08:26:47 -0000	1.10
+++ if_bnx.c	3 Dec 2007 23:37:43 -0000
 <at>  <at>  -4420,12 +4420,13  <at>  <at>  bnx_ioctl(struct ifnet *ifp, u_long comm

 	default:
 		error = ether_ioctl(ifp, command, data);
-		if (error == ENETRESET) {
-#if 0

Re: ipv6 mcast trouble with Broadcom NetXtreme II BCM5708

6bone <at> 6bone.informatik.uni-leipzig.de wrote:

> The problem occurs only with Broadcom NIC's but not with INTEL NIC's

I have the same problem:

http://mail-index.netbsd.org/current-users/2007/11/12/0007.html

Martti

Re: ipv6 mcast trouble with Broadcom NetXtreme II BCM5708

David Young wrote:
> On Mon, Dec 03, 2007 at 05:29:53PM -0600, David Young wrote:
>> Is the product supported by bnx(4) ?  It looks to me like bnx_ioctl()
>> does not implement SIOCADDMULTI / SIOCDELMULTI properly.  I have attached
>> a patch that I have only compile-tested.
>
> Oops.  This patch will work better.

I installed this on my NetBSD/amd64 4.0_RC5 and it works! So please commit it 
and send a pullup request for netbsd-4 as soon as possible (although I'm happy 
if this appears after 4.0 release).

Martti

A question about the IP header checksum

Hello IP Gurus,

I have a question about the IP header checksum that I'm looking for a
definitive answer for.  I'm pretty sure I have the answer, but if anyone 
can help me substantiate my answer, it would really help.

The IP header checksum is pretty straightforward: add up all the (2 byte)
words in the IP header using one's complement addition, then take the one's
complement of the sum and insert that as the checksum.  Here's the question:

    Is it proper to substitute a resulting value of 0x0000 with 0xffff as 
    is done in UDP?

UDP explicitly defines 0x0000 as "checksum disabled", and so specifies that
a computed result of 0x0000 should be replaced with 0xffff.  TCP and IP do 
not state anything more than "take the one's complement of the one's 
complement sum of the words...".  

What do you think?

Thanks,

Patrick Klos
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos                           Email: patrick <at> klos.com
    Network/Embedded Software Engineer     Web:   http://www.klos.com/
    Klos Technologies, Inc.                Phone: 603-714-0195
============================================================================

gigabit "benchmark"

Hi,

while searching for something different I stumbled across this
comparison using, among others, NetBSD/i386 4.0RC3

  http://www.bluelife.at/articles/98/

IMO you can ignore the German text, the table below "Hardware" speaks for
itself.

Can anyone repeat those results for NetBSD?
Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
NICs as the others do and at the same time needs 100% CPU?

ciao
     Klaus

Re: A question about the IP header checksum

> The IP header checksum is pretty straightforward: [...]  Here's the
> question: Is it proper to substitute a resulting value of 0x0000 with
> 0xffff as is done in UDP?

I can't see anything wrong with it.

I doubt it's necessary, but I have trouble seeing it causing trouble.

But I'm not an IP guru, so....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: gigabit "benchmark"

On Wed, Dec 05, 2007 at 09:56:27PM +0100, Klaus Heinz wrote:
> Hi,
> 
> while searching for something different I stumbled across this
> comparison using, among others, NetBSD/i386 4.0RC3
> 
>   http://www.bluelife.at/articles/98/
> 
> IMO you can ignore the German text, the table below "Hardware" speaks for
> itself.
> 
> Can anyone repeat those results for NetBSD?
> Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
> NICs as the others do and at the same time needs 100% CPU?

Maybe em enables hardware checkums automatically, while on wm it needs to
be turned on explicitely ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Re: gigabit "benchmark"

On Wed, 5 Dec 2007, Klaus Heinz wrote:
> Any opinions why NetBSD does not reach (near-) wirespeed with those Intel
> NICs as the others do and at the same time needs 100% CPU?

TCP buffers too small, and other values not tuned, see [1]? Though IIRC 
there was something about auto-tuning those buffers, but I don't know if 
that's enabled by default (or how to enable it if not).

[1] http://proj.sunet.se/LSR2/

  - Hubert