Posted: Sat Jul 09, 2022 16:55 Post subject: RT-AC68U similar issues
I upgraded two RT-AC68U from 49326 to 49392 on 2022-06-30 and started experiencing disconnects on one laptop running Fedora 36 with an Intel 7265 card.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Jul 09, 2022 18:33 Post subject:
@xaoslaad
No such issues here with my 68U or Linux clients connectivity and I'm well past on newer dev test builds not yet available as public builds. I dont have your client card exactly but have different flavors of Linux, and they all work just fine for longer than a day.
What I will do for you is split this topic and your post and our replies into new standalone topic.
What I will say is that drivers fedora side for the clients wifi card may be a lil off, easily tested on a dual boot scenario. Its a possibility Since Windblows vs Linux drivers side tends to be better supported, sadly and unfortunately.
also look at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327595 these are optimized settings, which I use to the T given my topology and clients support. If your clients support differs (channel width wise and others) you may want to adjust settings per their support from what is recommend in that page.
Posted: Wed Jul 13, 2022 21:41 Post subject: vht noise
I have been staring at this a lot trying to make some headway.
Last night I realized these are just noise in the logs:
[ 2109.660046] wlp1s0: bad VHT capabilities, disabling VHT
[ 2109.660048] wlp1s0: 80 MHz not supported, disabling VHT
It's roaming from 5GHz to 2.4GHz when it gets deauthenticated, which I can tell from the MAC address change, so of couse VHT80 isn't supported.
On the `Key Renewal Interval` I upped from 3600 to 86400 and I've been connected all day with no errors now, so it seems there is potentially valid behind the `GROUP_KEY_HANDSHAKE_TIMEOUT` error.
Can't say why I'm having problems all of a sudden, but still digging.
Updated to r49467, but the problem persisted until I supped the Key Renewal Interval.
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Thu Jul 14, 2022 1:52 Post subject:
It's been proven in the real world ad nauseum infinitum that the settings in that sticky are bunk and do not follow any published standards or driver spec. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Posted: Thu Jul 14, 2022 14:21 Post subject: just one
I narrowed it down to just one of the two. One is acting as a typical wireless router to the internet. The second is connected over ethernet and basically just acting as an AP since reception is poor in areas of the house.
Connections never survive an hour on the AP unit's wireless status page with the key renewal interval set to 3600, whereas they do on the router, so it's something with configuration. It's just manifesting with more annoying behavior on this laptop when it roams from the deauthentication it looks like.
There's not much configured, so if I can't figure it out by the weekend I'll factory reset it and start clean.
I also switched NetworkManager over from wpa_supplicant to iwd on the laptop before seeing that nothing is making it an hour on the AP and see a similar error, reason 16, etc.
And I updated to 49492 this morning to keep current.
Posted: Thu Jul 14, 2022 15:12 Post subject: power reset and update
As mentioned I updated to 49492. I also pulled the power and plugged it back in. It's been about 90 minutes since and there are many clients now connected for well over an hour.
Not very satisfying if that ends up solving it, not knowing the cause, but fingers crossed it remains stable.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Jul 16, 2022 8:28 Post subject:
Hi.
I have the RT-AC68U, just a single one and its Gateway and AP. I normally have between 3 and 6 clients depending on whats going on, some are on unbridged net and ap/isolated VAPS with masquerade, some just connect to regular network.
Overall its steady.
This being Broadcom is royal pain in the whatsit, I randomly experience spontaneous reboots (its rare but happens), sometimes when a client connects to WiFi or just because it's Tuesday and/or I logged into the Web Interface.
Sadly I don't have or can afford a serial adapter and without it, can't really tell whats going on, thus without finding a cause it's hard to pin down any issues.
The worse part is the drivers are closed source and fixing any issue will always be problematic, especially when DD-WRT has a custom wl at 61KB vs original at 500KB so its also hard to tell whats been ripped out or if it matters.
Posted: Sat Jul 23, 2022 1:30 Post subject: Still a problem
This is still a problem. It seems the failures are kind of random. It might rekey successfully one or several times then fail, or it might just repeatedly fail from the get go.
- I was able to reproduce the error on another laptop (with an AX201) running Fedora 36.
- I tried turning up logging in wpa_supplicant, and
see several messages, "wlp1s0: Not associated - Delay processing of received EAPOL frame (state=COMPLETED bssid=04:42:1a:9f:2e:44)" before disconnecting.
- I factory reset the AP and re-configured it manually but still saw the same issue.
- I switched NetworkManager to use iwd instead and got disconnected all the same with reason 16.
- I got my hands on a new RT-AC68U V3, flashed it with dd-wrt (seen as C1), manually configured, and swapped it in. I had the same issue within the hour.
- I flashed the original (A1) with fresh tomato and so far the problem hasn't presented yet, but it's only been about 4 hours, so not definitive.
I do weekly config backups and updates. If tomato remains stable I'm going to try to go back to what was running on 6/30 before I updated (49326) and see if the issue goes away. Most of the time on failure it behaves like it's roaming, but occasionally I get prompted with a login prompt from NetworkManager. That's the first day I recall noticing it. I guess if I can narrow it down between two builds it might narrow the range of offending commits...
I might also try the offending ap dual booting another distro for laughs. At this point I'm not sure what that would tell me though.
The router is an RT-AC68U B1 and I don't think it's having the same problem, which frustrates me.
Regardless of your opinion of intel cards, it doesn't rule out the possibility that something has changed to negatively impact dd-wrt.
3.5 weeks ago it wasn't happening. It seem to me as though something has changed, and I don't sit around updating my wireless settings for fun. That APs config probably hadn't been updated in a year in any meaningful way before this started other than being upgraded once a week.
I'm open to the possibility that it's not DD-WRT, but I've dug through the 5.18.y kernel diffs from then to now and there's not much exciting regarding wireless, wpa_supplicant hasn't been updated on Fedora timeframe, nor has the linux-firmware package.
No, there's nothing definitive yet either way, but the hardware isn't likely bad if it's behaving alike on two pieces of hardware, one old, one new, and yet stable with a different firmware.
The only thing of note between those builds are commits that were related to the R7000P, but it would still help to see your wifi settings on your RT-AC68U.
https://svn.dd-wrt.com/log?rev=49392&stop_rev=49327 _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
These are the wifi pages. I haven't changed anything under advanced. Happy to screen shot it if there's a reason to, but it's all defaults.
Other than that I disable WAN, disable DHCP, set the router name/hostname both to 'ap', set the hostname, configure the lan address 192.168.15.2/24, gateway/dns both 192.168.15.1, disable DHCP, time zone to americas/new_york, set the password, disable telnet, enable ssh, disable password login for ssh, add an ssh key, disable http, enable https, changed the mode on this one to router though being honest it was gateway on the original and seemed to make no difference. add a script to overwrite the crts on startup with self signed crts:
Code:
cat << EOF > /tmp/etc/cert.pem
...
EOF
cat << EOF > /tmp/etc/key.pem
...
EOF
mount -o bind /tmp/etc/cert.pem /etc/cert.pem
mount -o bind /tmp/etc/key.pem /etc/key.pem
stopservice httpd
startservice httpd
LAN 1 is ethernet to the gateway/router. LAN 4 is to a TV.
The A1 with Tomato went for about 7 hours without a disconnect. That's probably close to a record in the last three weeks.
I yanked that out and put the dd-wrt C1 one back now. I flashed it down to 49326, which is the last version I perceived to be problem free. It's been able to rekey once. I'll let it go for several hours. If it appears stable I'll bump up to r49361.
I never ran that version, but it would roughly cut in half the number of commits and be a nice start to a bisect. It also came just before all the R7000P stuff, if I recall from when I was looking.
I did see it was touching some of the 4.4 brcm stuff... I guess it's possible. But will see how these two versions run.
I would not be opposed to fumbling through setting up a dev environment to build an image and try reverting commits, to try to nail down one in particular if possible, but I think trying these two builds first would be a good start.