lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
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