Message-ID: <469FA417.8010207@lincor.com>
Date:	Thu, 19 Jul 2007 18:49:11 +0100
From:	Glen Gray <glen@...cor.com>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	edward_hsu@...ltek.com.tw, netdev@...r.kernel.org
Subject: Re: Status of RTL8110SC in vanilla r8169.c

Hey Francois,
I've CC'd the netdev list as requested, however, I'm not signed up to 
this list so please include my email address directly in any replies. Thanks

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" (4997 bytes)

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

Powered by blists - more mailing lists