Ethernet ports not functioning x86

Installing and Using OpenWrt
1

Hello,

I'm having an issue with hardware not seeming to function /be detected in OpenWRT. I'm using a Fujitsu Futro S920 (2ghz model) and a HP NC360t dual port pcie adapter.

The issue began when I could not get the expansion card to be listed in Network - devices in openWRT. I began by installing the kmod e-1000 and e-1000e packages as I assumed it would be a driver issue.

Howver the issue turned out to be that I had jostled the pcie riser and unseated the card in the case.

However, upon reboot none of the ports, including the motherboard port I was using to connect to my pc seem to accept a connection. I know that the ports all function physically as a live USB of finnix was able to ping google through all of them. However none seem to work at all anymore in openwrt. I cannot ssh in or use luci in the current state, but I can use the terminal on a keyboard connected to the device.

Any advice on how to get past this?

2

Since you used a live CD, I'm assuming you have a monitor and keyboard hooked up. Any errors in dmesg about hardware being recognised improperly? I believe those Intel gigabit drivers should be installed by default. But dmesg hopefully tells you more.

3

I would start by reinstalling OpenWrt from scratch. If this doesn't result in a system with at least one working Ethernet port, the course of action would depend on whether the impaired system has USB connectivity.

If you have USB, you can download the missing required packages to your computer, put them onto a USB stick, and then install them onto your OpenWrt box from the USB stick.

If you don't have USB, you'd have to go one more step back and put the missing required packages onto your boot media before you boot from it. Once you boot, install the packages from where they are on your boot media.

The big question is, what are these "missing required packages" I keep talking about? There may be shortcuts to what I am about to tell you, but I don't know them; someone else may.

Let's say we know nothing about the underlying system. In this case, we need the pciutils package. After we install it, we can use the lspci utility to see what PCI devices we have on the machine. After you install pciutils, execute this:

lspci -nn

If the output is too big and you don't feel like sifting through it manually, limit it to what concerns networking:

lspci -nn | grep Ethernet

This will give you the names and PCI identifiers of your Ethernet devices. A PCI identifier as reported by lspci consists of two four-digit hexadecimal numbers separated by a colon. Let's pretend that you found that the PCI identifier for your HP card is 1234:cdef. You can go straight to any Linux hardware database and see if a driver for this hardware exists. For example, you can see if folks at Hardware for Linux have heard of it:

https://linux-hardware.org/index.php?id=pci:1234-cdef

Let's say they have, and they tell you that they've seen two drivers for this card in the wild. One is called hpnic.c, the other, 360t.c. With this information, you go back to the full list of OpenWrt packages and see if OpenWrt has packages named kmod-hpnic or kmod-360t. If one or both exist, you check the descriptions to verify that those are indeed drivers for your card. If this is the case, you install the package of your choice, and your Ethernet card should be working immediately.

This is the best-case scenario. But there's also the not-so-good case scenario: the card is known in the broader Linux world (say, there's an Arch driver and a SUSE driver), but there is no implementation of the driver for OpenWrt. This potentially leaves you in a position to compile your own driver, which requires skills that I personally do not possess. And then, there's the worst-case scenario: no one in the Linux world has heard about this card, or people have heard about it and know that HP developed it strictly for use with Windows Server and/or HP-UX and open-source drivers for it do not exist.

Hope this helps.

1 Like
4

Hi, thanks for both replies. I'm only able to concentrate on it now and I haven't completed all the advice given but I thought I'd give some updates on where I'm at. Still quite puzzled by the symptoms.

I have reinstalled the legacy ext4 image, and reset my bios to factory default settings just in case. It now seems that in openwrt, no ports are currently functioning? One of the two expansion card ports seems to output intermittent signal- I can see it in Windows adapter settings, coming up as an unidentified network, then dropping the signal again. (Maybe an issue with total power draw to the system? This is a thin client pc.)

This may be a configuration issue in devices or interfaces though, I'm at a very low level of proficiency with openwrt in general. I tried to associate the eth1 port with br-lan to see if that would help- probably a foolish step as I didnt fully understand what I was doing. If anyone knows a way to reset this to default I can do it, or just fresh install again.

Dmesg, after a fresh boot, gives the following output. https://imgur.com/a/ZkUHgFK

I'll be running through NC1's advice today.

5

"legacy" is for very old CPUs e.g. Pentium 2. I think you want x86-64 non EFI.

6

Apologies that's what I meant. Non efi.

7

try put out hp nic and check motherobard lan working, if yes - your hp card is broken and push whole pcie to "L-DOWN" state, drivers for that HP NIC is integrated in x86 openwrt build, i can 100% say that becuse im also x86 user. It uses an 82571EB chip. If you 100% sure your card is working - something else is broken, not openwrt but hardware.

otherwise try to use ubuntu (from usb stick, live ...etc.) and check it hardware or software issue, if it would NOT live in ubuntu, means 99.999% chance hp card or whole computer is broken.

1 Like
8

Fujitsu Futro S920 is, if memory serves, a full 64-bit system. You should probably go with 64 firmware, rather than legacy firmware. Even if it were a 32-bit system, generic would be more appropriate...

Back to the matter at hand, on x86, this is quite normal. Remember, OpenWrt was originally intended for systems with a limited system device set exhaustively known in advance. x86 is anything but that.

I've had exactly the same problem installing OpenWrt on a Watchguard Firebox router. Let me explain what I did; you can follow this script; just keep substituting my data for those applicable to your case.

First, I examined he system with lspci:

lspci -nn

or, to make it more networking-specific,

lspci -nn | grep Ethernet

Initially, I was unsuccessful because lspci was not found on the system. So I had to go online using my computer, download the package file for pciutils, copy it onto the boot media for the router, and install it locally. This made lspci available. If you have a working USB port, you don't need to mess around with boot media; just bring the package over on a USB stick.

When I ran lspci as descbibed above, the output included these useful morsels of data:

Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 19)

Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller [11ab:4320] (rev 13)

The first appears to refer to a four-port PCI expansion card, the second, to the four-port Ethernet controller integrated into the motherboard.

Next, finding drivers. Let's start with the controller on the motherboard. Its PCI identifier is 11ab:4320, so let's see if Hardware for Linux has anything on it:

https://linux-hardware.org/index.php?id=pci:11ab-4320

Indeed it does; there's a driver called skge. Now, check the list of OpenWrt packages: does a package called kmod-skge (translation: a kernel module for skge) exist? Yes, it does:

https://openwrt.org/packages/pkgdata/kmod-skge

It is described as "SysKonnect Yukon support". When you Google "SysKonnect Yukon", you see that it is a family of network interface cards (NICs) made by Marvell. Everything checks out, so do as you did with pciutils: download the package, put it onto the router's boot media (or use USB media if you can), boot, install locally. Now you have one working NIC. Configure it for Internet access and let's keep on digging; we have a whole other NIC that's dead.

The PCI identifier for the currently-dead NIC is 11ab:4362. Let's check Hardware for Linux:

https://linux-hardware.org/index.php?id=pci:11ab-4362

Success; there is a driver, it's called sky2. Next, does the package kmod-sky2 exist on OpenWrt? It does:

https://openwrt.org/packages/pkgdata/kmod-sky2

This time, the package description explicitly mentions our NIC (88E8053), so no further verification is needed. Also, we already have an Internet connection, so we can install the driver the normal way:

opkg update
opkg install kmod-sky2

The end result: two working NICs on an x86 system.

This is more or less what you need to do on your system. It's a repeating script: (1) identify NIC, (2) find the driver for it, (3) install the driver. The worst-case scenario would be if the driver for your NIC didn't exist, but we don't know that yet. So take a stab at it as described above and post your progress here...

9

Note that in Eric12's case, it's not just the HP network card that doesn't work; the built-in single Ethernet port on the motherboard isn't working, either.

Fujitsu_Futro
Fujitsu_Futro800×600 53.7 KB

So I still suspect we have a case of missing drivers... But if you are correct and the problem is in hardware, this should still be discernible through lspci; the problem devices won't be identified. Or will they?

10

I ran the r lspci command in a live usb on the same hardware, and got this. I assume it's not an issue as it's just about detected hardware? I'm habing trouble loading packages from usb.

As you can see at the end it seems like all the hardware is being detected. I presume the two Intel Gigabit lines refer to the HP card, I know it uses an intel chip. Theres the intel wifi card I've included at the end, which I assume means the realtek is the integrated ethernet controller.

11

So... I followed Nick's instructions above re: drivers. It seems thats definitely not the issue- kmod-e1000 and kmod-r8169 are both installed. Could this be a more basic issue in how ive configured interfaces?

12

Ok! So not sure why but I've got a signal through the expansion card now. Unidentified network connection to my pc through ethernet.

Only issue is there's no default gateway when i use ipconfig in cmd. Ive used uci set network.lan.ipaddr to change the address off 192.168.1.1, and done service network restart. What would be the next step to be able to use luci?

https://imgur.com/a/grKL11E

13

Open a browser? If you installed a development image, stick with a stable release, those have LuCI included.

14

I would assume in this case I would need to see a default gateway to connect to luci. At least that's been the case in the past. The assigned local address is unreachable in browser

15

Does outgoing ping work, from OpenWrt? If basic connectivity doesn't work then LuCI won't either.

16

Yes, outgoing ping works

17

Ah, so. I think ive managed to stumble into relative success. I failed to try the other port on the expansion card, and it had a valid lan signal with gateway. The rest of the issie was solved by associating the two other ports with br-lan. Thanks to everyone who contributed, even if I probably dragged this out to exhaustion :sweat_smile:

1 Like
18

On first booting OpenWrt on an x86 with more than one usable Ethernet port, the first detected Ethernet port (typically but not always the one on the motherboard) will be wan, and the second one will be lan. Any additional ports will be unassigned and inactive in the default configuration.

Some e1000e chips have a bug which causes a firmware crash and the connection will randomly drop for a few seconds. This can be worked around by running ethtool once after boot to turn off TCP optimization:
ethtool -K eth0 tso off
Place this line in /etc/rc.local, one such line for each affected port.

2 Likes
19

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.