mt76x0u dongle disconnects

fortuna · 2022-08-16 12:36:14

Good news. Suddenly it's getting clearer what the problem really is. Luckily I discovered the following.

Once ping is running it continues to do so. But, starting ping after a period of inactivity of more than 30 secs or so the output looks like this:

user@laptop:~$ ping router
PING router.lan (192.168.0.1) 56(84) bytes of data.
64 bytes from _gateway (192.168.0.1): icmp_seq=2 ttl=64 time=16330 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=3 ttl=64 time=15280 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=4 ttl=64 time=14240 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=5 ttl=64 time=13212 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=6 ttl=64 time=12172 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=7 ttl=64 time=11132 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=8 ttl=64 time=10092 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=9 ttl=64 time=9042 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=18 ttl=64 time=2921 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=19 ttl=64 time=2044 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=20 ttl=64 time=3877 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=21 ttl=64 time=2878 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=22 ttl=64 time=1876 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=23 ttl=64 time=838 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=24 ttl=64 time=3.37 ms

This shows that it takes more than 15 secs before the first ping is acknowledged.
It is as if the dongle enters some kind of sleep mode when used @ 5 GHz.
I didn't notice this behaviour before because any wifi activity seems to keep the dongle "awake". Also reading email or browsing the internet. Even writing a reply in this forum does
Question is how to disable this sleep mode behaviour, if that really is what happens, but it looks like it.

seth · 2022-08-16 12:46:09

iw dev wlp0s29f7u5  set power_save off

https://wiki.archlinux.org/title/Power_ … interfaces

Possibly https://wiki.archlinux.org/title/Power_ … utosuspend
"usbcore.autosuspend=-1" will globally disable it, but can be overridden by userspace power management tools at runtime.

fortuna · 2022-08-16 15:35:50

Not there yet. After reboot turns out:

user@laptop:~$ sudo iw dev wlp0s29f7u7 get power_save
Power save: off

already. And with:

sil@laptop:~$ cat /etc/udev/rules.d/50-usb_power_save.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", ATTR{idProduct}=="7610", ATTR{power/autosuspend}="-1"

connecting to 5 GHz network seems to have become impossible altogether with 2.4 GHz still working flawlessly.

fortuna · 2022-08-18 12:26:25

You're not attaching it to an xhci port, nor are the any protocol errors, but maybe try a different usb slot anyway

Apart from the specific 5 GHz connection problem there is a slot related issue too.
Once connected to let's say 5 GHz it seems impossible to connect to a 2.4 GHz network without changing the dongle to a different USB slot.
And vice versa.

seth · 2022-08-18 15:15:12

Just retracting the dongle and plugging it back (implicitly resetting it) doesn't suffice?

fortuna · 2022-08-18 16:30:13

Just retracting the dongle and plugging it back (implicitly resetting it) doesn't suffice?

Yes. You're right. It does. That's why a reboot helps too.
Testing autosuspend again:

sil@laptop:~$ cat /etc/udev/rules.d/50-usb_power_save.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", ATTR{idProduct}=="7610", ATTR{power/autosuspend}="-1"

doesn't seem to make things better nor worse.

Last edited by fortuna (2022-08-18 16:47:49)

fortuna · 2022-08-22 17:20:23

Could it be the driver?

seth · 2022-08-22 20:29:27

Do you have the opportunity to test the dongle on different HW running some linux?
You could try the LTS kernel or a completely different SW stack (some live distro like grml)

mt76x0u doesn't seem to support power saving control, can you at all

iw dev wlp0s29f7u5  set power_save on

w/o getting an error yelled at you?

fortuna · 2022-08-23 22:08:08

user@laptop:~$ sudo iw dev wlp0s29f7u5 set power_save on
command failed: Operation not supported (-95)
user@laptop:~$ sudo iw dev wlp0s29f7u5 get power_save
Power save: off

As to your suggestion to try the dongle with different HW running linux, here are the off-the-shelf options:

up-to-date version of arch on a desktop PC. Only need to hook up a mouse and keyboard as it is usually headless and install NetworkManager
raspberry pi 3B with raspbian OS
a pendrive with a version of arch that is not up-to-date on a desktop PC
a desktop PC with windows. I know you prefer linux (who doesn't?) but the dongle came with a windows driver

Never tried Grml Live Linux. Didn't even know it.
One question though. Is it wise to vary HW and OS at the same time? On the other hand, a USB port is a USB port whatever HW it is on. The interesting variable to change is the driver, isn't it?

seth · 2022-08-24 06:59:10

Ideally you'd try same OS but different HW (USB ports are actually not all the same, they can vary in signal quality/stability and maximum off-spec current which is why some external drives work on some but not all USB ports) and a different OS on the same HW (in case it's a software/kernel regression)

fortuna · 2022-08-25 18:23:51

So I tested with option 1, an up-to-date version of arch on a desktop PC. Different HW.

Sometimes the dongle connects in the first attempt (never seen that on laptop):

user@host:~$ nmcli device wifi connect casillas5
Device 'wlp0s29f7u6' successfully activated with '9ad660cc-6c66-48f6-98d4-1c86d4c9d199'.

but mostly:

user@host:~$ nmcli device wifi connect casillas5
Error: Connection activation failed: (53) The Wi-Fi network could not be found.

The dongle then usually ends up connecting in the second attempt, sometimes in the third. It looks a bit smoother than with the laptop.
However, once connected it still seems to disconnect and/or enter a sleep mode or similar just like with the laptop:

user@host:~$ ping router
PING router.lan (192.168.0.1) 56(84) bytes of data.
64 bytes from _gateway (192.168.0.1): icmp_seq=2 ttl=64 time=6443 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=3 ttl=64 time=5403 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=4 ttl=64 time=4363 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=5 ttl=64 time=3323 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=6 ttl=64 time=2283 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=7 ttl=64 time=1243 ms
From host (192.168.0.10) icmp_seq=12 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=13 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=14 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=15 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=16 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=17 Destination Host Unreachable
From host (192.168.0.10) icmp_seq=18 Destination Host Unreachable
64 bytes from _gateway (192.168.0.1): icmp_seq=8 ttl=64 time=19723 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=9 ttl=64 time=18721 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=25 ttl=64 time=2054 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=26 ttl=64 time=1025 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=27 ttl=64 time=21.4 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=28 ttl=64 time=26.6 ms
64 bytes from _gateway (192.168.0.1): icmp_seq=29 ttl=64 time=200 ms
^C
--- router.lan ping statistics ---
29 packets transmitted, 13 received, +7 errors, 55.1724% packet loss, time 29028ms
rtt min/avg/max/mdev = 21.419/4986.826/19722.639/6379.191 ms, pipe 19

user@host:~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1669 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=8328 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=7761 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=8089 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=9784 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=8744 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=7705 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=6665 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=5625 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=25.8 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=9.93 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=31.7 ms
^C
--- 192.168.0.1 ping statistics ---
17 packets transmitted, 12 received, 29.4118% packet loss, time 16341ms
rtt min/avg/max/mdev = 9.929/5369.731/9784.167/3644.755 ms, pipe 10

And this didn't change either:

user@host:~$ sudo iw dev wlp0s29f7u6 set power_save on
command failed: Operation not supported (-95)
user@host:~$ sudo iw dev wlp0s29f7u6 get power_save
Power save: off

fortuna · 2022-08-29 16:54:19

Back to the laptop and to improve NetworkManager's logging I created:

user@laptop:~$ cat /etc/NetworkManager/conf.d/95-logging.conf 
[logging]
level=TRACE
domains=ALL

Now in the journalctl I found this line:

Aug 29 18:04:02 laptop NetworkManager[2504]: <trace> [1661789042.9360] device[937b23d916c2cfd5] (wlp0s29f7u7): powersave is set to 1

I thought all powersave options had been switched off but maybe they have not. This maybe the cause of the problem.

user@laptop:~$ cat /etc/udev/rules.d/50-usb_power_save.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0e8d", ATTR{idProduct}=="7610", ATTR{power/autosuspend}="-1"
user@host:~$ sudo iw dev wlp0s29f7u7 set power_save on
user@host:~$ sudo iw dev wlp0s29f7u7 get power_save
Power save: off

What did I miss?

seth · 2022-08-29 18:53:43

This maybe the cause of the problem.

Doesn't seem to be NM, though.
It might just have internally configured to enable PS and logs that it did so w/o accounting for the fact that it might fail in the driver.

Did you try "a different OS on the same HW" (can be any live distro, grml or full blown ubuntu)?

fortuna · 2022-08-31 18:51:19

I tried grml on the same HW but the dongle doesn't connect to either 2.4 GHz or 5 GHz:

http://ix.io/49gV

As you can see dhclient DHCPDISCOVER fails. Sometimes the 5 GHz network wasn't even visible during scanning.

The laptop onboard wifi connects normally.

seth · 2022-08-31 20:55:49

As you can see dhclient DHCPDISCOVER fails.

Unfortunately the carrier (I guess wpa_supplicant?) isn't logged, but the plit thickens, though https://github.com/torvalds/linux/tree/ … t76/mt76x0 doesn't show a lot of activity …
But at least the trajectory seems in your favor - did you ever try the behavior against a different AP (to see whether the AP and the dongle have bilateral issues…)?

Maniaxx · 2022-08-31 22:19:52

Try an USB3 port and do not use any additional extension cables. Many Wifi/USB-Modems/Dongles exceed USB2 power range (500mA). USB3 is 900mA.

Last edited by Maniaxx (2022-08-31 22:24:31)

seth · 2022-09-01 06:29:57

Though

The OP wrote:

And it is fast.... when it finally connects. But it takes ages before it does and then it disconnects randomly to start all over again.

fortuna wrote:

Once connected to let's say 5 GHz it seems impossible to connect to a 2.4 GHz network without [retracting the dongle and plugging it back]

(seems some firmware issue)

And while https://www.aliexpress.com/item/4000079918154.html seems some underspecified off-brand chinese roulette thing, it somewhat advertises it as ehci ("USB 2.0 Interface")
Let's see.

lsusb -vd 0e8d:7610

Though because of the grml situation: are there maybe other other (external) usb devices (on the same hub)?
Does there usage (or maybe bluetooth?) co-incide w/ the connection losses?

fortuna · 2022-09-01 20:42:57

user@laptop:~$ lsusb -vd 0e8d:7610

Bus 001 Device 004: ID 0e8d:7610 MediaTek Inc. WiFi
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.01
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0e8d MediaTek Inc.
  idProduct          0x7610 
  bcdDevice            1.00
  iManufacturer           1 MediaTek
  iProduct                2 WiFi
  iSerial                 3 1.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x004a
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              160mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           8
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x08  EP 8 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x09  EP 9 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1

fortuna · 2022-09-01 21:04:53

seth wrote:

are there maybe other other (external) usb devices (on the same hub)?

No. No bluetooth, nothing.

fortuna · 2022-09-01 21:08:00

seth wrote:

did you ever try the behavior against a different AP (to see whether the AP and the dongle have bilateral issues…)?

Very good idea! Buckle up.
I tried with an android phone with 5 GHz tethering capabilities. The dongle started connecting and continued connecting... When it looked like it was going to be connecting forever it suddenly connected!
The difference with the openwrt AP (TP-Link EAP225) is that connecting is aborted after some 25 secs. Therefore it "never" connects, because it takes longer, maybe due to some sleep mode issue.
So this is starting to look like a workaround! If the openwrt AP allows the dongle longer to connect, it will. If the AP aborts the connection attempt, the dongle tries again but that attempt is aborted after 25 secs as well.
Now I don't know how to change openwrt AP's connection timeout, but I'll find out.
The problem remains that it takes very long for the dongle to connect. It still looks like a sleep mode issue.

seth · 2022-09-02 06:57:11

Ftr

  bcdUSB               2.01
…
    MaxPower              160mA

fortuna · 2022-09-02 15:35:31

Maniaxx wrote:

Try an USB3 port

This laptop doesn't have any USB3 ports to try. But the dongle works fine in a USB2 slot as long as you keep it busy. If power supply was a problem it would get worse with a higher load, right? When there is no traffic the dongle seems to enter a kind of power sleep mode as you can see in post #26.

fortuna · 2022-09-02 16:09:19

The power sleep mode seems to last some 15 secs (post #26). The AP times out a connection attempt (authentication + associating) after 25 secs. That leaves 10 secs for the dongle to connect after waking up. Apparently not enough.

seth wrote:

And while https://www.aliexpress.com/item/4000079918154.html seems some underspecified off-brand chinese roulette thing

Because it's so cheap, more people will buy it and bump into this issue.

It would be interesting to know which linux was used by "amisix" who recommended the dongle here. It looks like he used it with a Raspberry Pi.

seth wrote:

seems some firmware issue

I agree. So is this the place where the firmware is built? I have no idea. Can I just contact the developer?

Last edited by fortuna (2022-09-02 16:39:18)

Maniaxx · 2022-09-02 17:34:09

fortuna wrote:

If power supply was a problem it would get worse with a higher load, right?

When there's a power problem you can get all kinds of erratic problems. That's the first thing i would want to rule out. It doesn't have to be this laptop (you could use an externally powered usb hub on that though). Try to make the stick run properly at least once.

If i reckon correctly MediaTek chipsets (at least some of them) are quite popular (best budget) in the OpenWrt scene as they support hardware offloading (ethernet version). Maybe look around in the dev channels or forum for your chipset.

seth · 2022-09-02 20:32:36

So is this the place where the firmware is built?

No, that's the kernel module.
The firmware would be /usr/lib/firmware/mediatek/mt7610u.bin.xz and comes from https://archlinux.org/packages/core/any/linux-firmware/ which would be https://git.kernel.org/pub/scm/linux/ke … t7610u.bin - no idea but I guess that's a binary blob extracted from the windows driver or provided by mediatek.
I also don't think that the band-switching issue is directly connected to the "slow to connect" issue.

Wrt. the power saving theory: if you first run a scan and then immediately connect to the AP afterwards, does that work? (for the scan needs to wake the chip and make its use its radio, idk how it could not be ready at this point)

Arch Linux

#26 2022-08-16 12:36:14

Re: mt76x0u dongle disconnects

#27 2022-08-16 12:46:09

Re: mt76x0u dongle disconnects

#28 2022-08-16 15:35:50

Re: mt76x0u dongle disconnects

#29 2022-08-18 12:26:25

Re: mt76x0u dongle disconnects

#30 2022-08-18 15:15:12

Re: mt76x0u dongle disconnects

#31 2022-08-18 16:30:13

Re: mt76x0u dongle disconnects

#32 2022-08-22 17:20:23

Re: mt76x0u dongle disconnects

#33 2022-08-22 20:29:27

Re: mt76x0u dongle disconnects

#34 2022-08-23 22:08:08

Re: mt76x0u dongle disconnects

#35 2022-08-24 06:59:10

Re: mt76x0u dongle disconnects

#36 2022-08-25 18:23:51

Re: mt76x0u dongle disconnects

#37 2022-08-29 16:54:19

Re: mt76x0u dongle disconnects

#38 2022-08-29 18:53:43

Re: mt76x0u dongle disconnects

#39 2022-08-31 18:51:19

Re: mt76x0u dongle disconnects

#40 2022-08-31 20:55:49

Re: mt76x0u dongle disconnects

#41 2022-08-31 22:19:52

Re: mt76x0u dongle disconnects

#42 2022-09-01 06:29:57

Re: mt76x0u dongle disconnects

#43 2022-09-01 20:42:57

Re: mt76x0u dongle disconnects

#44 2022-09-01 21:04:53

Re: mt76x0u dongle disconnects

#45 2022-09-01 21:08:00

Re: mt76x0u dongle disconnects

#46 2022-09-02 06:57:11

Re: mt76x0u dongle disconnects

#47 2022-09-02 15:35:31

Re: mt76x0u dongle disconnects

#48 2022-09-02 16:09:19

Re: mt76x0u dongle disconnects

#49 2022-09-02 17:34:09

Re: mt76x0u dongle disconnects

#50 2022-09-02 20:32:36

Re: mt76x0u dongle disconnects

Board footer