Date:	Thu, 26 Jul 2007 08:33:45 +0100
From:	Glen Gray <glen@...cor.com>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	netdev@...r.kernel.org
Subject: Multicast issues with RTL8110SC in r8169.c

Hey Francois,
I've CC'd the netdev list as requested

Francois Romieu wrote:
>> I'm in a particularly sticky situation in relation to the latest  
>> kernels and multicast. And I need some help to get out of it. I'm  
>> hoping with your combined experiences we might be able to solve my  
>> problems.
> 
> Multicast ? It could be worth to try 2.6.22 +
> http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
> 
> (same thing as a serie of patches at:
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628)
> 
> The patches are available in the current git kernel tree (and will thus
> appear in 2.6.23-rc1).
> 

I've applied that patch to the 2.6.22.1 kernel. I found a fedora source
rpm in the testing dir and modified it to apply your patch.

Unfortunately, this hasn't solved my problems. The tests mentioned below
where also carried out under this kernel with the same effect.

>> that for some reason dhcp wasn't working. After investigations back  
>> in our lab we realised that the hardware suppliers had changed the  
>> eth chip from the RTL8169S/8110S used in the initial run of units  
>> that we developed against to the RTL8169SC/8110SC without telling us.
> 
> Can you send a detailled output of mii-tool for both ? Just curious.
> 

Sure, but not sure what kind of info you'd like to see though, I'm new
to this side of things. Could you give me some examples of what would be
helpful ?
Here's some data from ethtool
[root@...note root]# uname -r
2.6.22.1-20.fc7

[root@...note root]# dmesg | grep eth
eth0: RTL8169sc/8110sc at 0xdc876000, 00:05:6b:40:2c:be, XID 18000000 IRQ 18
r8169: eth0: link up
r8169: eth0: link up

[root@...note root]# ethtool -i eth0
driver: r8169
version: 2.2LK-NAPI
firmware-version:
bus-info: 0000:00:0b.0

[root@...note root]# ethtool eth0
Settings for eth0:
          Supported ports: [ TP ]
          Supported link modes:   10baseT/Half 10baseT/Full
                                  100baseT/Half 100baseT/Full
                                  1000baseT/Full
          Supports auto-negotiation: Yes
          Advertised link modes:  10baseT/Half 10baseT/Full
                                  100baseT/Half 100baseT/Full
                                  1000baseT/Full
          Advertised auto-negotiation: Yes
          Speed: 100Mb/s
          Duplex: Full
          Port: Twisted Pair
          PHYAD: 0
          Transceiver: internal
          Auto-negotiation: on
          Supports Wake-on: pumbg
          Wake-on: g
          Current message level: 0x00000033 (51)
          Link detected: yes

[root@...note root]# ethtool -S eth0
NIC statistics:
       tx_packets: 2666
       rx_packets: 21498
       tx_errors: 0
       rx_errors: 0
       rx_missed: 0
       align_errors: 0
       tx_single_collisions: 0
       tx_multi_collisions: 0
       unicast: 20392
       broadcast: 579
       multicast: 536
       tx_aborted: 0
       tx_underrun: 0

>> I've frantically managed to upgrade the base distro to Fedora 7 with  
>> the stock 2.6.21 kernel in the hopes it would resolve our problems.  
>> DHCP now works correctly but I'm still having issues. Specifically  
>> with multicast.
> 
> FC7 with latest FC6 kernel may behave better. There are some issues
> with the last FC7 kernel and the r8169 driver.
> 
> However, you should really try the suggestion above first.
> 

I've managed to localise the problem a bit better. It looks like its
ethernet multicast that's the problem. We've setup some fixed playlist
items that use IP multicast addresses (what the SAP announcements are
providing) and they play fine. However, the ethernet multicast packets
are either being ignored or something else is wrong as the SAP messages
aren't getting back to the unit.

My colleague in our other office with an exterity iptv gateway captured
some data that I'm including here. I've replicated these tests also
using vlc as a simulated iptv gateway.

Attached are two files. One is a tcpdump from a machine on the same hub
showing the IGMPv2 messages getting sent to the multicast address and
then the subsequent data packets being routed from the iptv gateway
(192.168.3.4) to the unit. There's also a tcpdump from the unit where
you can see the IGMPv2 requests going out, but none of the data coming
back. The first file shows that the multicast session was setup
correctly, but for some reason the unit can't see it.

As mentioned in my original message, we have to force the igmp version
to 2 via the /proc/sys/net/ipv4/conf/eth0/force_igmp_version as it
defaults to V3 (as seen from /proc/net/igmp). The RTL8110S defaulted to V2.

Here is a dump of what the missing data packets look like

Frame 64 (324 bytes on wire, 324 bytes captured)
      Arrival Time: Jul 19, 2007 18:16:18.820712000
      [Time delta from previous captured frame: 1.020403000 seconds]
      [Time delta from previous displayed frame: 1.020403000 seconds]
      [Time since reference or first frame: 1184865378.820712000 seconds]
      Frame Number: 64
      Frame Length: 324 bytes
      Capture Length: 324 bytes
      [Frame is marked: False]
      [Protocols in frame: eth:ip:udp:sap:sdp]
Ethernet II, Src: AsustekC_51:f9:19 (00:0e:a6:51:f9:19), Dst:
01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
      Destination: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
          Address: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
          .... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast)
          .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
      Source: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
          Address: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
          .... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
          .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
      Type: IP (0x0800)
      Trailer: 8C0DFBE0
Internet Protocol, Src: 192.168.3.4 (192.168.3.4), Dst: 239.255.255.255
(239.255.255.255)
      Version: 4
      Header length: 20 bytes
      Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
          0000 00.. = Differentiated Services Codepoint: Default (0x00)
          .... ..0. = ECN-Capable Transport (ECT): 0
          .... ...0 = ECN-CE: 0
      Total Length: 306
      Identification: 0x0000 (0)
      Flags: 0x04 (Don't Fragment)
          0... = Reserved bit: Not set
          .1.. = Don't fragment: Set
          ..0. = More fragments: Not set
      Fragment offset: 0
      Time to live: 255
      Protocol: UDP (0x11)
      Header checksum: 0xc70e [correct]
          [Good: True]
          [Bad : False]
      Source: 192.168.3.4 (192.168.3.4)
      Destination: 239.255.255.255 (239.255.255.255)

Kind Regards
-- 
Glen Gray <glen@...cor.com>              Digital Depot, Thomas Street
Senior Software Engineer                            Dublin 8, Ireland
Lincor Solutions Ltd.                          Ph: +353 (0) 1 4893682


View attachment "newonwire.txt" of type "text/plain" (4998 bytes)

View attachment "newonstb.txt" of type "text/plain" (4534 bytes)

Powered by blists - more mailing lists