MT7621 | MT7603EN: Clients disconnecting | Serious problem.

[Openwrtfunboy]

Hi! I have MT7621 and when to router connected more than 10 peoples router start disconnecting some peoples(have two networks guest and main on 2,4).

There is my settings: config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option wpa_disable_eapol_key_retries '1' option key 'WIFIPASS' option ssid 'WIFINAME' option encryption 'psk2+ccmp' option disassoc_low_ack '0' (guest network have same settings)

I also noticed that before the client is disconnected from the network, it will lose the Internet.

Other info: Newifi-D2 MediaTek MT7621 ver:1 eco:3 OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07 branch git-20.045.27998-49999e9

I see it problem in other issue topic. 1: https://github.com/openwrt/mt76/issues/169#issuecomment-477673633 2: https://github.com/openwrt/mt76/issues/169#issuecomment-480727386

[Openwrtfunboy]

I also suggest that this is because I have two wifi networks. When I had one and 8 active clients were connected to it, everything was fine, but as soon as the clients began to connect also to the guest, then there were problems.

I will try to unite the networks, but this is not a solution and causes a lot of problems, because many clients will have to rewrite the password.

[Openwrtfunboy]

I found peoples with same problem: 1: https://github.com/openwrt/mt76/issues/146#issuecomment-458372609 2: https://github.com/openwrt/mt76/issues/146#issuecomment-484582241

Its seriously problem, OpenWRT team need to fix it!

Somebody need to tell them, please.

[Openwrtfunboy]

Empirically, I found out that the number of networks does not affect the problem. Even if you transfer clients to the same network, disconnections still occur.

[Openwrtfunboy]

Empirically, it was found out that not even the number of clients, but the distance to the router affects the outages. If there are ~ 3 clients next to the router, then everyone else will experience problems. If these clients are not near the routers, then everything will be fine

[JFtico]

Also seeing this on another MT7621/MT7603e platform, a ZBT WE3526 (512MB RAM) running OpenWRT 19.07.0

In a rural, uncongested WiFi setting, It handles six or so very active clients fine, even if very close (within 3') to the unit. I have not tested a mix of near + far like the OP. But what is occurring is that if the wifi context is extremely congested (8+ APs on every channel) in an urban setting (my mixed-use office building), even three clients do not remain connected for more than 30 minutes. Even locking in signal strength and channels, it still happens.

[Openwrtfunboy]

Also seeing this on another MT7621/MT7603e platform, a ZBT WE3526 (512MB RAM) running OpenWRT 19.07.0

In a rural, uncongested WiFi setting, It handles six or so very active clients fine, even if very close (within 3') to the unit. I have not tested a mix of near + far like the OP. But what is occurring is that if the wifi context is extremely congested (8+ APs on every channel) in an urban setting (my mixed-use office building), even three clients do not remain connected for more than 30 minutes. Even locking in signal strength and channels, it still happens.

And before everything was good? If so, on which version was it?

[JFtico]

And before everything was good? If so, on which version was it?

It was 18.06.4 and the Wifi was worse, with regular crashes caught in the system log.

The new behavior is puzzling, as there is no crash (or anything) in the system log. The clients just lose connectivity, and eventually (minutes) are able to reconnect.

on 19.07, it's OK in an isolated Wifi environment (only two or three competing APs, low client count), It is much, much worse the more local WiFi contention there is.

Does anyone know if MT76 Wifi has an ANI (Adaptive Noise Isolation) function & associated settings? If so, maybe turning that off in congested environments might address the disconnects.

[Openwrtfunboy]

And before everything was good? If so, on which version was it?

It was 18.06.4 and the Wifi was worse, with regular crashes caught in the system log.

The new behavior is puzzling, as there is no crash (or anything) in the system log. The clients just lose connectivity, and eventually (minutes) are able to reconnect.

on 19.07, it's OK in an isolated Wifi environment (only two or three competing APs, low client count), It is much, much worse the more local WiFi contention there is.

Does anyone know if MT76 Wifi has an ANI (Adaptive Noise Isolation) function & associated settings? If so, maybe turning that off in congested environments might address the disconnects.

In general, I studied this topic and talked with a lot of people in the local Russian forum, as well as with the seller of my router. Apparently, the only solution will be to migrate to Padavan or PandoraBox firmware.

This is a popular and very old issue. It is unlikely that OpenWRT will ever fix that.

[Openwrtfunboy]

IF HERE IS A DEVELOPER OPENWRT, PLEASE REPLACE DRIVER FOR MT7603E TAKEN FROM FIRMWARE PADAVAN OR PANDORABOX, WHERE 2,4 GHz. CHANNEL WORKS GOOD.

ENOUGH TO IGNORE THIS OLD PROBLEM!!!

[Rising-Sun]

If you know the solution please ignore openwrt.

Big thanks to nbd and the team. The driver may not be perfect but I can use my xiaomi mir3g as my daily driver which was unthinkable 1-2 years ago! I appreciate the big efforts made to the driver!

Using latest snapshot in an environment with >20 APs visible from my router on the 2.4 GHz network

[JFtico]

I also appreciate the hard work of the OpenWRT team to bring one of the few Open Source WiFi platforms forward.

Using latest snapshot in an environment with >20 APs visible from my router on the 2.4 GHz network

That is great to hear and hopefully a sign the code is handling corner cases better.

I do want to inquire why 19.07 (released in February 2020) has four and six-year-old firmware blobs, are these the most recent available?

` kern.info kernel: [ 14.476961] mt7603e 0000:02:00.0: ASIC revision: 76030010

kern.info kernel: [ 15.551185] mt7603e 0000:02:00.0: Firmware Version: ap_pcie

kern.info kernel: [ 15.556763] mt7603e 0000:02:00.0: Build Time: 20160107100755

kern.info kernel: [ 15.798531] mt76x2e 0000:01:00.0: ASIC revision: 76120044

kern.info kernel: [ 16.511248] mt76x2e 0000:01:00.0: ROM patch build: 20141115060606a `

There is an open pull request from July 2019 https://github.com/openwrt/mt76/pull/295 indicating that firmware from 2017 is available for the 7603/7621 pair. Are there problems with that 2017 version, if not, other than doing a custom build, any builds include that?

[nbd168]

As far as I can tell, there are no relevant changes in the newer firmware blop that make it worth upgrading to.

[JFtico]

@nbd168 Thanks for the update on the firmware blobs, so the fix for the client's disconnecting identified in this thread is in an existing build or still an open issue?

Thanks in advance

[Openwrtfunboy]

As far as I can tell, there are no relevant changes in the newer firmware blop that make it worth upgrading to.

Is work in progress or planned to correct this issue on the mt7621/mt7603e platform in the future?

This problem has existed since the 18 release.

[Openwrtfunboy]

If you know the solution please ignore openwrt.

Big thanks to nbd and the team. The driver may not be perfect but I can use my xiaomi mir3g as my daily driver which was unthinkable 1-2 years ago! I appreciate the big efforts made to the driver!

Using latest snapshot in an environment with >20 APs visible from my router on the 2.4 GHz network

However, this does not solve the existing problem. I switched to another firmware only because I cannot use OpenWRT. Look at my nickname again. Thanks.

[nbd168]

You could try this: echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dynamic_sensitivity

[Openwrtfunboy]

You could try this: echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dynamic_sensitivity

It really works and is a fix for me. But before the developers include this in the main branch, I would like to see feedback from other participants who also applied this fix. What about you, @JFtico?

Thanks, @nbd168 I love you! p.s. it works until reboot as i know

[JFtico]

Thank you, will give that a shot this weekend.

[Openwrtfunboy]

Thank you, will give that a shot this weekend.

Hi! Did you test it, @JFtico?

[9000000]

The latest update that I use "OpenWrt SNAPSHOT r12288-1173719817" does not know if I've fixed this error yet but the previous versions I have encountered the same case. And the current version I am using does not encounter this error

[Openwrtfunboy]

The latest update that I use "OpenWrt SNAPSHOT r12288-1173719817" does not know if I've fixed this error yet but the previous versions I have encountered the same case. And the current version I am using does not encounter this error

Yes, because it fixed now by default in new builds.

[JFtico]

@Openwrtfunboy @nbd168 In the testing this weekend, the disconnects were indeed fixed.

However, there is still a problem, even though the stations remain connected to wifi, the devices lose Internet connectivity. The device must cycle the wifi connection before it can re-establish Internet access. So while there is progress, I await to test with a 19.0.7.2 build before I'd call this fixed, unless there is a commit for the loss of internet as well.

[Openwrtfunboy]

@Openwrtfunboy @nbd168 In the testing this weekend, the disconnects were indeed fixed.

However, there is still a problem, even though the stations remain connected to wifi, the devices lose Internet connectivity. The device must cycle the wifi connection before it can re-establish Internet access. So while there is progress, I await to test with a 19.0.7.2 build before I'd call this fixed, unless there is a commit for the loss of internet as well.

Can you provide as much information as possible? Your observations? Assumptions?

[JFtico]

Can you provide as much information as possible? Your observations? Assumptions?

I was able to see that the devices were still connected to the Wifi, but they were showing "No internet".

For some reason, the devices wouldn't disconnect and connect back. I had to manually disconnect and connect back.

[Openwrtfunboy]

Can you provide as much information as possible? Your observations? Assumptions?

I was able to see that the devices were still connected to the Wifi, but they were showing "No internet".

For some reason, the devices wouldn't disconnect and connect back. I had to manually disconnect and connect back.

Please provide even more information. How many time client must be connected to the network for this to happen? How many clients connected to network when this happen? Do the same outages occur with LAN users?

[Rising-Sun]

Yes, because it fixed now by default in new builds.

No it shouldn’t be fixed because the new Mt76 driver hasn’t be pushed to the openwrt master branch, you have to manually change the makefile of the Mt76 driver.

[JFtico]

Please provide even more information.

The WiFi devices were losing the internet after a couple of hours. Not all devices were losing the internet, the TV never lost Internet.

This was with around 23-26 devices connected at all times.

Wired devices remained connected, so it was something in the wifi stack.

[Openwrtfunboy]

Yes, because it fixed now by default in new builds.

No it shouldn’t be fixed because the new Mt76 driver hasn’t be pushed to the openwrt master branch, you have to manually change the makefile of the Mt76 driver.

Take a look: https://github.com/openwrt/mt76/commit/master https://github.com/openwrt/mt76/commit/0a53dcda520346d45c4b280a19ff73cd50b0414b

[Openwrtfunboy]

Please provide even more information.

The WiFi devices were losing the internet after a couple of hours. Not all devices were losing the internet, the TV never lost Internet.

This was with around 23-26 devices connected at all times.

Wired devices remained connected, so it was something in the wifi stack.

Also provide information about you device.

So, we can wait only @nbd168

[9000000]

Can you provide as much information as possible? Your observations? Assumptions?

I was able to see that the devices were still connected to the Wifi, but they were showing "No internet".

For some reason, the devices wouldn't disconnect and connect back. I had to manually disconnect and connect back.

I have the same situation, I use xiaomi r3g v1 router, my house only uses a few devices

[nbd168]

I've pushed the mt76 update to OpenWrt master

[Openwrtfunboy]

@JFtico if you have another problem(not disconnecting) - open another issue. Now there my problem is solved.

[ergg]

Hi , I did have exactly the same problem after the "echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dynamic_sensitivity" my 5GHz Network works now and I can stop/start the Interfaces without any issues.