search

openwrt / mt76

mac80211 driver for MediaTek MT76x0e, MT76x2e, MT7603, MT7615, MT7628 and MT7688
750 stars 342 forks source link

MT7628: Clients keep disconnecting. #169

Closed yujincheng08 closed 5 years ago

yujincheng08 commented 6 years ago

I have a HC5661A using MT7628. I've just test the latest commit e2eedc92 and it's very unstable. I connect my xperia phone to the wifi and it keeps disconnected around every 10 minutes. And the log keeps showing:

WPA: group key handshake completed (RSN)

I google for a solution and I added the followings to /etc/config/wireless

option wmm '0'
option wpa_group_rekey '0'
option wpa_pair_rekey '0'
option wpa_master_rekey '0'

Things become better. But after 18-20 hours, clients disconnect again and the AP disappears from the air. I reference to the log and it shows:

hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs

I asked google for help again and added the following line to /etc/config/wireless:

option disassoc_low_ack '0'

After a few days testing, clients also keep disconnected, the log did not show something related to ACKs but:

hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: disassociated due to inactivity
daemon.info hostapd: wlan0: STA 00:00:00:00:00:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx

BTW, when clients disconnected, only rebooting recover the AP.

The full /etc/config/wireless:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/10300000.wmac'
        option htmode 'HT20'
        option country '00'
        option legacy_rates '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'LEDE'
        option wmm '0'
        option encryption 'psk-mixed'
        option key 'keep it secret'
        option wpa_group_rekey '0'
        option wpa_pair_rekey '0'
        option wpa_master_rekey '0'
        option disassoc_low_ack '0'
XobQuit commented 6 years ago

Same on TL-WR841ND v13

nbd168 commented 6 years ago

I've pushed some more fixes for MT7603 and MT7628, please test the latest version from mt76.git (not pushed to OpenWrt yet).

yujincheng08 commented 6 years ago

@nbd168 Thx for your fixes. I've been tried it for half a day and clients still disconnect. And the system log is

Sun May 20 19:02:46 2018 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Sun May 20 19:02:46 2018 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Sun May 20 19:02:47 2018 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun May 20 19:10:49 2018 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy IEEE 802.11: authenticated
Sun May 20 19:10:49 2018 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy IEEE 802.11: associated (aid 2)
Sun May 20 19:10:49 2018 daemon.notice hostapd: wlan0: AP-STA-CONNECTED yy:yy:yy:yy:yy:yy
Sun May 20 19:10:49 2018 daemon.info hostapd: wlan0: STA yy:yy:yy:yy:yy:yy WPA: pairwise key handshake completed (RSN)

I didn't change any configuration in /etc/config/wireless so it's the same as when I post this issue. If you want some more information, please tell me and I am glad to provide.

XobQuit commented 6 years ago

Problem still present.

ingamedeo commented 6 years ago

Issue confirmed on hardware with the same chipset

rwalli commented 6 years ago

Same Issue on GL-MT300N-V2 ( MT7628AN )

ekenchan commented 6 years ago

Same issue on MI-Nano ( MT7628AN )

yujincheng08 commented 6 years ago

Thing seems to be better after testing for several days on 65e161b. I did not suffer from disconnecting for these days. Thx for fixing!

ghost commented 6 years ago

no idea how you think its fixed, i am seeing it on both the NANO and 841 devices still

rdscorreia74 commented 6 years ago

And I'm still seeing this on a very different piece of hardware, the TP-Link TL-WR1043ND V2 with a Qualcomm Atheros QCA9558 chipset and I'm on OpenWrt 18.06.1 r7258-5eb055306f.

Tue Sep 4 12:25:35 2018 daemon.info dnsmasq-dhcp[1417]: DHCPINFORM(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc Tue Sep 4 12:25:35 2018 daemon.info dnsmasq-dhcp[1417]: DHCPACK(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc MyLAPTOP Tue Sep 4 12:26:09 2018 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 30:52:cb:aa:bb:cc Tue Sep 4 12:26:09 2018 daemon.info hostapd: wlan0: STA 30:52:cb:aa:bb:cc IEEE 802.11: disassociated Tue Sep 4 12:26:10 2018 daemon.info hostapd: wlan0: STA 30:52:cb:aa:bb:cc IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Tue Sep 4 12:26:21 2018 daemon.info dnsmasq-dhcp[1417]: DHCPREQUEST(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc Tue Sep 4 12:26:21 2018 daemon.info dnsmasq-dhcp[1417]: DHCPACK(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc MyLAPTOP Tue Sep 4 12:26:25 2018 daemon.info dnsmasq-dhcp[1417]: DHCPINFORM(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc Tue Sep 4 12:26:25 2018 daemon.info dnsmasq-dhcp[1417]: DHCPACK(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc MyLAPTOP Tue Sep 4 12:27:43 2018 daemon.info dnsmasq-dhcp[1417]: DHCPINFORM(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc Tue Sep 4 12:27:43 2018 daemon.info dnsmasq-dhcp[1417]: DHCPACK(br-lan) 10.11.11.30 30:52:cb:aa:bb:cc MyLAPTOP

yujincheng08 commented 6 years ago

Reopen this issue because problem still presents.

dibg commented 6 years ago

Same issue on MI-Nano (MT7628AN)

julianocss commented 6 years ago

Same issue on WR840 V4 (MT7628AN).

sanitariu commented 6 years ago

Same issue on WR840 V5 (MT7628AN). Router is unusable.

yujincheng08 commented 6 years ago

It seems that the latest version(fdc63f16) performs better now. I have tested it for two days and no disconnection has occurred. But I didn't connect the clients for a continuous long period so I am not sure the issue was completely settled down. I will keep this issue opened and if no other feedback saying this issue persists, I will then close it.

julianocss commented 6 years ago

I´m testing on my WR840 V4 too.

I give a feedback in the next days.

Thanks. Juliano

ffrediani commented 6 years ago

Hi Just want to report that similar to other people reporting stability issues when using TP-Link C20 v4 which has this same radio has also been very unstable. The symptoms are: when you boot up the router the SSID is advertised but after a couple of minutes it becomes unstable and disconnects clients which, although the SSID keeps been advertised, cannot connect anymore until reboot. Tried version 18.06.1 and also Snapshot. For the Snapshot (from last 30th October) it has been worst and most of the time the SSID is not even advertised most of the time and therefore clients cannot connect.

Tried to change the TX power (18, 19 and 20) and also to use in different fixed channels and also in Auto mode. Made no difference.

The configuration for /etc/config/wireless is default as follow:

config wifi-device 'radio0' option type 'mac80211' option hwmode '11g' option path 'platform/10300000.wmac' option htmode 'HT20' option country 'US' option legacy_rates '1' option txpower '20' option channel 'auto'

Find attached some logs for 2 scenarios: 1) Radio Channel configured in Auto and then in Channel 6. Both scenarios the client's behaviour is the same as reported initially.

Logs-MT7628AN-C20-v4.txt

ffrediani commented 6 years ago

Hello again.

I have a significant feedback to give. I have been running the same router with MT7628AN for the last two days with a single SSID and it seems more stable. Haven't had any disconnects or SSID disappearing as the previous times running with two SSIDs. Perhaps multiple SSIDs is something to be looked into more deep in order to confirm these issue.

I will keep it this way and if there is anything new I will report again.

julianocss commented 6 years ago

Hello!

I left a feedback in the issue #188 about latest commit. There was a huge improvement in speed on my WR-840 v4 (MT7628AN).

Juliano

ido1990 commented 5 years ago

Same issue on my GL-MT300N-V2

HunterDG commented 5 years ago

Same issue on my HooToo TM06 (Using GL MT300N build). un-checking Disassociate On Low Acknowledgement (default checked) seems to help. Agree that multiple SSIDs may exaggerate the issue (I use wifi>wifi AND WAN>wifi routing). Disabling the client/STA SSID and using only ethernet for WAN seems to allow the router to function a bit longer than using wifi>wifi routing, before connectivity dies.

nbd168 commented 5 years ago

Please try the latest version, with improved tx status handling, things should be better now.

joshuisken commented 5 years ago

I have the same issues on a Archer C7 v2, actually upgraded from lede 17.01.3 due to this issue and it still exists in 18.06.2 (SoC: Qualcomm Atheros QCA9558 ver 1 rev 0) Various options suggested at the start of this thread did not help. Except that with these options:

Thu Feb 14 21:08:15 2019 daemon.info hostapd: wlan1: STA 00:26:e8:d3:43:45 IEEE 802.11: authenticated Thu Feb 14 21:08:15 2019 daemon.info hostapd: wlan1: STA 00:26:e8:d3:43:45 IEEE 802.11: associated (aid 2) Thu Feb 14 21:08:19 2019 daemon.info hostapd: wlan1: STA d0:fc:cc:db:2f:32 IEEE 802.11: authenticated Thu Feb 14 21:08:19 2019 daemon.info hostapd: wlan1: STA d0:fc:cc:db:2f:32 IEEE 802.11: associated (aid 2) Thu Feb 14 21:08:27 2019 daemon.info hostapd: wlan1: STA d0:fc:cc:db:2f:32 IEEE 802.11: deauthenticated due to local deauth request

I do have 2 radios switched on with same SSID + pwd (2.4G and 5G) and enabled those options on both interfaces.

joshuisken commented 5 years ago

Now I disabled "Allow legacy 802.11b rates" on both radios. This seems to help! Without reboot I haven't seen a single disconnect during more than half an hour whereas before is was happening every minute or so.

ingamedeo commented 5 years ago

@joshuisken Completely unrelated! It's a different chipset!!

joshuisken commented 5 years ago

Maybe I'm suggesting that it is not chipset related? Actually I did realize it is a completely different chipset, as mentioned.

Op do 14 feb. 2019 23:27 schreef Amedeo Baragiola <notifications@github.com:

@joshuisken https://github.com/joshuisken Completely unrelated! It's a different chipset!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/169#issuecomment-463827391, or mute the thread https://github.com/notifications/unsubscribe-auth/ACpQwpLLmfEUl_A4Wnk6rfUAMbIc9WJ1ks5vNeLJgaJpZM4Tz3f2 .

ingamedeo commented 5 years ago

@joshuisken Thank you. The issue you have reported can be caused by many different factors and it is actually a known issue on the mt76, therefore it clearly is chipset related. It may not be on your unit however.

joshuisken commented 5 years ago

I was facing many "deauthenticated due to inactivity (timer DEAUTH/REMOVE)" in my Archer C7 v2, and since last night they are completely gone after disabling "Allow legacy 802.11b rates" on both radios. I'm running 18.06.2 happily now.

rdscorreia74 commented 5 years ago

@joshuisken Yep. To me, OpenWRT's wifi is broken for way more than an year and no one seems to care about it...

markuznw commented 5 years ago

I've got the same issue of IEEE 802.11: disassociated due to inactivity on my wife Note9. It appears to happen on 5ghz network and every 2-3 minutes at max.

I've got both disassoc_low_ack and legacy rates options deactivated.

Hope @nbd168 can look into it because in the current state she got to use LTE to use phone as mir3g wifi is TOTALLY unusable with that phone :(

Btw using stock rom (no modifications of any kind) so I guess it's really related to a bug in the driver :/

All looks fine on other phones, but same issue keeps happening with a Samsung Smart TV on the other room. It all goes fine as soon as we reboot the router but stalls like said after a while

nbd168 commented 5 years ago

@markuznw: for the 5ghz network that's a different issue (mt76x2e driver, not mt7603e). What openwrt version are you using? If it's older than about 5 days (or based on the 18.06 branch), you should update to latest master and try again.

markuznw commented 5 years ago

Thanks for the fast reply @nbd168. I'm using master (and I even tried e72376d2f03a5b4b19b00bbefd80023de6d218f6 on this repo to see if there were any differences) but no luck. Can't get why it is all fine on my oneplus 3t and other devices but on Note9 with better antennas and hardware so many problems

lukasz1992 commented 5 years ago

@markuznw @yujincheng08 it is probably finally fixed in master.

socomsystems commented 5 years ago

This is not fixed... Thought it would be if after upgrading from .1 Model MikroTik RBM33G Architecture MediaTek MT7621 ver:1 eco:3 Firmware Version OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.051.55698-76cf653) Kernel Version 4.14.95

nbd168 commented 5 years ago

You need to use a current snapshot, the fix was committed very recently.

markuznw commented 5 years ago

@nbd168 my issue with note9 seems to be solved on latest Master and your last push of mt76. Not a single disconnection in the past 16 hours.

Thanks for your hard work on making this kernel module available and fixing all quirks :)

socomsystems commented 5 years ago

@nbd168 forgive my ignorance, I'm not sure how to go about applying latest commits. I'm on an RBM33G board MediaTek MT7621 ver:1 eco:3 using R11e-2HPnD radio cards. Thanks so much for your help, creation and fixing of this issue.

Generic MAC80211 802.11bgn kmod-ath9k - 4.14.95+2017-11-01-9 kmod-ath9k-common - 4.14.95+2017-11-01-9 hostapd-common - 2018-05-21-62566bc2-5

Current config SSID sample:

`config wifi-device 'radio1' option type 'mac80211' option hwmode '11g' option path 'pci0000:00/0000:00:01.0/0000:02:00.0' option htmode 'HT20' option country 'US' option legacy_rates '0' option distance '100' option beacon_int '200' option channel '1'

config wifi-iface option device 'radio1' option mode 'ap' option ssid 'xxxxxxxxxxx' option network 'VLAN4_UNT' option disassoc_low_ack '0' option encryption 'psk2+ccmp' option key 'xxxxxxxx' option wpa_group_rekey '86400' option wpa_strict_rekey '1' `

agunzagun commented 5 years ago

I hate to just "me too" this (or if I should have filed the report on its own), but I'm also experiencing issues - namely on the 5GHz band. I found this thread trying to Google solutions.

Logread comes up

root@OpenWrt:~# logread | tail
Mon Apr  8 02:35:37 2019 daemon.info dnsmasq-dhcp[3138]: DHCPACK(br-lan) X.X.X.X xx:xx:xx:xx:xx:xx WirelessClient  
Mon Apr  8 02:35:38 2019 daemon.warn odhcpd[1202]: DHCPV6 CONFIRM IA_NA from xxxxxxxxxxxxxxxxxxxxxxxxxxxx on lan: ok xxxx:xxxx:xxxx::xxx/xxx  
Mon Apr  8 02:35:45 2019 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disconnected due to excessive missing ACKs  
Mon Apr  8 02:35:45 2019 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx  
Mon Apr  8 02:35:47 2019 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED xx:xx:xx:xx:xx:xx 1  
Mon Apr  8 02:35:47 2019 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated  
Mon Apr  8 02:35:47 2019 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED xx:xx:xx:xx:xx:xx 2  
Mon Apr  8 02:35:47 2019 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)  
Mon Apr  8 02:35:47 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx  
Mon Apr  8 02:35:47 2019 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)

And more or less repeats as such. No outstanding issues (so far) on 2.4GHz.

The build used is based on the latest git as of this post. The profile is based on RAMIPS>MTC WR1201.

Arch: MediaTek MT7621 ver:1 eco:3
Radio0 Type: MediaTek MT76x2E 802.11ac
lukasz1992 commented 5 years ago

@agunzagun If you have this issue on 5GHz, please open another ticket, as this is about MT7628 (2.4GHz radio)

ffrediani commented 5 years ago

@agunzagun for the 5 Ghz if you you Wifi chip is MT7610E please report all in issues #227 Mine is not working at all.

NischalBhandari commented 4 years ago

This issue exists in MediaTek MT7620N ver:2 eco:6 also . Have not been able to fix this issue learned a lot trying to debug this but many having tried it with different device with MediaTek MT7620N ver:2 eco:6 and different firmware still brings up this issue . While analyzing wifi from a mobile device the signal seem to drop sharply and then again restart again .

ykzj commented 4 years ago

same here on Nexx 3020F

lukasz1992 commented 4 years ago

@ykzj @NischalBhandari But MT7620N has nothing to do with mt76 driver. MT7620N wifi is driven by rt2800soc, not mt76

ykzj commented 4 years ago

you are right. I finally figure out that is caused by high cpu temperature. I decrease cpu frequency to low cpu temperature, and the symptoms are gone.

发自我的iPhone

在 2020年3月7日，00:48，lukasz1992 notifications@github.com 写道：

 @ykzj @NischalBhandari But MT7620N has nothing to do with mt76 driver. MT7620N wifi is driven by rt2800soc, not mt76

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

brentonv commented 4 years ago

https://github.com/openwrt/mt76/issues/379

db260179 commented 3 years ago

So for the mt76 driver, there is an unknown issue with setting the country code. So for now remove

option country

From your wireless config, and let the driver decide what it needs to set.

It seems this device has other issues?

brentonv commented 3 years ago

@db260179 sorry mate deleting config option country doesn't fix anything. This crontab is the only thing I've found to keep the device reliable 0 */1 * * * ifdown wwan && ifup wwan Edit: this is for relayd configuration.

trunneml commented 8 months ago

Don't know if it helps but I have the same problem with a banana pi r3 (MediaTek MT7986) on the 5GHz Network with two iphones.