AC1750 v2 lan interface needs occasional restart

I use an Archer C7 AC1750 v2 running OpenWRT 22.03.5 for my home network. It's a pretty simple setup: the wan port is connected to my cable modem, and (except one backup machine on ethernet) everything else in the house uses wifi.

Periodically (can be every few days, can be more often), our home network stops working. Power cycling the AC1750 fixes it.

I also allow ssh and (https-only) web access from the outside, and so I eventually noticed that during one of these failures it was still possible to log in over the wan, and that using luci to restart the "lan" interface was enough to fix the problem.

Any suggestions on troubleshooting this?

Start by upgrading to 23.05.3 since your current version is EOL and unsupported.

This is a very dangerous thing to do -- the web server in particular is not hardened for direct exposure to the internet.

Before you upgrade, we can take a look at your config:

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

Whoops, thanks for pointing that out! Looking.... I guess I was depending on attended-sysupgrade and missed that it ignores upgrades across major versions.

OK, thanks, any pointers to uhttpd documentation that would help me better understand the risks?

Appended. Thanks so much!

I'll go look into how to do the upgrade. (Any advice welcomed.)

root@pipe:~# ubus call system board
{
	"kernel": "5.10.176",
	"hostname": "pipe",
	"system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
	"model": "TP-Link Archer C7 v2",
	"board_name": "tplink,archer-c7-v2",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "22.03.5",
		"revision": "r20134-5f15225c1e",
		"target": "ath79/generic",
		"description": "OpenWrt 22.03.5 r20134-5f15225c1e"
	}
}
root@pipe:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix '***'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth0.2'
	option proto 'dhcp'

config interface 'wan6'
	option device 'eth0.2'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'

root@pipe:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option disabled '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option band '2g'
	option htmode 'HT20'
	option channel '4'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2'
	option key '***'
	option ssid '***'
	option macfilter 'deny'

root@pipe:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

***"config host" sections redacted***

root@pipe:~# cat /etc/config/firewall

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Block-chromebook-mornings'
	option src 'lan'
	option dest 'wan'
	option start_time '00:00:01'
	option target 'REJECT'
	option stop_time '07:30:00'
	list src_mac '***'
	option enabled '0'

config rule
	option name 'Block-chromebook'
	option src 'lan'
	list src_mac '***'
	option dest 'wan'
	option target 'REJECT'
	option enabled '0'

config rule
	option name 'Allow ssh from wan'
	list proto 'tcp'
	option src 'wan'
	option dest_port '22'
	option target 'ACCEPT'

config rule
	option name 'Allow https from wan'
	list proto 'tcp'
	option src 'wan'
	option dest_port '443'
	option target 'ACCEPT'


It's on 23.05.3, and still failing intermittently. Is it's possible some piece of the hardware is just failing?

What are the specific symptoms? Can you still reach the device, or do you have to power cycle it? If you can reach the device, can it ping the outside world (via a ssh session or the diagnostics)?

Yes, that's certainly possible...

But... this is very dangerous:

Your configuration appears to be very close to default, but the firewall exposing ssh and luci. Therefore, may want to reset to defaults and use a fresh config without those firewall rules. Resetting to defaults will ensure that if someone did manage to gain access to your system, anything they did will be wiped clean. Since it seems you have static DHCP assignments, you can easily restore that file -- just take a backup and then you can copy the specific file (/etc/config/dhcp) back into place without restoring the rest of the config.

it was still possible to log in

You got hacked, now address it.

I can reach it via the WAN, but not the LAN. Ditto if I log into it and try to ping anything on the LAN.

I think wireless might still actually be working at some level when this happens (e.g. I think my laptop still shows as connected, just not able to ping anything). Restarting the LAN interface is all that's required to fix it, powercycling isn't required.

I'm accessing it over ssh and https, the password is good. Could you be any more specific about what the worry is? Does uhttpd have some known vulnerability?

What's your evidence for that?

There are a few...

  1. uhttpd (webserver) isn't hardened for the purposes of internet exposure. It is a lightweight server by design, so it could be possible hack at it in ways that are not specifically tested or protected.
  2. ssh is generally more secure, but dropbear is likewise a lightweight ssh serer not really designed for internet exposure.
  3. You can be brute-force attacked. Even if this doesn't actually result in any successful logins, it could still be an unnecessary load on your system
  4. Why do you need to access your router from outside? If this is necessary, you should use a VPN which has cryptographic protections. WireGuard is great because it doesn't even respond at all unless the cryptographic keys are correct.

Got it, thanks for the explanation. To push back a little:

  • "lightweight" isn't the opposite of "hardened". If anything, a simpler server should be easier to secure. (But there are other factors, sure.)
  • The distinction between "internet exposure" and use on a lan isn't so clear to me. Like a lot of home networks these days, mine has dozens of wifi clients of all sorts. There's a significant chance one of them will be compromised some day, and I haven't tried to firewall them off.

But, I dunno, I may be pushing it, fair enough.

(The one hill I might die on: it's complicated I'm sure, and openssh has a stellar reputation for security, but I'm having a hard time with the statement that dropbear is "not really designed for internet exposure".)

I did wonder about that actually, though if it were an issue in my case I think it'd be obvious from the logs.

Yeah, I could do without https honestly. (Dropbear I'm inclined to trust.)

No, it's not the same, that's true. But just because it's smaller doesn't mean it's easier to secure. There are many features of 'full fledged' web servers are designed to handle internet-facing traffic with things like rate limiting to prevent brute-force authentication attempts and more sophisticated login handling routines (among many other things).

Ok... let's use a silly, but reasonable example... Let's say you go to a friend's house for a small party... maybe 25 people or so. They're all friends of your friend, and you have a reasonable amount of trust that your friend keeps good (honest) company. You probably wouldn't be too concerned about your phone if you were to leave it on the table and walk into another room (at least not from a theft perspective). But, you probably wouldn't do the same in a large night club.

Yes, there is always that chance. But generally, you've got a few dozen clients on your network, and most of the ones that you permit on your trusted lan are probably mostly safe. And if your device is compromised, it's probably more likely to target the data on that same device (passwords, keyloggers, other data to exfiltrate) or maybe it will target other lan devices. But typically they don't attack the router itself because they're already inside.

The internet, on the other hand, is not at all trusted (or at least it should be treated that way if you don't currently). Instead of the off-chance of one of your several dozen machines being compromised, there is 100% certainty (I mean that literally) that there are millions of of compromised devices that are hammering on the public IP addresses on the internet to exploit vulnerabilities.

Yeah, it's a stretch, to say it mildly. I'm giving you advice about how to secure your network properly (and this in turn helps reduce the number of infected devices on the internet in general). But it's your router and devices that are at risk, not mine, so do what you will. (to be clear, though, proper security on your router is in everybody's best interest except for those who have malicious intent, for whatever that's worth).

Well, despite OpenSSH having an excellent reputation, vulnerabilities are discovered from time to time in it as well as other seemingly robust protocols. The fewer exposed surfaces, the better the security posture. Don't forget -- this is your primary router/firewall for your network, so you want to reduce the risks wherever possible.

Meanwhile, there was a discussion about a CVE in OpenSSH just today, so while this does not affect Dropbear on OpenWrt, it's worth noting that it just takes one such vulnerability to render your router compromised... so use a VPN which is much less likely to have these types of attack surfaces.

Not necessarily.
A skillful attacker will clear the logs. And, in the case of OpenWrt (unless you have an external syslog server to which you send all the logs), you've got a limited window of visibility because the logs are kept in RAM and limited in buffer size (the oldest stuff falls off the edge as new entries are added).

That's good.

I'm arguing that you shouldn't... even if I can't quote you a specific issue, I don't see it being worth the risk because we know that a VPN is a viable solution and much more secure.

Sure. Sorry, I might have been unclear, I was just talking about the possibility that my problems might somehow be a consequence of load due to a lot of failed login attempts.

Again, the log entries of interest might roll over by the time you get to them.

You will not talk your way out of fixing it.
reset re-flashing in failsafe and recreate config from zero.

When I've had this problem there've always been logs covering the onset (and going back at least an hour or so). (Again, just addressing the question of whether the problem might be load from failed ssh login attempts.)

Regardless, the most prudent first step here is to simply reset the device to defaults and not enable the external access that you had previously.

1 Like