netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* multicast problems in forcedeth driver with MCP51 Ethernet Controller
@ 2008-03-16 22:56 Hans-Peter Jansen
  2008-03-17 22:32 ` Hans-Peter Jansen
  0 siblings, 1 reply; 2+ messages in thread
From: Hans-Peter Jansen @ 2008-03-16 22:56 UTC (permalink / raw)
  To: Ayaz Abdulla; +Cc: netdev

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

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.

TIA,
Pete

[-- Attachment #2: mctest.py --]
[-- Type: application/x-python, Size: 1042 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: multicast problems in forcedeth driver with MCP51 Ethernet Controller
  2008-03-16 22:56 multicast problems in forcedeth driver with MCP51 Ethernet Controller Hans-Peter Jansen
@ 2008-03-17 22:32 ` Hans-Peter Jansen
  0 siblings, 0 replies; 2+ messages in thread
From: Hans-Peter Jansen @ 2008-03-17 22:32 UTC (permalink / raw)
  To: Ayaz Abdulla; +Cc: netdev

[-- Attachment #1: Type: text/plain, Size: 3601 bytes --]

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

[-- Attachment #2: mctest.py --]
[-- Type: application/x-python, Size: 2693 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-03-17 22:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-16 22:56 multicast problems in forcedeth driver with MCP51 Ethernet Controller Hans-Peter Jansen
2008-03-17 22:32 ` Hans-Peter Jansen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).