All LAN ports suddenly stopped working

Hi, I've been using OpenWrt, then LEDE, and now OpenWrt again for many years, and it's been awesome. Something strange happened recently, though, and I'm stuck on how to fix it.

Yesterday, all the LAN ports suddenly stopped working on my TP-Link Archer C7 v2. The connected computers can't acquire an IP address. WiFi works totally fine. The ethernet lights on the front of the router do show when a cable is connected, and LuCi's Switch page shows "1000baseT full-duplex" for the computers that are connected. I haven't made any configuration changes in months. I tried a brand new Cat 6 cable between the router and one computer, just in case the cats gnawed through the old ones, but that made no difference, even when it was the only one connected.

Can anyone suggest how to determine if the LAN ports just died, or if it's a software thing? Today I upgraded to OpenWrt 18.06.2 from 18.06.1 just in case there was a bug that got fixed, but no change.

I'd sure appreciate any help you guys could provide. Thanks!

What does

ip link | egrep '^[0-9]'   # show status of interfaces
brctl show                   # show status of Linux bridges

show?

Interfaces that are up and running should show <BROADCAST,MULTICAST,UP,LOWER_UP>

Did you make any configuration changes since it was working, or reboot the device?

Edit: removed the stray k from the command

@jeff, thanks for the reply!

ip link k gives ip: invalid argument 'k' to 'ip'. Typo on the 'k'?

But the command without the k shows this:

$ ip link | egrep '^[0-9]'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
8: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
11: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
13: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
14: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
16: eth1.1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000

$ brctl show
bridge name    bridge id        STP enabled  interfaces
br-lan		7fff.18d6c7865c11	no           eth1.1
                                             wlan0
                                             wlan1

That's with only one computer connected.

Also, I don't know if this is relevant, but when a new cable is strung from the router to my iMac, it causes the Internet to stop working, even when the ethernet interface is disabled and WiFi is enabled. It doesn't work until the ethernet cable is physically unplugged, which seems strange to me. I'm not a networking expert, but it almost seemed as if something was physically broken with the LAN ports on the router. (Or maybe just a quirk of macOS.)

There are two separate chips involved-- the CPU has the eth0 and eth1 ports, and the switch chip has seven ports. Two of those are permanently wired over to the CPU and the other five are the Ethernet ports on the back of the router.

The switch can switch any port to any other one, using VLANs inside the switch. One way to think about these VLANs are they are like bus wires that can be either tapped into or ignored. The default configuration connects the four LAN ports to one of the CPU ports and the blue WAN port to the other CPU port.

Try swconfig dev switch0 show shows the status and configuration of the switch.

The CPU ports will always show "connected" because they are permanently wired. Running a command like ip link show, which interrogates the CPU ports, likewise will not reflect whether any Ethernet cables are plugged in, the CPU ports are always "connected" to the switch.

If you have switch ports showing "connected" when there is actually no cable plugged in, that is likely a hardware failure that can make the whole switch do strange things.

2 Likes

Thanks for the explanation, I think that helps me understand more how it works inside. :slight_smile:

Either I didn't write clearly, or maybe something you wrote went over my head, but I'm not aware of a switch port showing "connected" when there is no cable plugged in. As far as I can tell, the router shows one cable plugged in -- and it truly is plugged in.

Is there any point in resetting OpenWrt to default values and setting it up again to rule out software issues? Like I said, I haven't changed any settings in months and it has worked well all this time.

I just noticed that the LAN LED lights on the front of the router seem numbered backwards, so that light #4 represents port #1, and light #1 represents port #4. Is that normal?

I don't know how they're numbered, but if you're looking at the front/top of the Archer C7v2, the left-most light seems to correspond to the left-most socket and so-forth. The "Wireless On/Off" switch is "backwards" and funky in that it is tested as a button, not a switch.

Ok, I guess the lights are consistent with what you described, then — thank you!

So how can I rule out a hardware failure? Is there a way to do that?

The easiest way would be to make a backup of your current configuration (both luci or sysupgrade offer this feature to generate a config tarball), and then to reset/ firstboot the device. Given that it's a very common device, the defaults should be working (otherwise problems with it would be known) - so this would rule out issues with your own config (which might be down to file corruption in a crucial file, e.g. /etc/config/network). The downside, the default configuration comes with wlan disabled - so if there is a hardware issue with the switch/ LAN ports, you won't be able to access your device anymore.

1 Like

Holy cow, it works now!!! I backed it up, did a reset/firstboot like @slh said, and it came up with the ethernet connections working! I had previously taken screenshots of every config page, so it didn't take long to put everything back, too.

Thank you so much to everyone who took the time to help. I really appreciate it!

1 Like

That suggests an accidental configuration change (probably switch/ vlan related) - or file corruption (NAND is slightly suspectible to that), great that you could get it sorted.

1 Like

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