Can't connect to onboard LAN (SOLVED)

There will be a setting in the BIOS somewhere to clear the DMI data … select that, and it will be re configured and stored on next boot.

Probably (but not necessarily) somewhere under the PnP/PCI Configuration sub menu.

a) I want you to reboot ,, then send the output from: Code: [Select] lsmod | grep r8169

What NIC do you want me connected to onboard or PCI ?

run both BEFORE and after running Code: [Select] sudo modprobe r8169

Sorry I’m not sure what you mean by “run both” ?

Graeme

Is it possible that the onboard network adapter gets detected, but ignored by OMV in favour of the pci one.
You could check dmesg:

dmesg | grep eth

then

ip link

Thanks SeZo

Can I carry out these commands while connected to the PCI card if so I can SSH in and copy and paste outputs ?

Many thanks

Graeme

Yes. It will just print out the results to the query.

All these commands were carried out immediately after reboot

root@openmediavault:~# lsmod | grep r8169
r8169                  41077  0 
mii                    12595  3 8139too,8139cp,r8169
root@openmediavault:~# sudo modprobe r8169
root@openmediavault:~# dmesg | grep eth
[    0.851331] r8169 0000:05:00.0: eth0: RTL8168b/8111b at 0xf800e000, 00:1a:4d:5f:86:d4, XID 18000000 IRQ 45
[    0.851334] r8169 0000:05:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
[    0.926847] 8139too 0000:06:00.0: eth1: RealTek RTL8139 at 0xd000, 00:e0:4c:39:22:53, IRQ 20
[    8.216595] udev[442]: renamed network interface eth0 to eth0-eth1
[    8.217001] udev[447]: renamed network interface eth1 to eth0
[    8.267036] udev[442]: renamed network interface eth0-eth1 to eth1
[   19.077228] 8139too 0000:06:00.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[   19.252069] r8169 0000:05:00.0: eth1: link down
[   19.252604] ADDRCONF(NETDEV_UP): eth1: link is not ready
root@openmediavault:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:1a:4d:5f:86:d4 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:4c:39:22:53 brd ff:ff:ff:ff:ff:ff
root@openmediavault:~# 
[ 0.851331] [b]r8169[/b] 0000:05:00.0: eth0: RTL8168b/8111b at 0xf800e000, 00:1a:4d:5f:86:d4, XID 18000000 IRQ 45 [ 0.926847] 8139too 0000:06:00.0: eth1: RealTek RTL8139 at 0xd000, 00:e0:4c:39:22:53, IRQ 20

It appears that your onboard NIC is detected as eth0 (first line) and the pci addon card is as eth1 (second line)
Then it proceeds to swap them and uses eth1 as eth0 ???

Try bringing the onboard NIC (now eth1) back up again:

ip link set eth1 up

check it:

ip addr show

then try to ping google dns via that interface:

ping -c 3 -I eth1 8.8.8.8

I can’t carry out the ping command because when I connect up the onboard interface I lose connection

That is a bummer. Have you got a network switch so that you can plug both in?

That is a bummer. Have you got a network switch so that you can plug both in?

Yes i think I have one in the attic but I can’t rig it up tonight I can try that tomorrow, but I tried directly at the NAS shell (no ssh)

ping -c 5 8.8.8.8 and it returned 5 packets transmitted, 5 recieved, 0% packet loss but I still can’t connect to the web gui, ssh or any of the shares

but I tried directlt at the NAS shell (no ssh)

I take it that you have a monitor connected to the NAS?
If so then you could try to run those commands in the NAS shell and see what it comes back with.
All I am trying to ascertain at this point is that the on-board NIC is working OK.
Once that is established then it is certain that some configuration in OMV is preventing the use of this interface.
Perhaps some sort of binding.

What SeZo wants you to do is connect only the ONBOARD ethernet adapter to your network (router) and post the output from:

ping -c 3 -I eth1 8.8.8.8

or
ping -c 3 -I eth1 <ip.of.your.router>

but the command MUST contain the “-I eth1” … otherwise it will default to eth0

Because it looks like BOTH adapters are working … but for some reason udev is swapping their designations.


I agree with him … it looks like both are active, but the onboard is being reassigned as eth1, yet OMV is set to use eth0

The designations are probably being reassigned by something in /etc/udev/rules.d/70-persistent-net.rules or similarly named udev rules file.

So can you also post the output from:

ls -a /etc/udev/rules.d

and if there’s a file called nn-persistent-net.rules listed in te output, post it’s contents.

I take it that you have a monitor connected to the NAS?

Yes I have a monitor & keyboard connected I can also log in via SSH from my PC (but obviously only if I have a network connection)

All I am trying to ascertain at this point is that the on-board NIC is working OK.

I can confirm that the NIC is working ok because I can connect to the network in a live session (Lubuntu 12.04)

Once that is established then it is certain that some configuration in OMV is preventing the use of this interface.

That’s certainly what it looks like because when it’s connected and I try to connect to anything it’s showing activity but it just wont connect

ping -c 3 -I eth1 8.8.8.8

3 packets transmitted, 3 recieved, 0% packet loss

ls -a /etc/udev/rules.d

70-persistent-cd.rules 99-openmediavault-md-raid.rules 99-openmediavault-scheduler,rules
70-persistent-net.rules 99-openmediavault-nonrot.rules z60_hdparm.rules

I’m not sure if this is relevant but this showed up during a OMV update

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169

Is this any help ?

root@openmediavault:~# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:39:22:53", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:4d:5f:86:d4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
root@openmediavault:~# 

Many thanks

Graeme

First try installing nthe firmware:

sudo apt-get install linux-firmware

Then try swapping those entries in 70-persistent-net.rules over (both in order, and the eth(n) … so it reads:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:4d:5f:86:d4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:39:22:53", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Then REBOOTING with the ethernet cable plugged into the onboard adapter.

root@openmediavault:~# sudo apt-get install linux-firmware
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package linux-firmware
root@openmediavault:~# 

To tell the truth I’m not that bothered about the firmware … it appears to be working without any.

Just carry on without the firmware.

As OMV is based on Debian try this:

sudo apt-get install firmware-linux

But as Mark pointed out - it is working so why bother?

Sorted :slight_smile:

Changing the order in the 70-persistent-net.rules file did the trick (once I figured how to copy & paste in Nano)

however if you think you’ve heard the last of my NAS problems you’d be mistaken but I’ll mark this one solved meantime :wink:

Can’t thank you guys enough

Graeme

For my part … you’re welcome :slight_smile: