Hi, I have a couple of recurrent problems with the TP-Link Archer C7 v2 router and v22.03.3 (and previous versions): firstly the wifi connection drops off over a period of a couple of weeks becoming slower and more reluctant, when restarting the wireless device(s) fixes it; secondly the wireless occasionally fails completely, requiring a wired connection to again reset the wifi.
I look at the system and kernel logs but never see any obvious errors though I don't know what's normal, for one example, "Switch own primary and secondary channel to get secondary channel with no Beacons from other BSSes". How can I find more about what's causing these problems and filter the wheat from the (disassociated/deauthenticated) chaff?
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:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
This is over-redacted. It is not necessary to redact the RFC1918 network addresses (i.e. 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8).
Since your config isn't that far from defaults, I'd recommend upgrading to 23.05.0 and going back to defaults. Then just change the minimum things necessary (i.e. country code, SSID, encryption type, passphrase and any other key things) and then test again.
I'd still like some answers to these questions (the first at least should be trivial):
How to increase the logging level, either for specific modules or the whole system?
How to decide whether lines in the system and kernel logs are normal or errors?
How to find out where delays are happening?
As I said, the slowdown is a longstanding problem and before posting here, I'd read the notes for later releases and didn't see anything which might fix it. As far as I know, I have only made essential changes to the config and frankly was hoping for more than "install the latest version" without any further justification.
You say it's overredacted, I say I do not wish to expose my internal network config.
You may need to do some searches if you want to learn how to increase the depth and granularity of the logging... some options may require recompiling from source. And be aware, heavy logging activity will likely slow down your system.
Usually, errors are quite clear with "Error" as part of the message. There are also warning messages, and then the vast majority of entries are just status (normal).
That's harder... the symptoms you describe are not common or normal, but there may be more to the story than just your router. Sometimes the problem is elsewhere in your network. For example, there are USB-C docking hubs that have a bug where the device will produce broadcast storms over ethernet (sufficient to completely kill the network) when the host system is powered down/sleeping or disconnected. It can take a while before someone locates that device as the culprit because it 'seems' like it must be the router (this is just an example, but a true one... there are other similar things I can share, too). So simplifying the network and working to isolate things by literally going back to basics is sometimes required. But yes, looking at logs may provide some clues, or it may not in some situations.
As you wish. However, in the process, it becomes harder for us to help. Essentially everybody on the planet who is using IPv4 behind a NAT masquerading router is (or should be) using the RFC1918 address range for their LANs. There is nothing secret about them, and it doesn't expose anything private about the network. The only value to anyone else is if they have a direct ethernet or wifi connection to your network, and even still, once they are on the network, they can assertain at least the subnet to which they are connected without needing to see configs. I'm happy to share that my subnets are 10.0.1.0/24 (lan), 10.0.3.0/24 (guest), and 10.0.4.0/24 (iot), and then I have VPNs on 10.0.21.0/24 10.0.1.22.0/24 and 20.0.23.0/24. Sharing that info won't compromise my network (and these are the real subnets I use).
My network isn't complicated, I don't have any USB hubs. I suspect the router and wanted to find out how to investigate and troubleshoot it, so far without success. Redacting my subnet does not make it "harder for us to help."
With hindsight, it was perhaps foolish of me to expect answers by posting on the forum dedicated to the product.
Your response is surprisingly snarky... I was giving you legit advice. Maybe the bigger point here is that you probably haven't done enough investigating/testing/debugging to actually isolate the problem to the router itself. Can this be an issue with OpenWrt? Yes, of course. But can it be somewhere else in your network -- yes...very much so.
To give you an example of how we call can fall into certain traps like this: I personally had major network problems a few years ago. I did a bunch of troubleshooting, and everything seemed to suggest that it was my core switch (at the time, a 24-port managed gigabit PoE buisness grade device). Things were hanging, bandwidth was inconsistent, packets would just get dropped... and nothing had changed in terms of connected equipment and wiring on my network. I was arranging to RMA my switch when I unplugged one device and suddenly everything started working normally again. What was it?? Well, I had a Sonos Bridge (which is just basically a special AP that used to be necessary in some situations for Sonos systems) and I also had a Sonos Connect (which is one of the music players), both wired to the network. They had been like that for years without any problems. But... a Sonos update must have changed their STP algorithm and it suddenly was causing switching loops which caused all the issues I described. But removing the Bridge, all the problems cleared up. It makes perfect sense in highsight, but I didn't see it until I stumbled into the solution.
So yeah, when I suggest that you do more troubleshooting and isolation, it's for a good reason.
EDIT: I also want to point out that your device is well supported and very popular with OpenWrt users. There are very few reports of issues related to OpenWrt performance on this device. This means that your situation is different -- it could be a configuration issue, a hardware issue with your C7, or a problem caused by something else on your network. You need to experiment to find out what it might be... I was trying to give you examples of how you need to think of your network as a system and work to identify and isolate the problem.
It might be worth pointing out that you are asking us for help... so we're asking for the things that are relevant and not actually sensitive/private information that could compromise the security of your network. In this very simple case, it's likely that this will not be the problem, but we cannot know for sure that you are using an RFC1918 address range.
Some of the logging was put there by developers and would require looking at and understanding the source code. When something goes wrong or when working on adding support for a new device a user can post the logs for developers to look at.
The OpenWRT developers do not write all the drivers or other code. It comes from Linux kernel and other developers with the changes getting merged into OpenWRT on a regular basis. OpenWRT does not duplicate change history from upstream and usually just merges a specific version with that as the commit message. There is no detailed list of what changed between versions - for that you would need to check upstream for each component. A few packages are managed as OpenWRT projects and have more detailed change logs.
There is no guide to sorting through everything as so much comes from upstream projects that change on a regular basis.
If the signal degrades over time and improves after a reboot then the most likely culprit is signal interference. The rebooting process means the router can search for a less congested frequency slot. You didn't tell me if you live in a condo or crowded area. If affirmative then I am confident that is your problem.
You should add a script to cron to reboot/wifi restart at 4am each morning so it picks up a new less congested frequency slot.
The channel is fixed, so the reboot wouldn't affect the channel selection. But certainly environmental conditions may be at play here.
While we're on the topic of the radio, though...
channel 9 is not recommended. Typically 1, 6, and 11 (or possibly 12 or 13 in the UK) should be used. Channel 9 will likely experience a lot of noise from APs that are using 6 or 11 since it's nominally in the guard band between the two commonly used channels.
Your wireless config contains references to deprecated setting option hwmode => can you use option band instead ? Also:
Use option band '2g' (instead of option hwmode '11g')
Use option band '5g' (instead of option hwmode '11a')
see also https://openwrt.org/docs/guide-user/network/wifi/basic#common_options
(not sure whether this will make a difference though)
you are using a DFS channel (option channel '56')
=> possibly you are running into a DFS related issue - can you use a non-DFS channel instead like 48 ?
For troubleshooting: possibly these commands will return different output at times when you are facing issues?
