Old Laptop, Failure to Connect

I have an old Dell XPS 1300 (x86_64-capable) laptop that came originally with Windows Vista pre-installed. Years ago I installed openSUSE alongside (I forget which version), double-boot. Last year I replaced Vista with Windows10 (which is slow, but it works); and last week I replaced openSUSE 13.2 with Leap 15.1, fresh install from DVD, still double-boot.

It’s all working, except for the onboard wired ethernet NIC under Leap 15.1. The wireless connection works fine, but the wired one doesn’t, even though NetworkManager tells me it’s “activated and connected”. While it might be activated, it isn’t connected.

According to hwinfo the NIC is a Marvell 88E8040 PCI-E Fast Ethernet Controller, driver Sky2. I’ve always assigned it the static address 192.168.0.30, and I’ve kept to that in Leap 15.1 using NetworkManager. It’s on a small local LAN in the 192.168.0.x segment, which connects via ip forwarding through a Raspberry Pi4 to a 192.168.1.x segment with a cable Internet connection at 192.168.1.254.

This arrangement works with other computers on the local wired LAN. It also worked with the laptop booted to oS 13.2 before I changed to Leap 15.1; and it still does with the laptop booted to Win 10. So it seems the problem can’t be hardware or cabling, but must be something else in Leap 15.1.

The laptop can ping its own wired NIC at 192.168.0.30. But pinging other computers on the same segment such as the RPi’s LAN-facing address 192.168.0.1 produces only “Destination Host Unreachable”. Nor is the laptop pingable from other computers on the LAN.

# Here’s the output of ip route list:     

 default via 192.168.0.1 dev eth0 proto static metric 20100  
 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.30 metric 100  
 
 # ip addr show eth0 returns this:
 
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
     link/ether 00:21:9b:f6:6f:c1 brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.30/24 brd 192.168.0.255 scope global noprefixroute eth0
        valid_lft forever preferred_lft forever
     inet6 fe80::4219:94f2:f6c9:877e/64 scope link noprefixroute  
        valid_lft forever preferred_lft forever
 
 # ….and here is cat /etc/sysconfig/network/ifcfg-eth0  
   
 BOOTPROTO='static'
 BROADCAST=''
 ETHTOOL_OPTIONS=''
 IFPLUGD_PRIORITY='0'
 IPADDR='192.168.0.30/24'
 MTU=''
 NAME='88E8040 PCI-E Fast Ethernet Controller'
 NETWORK=''
 REMOTE_IPADDR=''

 STARTMODE='auto'    

So, in summary, the laptop’s wired NIC accepts the address 192.168.0.30 in Win10 and Leap 15.1, and it works in Win10 but not in Leap 15.1. In the latter case NetworkManager says it’s activated, but it’s not connected; nor is it pingable other than from the laptop itself.

I can see nothing in the setup or the above code excerpts that says the configuration is wrong. I’ve tried it all with and without firewalld running; also with wicked instead of NetworkManager. Other Linux computers on the LAN are configured equivalently, and connect perfectly well. So does the laptop in Win 10 but not in Leap 15.1, so the problem can’t be hardware failure.

I’m flummoxed. Where do I look next? Anyone? Please?

If you’re using NetworkManager, then the /etc/sysconfig/network/ifcfg-eth0 configuration file is irrelevant. That’s only used when the wicked network management framework is in use. Instead, configure via the NetworkManager graphical front-end itself.

Here’s the openSUSE guide for NetworkManager…
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.nm.html

Thanks for the replies.

Thing is, I’ve done all that and still it doesn’t work - tells me it’s activated and connected when it isn’t. I also have other computers on the network using 15.1 and configured with NetworkManager where it does work, so it’s hard to see how the configuration(s) I have can be wrong.

Hi
Anything in dmesg/journalctl output about missing firmware for the network card? What driver is in use as it could be the driver that’s causing issues?


/sbin/lspci -nnk | grep -A3 Ethernet

Can you ping the gateway address ok?

journalctl has many references to sky2, but typically this as an extract:

Sep 22 15:56:34 Beagle kernel: sky2 0000:09:00.0 eth0: tx timeout
Sep 22 15:56:34 Beagle kernel: sky2 0000:09:00.0 eth0: transmit ring 40 .. 43 report=40 done=40
Sep 22 15:56:37 Beagle kernel: sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both
Sep 22 16:16:49 Beagle kernel: sky2 0000:09:00.0 eth0: tx timeout
Sep 22 16:16:49 Beagle kernel: sky2 0000:09:00.0 eth0: transmit ring 40 .. 43 report=40 done=40
Sep 22 16:16:53 Beagle kernel: sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both
Sep 22 16:41:35 Beagle kernel: sky2 0000:09:00.0 eth0: tx timeout
Sep 22 16:41:35 Beagle kernel: sky2 0000:09:00.0 eth0: transmit ring 42 .. 45 report=42 done=42
Sep 22 16:41:38 Beagle kernel: sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both
Sep 22 17:01:48 Beagle kernel: sky2 0000:09:00.0 eth0: tx timeout
Sep 22 17:01:48 Beagle kernel: sky2 0000:09:00.0 eth0: transmit ring 40 .. 43 report=40 done=40
Sep 22 17:01:52 Beagle kernel: sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both

and dmesg returns something similar like this:

10265.056060] sky2 0000:09:00.0 eth0: transmit ring 40 .. 43 report=40 done=40
[10268.414056] sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both
[11750.880024] sky2 0000:09:00.0 eth0: tx timeout
[11750.880034] sky2 0000:09:00.0 eth0: transmit ring 42 .. 45 report=42 done=42
[11754.238012] sky2 0000:09:00.0 eth0: Link is up at 100 Mbps, half duplex, flow control both

… but in each case when it says the link is “up”, it isn’t connected.

And here’s lspci:

robin@Beagle:~> /sbin/lspci -nnk | grep -A3 Ethernet
09:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller [11ab:4354] (rev 12)
        Subsystem: Dell Device [1028:022e]
        Kernel driver in use: sky2
        Kernel modules: sky2

The laptop will ping itself (192.168.0.30) OK, but all other targets return “Destination host unreachable”.

Open bug report. There are some other reports about similar issues with sky2 supported chipset in recent kernels. Like 199783 – NETDEV WATCHDOG: enp3s0 (sky2): transmit queue 0 timed out

The link negotiation status (100Mbps half-duplex) is problematic. It is often indicative of a hardware fault (cabling, terminations, or NIC-related), although in this case you state that it works in a Windows environment, so it might be due be a problem with the driver, or perhaps it’s configuration. Is your connection set to using ‘Allow auto-negotiation’ or have you explicitly set it?

Bingo! That fixed it. Thank you; I’m much obliged.

I hadn’t set it explicitly to half-duplex/100. I’d merely accepted the defaults on first setup, which were consistent with the settings in other computers on the LAN, so I didn’t think anything of it. How wrong can one be!

Thank you again.

Thanks for the update.

What is now reported by ethtool?

/usr/sbin/ethtool eth0
Settings for eth0:
        Supported ports:  TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pg
        Wake-on: d
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Addendum to all of this.

Having found that selecting auto negotiation rather than an explicit speed cured my laptop problem, I took a punt and also changed the NetworkManager profile in other computers on the LAN from the default’s explicit setting to auto negotiation.

I’m on a fibre connection to the Internet, nominally at 100Mbps. Before the change to auto negotiation the speed measured by an Ookla-based test was no more than 80Mbps or thereabouts. I’d vaguely thought the margin was likely due to firewall or similar processing losses. But, after the change to auto negotiation I get slightly more than 100Mbps, consistently. That’s an improvement of more than 20%.

I’ve no idea whether the improvement is related to the change in setting in pure technical terms, but it is co-incident in my case. If it is related, however, it invites the question why does NetworkManager offer explicit settings as the initial default, rather than auto negotiation?

NetworkManager default settings: 100 Mb/s, half duplex (for a 100 Mb/s and 1000 Mb/s hardware).

When NetworkManager is set to auto-negotiate:
with a 100 Mb/s - 100 Mb/s, full duplex
with a 1000 Mb/s - 1000 Mb/s, full duplex, jumbo frames.

I can suppose that with an extremely old hardware there is no support for an auto-negotiation protocol, and some network cards and cables have no support for a full duplex mode.

80 + 25% = 100.

Duplex mismatch