r8168 fix completed but still can't ping

I’m still having confusing problems with my network connection after consulting other forum threads that I thought would fix the problem.

I just installed OpenSuSE 11.1 64bit on a motherboard with an onboard Realtech R8168b rev 2 gigabit connection.

I am able to get an ip address by dhcp and ifconfig eth0 seems to be ok but I can’t ping anything or get web traffic. This also happens for a pci nic card I tried.

I have installed the r8168 module downloaded from Realtech, blacklisted r8169 to fix the incorrect module issue. Now lsmod | grep r816 shows the correct result but I still have the same problem.

I have also turned off IPv6 in Yast.

I ran the lan cable check in my bios and it says its ok.

Any help would be much appreciated, I have exhausted my troubleshooting capabilities.

The output of these commands could be helpful:

/sbin/ifconfig
/sbin/route
cat /etc/resolv.conf

as requested

ifconfig


br0       Link encap:Ethernet  HWaddr 00:24:1D:D1:69:0D  
          inet addr:192.168.254.5  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:463 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:147212 (143.7 Kb)  TX bytes:4102 (4.0 Kb)

eth0      Link encap:Ethernet  HWaddr 00:24:1D:D1:69:0D  
          inet addr:192.168.254.5  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:517 errors:0 dropped:0 overruns:0 frame:0
          TX packets:237 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:168402 (164.4 Kb)  TX bytes:41829 (40.8 Kb)
          Interrupt:254 Base address:0x4000 

eth1      Link encap:Ethernet  HWaddr 00:50:04:BF:D2:9F  
          inet addr:192.168.0.104  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:21 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:62 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4028 (3.9 Kb)  TX bytes:4028 (3.9 Kb)

route


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
192.168.254.0   *               255.255.255.0   U     0      0        0 eth0
192.168.254.0   *               255.255.255.0   U     0      0        0 br0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.254.254 0.0.0.0         UG    0      0        0 eth0

/etc/resolv.conf


### /etc/resolv.conf file autogenerated by netconfig!
#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
#     NETCONFIG_DNS_STATIC_SEARCHLIST
#     NETCONFIG_DNS_STATIC_SERVERS
#     NETCONFIG_DNS_FORWARDER
# or disable DNS configuration updates via netconfig by setting:
#     NETCONFIG_DNS_POLICY=''
#
# See also the netconfig(8) manual page and other documentation.
#
# Note: Manual change of this file disables netconfig too, but
# may get lost when this file contains comments or empty lines
# only, the netconfig settings are same with settings in this
# file and in case of a "netconfig update -f" call.
#
### Please remove (at least) this line when you modify the file!
search rosemount domain.invalid
nameserver 192.168.254.254
nameserver 192.168.0.1

You read this so many times in several fora that “linux chose the wrong driver r8169 for a card which is called RTL8168”, this seems to be one of the Top 10 misconceptions at the moment.

Linux chooses the driver according to a (hopefully, if the vendor’s didn’t mess up) unique ID and not due to some fancy name.

Interestingly enough that on my system this “incorrect” driver works fine with the same card.

lspci -nnk |grep -A2 -i realtek
14:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller **10ec:8168**] (rev 02)
        **Kernel driver in use: r8169**
        Kernel modules: r8169, r8168

(Yes, there is also r8168 installed, BOTH drivers work with this card, r8168 is installed for testing reasons as I am maintaining r8168-packages in OBS).

And to prove that linux chose the right driver

/sbin/modinfo r8169

filename:       /lib/modules/2.6.27.29-0.1-default/kernel/drivers/net/r8169.ko
version:        2.3LK-NAPI
license:        GPL
description:    RealTek RTL-8169 Gigabit Ethernet driver
author:         Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
srcversion:     CE92D2502BBADA18B5F8C86
alias:          pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias:          pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias:          pci:v000016ECd00000116sv*sd*bc*sc*i*
alias:          pci:v00001259d0000C107sv*sd*bc*sc*i*
alias:          pci:v00001186d00004300sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008169sv*sd*bc*sc*i*
alias:          pci:v0000**10EC**d0000**8168**sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008167sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008136sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008129sv*sd*bc*sc*i*
depends:        mii
supported:      yes
vermagic:       2.6.27.29-0.1-default SMP mod_unload modversions
parm:           rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)

Of course a driver may have a bug and not work correctly with a device on certain constellations, but still the statement “r8169 is the incorrect driver” is an “incorrect statement”.

But be it as it may, with your setup no driver will work with any card as eth0.

  • Do you need that bridge br0?

  • If so, do you know that this bridge will then exclusively take over the network traffic and the physical interface (eth0) will no longer be available for “normal” network connections?

  • If you need the bridge and (now) know, that eth0 will then be no longer available for “normal” networking, why does eth0 still have an IP address? (and to make it even worse, the same one as br0)?

The best driver won’t help if the setup is incorrect.

Thank you for the detailed response. I will switch back to r8169.

As far as the bridge goes, I can only assume it was created during the suse install because of xen virtualization.

Also, the inability to ping was observed on eth1 even though that connection is not connected to the bridge.

Nevertheless, I removed the bridge and (still with r8168) it now works.

Again, thank you for the help.

Depends on what you actually tried to ping.

You certainly won’t be able to ping the “outside world” from both interfaces, assuming only one is connected to the outside world (aka “the internet”) and the other one is connected to some LAN (with another subnet).

With the routing table like in your first output, you would only be able to ping addresses in 192.168.0.0/24 (and of course localhost).

If you have two LANs, you will also have to look for correct routing, the routing table in your first output was a complete mess (at least partially as a result of the faulty configs of the eth0/br0 interfaces).

I had just tried pinging something on the lan at 192.168.0.107 from eth1.

While troubleshooting I had plugged eth0 into the different subnet. In the end use they’ll both be on 192.168.0.x

I guess if I end up trying to setup a virtual machine the I will have to deal with the bridge issues.

Not being UP at the same time I may hope.