Message-Id: <200803172332.17734.hpj@urpla.net>
Date:	Mon, 17 Mar 2008 23:32:17 +0100
From:	Hans-Peter Jansen <hpj@...la.net>
To:	Ayaz Abdulla <aabdulla@...dia.com>
Cc:	netdev@...r.kernel.org
Subject: Re: multicast problems in forcedeth driver with MCP51 Ethernet Controller

Am Sonntag, 16. März 2008 schrieb Hans-Peter Jansen:
> Hi Ayaz, hi forcedeth hackers,
>
> I'm trying to get my first multicast application to life ATM, but even
> the first tests failed mysteriously for some systems, running a 2.6.24.3
> kernel. Goggling around let me to one of your fixes:
> [PATCH 5/5] forcedeth: multicast fix, which Linus applied before
> 2.6.25-rc1 as: bb9a4fd1f7cc083f72e52f01938c23ac5b3403d5
>
> I applied your patch to my local 2.6.24.3 kernel build, but still no go.
> Try attached python script (after setting up a route like this):
>
> Destination     Gateway        Genmask         Flags Metric Ref   Use 
> Iface 229.0.0.0       *              255.0.0.0       U     0      0      
>  0 eth0
>
> Run one instance as './mctest.py server' and others without arguments.
> Normally, the server sends out a multicast packet every second, and the
> clients catch 10 of those before quitting, unless such a MCP51 Ethernet
> Controller is in the equation: that one doesn't send/receive a single MC
> bit here... Other nics (well, I tested this on e1000s and another MCP55)
> behave well in this respect.
>
> If I make the MCP51 the server, tcpdump is able to fetch the packets, but
> nothing is received on the other systems. Looks, like multicasting is
> still broken for the NIC in question.
>
> Here's the complete hwinfo for the affected NIC:
> ~# hwinfo --netcards
> 15: PCI 14.0: 0200 Ethernet controller
>   [Created at pci.286]
>   UDI: /org/freedesktop/Hal/devices/pci_10de_269
>   Unique ID: MZfG.uQ5k42VxsiA
>   SysFS ID: /devices/pci0000:00/0000:00:14.0
>   SysFS BusID: 0000:00:14.0
>   Hardware Class: network
>   Model: "ASUSTeK MCP51 Ethernet Controller"
>   Vendor: pci 0x10de "nVidia Corporation"
>   Device: pci 0x0269 "MCP51 Ethernet Controller"
>   SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
>   SubDevice: pci 0x816a
>   Revision: 0xa3
>   Driver: "forcedeth"
>   Driver Modules: "forcedeth"
>   Memory Range: 0xfe02b000-0xfe02bfff (rw,non-prefetchable)
>   I/O Ports: 0xc800-0xc807 (rw)
>   IRQ: 18 (309189603 events)
>   Module Alias: "pci:v000010DEd00000269sv00001043sd0000816Abc06sc80i00"
>   Driver Info #0:
>     Driver Status: forcedeth is active
>     Driver Activation Cmd: "modprobe forcedeth"
>   Config Status: cfg=no, avail=yes, need=no, active=unknown
>
> Board: ASUS M2NPV-VM ACPI BIOS Revision 0603
> Distr: openSUSE 10.2
>
> Ideas, patches, workarounds are heightly appreciated.

Okay, I've read the multicast howto again, inquired on linux-net about my 
procedures, and did more tests. 

In my environment, it seems to not matter, what multicast routing I use:
route add -net 224.0.0.0/4 dev eth0
ip route add 224.0.0.0/4 dev eth0
ip route add multicast 224.0.0.0/4 dev eth0

On those systems, that work fine, it does without, and on those, that don't, 
it doesn't change behavior (nothing is send/received), _unless_ I use 
224.0.0.1 as the multicast group address, which should be avoided, AFAICS.

I've learned to look for the group membership, and while the test program 
runs, it looks fine:

~# LANG=C netstat -gn
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      232.1.1.1	    <-- new mc group address default
eth0            1      224.0.0.1
lo              1      ff02::1
eth0            1      ff02::1:ff24:683c
eth0            1      ff02::1

Below, you find the updated/cleaned up version of my test script.

Still busted,
Pete

Download attachment "mctest.py" of type "application/x-python" (2694 bytes)

Powered by blists - more mailing lists